Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy)
Sorry meant to send this to the list! --Heather ---------- Forwarded message ---------- From: heather skanks <heather.skanks@gmail.com> Date: May 9, 2007 8:48 AM Subject: Re: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) To: Gert Doering <gert@space.net> Why the assumptaion that anycast requires PI space in the first place? I can understand why it might be preferred that DNS operators have PI space, regardless of whether they anycast. They don't need a lot of space to run the service, and without a policy to allow them to get PI, they would be dependent on space from a provider. But, I think their need for PI has more to do with them being critical infrastructure, rather than the fact that they anycast. The fact that they don't need a lot of space to run the service and wouldn't otherwise qualify for PI, means that there needs to be a special policy for them. That said, the change from "If the name server set of a ccTLD or a gTLD " to: "If the name server set of an organisation running DNS" The rest of the policy goes on to make the requirement that they have 8 or more IP addresses for the services (pre anycasting) and demonstration of the need to do anycasting. The new text seems to change the policy to hinge more on the need to anycast as justification for this space, rather than the service being critical infrastructure. I don't know of anything inherent in anycast technology that would require provider independent space. --Heather On 4/25/07, Gert Doering <gert@space.net> wrote:
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
Hi Heather, ---------- Forwarded message ---------- From: heather skanks < <mailto:heather.skanks@gmail.com> heather.skanks@gmail.com> Date: May 9, 2007 8:48 AM Subject: Re: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) To: Gert Doering < <mailto:gert@space.net> gert@space.net>
Why the assumptaion that anycast requires PI space in the first place?
I agree, and I already mentioned this 2 years ago: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01079.... The 8 ip-address limit only limits actual locations you can place your nameservers at. So 8 locations/different ISPs is with todays standard more than enough? At those 8 locations you can at each configure 80 network load balancing servers causing a total capacity of ~13 million queries per second with old hardware and bad dns software. There is no such thing as “critical internet infrastructure”. The internet is never stronger than its weakest link. If that is ccTLD nameservers... okay. (This whole anycast problem only concerns nameservers with very few but extremely large zones. The others can just spread them into different nameservers) Cheers,
[ can people avoid using HTML please.... eyes hurt etc ] Heather Skanks wrote: [..]
That said, the change from "If the name server set of a ccTLD or a gTLD " to: "If the name server set of an organisation running DNS" The rest of the policy goes on to make the requirement that they have 8 or more IP addresses for the services (pre anycasting) and demonstration of the need to do anycasting.
The new text seems to change the policy to hinge more on the need to anycast as justification for this space, rather than the service being critical infrastructure.
As without that little rule I could simply ask for a nice chunk of /24 PI space for my "DNS servers" which are used for my single domain. (Gert I need a /24 PI for my unfix.org dns servers!!!! kidding :) That said, as this policy is specific for organizations running, why not simply have a "minimum amount of DNS 2nd and 1st level zones served". Giving the criteria "runs one or more TLD's" justification to apply to this policy. And "runs more than a 10.000 1st level domains" justification to apply to it too. (10k chosen arbitrarily, I'll let the folks here figure that number out :) Greets, Jeroen (in the above TLD = ".com", 1st level domain == "example.com", 2nd level domain would be "marketing.example.com", of course for TLD's like .uk, a 1st level domain is "example.co.uk")
I thought we learned from the 200 customer rule :-) j -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jeroen Massar Sent: 9. mai 2007 15:36 To: Heather Skanks Cc: address-policy-wg@ripe.net Subject: Re: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) [ can people avoid using HTML please.... eyes hurt etc ] Heather Skanks wrote: [..]
That said, the change from "If the name server set of a ccTLD or a gTLD " to: "If the name server set of an organisation running DNS" The rest of the policy goes on to make the requirement that they have 8 or more IP addresses for the services (pre anycasting) and demonstration of the need to do anycasting.
The new text seems to change the policy to hinge more on the need to anycast as justification for this space, rather than the service being critical infrastructure.
As without that little rule I could simply ask for a nice chunk of /24 PI space for my "DNS servers" which are used for my single domain. (Gert I need a /24 PI for my unfix.org dns servers!!!! kidding :) That said, as this policy is specific for organizations running, why not simply have a "minimum amount of DNS 2nd and 1st level zones served". Giving the criteria "runs one or more TLD's" justification to apply to this policy. And "runs more than a 10.000 1st level domains" justification to apply to it too. (10k chosen arbitrarily, I'll let the folks here figure that number out :) Greets, Jeroen (in the above TLD = ".com", 1st level domain == "example.com", 2nd level domain would be "marketing.example.com", of course for TLD's like .uk, a 1st level domain is "example.co.uk")
Jørgen Hovland wrote:
I thought we learned from the 200 customer rule :-)
And what exactly did you learn from that rule? Ah indeed, that instead of requiring 200 customers, one could better simply let the requester justify the address space. If you have 1 zone to serve, and you request a PI block for that, I don't really see a real justification. If you have one or more TLD's, I definitely see a justification. If you have 10.000 zones, I can also be tricked into seeing a justification. As I mentioned, the 10k is an arbitrary number, to avoid exactly what the 200 number was for: that everybody can grab PI space for their need wherever they want. Of course, I can't care less so much about IPv4, it will make it run out even further, but letting junk into the IPv6 space is waste. Then again, one can of course say "I am a site" and get a nice /48 PI from ARIN already. Or just claim you are an IX of course. Greets, Jeroen
On 9 May 2007, at 14:54, Jeroen Massar wrote:
If you have 1 zone to serve, and you request a PI block for that, I don't really see a real justification.
What about if it's one very popular zone, and you want to get dns for it topologically close to as many end users as possible ? There's nothing to stop you breaking off a bit of your PA and getting that announced at lots of places where you host an anycast instance, but now we're causing deaggregation. -- Andy Davidson - ( http://www.andyd.net/ )
On 9 May 2007, at 6:39pm, Andy Davidson wrote:
If you have 1 zone to serve, and you request a PI block for that, I don't really see a real justification.
What about if it's one very popular zone, and you want to get dns for it topologically close to as many end users as possible ?
There's nothing to stop you breaking off a bit of your PA and getting that announced at lots of places where you host an anycast instance, but now we're causing deaggregation.
If you aren't the LIR then you probably need the agreement of the LIR before deaggregating their allocation. I suspect that lots of organisations would like to spread the DNS load but aren't LIRs. Regards, -- Leo Vegoda IANA Numbers Liaison
* Jeroen Massar <jeroen@unfix.org> [2007-05-09 15:55]:
If you have 1 zone to serve, and you request a PI block for that, I don't really see a real justification.
If you have one or more TLD's, I definitely see a justification.
If you have 10.000 zones, I can also be tricked into seeing a justification.
I agree with Jeroen. We're having waaay more than 10.000 zones which (currently) don't go over the 512 byte limit. On the contrary, if I wanted to get PI, what would stop me from taking one zone, expand it's dns records up to 512+ byte and request the space? I'm more in favor for a "number of zones" limit. 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
If you have 10.000 zones, I can also be tricked into seeing a justification. I agree with Jeroen. We're having waaay more than 10.000 zones which (currently) don't go over the 512 byte limit.
On the contrary, if I wanted to get PI, what would stop me from taking one zone, expand it's dns records up to 512+ byte and request the space?
Why should address policy be so tightly tied to the technical details of the DNS protocol and its implementation? Are you saying that IPv4 Anycast is only justified if the application is DNS hosting and the number of separate zones (presumably you count SOA records) goes over a certain limit? No other application is justified? Only the organization hosting the DNS is eligible, i.e. a data centre operator who wants to provide hosting services is not eligible? Every DNS hoster with over x zones gets their own /24 even though you could aggregate over 200 such organizations into one /24 if they shared data centre infrastructure? It seems to me that this approach to IPv4 Anycast prefixes only reinforces an existing monopoly and blocks organizations who might want to take a fresh approach to DNS hosting or other types of application hosting. --Michael Dillon
* michael.dillon@bt.com <michael.dillon@bt.com> [2007-05-10 11:09]:
I agree with Jeroen. We're having waaay more than 10.000 zones which (currently) don't go over the 512 byte limit.
On the contrary, if I wanted to get PI, what would stop me from taking one zone, expand it's dns records up to 512+ byte and request the space?
Why should address policy be so tightly tied to the technical details of the DNS protocol and its implementation?
Are you saying that IPv4 Anycast is only justified if the application is DNS hosting and the number of separate zones (presumably you count SOA records) goes over a certain limit?
No other application is justified?
No, I don't say that. I'm not happy with these "numerical" requirements. But I'm *more* happy with the SOA count (in our case) then the 512 byte limit.
Only the organization hosting the DNS is eligible, i.e. a data centre operator who wants to provide hosting services is not eligible?
Every DNS hoster with over x zones gets their own /24 even though you could aggregate over 200 such organizations into one /24 if they shared data centre infrastructure?
It seems to me that this approach to IPv4 Anycast prefixes only reinforces an existing monopoly and blocks organizations who might want to take a fresh approach to DNS hosting or other types of application hosting.
You definitely have a point here. I'm hoping that someone comes up with a better plan for the requirement(s), I'm still thinking about one. It's a lot of space to give away, and there has to be some sort of limitation. 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
No, I don't say that. I'm not happy with these "numerical" requirements. But I'm *more* happy with the SOA count (in our case) then the 512 byte limit.
It is hard to do this kind of policy without numerical requirements. But we need to agree on what will be counted before deciding on the numbers. As you say, it seems bad to count bytes per DNS packet. Counting SOA records seems more reasonable but is still DNS specific and can be spoofed easily. However, counting data centre locations is harder to spoof and is more in line with IP addressing policy. We already allow physical locations as a justification for a subnet. Normally, we also count hosts within the location, but for IPv4 Anycast, multiple hosts hide behind a single IP address so host counting is problematic. Currently, the IPv4 Anycast policy seems to accept 99.6% wasted address space as OK. I am suggesting that the policy should try to reduce that waste, by offering a /24 to organizations which provide Anycast hosting services. Since you can't legitimately offer such a service without having some minimum number of data centre locations, then the policy could specify a minimum number. And if you gain more than 250 or so customers and need another /24 then that should be easy to get. People who want to anycast their DNS, then have the option to set up a generic anycast hosting service, or contract with a service provider who offers such a hosting service. And people who want to anycast something else, like map data or satellite photos, or financial data, can also use IPv4 anycast without chasing the RIR to change policies or pretending to be a DNS hosting service. And people won't complain that RIPE is anti-competitive. Technically, it seems to me that any hosting application which sends out predictable replies to queries from a static database could potentially benefit from anycasting. In any case, RIPE shouldn't tell people what to do, just make it possible for people to do things. --Michael Dillon
michael.dillon@bt.com wrote: [..]
Currently, the IPv4 Anycast policy seems to accept 99.6% wasted address space as OK. I am suggesting that the policy should try to reduce that waste, by offering a /24 to organizations which provide Anycast hosting services. Since you can't legitimately offer such a service without having some minimum number of data centre locations, then the policy could specify a minimum number. And if you gain more than 250 or so customers and need another /24 then that should be easy to get.
This sounds VERY acceptable to me, and IMHO this should definitely be incorporated into this new policy. This is the real justification that can be very easily verified by RIPE NCC to see if the requester really has a need for this address space. It can then indeed also be applied for other services that benefit from an anycast construct. Also, for the DB WG, should there maybe be a special way of notating anycast prefixes in the route/route6 object!? This way, when one does a whois it will pop up showing that the prefix is anycasted, and possibly from where, when documented. This allows for better debugging, otherwise you customer might be reporting "issues to reach X or Y", while it actually is going somewhere completely different for you. Of course traceroute is always a help there too, but how many customers know how to use that ;) Greets, Jeroen
Jeroen Massar wrote:
michael.dillon@bt.com wrote: [..]
Currently, the IPv4 Anycast policy seems to accept 99.6% wasted address space as OK. I am suggesting that the policy should try to reduce that waste, by offering a /24 to organizations which provide Anycast hosting services. Since you can't legitimately offer such a service without having some minimum number of data centre locations, then the policy could specify a minimum number. And if you gain more than 250 or so customers and need another /24 then that should be easy to get.
This sounds VERY acceptable to me, and IMHO this should definitely be incorporated into this new policy. This is the real justification that can be very easily verified by RIPE NCC to see if the requester really has a need for this address space. It can then indeed also be applied for other services that benefit from an anycast construct.
Also, for the DB WG, should there maybe be a special way of notating anycast prefixes in the route/route6 object!?
Is the status: attribute the appropriate place or mechanism for this? Anycasting is more like a special routing setup, imho, so (just from a debugging point of view) the Routing Registry might be more appropriate?
This way, when one does a whois it will pop up showing that the prefix is anycasted, and possibly from where, when documented. This allows for better debugging, otherwise you customer might be reporting "issues to reach X or Y", while it actually is going somewhere completely different for you. Of course traceroute is always a help there too, but how many customers know how to use that ;)
Greets, Jeroen
Wilfried.
Hi, On Thu, May 10, 2007 at 12:25:03PM +0100, michael.dillon@bt.com wrote:
In any case, RIPE shouldn't tell people what to do, just make it possible for people to do things.
I want to remind the readers that there is no evil conspiracy called "RIPE", but that *you* are part of RIPE, as well as I am, and everybody else in RIPE land. Policy is made by community consensus - and if the community wants to be restrictive, those that do see a specific need are always welcome to come forward and present their case. Argueing that "someone else might want to do this!!!" even if nobody every showed up and said so isn't going to bring us forward (we had this discussion already last time this policy was under discussion, and nobody was able to present a case for working non-DNS wide-area anycast) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sebastian Wiesinger wrote:
* michael.dillon@bt.com <michael.dillon@bt.com> [2007-05-10 11:09]: [...]
No other application is justified?
No, I don't say that. I'm not happy with these "numerical" requirements. But I'm *more* happy with the SOA count (in our case) then the 512 byte limit.
Everyone can create as many SOA-records as necessary. I don't think that this is a good idea to count the number of hosted domains. I've even seen customers which generate a subdomain for each A-record. The 512 byte limit is hard to prove but it's for protocol reasons. Nevertheless, does it still make sense?
Sebastian
Johann - -- Johann Gutauer, jgutauer@cw.net Sen. Netw. Engineer DNS Cable&Wireless Telecommunication Services GmbH Landsberger Str.155 D-80687 München Deutschland Geschäftsführer Francois Goreux, Richard Pennal Amtsgericht München HRB 146 617 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQxeMQ7r8ZjAASRARArPqAJ9f/FUAwNFA1fg+lm5U5c7P3tkXuQCfdgSN V4SXua4nc8c2WPrgVtVvYPc= =D+uF -----END PGP SIGNATURE-----
* Johann Gutauer <jgutauer@cw.net> [2007-05-10 15:30]:
No, I don't say that. I'm not happy with these "numerical" requirements. But I'm *more* happy with the SOA count (in our case) then the 512 byte limit.
Everyone can create as many SOA-records as necessary. I don't think that this is a good idea to count the number of hosted domains. I've even seen customers which generate a subdomain for each A-record.
You would have to restrict that to 1st-level domains to be effective, but there would surely be cases where this would exclude people who have a valid reason for anycast. At the moment the "physical location" requirement seems to be the one which covers most of the valid anycast setups, if I'm not mistaken?
The 512 byte limit is hard to prove but it's for protocol reasons. Nevertheless, does it still make sense?
I don't think it still makes sense. It doesn't cover for example (D)DoS, which is something you can fend of with anycast. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 10.05.2007 11:09, michael.dillon@bt.com wrote:
Why should address policy be so tightly tied to the technical details of the DNS protocol and its implementation?
Are you saying that IPv4 Anycast is only justified if the application is DNS hosting and the number of separate zones (presumably you count SOA records) goes over a certain limit?
No other application is justified?
The reason is that there has been the need of an Anycast Assignment by the DNS people, and when asking the community what other services using currently anycast noone stood up. So the policy was made in regards to the DNS. At least that's the story as far as I remember. Additionally, the policy would not have reached consensus if it would have been open to all anycasting services.
Only the organization hosting the DNS is eligible, i.e. a data centre operator who wants to provide hosting services is not eligible?
Not even with the existing policy.
Every DNS hoster with over x zones gets their own /24 even though you could aggregate over 200 such organizations into one /24 if they shared data centre infrastructure?
It seems to me that this approach to IPv4 Anycast prefixes only reinforces an existing monopoly and blocks organizations who might want to take a fresh approach to DNS hosting or other types of application hosting.
As it was said here in the Address Policy WG session at the RIPE Meeting, for v4 this may become obsolete when the policy reaches consensus that set the PI assignment size to a /24 minimum generally. v6 then still remains as unsolved. 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 iD8DBQFGQvnrhC6y11CNwvcRArtXAJ43WNgEuPWuJjp8mbz5EW/wrRuBFwCg4T/n U4zgdj7J5YNbKs+t4V9Ztsg= =Ck2T -----END PGP SIGNATURE-----
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Tobias Cremer Hi,
Only the organization hosting the DNS is eligible, i.e. a data centre operator who wants to provide hosting services is not eligible?
Not even with the existing policy.
This depends on the definition. If a network announce their /16 prefix world-wide and decide to assign a customer a /29 for the use of anycast, they are entirely free to do so. The internal routing for the /29 within this network obviously needs to be configured for anycast use directed to the closest of the 15 different datacenters. The /29 is of course not announced to dfz, only the aggregate /16 is. Is the problem with this method perhaps that DNS operators don't seem to operate a real network and they are not willing to let the network operator to it for them? Or is the network operator unwilling to do it? Or is it just a bad plan? J
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10.05.2007 13:28, Jørgen Hovland wrote:
Only the organization hosting the DNS is eligible, i.e. a data centre operator who wants to provide hosting services is not eligible?
Not even with the existing policy.
This depends on the definition. If a network announce their /16 prefix world-wide and decide to assign a customer a /29 for the use of anycast, they are entirely free to do so. The internal routing for the /29 within this network obviously needs to be configured for anycast use directed to the closest of the 15 different datacenters. The /29 is of course not announced to dfz, only the aggregate /16 is.
Well, I was perhaps not precise enough. The existing DNS Anycasting Assignment policy is for dedicated Anycast assignments only for DNS Anycasting setups. Of course that doesn't mean that you can't anycasting others service, e.g. as you described above, but you cannot receive an own assignment for that. 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 iD8DBQFGQxLyhC6y11CNwvcRAvCBAKCe1RZOdXFQPNGWAcWoiRlvOwrIHQCggqhE 5YCfUk3pqZoMJcfwd30KeUM= =+MuI -----END PGP SIGNATURE-----
Hi, On Thu, May 10, 2007 at 01:28:02PM +0200, Jørgen Hovland wrote:
This depends on the definition. If a network announce their /16 prefix world-wide and decide to assign a customer a /29 for the use of anycast, they are entirely free to do so. The internal routing for the /29 within this network obviously needs to be configured for anycast use directed to the closest of the 15 different datacenters. The /29 is of course not announced to dfz, only the aggregate /16 is.
Indeed, this could be a workable solution for entities that already operate a large network, and would want to have all of the anycast nodes inside their network ("under their direct control"). In that case, we don't need anything special policywise, as the whole anycast setup would not be visible in the global routing system, and we don't need special prefixes, etc. etc. This isn't possible for most of the TLD operators (as they do not have a large network, usually, but host their boxes at other networks, IXPs, etc.) - but it might be a workable approach for service providers that just want to provide reliable DNS service, and do not want/need an external routing table slot. 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
Hi, On Thu, May 10, 2007 at 10:09:26AM +0100, michael.dillon@bt.com wrote:
Why should address policy be so tightly tied to the technical details of the DNS protocol and its implementation?
Just for the records: because this policy is an exeption to the normal rules - and an exception made for a very specific community (DNS TLD Ops) that made a good point for it. If the normal rules permitted anybody to get a /24 IPv4 PI and an IPv6 PI block (which might happen over time, we can't know yet), then we need no exception to the rule. As of now, neither is easily available in RIPE land, and thus a special case policy was made. (As for all the arguments going back and forth regarding the *existing* policy, please don't rehash them here - just go to the mailing list archives. Everything has been said before). So there's actually just two thing that we want to decide *now*: - do we want to change the rules for this specific policy to apply to other entities as well? - if yes, what shall the new rules be? The rules should always aim to - solve the problem (so it would be helpful if organizations that are *not* a TLD operator but would want to do an externally-visible anycast setup to speak up, say what they are doing, and why it can't be done using the standard way to build nameserver redundancy "just put up a good number of them") - be easy to evaluate by the RIPE NCC 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, Gert Doering wrote:
Hi, [...] So there's actually just two thing that we want to decide *now*:
- do we want to change the rules for this specific policy to apply to other entities as well?
basically, yes. Anycast is a nice technology, works great for DNS and i don't like being hindered to deploy new technologies by outdated policies that much in general (even that i don't have any personal interest in DNS Anycast on the public internet atm.) What i'm not sure about is other-than-DNS Anycast usage. If anyone can come up with nice examples.... fine. Otherwise i would - for now - only deal with DNS-Anycast in any new/changed policy, and probably look into that issue again if there are clear ideas for other Anycast setups (on the public Internet). (That one is aimed towards those who would like to expand the policy change to anything beyond DNS...)
- if yes, what shall the new rules be?
Always a good qustion - which i don't have much clue about since i never felt the need for DNS anycast (yet). As an outsider here, i'd rather like to have a not-so-strict policy/rules about that on a first glance. I probably want to be able to anycast my own small nameservers just for the fun of it sometimes - "i don't get Anycast Addresses due to anycast policy issues? Ok then i will just use some PI/Unspecific for that" ... (i guess you all get the idea of what i want to point out with that fictional statement). But i'm not familiar with DNS Setups which would require/benefit from anycast, so i'm really out of ideas about possible boundaries for a yes or no.
The rules should always aim to
- solve the problem (so it would be helpful if organizations that are *not* a TLD operator but would want to do an externally-visible anycast setup to speak up, say what they are doing, and why it can't be done using the standard way to build nameserver redundancy "just put up a good number of them")
- be easy to evaluate by the RIPE NCC
I'd like to see some real-life ideas about WHY an entity wants to use DNS anycast here, too. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Hi, On Tue, May 15, 2007 at 01:45:53PM +0200, Sascha Lenz wrote:
I'd like to see some real-life ideas about WHY an entity wants to use DNS anycast here, too.
Well, for the original proposal, the reasoning was about this: - entity wants to deploy a LARGE number of nameservers for a given zone - the way DNS works limits the amount of NS records that can be returned by the parent - if more nameservers are to be deployed, they must "share an NS record" (sort of) -> anycast. - ("the DNS WG says that anycast is a useful approach", and they are the DNS experts, so it's not us to argue this statement) - added benefits are indeed "bring servers closer to the clients" (improve latency) and "DDoS spread" (DDoS usually hits not all of the instances, so lots of users are not affected at all) the last argument is hard to bring into a policy (because it's hard for the NCC to evaluate) - the first argument is a hard technical fact, and as such, can be measured, counted, and used for a decision. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10.05.2007 09:50, Sebastian Wiesinger wrote:
I'm more in favor for a "number of zones" limit.
I disagree here, as the number of zones a) is again a number - but which one? How can we decide how many zones you need to serve. And what if someone has x-1 zones? He won't be eligible for an anycasting assignment, even if he serves e.g. 9999 zones. b) is generally no criteria for being eligible for an anycasting assignment in my opinion. If it would be, it would mean "I'm more important because I have more zones, and thus may do anycast". 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 iD8DBQFGQv06hC6y11CNwvcRAhOaAJ4xj225RJp3RsmtaCl88/3CbBblmgCgpR1K HfAtaCA3aWTgJB4T9UnD3ig= =OyVX -----END PGP SIGNATURE-----
* Tobias Cremer <tcremer@cw.net> [2007-05-10 13:10]:
On 10.05.2007 09:50, Sebastian Wiesinger wrote:
I'm more in favor for a "number of zones" limit.
I disagree here, as the number of zones
a) is again a number - but which one? How can we decide how many zones you need to serve. And what if someone has x-1 zones? He won't be eligible for an anycasting assignment, even if he serves e.g. 9999 zones.
b) is generally no criteria for being eligible for an anycasting assignment in my opinion. If it would be, it would mean "I'm more important because I have more zones, and thus may do anycast".
Yes, you're right. The same problem exists with the 512 byte limit. There are valid reasons for anycast without meeting these criteria. (And in my opinion they are even more important then number of zones/bytes). Michael Dillon suggests to use physical locations as a criteria. Perhaps we should go in that direction? Something like: You're providing a service which will benefit from anycast AND you have x¹ physical locations where you will deploy these services (Regardless of who "owns" the location). ¹(x locations could be "multiple" or a number?) 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
participants (12)
-
Andy Davidson -
Gert Doering -
heather skanks -
Jeroen Massar -
Johann Gutauer -
Jørgen Hovland -
Leo Vegoda -
michael.dillon＠bt.com -
Sascha Lenz -
Sebastian Wiesinger -
Tobias Cremer -
Wilfried Woeber, UniVie/ACOnet