This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
- Previous message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
- Next message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jørgen Hovland
jorgen at hovland.cx
Sun Nov 13 15:20:31 CET 2005
-----Original Message----- From: Hans Petter Holen [mailto:hph at oslo.net] Sent: 13. november 2005 00:30 >What if I want to plan for more disasters than that ? Like MCI going out >of business? Hi, If you honestly believe that all 11 internet service providers which you are running your nameservers with (these 11 also run anycast and have multiple servers each) at the exact same time will go bankrupt and shutdown their network at around the same time then I don't think it is the nameservers we should worry about but the internet itself. >I guess I could agree with MCI to place some servers with their IP >addresses outside their network and agree with other providers to carry >my more specific routes. In order to have universal access and plan for >any network failure I would have to sign such agreement with all ISPs. > Will it not satisfy your needs placing 200 servers at 100 (numbers randomly selected) MCI locations world wide using IP space assigned by MCIs /32? Or is this discussion simply about the fact that the /32 prefix is not yours and you want to use your "own"? Take the following: 1 server at ISP x in London. /32 announced by ISP x's ASN. Your ip is assigned from this /32. 1 server at ISP x in Amsterdam. /32 announced by ISP x's ASN. Your ip is assigned from this /32. and 1 server at ISP g in London. /32 announced by your ASN through ISP g. It is your /32 1 server at ISP k in Amsterdam. /32 announced by your ASN through ISP k. It is your /32 What is really the difference here? Yes, ISP x, g or k can go bankrupt so you loose that redundancy in the first scenario. Any others? I can't think of any. Either way, there is no difference here network wise? You get exactly the same reachability/redundancy. So, should we alter the address policy because ISP x can go bankrupt and we need redundancy for that? You still have 10 more ISPs you have placed your servers at if you use all 11 IPs. >This could be a business idea for somebody: to set up an "anycast >registry" - sign agreement with all the major ISPs to not aggregate my >addresses. Then I could offer a guaranteed minimum routability for >thoose prefixes. > For medium/large operators that wouldn't make any sense at all since they already have a global network and can do fully redundant anycasting anytime with any IP address. For smaller ones it might. Conclusion: I am against a policy that would let LIRs receive prefixes from RIRs when the intention is to use the prefix for anycast. I have hopefully shown that you don't need a dedicated prefix for that. It is a bad hack to the existing solution and as I see it, would give the same benefits. This bad hack is one thing. I am sure everyone can agree on that it is impossible to decide whom and what services should be granted anycast prefixes if it was accepted. The only solution would be to permit everyone or have some rule saying "you must have more than N anycast servers at Y locations" which basically again means that everyone can and will get a prefix. I am not against 42 billion prefixes in dfz. I am sure we will get there eventually:) I am however against the ones that don't make any sense. Cheers, Joergen Hovland
- Previous message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
- Next message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]