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@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299