July 2004 - address-policy-wg

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

Updated RIR Comparative Policy Overview document available
by leo vegoda 20 Jul '04

20 Jul '04

Dear Colleagues, We are pleased to announce that an updated version of the "RIR Comparative Policy Overview" is now available and can be found at: http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix- rev.html This version, 2004-07, is numbered using the year and month of publication. It replaces version 2.1, which was published on 7 August 2003. Regards, -- leo vegoda Registration Services Manager RIPE NCC

2 1

Registration Deadline - RIPE NCC Regional Meeting, Nairobi 28 - 30 July 2004
by Membership Liaison Officer 12 Jul '04

12 Jul '04

[Apologies for duplicate mails] Dear Colleagues, This is a final reminder that the RIPE NCC Regional Meeting in Nairobi will be held 28 - 30 July 2004 at the Norfolk Hotel in Nairobi, Kenya. Attendance to the RIPE NCC Regional Meeting is free of charge. However, attendees are responsible for covering their own travel and accommodation costs. REGISTRATION Please note that registration for the Regional Meeting closes on 19 July 2004. To register, please see: http://www.ripe.net/cgi-bin/nairobi-reg AGENDA The agenda has recently been updated with more information about speakers and presentations. For the full agenda, please see: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/agenda.html TRAINING As a part of the Regional Meeting the RIPE NCC will hold a Routing Registry and DNSSec seminar in the afternoon of Thursday, 29 July 2004. In addition, RIPE NCC will be holding an LIR Training Course on Friday 30 July 2004. You can register for the LIR Training Course at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Information about the contents of the course can be found at: http://www.ripe.net/training/ If you have any questions about the Training Course, please contact us at: <training(a)ripe.net>. MORE INFORMATION More information about the RIPE NCC Regional Meeting, Nairobi is available from: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/index.html Any further questions can be sent directly to: <contact(a)ripe.net>. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC

1 0

IPv6 Policy Clarification - Initial allocation criteria "d)"
by Laura Cobley 06 Jul '04

06 Jul '04

Dear Colleagues, We have received many comments that the text of the current IPv6 Allocation and Assignment Policy document can be difficult to read and understand. Some of these difficulties were presented at RIPE 48 by Leo Vegoda: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-poli… During the following discussions, the RIPE NCC was asked to co-ordinate work on clarifying the text. Please note that we do not intend to propose any policy changes. In order to assist with rewriting the IPv6 Policy document, we would like to have some input from the community on the issues needing clarification. We will send each issue for discussion in a separate mail. This is the first of these mails. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "d)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years." 1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention? 2. There are a number of interpretations of requirement "d)": - NUMBER OF ASSIGNMENTS -- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48. -- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s. Which interpretation was intended regarding the number of assignments? - RECIPIENT OF ASSIGNMENTS -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations. -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted. -- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation. -- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure". Which interpretation was intended regarding the recipient of assignments? We look forward to receiving the community's input on this. Best Regards, Laura Cobley Registration Services RIPE NCC

36 176

RE: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by Chris Cain 05 Jul '04

05 Jul '04

> imho the difficulty here is how do you define a "large" network, i mean > when a network is large enough to obtain its own allocation. > > to which i guess one option is what you mention below.... > [...] > > > > > Maybe the rule should not say "planning to connect 200 organizations" > > but > > rather "will connect x devices within the next 2 years". X has to be > > negotiated. Or, instead of devices, networks. But these are much more > > useful > > numbers. As well for some ISPs (which only 5-20 customers, but these > > are > > big) as for other organizations, which in the end connect more > > end-users > > then most ISPs. > > > > how much is x? > Since the device count is not the limited resource but the route count is how about a completely different size measure. As a first attempt: 1. Define a list of interconnect points (NAPS/interconnect exchanges) This would be fairly strict with only the main interconnect points in each country qualifying. 2. Any entity wanting an allocation must interconnect IPV6 at more than N of these points (and be an LIR of course) to qualify for an allocation. I don't know how the number of allocations would vary with N but a guess is that N=2 would be a reasonable number. Chris Cain

4 3

RE: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by matthew.ford＠bt.com 05 Jul '04

05 Jul '04

Hi Marcelo, > -----Original Message----- > From: address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net] On Behalf Of > marcelo bagnulo braun > Sent: 02 July 2004 10:49 > To: Nils Ketelsen > Cc: address-policy-wg(a)ripe.net > Subject: Re: [address-policy-wg] IPv6 Policy Clarification - > Initial allocation criteria "d)" > > Hi Nils, > > El 02/07/2004, a las 2:03, Nils Ketelsen escribió: > > > On Thu, Jul 01, 2004 at 11:49:27AM -0400, Thomas Narten wrote: > > > >> Jon Lawrence <jon(a)lawrence.org.uk> writes: > >> It seems that folk have lost site of the motivation for this > >> rule. What we were trying to achieve (and believe we still > MUST strive > >> to achive) is a balance between making it straightforward for a > >> serious ISP to get an IPv6 block, but also prevent what is > essentially > >> an end site from getting an allocation direct from an RIR. > The latter > >> is not scalable long-term and must be prevented in general. > > > > I know a lot of endsites, that (essentially) have (a) a lot > more need > > for > > address space than many ISPs and (b) the realistic chance to deploy > > IPv6 in > > a large network, because they can actually force the use of IPv6 in > > their > > network. > > > > imho the difficulty here is how do you define a "large" > network, i mean > when a network is large enough to obtain its own allocation. What Thomas said. Allocations should not be made based on the size of the network, but rather on the location of the network within the overall heirarchy. In the absence of a multihoming solution, this is the only way that scalability can be preserved long-term. > > Maybe the rule should not say "planning to connect 200 organizations" > > but > > rather "will connect x devices within the next 2 years". X has to be > > negotiated. Or, instead of devices, networks. But these are much more > > useful > > numbers. As well for some ISPs (which only 5-20 customers, but these > > are > > big) as for other organizations, which in the end connect more > > end-users > > then most ISPs. > > how much is x? x is irrelevant. -- Mat

3 2