June 2004 - address-policy-wg

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