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

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 177

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

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by David Kessens 29 Jun '04

29 Jun '04

Laura, On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: > > 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. During the meeting, I asked you not to waste your time on this. Since the policy is already changing in the other regions, our time would be better spend to move forwards, instead of stalling the policy development process by spending time on 'clarifications'. I would like to ask the working group whether we can ask the RIPE NCC to summarize the different changes made to the policy in the other regions, so that we can have a discussion on which changes are appropriate. Thanks, David Kessens ---

7 7

Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
by Masataka Ohta 24 Jun '04

24 Jun '04

Jeff Williams wrote: > Open to some does not mean "all the way open" to others. So restrictions > for the sake of how far "Open" discussion is, is dependent sometimes on > whom is discussing what aspect of relevant issues on a topic area... So true. > That said, I liked your draft. I still must study it more however. Thank you. However, such statement without technical reasoning is no better than the emotional postings by Brian Carpenter. So, let's have discussions on technical points with verifiable reasons. Note, for example, that I oppose any proposal trying to import *THE* swamp of v4. Masataka Ohta

1 0

RE: [address-policy-wg] Re: Fallacy by Kurt
by Potapov Vladislav 24 Jun '04

24 Jun '04

>And, I happened to be a technologist who know how to build a >fast (Pbps or more) router even before no one have the needs. >So, the only problem on fast routers is their prices. >Limiting the number of global routing table entries helps a lot. Dear Masataka, It may help to optimize only ONE and not very IMPORTANT part of the router. You knew how to build fast (in mean of PPS OR MORE) routers, but didn't say about importance of the routing table. Please, give me an example of multigigabit routers without support of large routing table (or even switches, which don't have any routing table at all) which is cheaper than Cisco 2511 or so? The price of the multigigabit-per-second routers is high itself and not because of need to support routing tables. Please DO NOT turn fact. >So, you can still insist that my theory is incorrect and ATM is >8192 or more times faster than IP, while I can keep saying ATM >is about 10 times slower than IP with reasons. It seems that you have only your old theories in mind. Your previous heroic prophecies maid be right but it doesn't prove that your current prophecy is right, just because it IS prophecy without ANY facts in mind. Vladislav Potapov

1 0

IPv6 Policy - Initial Allocation Criteria in other regions
by Filiz Yilmaz 23 Jun '04

23 Jun '04

Dear Colleagues, As requested by the working group, please find below a summary of the variations in the Initial Allocation Criteria for IPv6 Policy from each of the other regions. For all regions, the following criteria apply: a) Requester must be an LIR b) Requester must not be an end site The other criteria vary. They are summarised below by region: ARIN region: Requesters must: c) plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; d) have a plan for making at least 200 /48 assignments to other organisations within two years. There is a policy proposal in last call review currently which states: - to change the timeframe above in 'd)' from "two years" to "five years" and - to have 'd)' prepended "be an existing, known ISP in the ARIN region or..." (http://www.arin.net/policy/2003_4.html) APNIC region: Requesters must: c) plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; d) have a plan for making at least 200 /48 assignments to other organisations within two years. In addition, APNIC will make allocations to closed networks if they meet all other criteria. LACNIC region: Requesters must: c) document a detailed plan for the services and IPv6 connectivity to be offered to other organisations (clients); d) announce a single block in the Internet inter-domain routing system, aggregating the total IPv6 address allocation received, within a period not longer than 12 months; e) offer IPv6 services to clients physically located within the region covered by LACNIC within a period not longer than 24 months. Regarding your comments on the RIR Comparative Policy Overview document, http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.h… I realise that it is currently out of date. This document is currently being reviewed. I expect the document to be published in July. It will include the above points along with any other policy related matters. Kind regards, -- Filiz Yilmaz RIPE NCC

1 0