On Fri, 14 Oct 2005, Mohacsi Janos wrote:

Dear All, I did not see any answers except one from Bill Manning - who was supporting the 4. options.

FWIW, I do not see a problem with option 3 -- the .hu servers would not need to get addresses from each an every ISP, two or three of them should be enough. I would be opposed to option 4.

So this means this is the accepted and RIPE reccomended method. Basically allow allocating portable IPv6 address: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers;

When the RIPE policy will reflect this changes?

Thanks Regards,

Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98

On Mon, 10 Oct 2005, Mohacsi Janos wrote:

...

Dear All, I have a question regarding the IPv6 address assignment to cc level DNS server.

If you don't have answer to this question please forward it to an appropriate working group - sorry for cross-posting this mail to two wg.

We have here in Hungary a dilemma:

- Traditionally, the IPv4 address of the primary cc level DNS server in of belonged to NIIF/HUNGARNET.

- The DNS registration service a while ago was delegated to Council of Hungarian Internet Providers (ISZT) who is also operating the biggest Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including NIIF/HUNGARNET) has right to do the registration via a special interface.

- The IPv4 address of the primary cc level DNS server announced by NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate address from a new PI type IPv4 address space to DNS servers.

- The primary hu DNS server is connected to BIX - to be well connected.

What IPv6 address space should we allocate to hu primary DNS server?

1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? - not very optimal since the only transit to hu primary will be NIIF/HUNGARNET - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET

2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and ripe-310)? - According to the RIPE documents: "Networks assigned under this policy may not be globally routable" - which problematical since primary DNS servers should be globally reachable.

3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS server? - This can be problematical since the answers to DNS queries might be quite big.

4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region?

- I think this is the cleanest solution.

Can we discuss this issue on the working group or mailing lists?

I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html

In my opinion this can solve the problem....

Best Regards,

Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98

-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Tue, 1 Nov 2005, Andreas Bäß/Denic wrote:

...

...

...

4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region?

- I think this is the cleanest solution.

Can we discuss this issue on the working group or mailing lists?

I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html

In my opinion this can solve the problem....

I have not seen any discussions that think it is a bad idea to assign several network resources to TLD administrators which will enable them to operate their nameservers according to RFC3258.

When we have reviewed the discussions we felt that your objection against the proposal was because of the size of the assignment. I'm planning to submit revised proposal with a reduced prefix length which better fits with other assignment policies. If you are opposing to the new proposal I would be glad to know as soon as it is submitted.

Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough; 2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended; 3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically. In addition, a) we have enough address space that allocating a (v6) /32 is not waste. b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a). So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Hi, I would like to comment on this topic. --- From: Andreas Bäß/Denic Date: Mon, 4 Apr 2005 18:18:22 +0200

1. Is there a need for anycasting at all ?

I was surprised to see this question on the list. I think that anycasted nameservers are an accepted standard and there is no need to discuss pros and cons anymore.

If anycasting involves creating special prefix allocation policies, then I am 100% against anycast. We are currently running anycast on our own nameservers, but we don't require our own v4 or v6 prefix just for that. I don't see why you can't do the same with your already 11 nameservers (on 11 networks?), but maybe that's just me. Furthermore, nameservers should not be specially treated. It is impossible to define what is important and what is not (like defining what spam is). The only anycast service at all I would be willing to exempt is root nameservers and give them their own prefix if needed. Nothing, and by nothing I mean any service (dns, web, mail etc), is justified for their own anycast prefix unless you can implement it with standard allocation policies. Microallocations might be a standard allocation policy. What I don't want to see is that RIRs hand out microallocations for the sole purpose of running anycast. Then I would probably be asking for at least 50 microallocations just for myself, oh pretty please. I am therefore against any proposal about anycast prefix allocations no matter whom and what it concerns. Do whatever you want between your peers if your agreement permits; just don’t put the prefix in the dfz. I don't think it belongs there. Thank you, Joergen Hovland -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Andreas Bäß/Denic Dear Pekka,

Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough;

I agree that if a DNS operator is below a certain limit of DNS servers he does not have the need for anycast at all. But once you grow your farm beyond a limit anycast is the current best solution. DENIC for example had 11 different NS before we have started to deploy anycast to further enhance network diversity and capacity and simultaniously introducing AAAA records for our nameservers.

2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended;

