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

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

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

[local-ir@ripe.net]ASO AC - Call for Nominations 2004 - RIPE NCC Service Region
by Paul Rendek 23 Jun '04

23 Jun '04

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

[ncc-co@ripe.net] ASO AC - Call for Nominations 2004 - RIPE NCC Service Region
by Paul Rendek 23 Jun '04

23 Jun '04

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

ASO AC - Call for Nominations 2004 - RIPE NCC Service Region
by Paul Rendek 22 Jun '04

22 Jun '04

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by Sascha Luck 22 Jun '04

22 Jun '04

Hi Carlos, all, On Tuesday 22 June 2004 12:16, Carlos Friacas wrote: > I cant really support the idea RIPE/NCC is a monopoly. It works in an > open and well-known fashion, cooperating with the community it > serves... > The real danger to internet governance is ICANN, and having Internet > Addressing and other stuff decisions depend on a US Government Department. I would also not much fancy if Internet governance/IP allocation policy/etc fell into the hands of the likes of the European Commission or such... rgds, Sascha Luck -- DDO Eirconnect

1 0

Fw: [GLOBAL-V6] [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" (fwd)
by Toshiyuki Hosaka 22 Jun '04

22 Jun '04

Dear all, Please allow me to forward global-ipv6 ML post by Kosuke Ito, who has not subscribed ripe-policy-wg ML. Also I would suggest you can ask original IPv6 policy intention to v6-edit team(v6-edit(a)ripe.net) that knows it very well, if you still need that. best regards, Toshi -- Toshiyuki Hosaka <hosaka(a)nic.ad.jp> IP Department, Japan Network Information Center (JPNIC) tel: +81-(0)3-5297-2311 fax: +81-(0)3-5297-2312

1 0

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by Sascha Luck 21 Jun '04

21 Jun '04

Hi Marcus, On Monday 21 June 2004 20:46, Marcus Gerdon wrote: > I had *no* trouble with the policy. > Currently (!) nobody asks for IPv6 directly, but those customers, > espicially bussiness customers, we offered routing ipv6 space to get them > accustomed to v6 were mostly quite happy with this service. And that > although they're informed it's still run in a test network (regarding our > infrastructure). We've actually been asked (with the understanding that it wasn't going to be a production rollout anytime soon. There is an actual drive towards ipv6 underway in Ireland - largely owing to heanet's efforts) > There's /16's spliit up to an endless number of /23,/24 ... Tkae a look at > Gert's email footer ... THAT's a problem. Not to say we're perfect - no > way. We ourselves have announced smaller prefixes out of space assigned to > other lir's each for many months only for customers UNWILLING to renumber > in appropriate time or to keep their old link long enough. Now this is hardly the fault of the allocation/assignment policies. If you are allocated a /16 and then announce it as /24s what can the RIR do about it? > So if you're going to deploy IPv6, just write a request. If it's serious > and understandable, I'd be surprised if a hostmaster reject it when you > count a /40 for your infrastructre or only get a sum of 180 /48. If the > plan itself is a thing to understand. The best laid plans of mice and men... As others here have pointed out, we can't yet say where the market is going with ipv6. Most plans we make today are likely to be rubbish tomorrow... > ehhmm... sorry Sascha .... not meant to be rude, just wondered ... > > A LIR without own network and ONE uplink / provider ? What services do you > provide ? Your RIPE data (as far as I found on-the-fly- look like a company > paying membership fee for their PI. Now, *that* i could consider rude ;) Where do you get the uplink from, we're not even announcing the route yet (still waiting for upstream #1 to connect their end) We're only just starting and suffered some delays. Look again towards the end of the year and things will look much different. > Before answering it: I'm not going to offend you ... but with this, you > *really* should take IPv6 from your upstream. For various reasons, this is not *really* an option. rgds, Sascha Luck -- DDO Eirconnect

1 0

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by Wilfried Woeber, UniVie/ACOnet 17 Jun '04

17 Jun '04

> We do not want to assign a /48 to all >our customers only to meet RIPE's criteria. > >We prefer using only a /32 for each of our broadband access server, and /48 >only for customers asking for it (ie : customers who have a router, several >subnets, ...). First of all, I think you got the prefix length stuff mixed up altogether (/32 for each access server?! :-) But more importantly, why do you intend to continue with the "address space scarcity" paradigm towards your customers? This sounds very much like an attempt to carry over the (broken) v4-business model for services into the v6 world, like - "you want a permanent address?" - well, this i not available in this package because the NCC forces us to do dynamic address management" or - "more than one permanent address?" - well, unfortunately this is not possible for this end-user package, you have to go for a business service which gives you 4/8/16 addresses, but unfortunately you _also_ have to subscribe to a bigger bandwith" at the same time,... >Bertrand Maujean Wilfried.

1 0

Re: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Jim Reid 16 Jun '04

16 Jun '04

Not having seen the whole discussion thread, it's a bit hard to make sense of what's been said. However it appears to be that someone is saying that the need for anycasting (and more specifically special address allocations for anycast name servers) can be discounted if ENDS0 was more widely used. This is a flawed argument IMO. As Peter has said, resolvers that aren't EDNS0-aware will still be pounding on the parent zone's name servers. [They're also much more likely to be the resolvers that are misconfigured to go to the root to reverse lookup RFC1918 addresses, don't implement negative caching and so on....] Simply adding more NS records and glue in the parent zone's delegation for a child zone is no help. For one thing, most name server implementations have a limit on the number of name servers they can handle for a delegation. Adding extra NS records is even less help when those servers have IPv6 addresses => yet bigger DNS payloads. In fact adding extra servers and/or IPv6 addresses may be worse because there's an increased likelihood of truncated responses getting sent to these non-EDNS0 resolvers, resulting in retried queries over TCP. Nasty. Aside from these DNS protocol issues, there are plenty of other good reasons for deploying anycasting for important DNS infrastructure. That's why lots of the root and TLD name server operators are doing this already. Ironically, these include the NCC's root name server. Anycasting provides increased robustness, extra redundancy, improved performance, better scalability, extra capacity/throughput, defence in depth from DDoS attacks, etc, etc. Anycasting isn't going to go away even if all the world's DNS software implemented EDNS0. Anycasting is a fact of life. And it will become more prominent in future. So if the address policy WG is reluctant to endorse special address allocations for DNS anycasting, I'd ask them to reconsider. If it helps, we could ask the DNS WG to discuss the issue and perhaps make a recommendation to the address policy WG.

2 1

Policy Change Request - Allow address allocations for anycast DNS operation
by Andreas Bäß/Denic 16 Jun '04

16 Jun '04

In the background I had some discussions with several people what is the best wording for the policy to reflect the discussions that we had on RIPE 47. I think the outcome of these discussions reflect pretty well what I can recall. So I would like to ask the workinggroup what you think. "Operators providing DNS for a zone that is approaching the UDP packet size limit due to the number of authoritative servers may be assigned PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These prefixes will allow them to anycast the DNS server, as described in RFC 3258." Have a nice day Andreas Baess -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess(a)denic.de

10 28

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

Hi Gert! >> 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. This, together with the fact that (if I remeber correctly!) there is no longer a minimum usage restriction for becoming an LIR should help to solve this problem?! Wilfried.

2 1

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

>> There has been some confusion on whether this is "PI". It is not, it's >> "anycast space", and should be tagged as such in the database, to help >> people recognizing these special blocks immediately as such. The usual >> rules apply: "if the criteria for allocations do no longer apply, the >> address block should be returned" (even if that is unlikely to happen >> very often in practice). >> > >Don;t know if there is a real need to tag things like this in the DB, >but I am not going to argue either way. If there is a "real" difference as compared to PI (which I'm still not convinced :-), _and_ a "special" provision for reclaiming those addresses, then I think the answer should be YES. Wilfried.

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

Hi Pekka! The next paragraph is where I strongly start to disagree: > (2) this proposal takes no stance on who can request a block of >addresses like this for his DNS servers? Correct, and this is the way it should be! If someone wants to start deploying a particular _technology_ for her service, then there should be NO discussion about size, "importance", level in a hierarchy and similar things. > People could add up servers >and addresses for them just for the purposes of getting nice PI >prefix(es) for their DNS servers. Just like they can buy/rent cheap end systems today to be configured on a particular network to get IPv4 addresses ;-) > Wouldn't it be nice, never having >to renumber your DNS server addresses in different registries etc. Sure :-) And? >This is short-sighted. We should restrict this approach to specific >class of DNS servers, like ccTLDs or the like -- if that's the class >of DNS servers where we'd intend do something like this. This would get us (i.e. the NCC) into deep trouble: without intending to pick at a particular Zone - just to make a point - why would eg. VT. or MD. be eligible, but AC.UK. (or AC.AT. for that matter) or google.com or 3.4.E164.ARPA. would not?! >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings We just made this mistake too often already (looking at a particular application, at a particular transmission technology[1], and the like, and hard-wiring that into resource distribution policy). The only aspect that I would accept here is characteristics or rather limitations of the DNS _technology_ and _protocols_ (and maybe others), but NOT what type of service it is used for! Wilfried. [1] like 24/8 and DSL being treated as "dial-up" when in reality (for a certain period in time) the _business model_ would have been interesting to look at, and not the technology or application...

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

