PI for Not-DNS Anycast.
Hi, Can I get the community's thoughts on this, please .. I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made. What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ? Many thanks Andy
On 12 Jun 2007, at 22:58, Andy Davidson wrote:
Hi,
Can I get the community's thoughts on this, please ..
I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made.
What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ?
They could also state their case in this wg. Sounds far more reasonable. Joao Damas
On 12 Jun 2007, at 22:23, Joao Damas wrote:
I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made. They could also state their case in this wg. Sounds far more reasonable.
I disagree; its not reasonable for someone to have to state their case for why they need resources on a -wg mailing list. A sponsoring LIR should perform the function of deciding whether an application is appropriate. I'm simply suggesting that there's a hole in current policy (or is there ? Does this resource requirement get covered by 'PI needed to multihome'), that we can look to fill with this real world example. Andy
On 13 Jun 2007, at 09:08, Andy Davidson wrote:
On 12 Jun 2007, at 22:23, Joao Damas wrote:
I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made. They could also state their case in this wg. Sounds far more reasonable.
I disagree; its not reasonable for someone to have to state their case for why they need resources on a -wg mailing list. A sponsoring LIR should perform the function of deciding whether an application is appropriate.
Policy is dynamic. If the LIR can't determine whether a request fits current policy or if it doesn't but the LIR would like to evolve policy so that it does, then the discussion needs to take place in the wg.
I'm simply suggesting that there's a hole in current policy (or is there ? Does this resource requirement get covered by 'PI needed to multihome'), that we can look to fill with this real world example.
A real world example, needs a real world *specific* example, so provide details of the technical requirements for discussion. Does the proposed use actually work in the real world? Has it been tested, etc? People around here are reasonable. Everyone wants to get their business to work, but the frame for discussion is a technical one, not a marketing one. Joao Damas
Hi, On Wed, Jun 13, 2007 at 08:08:49AM +0100, Andy Davidson wrote:
I'm simply suggesting that there's a hole in current policy (or is there ? Does this resource requirement get covered by 'PI needed to multihome'), that we can look to fill with this real world example.
The current policy doesn't permit assignment of "PI for generic anycast" - mainly because nobody has stood up and said "we plan do to do *this*, and we plan to do it via anycast, and the current policy doesn't work for us!" yet. "Someone might want to use it some day" is *not* a good argument for making policy. 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, Andy Davidson wrote:
Hi,
Can I get the community's thoughts on this, please ..
I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made.
What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ?
during the first round of discussion on http://www.ripe.net/ripe/policies/proposals/2007-02.html some people already raised their voice about "other anycast services, not being DNS" (see mailinglist archives). The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either. ==> Currently it doesn't look like there is a need to discuss this as long as noone needs it because all this in only theoretically - is it?. If you have a concrete idea about another setup not related to DNS where Anycast is very helpful or needed, feel free to create another policy proposal which deals with it. If you only want to "try to deploy" like you write, there is http://www.ripe.net/ripe/docs/ipv4-policies.html#8 and http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments already. One can play with that and develop requirements for a new Anycast policy based on the results. ...my 0.02EUR - please don't shoot me if i forgot about some shiny new Anycast solution for some technique that actually already exists -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On 12 Jun 2007, at 22:54, Sascha Lenz wrote:
Andy Davidson wrote:
What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ? The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either.
Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now. Andy
Andy Davidson schrieb:
On 12 Jun 2007, at 22:54, Sascha Lenz wrote:
Andy Davidson wrote:
What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ? The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either.
Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now.
that still sounds like an experiment for a new protocol - then follow my suggestion - get them an experiemental assignment. If it works out, suggest a policy. There is no real "legal" way to help you out with the current policies. I don't assume you can justify >250 IPs to get the customer a valid, internet-routable /24-or-smaller assignment (neither PA nor PI since the rules apply to both), and since i strongly hope that it is safe to assume that your customer also developed that for IPv6, you're busted here in any way (no PI assigments in RIPE-land, an additional /48 PA just for that probably not justifyable and probably not really routable worldwide...). OTOH - If you can justify all that amount of address space according to the current policies, you don't have a problem, since the RIRs are not about routing. You don't need their consent to deploy anycast. You just need to follow the policies to get the address space you need. In case of Anycast-DNS the problem is, that you usually only need two IPs - the DNS server and a gateway, which doesn't justify more than a /30 or so :-) Hence, the special policy for Anycast DNS. Due to lack of any real information i'd say ==> Experiment, in my eyes. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On 13 Jun 2007, at 12:21am, Sascha Lenz wrote: [...]
Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now.
that still sounds like an experiment for a new protocol - then follow my suggestion - get them an experiemental assignment. If it works out, suggest a policy.
That only works if the experiment is for a non-commercial service: "Resources issued must not be used for commercial purposes during or following the conclusion of the experiment." If the service is commercial then it could not benefit from this kind of assignment. If the fees aren't a problem then the easiest way to get the address space might be to sign up as an LIR, get the minimum allocation and break it up. It's not the most elegant solution but it should work. That being said, it would be nice to have a policy that didn't encourage people to do that sort of thing. Regards, -- Leo Vegoda IANA Numbers Liaison
Hi, Leo Vegoda wrote:
On 13 Jun 2007, at 12:21am, Sascha Lenz wrote:
[...]
Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now.
that still sounds like an experiment for a new protocol - then follow my suggestion - get them an experiemental assignment. If it works out, suggest a policy.
That only works if the experiment is for a non-commercial service:
"Resources issued must not be used for commercial purposes during or following the conclusion of the experiment."
If the service is commercial then it could not benefit from this kind of assignment.
this is somewhat implicit with "experiment". He wrote "they want to try" - that doesn't sound like anything commercial to me, or probably i'm misguided and it is a fact that todays companies use their customers as beta-testers on a regular basis? ;-) If he'd wrote that they had a *REAL* product and they want to *SELL* it, i wouldn't have come up with the experimental pathway in the first place.
If the fees aren't a problem then the easiest way to get the address space might be to sign up as an LIR, get the minimum allocation and break it up. It's not the most elegant solution but it should work.
*purr* That's quite a customer-friendly rule-bending in my eyes - it doesn't solve the general "how to justify the size of an assignment needed for routing" issue. They only "half-way right" solution to this in my head sounds like becoming LIR and dedicating a sub-allocation of the PA space you get for Anycast announcement. This way you can seperately announce the Sub-Allocation, and have no problems justifying a routable *assignment* The actual assignment within the sub-allocation can be a /29 then or whatever you really need for the Anycast setup. ...doesn't really sound appealing for me though.
That being said, it would be nice to have a policy that didn't encourage people to do that sort of thing.
Correct. Like i pointed out, if there is a *concrete* need for that, i'm more than happy to have yet another policy on this. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On 13 Jun 2007, at 3:09pm, Sascha Lenz wrote: [...]
If the fees aren't a problem then the easiest way to get the address space might be to sign up as an LIR, get the minimum allocation and break it up. It's not the most elegant solution but it should work.
*purr* That's quite a customer-friendly rule-bending in my eyes - it doesn't solve the general "how to justify the size of an assignment needed for routing" issue.
They only "half-way right" solution to this in my head sounds like becoming LIR and dedicating a sub-allocation of the PA space you get for Anycast announcement. This way you can seperately announce the Sub-Allocation, and have no problems justifying a routable *assignment* The actual assignment within the sub-allocation can be a /29 then or whatever you really need for the Anycast setup. ...doesn't really sound appealing for me though.
Yes, routes could be shorter prefixes than assignments. It's certainly not ideal and it probably means the LIR would never qualify for an additional allocation but it would fix a short term problem while there is no policy meeting this need. Regards, -- Leo Vegoda IANA Numbers Liaison
Sascha and all, Well it's clear that ICANN is and has been using consumers as beta testers for some time. So selling nonsense should come as no suprise iregardless of being "Experimental" or not. Sascha Lenz wrote:
Hi,
Leo Vegoda wrote:
On 13 Jun 2007, at 12:21am, Sascha Lenz wrote:
[...]
Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now.
that still sounds like an experiment for a new protocol - then follow my suggestion - get them an experiemental assignment. If it works out, suggest a policy.
That only works if the experiment is for a non-commercial service:
"Resources issued must not be used for commercial purposes during or following the conclusion of the experiment."
If the service is commercial then it could not benefit from this kind of assignment.
this is somewhat implicit with "experiment". He wrote "they want to try" - that doesn't sound like anything commercial to me, or probably i'm misguided and it is a fact that todays companies use their customers as beta-testers on a regular basis? ;-) If he'd wrote that they had a *REAL* product and they want to *SELL* it, i wouldn't have come up with the experimental pathway in the first place.
If the fees aren't a problem then the easiest way to get the address space might be to sign up as an LIR, get the minimum allocation and break it up. It's not the most elegant solution but it should work.
*purr* That's quite a customer-friendly rule-bending in my eyes - it doesn't solve the general "how to justify the size of an assignment needed for routing" issue.
They only "half-way right" solution to this in my head sounds like becoming LIR and dedicating a sub-allocation of the PA space you get for Anycast announcement. This way you can seperately announce the Sub-Allocation, and have no problems justifying a routable *assignment* The actual assignment within the sub-allocation can be a /29 then or whatever you really need for the Anycast setup. ...doesn't really sound appealing for me though.
That being said, it would be nice to have a policy that didn't encourage people to do that sort of thing.
Correct. Like i pointed out, if there is a *concrete* need for that, i'm more than happy to have yet another policy on this.
-- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827
Hi Andy,
The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either.
Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now.
Can you give more details of how this works with anycast? I am interested in examples of non-DNS anycast applications. In the past there have been questions about which protocols/applications other than DNS can benefit from anycasting, and you seem to be the first with a concrete example. Thanks, Sander.
On Wed, 13 Jun 2007, Sander Steffann wrote:
Can you give more details of how this works with anycast? I am interested in examples of non-DNS anycast applications. In the past there have been questions about which protocols/applications other than DNS can benefit from anycasting, and you seem to be the first with a concrete example.
IRC uses a single TCP session and several IRC networks have deployed anycast as a way to limit amount of clients that can potentially ddos a single server. It seems to routing subsystem is stable enough for most users that even long lived TCP sessions as IRC (that might be up for weeks) work well with anycast. It works best with regionally limited announcements though, as these tend to be more stable (direct peering relationships between ISPs). -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi, On Wed, Jun 13, 2007 at 10:53:01AM +0200, Mikael Abrahamsson wrote:
IRC uses a single TCP session and several IRC networks have deployed anycast as a way to limit amount of clients that can potentially ddos a single server.
Can you point me to some documentation for that? Or some prefixes that have been used for anycasting IRC servers? I'm really curious how well that works. 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
On Thu, 14 Jun 2007, Gert Doering wrote:
Hi,
On Wed, Jun 13, 2007 at 10:53:01AM +0200, Mikael Abrahamsson wrote:
IRC uses a single TCP session and several IRC networks have deployed anycast as a way to limit amount of clients that can potentially ddos a single server.
Can you point me to some documentation for that? Or some prefixes that have been used for anycasting IRC servers?
I'm really curious how well that works.
194.68.45.0/24. Afaik there are no official documentation. I ran an EFnet irc-server off of a similar /24 for a couple of years and it worked very well. We only announced it to peering partners in scandinavia though, so it was quite limited in announcement. Solved the ddos problem very nicely back then, though. What you cannot reach you cannot ddos. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi, On Thu, Jun 14, 2007 at 04:16:06PM +0200, Mikael Abrahamsson wrote:
Solved the ddos problem very nicely back then, though. What you cannot reach you cannot ddos.
But that's not "anycast"... - in my book, anycast is "the same prefix is announced in multiple locations" (which does help against DoS), not "the prefix isn't visible world wide"...? 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
On Thu, 14 Jun 2007, Gert Doering wrote:
But that's not "anycast"... - in my book, anycast is "the same prefix is announced in multiple locations" (which does help against DoS), not "the prefix isn't visible world wide"...?
I never said it was "anycast". I called it "limitcast". DALnet announces the same prefix in several places in an identical fashion as the one I described. So no, it's not anycast as it's not globally reachable. So they have a lot of servers located at the same IP adress in different geographical locations, and depending on which one is closest to you, you'll reach it. There is no guarantee that you'll reach one of the anycasted ones though, as the prefix is not globally reachable. As far as I know there is no name for this, but personally I refer to it as "limitcast". -- Mikael Abrahamsson email: swmike@swm.pp.se
* Gert Doering wrote:
But that's not "anycast"... - in my book, anycast is "the same prefix is announced in multiple locations" (which does help against DoS), not "the prefix isn't visible world wide"...?
If the (already managed) areas of visible prefixes do not overlap. there is no reason for not announcing the same prefix in all those areas.
On Thu, 14 Jun 2007, Gert Doering wrote:
Hi,
On Wed, Jun 13, 2007 at 10:53:01AM +0200, Mikael Abrahamsson wrote:
IRC uses a single TCP session and several IRC networks have deployed anycast as a way to limit amount of clients that can potentially ddos a single server.
Can you point me to some documentation for that? Or some prefixes that have been used for anycasting IRC servers?
I'm really curious how well that works.
it work very well, and have a look at inetnum: 194.68.45.0 - 194.68.45.255 netname: DALNET descr: DALnet unrouted servers -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
On Tue, 12 Jun 2007, Sascha Lenz wrote:
The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either.
This is widely used for IRC servers that are prime DDoS targets, either as "anycast" or something that might be called "limitcast", ie a prefix that is only reachable by part of the internet to limit the amount of DDoS drones that can actually send traffic to the prefix in question. -- Mikael Abrahamsson email: swmike@swm.pp.se
some people already raised their voice about "other anycast services, not being DNS" (see mailinglist archives). The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either.
I believe that I did give such an example when we discussed this on or about the 10th of May this year. IPv4 Anycast works with any application and any protocol which uses a short-lived connection to serve up information from a relatively static database which has been replicated to many locations. DNS is an example of such an application but not the only possibility. LDAP services could be anycast. Plain old HTTP sites serving static data over short-lived connections can also be anycast. People can design protocols to be anycast-friendly. For instance a long-lived file transfer where missing or delayed packets result in the client sending a NACK, could be done using UDP so that any server in the anycast group would respond to the NACK with the correct data packet. And the protocol would continue to send at least a few packets after not receiving an ACK. Just because some people don't have the imagination to see the possibilities does not mean that RIPE should make restrictive policies that limit innovation in Europe.
==> Currently it doesn't look like there is a need to discuss this as long as noone needs it because all this in only theoretically - is it?.
We make policy BEFORE handing out resources. Therefore, the use of the resources has to be somewhat theoretical at the time the policy is made. The current IPv4 anycast policy requires applicants to wast over 99% of their allocation at a time when we are dangerously close to IPv4 exhaustion. This is negligent and we need to correct this. IPv4 anycast allocations should be tied to having a distributed infrastructure in many different locations, not to the use of a specific protocol or specific port number. We should encourage organizations who have IPv4 anycast allocations to offer IPv4 anycast hosting services using their anycast topology. That way we can reduce the waste level, possibly down to zero. --Michael Dillon
Hi, michael.dillon@bt.com wrote:
some people already raised their voice about "other anycast services, not being DNS" (see mailinglist archives). The problem is, noone came up with some concrete idea what that might be. You obviously don't have an idea about some concrete example either.
I believe that I did give such an example when we discussed this on or about the 10th of May this year. IPv4 Anycast works with any application
my apologies if i missed it.
and any protocol which uses a short-lived connection to serve up information from a relatively static database which has been replicated to many locations. DNS is an example of such an application but not the only possibility. LDAP services could be anycast. Plain old HTTP sites ^^^^^ serving static data over short-lived connections can also be anycast. ^^^ People can design protocols to be anycast-friendly. For instance a ^^^ long-lived file transfer where missing or delayed packets result in the client sending a NACK, could be done using UDP so that any server in the anycast group would respond to the NACK with the correct data packet. And the protocol would continue to send at least a few packets after not receiving an ACK.
Just because some people don't have the imagination to see the possibilities does not mean that RIPE should make restrictive policies that limit innovation in Europe.
I still don't see a point for that. Do you have an implementation? (besides IRC :-) You can develop much, but as long as it's not there, why the need for a policy on that? Do we really want a very very vague policy? Last time i checked, i was told that RIPE NCC doesn't like vague policies. Again, do you have a real world example? Why isn't the policy about experimental assignments, which is there for IPv4 and IPv6 not enough to get the development started?
==> Currently it doesn't look like there is a need to discuss this as long as noone needs it because all this in only theoretically - is it?.
We make policy BEFORE handing out resources. Therefore, the use of the
..soo in your eyes, the ULA-C policy proposal was timed right? :-)
resources has to be somewhat theoretical at the time the policy is made. The current IPv4 anycast policy requires applicants to wast over 99% of their allocation at a time when we are dangerously close to IPv4 exhaustion. This is negligent and we need to correct this. IPv4 anycast allocations should be tied to having a distributed infrastructure in many different locations, not to the use of a specific protocol or specific port number. We should encourage organizations who have IPv4 anycast allocations to offer IPv4 anycast hosting services using their anycast topology. That way we can reduce the waste level, possibly down to zero.
OK, i think i need another .. say two /23s and /32s for Anycast usage, i MIGHT deploy it someday in the future, PROBABLY i will anycast my LDAP servers, EVENTUALLY even my HTTP servers and oh yes i do run an IRC Server... and i have some file-transfer protocol in the back of my head that implements anycast, i will DEVELOP that soon, but i need anycast space now so i can test it, i'm not happy with an experimental assignment because i will sell the services right away during my tests! ... sounds ridiculous to me, but probably i'm not in a good mood today since it's Microsoft Patchday. ==> If someone puts up a policy proposal, i'm happy to think about it again. Please don't misunderstand me, but i'm not fond of long theoratical discussions without much outcome. Someone who thinks we need an Any-Anycast policy, please make up a draft! Get the process going so that we will have a policy in place soon. I completely share the opinion that innovation shouldn't be hindered just because i don't see the point here. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
You can develop much, but as long as it's not there, why the need for a policy on that? Do we really want a very very vague policy? Last time i checked, i was told that RIPE NCC doesn't like vague policies.
Very very vague policies are bad. But policies which specify too much irrelevant detail are also bad. The current IPv4 Anycast policy is bad because it says that some DNS servers are special and deserve to have their own PI block without any of the normal technical justification. Also, these special DNS servers are exempt from the usage rules and are allowed to waste over 99% of their block. A good policy would leave DNS out of the criteria because DNS isn't special. If an organization can show that they have many geographically diverse hosting sites where they will host servers using IPv4 Anycast, then we have something similar to the technical justification that other IPv4 users must provide. In addition, we could require these organizations to have a plan for using a reasonable percentage of their PI block within the first year, perhaps 25%. This would mean that they have to do one of two things: 1) Find other DNS providers that want to use IPv4 Anycast and sell them hosting services. 2) Find people who want to pay for IPv4 Anycast hosting services for some other application. Maybe commercial. Maybe experimental. RIPE normally does not care what end users do on the Internet as long as they build real networks and connect real hosts. Doesn't that sound a lot like a normal LIR/ISP who gets a PI allocation and then sells Internet access services to other companies? IPv4 Anycast is a little bit special and does deserve a policy that is tailored to the TECHNICAL REQUIREMENTS OF IMPLEMENTING IPv4 ANYCAST, but it does not deserve a restrictive policy that is anticompetitive and forces companies to lie and cheat RIPE in order to get a PI block. RIPE's current policy treats IPv4 Anycast as a second class citizen unless it is used by the in-group who run DNS servers.
Again, do you have a real world example? Why isn't the policy about experimental assignments, which is there for IPv4 and IPv6 not enough to get the development started?
Fixing the IPv4 Anycast policy does not prevent you from proposing a good experimental use policy or proposing changes to the IPv6 policies. We can do all of these things at the same time in separate policy proposals.
We make policy BEFORE handing out resources. Therefore, the use of the
..soo in your eyes, the ULA-C policy proposal was timed right? :-)
No because ULA-C resources do not exist. IPv4 Anycast has been described in RFCs since at least 1993. Check RFC 1546 for the first one that I know of. Also, IPv4 Anycast is mentioned in RFC 3068 where it is used as an address for 6to4 Relay Service. So DNS is not the only IPv4 Anycast application that has been currently implemented. It also exists for 6to4 relay. IPv4 Anycast is an old technology (if 14 years is old) which can be applied to a wide range of applications. We should not be blocking the development of such applications by forcing developers to work their way through the policy process in order to simply get a single /32 address. If we had a rational IPv4 Anycast policy, then some service providers with geographically distributed data centers would get an IPv4 Anycast /24 from RIPE and offer /32's to customer who host their IPv4 Anycast application in their data center.
OK, i think i need another .. say two /23s and /32s for Anycast usage, i MIGHT deploy it someday in the future,
Go sign a contract with an Anycast hosting company and pay their monthly fees. I don't care if you ever get your application functioning and RIPE doesn't care either. As long as you have some hosts connected to the Internet in the Anycast ISP hosting centers, they will give you a fully justified /32 from their /24. --Michael Dillon
Andy Davidson wrote:
What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ?
I haven't been doing much in this world for a while, but I think that PI space is still the only thing that fulfills the requirement for organisations who wish to establish VPN (IPsec) connections between themselves (as a non BGP/LIR type company) and others. You cannot use PA space as that is not "yours" and cannot be in anyway guarenteed to be around longer than your contract with your ISP (if that) and 1918 space is no good as the RFC cleary states it is not for this kind of thing. Did anything ever come of "solving" this problem since I last mentioned is around 2001 ? First person who says that renumbering, especially between N independent large corporates is feasible should - and I have said this since the 90s - get off the drugs and enter the real world. Peter
Hi, I think Anycast should be just an extra issue for getting a "regular" PI, and that PI should be not less than /24. Why not less than /24? Because of less size networks not routed in global Internet. Of course, we can do policies whatever we want, thinking about conservation, but people will have to lie to RIPE NCC to get really useful block (or even got less size block, spend money and time, and have to drop it because of unable to provide service). By the way, what is current anycast projects' behavior now? Getting a "regular" PI? Getting more specific from somebody? Andy Davidson wrote:
Hi,
Can I get the community's thoughts on this, please ..
I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made.
What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ?
Many thanks Andy
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
participants (13)
-
Andy Davidson -
Gert Doering -
Jeff Williams -
Joao Damas -
Leo Vegoda -
Lutz Donnerhacke -
Max Tulyev -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Peter Galbavy -
Roger Jorgensen -
Sander Steffann -
Sascha Lenz