In my first presentation I have voted for a more open policy. However I have seen no acceptance to this approach as the process of defining a network critical resource would take too long while I felt consensus that TLD nameservers are critical enough to justify special treatment. So I wrote a policy proposal that is only applicable for TLD nameservers. Why do you think this is open ended?

3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically.

I have not limited my proposal to ccTLDs but includes any TLD.

In addition, a) we have enough address space that allocating a (v6) /32 is not waste.

If you have seen the updated version of my proposal I hope you will not see any problem iwth a /48 prefix.

b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a).

I don't see why you think that it is a bad idea to do the assignments for anycasted nameservers from a bigger block. Can you explain what makes the difference from spreading them all over the address range. Sounds like a security through obscurity approach to me. I haven't made a suggestion on how RIPE should manage their microallocation assignments. From my personal experience I would be an favour of a microallocation block as this bundles the efforts to eliminate routing problems that might exist.

So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it.

As said before, it is a superset of 3. with /48 V6 prefixes. Maybe it's best to take a quick look at the current proposal. Regards Andreas Baess

I am therefore against any proposal about anycast prefix allocations no matter whom and what it concerns. Do whatever you want between your peers if your agreement permits; just don?t put the prefix in the dfz. I don't think it belongs there.

I think that some anycast prefixes *DO* belong in the dfz. However, I think that it is wrong to give out anycast prefix allocations to organizations whose only intent is to run their own internal services. The .de TLD is proposing that they should get a prefix just for their own anycast services. Instead, I think that RIPE and other RIRs should give out a small number of prefix allocations to "network operators" who intend to run anycast network services for their customers. Does anyone see the parallel with Internet access network operators who run networks to provide Internet access to their customers? In theory, an anycast operator will sell anycast services to other organizations. Those organizations will place their servers in facilities where the anycast operator has some kind of presence, i.e. a router and a rack. The organizations such as DENIC, will receive a *SUBSET* of the anycast prefix for their servers but that subset will not be visible outside of the anycast operator's network. If customers, such as DENIC, do not feel that a single anycast network operator can supply the coverage that they require then they can buy services from more than one anycast network operator. It is interesting to note that domain hosting uses the DNS protocol which allows for a server to have up to 13 unique IP addresses. Theoretically a domain hosting company like DENIC could use the services of 13 different anycast operators. If a company like DENIC was willing to sign an undertaking with RIPE that they would offer the use of their own anycast architecture commercially to other organizations, then DENIC should also be able to qualify for an anycast prefix allocation. --Michael Dillon

Hi, On Fri, Nov 11, 2005 at 05:20:44PM +0100, Jørgen Hovland wrote:

Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers around the world at their collocation facilities. MCI may then assign DENIC one /64 prefix from their /32 prefix which will be routed to the closest DENIC server in MCIs network. Would this be a suitable solution? This /32 has not been given to MCI by the RIR explicit for anycast purposes.

I'm not sure whether you understand what this is all about. DENIC is providing a public service (namely: DNS for the .de TLD) - and *the whole world* wants to reach their DNS servers. (No different to .com and other large TLDs) Due to the fact that DNS has packet size limits (the DNS WG says so, and it's not the address policy WG's job to know DNS better than the DNS WG), anycast is a necessary workaround if a DNS operator wants to increase reliability and reachability for their DNS servers - after they have exhausted all other options (like "using very short server names" and so on). So where's the benefit if DENIC sets up something inside MCI's network that only MCI customers can see? And *if* the route is leaked outside, what is gained, except people will have to maintain explicit white-lists ("hey, this /64 is DENIC-anycast, so we permit it, while not permitting other /64s")? I don't really understand what you are worrying about, and why, and how this "solution" is going to help anyone. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi, On Fri, Nov 11, 2005 at 08:53:04AM -1000, Randy Bush wrote:

...

DENIC is providing a public service (namely: DNS for the .de TLD) - and *the whole world* wants to reach their DNS servers. (No different to .com and other large TLDs)

or anywhere else in the dns tree, tends of thousands of servers

Yes. I think we can agree that there are lots of domain service providers that have 2, 3, maybe 5 name servers in their NS set (and those can grow without anycasting), and that there are some that really use up all that you can fit in those small packets, and want to provide even *more* resiliency. Looking at DNS, I see "lots of nameservers" primarily for root, and some gTLD/ccTLD zones. Haven't seen that for "further down" stuff (.co.uk is "sort of ccTLD" stuff). And really - I don't care who they are and what they do, but if they think it's a good thing to have more than 11 different primary name servers for whatever they are hosting, it must be important to them, and at leat to whoever is providing the funding.

