February 2002 - ipv6-wg - mailman.ripe.net

Summary of IPv6 Policy Discussions at RIPE41
by James Aldridge 27 Feb '02

27 Feb '02

With apologies for the time that it's taken me to get this posted to the list, here is an attempt to summarise the discussions which took place among the approx. 180 people attending the Local IR working group at RIPE41 on 16th January 2002. Although many of those attending the working group had read the published draft, | IPv6 Address Allocation and Assignment Global Policy | Draft of December, 22 2001 | Version 2001-12-22 | APNIC | ARIN | RIPE - NCC we started this session with a presentation by Mirjam Kuehne from the RIPE NCC (http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/ipv6-mir/) which summarised the main points of the current document. Most of the discussion centered on section 5.2 of the draft related to the Initial Allocation Criteria and Initial Allocation Size | 5.2.1. Initial allocation criteria | | A requesting organization can receive an initial allocation by | demonstrating that it has an immediate (i.e., within next three | months) requirement for at least a /36 prefix. That is, immediately | after the allocation, the organization will have 776 or more sites in | need of address assignments. 776 is the number of /48 address blocks | that can be assigned out of a /36 address block to achieve an HD- | Ratio of 0.8. The HD-Ratio is an address allocation utilization | metric proposed in RFC 3194 as an adaptation of the H-Ratio | originally defined in [RFC1715]. (See also Section 5.3.3.) | | [Note: discussion is needed as to whether justification for need of a | /36 is reasonable initial starting point, or whether the criteria of | an immediate need to address 776 sites is too high. Note also, that | once a request for an initial allocation has been granted, the | minimum allocation (i.e., /32) is provided, even though the requestor | has not justified a need for such a large amount of space.] The general consensus at the meeting was that this placed too high a barrier to registries at a time when getting real IPv6 deployment underway was seen as becoming more urgent. Several alternatives were discussed, but the one which seemed to achieve almost complete consensus from those at the meeting involved dropping the "776 or more sites" and HD-Ratio requirements completely. The proposal can be summarised as: "For a limited period (no more than the first 2000 allocations in each RIR area was suggested), a requesting registry (either a LIR or NIR in the draft's terminology) would receive a /32 minimum allocation from the appropriate RIR on the documentation of at least one /48 assignment." This is just one way of removing the barrier imposed in the current draft... there are, of course, other possibilities which weren't discussed at the meeting. This lowers the barrier to whatever policies the RIRs have in place for the establishment of new local or national registries. The aim was seen as being to obtain global consensus based on the current draft as an *interim* policy, with final policy being worked on as experience was gained during the "2000*3 allocations" period. Time was such that discussion of other sections of the draft were only covered briefly, if at all. James Aldridge (Co-chair, RIPE LIR WG)

1 0

up a few thousand meters
by Randy Bush 15 Feb '02

15 Feb '02

the rirs, as the meeting place of those responsible for prudent operation of the network, have traditionally been where the compromise between the three *competing* and *conflicting* vectors of o address space conservation, o routing table growth, and o ease of allocation for isps have responsibly reached compromise. this has not been an easy balance because the three really are in conflict with each-other. but, as prudent operators, and as shepherds of a public good, we have struggled along to manage in a really pretty responsible fashion. witness that one can get and use the ip space one needs, the routing table has not gotten completely unmanageable (especially if you filter prudently <g>), and there is a fair amount of v4 space left. as we move into the v6 world, prudent folk find it hard not to assume that the same or similar forces will be at work. v6 gives us zero leverage on the routing table expansion problem. there is no reason to believe that the seemingly enormous 128 bit address space of v6 will turn out to be any more infinite than the seemingly enormous 32 bit address space did some decades ago. and, as operators, we still have the annoying problems and responsibilities of acquiring, tracking, allocating, ... the address space which is vital to our businesses. in moving forward, it would seem irresponsible to let one consideration obviate all others. e.g. some once thought tlas would solve the routing table growth issue by limiting the global universe to 8k isps. this month, others think ease of allocation is most important, and the problems of address consumption and routing table growth are old-fashioned fears. sadly, as we have discovered in exploring the issues of multi-homing and routing table growth, and as we learned that frequent and rapid renumbering may not be the realities, we seem to need to be a bit cautious about the new world, and not leap to bold conclusions and make radical changes based on yet to be proven assumptions. as isps, in our rush to make life easy for ourselves at the possible expense of other considerations, let us not again demonstrate george santayana's wisdom by repeating history, again creating a swamp, losing track of detailed allocation data, ... as far as i can tell, v6 deployment is not being inhibited by issues surrounding address space allocation. randy

