RE: [address-policy-wg] PI for Not-DNS Anycast.
I think that the PI /24 block should be assigned only to UDP related services as RFC suggests, however, I have yet to see the successful implementation of TCP data, state... replication in case one router withdraws BGP announcement of the /24 prefix. IPv4 anycast is a perfect way to distribute load and hopefully with lowest latency (not always true) for the following UDP related services: -syslog -dns -ddos mitigation The PI /24 anycast block should be assigned only when the applicant can demonstrate: at least 5 physically disperse locations (verification done by traceroute and checking the hop before the last hop in the traceroute). Traceroute's can be performed from open traceroute gateways (over the web etc - there are hundreds) or public ISP BGP route servers. to manage the server you will need a non anycast address(es), however, customers may keep this info secret if they do not want it to be public.... all anycast nodes must speak BGP to the upstream and in case the server goes down, the BGP router withdraws the BGP anycast /24 route Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and other UDP based services, then expect all free /24 blocks taken in a year or less for sure ;) My $0.02 cents... Greg http://www.LinuxAdmin.org
Hi, On Tue, Aug 07, 2007 at 08:36:06PM -0700, Greg L. wrote:
Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and other UDP based services, then expect all free /24 blocks taken in a year or less for sure ;)
So what's your message? Do you support handing out /24 PI for "these" applications, or do you oppose it, due to address space / routing table slots usage? Your e-mail was a bit unclear in that respect... 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
I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit... The rules for IPv6 anycast allocations must be not that strict in the future... why? The address space will be more than enough, the router HW will be more powerful to handle large routing tables ... Sincerely, Greg L.
On Tue, Aug 07, 2007 at 08:36:06PM -0700, Greg L. wrote:
Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and other UDP based services, then expect all free /24 blocks taken in a year or less for sure ;)
So what's your message? Do you support handing out /24 PI for "these" applications, or do you oppose it, due to address space / routing table slots usage?
Your e-mail was a bit unclear in that respect...
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 Greg,
I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit...
That is an incorrect assumption no matter how you look at it. To me, the biggest problem seems to be that people either doesn't know better or actually don't want to know better regarding this topic. I have probably written this before, and some people have probably answered, but: You can add as many anycast nameservers as you want without any prefix at all. They obviously have to be in the same asn/ip-network if you want to anycast without using your own prefix in dfz. You can also use other similar techniques than ancyast, for example network load balancing. The NS limit in a response is what, 13 entries? If you need more than 13 nameservers spread around 13 different networks, and they are all anycasted for each network, then you really need to start thinking about running some other nameserver software because it is obviously not designed to scale anyway. If you actually have 13 NS entries and 10 anycast servers per entry, you should be able to handle more than 7 billion requests per second with cheap hardware. DDoS is not a problem with decent hardware. With 7 billion requests per second I am sure you can afford it. j -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Greg L. Sent: 8. august 2007 21:39 To: Gert Doering Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PI for Not-DNS Anycast. I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit... The rules for IPv6 anycast allocations must be not that strict in the future... why? The address space will be more than enough, the router HW will be more powerful to handle large routing tables ... Sincerely, Greg L.
On Tue, Aug 07, 2007 at 08:36:06PM -0700, Greg L. wrote:
Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and other UDP based services, then expect all free /24 blocks taken in a year or less for sure ;)
So what's your message? Do you support handing out /24 PI for "these" applications, or do you oppose it, due to address space / routing table slots usage?
Your e-mail was a bit unclear in that respect...
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
I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit...
That is an incorrect assumption no matter how you look at it. To me, the biggest problem seems to be that people either doesn't know better or actually don't want to know better regarding this topic.
I have probably written this before, and some people have probably answered, but: You can add as many anycast nameservers as you want without any prefix at all. They obviously have to be in the same asn/ip-network if you want to anycast without using your own prefix in dfz. You can also use other similar techniques than ancyast, for example network load balancing.
Thanks for your response. Who needs a new /24 PI if you are only going to implement DNS anycast in your own network? I was speaking about global DNS anycast /24 PI allocation with min. ~5 disperse locations / networks, verified later by running traceroutes to see ASN, data path etc... Thanks Greg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg L. wrote: [...]
Who needs a new /24 PI if you are only going to implement DNS anycast in your own network? I was speaking about global DNS anycast /24 PI allocation with min. ~5 disperse locations / networks, verified later by running traceroutes to see ASN, data path etc... [...] ... and it shouldn't be linked to running ccTLD-Servers. Neither in IPv4 nor in IPv6.
Cheers, Johann - -- Johann Gutauer, jgutauer@cw.net Sen. Netw. Engineer DNS Cable&Wireless Telecommunication Services GmbH Tel: +49 89 92699 499 Landsberger Str.155 D-80687 München Deutschland Fax: +49 89 92699 810 Geschäftsführer Chris Connors, Jonathan Walters, Richard Pennal http://www.cw.com/de Amtsgericht München HRB 146 617 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuahJQ7r8ZjAASRARAq2tAJ9XOcayzz5iJx8Q++hpn3Hkl1ZmvgCfULoE 7gXlzADTJATTUX7zAfhlfRk= =aEeE -----END PGP SIGNATURE-----
Who needs a new /24 PI if you are only going to implement DNS anycast in your own network? I was speaking about global DNS anycast /24 PI allocation with min. ~5 disperse locations / networks, verified later by running traceroutes to see ASN, data path etc... [...] ... and it shouldn't be linked to running ccTLD-Servers. Neither in IPv4 nor in IPv6.
Sure it shouldn't. ccTLD DNS hosting requirement for /24 PI anycast assignment already forces small companies into unfair competence with LIR members and big guys. Sincerely, Greg LinuxAdmin.org
Hi Greg, On 8 Aug 2007, at 23:15, Greg L. wrote: [...]
I was speaking about global DNS anycast /24 PI allocation with min. ~5 disperse locations / networks, verified later by running traceroutes to see ASN, data path etc...
What is the reasoning behind the minimum of five locations? Why would four be too few? Regards, Leo Vegoda
Leo Vegoda wrote:
What is the reasoning behind the minimum of five locations? Why would four be too few?
This is the great thing about magic numbers. They offer a thin veneer of authority and the possibility of enabling easy policing. In many respects, it a real pity that rules based on numbers pulled out of the air like this have such a completely arbitrary basis. Life would be much easier. 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
This is the great thing about magic numbers. They offer a thin veneer of authority and the possibility of enabling easy policing. In many respects, it a real pity that rules based on numbers pulled out of the air like this have such a completely arbitrary basis. Life would be much easier.
So where does the magic number 53 come from? Why is this anycast policy only going to give an address block to those who wish to anycast services on port 53? If I ran http on port 53, could I get an allocation under this policy? Why not? Note that when this was discussed in the past, it was pointed out that some people had done some actual experiments and discovered that many protocols which seem to be not-anycastable, are able to be anycast in practice due to the stability of the net. RIPE should not be making arbitrary limits on what people can do. Yes, let's have a policy to give out address blocks to people who can show that they are running (or intend to run) real anycast services. Let's not restrict what those services are. If we are concerned about too many requests coming in, then let's place an arbitrary numerical limit for now, which can be removed later. In the case of anycast, the relevant thing to count for an arbitrary limit, is the number of separate geographical locations. Two is sufficient from a technical point of view, but given that RIPE policy can change to meet changing needs, it seems to me that it is not unreasonable to place a larger limit, perhaps 4, perhaps 5. --Michael Dillon
Leo:
I was speaking about global DNS anycast /24 PI allocation with min. ~5 disperse locations / networks, verified later by running traceroutes to see ASN, data path etc...
What is the reasoning behind the minimum of five locations? Why would four be too few?
No problem, it was just a suggestion. I remember reading email in the list with 8+ disperse location requirement. Greg
Greg L. wrote:
Leo:
I was speaking about global DNS anycast /24 PI allocation with min. ~5 disperse locations / networks, verified later by running traceroutes to see ASN, data path etc...
What is the reasoning behind the minimum of five locations? Why would four be too few?
No problem, it was just a suggestion. I remember reading email in the list with 8+ disperse location requirement.
So, we are rolling the dice again to come up with another "magic", arbitrarily chosen figure which is supposed to discriminate between those who "qualify" and those which don't?
Greg
IIRC, we spent a lot f effort recently to get rid of one of those magic numbers in one policy... IMHO, anycast becomes anycast, as opposed to unicast, as soon as you've got more than one, i.e. 2 (two) - or more. Right? Wilfried.
-----Original Message----- From: Greg L. [mailto:bgp2@linuxadmin.org]
Thanks for your response. Who needs a new /24 PI if you are only going to implement DNS anycast in your own network?
Why do you need anycast DNS? Suggestions: * To scale (and keep 100% uptime) * DDoS prevention/reduction of weaknesses The scaling problem has already been solved in my previous email. To take down all of your nameservers, the best way would probably be to generate a lot of DNS queries. But then we are back at the scaling problem which has already been solved. So what is the real problem? Cheers, j
At 04:36 2007.08.08.÷, Jørgen Hovland wrote:
-----Original Message----- From: Greg L. [mailto:bgp2@linuxadmin.org]
Thanks for your response. Who needs a new /24 PI if you are only going to implement DNS anycast in your own network?
Why do you need anycast DNS? Suggestions:
* To scale (and keep 100% uptime) * DDoS prevention/reduction of weaknesses
The scaling problem has already been solved in my previous email.
To take down all of your nameservers, the best way would probably be to generate a lot of DNS queries. But then we are back at the scaling problem which has already been solved. So what is the real problem?
To speed up DNS queries for their customers and clients. If I was running DNS hosting service I would prefer to have Australian visitors querying DNS boxes in Australia. Clients from Germany querying anycast node in Germany. And if I was in Romania, all local clients to "hit" DNS anycast IP in Romania. Why should only ccTLD's and some large LIR's allowed to lower the service query latency for DNS traffic and sometimes cut the bandwidth bills? ccTLD service should be NOT the only exception to get /24 PI for anycast DNS, the policy should be open for any business entity that can demonstrate the need for /24 PI DNS anycast allocation and 2+ disperse locations where this prefix is announced. Greg
Hi, just to point something out: On Wed, Aug 08, 2007 at 03:16:51PM -0700, Greg L. wrote:
ccTLD service should be NOT the only exception to get /24 PI for anycast DNS, the policy should be open for any business entity that can demonstrate the need for /24 PI DNS anycast allocation and 2+ disperse locations where this prefix is announced.
So far, I have seen *one* entity speak up and say "we want to do DNS anycast, and we're not a ccTLD operator". So there's certainly not overwhelming demand (yet?). Argueing on behalf of not-so-well defined others isn't too helpful in policy development... 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
-----Original Message----- From: Greg L. [mailto:bgp2@linuxadmin.org]
To speed up DNS queries for their customers and clients. If I was running DNS hosting service I would prefer to have Australian visitors querying DNS boxes in Australia. ...
I can't get myself to agree with you on that, but I understand the problem. If you actually have customers in Australia, TTL will take care of that for you. If you only have a few customers it cannot possibly be that important to have slightly lower latency for your domain at the first query. (FYI we are a medium size dns hosting company)
If I was running DNS hosting service I would prefer to have Australian visitors querying DNS boxes in Australia. Clients from Germany querying anycast node in Germany. And if I was in Romania, all local clients to "hit" DNS anycast IP in Romania.
Sure thing, but you probably mean the closest DNS box network wise/AS-hop/latency, not by country.
Why should only ccTLD's
They shouldn't.
and some large LIR's
Large LIRs probably have a decent network and can do what they want within their own network. Do you disagree that they should have that advantage?
..allowed to lower the service query latency for DNS traffic and sometimes cut the bandwidth bills?
Cheers, j
and some large LIR's
Large LIRs probably have a decent network and can do what they want within their own network. Do you disagree that they should have that advantage?
Sure it's their advantage... However, I cannot understand .. there are some companies that offer global anycast dns service in USA or ARIN has different rules (they didn't approve /24 for dns anycast back in 2005 I believe)? How these companies can meet 25% initial and 50% utilization in one year for that /24 allocation? Sincerely, Greg
Hi, On Aug 8, 2007, at 12:38 PM, Greg L. wrote:
I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit...
The term "overkill" comes to mind. How many name servers does one actually need (anycast or not), particularly given the concept of caching?
The rules for IPv6 anycast allocations must be not that strict in the future... why? The address space will be more than enough, the router HW will be more powerful to handle large routing tables ...
While router hardware will undoubtedly be more powerful, the question of whether or not BGP will be able to converge with everybody and their great aunt having PI space is still open. Then there is the question of whether or not people will be happy with the O(10) ISPs capable of affording the hardware/power/cooling of the future DFZ routers (have you priced top-end routers recently?). This proposal seems a bit on the extreme side to me. Rgds, -drc
Disperse located servers powered by anycast bgp will be much more resilient to attacks and local node can take the direct hit. Other anycast based locations will function as usual, unless the attack brings down the box and /24 route is withdrawn.... More and more Internet based services take advantages of lower TTL (many ISPs ignore it but still...) and if both dns servers for the particular domain are attacked with UDP flood and there is no cache record on your ISP's recursive DNS server - the service will be down. In anycast situation, a fraction of the clients will be affected... I still think /24 block anycast PI policy should be more open towards other business entities, not only for ccTLD's. Actually not that many ccTLDs use BGP anycast anyway.... I wish our company had monopoly for some Internet services or even monopoly for ccTLD registration - we would not care and spend $$ for set-up and additional monthly expenses by running anycast based DNS service either. ;) Unfortunately, we need to compete in business.... Sincerely, Greg At 17:04 2007.08.08.÷, David Conrad wrote:
Hi,
On Aug 8, 2007, at 12:38 PM, Greg L. wrote:
I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit...
The term "overkill" comes to mind. How many name servers does one actually need (anycast or not), particularly given the concept of caching?
The rules for IPv6 anycast allocations must be not that strict in the future... why? The address space will be more than enough, the router HW will be more powerful to handle large routing tables ...
While router hardware will undoubtedly be more powerful, the question of whether or not BGP will be able to converge with everybody and their great aunt having PI space is still open. Then there is the question of whether or not people will be happy with the O(10) ISPs capable of affording the hardware/power/cooling of the future DFZ routers (have you priced top-end routers recently?).
This proposal seems a bit on the extreme side to me.
Rgds, -drc
On Tue, 7 Aug 2007, Greg L. wrote:
I think that the PI /24 block should be assigned only to UDP related services as RFC suggests, however, I have yet to see the successful implementation of TCP data, state... replication in case one router withdraws BGP announcement of the /24 prefix.
As I have stated before, there are TCP based services (IRC) that already today use /24 PIs for anycast. No, they do not handle state. -- Mikael Abrahamsson email: swmike@swm.pp.se
As I have stated before, there are TCP based services (IRC) that already today use /24 PIs for anycast. No, they do not handle state.
and this statement was true ten years ago randy
On Wed, 8 Aug 2007, Randy Bush wrote:
As I have stated before, there are TCP based services (IRC) that already today use /24 PIs for anycast. No, they do not handle state.
and this statement was true ten years ago
why isn't it true anymore? Afaik those irc-services mention above are still operative. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
As I have stated before, there are TCP based services (IRC) that already today use /24 PIs for anycast. No, they do not handle state. and this statement was true ten years ago why isn't it true anymore? Afaik those irc-services mention above are still operative.
i did not mean to imply it was not still true. merely wishing to point out this is old old old; well, maybe only two olds. randy
participants (12)
-
David Conrad -
Gert Doering -
Greg L. -
Johann Gutauer -
Jørgen Hovland -
Leo Vegoda -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Nick Hilliard -
Randy Bush -
Roger Jorgensen -
Wilfried Woeber, UniVie/ACOnet