but i am sure denic is very important

The second largest DNS zone in the world *does* sound somewhat important to me. I don't have query numbers to compare .com and .de requests/second (which would be more useful than sheer zone size), but I'd assume that there are also plenty of request for .de domains. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi, On Fri, Nov 11, 2005 at 11:44:40PM +0100, Jørgen Hovland wrote:

...

Yes. I think we can agree that there are lots of domain service providers that have 2, 3, maybe 5 name servers in their NS set (and those can grow without anycasting), and that there are some that really use up all that you can fit in those small packets, and want to provide even *more* resiliency. Looking at DNS, I see "lots of nameservers" primarily for root, and some gTLD/ccTLD zones. Haven't seen that for "further down" stuff (.co.uk is "sort of ccTLD" stuff).

Gert, you can configure 1000 anycast servers, all with the same IP address, in your own network no matter how small/large your network is.

That's the point. DENIC isn't doing this for themselves. They do this for *you* (and for me, and even for Randy). So putting up the anycast servers somewhere where half of the internet might not see them is not useful. For maximum resiliency (against DoS and outages), one wants to spread the anycast servers over as many different (!) networks as possible. And this cannot be done without a dedicated prefix for it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi, On Fri, Nov 11, 2005 at 09:52:53PM -1000, Randy Bush wrote:

...

That's the point. DENIC isn't doing this for themselves. They do this for *you*

in a peer2peer or client/server world, this statement is fatuous

So we abandon DNS, because it's a model from the last century? (Now that would be a policy proposal for the DNS WG, not for address policy -- but I'm all for it, this whole hassle with "finding a free domain name" and "going to court with name right holders" and so on is really annoying) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

That's the point. DENIC isn't doing this for themselves. They do this for *you* (and for me, and even for Randy).

The Red Cross Society is also doing it for *you* and for me and even for Randy. But that doesn't make their network special. If DENIC really wants to build a special network then they should share that special network with other TLD operators. Then I would be happy to support their requests for IP addresses. But if they are not going to share their network then there is nothing special and they must buy service on the open market. I really do want DENIC to build their anycast network. But I want them to share it so that all the other important TLDs don't have to build their own separate networks all doing the same thing as DENIC. In fact, now that DENIC is selling resilient domain name hosting around the world, I would be interested in having them host my second level domains as well.

So putting up the anycast servers somewhere where half of the internet might not see them is not useful. For maximum resiliency (against DoS and outages), one wants to spread the anycast servers over as many different (!) networks as possible. And this cannot be done without a dedicated prefix for it.

I agree with you Gert but this is such a good idea that every TLD will want to do the same. You need to either outsource this to a company that specializes in anycast hosting or you need to separate DENIC into a hosting network business and the .DE name registry business. --Michael Dillon

Jørgen Hovland wrote:

The next problem is that you want better redundancy(?). Then buy more connectivity. If you for some reason can't afford better connectivity, please look at my MCI example and put your servers elsewhere.

What if I want to plan for more disasters than that ? Like MCI going out of business? I guess I could agree with MCI to place some servers with their IP addresses outside their network and agree with other providers to carry my more specific routes. In order to have universal access and plan for any network failure I would have to sign such agreement with all ISPs. This could be a business idea for somebody: to set up an "anycast registry" - sign agreement with all the major ISPs to not aggregate my addresses. Then I could offer a guaranteed minimum routability for thoose prefixes. What we are discussing is really to make this mechanism available by addressing policy. Traditionally the RIRs does not set routing policy. Hans Petter

On 13 nov 2005, at 15.20, Jørgen Hovland wrote:

Take the following:

1 server at ISP x in London. /32 announced by ISP x's ASN. Your ip is assigned from this /32. 1 server at ISP x in Amsterdam. /32 announced by ISP x's ASN. Your ip is assigned from this /32.

and

1 server at ISP g in London. /32 announced by your ASN through ISP g. It is your /32 1 server at ISP k in Amsterdam. /32 announced by your ASN through ISP k. It is your /32

What is really the difference here? Yes, ISP x, g or k can go bankrupt so you loose that redundancy in the first scenario. Any others? I can't think of any. Either way, there is no difference here network wise? You get exactly the same reachability/redundancy. So, should we alter the address policy because ISP x can go bankrupt and we need redundancy for that? You still have 10 more ISPs you have placed your servers at if you use all 11 IPs.

