2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy)
PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. This proposal suggests that there should no longer be a requirement to be a ccTLD or a gTLD to receive IPv4 and IPv6 assignments for anycasting DNS. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-02.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 21 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
Just wondering, this is essentially PI, too, so... would the 2007-01 reasoning and proposal be also applicable here? Wilfried. Filiz Yilmaz wrote:
PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy
Dear Colleagues
A new RIPE Policy Proposal has been made and is now available for discussion.
This proposal suggests that there should no longer be a requirement to be a ccTLD or a gTLD to receive IPv4 and IPv6 assignments for anycasting DNS.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2007-02.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 21 May 2007.
Regards
Filiz Yilmaz RIPE NCC Policy Development Officer
Hi, On Wed, Apr 25, 2007 at 11:41:00AM +0000, Wilfried Woeber, UniVie/ACOnet wrote:
Just wondering, this is essentially PI, too, so... would the 2007-01 reasoning and proposal be also applicable here?
Well, yes-and-no. 2007-01 is only IPv6, while this is IPv4+IPv6, with a special twist "this prefix comes from a certain range set aside for DNS anycast deployment" (to help folks in adjusting their routing filters). Eventually (if we have IPv6 PI) the whole list of exceptions to the RIPE IPv6 policy could be removed, and be replaced by a field on the PI request "please assign from the [ ] DNS anycast [ ] IXP [ ] root DNS address range". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Well, yes-and-no. 2007-01 is only IPv6, while [...]
2007-01 applies to ipv4, ipv6 and as numbers. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
Hi, On Wed, Apr 25, 2007 at 03:44:26PM +0100, Nick Hilliard wrote:
Well, yes-and-no. 2007-01 is only IPv6, while [...] 2007-01 applies to ipv4, ipv6 and as numbers.
Sorry. I got all confused with the IPv6 PI proposal (which is 200*6*-01). However, my primary comment still stands :-) - if we end up having IPv6 PI, we can do away with most of the special-case IPv6 policies. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Why does this proposal say it's for DNS only? I guess other anycast protocols aren't important enough? j -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering Sent: 25. april 2007 16:52 To: Nick Hilliard Cc: Gert Doering; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) Hi, On Wed, Apr 25, 2007 at 03:44:26PM +0100, Nick Hilliard wrote:
Well, yes-and-no. 2007-01 is only IPv6, while [...] 2007-01 applies to ipv4, ipv6 and as numbers.
Sorry. I got all confused with the IPv6 PI proposal (which is 200*6*-01). However, my primary comment still stands :-) - if we end up having IPv6 PI, we can do away with most of the special-case IPv6 policies. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi, On Wed, Apr 25, 2007 at 05:00:52PM +0200, Jørgen Hovland wrote:
Why does this proposal say it's for DNS only?
The protocol is changing an existing policy document, which has "DNS only" in it. It's not creating new policy.
I guess other anycast protocols aren't important enough?
What other anycast protocols are in widespread use today? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering On Wed, Apr 25, 2007 at 05:00:52PM +0200, Jørgen Hovland wrote:
Why does this proposal say it's for DNS only?
The protocol is changing an existing policy document, which has "DNS only" in it. It's not creating new policy.
I understand.
I guess other anycast protocols aren't important enough?
What other anycast protocols are in widespread use today?
I assume very few, but I was more curious and I'm not objecting to anything. I am not too fond of policies that are so restricted to certain types of technology. It may prevent innovative and/or competitive new solutions to be deployed to the masses. So sometimes I wonder why IP assignment policies specify layer 7 technology at all. j
Hi, On Wed, Apr 25, 2007 at 05:21:24PM +0200, Jørgen Hovland wrote:
I am not too fond of policies that are so restricted to certain types of technology. It may prevent innovative and/or competitive new solutions to be deployed to the masses. So sometimes I wonder why IP assignment policies specify layer 7 technology at all.
When that policy was made, people heavily objected to any sort of "direct to the end user" (= PI) IPv6 assignments, but still, there was a well-defined need for this specific application. To be able to reach consensus between the DNS group ("we need this! now!") and the conservationists ("keep the flood gates closed!"), this policy was done in a very targeted way, with a limited scope. Similar for IXP and Root DNS policies. As I said before - if the IPv6 PI policy goes through, we can move all the special-case policies to the big heap of historic garbage. If not, we'll have to live with a few exceptions that the ``majority'' of this group agrees upon. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert Doering wrote:
Hi,
On Wed, Apr 25, 2007 at 03:44:26PM +0100, Nick Hilliard wrote:
Well, yes-and-no. 2007-01 is only IPv6, while [...]
2007-01 applies to ipv4, ipv6 and as numbers.
Sorry. I got all confused with the IPv6 PI proposal (which is 200*6*-01).
However, my primary comment still stands :-) - if we end up having IPv6 PI, we can do away with most of the special-case IPv6 policies.
I think my terse contribution started the confusion, sorry :-/ My point is that we are discussing how to improve the linkage of resources that are *not* PA in 2007-01. That discussion pertains to IPv4 PI and AS numbers. However, 2007-02 applies to resources that are, in effect, portable and handled like IPv4 PI. That was the basis for my question.
Gert Doering -- APWG chair
But it is probably a minor issue and/or premature as we do not know yet if and when 2007-01 reaches consensus, eventually. Wilfried.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25.04.2007 13:41, Wilfried Woeber, UniVie/ACOnet wrote:
Just wondering, this is essentially PI, too, so... would the 2007-01 reasoning and proposal be also applicable here?
Actually it is applied to the current policy texts: See item "2. Additions". Only the term "TLD" would have to be removed in order to make 2007-01 applicable to a possibly accepted proposal 2007-02. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 Geschäftsführer Francois Goreux, Richard Pennal Amtsgericht München HRB 146 617 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMHavhC6y11CNwvcRAqqfAKDG1ECwzJ9bNg8wvU0VZdnU4dbamQCgjoSe 7r09je6DnBUCKTEkKLSUzag= =1/wg -----END PGP SIGNATURE-----
PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy
Without questioning the particular needs of the proponent, the proposal as it stands has some issues to be resolved (quoting only the v4 part for ripe405 here):
6.9 Anycasting Name servers
If the name server set of an organisation running DNS without using
It is unclear to me whether "an organisation" refers to the domain holder, zone maintainer or the DNS infrastructure provider, if any. The original proposal deliberately chose the term TLD here, referring to the TLD manager, not the service provider and if this proposal intends to change that, it should be made more explicit.
anycasting technology would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the organisation may receive a single dedicated /24 network prefix for the sole purpose of anycasting name servers, as described in RFC 3258.
The organisation should demonstrate that the number of name servers or IP addresses for these name servers in the delegation exceeds eight and that without anycasting their zone size exceeds the UDP datagram size.
During the discussion of the original anycast policy proposal it was carefully avoided -- after some looping debate -- to encode explicit DNS parameters into said proposal. That's the whole point of referring to IANA's delegation procedure. Now, I understand that IANA's procedures aren't applicable to non-TLDs, but at the same time it isn't obvious where the number "eight" originates from. To make matters more complicated, the basic procedure IANA is supposed to apply would indeed fit well, but then depends on the respective parent's glue and registration policy. Again, I'm not sure anyone would want the RIPE NCC to engage in cumbersome tests and judgements, so even a fixed number might be fine - if there's some rationale given. NIT: "their zone size exceeds the UDP datagram size" should probably read "a referral response for their domain would exceed the 512 octet UDP payload limit".
The organisation should also demonstrate that they need to do anycasting due to the geographical diversity of their DNS setup. The organisation will be required to demonstrate that anycasting will be used in diverse geographical locations. The existence of the real servers should be demonstrated with anycasting nodes that can be pinged and tracerouted.
That should be topological diversity instead. I'm not so confident that pings and traceroutes can differentiate between anycast and multihoming uses. The basic question is whether checks should be applied at all.
The prefix will be assigned by the RIPE NCC directly to the organisation, upon a request submitted via an existing LIR and will be registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database. The prefix must be returned to the RIPE NCC if no longer in use for anycast DNS.
Within the "arguments opposing the proposal" I'd suggest to change the reason from "... be opened to organisations that are not a ccTLD or a gTLD." to something like "... no longer have an upper bound of {some fraction of 267}." Actually, the proliferation of anycast assignments could lead to more rigid filtering. -Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Peter, On 02.05.2007 19:07, Peter Koch wrote:
6.9 Anycasting Name servers
If the name server set of an organisation running DNS without using
It is unclear to me whether "an organisation" refers to the domain holder, zone maintainer or the DNS infrastructure provider, if any. The original proposal deliberately chose the term TLD here, referring to the TLD manager, not the service provider and if this proposal intends to change that, it should be made more explicit.
As the proposal intends to open the policy not only to TLD nameservers but to all Anycasting DNS setups (with some more requirements than just anycasting), you can't refer only to the TLD manager anymore. "An organisation" is the organisation that operates the DNS servers. One could include again the term of the TLD manager, but I think it doesn't make much sense here as operating a TLD is not a requirement anymore.
anycasting technology would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the organisation may receive a single dedicated /24 network prefix for the sole purpose of anycasting name servers, as described in RFC 3258.
The organisation should demonstrate that the number of name servers or IP addresses for these name servers in the delegation exceeds eight and that without anycasting their zone size exceeds the UDP datagram size.
During the discussion of the original anycast policy proposal it was carefully avoided -- after some looping debate -- to encode explicit DNS parameters into said proposal. That's the whole point of referring to IANA's delegation procedure. Now, I understand that IANA's procedures aren't applicable to non-TLDs, but at the same time it isn't obvious where the number "eight" originates from.
Why is the IANA procedure not applicable to non-TLDs? It is clear that the IANA document only refers to TLD nameservers, but one can apply the requirements to other DNS setups as well. And in my opinion this is a good procedure, as the IANA policy in regards to the UDP packet size is a reasonably clear and well-defined requirement for having the need of an anycasting setup.
To make matters more complicated, the basic procedure IANA is supposed to apply would indeed fit well, but then depends on the respective parent's glue and registration policy.
Sorry, can you explain this a bit further?
Again, I'm not sure anyone would want the RIPE NCC to engage in cumbersome tests and judgements, so even a fixed number might be fine - if there's some rationale given.
Yes, basically we can refer to the number of nameservers instead solely, but I meant to have a more technical justification (the size of the UDP datagrams) would be helpful.
NIT: "their zone size exceeds the UDP datagram size" should probably read "a referral response for their domain would exceed the 512 octet UDP payload limit".
I'd be fine with changing the text accordingly.
The organisation should also demonstrate that they need to do anycasting due to the geographical diversity of their DNS setup. The organisation will be required to demonstrate that anycasting will be used in diverse geographical locations. The existence of the real servers should be demonstrated with anycasting nodes that can be pinged and tracerouted.
That should be topological diversity instead. I'm not so confident that pings and traceroutes can differentiate between anycast and multihoming uses. The basic question is whether checks should be applied at all.
The checks were meant to provide a possibility for a check as last means if the application is clear enough. And for maintenance reasons, every anycasting DNS server is reachable by a dedicated IP, right?
Actually, the proliferation of anycast assignments could lead to more rigid filtering.
If that's the case, the current practice and policy of PI address assignments should lead to that as well. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 Geschäftsführer Francois Goreux, Richard Pennal Amtsgericht München HRB 146 617 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOvxVhC6y11CNwvcRAmCwAJ44LwLrB+FIGsmDNI2lO8vU0lT2pgCgxEzP KLL+TVQcNN69Rk7YQLvf+5w= =qVfh -----END PGP SIGNATURE-----
* Tobias Cremer <tcremer@cw.net> [2007-05-04 11:28]:
During the discussion of the original anycast policy proposal it was carefully avoided -- after some looping debate -- to encode explicit DNS parameters into said proposal. That's the whole point of referring to IANA's delegation procedure. Now, I understand that IANA's procedures aren't applicable to non-TLDs, but at the same time it isn't obvious where the number "eight" originates from.
Why is the IANA procedure not applicable to non-TLDs? It is clear that the IANA document only refers to TLD nameservers, but one can apply the requirements to other DNS setups as well. And in my opinion this is a good procedure, as the IANA policy in regards to the UDP packet size is a reasonably clear and well-defined requirement for having the need of an anycasting setup.
Hello, the company I work for would greatly appreciate this policy change. We're hosting a huge amount of zones. We would benefit from using anycast for our setup, but not so much in regard to the 512 byte limit of the referral response. We see the need for an anycast setup for other reasons. Most important to us: The mitigation of damage/effects from (D)DoS or disaster at / shutdown of a site. In this case the anycast setup would prevent bigger problems because other sites would handle the DNS requests. Besides that, anycast would improve our setup with load sharing between anycast locations and the possibility to deploy locations in other countries to improve response time. In this regard I would appreciate alternatives to the 8 NS rule in the policy. I must admit that I'm not quite sure what the alternatives should be, but I'm looking forward to comments/suggestions. Regards, Sebastian -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59579-051 Geschäftsführer/CEO: Thomas Mörz Amtsgericht Regensburg, HRB 7142 nic-hdl : SW1421-RIPE GPG-Key : 0x97F5A1D8 (0x8431335F97F5A1D8) GPG-Fingerprint : 6181 B041 3554 0B6F 4EF3 1B12 8431 335F 97F5 A1D8
Sebastian Wiesinger píše v St 09. 05. 2007 v 12:00 +0200:
We're hosting a huge amount of zones. We would benefit from using anycast for our setup, but not so much in regard to the 512 byte limit of the referral response. We see the need for an anycast setup for other reasons.
That's very good point. We don't have problem with 8 IP addresses since we are (will be shortly) running IPv6 on all our DNS nodes. We don't even have a problem to create 512 payload, since we are already almost at the limit and we plan to have more nodes. But our reasons for having anycasted DNS lies within stability and resiliency and not within "not able to fit in 512 bytes". I would rather have 4 anycasted nodes then to have 1 anycast and 7 unicast (or 2/6 setup). On the other hand I thought that this Anycasting DNS policy was made to cover "critical infrastructure of Internet". If we loosen this policy then anybody can create such DNS setup to grow bigger then 8 IP addresses and 512 and receive anycast IPv4/IPv6 address. I would be extremely careful to make those rules less strict (wearing my ccTLD hat now :-). Ondrej. -- Ondřej Surý technický ředitel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 -----------------------------------------
participants (9)
-
Filiz Yilmaz -
Gert Doering -
Jørgen Hovland -
Nick Hilliard -
Ondřej Surý -
Peter Koch -
Sebastian Wiesinger -
Tobias Cremer -
Wilfried Woeber, UniVie/ACOnet