- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs
by Doug Barton 10 Aug '04

10 Aug '04

> On Monday 09 August 2004 18:42, Randy Bush wrote: >> leo, >> >> can you explain why the rirs need a time window from the iana >> (36 months) so much larger than lirs need from the rirs? >> >> randy > > Randy, > I read it that IANA don't see RIR's needing more than a /12 in a 36 month > period - thus a /12 would at least meet the RIR's needs for the next 36 > months. > > Seems like a much better idea than faffing about handing out a /23 every few > months. > > Jon Jon, Just to be clear, the policy as proposed is coming to you direct from the NRO, IANA has had no direct input in it's creation. I first saw this draft document myself on the APNIC sig-policy list on 4 August. http://www.apnic.net/mailing-lists/sig-policy/archive/2004/08/msg00003.html That said, we're very happy that the NRO has offered this submission as a starting place for the public dialog, and we look forward to seeing how the process plays out. While it's certainly not IANA's job to _set_ policy, we are happy to offer the benefit of our experience to anyone who asks. :) Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority

2 1

Re: NCC#2004080845 IPV6 Addresses pool
by RIPE NCC 09 Aug '04

09 Aug '04

Dear Gil, The following link will give you a list of all LIRs who received an IPv6 allocation from RIPE NCC. However, it is not ordered per country. http://www.ripe.net/ripencc/mem-services/general/allocs6.html Kind regards, Monique van Troost First Line Support Operator RIPE NCC On Mon, 9 Aug 2004 09:46:37 +0200, Gil Yaacoby wrote: > Hi , > > My name is Gil Yaacoby. I am responsible for the evaluation of > new Datacom technologies in Cellcom Israel Ltd. IPv6 is one of our > current projects.I need to find out the formal procedure to purchase an > IPv6 address > pool > > we need IPV6 Addresses pool for our cellular costumers. > I think that at this point of time Cellcom Israel Ltd can't show > bussiness case for being a LIR . > > I think getting small amount like /48 from some ISP will be good enough. > Do you know about any ISP's who can provide Cellcom IPV6 adresses pool > (In ISRAEL or outside the country)? > > Many thanks, > > Gil Yaacoby > > > --------------------------------------------------------------------------------------------------------------- > This e-mail message may contain confidential, commercial and privileged information or data that constitute proprietary information of Cellcom Israel Ltd. Any review or distribution by others is strictly prohibited. If you are not the intended recipient you are hereby notified that any use of this information or data by any other person is absolutely prohibited. If you are not the intended recipient, please delete all copies. > > Thank You. > http://www.cellcom.co.il --

2 1

Re: Policy Change Request - Allow address allocations for anycast DNS operation] (fwd)
by Pekka Savola 01 Aug '04

01 Aug '04