In the first scenario you are forced to the routing policies of ISP x and only to the locations of ISP x. In the second example you can co- locate, connect to and IXP and do your own routing decisions as well as be present at locations you choose (without "vasting" or even having to go to 11 servers). - kurtis -

On 13 nov 2005, at 16.47, Jørgen Hovland wrote:

From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] Sent: 13. november 2005 15:32

...

In the first scenario you are forced to the routing policies of ISP x and only to the locations of ISP x. In the second example you can co- locate, connect to and IXP and do your own routing decisions as well as be present at locations you choose (without "vasting" or even having to go to 11 servers).

You will always be forced to obey the rules of whatever provider you are using, ISP or IXP. I get the impression that you believe ISP x's routing policies will always be insufficient for you. Nameservers are not the only anycast service so it would be tricky to discuss this in general. But you want your nameserver to be reachable, that I know. Both scenarios will accomplish that with the same amount of redundancy. What kind of routing policies do you mean? Do you want to restrict your reachability?

If you are connected to the IXP with your own peerings, you will have control of the routing policies. If you host with ISP x, you will have to follow ISP x peerings and depeerings. You claimed the two cases to be equal. I just pointed out that they are not. - kurtis -

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Wilfried Woeber, UniVie/ACOnet Hi Wilfried,

From that perspective I seem to see 2 aspects in the recent discussion:

- you shall not receive address space for builing a service, you are to buy that from some "big-folk".

This is an intersting point of view, and taken to the extreme will make us end up with a _very small_ number of _very big_ entities.

Traditionally these things were called monopolies. Nothing I would be too happy to see coming back ;-)

- there has been th discussion regarding "anycast" but isnt this just a special(?) case of th PI-topic?

You are right; the differences between PI and anycast are few. Perhaps it would be a (good?) idea to merge the anycast and PI discussion into a single discussion instead.

This is an intersting point of view, and taken to the extreme will make us end up with a _very small_ number of _very big_ entities.

Strictly speaking; All you need to do is to create a network and ask for address space. The "anycasters" won't even do that. They want the address space without the network. That is what I don't support. Joergen Hovland

-----Original Message----- From: Elmar K. Bins [mailto:elmi@4ever.de]

Hello Jørgen,

Hello

...

Will it not satisfy your needs placing 200 servers at 100 (numbers randomly selected) MCI locations world wide using IP space assigned by MCIs /32?

Certainly not - why should one be satisfied with such a pseudo-solution?

Because that’s what everybody else are doing? That’s why we currently have 600 routes in dfz and not one per server on the internet? Should DNS be excused only because the protocol itself supports a finite amount of IP addresses?

A service provider (we _are_ talking about Internet infrastructure service providers currently, keep that in mind) that has come to the conclusion they want to "anycast" (aka shared unicast) their services, surely has thought about going to a big ISP before and decided that that' not what they want.

Ok, but I would still like to hear from people who have tried that but had to reject the solution for valid reasons where the ISP offered you this service. Anyone?

...

Either way, there is no difference here network wise? You get exactly the same reachability/redundancy.

Only if you limit your thoughts to a very small world. Sorry, but the fallacy of your argument is so obvious that the words fail me here.

...

I am against a policy that would let LIRs receive prefixes from RIRs when the intention is to use the prefix for anycast. I have hopefully shown

Could you be more specific? I am sure there are ISPs that are not willing to sell anycast services, but if you have buyers then the sellers will always show up eventually. that

...

you don't need a dedicated prefix for that.

No. You have shown that _you_ don't need that.

Obviously some people have different needs. It is good that we try to figure those out.

You try to decide here how other people run their services.

No, I am trying to prevent excessive defragmentation of the routing table. I am trying to prevent a special case of PI where you are not even required to have your own network. The requirement to this special PI case is so low that anyone would be able to apply for it - and anyone _will_ apply for it. In order to prevent that we only permit DNS? Are there any other services that should be permitted?

I honestly believe that's none of your business, but up to the respective service provider. You can give them good advice, of course. But you must be open to accepting arguments for the way they intend to do it.

So far we have two reasons why anycast prefixes, "anycast PI", should be permitted: * Bankruptcy * Routing policies

...

Nameservers are not the only anycast service so it would be tricky to discuss this in general.

DNS is a special service (UDP packet size stuff) and needs a special solution - unfortunately.

