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

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

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 14 Jun '04

14 Jun '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4000::/23 from the IANA in June 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0