Following up with really old email.. [Gert:] > On Tue, Jun 15, 2004 at 02:11:22PM +0300, Pekka Savola wrote: > > On Tue, 15 Jun 2004, Gert Doering wrote: > > > One comment asked for "do we really need yet another special rule here", > > > and my reply would be "the current PA and PI policy doesn't permit doing > > > this without lying to the NCC", *and* DNS is really special here due to > > > protocol constraints. > > > > If you qualify for at least /24 of v4 address space, there shouldn't > > be a problem with current v4 policy? > > There is. People don't want to use part of their PA block for the > anycast announcement (due to "allocation boundary" filters) and you > won't qualify for a /24 PI with just a single IP address used inside > the block. I don't think this really matters. First, the allocation boundary filters filters filter out a lot of stuff as well. If you put them in, you should know that you might not get some advertisements. Second, even if you filter on the boundary, you'll just go to the main office, not necessarily the closest anycasting service. So, the service you get is no worse than it's today. Last, there are also those other, non-anycasted servers, so you'll be able to reach them as well. I don't clearly see why this exception is necessary, especially if folks document the more specific block appropriately in the registry. > > If you can't qualify for that amount of addresses, do we care about > > anycasting that kind of server? > > The ccTLD's office might have 500 machines in use, but the individual > instances will all only use 1 IP (or very few). I'm not sure what you meant by 1 IP -- the DNS server or some small offices? (or offices behind a NAT?) > > Remember, nothing prevents anycasting with your existing allocated > > blocks. Hence, the policy for allocating these special PI/PA prefixes > > should be at least as strict as the policy for getting PI/PA prefixes > > in the first place .. to avoid getting around policies. > > The problem in the first place is that the PI policy doesn't permit > these prefixes in the first place, due to insufficient utilization. Ok -- then we have still the PA policy left that might be useful. > [..] > > I object to this as a whole, but even if we agreed that this is > > desirable in general, I have two strong objections: > > > > (1) there is little reason for allocating a /32 IPv6 prefix except > > for getting around the IPv6 policy. Why not use the "critical > > infrastructure" /48's for this, so we can easily filter out this junk > > in our BGP :) > > We have no "critical infrastructure" /48s in RIPE land, *and* you're > not supposed to catch this in "general-purpose more-specific filters" > - which is the whole point of this excercise. > > (If you really want to filter the prefixes, you still can, as they are > supposed to be clearly tagged in the RIPE DB). Just chunk out a couple of /48's from the block where the IX addresses have been allocated? Given the reasoning above, and the fact that the servers should always also include non-anycasted addresses, I see no reason why these should be given special status -- it's not as if it's critical that these prefixes go through the filters or aelse all else breaks. That IMHO argues for similar treatment as ARIN's "critical infrastructure" prefixes: /48's which some might and some might not filter. We certainly intend to :). > > (2) this proposal takes no stance on who can request a block of > > addresses like this for his DNS servers? > > Yes. On purpose, because it was envisioned that some organizations > that are not TLD operators but still operate a high number of DNS > servers (due to having a very large number of zones, or due to > having a world-wide network, or whatever) might still meet the > spirit of the thing. Due to reasons discussed below, I strongly believe that we need restrictions here. I don't care much about giving special golden PI blocks to TLD operators, but I care even less for giving them anyone at all that comes knocking at the door! TLD operators should at least be considered (by some measure) "semi-critical" infrastructure. Big ISPs don't need these special provisions, and the net doesn't care about the small ISPs which can't get routable PI otherwise (and this would be a nice trick to get it through a loophole). In short, let's just decide on a list, if we need this in the first place. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

1 0

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

New AS Number Block allocated to RIPE NCC
by Filiz Yilmaz 30 Jun '04

30 Jun '04

Dear Colleagues, The RIPE NCC received the AS Number Block 33792 - 34815 from the IANA in June 2004. You may want to update your records accordingly. Kind regards, -- Filiz Yilmaz RIPE NCC

1 0

Reminder - RIPE NCC Regional Meeting, Nairobi, Kenya 28-30 July 2004
by Membership Liaison Officer 30 Jun '04

30 Jun '04

[Apologies for duplicate emails] Dear Colleague, We would like to remind you that the RIPE NCC Regional Meeting in Nairobi will be held 28 - 30 July 2004 at the Norfolk Hotel, Nairobi, Kenya. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. Conference attendees will include RIPE NCC members, industry partners, government representatives and regulators with particular interest in wide area IP networking. If your organisation wishes to provide a presentation or suggest a relevant topic, or if you have any questions, please send an email to: <contact(a)ripe.net> REGISTRATION To register, please see: http://www.ripe.net/cgi-bin/nairobi-reg Please note that registration closes on 19 July 2004. AGENDA The Regional Meeting draft agenda has been updated and can be found at: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/agenda.html Agenda points and discussion topics include: * AfriNIC - The emerging RIR; * Peering and Exchange Points; * Are we running out of IPv4 address space?; * An update on IPv6; * The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; * How to participate in and influence IP address management policy-making; * Domain Name management on the Internet; * Root Server Operations. 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 I trust you will find the discussions and tutorials on Internet Resource allocation and management relevant to your work. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC http://www.ripe.net

1 0