I disagree. DNS is certainly not a special service. The importance of it is however perhaps greater than many others - many, but far from all. The packet size thing is a general design problem. As far as I know, there are currently two methods to solve it: * EDNS0 * TC flag If you are going to use the packet size problem as an argument to use anycast, then I think it would be a good idea to hear reasons why none of these solutions would be suitable (also because I don't really know it myself) and perhaps if there are any other solutions that would help solving the problem?

...

From that perspective I seem to see 2 aspects in the recent discussion:

- you shall not receive address space for builing a service, you are to buy that from some "big-folk".

This is an intersting point of view, and taken to the extreme will make us end up with a _very small_ number of _very big_ entities.

Traditionally these things were called monopolies. Nothing I would be too happy to see coming back ;-)

You did not comment on this part. Why?

I was probably just a bit unclear. "All you need to do is to create a network and ask for address space.." There is no monopoly threat as long as you follow the requirements. If the requirements are too strict, then it would become a problem. Currently, I think they are not. Joergen Hovland

-----Original Message----- From: Elmar K. Bins [mailto:elmi@4ever.de]

But you're trying to lure us away from the proposal we're discussing which states a special case of DNS for _ccTLDs...

The requirements for v6 space in the RIPE region includes having transit customers (at all, the 200 is just an arbitrary number). No ccTLD registry that's not also conducting other business may receive an allocation. That's the entire point of the special case being made. ccTLDs cannot deliver services in v6 like in v4. This - IMHO - is a v6 showstopper.

So we are back at the beginning; I say no to anycast PI for TLDs/ccTLDs. I don't believe it is a special case so it doesn't need a special policy. TLDs/ccTLDs could/should however be used as an argument to allow v6 PI prefixes in general. V6 PI compared to v4 surely is a showstopper for many, or at least for some. Cheers, Joergen Hovland

Hi, On Mon, Nov 14, 2005 at 10:51:58AM +0100, Jørgen Hovland wrote:

...

You try to decide here how other people run their services.

No, I am trying to prevent excessive defragmentation of the routing table. I am trying to prevent a special case of PI where you are not even required to have your own network. The requirement to this special PI case is so low that anyone would be able to apply for it - and anyone _will_ apply for it. In order to prevent that we only permit DNS? Are there any other services that should be permitted?

This is the type of argument that I love most - "if we permit this to you, everybody will want it, too!!!". I read into this that you are afraid that the initial criteria are not strict enough. As far as I can see, the criteria are pretty explicit, and verificable. [..]

...

DNS is a special service (UDP packet size stuff) and needs a special solution - unfortunately.

I disagree. DNS is certainly not a special service. The importance of it is however perhaps greater than many others - many, but far from all. The packet size thing is a general design problem. As far as I know, there are currently two methods to solve it:

* EDNS0 * TC flag