>==> While discussing this issue, IPv6 Policy (especially "Initial > allocation criteria" section ) is being clarified (see current > discussion on global-v6(a)lists.apnic.net). Even though, it is said > that the intention of this discussion is to clarify the IPv6 > Policy and not to change it, does it make sense to consider adding > explicitely the criterion above ("DNS ANYCASTING") as a new > criterion to qualifiy for a /32 ? > >Regards, > >Mohsen. I don't think that mixing this would be a good idea, for the following reasons: - I expect the IPv6-clarification exercise to take "quite a while" to converge (across the 4+ RIR constituencies) and I get the feeling that the DNS operators would really like to see a decision reasonably soon now :-) - it is not obvious to me that this special "rucksack"-provision has to go into a globally coordinated text - and for the formal reason that the mandate right now is to provide clarifications or improved wording for the existing v6 policiy. If and when during that exercise it turnes out that we should actually start revising the v6 policy (which would not surprise me :-), then we can reconsider... Wilfried.

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 14 Jun '04

14 Jun '04

>And with regards, to Wilfried's question about whether this policy >proposal should require the requester to be an LIR, the reply is "why >should it?". To be more precise: not "to be an LIR" but to submit by way of an LIR" - much like the distribution of AS numbers. > Unlike Daniel, I have trouble seeing bureaucracy as a beautiful >clockwork mechanism. This is not to feed any bloated organisational overhead (no implication that there is one in this case!), but rather to avoid digging administrative bypass tunnels :-) >Cheers, >Joao Wilfried.

4 3