6 10

Re: [GLOBAL-V6] Re: up a few thousand meters
by Randy Bush 14 Feb '02

14 Feb '02

> Agreed. As some of us think it would be a good thing to push IPv6 > onwards, we de-emphasize conservation right now, and emphasize > easy access to address space. this seems to be based on some idea that it is address space policy, as opposed to continuingly changing the policy, which is inhibiting the deployment of v6. this does not seem to be the case. > But let's rethink whether all of our experience is fully appropriate > in changed circumstances. re-thinking is always good. acting before thinking is generally not. randy

2 3

RE: up a few thousand meters
by Lelieveld, Sander 12 Feb '02

12 Feb '02

Hi all, Please can you put "[GLOBAL-V6]" or something in Subject field. Regards, Sander Lelieveld Alcatel Netherlands. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: dinsdag 12 februari 2002 13:13 To: Daniel Karrenberg Cc: global-v6(a)lists.apnic.net; ipv6-wg(a)ripe.net; Randy Bush Subject: Re: up a few thousand meters On Tue, 12 Feb 2002, Daniel Karrenberg wrote: > - V6 per-se does *not at all* solve the routing (table) problem > That's true in a technical sense. However, there are a few reasons why we, even though IPv6 does not solve the problem, _can_ solve it: 1) organizations, however large, can be represented by one "dot", a /48. This enables us, at worst, to have O(organizations) routing table entries, not O(organizations * average number of nodes per organization). The former is too big still, but it is still good news and makes aggregation and address space estimations easier. 2) it's all new protocol -- not a win as such, but due to this, we can _reinvent_ the routing system (within some restrictions) the way we see fit, based on earlier experience. Let's not pretend 2) does not exist. There are 6bone routing guidelines, which have been happily adapted by production operators (sTLA) also; they prevent most of the problems we're now facing with IPv4 global routing table growth. Why toss all of that aboard, pretending we cannot work around the routing problem for now when moving to IPv6 (note: I didn't say IPv6 would magically solve the problem!)? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords

1 0

Re: [GLOBAL-V6] up a few thousand meters
by Randy Bush 12 Feb '02

12 Feb '02

apocrypha can be misleading > As far as I can tell, v6 deployment in the ARIN region is not taking > place due to desinterest. > > The APNIC people have very clearly stated at R40 (at least) their need > for a workable interim policy, and there is still none. They are > building production IPv6 networks today. come to ietf in minneapolis, which is still in the arin region as far as i know, where c&w will be the upstream running native v6 on their backbone. [ this is not a side prototype atm network running on bsd/kame or cisco's slow path marketecture, but a full bore, line rate, native v6 enabled backbone ] randy

1 0

Válasz: [GLOBAL-V6] Re: Válasz: [GLOBAL-V6] RE: How to reduce the junk applications?
by turchanyi.geza＠ln.matav.hu 12 Feb '02

12 Feb '02

Gert, I agree, ONE DAY setting up IPv6 only services MUST be possible. However, I do not think that we can apply this assumption today. Most probably not in the next two years to come. The question here is how to enable the transition period for most of the ISPs as soon as possible, without creating too big mess. If you end up with a heavily scattered address space, then the IPv6 transition is killed before it has been completed. Everybody will have addresses, just the routing will be missing. I do not know how to solve all aspects of this problem, but keeping the number of IPv6 LIRs under control is a MUST, I think. Best, Geza Gert Doering <gert(a)space.net> dátum: 2002.02.08 14:46:46 Címzett: Turchányi Géza/PKI/HTC2@HTC2 Másolat: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at>, denesh(a)cyberstrider.net, global-v6(a)lists.apnic.net, ipv6-wg(a)ripe.net Tárgy: [GLOBAL-V6] Re: Válasz: [GLOBAL-V6] RE: How to reduce the junk applications? Hi, On Fri, Feb 08, 2002 at 02:17:29PM +0100, turchanyi.geza(a)ln.matav.hu wrote: > 1, I do not think that it is possible to create a brand new ISP without IPv4 > experience, therefore my suggestion is not a restriction for a real ISP, just > for the virtual ones. It MUST be possible if we want IPv6 to be a success. It's to be assumed that the employees of this company will have IPv4 experience (of course), but that doesn't mean the company has a track record of "having been IPv4 LIR for xx years". > 2, It is not mandatory to create a LIR In order to provide an IP service. An > other LIR can provide a service for you. But for those cases, this whole discussion does not apply. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71770 (72395) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 - - This list (global-v6) is handled by majordomo(a)lists.apnic.net

2 1

Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by CJ Wittbrodt 11 Feb '02

11 Feb '02

Arano-san, First I'd like to respond to your last sentence, your English is just fine... thanks for the thoughtful note. I have one comment (see below) At 09:52 02/02/07, CJ Wittbrodt wrote: >Maybe we should look at the people you refer to as wanting to be "in" >and figure out what distinguishes them from just some end user who >should have a /48 from their upstream...? Yes, this is the point. I basically supports RIPE's consensus. First, requiring 776 customer sites as criteria of getting /32 is a too high barrier and should be relaxed in any way. Maybe, anyone can agree with this so far. Next, "any LIR can get /32 until 2000 /32 per a region" is almost OK, but one problem may be to use the existing definition(s) of "LIR" mainly defined for IPv4. In ARIN region, you can become a LIR if you pay some money as far as I heard. This may include an large enterprise. One concern here is that this rule will give /32 end users even if they are large enterprise. We should avoid this as Thomas suggested. In the ARIN region, it is true, anyone can become a member of ARIN by paying a fee. to get address space, however, you have to give quite a lot of justification. Every ARIN member does not have address space. I just want to make sure that's clear. I am a member of ARIN as an individual. I paid $500 for the year 2002. I have no address space and I am not what you'd call an LIR. ---CJ

3 2

RE: How to reduce the junk applications?
by turchanyi.geza＠ln.matav.hu 11 Feb '02

11 Feb '02

Tim, I am sure that there is a misunderstanding here. I never proposed anything that would limit the IPv6 address allocations to any organisation. What I said, however, that address assignement need some experiences - even if there are "plenty addresses"; those wanted to have IPv6 address should go to an experienced LIR; and anyhow, IPv6 networking is not a turnkey issue. Probably we need another two years for that. LIR not equal to an ISP. Best, Geza Tim Chown <tjc(a)ecs.soton.ac.uk> dátum: 2002.02.11 12:54:48 Címzett: Turchányi Géza/PKI/HTC2@HTC2 Másolat: Denesh Bhabuta <denesh(a)cyberstrider.net>, "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at>, global-v6(a)lists.apnic.net, ipv6-wg(a)ripe.net Tárgy: Re: Válasz: Re: Válasz: [GLOBAL-V6] RE: How to reduce the junk applications? On Mon, 11 Feb 2002 turchanyi.geza(a)ln.matav.hu wrote: > 2, You might heard about big research initiatives for the introduction of IPv6 > service. A good example is 6net. > > 6NET will have initially its own infrastructure, and there is a good reason > behind: it would be too risky to use a production network. > > This is not the eventual address allocation restriction that will stop new > IPv6-only companies to pop up, but the basic limitations of the technology and > the installed services. I disagree; if 6NET were a commercial project, not a EC-funded research and development project, we would want IPv6 address space. With your rules, we could not get it, which is very bad. Likewise with the Euro6IX project, where the partners are predominantly telcos rather than NRENs. Tim

2 1

Válasz: Re: Válasz: [GLOBAL-V6] RE: How to reduce the junk applications?
by turchanyi.geza＠ln.matav.hu 11 Feb '02

11 Feb '02

Denesh, The most probably you know the answers ;-) 1, We applied restrictions on IPv4 LIRs. This is "the slow start mechanism". Restrictions are not for themself. The goal of hardening the life of a new LIR was just to filter off a half million students, that might want to create a LIR, just to decorate their business card. There are many-many small business unit that may pay the fees to become a registry, however, not able to provide a service that realy need a LIR. Too many LIR is against routability. I would not recommend an address allocation strategy that kills the network. Today some ISPs filters IPv4 /24 announcements - if we are not careful with IPv6 LIRs, we will end up of filtering of the minimum allocation to a LIR. Therefore I recommend to think about the network as a whole. I like the liberty however I do not like the mess. 2, You might heard about big research initiatives for the introduction of IPv6 service. A good example is 6net. 6NET will have initially its own infrastructure, and there is a good reason behind: it would be too risky to use a production network. This is not the eventual address allocation restriction that will stop new IPv6-only companies to pop up, but the basic limitations of the technology and the installed services. Applying restrictions in the transition period is better than creating a mess. Best, Geza Denesh Bhabuta <denesh(a)cyberstrider.net> dďż˝tum: 2002.02.08 14:23:35 Kďż˝rem, vďż˝laszoljon Cďż˝mzett Denesh Bhabuta <denesh(a)cyberstrider.net> Cďż˝mzett: Turchďż˝nyi Gďż˝za/PKI/HTC2@HTC2 Mďż˝solat: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at>, global-v6(a)lists.apnic.net, ipv6-wg(a)ripe.net Tďż˝rgy: Re: Vďż˝lasz: [GLOBAL-V6] RE: How to reduce the junk applications? On Fri, Feb 08, 2002 at 02:17:29PM +0100, turchanyi.geza(a)ln.matav.hu (turchanyi.geza(a)ln.matav.hu) wrote: Re: Vďż˝lasz: [GLOBAL-V6] RE: How to reduce the junk applications? > 1, I do not think that it is possible to create a brand new ISP without IPv4 > experience, therefore my suggestion is not a restriction for a real ISP, just > for the virtual ones. I disagree on two points Firstly, what is an ISP (real or virtual) - define one. Secondly, IPv4 experience? What experience? registry experience, transport experience, network harware experience? what about those 'new' ISPs that have employed the services of, or even recruited, a person who had 10 years IPv4 experience. Company is new.. but the experience is old.. who are we to say that an ISP is experienced or not? -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net - Computer shop now live me.uk domains released - http://www.cyberstrider.net/meuk.shtml

2 1

Válasz: Re: Válasz: [GLOBAL-V6] RE: How to reduce the junk applications?
by turchanyi.geza＠ln.matav.hu 11 Feb '02

11 Feb '02

Denesh, The most probably you know the answers ;-) 1, We applied restrictions on IPv4 LIRs. This is "the slow start mechanism". Restrictions are not for themself. The goal of hardening the life of a new LIR was just to filter off a half million students, that might want to create a LIR, just to decorate their business card. There are many-many small business unit that may pay the fees to become a registry, however, not able to provide a service that realy need a LIR. Too many LIR is against routability. I would not recommend an address allocation strategy that kills the network. Today some ISPs filters IPv4 /24 announcements - if we are not careful with IPv6 LIRs, we will end up of filtering of the minimum allocation to a IPv6 LIR. Therefore I recommend to think about the network as a whole. I like the liberty however I do not like the mess. 2, You might heard about big research initiatives for the introduction of IPv6 service. A good example is 6net. 6NET will have initially its own infrastructure, and there is a good reason behind: it would be too risky to use a production network. This is not the eventual address allocation restriction that will stop new IPv6-only companies to pop up, but the basic limitations of the technology and the installed services. Applying restrictions in the transition period is better than creating a mess. Best, Geza Denesh Bhabuta <denesh(a)cyberstrider.net> dďż˝tum: 2002.02.08 14:23:35 Kďż˝rem, vďż˝laszoljon Cďż˝mzett Denesh Bhabuta <denesh(a)cyberstrider.net> Cďż˝mzett: Turchďż˝nyi Gďż˝za/PKI/HTC2@HTC2 Mďż˝solat: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at>, global-v6(a)lists.apnic.net, ipv6-wg(a)ripe.net Tďż˝rgy: Re: Vďż˝lasz: [GLOBAL-V6] RE: How to reduce the junk applications? On Fri, Feb 08, 2002 at 02:17:29PM +0100, turchanyi.geza(a)ln.matav.hu (turchanyi.geza(a)ln.matav.hu) wrote: Re: Vďż˝lasz: [GLOBAL-V6] RE: How to reduce the junk applications? > 1, I do not think that it is possible to create a brand new ISP without IPv4 > experience, therefore my suggestion is not a restriction for a real ISP, just > for the virtual ones. I disagree on two points Firstly, what is an ISP (real or virtual) - define one. Secondly, IPv4 experience? What experience? registry experience, transport experience, network harware experience? what about those 'new' ISPs that have employed the services of, or even recruited, a person who had 10 years IPv4 experience. Company is new.. but the experience is old.. who are we to say that an ISP is experienced or not? -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net - Computer shop now live me.uk domains released - http://www.cyberstrider.net/meuk.shtml

1 0