If you are going to use the packet size problem as an argument to use anycast, then I think it would be a good idea to hear reasons why none of these solutions would be suitable (also because I don't really know it myself) and perhaps if there are any other solutions that would help solving the problem?

Please. We have been through this part of the discussion half a year ago, and we've asked those that know (the DNS WG) and they tell us "we can't rely on EDNS0, and truncation is bad". It would be very helpful if you could do us the favour and read up on old arguments in the archives. To repeat myself: it's not the AP WG's job to tell the DNS WG how DNS works. We're making policy, (partly) based on the expertise of other working groups. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi, On Mon, Nov 14, 2005 at 11:31:44PM +0100, Havard Eidnes wrote:

...

Please. We have been through this part of the discussion half a year ago, and we've asked those that know (the DNS WG) and they tell us "we can't rely on EDNS0, and truncation is bad". It would be very helpful if you could do us the favour and read up on old arguments in the archives.

Really? I always got the sense of earlier comments (not here, though -- I seem to recall this from IETF circles) saying that if you're running so newfangled software that you speak IPv6 you would be expected to also implement EDNS0.

I don't see the connection. The set of NS records returned by the root name servers for ".de" needs to be small enough so that the results fit into a non-EDNS0-UDP response packets, no matter whether the client can do IPv6 or not - even very old clients should get a complete answer. OTOH, I am way out of my technical league here - I refer to the DNS WG, and they said "don't do this". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hello,

So far we have two reasons why anycast prefixes, "anycast PI", should be permitted: * Bankruptcy * Routing policies

For ccTLDs, there's a third: Autonomy from ICANN decisions to change IP addresses of DNS servers in the root zone if some IP is no longer servicable. That's a national security issue for some countries. -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372

Florian & all, On 16 Nov, Florian Weimer wrote: [...] | It depends on the PI criteria. If slots in the global routing tables | are kept in short supply *and* you get at most one if you aren't an | ISP *and* you need to do IPv6 anycast, you might have a problem | because you need two globally visible prefixes (one for your | production network, one for anycast). | | But I think you are right that it makes sense to resolve the PI first, | either negatively or positively. ==> This is just amazing! I have been follwing this topic for more than two years and I have the feeling that we are making again and again the history! I remember that when the IPv6 "PI" issue was first raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that time), the answer was "PI is out of scope of this wg". Then came the first draft proposel of Andreas in the AP wg asking for a /32 for ccTLDs wishing to deploy anycast. At that time, the wg said "let's not talk about "PI", which is still out of scope of this wg. Let's rather talk about specific needs of TLDs wishing to do anycast and see what we can do for them in termes of (micro-)allocation." Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem... If that's to be done and while we ar at it, we can see again how RIPE is the only RIR not considering TLD networks as "critical infrastructure" while an appropriate policy has been already implemented in all other existing RIRs for a long while (please revisit the comparative matrix of RIR policies at http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and see how RIPE is lagging behind in this matter. Some of this mailing-list member would say: "that was our choice!"). Isn't it a European speciality to discuss over again and again issues without coming to any solution? Some people on RIPE mailing-lists are now used to coming after a consensus is almost reached and try to break everything just for the sake of building CLEAN solutions... (cc)TLD need an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop. To recall only a few of the arguments for deploying anycast for a TLD, I would say: Redundance & Resilience against DDoS attacks, better global time response, a greater flexibility in adding and removing name servers without notifying IANA! Btw, I'd like to remind some of this mailing-list readers that the request of DENIC is not isolated since AFNIC asked even before Adndreas first draft for a constency between all RIRs in the way IPv6 allocation were made for "critical infrastructure". AFNIC has then strongly supported Andreas proposal from the beginning and hoped that the solution would come rapidly because AFNIC is still needing such a solution to start deploying anycast in IPv4 AND in IPv6 in a consistent way! I still hope this debate will lead to a concrete solution within the coming 3 years! Good luck :-) Mohsen.

Mohsen Souissi wrote: <SNIP>

Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem...

<SNIP>

(cc)TLD need an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop.

"example.net DNS servers needs an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop." What makes .de more important then example.net DNS servers? I am quite sure that a large part of the world can live perfectly without complete *.de (especially older french people :) but would hate it when google.com (they have already a /32) or ebay.com or say cnn.com (the latter who don't have an allocation yet), are not reachable. These kind of sites also require what you want with 'anycast', a server as close as possible to the enduser for resiliency, latency, DDoS etc... For that matter .com/.net/.org don't have it (yet) either. My points for this, which are mostly also reflected in the proposal: - Special policy only for accredited ccTLD's - Give them a /32 (bigger is only filtering nightmare already) (in another message) Michael Dillon wrote:

If AFNIC and DENIC form a consortium to operate anycast deployments for TLD operators, then that is a different question entirely. I think it would be right for RIPE to allocate addresses to such a consortium just like we now do with other network operators.

You mean clustering up all ccTLD's into 1 prefix? Then why not have a single /32 with a caching recursive DNS server which answers to all queries, see section 4 of: http://unfix.org/~jeroen/archive/drafts/draft-massar-dnsop-service-00.txt But proposing that gets one into 4 holy wars I understood, especially the 'anycast' part seems to be very hurting to a number of people... Note also that clustering them together causes loss of diversity. Thus a /32 per ccTLD seems appropriate here. <SNIP>

I still hope this debate will lead to a concrete solution within the coming 3 years!

Only 3? :) If you really want to get over all of this use the current policy: just define DENIC and anything else as being an LIR (just pay some cash), providing end connectivity to 200+ *planned* sites. Those 200 sites consist out of: - 13 /48's for the anycasted PoPs - 1 /48 for the main office - X /48's for branch offices. - 100+ VPN connections to endsites (for management, employee 'dailin' etc). Done. Please read through: http://www.sixxs.net/tools/grh/dfp/all/ and see what kind of organisations have already got an allocation. Then go over to your favourite colo facility and see what equipment they have. I am quite sure that quite many don't have a lot of equipment (or customers). But they have planned it... and back to everybodies normal schedule.... Greets, Jeroen

