[address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"

Hi,

SUMMARY of the IPv6 working group thread 
  "Re: IPv6 Policy Clarification - Initial allocation criteria "d)"

The discussion started with a request for clarification from the RIPE
NCC hostmasters about the "200 /48 assignments to other organization"
rule.

At first, people discussed various interpretations of this:

  - whether or not "infrastructure /48s" count towards the 200 number
    (no clear statement what really was intended, as it didn't originally
    come from the RIPE region, and people have very different opinions on
    what it should be)

  - whether or not ISPs assigning only /64s (3GPP networks) qualify
    (most people seem to agree that those qualify, but per the letter, 
    they don't.  Some comments are confused why someone would assign
    /64s at all, but that's what the 3GPP standard recommends)

In the course of the discussion, one major point emerged:

  - please *change* the policy and remove the "200 assignments" clause
    (and leave the remaining criteria mostly unchanged, that is, the
    applicant still has to be a LIR).

there have been many voices supporting this change, and only one
voice vehemently argueing against it.  Masaka Ohta urges us to rework
the whole system to make sure that at maximum 1000 routes appear in
the global table.

To base the WGs decision on more facts, the RIPE NCC has been asked to
provide an overview about the current IPv6 policy (proposals) in the
other regions.  Filiz from the NCC has done this yesterday (thanks).


There have been a couple of sidetrack discussions without specific 
results:

- whether the "one size fits all" (/32) model for sizing the LIR
  allocations is a good way to tackle things, or whether it's repeating 
  the "class A allocation" error.

- whether or not using "more specific PA space" from one upstream ISP is 
  a valid way to do BGP multihoming, at least for some networks

- whether or not the price of a >10Gbit router is significantly changed
  if the number of routes it must carry is hard capped to 1000 (or 8192).

  (Oliver Bartels has sent me some more supporting documents.  His claim 
  is that a TCAM memory based hardware forwarding engine can handle
  at least 65k IPv6 prefixes at >10Gbit/s with a $150 US$ TCAM per
  line card.  Going to a $350 US$ TCAM per line card enables >130k 
  prefixes.  Comparing that to the cost of 10Gbit/s. optics, SDH
  framing chips, and hardware development effort, that's a only a minor 
  part of the total costs.  For lower bandwidth, todays algorithms don't 
  even need TCAM, SRAM is enough. Details upon request)

- a very vehement discussion concerning a specific IETF multi6 proposal
  which may or may not have been judged fairly by the multi6 working
  group.  Kurtis Lindqvist moved *that* subthread to the IETF list, and
  volunteered to give updates about multi6 progress to the APWG list.


- at least two persons voiced very clearly that they are convinced IPv6
  deployment will not go ahead unless companies that have their own IPv4
  address space today will be able to reach that amount of independence
  and flexibility with IPv6 as well.   Read: get "IPv6 PI" address
  space (or qualify for a LIR allocation, which is effectively the same).

  This latter part worries me.


Judging from the discussion, and "counting voices", I propose to
proceed as follows:

 - study the "other regions policy" report from the RIPE NCC

 - try to come up with new rules for the allocation criteria, dropping
   the 200-assignments part, and integrate whatever is necessary to
   balance the remainder.

 - circulate that proposal, present it at RIPE49, and if there is
   consensus, integrate it into the official RIPE policy.


I don't think that we will be able to find consensus for "let's start
handing out PI address space".  But if one of the proponents wants 
to try to propose a policy that will permit "special networks" 
to receive a portable allocation without widely opening the flood
gates (there *is* consensus that "everybody can get their own block
and carry it around" is *not* what will scale), please go ahead and
do so.  Please do it in a new thread, though.

Gert Doering
        -- APWG Co-Chair
-- 
Total number of prefixes smaller than registry allocations:  60210  (58081)

SpaceNet AG                 Mail: netmaster at Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299