Hi, On Thu, Nov 17, 2005 at 11:50:32AM +0100, Mohsen Souissi wrote:

==> This is just amazing! I have been follwing this topic for more than two years and I have the feeling that we are making again and again the history! I remember that when the IPv6 "PI" issue was first raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that time), the answer was "PI is out of scope of this wg".

I'm not sure which WG you are talking about (IPv6 WG or LIR WG?), but it's certainly in scope for the address policy WG. The topic of PI space for IPv6 just has been avoided like the plague so far - nobody seems to be able to define proper criteria for IPv6 PI, and I'm fairly sure we will not be able to reach consensus for IPv4-style PI ("come and ask for it, and that's all you need to do"). Personally, I've seen some doomsayers so far ("IPv6 will die if we have no PI!"), but I can't remember having seen a proposal for rules that let "those that we all agree should have it" have PI, and "those that we all agree should not have it" not have it. Which reflects on the problem - there are many readers here that have good arguments against any sort of PI (that is not needed for DNS purposes, due to protocol constraints [brokenness]), and others see any possible alternative as "this is just not going to work" (read "I'm politically opposing this, and because it isn't PI, it is not acceptable")... so getting consensus will be tough.

Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem...

"We" aren't. These are just some comments by some of the participants. But of course "we" will, if someone formulates a specific policy proposal how to make PI work.

If that's to be done and while we ar at it, we can see again how RIPE is the only RIR not considering TLD networks as "critical infrastructure" while an appropriate policy has been already implemented in all other existing RIRs for a long while (please revisit the comparative matrix of RIR policies at http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and see how RIPE is lagging behind in this matter. Some of this mailing-list member would say: "that was our choice!"). Isn't it a European speciality to discuss over again and again issues without coming to any solution?

It certainly is an European speciality to bring up the same discussion again and again without any new facts that might affect the outcome. DNS is special, in that the protocol is fairly broken, but too widespread to re-do over night. This warrants special cases for the root, and maybe special cases for *anycast* - but nobody is asking for special cases for normal unicast DNS servers. That's what glue records are for, and they work fairly well. DNS is critical infrastructure, but nobody has explained properly yet why "critical infrastructure" (in itself) requires a different way to get IP addresses. Even so, Google is likely more critical to more people than some of the ccTLDs out there... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Elmar K. Bins wrote:

How about: Every ASN is entitled to an IPv6 block. Full stop. Then you can tie it to independency of routing and to the rules for ASNs.

Anyone else think along these lines? Elmi.

Hear! Hear! I think even the routing-table purists will agree that 64K routes maximum size will be fine. I'm for this approach. -- Best regards, Cameron Gray Director Netegral Limited Registry: uk.netegral

Hi, On Sun, Nov 20, 2005 at 11:23:25AM +0000, Cameron C. Gray wrote:

I think even the routing-table purists will agree that 64K routes maximum size will be fine.

AS numbers are not really limited to 16 bits... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

as long as it's "something new", let's get a fresh subject line... :-) On Sun, 20 Nov 2005, Elmar K. Bins wrote:

Just to get the thing rolling again with something new :-)

gert@space.net (Gert Doering) wrote:

...

Personally, I've seen some doomsayers so far ("IPv6 will die if we have no PI!"), but I can't remember having seen a proposal for rules that let "those that we all agree should have it" have PI, and "those that we all agree should not have it" not have it.

How about: Every ASN is entitled to an IPv6 block. Full stop. Then you can tie it to independency of routing and to the rules for ASNs.

Anyone else think along these lines? Elmi.

this was the original ARIN proposal 2005-1, which could not reach consensus. The last time around it was re-worked to add more restrictions and again failed because other folks felt it was too restrictive. There are actually two issues: 1) the high cost of renumbering in a large organization 2) multi-homing for network reliability and resiliency the problem with using ASNs is that when you think over the projected lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN draft is entering the standards track in IETF. Don't think that tying PI to ASNs is anything more that passing the problem to the next generation (if that long... :-) It would seem obvious that as network connectivity becomes essential for doing business, it must be reliable. It is unwise to carry forward the IPv4 multi-homing model for network resilience with just faith that the system will be able to scale to an ever larger number of routes. IPv6 has so far failed to deliver on its original promise of seamless renumbering and multi-homing using multiple prefixes. The hard problems still need to be solved in a way that can scale for decades to come. regards, /Lea

On 21 Nov 2005 16:27:02, Elmar K. Bins wrote:

lea.roberts@stanford.edu (Lea Roberts) wrote:

...

this was the original ARIN proposal 2005-1, which could not reach consensus. The last time around it was re-worked to add more restrictions and again failed because other folks felt it was too restrictive. There are actually two issues:

1) the high cost of renumbering in a large organization

Why should they renumber, if it's their own block?

As in, PI ?

...

2) multi-homing for network reliability and resiliency

Where's the problem here? Someone who can afford and establish a case for _real_ multihoming can get an ASN and thus an assignment.

No. Unless you relax the rules for ASN and then *oh gosh* you have a ASN size problem.

Like was already said - loosening the ASN handout rules needs changes in assignment rules, too. But that's for years to come.

No. Adress space and routing policy are diferent entities. That's why LIRs don't automagically get an ASN.

Yours, Elmi.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>)

--------------------------------------------------------------[ ELMI-RIPE ]---

-- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A

Florian, Florian Weimer wrote:

If DNS operators really cared about the availability of their data, they would allow the general public to mirror it. However, some of them seem to think that such a precaution against disaster would negatively impact their current business model.

of course, I can't speak for every DNS operator, but DENIC denying the transfer of the .de zone has no other reason than data protection, ie. making the harvesting of contact data of some 9 million plus domain name holders by just piping the zone through the whois impossible. Best regards, Carsten

Florian, Florian Weimer wrote:

...

of course, I can't speak for every DNS operator, but DENIC denying the transfer of the .de zone has no other reason than data protection, ie. making the harvesting of contact data of some 9 million plus domain name holders by just piping the zone through the whois impossible.

Your claim is absurd. The real privacy issue comes form forced publication of WHOIS data. As a member of the DENIC executive board, you certainly know that, so please stop spreading such misinformation.

it's interesting that you appear to know what I "certainly" know... What I indeed know is that DENIC's whois policy is well balanced between the interests of the individual domain name holder and the general public: bulk access to whois data is not possible, but only on a per-domain-name basis - ie. you need to have the domain name at hand to get the appropriate whois data. And besides that there is no other means (aka. 'key' - eg. last name, city of residence etc.) to access that data. This policy, BTW, is in full accordance with the relevant data protection bodies. But may I suggest that we have that discussion off this list - as RIPE's address policy and IPv6 WGs are IMHO the wrong fora to discuss DENIC's whois policy - and moved to a place of your choice? Best, Carsten

...

...

Your claim is absurd. The real privacy issue comes form forced publication of WHOIS data. As a member of the DENIC executive board, you certainly know that, so please stop spreading such misinformation.

it's interesting that you appear to know what I "certainly" know...

Don't tell me you haven't been briefed on such issues. 8-/

Be assured, I consider myself very well up to speed with regard to DENIC's business. I was actually referring to my alleged knowledge of the absurdity of my "claim" and the existence of "privacy issues".

Anyway, I have moved the discussion to a more appropriate list.

Seen that; EOD here then. Regards, Carsten

-----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: 11. november 2005 19:02

So where's the benefit if DENIC sets up something inside MCI's network that only MCI customers can see? And *if* the route is leaked outside, what is gained, except people will have to maintain explicit white-lists ("hey, this /64 is DENIC-anycast, so we permit it, while not permitting other /64s")?

I will try to explain more detailed: A large network provider can have hundreds/thousands of peers. These peers receive the same /32 prefix. A large network provider has housing facilities many places in many countries. * Put your server in some or all of these housing facilities. * Give every server the same IP address. * Tell large network provider to use the closest path and make a route to this IP address where you have your servers (use a routing protocol or whatever) * The peers of large network provider will be routed to the closest DENIC server in large network providers network. * If a server is down, the next closest DENIC server will get the traffic. * There is no single point of failure here. * You are using anycast. * You have a multiple failover solution. I hope this was clear enough. Cheers, Joergen Hovland

jorgen@hovland.cx (Jørgen Hovland) wrote:

Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers around the world at their collocation facilities. MCI may then assign DENIC one /64 prefix from their /32 prefix which will be routed to the closest DENIC server in MCIs network. Would this be a suitable solution? This /32 has not been given to MCI by the RIR explicit for anycast purposes.

Vendor/ISP dependence has never been a solution for better availability. Michael and you are somewhat off the track IMHO. Read Gert's comment, too. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---