From randy at psg.com Tue Mar 1 02:25:15 2005 From: randy at psg.com (Randy Bush) Date: Tue, 1 Mar 2005 10:25:15 +0900 Subject: [address-policy-wg] IPv6 access to K-root References: <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228140656.GA19221@srv01.cluenet.de> Message-ID: <16931.50299.305314.272267@roam.psg.com> > ==> Large scale IPv6 adoption: Full Stop. and when is non-negligible even partial start? From tim.streater at dante.org.uk Tue Mar 1 18:31:44 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Tue, 01 Mar 2005 17:31:44 +0000 Subject: [address-policy-wg] IPv6 access to K-root Message-ID: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> On Fri, 25 Feb 2005 21:00:05 +0100, Jeroen Massar wrote: >If you say they are lying, then complain to RIPE NCC that they are doing >their jobs wrongly. Apparently everybody who has gotten an allocation up >to now have been able to reason that they need the allocation under the >current policies. If you are not able to do so, though luck, you most >likely don't need it in the first place then. Sure they lie. I went on a BGP course a couple of years ago, and the instructor said that in his experience most people did because that's the only way to get what you need from RIPE. Current policies certainly don't fit us, for example. Looking in ripe-267, I see that in 5.1.1 there are four criteria for getting v6 space: 1) be an LIR - OK fine, we're an LIR. 2) not be an End Site - OK we're not. 3) plan to provide IPv6 connectivity to organisations - yes, we will certainly do that - to which it will assign /48s etc etc - no, we will never do that as all our customers are LIRs. 4) have a plan for making at least 200 /48 assignments to other organisations etc etc - no, we will never assign such space as all our customers have their own already. We manage one network (GEANT) for which we have a /32. There is another network (EUMEDCONNECT) which we manage at present, but in two years we are expecting that the connected NRENs will set up their own managing entity, and the infrastructure (including address space) will be handed over to them. I managed to get PI v4 space last year for this but it seems there is no such thing as PI v6 space so unless I fib and say that we have connected 50k end users to GEANT, I don't see how I can obtain separate, routeable v6 space for EUMEDCONNECT. We're an LIR, and an ISP, but we don't fit into the nice hierarchical tree that everyone assumes exists. For v4 we have an essentially similar problem. When GEANT's predecessor network, TEN-155, was being replaced we had to argue with RIPE about getting another /21 for GEANT. Well, now we have handed back the old /21 that we used for TEN-155. But the process should be easier than that. In short, I would advocate relaxing the rules about PI space. -- Tim From iljitsch at muada.com Tue Mar 1 20:58:55 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Mar 2005 20:58:55 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> Message-ID: <888429808ff5dac7304c88ca8bcca237@muada.com> On 1-mrt-05, at 18:31, Tim Streater wrote: > 3) plan to provide IPv6 connectivity to organisations - yes, we will > certainly do that - to which it will assign /48s etc etc - no, we will > never do that as all our customers are LIRs. > 4) have a plan for making at least 200 /48 assignments to other > organisations etc etc - no, we will never assign such space as all our > customers have their own already. So what do you need IPv6 address space for apart from your own stuff? Seems to me that from an address allocation point of view, you are and endsite. > In short, I would advocate relaxing the rules about PI space. The trouble is that in IPv4 there is at least _some_ backpressure on PI because people need to qualify for a /24. In IPv6, we don't count addresses anymore, so all else being equal, MORE people would be able to get PI space. If that were to happen, we'd be in a lot of trouble. Iljitsch From iljitsch at muada.com Tue Mar 1 21:09:18 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Mar 2005 21:09:18 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228164924.GA20369@srv01.cluenet.de> References: <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> Message-ID: <20bcc57c58f2523a9836d06cd3d812b5@muada.com> On 28-feb-05, at 17:49, Daniel Roesen wrote: >>> You can also ask the other transit upstream to announce your /48 for >>> you. >> Mind you, I prefer to advertise myself, and, as discussed, am in the >> lucky position that my transit ISPs are reasonable. > Unfortunately this mainly leads to bad connectivity as half of the > IPv6 world filters /48. As long as your two transit ISPs accept the /48 from eachother, you'll have redundancy so this is not fatal. And if we can write up a nice document that outlines how people can filter out "remote" /48s because having those in their routing tables has no added value, while allowing "close by" /48s that help optimize traffic flow, this could work out very well. The good part is that if the uptake of this way of multihoming isn't excessive, there is no need to filter at all and we're all happy. But if it gets out of hand, people can filter without breaking connectivity. So this takes having to correctly guess the amount of multihoming in the future out of the equation. From kurtis at kurtis.pp.se Tue Mar 1 21:57:00 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 1 Mar 2005 21:57:00 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20bcc57c58f2523a9836d06cd3d812b5@muada.com> References: <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> Message-ID: <752CC0A1-8A94-11D9-94B3-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-01, at 21.09, Iljitsch van Beijnum wrote: > And if we can write up a nice document that outlines how people can > filter out "remote" /48s because having those in their routing tables > has no added value, while allowing "close by" /48s that help optimize > traffic flow, this could work out very well. > > The good part is that if the uptake of this way of multihoming isn't > excessive, there is no need to filter at all and we're all happy. But > if it gets out of hand, people can filter without breaking > connectivity. So this takes having to correctly guess the amount of > multihoming in the future out of the equation. It also have the potential to give us even more asymmetrical routing than what we have today. Which might or might not be a problem. YMMV. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiTXI6arNKXTPFCVEQJJmACgr+FQm5MF2SjqHqJMC66mw7hLFTwAnikA xvQltjWS1J6/B13KNKV9RAck =FCeo -----END PGP SIGNATURE----- From hpholen at tiscali.no Wed Mar 2 00:24:31 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 02 Mar 2005 00:24:31 +0100 Subject: [address-policy-wg] IPv6 policy of making 200 /48 assignments In-Reply-To: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> Message-ID: <4224F9AF.50704@tiscali.no> Tim Streater wrote: > We're an LIR, and an ISP, but we don't fit into the nice hierarchical > tree that everyone assumes exists. For v4 we have an essentially > similar problem. This is actually quite interesting. From the historical point of view my understanding is that the IPv6 designers in the IETF tried to enforce a very strict hierarcy in IPv6. The reasons for this was of course to limit the global routing table. This is similar to my understanding of the IPv4 policies in the ARIN region where you need to document a need for addresses. We tried that for a while in the RIPE region too - but removed this criteria again. In IPv6 the requirement for having plans to have 200 customers exists as a global compromize to make the policy acceptable in alll regions - its was a regiaonaly approved policy - but globaly coordinated. Now we are facing a review of this policy - some changes has already been made in some regions - and the question is 1) Should we change this criteria - if so - what should the new criteria be - if any at all ? (why should v4 and v6 policy differ) 2) What would the (global) consequences be of such a change ? (the policy will not be globaly coordinated any more, what about routing table implications ?) -hph From dr at cluenet.de Wed Mar 2 03:01:34 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 2 Mar 2005 03:01:34 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20bcc57c58f2523a9836d06cd3d812b5@muada.com> References: <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> Message-ID: <20050302020134.GA12231@srv01.cluenet.de> On Tue, Mar 01, 2005 at 09:09:18PM +0100, Iljitsch van Beijnum wrote: > >Unfortunately this mainly leads to bad connectivity as half of the > >IPv6 world filters /48. > > As long as your two transit ISPs accept the /48 from eachother, you'll > have redundancy so this is not fatal. I consider 15-hop AS_PATHs crossing ponds multiple times and tunnels all over etc with 500ms+ RTT quite fatal, compared to let's say 3-hop AS_PATH all native. > And if we can write up a nice document that outlines how people can > filter out "remote" /48s because having those in their routing tables > has no added value, while allowing "close by" /48s that help optimize > traffic flow, this could work out very well. No, won't. The problem operators on the net don't update filters, let alone read "nice documents" how to do things properly. And there is still: > But if it gets out of hand, people can filter without breaking > connectivity. Wrong. You cannot filter PA-more-specific-multihomer-prefixes away without risking to lose connectivity to them. If the provider aggregate has routing problems (be it interdomain or even intradomain) and your transit cloud doesn't see the more-specific prefix announced by the multihomer, you lose connectivity. Especially in the case of the aggregate falling off the sky. A site behind upstreams who filter doesn't see the aggregate anymore, and because of filtering don't see the more-specific anymore too. POOF. There goes your connectivity. You still rely on the PA provider. You don't want that. PA-more-specific-multihoming fails (as a viable solution) as soon as people (especially transits) start filtering more-specifics. And looking at the IPv6 world today, this is already the case. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gert at space.net Wed Mar 2 10:36:38 2005 From: gert at space.net (Gert Doering) Date: Wed, 2 Mar 2005 10:36:38 +0100 Subject: [address-policy-wg] IPv6 policy of making 200 /48 assignments In-Reply-To: <4224F9AF.50704@tiscali.no> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <4224F9AF.50704@tiscali.no> Message-ID: <20050302093638.GF84850@Space.Net> Hi, On Wed, Mar 02, 2005 at 12:24:31AM +0100, Hans Petter Holen wrote: > In IPv6 the requirement for having plans to have 200 customers exists as > a global compromize to make the policy acceptable in alll regions - its > was a regiaonaly approved policy - but globaly coordinated. > > Now we are facing a review of this policy - some changes has already > been made in some regions - and the question is > > 1) Should we change this criteria - if so - what should the new criteria > be - if any at all ? (why should v4 and v6 policy differ) >From the discussions in the APWG mailing list, I understand that most participants seem to be in favour of abandoning the 200-customer rule. "If you're a LIR, pay your fees, assign to 3rd parties" - that's considered sufficient to receive an allocation. We just never came around to formalize the policy change. (Time to excercise the new policy process...) > 2) What would the (global) consequences be of such a change ? (the > policy will not be globaly coordinated any more, what about routing > table implications ?) The "global policy" is already out of sync, as LACNIC has already dropped the 200-customer rule... I haven't checked the current state at ARIN and APNIC, though. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From iljitsch at muada.com Wed Mar 2 10:50:35 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Mar 2005 10:50:35 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050302020134.GA12231@srv01.cluenet.de> References: <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> Message-ID: <3a88454851eeb2313789fdbb89d3b04e@muada.com> On 2-mrt-05, at 3:01, Daniel Roesen wrote: > I consider 15-hop AS_PATHs crossing ponds multiple times and tunnels > all > over etc with 500ms+ RTT quite fatal, compared to let's say 3-hop > AS_PATH all native. [...] > The problem operators on the net don't update filters, let > alone read "nice documents" how to do things properly. [...] > You cannot filter PA-more-specific-multihomer-prefixes away > without risking to lose connectivity to them. If the provider aggregate > has routing problems (be it interdomain or even intradomain) and your > transit cloud doesn't see the more-specific prefix announced by the > multihomer, you lose connectivity. [...] It's important to separate fundamental problems that aren't fixable, or require unpleasant compromises to be fixed, from the incidental problems that can be fixed in time and with education. The ones you list all fall in the latter category, IMO. The problem with the routing table size is that when it gets out of hand, there isn't much that you can do. We all know aggregation in IPv4 could be much better than it is now but still there is nothing anyone seems to be able to do to help the situation. From jeroen at unfix.org Wed Mar 2 11:05:12 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 02 Mar 2005 11:05:12 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> Message-ID: <1109757912.17484.122.camel@firenze.zurich.ibm.com> On Tue, 2005-03-01 at 17:31 +0000, Tim Streater wrote: >On Fri, 25 Feb 2005 21:00:05 +0100, Jeroen Massar wrote: > >>If you say they are lying, then complain to RIPE NCC that they are doing >>their jobs wrongly. Apparently everybody who has gotten an allocation up >>to now have been able to reason that they need the allocation under the >>current policies. If you are not able to do so, though luck, you most >>likely don't need it in the first place then. > >Sure they lie. I went on a BGP course a couple of years ago, and the instructor said that in his experience most people did because that's the only way to get what you need from RIPE. Current policies certainly don't fit us, for example. Looking in ripe-267, I see that in 5.1.1 there are four criteria for getting v6 space: > >1) be an LIR - OK fine, we're an LIR. > >2) not be an End Site - OK we're not. > >3) plan to provide IPv6 connectivity to organisations - yes, we will certainly do that - to which it will assign /48s etc etc - no, we will never do that as all our customers are LIRs. > >4) have a plan for making at least 200 /48 assignments to other organisations etc etc - no, we will never assign such space as all our customers have their own already. According to the above, either 4 is false or 2 is false and you are simply an endsite. Might sound harsh, but that is it... at the moment... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From hpholen at tiscali.no Wed Mar 2 11:17:58 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 02 Mar 2005 11:17:58 +0100 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <1109757912.17484.122.camel@firenze.zurich.ibm.com> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> Message-ID: <422592D6.4030304@tiscali.no> Jeroen Massar wrote: >On Tue, 2005-03-01 at 17:31 +0000, Tim Streater wrote: > > >> 1) be an LIR - OK fine, we're an LIR. >> >>2) not be an End Site - OK we're not. >> >>3) plan to provide IPv6 connectivity to organisations - yes, we will certainly do that - to which it will assign /48s etc etc - no, we will never do that as all our customers are LIRs. >> >>4) have a plan for making at least 200 /48 assignments to other organisations etc etc - no, we will never assign such space as all our customers have their own already. >> >> > >According to the above, either 4 is false or 2 is false and you are >simply an endsite. Might sound harsh, but that is it... at the moment... > > Whait if I am (mainly) anIPv6 transit provider with 201 customers - all beeing LIR on their own: - I cannot get address space from my upstream because I have none or several depending on my size and definition of "up" - I cant make a plan to assigh 200 /48s since all my customers are LIRs on their own - I am hardly an end site ? how do I get adresses under the current policy ? If I cannot, how do we modify the policy to alow me to get adresses ? This is an excellent point to show were the addressing policies puts limitations on the structure of the ISP industry unless we are careful. -hph From elmi at 4ever.de Wed Mar 2 11:27:11 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 2 Mar 2005 11:27:11 +0100 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <422592D6.4030304@tiscali.no> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> Message-ID: <20050302102711.GF32387@new.detebe.org> hpholen at tiscali.no (Hans Petter Holen) wrote: > - I cannot get address space from my upstream because I have none or > several depending on my size and definition of "up" > - I cant make a plan to assigh 200 /48s since all my customers are LIRs > on their own > - I am hardly an end site ? > > how do I get adresses under the current policy ? Maybe you qualify as an exchange point... Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From dr at cluenet.de Wed Mar 2 11:29:06 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 2 Mar 2005 11:29:06 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <3a88454851eeb2313789fdbb89d3b04e@muada.com> References: <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> Message-ID: <20050302102906.GA15885@srv01.cluenet.de> On Wed, Mar 02, 2005 at 10:50:35AM +0100, Iljitsch van Beijnum wrote: > It's important to separate fundamental problems that aren't fixable, or > require unpleasant compromises to be fixed, from the incidental > problems that can be fixed in time and with education. The ones you > list all fall in the latter category, IMO. Doing more-specific multihoming makes ONLY sense when planning to filter them at some point in time. Unfortunately at exactly this point, this scheme fails. This cannot be fixed in time and with education, this is a very fundamental problem of this approach. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jeroen at unfix.org Wed Mar 2 11:32:26 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 02 Mar 2005 11:32:26 +0100 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <422592D6.4030304@tiscali.no> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> Message-ID: <1109759546.17484.134.camel@firenze.zurich.ibm.com> On Wed, 2005-03-02 at 11:17 +0100, Hans Petter Holen wrote: >Jeroen Massar wrote: > >>On Tue, 2005-03-01 at 17:31 +0000, Tim Streater wrote: >> >> >>> 1) be an LIR - OK fine, we're an LIR. >>> >>>2) not be an End Site - OK we're not. >>> >>>3) plan to provide IPv6 connectivity to organisations - yes, we will certainly do that - to which it will assign /48s etc etc - no, we will never do that as all our customers are LIRs. >>> >>>4) have a plan for making at least 200 /48 assignments to other organisations etc etc - no, we will never assign such space as all our customers have their own already. >>> >>> >> >>According to the above, either 4 is false or 2 is false and you are >>simply an endsite. Might sound harsh, but that is it... at the moment... >> >> >Whait if I am (mainly) anIPv6 transit provider with 201 customers - all >beeing LIR on their own: >- I cannot get address space from my upstream because I have none or >several depending on my size and definition of "up" >- I cant make a plan to assigh 200 /48s since all my customers are LIRs >on their own Do these customers are LIR's because they have 200 customers themselves or because being LIR allows them to get some address space more easily? When they are endsites, that is having no other transits, they should be getting space from you and not themselves. >- I am hardly an end site ? >how do I get adresses under the current policy ? This is I assume indeed the scheme that Tim from Dante shows. And indeed this does not work under the current policy and as such that needs to be fixed.... The question boils down to: - do you require a entry in the routing table or: - do you need address space Giving a /32 to such a site would be quite some waste, as you will never use it. A /40 could be appropriate. But do you really need the entry in the routing table? >If I cannot, how do we modify the policy to alow me to get adresses ? Propose a new/addition/change to the policy that specifies this specific case, bring it forward and let people vote. If for one see why, especially in business case, you want your own address space. For that matter a micro-policy would sort of be good, but the thing is..... how much routing entries will we end up with, again as much as with IPv4? >This is an excellent point to show were the addressing policies puts >limitations on the structure of the ISP industry unless we are careful. Ack. Greets, Jeroen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From iljitsch at muada.com Wed Mar 2 11:38:50 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Mar 2005 11:38:50 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050302102906.GA15885@srv01.cluenet.de> References: <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> Message-ID: On 2-mrt-05, at 11:29, Daniel Roesen wrote: > Doing more-specific multihoming makes ONLY sense when planning to > filter > them at some point in time. Unfortunately at exactly this point, this > scheme fails. This cannot be fixed in time and with education, this is > a very fundamental problem of this approach. No, it's not. Keeping the aggregate up isn't hard to do, and all the other stuff is even easier. From dr at cluenet.de Wed Mar 2 11:45:29 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 2 Mar 2005 11:45:29 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> Message-ID: <20050302104529.GB15885@srv01.cluenet.de> On Wed, Mar 02, 2005 at 11:38:50AM +0100, Iljitsch van Beijnum wrote: > >Doing more-specific multihoming makes ONLY sense when planning to > >filter > >them at some point in time. Unfortunately at exactly this point, this > >scheme fails. This cannot be fixed in time and with education, this is > >a very fundamental problem of this approach. > > No, it's not. Keeping the aggregate up isn't hard to do, and all the > other stuff is even easier. "isn't hard to do". Yeah, I have seen vomitting horses, right in front of the pharmacy. With prescription in their mouth. What do you do against intradomain routing problems? Loops? DDoS congestion? With proper BGP multihoming you (as end site) can just withdraw your announcement via this problematic uplink. Doesn't help you with more-specific pseudomultihoming and people filtering the more-specific. Traffic to you still ends up in the problem area. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From koch at tiscali.net Wed Mar 2 12:05:12 2005 From: koch at tiscali.net (Alexander Koch) Date: Wed, 2 Mar 2005 12:05:12 +0100 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <1109759546.17484.134.camel@firenze.zurich.ibm.com> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> <1109759546.17484.134.camel@firenze.zurich.ibm.com> Message-ID: <20050302110512.GB18903@shekinah.ip.tiscali.net> On Wed, 2 March 2005 11:32:26 +0100, Jeroen Massar wrote: [..] > The question boils down to: > - do you require a entry in the routing table > or: > - do you need address space > > Giving a /32 to such a site would be quite some waste, as you will never > use it. > A /40 could be appropriate. But do you really need the entry in the > routing table? Cool. Then we as a transit provider have a problem. Well, we have a handful of customers with /48 and some /64, but that are not exactly that many... 80% of our v6 customers run BGP with their /48 or /32... Alexander From koch at tiscali.net Wed Mar 2 12:11:29 2005 From: koch at tiscali.net (Alexander Koch) Date: Wed, 2 Mar 2005 12:11:29 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> Message-ID: <20050302111129.GC18903@shekinah.ip.tiscali.net> On Wed, 2 March 2005 11:38:50 +0100, Iljitsch van Beijnum wrote: > On 2-mrt-05, at 11:29, Daniel Roesen wrote: > > >Doing more-specific multihoming makes ONLY sense when planning to > >filter > >them at some point in time. Unfortunately at exactly this point, this > >scheme fails. This cannot be fixed in time and with education, this is > >a very fundamental problem of this approach. > > No, it's not. Keeping the aggregate up isn't hard to do, and all the > other stuff is even easier. "No, it's not." - don't you think you said a little too quick? Different network, different ppl, complexity++? How many routers did you say have internationally, and at what networks did you gain experience previously? Alexander -- Alexander Koch / ako4-ripe Tiscali Int., Peering Coordination Phone +49 6103 916 480, Fax +49 6103 916 464 From iljitsch at muada.com Wed Mar 2 12:15:59 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Mar 2005 12:15:59 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050302104529.GB15885@srv01.cluenet.de> References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> <20050302104529.GB15885@srv01.cluenet.de> Message-ID: On 2-mrt-05, at 11:45, Daniel Roesen wrote: > What do you do against intradomain routing problems? Loops? DDoS > congestion? Read my book, it's all in there. > With proper BGP multihoming you (as end site) can just > withdraw your announcement via this problematic uplink. Doesn't > help you with more-specific pseudomultihoming and people filtering > the more-specific. I appreciate that having your own prefix in the global table makes lots of stuff easier, but what if everyone wants this? It just doesn't scale. As for the DoS issue, your transit ISPs can create blackhole communities so you can have them blackhole the traffic for individual /32s (if desired) when those are under attack by announcing even more specific more specifics with this community on them. From jon at lawrence.org.uk Wed Mar 2 12:29:30 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Wed, 2 Mar 2005 11:29:30 +0000 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <422592D6.4030304@tiscali.no> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> Message-ID: <200503021129.30773.jon@lawrence.org.uk> On Wednesday 02 March 2005 10:17, Hans Petter Holen wrote: > > Whait if I am (mainly) anIPv6 transit provider with 201 customers - all > beeing LIR on their own: > - I cannot get address space from my upstream because I have none or > several depending on my size and definition of "up" > - I cant make a plan to assigh 200 /48s since all my customers are LIRs > on their own > - I am hardly an end site ? > > how do I get adresses under the current policy ? > If I cannot, how do we modify the policy to alow me to get adresses ? IMHO, this is what is wrong with the current policy. It says you should 'PLAN' to assign 200 /48s it doesnot say you 'WILL' assign. In order to obey the letter of the policy you could say that you 'PLAN' to assign each of your customers a /48 - whether they use it is entirely upto them (as they've got their own allocation they would probably never use the /48 from you). This would get you an allocation and be obeying the letter of the policy. You're not strictly lying, but it is a completely pointless use of address space. Jon From jorgen at hovland.cx Wed Mar 2 12:53:24 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 2 Mar 2005 11:53:24 -0000 Subject: [address-policy-wg] IPv6 access to K-root References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> <20050302104529.GB15885@srv01.cluenet.de> Message-ID: <007601c51f1e$70fe6f90$c2401cac@jorgen> ----- Original Message ----- From: "Iljitsch van Beijnum" > On 2-mrt-05, at 11:45, Daniel Roesen wrote: > >> What do you do against intradomain routing problems? Loops? DDoS >> congestion? > > Read my book, it's all in there. > Hi I think it would be much better if you explained it instead. Some of us (just a few though) may not have read that book. >> With proper BGP multihoming you (as end site) can just >> withdraw your announcement via this problematic uplink. Doesn't >> help you with more-specific pseudomultihoming and people filtering >> the more-specific. > > I appreciate that having your own prefix in the global table makes lots of stuff easier, but what if everyone wants this? It just > doesn't scale. You seem to be too worried about the vendor implementations rather than the BGP specification which scales greatly and way beyond todays and tomorrows size of the global routing table. It doesn't affect us as the customer before no bgp vendor in the world can deliver a working BGP implementation. I am quite confident that this will never happen. As a matter of fact, I am willing to bet all my obsolete Cisco equipment on it. > > As for the DoS issue, your transit ISPs can create blackhole communities so you can have them blackhole the traffic for individual > /32s (if desired) when those are under attack by announcing even more specific more specifics with this community on them. > > It would be interesting if this could be implemented in BGP5 as a standard so you can announce more specific prefixes that is not to be routed instead of just announcing the ones that is supposed to be routed. J?rgen Hovland ENK From jeroen at unfix.org Wed Mar 2 13:26:42 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 02 Mar 2005 13:26:42 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <007601c51f1e$70fe6f90$c2401cac@jorgen> References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> <20050302104529.GB15885@srv01.cluenet.de> <007601c51f1e$70fe6f90$c2401cac@jorgen> Message-ID: <1109766403.17484.146.camel@firenze.zurich.ibm.com> On Wed, 2005-03-02 at 11:53 +0000, J?rgen Hovland wrote: >From: "Iljitsch van Beijnum" >> As for the DoS issue, your transit ISPs can create blackhole communities so you can have them blackhole the traffic for individual >> /32s (if desired) when those are under attack by announcing even more specific more specifics with this community on them. >> >> > >It would be interesting if this could be implemented in BGP5 as a standard so you can announce more specific prefixes that is not to >be routed instead of just announcing the ones that is supposed to be routed. SSUD (Source Specific Unicast Deny), the reverse of SSM in Multicast? The only issue with it is that if somebody has 200 prefixes and each prefix has 100 SSUD entry's you have 200.000 extra prefixes in the routing table... Though you could say that one is allowed to have a max of 5 SSUD's per prefix or some other limit and if the limit is hit the SSUD becomes an exclude for ::/0 or 0.0.0.0 aka anything... Unfortunately DDoS's come from botnets and botnets have more than 200 sources, read, more likely something like 200.000 or 500.000 sources, depending on the person who likes you so very much... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From jeroen at unfix.org Wed Mar 2 13:36:06 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 02 Mar 2005 13:36:06 +0100 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <20050302110512.GB18903@shekinah.ip.tiscali.net> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> <1109759546.17484.134.camel@firenze.zurich.ibm.com> <20050302110512.GB18903@shekinah.ip.tiscali.net> Message-ID: <1109766967.17484.150.camel@firenze.zurich.ibm.com> On Wed, 2005-03-02 at 12:05 +0100, Alexander Koch wrote: >On Wed, 2 March 2005 11:32:26 +0100, Jeroen Massar wrote: >[..] >> The question boils down to: >> - do you require a entry in the routing table >> or: >> - do you need address space >> >> Giving a /32 to such a site would be quite some waste, as you will never >> use it. >> A /40 could be appropriate. But do you really need the entry in the >> routing table? > >Cool. Then we as a transit provider have a problem. Well, we >have a handful of customers with /48 and some /64, but that are >not exactly that many... 80% of our v6 customers run BGP with >their /48 or /32... That is indeed a problem for such a setup. But this is a problem with the policy and the thought behind the policy than with your setup :) As such, these cases should be covered in the policy too. But Tiscali already has a very well working IPv6 connectivity and I assume that you also have the _plan_ of providing connectivity for more than 200 customers at some point in the very distant future, so actually it is not a big issue. But it is for some indeed :( Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From tim.streater at dante.org.uk Wed Mar 2 14:30:42 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Wed, 02 Mar 2005 13:30:42 +0000 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <1109759546.17484.134.camel@firenze.zurich.ibm.com> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> <1109759546.17484.134.camel@firenze.zurich.ibm.com> Message-ID: <6.2.1.2.2.20050302120632.04c95fe8@mail.dante.org.uk> At 10:32 02/03/2005, Jeroen Massar wrote: >On Wed, 2005-03-02 at 11:17 +0100, Hans Petter Holen wrote: >>Jeroen Massar wrote: >> >>>On Tue, 2005-03-01 at 17:31 +0000, Tim Streater wrote: >>> >>> >>>> 1) be an LIR - OK fine, we're an LIR. >>>> >>>>2) not be an End Site - OK we're not. >>>> >>>>3) plan to provide IPv6 connectivity to organisations - yes, we will certainly do that - to which it will assign /48s etc etc - no, we will never do that as all our customers are LIRs. >>>> >>>>4) have a plan for making at least 200 /48 assignments to other organisations etc etc - no, we will never assign such space as all our customers have their own already. >>>> >>>> >>> >>>According to the above, either 4 is false or 2 is false and you are >>>simply an endsite. Might sound harsh, but that is it... at the moment... >>> >>> >>Whait if I am (mainly) anIPv6 transit provider with 201 customers - all >>beeing LIR on their own: >>- I cannot get address space from my upstream because I have none or >>several depending on my size and definition of "up" >>- I cant make a plan to assigh 200 /48s since all my customers are LIRs >>on their own > >Do these customers are LIR's because they have 200 customers themselves or because being LIR allows them to get some address space more easily? >When they are endsites, that is having no other transits, they should be getting space from you and not themselves. In our case the customers are the NRENs of Europe so they certainly have >200 customers each. >>- I am hardly an end site ? >>how do I get adresses under the current policy ? > >This is I assume indeed the scheme that Tim from Dante shows. >And indeed this does not work under the current policy and as such that needs to be fixed.... > >The question boils down to: >- do you require a entry in the routing table >or: >- do you need address space > >Giving a /32 to such a site would be quite some waste, as you will never use it. >A /40 could be appropriate. But do you really need the entry in the routing table? If in fact all we do is assign space to the transit infrastructure, a smaller space could be sufficient. But (a) we need it to be routeable, else how can we manage/monitor it from entities outside the network (which we do), and (b) how do we get the space? Not from one of our customers, and we have no upstream. I am told that no prefix longer than /35 is routeable. >>If I cannot, how do we modify the policy to alow me to get adresses ? > >Propose a new/addition/change to the policy that specifies this specific case, bring it forward and let people vote. >If for one see why, especially in business case, you want your own address space. >For that matter a micro-policy would sort of be good, but the thing is..... how much routing entries will we end up with, again as much as with IPv4? > >>This is an excellent point to show were the addressing policies puts >>limitations on the structure of the ISP industry unless we are careful. We have PoPs from Vienna to Lisbon on a network with its own AS number. We do transit for the customers only. Everything else they can do for themselves and the customers set us up to do just what we do. With the existing policies I am not able to get v6 space for such a network. And why should not *any* group of entities decide to assemble a similar network, if they feel like it. If the v6 designers wanted to keep the routing table small, perhaps they should have gone for geographical prefixes like the phone system. -- Tim From nils at druecke.strg-alt-entf.org Wed Mar 2 14:46:09 2005 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Wed, 2 Mar 2005 08:46:09 -0500 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> Message-ID: <20050302134609.GB14394@h8000.serverkompetenz.net> On Wed, Mar 02, 2005 at 11:38:50AM +0100, Iljitsch van Beijnum wrote: > On 2-mrt-05, at 11:29, Daniel Roesen wrote: > >Doing more-specific multihoming makes ONLY sense when planning to > >filter > >them at some point in time. Unfortunately at exactly this point, this > >scheme fails. This cannot be fixed in time and with education, this is > >a very fundamental problem of this approach. > No, it's not. Keeping the aggregate up isn't hard to do, and all the > other stuff is even easier. I want a second uplink to another provider for one simple reason: I do not trust one single provider to deliver the Level of service I want. Making a backup, that still relies on the first provider to work is only of limited use. I want a backup, that also works if Provider1 loses all his peers, burns down, goes bankrupt etc. Nils -- Will trade links for food. [geklaut bei www.userfriendly.org] From nils at druecke.strg-alt-entf.org Wed Mar 2 14:54:10 2005 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Wed, 2 Mar 2005 08:54:10 -0500 Subject: [address-policy-wg] IPv6 policy of making 200 /48 assignments In-Reply-To: <20050302093638.GF84850@Space.Net> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <4224F9AF.50704@tiscali.no> <20050302093638.GF84850@Space.Net> Message-ID: <20050302135410.GC14394@h8000.serverkompetenz.net> On Wed, Mar 02, 2005 at 10:36:38AM +0100, Gert Doering wrote: > The "global policy" is already out of sync, as LACNIC has already dropped > the 200-customer rule... I haven't checked the current state at ARIN > and APNIC, though. Policy of the day bei ARIN: -----cut here----- a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) be an existing, known ISP in the ARIN region or have a plan for making at least 200 /48 assignments to other organizations within five years. -----cut here----- Quelle: http://www.arin.net/policy/index.html#six511 Nils -- Bad people are punished by societies law Good people are punished by Murphies law [From "Dead Like Me"] From iljitsch at muada.com Wed Mar 2 14:55:17 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Mar 2005 14:55:17 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050302134609.GB14394@h8000.serverkompetenz.net> References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> <20050302134609.GB14394@h8000.serverkompetenz.net> Message-ID: <3b548384c50cca02d63ab154ea58ee36@muada.com> On 2-mrt-05, at 14:46, Nils Ketelsen wrote: >> Keeping the aggregate up isn't hard to do > Making a backup, that still relies on the first provider to work is > only of > limited use. I want a backup, that also works if Provider1 loses all > his > peers, burns down, goes bankrupt etc. Another party can set up a route server at an exchange point that injects a backup route for the aggregate, or multiple ISPs can share an aggregate. The specifics aren't all that interesting, the point is that there are more ways to skin a cat than doing everything the way we always did but now with longer addresses. From iljitsch at muada.com Wed Mar 2 14:59:09 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Mar 2005 14:59:09 +0100 Subject: [address-policy-wg] Anti-DoS BGP communities In-Reply-To: <007601c51f1e$70fe6f90$c2401cac@jorgen> References: <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> <20050228164924.GA20369@srv01.cluenet.de> <20bcc57c58f2523a9836d06cd3d812b5@muada.com> <20050302020134.GA12231@srv01.cluenet.de> <3a88454851eeb2313789fdbb89d3b04e@muada.com> <20050302102906.GA15885@srv01.cluenet.de> <20050302104529.GB15885@srv01.cluenet.de> <007601c51f1e$70fe6f90$c2401cac@jorgen> Message-ID: On 2-mrt-05, at 12:53, J?rgen Hovland wrote: >>> What do you do against intradomain routing problems? Loops? DDoS >>> congestion? >> Read my book, it's all in there. > I think it would be much better if you explained it instead. Some of > us (just a few though) may not have read that book. I would assume that this information is available elsewhere too, it's not like I came up with it all on my own. But if there is any interest I'd be happy to do a tutorial at one of the next RIPE meetings. From nils at druecke.strg-alt-entf.org Wed Mar 2 15:00:54 2005 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Wed, 2 Mar 2005 09:00:54 -0500 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <422592D6.4030304@tiscali.no> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> Message-ID: <20050302140054.GD14394@h8000.serverkompetenz.net> On Wed, Mar 02, 2005 at 11:17:58AM +0100, Hans Petter Holen wrote: > Whait if I am (mainly) anIPv6 transit provider with 201 customers - all > beeing LIR on their own: > - I cannot get address space from my upstream because I have none or > several depending on my size and definition of "up" Define to have several and chose one of them to give you a /48 > - I cant make a plan to assigh 200 /48s since all my customers are LIRs > on their own > - I am hardly an end site ? According to the policy you are. > > how do I get adresses under the current policy ? PA from one of your customers^WProviders. > If I cannot, how do we modify the policy to alow me to get adresses ? Bring back PI. > This is an excellent point to show were the addressing policies puts > limitations on the structure of the ISP industry unless we are careful. This limits other endsites as well. You are as much an endsite as many other big companies. Big companies connecting more stuff then most of the ISPs out there. They will not accept a renumbering when they change their provider. Just as you do not want to renumber when your customer that gave you the PA moves somewhere else. They want multihoming that works and does not rely on the aggregate still being visible from the provider they got the PA space from. Just like you do. You are not so special ;-) Nils -- 12:23 < remex> jjFux: Warum benutzt Du Computer nicht einfach, wie andere Menschen auch? 12:24 <@jjFux> remex: ... als Wurfgescho?? Soweit habe ich meine Emotionen noch unter Kontrolle From jonl at tellnet.co.uk Wed Mar 2 11:30:48 2005 From: jonl at tellnet.co.uk (Jon Lawrence) Date: Wed, 2 Mar 2005 10:30:48 +0000 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <422592D6.4030304@tiscali.no> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> Message-ID: <200503021030.48901.jonl@tellnet.co.uk> On Wednesday 02 March 2005 10:17, Hans Petter Holen wrote: > > Whait if I am (mainly) anIPv6 transit provider with 201 customers - all > beeing LIR on their own: > - I cannot get address space from my upstream because I have none or > several depending on my size and definition of "up" > - I cant make a plan to assigh 200 /48s since all my customers are LIRs > on their own > - I am hardly an end site ? > > how do I get adresses under the current policy ? > If I cannot, how do we modify the policy to alow me to get adresses ? > > This is an excellent point to show were the addressing policies puts > limitations on the structure of the ISP industry unless we are careful. > IMHO, this is what is wrong with the current policy. It says you should 'PLAN' to assign 200 /48s it doesnot say you 'WILL' assign. In order to obey the letter of the policy you could say that you 'PLAN' to assign each of your customers a /48 - whether they use it is entirely upto them (as they've got their own allocation they would probably never use the /48 from you). This would get you an allocation and be obeying the letter of the policy. You're not strictly lying, but it is a completely pointless use of address space. Jon From tim.streater at dante.org.uk Wed Mar 2 15:11:16 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Wed, 02 Mar 2005 14:11:16 +0000 Subject: [address-policy-wg] IPv6 addresses to transit-providers In-Reply-To: <200503021030.48901.jonl@tellnet.co.uk> References: <6.2.1.2.2.20050301162322.04dfe610@mail.dante.org.uk> <1109757912.17484.122.camel@firenze.zurich.ibm.com> <422592D6.4030304@tiscali.no> <200503021030.48901.jonl@tellnet.co.uk> Message-ID: <6.2.1.2.2.20050302140516.02fb3c98@mail.dante.org.uk> At 10:30 02/03/2005, Jon Lawrence wrote: >On Wednesday 02 March 2005 10:17, Hans Petter Holen wrote: >> >> Whait if I am (mainly) anIPv6 transit provider with 201 customers - all >> beeing LIR on their own: >> - I cannot get address space from my upstream because I have none or >> several depending on my size and definition of "up" >> - I cant make a plan to assigh 200 /48s since all my customers are LIRs >> on their own >> - I am hardly an end site ? >> >> how do I get adresses under the current policy ? >> If I cannot, how do we modify the policy to alow me to get adresses ? >> >> This is an excellent point to show were the addressing policies puts >> limitations on the structure of the ISP industry unless we are careful. >> >IMHO, this is what is wrong with the current policy. It says you should 'PLAN' >to assign 200 /48s it doesnot say you 'WILL' assign. >In order to obey the letter of the policy you could say that you 'PLAN' to >assign each of your customers a /48 - whether they use it is entirely upto >them (as they've got their own allocation they would probably never use >the /48 from you). >This would get you an allocation and be obeying the letter of the policy. >You're not strictly lying, but it is a completely pointless use of address >space. It's also a dopey piece of administrative b/s which has no value. Much better that the policy be designed to cover cases like this and encourage people to be honest. That way the database models reality a bit better. -- Tim From filiz at ripe.net Thu Mar 3 14:37:54 2005 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 3 Mar 2005 14:37:54 +0100 Subject: [address-policy-wg] New AS Number Block allocated to the RIPE NCC Message-ID: <20050303133754.GJ27361@x13.ripe.net> Dear Colleagues, The RIPE NCC received the AS Number Block 34816 - 35839 from the IANA in February 2005. You may want to update your records accordingly. Kind regards, -- Filiz Yilmaz RIPE NCC From hpholen at tiscali.no Fri Mar 4 20:34:53 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 04 Mar 2005 20:34:53 +0100 Subject: [address-policy-wg] Beta test of new PDP Message-ID: <4228B85D.5090908@tiscali.no> As the new policy process proposed by Rob http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html has not been finalized yet I have deceided to "beta test" the new process on new proposals received after today. The new process is a bit more structured that the previous one, and the previous one is open enough in its definition to fit the new one in this framework. Until the new process is approved and fully implmenented I'll maintain the list of proposals myself. Please let me know if you have any concerns with this approach Best Regards, Hans Petter Holen Address POlicy WG Chair From hpholen at tiscali.no Fri Mar 4 20:38:33 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 04 Mar 2005 20:38:33 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <4228B939.2020509@tiscali.no> Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th. Best Regards, Hans Petter 1.Number (assigned by the RIPE NCC) alpha 2.Policy Proposal Name: TLD Anycast Allocation Policy 3.Author a.name: Andreas Baess b.e-mail: baess at denic.de c.telephone: +49 69 27235 0 d.organisation: DENIC e.G. 4.Proposal Version: 1 5.Submission Date: 6.Suggested WG for discussion and publication: Address Policy Working Group 7.Proposal type: new 8.Policy term: renewable 9.Summary of proposal To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services. 10. Policy text a.Current: N/A b.New: "If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer." 11. Rationale: PROS A. Acceptance of DNS for special treatment Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.pdf shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications. B. Policy Harmonization Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. C. Scalability of DNS To serve the projected increase of DNS queries and to ensure sufficient network topological coverage and diversity TLD managers need to deploy an increasing number of nameservers. D. Resilience Internet has become part of the daily life and their availabilty is as important as the availability of all public services. Anycasting is currently the state-of-the-art solution to lower the impact of DDoS attacks. E. IPv6 Support As the world starts exploiting IPv6, the DNS infrastructure should support IPv6 natively. However it is not yet possible to reduce the number of nameservers in the IPv4 cloud. CONS F. Waste of Address Space Accepting a number of IPv4/24 and IPv6/32 allocations for critical network infrastructures does not align with the traditional address conservation efforts. With anycasting it is very likely that only a few addresses from the entire assignment would be used. 2. Root DNS are special, others are not RIPE document 233 dated from 24th May 2002 says: "Although it is undesirable to give special status to any IP (IPv4 or IPv6) address block, it was agreed by the community that the particular need defined in this document is the only justifiable exception to that general principle." 3. Assigning an own network prefix is just a workaround to ensure global reachability which could also be achieved by adjusting currently deployed route filter practices. Appendix I APNIC Policy (Following section is taken from http://www.apnic.net/docs/policy/add-manage-policy.html - 11.3) 11.3 Critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to receive a portable assignment: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers; * IANA; * Regional Internet Registry (RIRs); and * National Internet Registry (NIRs). Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. Registrar organisations which do not actually host the network housing the registry infrastructure, will not be eligible for an assignment under this policy. The minimum assignment made under these terms is /24. Appendix II ARIN Policy (Following section taken from http://ww2.arin.net/policy/index.html#four4) 4.4. Micro-allocation - ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. Appendix III LACNIC (Following section is taken from http://lacnic.net/policy-en.pdf) 3.3.3 Micro Allocations Micro allocation is the name given to those allocations that imply blocks smaller than /20 but always larger than or equal to /24. LACNIC can grant this type of allocation in case of projects and infrastructure for networks that are key or critical for the region, such as IXPs (Internet Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among others. In the case of IXPs or NAPs, in order to be able to apply for this type of allocation, organizations shall meet the following requirements: 1. Duly document the following aspects: 1. 1Prove by means of their bylaws their capacity of IXP or NAP. The organization shall have at least three members and an open policy in relation to the association of new members. 1. 2Submit a company structure organizational diagram. 1. 3Document the numbering plan to be implemented. 2. Provide a usage plan for the following three and six months. The rest of the applications shall be studied based on the analysis of the documentation justifying the critical and/or key aspects of the project. Organizations receiving micro allocations are not authorized to suballocate these addresses. From hpholen at tiscali.no Fri Mar 4 21:40:46 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 04 Mar 2005 21:40:46 +0100 Subject: [address-policy-wg] HD ratio policy proposal In-Reply-To: <89E8CBF169FE82408CBC2892EF204394322469@PUEXCBA0.nanterre.francetelecom.fr> References: <89E8CBF169FE82408CBC2892EF204394322469@PUEXCBA0.nanterre.francetelecom.fr> Message-ID: <4228C7CE.2070706@tiscali.no> Thanks Alain, I'll as the new PDP is not in operation yet, I'll add this to my list as #beta v1 I propose that we enter into the Discussion phase for 4 weeks from date until April 4. -hph BIDRON Alain ROSI/DAS wrote: >Dear Colleagues >Referring to the minutes of the last RIPE Policy Working Group meeting and to the action list >as updated during that meeting, I have to make a formal proposal on use of HD ratio for IPV4. >Here is this policy proposal. >In order to be consistent with the PDP Draft proposal coming from Rob Blokzijl I have used the template >provided in the new PDP proposal. >Best regards. >Alain > > >_________________________________________________________ >1. Policy Proposal Name: IPv4-HD-Ratio >2. Author > a. name: Alain Bidron > b. e-mail: alain.bidron at francetelecom.com > c. telephone: +33 1 44 44 27 75 > d. organisation: France Telecom >3. Proposal Version: V0 >4. Submission Date: 02/02/2005 >5. Suggested WG for discussion and publication: Address Policy WG >6. Proposal type: modify >7. Policy term: permanent >8. Summary of proposal: >Internet address space is managed hierarchically: >- IANA allocates space to Regional Internet Registries (RIRs). >- RIRs allocate space to Local Internet Registries (LIRs). >- LIRs assign space to End Users. > >At each level, some address space may be reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced, the overall efficiency of the address space usage decreases. > >The HD ratio (Host-Density ratio) is a way to measure address space usage [RFC 3194]. The HD ratio value can relate to a percentage of usage, which decreases as the amount of address space grows. This allows for the decreasing efficiency that occurs with more hierarchical levels. > >The HD ratio is currently used to measure IPv6 address space usage [ipv6-address-policy]. The IPv6 Address Allocation and Assignment Policy considers a block of IPv6 address space to be ?used? when its HD ratio reaches 0.80. This is a manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). > >This document proposes using the HD ratio to measure IPv4 usage. The proposed value of the HD ratio for IPv4 is 0.96. > >9. Policy text: > a. Current: "An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations." > b. New: "An LIR may receive an additional allocation when its total allocated address space usage meets the HD-Ratio value of 0.96." > >10. Rationale: > >a. Background >The current document, ?IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region? [ipv4-address-policy], considers a block of IPv4 addresses to be ?used? when 80% of the addresses within the block have been sub-allocated or assigned. This is applied to all address blocks, regardless of size. > >Current policies assume a hierarchical system of address space delegation. However, they do not make any allowance for hierarchical management within allocated address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual Points of Presence (PoPs), regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are not recognised by the current policy framework and are highly restricted by the "80% rule". As a result, managing large blocks is often difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. > >One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space. However, address management policies must also be practical in terms of how much management overhead they cause. When large amounts of address space are involved, the "80% rule" can result in more work for an LIR. > >Basing usage on the HD ratio should lead to equal levels of management overhead across the board, rather than penalising the holders of large address blocks. > >b.Impact >To see a rough estimation of the immediate impact of this proposal, an HD Ratio value of 0.96 was applied to the average amount of address space held by an LIR in the RIPE NCC Service Region. This showed that on average, LIRs would qualify for an additional allocation block when they have assigned or sub-allocated about 59% of their allocated address space. > >c.Arguments supporting the proposal. >This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries >The local Internet registries using the 80% criteria may continue to do so and will not be impacted by the new policy. >The RIPE NCC will provide support to minimise complicated calculations or administrative burden to LIRs. > >d. Arguments opposing the proposal. >This proposal will have some limited impact on IPV4 address consumption. > > > > >Appendix A. The HD ratio > > The HD ratio is calculated as follows [RFC 3194]: > > HD = log(U)/log(S) > > Where: > > S is the size of the address block concerned, and > U is the number of addresses used. > >Note: The current IPv4 policy considers addresses to be ?used? once they are assigned or sub-allocated by the LIR. > >Appendix B. Selection of HD ratio value > >We should decide an appropriate HD ratio value on a rational basis. To do this, we make certain assumptions about the number of "hidden" hierarchical levels involved in managing address blocks of various sizes. If we assume there is 80% usage at each level, we can easily calculate the overall usage. > >The following table proposes a set of hierarchical levels which we can reasonably expect within different amounts of address space. If a usage of 80% is achieved at each hierarchical level, then the overall usage will be (0.80 to the power of "n"). It is then possible to calculate HD ratio values from this value. > > Size range Level Utilisation HD ratio > (prefix) (n) (0.80**n) (calculated) > > /24 to /20 1 80% .960 to .973 > /20 to /16 1.5 72% .961 to .970 > /16 to /12 2 64% .960 to .968 > /12 to /8 2.5 57.2% .960 to .966 > /8 to /4 3 51.20% .960 to .966 > >The levels of hierarchy listed above are based on assumptions about the likely size and structure of LIRs holding address blocks of these sizes. A reasonable HD ratio value may be 0.96 (a round figure which occurs within most of these ranges) from the table above. The following table gives the usage requirements for IPv4 address blocks from /24 to /8 for this value. > > IPv4 Addresses Addresses Util% > prefix total used > > 24 256 205 80.11% > 23 512 399 77.92% > 22 1024 776 75.79% > 21 2048 1510 73.71% > 20 4096 2937 71.70% > 19 8192 5713 69.74% > 18 16384 11113 67.83% > 17 32768 21619 65.98% > 16 65536 42055 64.17% > 15 131072 81811 62.42% > 14 262144 159147 60.71% > 13 524288 309590 59.05% > 12 1048576 602249 57.43% > 11 2097152 1171560 55.86% > 10 4194304 2279048 54.34% > 9 8388608 4433455 52.85% > 8 16777216 8624444 51.41% > >Note: This table provides values for CIDR blocks, but the same calculations can be made for non-CIDR blocks. > >As an example, an LIR holding a total amount of address space equal to a /16 would be able to receive more address space when they had sub-allocated or assigned 64.17% of that space; while an LIR holding a /9 would be able to receive more space when they had sub-allocated or assigned 52.85% of their address space. > >Appendix C. References >[RFC 3194] "The Host-Density ratio for address assignment efficiency: An > update on the H ratio", A. Durand, C.Huitema, November 2001. >[ipv6-address-policy] RIPE NCC document: "IPv6 Address Allocation and > Assignment Policy" http://www.ripe.net/ripe/docs/ipv6policy.html >[ipv4-address-policy] RIPE NCC document: "IPv4 Address Allocation and > Assignment Policies for the RIPE NCC Service Region" > http://www.ripe.net/ripe/docs/ipv4-policies.html > > > From hpholen at tiscali.no Fri Mar 4 21:50:03 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 04 Mar 2005 21:50:03 +0100 Subject: [address-policy-wg] Status of open actions Message-ID: <4228C9FB.2020806@tiscali.no> Dear all, the next RIPE meeting is approaching in a couple months - It is time to review the action list. I have added the status as far as I know. http://www.ripe.net/ripe/wg/address-policy/action-list.html 47.3 Andreas B?? Anycast for ccTLD: Complete discussion through Mailing List to draft formal proposal. Ongoing - published as policy proposal #alpha 47.4 Chair AfriNIC proposal for /22 minimum allocation size: Seek final consensus through the Mailing List. completed 47.5 Chair Changing the 80% rule for IPv4 allocations: Start discussion through the Mailing List. 48.1 Chair HD Ratio for IPv4: Take discussion to the mailing list policy proposal #beta 48.2 Chair Issues seen in IPv6 Allocation requests: circulate input on the mailing list. 48.3 NCC Issues seen in IPv6 Allocation requests: Propose re-write following mailing list discussion. 49.1 Andy Furnel Draft formal proposal on removing the 200 customer requirements for IPv6 49.2 Rob Blokzijl Publish draft Policy Development process published http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html 22 Dec 2004 49.3 Working Group Continue discussion on the list of the IANA-RIR IPv6 policy 49.4 Eva Ericsson-Rabete Take discussion on Whois to the list 49.5 Alain Bidron Make a formal proposal on use of HD ratio for IPv4 policy proposal #beta From tomthorne1 at yahoo.com Thu Mar 10 15:49:30 2005 From: tomthorne1 at yahoo.com (Thomas Thorne) Date: Thu, 10 Mar 2005 06:49:30 -0800 (PST) Subject: [address-policy-wg] Registration Policy Message-ID: <20050310144930.4252.qmail@web40913.mail.yahoo.com> To Whom It May Concern: How does a company or individual "own" the .biz, .info or similar URL suffix? Is it possible to register a new one? If so, at what cost? And do you allow someone to then own and profit from it? Thank you, Tom Thorne __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From iljitsch at muada.com Fri Mar 11 09:46:37 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 11 Mar 2005 09:46:37 +0100 Subject: [address-policy-wg] Registration Policy In-Reply-To: <20050310144930.4252.qmail@web40913.mail.yahoo.com> References: <20050310144930.4252.qmail@web40913.mail.yahoo.com> Message-ID: <82f0125508d79c88a5b6713867b7a30e@muada.com> On 10-mrt-05, at 15:49, Thomas Thorne wrote: > To Whom It May Concern: > How does a company or individual "own" the .biz, .info > or similar URL suffix? They don't as such. > Is it possible to register a > new one? If so, at what cost? And do you allow someone > to then own and profit from it? The documents linked at http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm should help you get started on understanding how all of this works. From hpholen at tiscali.no Fri Mar 11 12:14:22 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 11 Mar 2005 12:14:22 +0100 Subject: [address-policy-wg] Registration Policy In-Reply-To: <20050310144930.4252.qmail@web40913.mail.yahoo.com> References: <20050310144930.4252.qmail@web40913.mail.yahoo.com> Message-ID: <42317D8E.9010305@tiscali.no> Dear Thomas, The Address Policy mailinglist deals with IP addressing policy questions not domain names. IP addresses are numeric addresses used by devices connected to the Internet. For a list of ICANN acredited registrars for domain names please refer to http://www.internic.net/ Best Regards, Hans Petter Holen Address Policy gw Chair. Thomas Thorne wrote: >To Whom It May Concern: > >How does a company or individual "own" the .biz, .info >or similar URL suffix? Is it possible to register a >new one? If so, at what cost? And do you allow someone >to then own and profit from it? > >Thank you, > >Tom Thorne > > > >__________________________________ >Do you Yahoo!? >Take Yahoo! Mail with you! Get it on your mobile phone. >http://mobile.yahoo.com/maildemo > > From kurtis at kurtis.pp.se Wed Mar 23 10:36:00 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 23 Mar 2005 10:36:00 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <4228B939.2020509@tiscali.no> References: <4228B939.2020509@tiscali.no> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-04, at 20.38, Hans Petter Holen wrote: > Dear all, > Please find enclosed a policy proposal. As per my previous message I > will "beta-test" the new PDP on this proposal. > The current proposal has been discussed previously and has now been > re-formulated after that discussion. > My proposal is to enter this proposal into the Discussion Phase with a > time line of 2 weeks ending on April 4th. I am behind on email, but better late than never.... > 9.Summary of proposal > > To enable ccTLD and gTLD nameserver operators to provide their DNS > service > using shared unicast technology, RIPE NCC is able to assign one IPv4 > and > IPv6 prefix per operator that is not likely to be filtered by common > practise for anycast-operation of their DNS services. This part troubles me. This is a significant change from current policy on guaranteed routability, and also quite a deviation from the critical infrastructure policies of the other RIRs. I would like to remove the "likely not to be filtered" from the above, or add that at no times can the RIPE NCC guarantee routability or wide reachability and acceptance of the assigned prefixes. > "If the nameserverset of a TLD without anycasting technology applied > would > not pass the IANA Administrative Procedure for Nameserver Delegation > and > Glue Data (http://www.iana.org/procedures/delegation-data.html) may > receive > dedicated network prefixes for the sole purpose of anycasting name > servers, > as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or > one > /32 IPv6 prefix per operator. The prefixes shall be tagged as > 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the > RIPE NCC > if not in use for anycast DNS any longer." I don't see why RIPE need to assign a /32 when the other regions are /48s? I would also like to add that these assignments should be made out of a single block. Also, to follow the "have you considered private address space" (or whatever the exact formulation is ) question in the PI application, I would like to require the applicant to consider using an existing anycasting service. YEs, I understand that that is a business decision, but so is accepting these prefixes by the rest of the world. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkE4h6arNKXTPFCVEQK5PwCgy2upHuiK5Odk+FyGV54UY6UXCzQAnjMA itq8rIX9z3ov1GjO4LGEc1Tn =4ibU -----END PGP SIGNATURE----- From elmi at 4ever.de Wed Mar 23 10:58:18 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 23 Mar 2005 10:58:18 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <4228B939.2020509@tiscali.no> Message-ID: <20050323095817.GD97739@new.detebe.org> Hi Kurtis, kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: > > IPv6 prefix per operator that is not likely to be filtered by common > > practise for anycast-operation of their DNS services. > > This part troubles me. This is a significant change from current policy > on guaranteed routability, and also quite a deviation from the critical > infrastructure policies of the other RIRs. I would like to remove the > "likely not to be filtered" from the above, or add that at no times can > the RIPE NCC guarantee routability or wide reachability and acceptance > of the assigned prefixes. I'd go for something like "...IPv6 prefix per operator for anycast- operation of their DNS services. While the RIPE NCC naturally cannot guarantee routability of assigned or allocated prefixes, care shall be taken to select a prefix that is less likely to be filtered than other candidates." I myself would prefer a defined range (say, a /32 block out of which /48s are allocated), but I seem to be a minority with that opinion. This range would allow operators to exclude it from their filters. > > /32 IPv6 prefix per operator. The prefixes shall be tagged as > > 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the > > RIPE NCC > > if not in use for anycast DNS any longer." > > I don't see why RIPE need to assign a /32 when the other regions are > /48s? I would also like to add that these assignments should be made > out of a single block. Joining the minority? ;-) I believe the proposal for a /32 tried to minimize the probability of being filtered. And since there's no real need not to be generous... > Also, to follow the "have you considered private address space" (or > whatever the exact formulation is ) question in the PI application, I > would like to require the applicant to consider using an existing > anycasting service. YEs, I understand that that is a business decision, > but so is accepting these prefixes by the rest of the world. Quite some "small zone" ccTLDs already use other cc/gTLDs setups, so what you're proposing is already done in the real world. If a TLD goes to the hassle of setting up, shipping, connecting, and maintaining anycast setups around the world which, if I may say so, includes quite some battles with network operators to remove the prefix from their filters, they will most probably already have considered using third party anycast services. And decided to operate the grid themselves. Cheers, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From steffann at nederland.net Wed Mar 23 11:28:18 2005 From: steffann at nederland.net (Sander Steffann) Date: Wed, 23 Mar 2005 11:28:18 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050323095817.GD97739@new.detebe.org> Message-ID: <2B1A983EDCEC3447B22632B64F72646010875E@bill.office.computel.nl> Hi, > I myself would prefer a defined range (say, a /32 block out of which > /48s are allocated), but I seem to be a minority with that opinion. I'll join that minority group :-) > Joining the minority? ;-) Indeed. Sander. From Joao_Damas at isc.org Wed Mar 23 14:39:03 2005 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 23 Mar 2005 14:39:03 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <4228B939.2020509@tiscali.no> Message-ID: <6d88bfe5ae495a7ef1291ec36f760126@isc.org> On 23 Mar, 2005, at 10:36, Kurt Erik Lindqvist wrote: > I don't see why RIPE need to assign a /32 when the other regions are > /48s? I would also like to add that these assignments should be made > out of a single block. What would the problem be with the /32, really? Counting the addresses? Howeverm, the "out of a single block" is the part that really bothers me. Putting supposedly "critical infrastructure" as it is called elsewhere in a block that makes them all share fate in the event of network "optimisations" is still a bad idea. > > Also, to follow the "have you considered private address space" (or > whatever the exact formulation is ) question in the PI application, I > would like to require the applicant to consider using an existing > anycasting service. Sounds like a good idea, actually. Joao From kurtis at kurtis.pp.se Wed Mar 23 14:54:27 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 23 Mar 2005 14:54:27 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <6d88bfe5ae495a7ef1291ec36f760126@isc.org> References: <4228B939.2020509@tiscali.no> <6d88bfe5ae495a7ef1291ec36f760126@isc.org> Message-ID: <6b6e6f0554c45971d7d5ce62d41f5610@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-23, at 14.39, Joao Damas wrote: > On 23 Mar, 2005, at 10:36, Kurt Erik Lindqvist wrote: >> I don't see why RIPE need to assign a /32 when the other regions are >> /48s? I would also like to add that these assignments should be made >> out of a single block. > > What would the problem be with the /32, really? Counting the addresses? "640k should be enough for anyone" :-) (Although Mr Gates disputes that statement ever been said here : http://www.nybooks.com/articles/15180#fn*). My main concern is that this again is contrary to the "conservation" policy which is one of the reasons we have RIRs at all... > Howeverm, the "out of a single block" is the part that really bothers > me. Putting supposedly "critical infrastructure" as it is called > elsewhere in a block that makes them all share fate in the event of > network "optimisations" is still a bad idea. Well, this can be argued the otherway around as well. We know that ISPs filter out previously unused space, and that they are not very active in updating those filters when IANA starts allocating out of new blocks. Having all in well-known block would limit that. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkF1GaarNKXTPFCVEQLi+wCfTXZHrL4u+kAvRuDB1O6mc2AJWy0AoPN1 S4yfPNG+44ZYMKm7gZ3Z0nZq =FH9m -----END PGP SIGNATURE----- From elmi at 4ever.de Wed Mar 23 15:00:08 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 23 Mar 2005 15:00:08 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <6b6e6f0554c45971d7d5ce62d41f5610@kurtis.pp.se> References: <4228B939.2020509@tiscali.no> <6d88bfe5ae495a7ef1291ec36f760126@isc.org> <6b6e6f0554c45971d7d5ce62d41f5610@kurtis.pp.se> Message-ID: <20050323140008.GL97739@new.detebe.org> kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: > > Howeverm, the "out of a single block" is the part that really bothers > > me. Putting supposedly "critical infrastructure" as it is called > > elsewhere in a block that makes them all share fate in the event of > > network "optimisations" is still a bad idea. > > Well, this can be argued the otherway around as well. We know that ISPs > filter out previously unused space, and that they are not very active > in updating those filters when IANA starts allocating out of new > blocks. Having all in well-known block would limit that. Additionally, once someone starts filtering, they will receive much more pressure than if the block contained only one piece of "critical infrastructure". As always the coin has two sides :) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From woeber at cc.univie.ac.at Wed Mar 23 14:23:20 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 23 Mar 2005 15:23:20 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <00A41344.B5D6078E.19@cc.univie.ac.at> Kurtis, >> Howeverm, the "out of a single block" is the part that really bothers >> me. Putting supposedly "critical infrastructure" as it is called >> elsewhere in a block that makes them all share fate in the event of >> network "optimisations" is still a bad idea. > >Well, this can be argued the otherway around as well. We know that ISPs >filter out previously unused space, and that they are not very active >in updating those filters when IANA starts allocating out of new >blocks. Having all in well-known block would limit that. ...wouldn't we/you/they/all have to do some filtering the "other way 'round" if all of those prefixes are contained in _one_ superblock to guard against someone/something announcing (and potentially black- holeing(sp?)) a route for that /32? >- - kurtis - Wilfried. From dr at cluenet.de Wed Mar 23 16:18:59 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 23 Mar 2005 16:18:59 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050323095817.GD97739@new.detebe.org> References: <4228B939.2020509@tiscali.no> <20050323095817.GD97739@new.detebe.org> Message-ID: <20050323151859.GA17007@srv01.cluenet.de> On Wed, Mar 23, 2005 at 10:58:18AM +0100, Elmar K. Bins wrote: > I myself would prefer a defined range (say, a /32 block out of which > /48s are allocated), but I seem to be a minority with that opinion. > This range would allow operators to exclude it from their filters. I totally agree. Derriving policy from prefix length (at least in the range up to /48) is just bogus and shouldn't be supported by issuing /32s to guarrantee routability. The folks filtering ANYTHING longer than /32 or /35 are just wrong. A /48 is far more than enough. > > I don't see why RIPE need to assign a /32 when the other regions are > > /48s? I would also like to add that these assignments should be made > > out of a single block. > > Joining the minority? ;-) I certainly do. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Joao_Damas at isc.org Wed Mar 23 17:00:44 2005 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 23 Mar 2005 17:00:44 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <6b6e6f0554c45971d7d5ce62d41f5610@kurtis.pp.se> References: <4228B939.2020509@tiscali.no> <6d88bfe5ae495a7ef1291ec36f760126@isc.org> <6b6e6f0554c45971d7d5ce62d41f5610@kurtis.pp.se> Message-ID: <659cb6cb45c866ef7a2fc5c2e6e6adfb@isc.org> On 23 Mar, 2005, at 14:54, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2005-03-23, at 14.39, Joao Damas wrote: >> On 23 Mar, 2005, at 10:36, Kurt Erik Lindqvist wrote: >>> I don't see why RIPE need to assign a /32 when the other regions are >>> /48s? I would also like to add that these assignments should be made >>> out of a single block. >> >> What would the problem be with the /32, really? Counting the >> addresses? > > "640k should be enough for anyone" :-) (Although Mr Gates disputes that > statement ever been said here : > http://www.nybooks.com/articles/15180#fn*). My main concern is that > this again is contrary to the "conservation" policy which is one of the > reasons we have RIRs at all... You really think so? Even for IPv6? For me the real value is that RIRs provide uniqueness, that is their true value. Just like a cadaster. Conservation has been an additional task that has been put on the RIRs thanks to the limitations of IPv4 ( and surely IPv6 will solve that . Was the main goal of the RIPE NCC conservation (other than through promotion of CIDR) when it came into existence? > >> Howeverm, the "out of a single block" is the part that really bothers >> me. Putting supposedly "critical infrastructure" as it is called >> elsewhere in a block that makes them all share fate in the event of >> network "optimisations" is still a bad idea. > > Well, this can be argued the otherway around as well. We know that ISPs > filter out previously unused space, and that they are not very active > in updating those filters when IANA starts allocating out of new > blocks. Having all in well-known block would limit that. > However that affects one at a time, rather than all at once. I mean if go shooting ducks I really prefer to have them all nicely bunched together so that it requires less skill, but if I am a duck I would rather make it more difficult for the hunter (or wild sniper entering the burger shop, as it may be) Joao From kurtis at kurtis.pp.se Wed Mar 23 22:08:08 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 23 Mar 2005 22:08:08 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <00A41344.B5D6078E.19@cc.univie.ac.at> References: <00A41344.B5D6078E.19@cc.univie.ac.at> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-23, at 14.23, Wilfried Woeber, UniVie/ACOnet wrote: >>> Howeverm, the "out of a single block" is the part that really bothers >>> me. Putting supposedly "critical infrastructure" as it is called >>> elsewhere in a block that makes them all share fate in the event of >>> network "optimisations" is still a bad idea. >> >> Well, this can be argued the otherway around as well. We know that >> ISPs >> filter out previously unused space, and that they are not very active >> in updating those filters when IANA starts allocating out of new >> blocks. Having all in well-known block would limit that. > > ...wouldn't we/you/they/all have to do some filtering the "other way > 'round" if all of those prefixes are contained in _one_ superblock to > guard against someone/something announcing (and potentially black- > holeing(sp?)) a route for that /32? Eh, I would assume there is no /32 to announce and that more specifics will always win. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkHau6arNKXTPFCVEQKUhgCfWIZjB4+fjTez5hZNa/4pYPbCqLUAoJsI 0HcVTYcqA0SIVDxYFEuONSBk =mmQ3 -----END PGP SIGNATURE----- From iljitsch at muada.com Wed Mar 23 22:53:54 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 23 Mar 2005 22:53:54 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <2B1A983EDCEC3447B22632B64F72646010875E@bill.office.computel.nl> References: <2B1A983EDCEC3447B22632B64F72646010875E@bill.office.computel.nl> Message-ID: <0f871129cd8da5b4bb0c785f70c4c365@muada.com> On 23-mrt-05, at 11:28, Sander Steffann wrote: >> I myself would prefer a defined range (say, a /32 block out of which >> /48s are allocated), but I seem to be a minority with that opinion. > I'll join that minority group :-) I would strongly prefer a smaller block than a /32. ARIN has a /30. If someone makes a filter that allows upto /48 in that /30, this means that some evildoer could inject 250k /48s in that /30 and make routers all over the world run out of memory. On the other hand, if RIPE would use a /35 or something like that, this would only allow for a maximum of 8192 of these prefixes. A leak of that size presumably won't kill too many routers. I would also be very happy if RIPE would charge enough money to people wanting to do this to make them consider whether they really need it. From pekkas at netcore.fi Thu Mar 24 06:53:01 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 24 Mar 2005 07:53:01 +0200 (EET) Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <0f871129cd8da5b4bb0c785f70c4c365@muada.com> References: <2B1A983EDCEC3447B22632B64F72646010875E@bill.office.computel.nl> <0f871129cd8da5b4bb0c785f70c4c365@muada.com> Message-ID: On Wed, 23 Mar 2005, Iljitsch van Beijnum wrote: > I would also be very happy if RIPE would charge enough money to people > wanting to do this to make them consider whether they really need it. Agreed.. but unfortunately, RIRs operate (typically) on a cost-recovery basis.. FWIW, I think it makes perfect sense to give each of these their own /32. Arguments about conservation are IMHO bogus when we're talking about one-in-4-billion allocations. That allows people to filter just fine, has better failure modes (as Joao pointed out), and does not have the concern Iljitsch noted. I guess the folks opposed to using /32's are mainly the ones which want to inject their own (non-related) /48's and would like the operators to drop the "we don't accept anything past /32 or /35 unless very well justified" filters. Which are a good thing, but out of scope for discussion on this list. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From woeber at cc.univie.ac.at Thu Mar 24 09:53:23 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Mar 2005 10:53:23 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <00A413E8.29BB620E.5@cc.univie.ac.at> >>> Well, this can be argued the otherway around as well. We know that >>> ISPs >>> filter out previously unused space, and that they are not very active >>> in updating those filters when IANA starts allocating out of new >>> blocks. Having all in well-known block would limit that. >> >> ...wouldn't we/you/they/all have to do some filtering the "other way >> 'round" if all of those prefixes are contained in _one_ superblock to >> guard against someone/something announcing (and potentially black- >> holeing(sp?)) a route for that /32? > >Eh, I would assume there is no /32 to announce and that more specifics >will always win. > >- - kurtis - In a perfect world - yes. But "per default" when you announce something in v6-world, you are "supposed" to announce a /32 (or maybe a /35) _and_ filter anything that is longer than that. I really don't see any benefit from adding complexity again, other than clinging to the well-worn conservatiopn goal from IPv4. Wilfried. From woeber at cc.univie.ac.at Thu Mar 24 09:58:49 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Mar 2005 10:58:49 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <00A413E8.EC31CAEE.17@cc.univie.ac.at> >I would also be very happy if RIPE would charge enough money to people >wanting to do this to make them consider whether they really need it. ...this is just a fuzzy wording for: "Make the RIRs sell address space at different (and maximum) premiums, depending on how dearly the applicant needs the addresses at that particular point in time." I would not support such a proposal. Wilfried. From iljitsch at muada.com Thu Mar 24 11:09:18 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 11:09:18 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <00A413E8.EC31CAEE.17@cc.univie.ac.at> References: <00A413E8.EC31CAEE.17@cc.univie.ac.at> Message-ID: On 24-mrt-05, at 9:58, Wilfried Woeber, UniVie/ACOnet wrote: >> I would also be very happy if RIPE would charge enough money to people >> wanting to do this to make them consider whether they really need it. > ...this is just a fuzzy wording for: > "Make the RIRs sell address space at different (and maximum) > premiums, > depending on how dearly the applicant needs the addresses at that > particular point in time." > I would not support such a proposal. No, what it means is: "People who inject routes in the global routing table, for whatever reason, increase the cost of operating routers. So for reasons of fairness and as a mild deterrent, these people should bear a generous share of the costs associated with operating the RIR infrastructure." A good way to do this would be to require everyone who wants such a block to become a RIR and to charge address based costs only on the number of blocks and not on their size. Note that I'm not saying these people should pay an artificially inflated fee (although deep in my heart I would love that), just their fair share. It shouldn't be cheaper to obtain a special prefix than a regular one. Also, there should be limits on the number of special prefixes. From iljitsch at muada.com Thu Mar 24 11:13:36 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 11:13:36 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <00A413E8.29BB620E.5@cc.univie.ac.at> References: <00A413E8.29BB620E.5@cc.univie.ac.at> Message-ID: On 24-mrt-05, at 9:53, Wilfried Woeber, UniVie/ACOnet wrote: > But "per default" when you announce something in v6-world, you are > "supposed" to announce a /32 Yes. > (or maybe a /35) No, certainly not those. > _and_ filter anything that is longer than that. That's what it says in the documents but then ARIN started to give out /48s so this policy doesn't work anymore. (Noboby bothered to change the documents that say it's ok to filter, though.) So the can of complexity worms has been opened, wasting address space (even though there is a lot to waste) has no upside anymore. Also, for reasons of flap dampening exceptions and the like it's good to have these addresses in a single block. From woeber at cc.univie.ac.at Thu Mar 24 10:31:39 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Mar 2005 11:31:39 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <00A413ED.82251A8E.13@cc.univie.ac.at> >No, what it means is: "People who inject routes in the global routing >table, for whatever reason, increase the cost of operating routers. So >for reasons of fairness and as a mild deterrent, these people should >bear a generous share of the costs associated with operating the RIR >infrastructure." Again, this implies the existence of some sort of cross-domain funds- transfers. As there is no direct and transparent relationship between ensuring uniqueness of address space blocks (RIR business) and those covering the cost of implementing the routing layer for the global Internet, it would simply be an address tax raised by the RIRs. There's not even the concept of "reverse funds" transfer from the RIRs charging for such addresses back to the LIRs. >A good way to do this would be to require everyone who wants such a >block to become a RIR and to charge address based costs only on the >number of blocks and not on their size. No, see above. [btw, I assume the string "RIR" in the previous paragraph is just a typo and that you meant to type "LIR". Otherwise this would be a clever move to kill the proposal - by sending them to ICANN for recogition as an RIR :-] And, I presume that addresses would only be distributed by way of an LIR anyway. So where is the point? >Note that I'm not saying these people should pay an artificially >inflated fee (although deep in my heart I would love that), just their >fair share. With your definition of fair for something you don't like :-) Scary... > It shouldn't be cheaper to obtain a special prefix than a regular one. Indeed, and then it should not be smaller or, rather, more difficult and risky to use. >Also, there should be limits on the number of special prefixes. Ahem, how many - and why? Wilfried. From koch at tiscali.net Thu Mar 24 11:34:08 2005 From: koch at tiscali.net (Alexander Koch) Date: Thu, 24 Mar 2005 11:34:08 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <00A413E8.29BB620E.5@cc.univie.ac.at> Message-ID: <20050324103408.GB4002@shekinah.ip.tiscali.net> On Thu, 24 March 2005 11:13:36 +0100, Iljitsch van Beijnum wrote: > > _and_ filter anything that is longer than that. > > That's what it says in the documents but then ARIN started to give out > /48s so this policy doesn't work anymore. (Noboby bothered to change > the documents that say it's ok to filter, though.) Strongest argument so far. Besides the point that I agree with the argument a /32 is probably oversized, be it v6 or not. Now that we have to take special care of the filters we place anyway, why not do one approach, and that's pretty much it. > Also, for reasons of flap dampening exceptions and the like it's good > to have these addresses in a single block. Yes, excellent point, I agree with that for sure! I do not want to think of some fancy BGP Flap Damping advisories that gives me 7 /32 blocks I should not be damping or so. Argh. Regards, Alexander -- Alexander Koch / ako4-ripe Phone +49 6103 916 480, Fax +49 6103 916 464 From kurtis at kurtis.pp.se Thu Mar 24 12:05:44 2005 From: kurtis at kurtis.pp.se (Kurtis Lindqvist) Date: Thu, 24 Mar 2005 13:05:44 +0200 (EET) Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <00A413E8.29BB620E.5@cc.univie.ac.at> References: <00A413E8.29BB620E.5@cc.univie.ac.at> Message-ID: <20050324130326.H75823@mariehamn.kurtis.pp.se> On Thu, 24 Mar 2005, Wilfried Woeber, UniVie/ACOnet wrote: > In a perfect world - yes. > > But "per default" when you announce something in v6-world, you are > "supposed" to announce a /32 (or maybe a /35) _and_ filter anything that > is longer than that. > > I really don't see any benefit from adding complexity again, other than > clinging to the well-worn conservatiopn goal from IPv4. This is a myth that is hard to kill. There are already today valid, RIR assignments that are /48s. If you where to do what you state above, you have already missed out a part of the IPv6 Internet and there is not much to do. The "filter on /32" comes from some belife that that would be the longest assigned or allocated prefixes. That is not true, and the policy proposed would add to that. I have a hard time seeing what harm consvertaion does and what complexity it would add? - kurtis - From iljitsch at muada.com Thu Mar 24 12:08:03 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 12:08:03 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <00A413ED.82251A8E.13@cc.univie.ac.at> References: <00A413ED.82251A8E.13@cc.univie.ac.at> Message-ID: On 24-mrt-05, at 10:31, Wilfried Woeber, UniVie/ACOnet wrote: >> No, what it means is: "People who inject routes in the global routing >> table, for whatever reason, increase the cost of operating routers. So >> for reasons of fairness and as a mild deterrent, these people should >> bear a generous share of the costs associated with operating the RIR >> infrastructure." > Again, this implies the existence of some sort of cross-domain funds- > transfers. No, it explicitly states that that doesn't exist. > As there is no direct and transparent relationship between > ensuring uniqueness of address space blocks (RIR business) and those > covering the cost of implementing the routing layer for the global > Internet, Yes, I said that. > it would simply be an address tax raised by the RIRs. RIR operation costs money. This money has to be recovered somehow. The only thing I'm saying is that special address holders should pay for this relative to their contribution to the global routing table. There are of course other ways to go about this, such as make the fees dependent on the amount of work the RIR has to do. But I think my suggestion is better. >> A good way to do this would be to require everyone who wants such a >> block to become a RIR and to charge address based costs only on the >> number of blocks and not on their size. > No, see above. Why wouldn't they have to become a LIR (yes, typo)? > And, I presume that addresses would only be distributed by way of an > LIR > anyway. So where is the point? Today you can get v4 PI space without becoming a LIR. >> Note that I'm not saying these people should pay an artificially >> inflated fee (although deep in my heart I would love that), just their >> fair share. > With your definition of fair for something you don't like :-) > Scary... I'm very fair with what I like and dislike, don't worry. :-) The thing is that routes in the routing table is like polution of the environment. We know we can't completely stop it, but it helps if there are monetary incentives so that people at least consider the alternatives. Don't forget that DNS anycasting isn't an essential technique, it's just an optimization. However, if the plus side ends up at the TLD operator and the minus side at the internet users at large, this optimization won't be very optimal. >> It shouldn't be cheaper to obtain a special prefix than a regular one. > Indeed, and then it should not be smaller or, rather, more difficult > and > risky to use. Nope, these attributes have nothing to do with the fees involved. Address space isn't for sale. >> Also, there should be limits on the number of special prefixes. > Ahem, how many - and why? To keep the global routing table from growing too quickly. The exact number is hard to determine, but something like 10% of the existing routing table per year seems reasonable, maybe a bit more the first few years. From pk at DENIC.DE Thu Mar 24 12:53:41 2005 From: pk at DENIC.DE (Peter Koch) Date: Thu, 24 Mar 2005 12:53:41 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <00A413ED.82251A8E.13@cc.univie.ac.at> Message-ID: <20050324115341.GA18345@denics7.denic.de> Iljitsch van Beijnum wrote: > The thing is that routes in the routing table is like polution of the > environment. We know we can't completely stop it, but it helps if there > are monetary incentives so that people at least consider the In real life often enough parties "buy the right to pollute" where there is noone really in a position to sell. I wonder whether this model can succesfully be applied here. > alternatives. Don't forget that DNS anycasting isn't an essential > technique, it's just an optimization. However, if the plus side ends up If an optimization at all, it's an essential one. Reasons for DNS anycasting have been stated multiple times and rehashing them over and over again won't make any progress. Let's assume it's best practice as long as certain criteria are met. > at the TLD operator and the minus side at the internet users at large, > this optimization won't be very optimal. TLD and root servers are a prime example for an "at large" benefit, so while I'd agree with your statement, the preconditions aren't met. Is there anything in the current proposal that makes it "too easy" to get the address space? Any suggestions for rewording or clarification? -Peter From kurtis at kurtis.pp.se Thu Mar 24 13:00:41 2005 From: kurtis at kurtis.pp.se (Kurtis Lindqvist) Date: Thu, 24 Mar 2005 14:00:41 +0200 (EET) Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <00A413E8.29BB620E.5@cc.univie.ac.at> Message-ID: <20050324140000.A75823@mariehamn.kurtis.pp.se> On Thu, 24 Mar 2005, Iljitsch van Beijnum wrote: > > _and_ filter anything that is longer than that. > > That's what it says in the documents Those documents I assume is the 6bone routing guidelines document? - kurtis - From iljitsch at muada.com Thu Mar 24 13:08:26 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 13:08:26 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324140000.A75823@mariehamn.kurtis.pp.se> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <20050324140000.A75823@mariehamn.kurtis.pp.se> Message-ID: On 24-mrt-05, at 13:00, Kurtis Lindqvist wrote: >>> _and_ filter anything that is longer than that. >> That's what it says in the documents > Those documents I assume is the 6bone routing guidelines document? No, this one/ones: http://lacnic.net/en/chapter-4.html http://ftp.apnic.net/apnic/docs/ipv6-address-policy http://www.ripe.net/ripe/docs/ipv6-policies.html http://www.arin.net/policy/index.html#six43 http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02 See section 4.3. From iljitsch at muada.com Thu Mar 24 13:20:15 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 13:20:15 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324115341.GA18345@denics7.denic.de> References: <00A413ED.82251A8E.13@cc.univie.ac.at> <20050324115341.GA18345@denics7.denic.de> Message-ID: <26ac7e07ee4a58f4018194adbdf8703d@muada.com> On 24-mrt-05, at 12:53, Peter Koch wrote: >> alternatives. Don't forget that DNS anycasting isn't an essential >> technique, it's just an optimization. However, if the plus side ends >> up > If an optimization at all, it's an essential one. We're talking about TLDs here, not the root. There are very few TLDs that even use the full 13 or so addresses that are possible without using EDNS0. Country code TLDs have existed for 20 years without trouble without anycast, so I really don't see why this would be necessary now, especially as the shorter RTTs that are possible with anycasting are extremely unlikely to make a noticeable real-world difference. >> at the TLD operator and the minus side at the internet users at large, >> this optimization won't be very optimal. > TLD and root servers are a prime example for an "at large" benefit, I'll go along with you for the root part but arguments for the root don't automatically carry over to TLDs. > Is there anything in the current proposal that makes it "too easy" to > get the > address space? Any suggestions for rewording or clarification? The fact that it exists makes it easy. One thing that would help is forbid the use of more than one IPv6 prefix for a nameserver (cluster) under the same administrative and/or technical management. I.e., if .nl and .fr both want to anycast and they both hire Anycast PLC to run anycast instances around the world, they don't both get a prefix, but have to share one. Don't forget that changing addresses for a TLD server is a simple administrative procedure (= no new root.zone) so it's easy to change addresses when the situation changes. And I think one special prefix per TLD is enough. From kurtis at kurtis.pp.se Thu Mar 24 13:22:20 2005 From: kurtis at kurtis.pp.se (Kurtis Lindqvist) Date: Thu, 24 Mar 2005 14:22:20 +0200 (EET) Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <00A413E8.29BB620E.5@cc.univie.ac.at> <20050324140000.A75823@mariehamn.kurtis.pp.se> Message-ID: <20050324142116.F75823@mariehamn.kurtis.pp.se> On Thu, 24 Mar 2005, Iljitsch van Beijnum wrote: > On 24-mrt-05, at 13:00, Kurtis Lindqvist wrote: > > >>> _and_ filter anything that is longer than that. > > >> That's what it says in the documents > > > Those documents I assume is the 6bone routing guidelines document? > > No, this one/ones: > > http://lacnic.net/en/chapter-4.html > http://ftp.apnic.net/apnic/docs/ipv6-address-policy > http://www.ripe.net/ripe/docs/ipv6-policies.html > http://www.arin.net/policy/index.html#six43 > http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02 > > See section 4.3. Section 4.3 says : 4.3. Minimum allocation RIRs will apply a minimum size for IPv6 allocations to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32. I think I must have a very different understanding of the word "facilitate" than the rest of the world... - kurtis - From iljitsch at muada.com Thu Mar 24 13:34:34 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 13:34:34 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324142116.F75823@mariehamn.kurtis.pp.se> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <20050324140000.A75823@mariehamn.kurtis.pp.se> <20050324142116.F75823@mariehamn.kurtis.pp.se> Message-ID: <252ff568cf36120fdcf7002fc4b7c2e2@muada.com> On 24-mrt-05, at 13:22, Kurtis Lindqvist wrote: > 4.3. Minimum allocation > > RIRs will apply a minimum size for IPv6 allocations to facilitate > prefix-based filtering. > > The minimum allocation size for IPv6 address space is /32. > I think I must have a very different understanding of the word > "facilitate" than the rest of the world... My reading of this text is: "the RIRs will only give out /32 or shorter prefixes so if you want, you can filter out any prefix that's longer than 32 bits" What's yours? From elmi at 4ever.de Thu Mar 24 14:02:31 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 24 Mar 2005 14:02:31 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <00A413ED.82251A8E.13@cc.univie.ac.at> Message-ID: <20050324130230.GT97739@new.detebe.org> iljitsch at muada.com (Iljitsch van Beijnum) wrote: > > And, I presume that addresses would only be distributed by way of an LIR > > anyway. So where is the point? > > Today you can get v4 PI space without becoming a LIR. I believe the reason for this is conservation. Any LIR is entitled to receiving a /20 up-front (allocation; certainly, assignments from this need to be made explicitly), so handing out PI /24s where no more space is needed looks like the better alternative. Of course, the right to the first allocation might be removed. This has not happened yet. > > Ahem, how many - and why? > > To keep the global routing table from growing too quickly. The exact > number is hard to determine, but something like 10% of the existing > routing table per year seems reasonable, maybe a bit more the first few > years. There is, however, a difference between routing table pollution (mostly because of missing or failing aggregation) and small prefixes in the routing table due to "special" PI service blocks. One should not mix this. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From elmi at 4ever.de Thu Mar 24 14:05:40 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 24 Mar 2005 14:05:40 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <26ac7e07ee4a58f4018194adbdf8703d@muada.com> References: <00A413ED.82251A8E.13@cc.univie.ac.at> <20050324115341.GA18345@denics7.denic.de> <26ac7e07ee4a58f4018194adbdf8703d@muada.com> Message-ID: <20050324130540.GU97739@new.detebe.org> iljitsch at muada.com (Iljitsch van Beijnum) wrote: > We're talking about TLDs here, not the root. There are very few TLDs > that even use the full 13 or so addresses that are possible without > using EDNS0. Country code TLDs have existed for 20 years without > trouble without anycast, so I really don't see why this would be > necessary now, especially as the shorter RTTs that are possible with > anycasting are extremely unlikely to make a noticeable real-world > difference. I don't see from where you take the right to decide for a TLD registry how they should run their operations. There are a lot of reasons for doing one or the other, but I cannot see where you come in. Apart from that, I can tell you that these shorter RTTs make a hell of a difference. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From pk at DENIC.DE Thu Mar 24 14:25:00 2005 From: pk at DENIC.DE (Peter Koch) Date: Thu, 24 Mar 2005 14:25:00 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <26ac7e07ee4a58f4018194adbdf8703d@muada.com> References: <00A413ED.82251A8E.13@cc.univie.ac.at> <20050324115341.GA18345@denics7.denic.de> <26ac7e07ee4a58f4018194adbdf8703d@muada.com> Message-ID: <20050324132500.GA19627@denics7.denic.de> Iljitsch van Beijnum wrote: > We're talking about TLDs here, not the root. There are very few TLDs > that even use the full 13 or so addresses that are possible without it might appear so since they are already anycasting. And with IPv6 it's no longer really 13. And by the way, that's exactly covered in the proposed policy, so the applicant has to provide some reasoning. > using EDNS0. Country code TLDs have existed for 20 years without > trouble without anycast, so I really don't see why this would be Well, I've been told that some things have changed during those 20 years, including IPv6 deployment, query volume increase, DoS attacks, user expectation to name a few. > necessary now, especially as the shorter RTTs that are possible with > anycasting are extremely unlikely to make a noticeable real-world > difference. They might not for a single user but they definitely do -- even more so for the users "at large". > >TLD and root servers are a prime example for an "at large" benefit, > > I'll go along with you for the root part but arguments for the root > don't automatically carry over to TLDs. Nothing automatic here, but just one example: most people during the day hit more SLDs in a single TLD than they hit different TLDs. > prefix for a nameserver (cluster) under the same administrative and/or > technical management. I.e., if .nl and .fr both want to anycast and > they both hire Anycast PLC to run anycast instances around the world, > they don't both get a prefix, but have to share one. That raises the question whether the prefix is per TLD or per DNS operator. Thanks for your input - any comments anyone else? > And I think one special prefix per TLD is enough. Assumed the former this has interesting implications. -Peter From iljitsch at muada.com Thu Mar 24 14:29:21 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 14:29:21 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324130540.GU97739@new.detebe.org> References: <00A413ED.82251A8E.13@cc.univie.ac.at> <20050324115341.GA18345@denics7.denic.de> <26ac7e07ee4a58f4018194adbdf8703d@muada.com> <20050324130540.GU97739@new.detebe.org> Message-ID: <176fc85299797e2f962385138ae84400@muada.com> On 24-mrt-05, at 14:05, Elmar K. Bins wrote: > I don't see from where you take the right to decide for a TLD registry > how they should run their operations. The same place they find the right to take up space in my routing table. > Apart from that, I can tell you that these shorter RTTs make a hell > of a difference. Then you're running the wrong DNS software. A good resolving server should keep track of the TTLs towards different nameservers for a zone and try to talk to the one with the lowest TTL first most of the time. From your other message: > There is, however, a difference between routing table pollution (mostly > because of missing or failing aggregation) and small prefixes in the > routing table due to "special" PI service blocks. One should not mix > this. It's natural to look at these differently, but the end result is invariably the same: more CPU and memory usage in the routers. From iljitsch at muada.com Thu Mar 24 14:38:33 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 14:38:33 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324132500.GA19627@denics7.denic.de> References: <00A413ED.82251A8E.13@cc.univie.ac.at> <20050324115341.GA18345@denics7.denic.de> <26ac7e07ee4a58f4018194adbdf8703d@muada.com> <20050324132500.GA19627@denics7.denic.de> Message-ID: On 24-mrt-05, at 14:25, Peter Koch wrote: >> We're talking about TLDs here, not the root. There are very few TLDs >> that even use the full 13 or so addresses that are possible without > it might appear so since they are already anycasting. I was talking about addresses, not about servers. It makes no sense to anycast when there is room for more regular addresses. >> using EDNS0. Country code TLDs have existed for 20 years without >> trouble without anycast, so I really don't see why this would be > Well, I've been told that some things have changed during those 20 > years, including IPv6 deployment, query volume increase, DoS attacks, > user expectation to name a few. Yes, and these changes over 20 years could be accommodated without TLD anycasting. My point isn't that there shouldn't be any TLD anycasting, just that TLDs can get by just fine without it too. >> necessary now, especially as the shorter RTTs that are possible with >> anycasting are extremely unlikely to make a noticeable real-world >> difference. > They might not for a single user but they definitely do -- even more so > for the users "at large". The users "at large" of ccTLDs are clustered within a small part of the network so having anycast instances all over the place doesn't help the users at large, only the very few that go to .nl from Argentina or some such. And since they incur longer round trips for the query to the authorative nameserver for the domain and then for the actual communciation anyway, the benefit to those users is also relatively low. From dr at cluenet.de Thu Mar 24 14:45:15 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 24 Mar 2005 14:45:15 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <252ff568cf36120fdcf7002fc4b7c2e2@muada.com> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <20050324140000.A75823@mariehamn.kurtis.pp.se> <20050324142116.F75823@mariehamn.kurtis.pp.se> <252ff568cf36120fdcf7002fc4b7c2e2@muada.com> Message-ID: <20050324134515.GA28726@srv01.cluenet.de> On Thu, Mar 24, 2005 at 01:34:34PM +0100, Iljitsch van Beijnum wrote: > My reading of this text is: "the RIRs will only give out /32 or shorter > prefixes so if you want, you can filter out any prefix that's longer > than 32 bits" > > What's yours? About the same here. But we're speaking of assignments, not allocations. This policy doesn't apply. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Thu Mar 24 14:55:24 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 14:55:24 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324134515.GA28726@srv01.cluenet.de> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <20050324140000.A75823@mariehamn.kurtis.pp.se> <20050324142116.F75823@mariehamn.kurtis.pp.se> <252ff568cf36120fdcf7002fc4b7c2e2@muada.com> <20050324134515.GA28726@srv01.cluenet.de> Message-ID: <9335bb3da80e9ca929fd809c2dd08c3d@muada.com> On 24-mrt-05, at 14:45, Daniel Roesen wrote: > On Thu, Mar 24, 2005 at 01:34:34PM +0100, Iljitsch van Beijnum wrote: >> My reading of this text is: "the RIRs will only give out /32 or >> shorter >> prefixes so if you want, you can filter out any prefix that's longer >> than 32 bits" >> What's yours? > About the same here. But we're speaking of assignments, not > allocations. > This policy doesn't apply. So how exactly do I build a prefix length filter that only applies to allocations and not assignments? From joao-ripe at c-l-i.net Thu Mar 24 15:06:39 2005 From: joao-ripe at c-l-i.net (Joao Damas) Date: Thu, 24 Mar 2005 15:06:39 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay so the only point of contention is the size of the prefix. Using longer prefixes does not add much to the conservation and introduces more exceptions. Even if other RIRs are doing /48s already why would introducing an additional chunk of swamp space with the potential for more likely large scale failure be of any benefit? If people agree with assigning the addresses for this purpose, which seems to be the case, just issue a standard allocation and be done. Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50. Joao PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon. PS: regarding the use of "wrong DNS software", the TLD operator is running *SERVERS* and providing services to resolvers/users. The best they can do is provide as good a service as they can to their consumers, not preach to them about them running the wrong client side software. From iljitsch at muada.com Thu Mar 24 15:10:47 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Mar 2005 15:10:47 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> References: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> Message-ID: On 24-mrt-05, at 15:06, Joao Damas wrote: > Regarding the issue of flap damp(en)ing parameters, I think we should > really revisit the flap damp(en)ing recommendations again at RIPE 50. It should happen before doing anything with regard to this proposal, though. And what kind of changes do you imagine? > PS: regarding entries in the routing table and the pollution it > causes, keep an eye on RFCs coming soon. Do you have the draft names? That saves me the waiting. :-) > PS: regarding the use of "wrong DNS software", the TLD operator is > running *SERVERS* and providing services to resolvers/users. The best > they can do is provide as good a service as they can to their > consumers, not preach to them about them running the wrong client side > software. We shouldn't go out of our way to help people who don't help themselves. Inflating the routing table because DNS software doesn't do what it should do is WRONG. From joao-ripe at c-l-i.net Thu Mar 24 15:14:55 2005 From: joao-ripe at c-l-i.net (Joao Damas) Date: Thu, 24 Mar 2005 15:14:55 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> Message-ID: On 24 Mar, 2005, at 15:10, Iljitsch van Beijnum wrote: > On 24-mrt-05, at 15:06, Joao Damas wrote: > >> Regarding the issue of flap damp(en)ing parameters, I think we should >> really revisit the flap damp(en)ing recommendations again at RIPE 50. > > It should happen before doing anything with regard to this proposal, > though. And what kind of changes do you imagine? OH, that would be for the wg to discuss, but perhaps deprecation would be amongst the possibilities that need consideration > >> PS: regarding entries in the routing table and the pollution it >> causes, keep an eye on RFCs coming soon. > > Do you have the draft names? That saves me the waiting. :-) > In this case it would not, really :) You will have to be a bit patient. Joao From randy at psg.com Thu Mar 24 15:26:32 2005 From: randy at psg.com (Randy Bush) Date: Thu, 24 Mar 2005 06:26:32 -0800 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy References: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> Message-ID: <16962.52760.801861.318974@roam.psg.com> > OK, so I guess my point altogether is that I dislike special-ness. > > There seems to be agreement that DNS anycasting is here to stay and it's special enough to require special policy. i.e. one does not have to like consistency to dislike specialness. randy From joao-ripe at c-l-i.net Thu Mar 24 15:30:13 2005 From: joao-ripe at c-l-i.net (Joao Damas) Date: Thu, 24 Mar 2005 15:30:13 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <16962.52760.801861.318974@roam.psg.com> References: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> <16962.52760.801861.318974@roam.psg.com> Message-ID: <94dad07cf9cbfd0634ff7ac21a9492b0@c-l-i.net> Hi Randy! On 24 Mar, 2005, at 15:26, Randy Bush wrote: >> OK, so I guess my point altogether is that I dislike special-ness. >> >> There seems to be agreement that DNS anycasting is here to stay > > and it's special enough to require special policy. i.e. one does > not have to like consistency to dislike specialness. > one tries to limit it to the minimum. Joao From randy at psg.com Thu Mar 24 15:36:02 2005 From: randy at psg.com (Randy Bush) Date: Thu, 24 Mar 2005 06:36:02 -0800 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy References: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> <16962.52760.801861.318974@roam.psg.com> <94dad07cf9cbfd0634ff7ac21a9492b0@c-l-i.net> Message-ID: <16962.53330.599688.388744@roam.psg.com> mornin' joao, >>> OK, so I guess my point altogether is that I dislike special-ness. >>> There seems to be agreement that DNS anycasting is here to stay >> and it's special enough to require special policy. i.e. one does >> not have to like consistency to dislike specialness. > one tries to limit it to the minimum. so, in this case, would that be o only tlds can get this specialness o only dns services can get this specialness o any anycasting services can get this specialness o any services which can justify address space get the space (which is what we theoretically have today)? randy From joao-ripe at c-l-i.net Thu Mar 24 15:43:37 2005 From: joao-ripe at c-l-i.net (Joao Damas) Date: Thu, 24 Mar 2005 15:43:37 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <16962.53330.599688.388744@roam.psg.com> References: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> <16962.52760.801861.318974@roam.psg.com> <94dad07cf9cbfd0634ff7ac21a9492b0@c-l-i.net> <16962.53330.599688.388744@roam.psg.com> Message-ID: <6a5ee1da4d8541d0f244e185969623c7@c-l-i.net> On 24 Mar, 2005, at 15:36, Randy Bush wrote: > mornin' joao, > >>>> OK, so I guess my point altogether is that I dislike special-ness. >>>> There seems to be agreement that DNS anycasting is here to stay >>> and it's special enough to require special policy. i.e. one does >>> not have to like consistency to dislike specialness. >> one tries to limit it to the minimum. > > so, in this case, would that be > o only tlds can get this specialness > o only dns services can get this specialness > o any anycasting services can get this specialness > o any services which can justify address space get the space > (which is what we theoretically have today)? > Dunno, you will have to ask the wg. What is your take on it? On a separate issue, your 3rd bullet point: are there any more results from your study on the routing of anycasted services? Some people are telling they are OK with using anycast for TCP and I am certainly curious. Joao From dr at cluenet.de Thu Mar 24 15:44:59 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 24 Mar 2005 15:44:59 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <9335bb3da80e9ca929fd809c2dd08c3d@muada.com> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <20050324140000.A75823@mariehamn.kurtis.pp.se> <20050324142116.F75823@mariehamn.kurtis.pp.se> <252ff568cf36120fdcf7002fc4b7c2e2@muada.com> <20050324134515.GA28726@srv01.cluenet.de> <9335bb3da80e9ca929fd809c2dd08c3d@muada.com> Message-ID: <20050324144459.GA29292@srv01.cluenet.de> On Thu, Mar 24, 2005 at 02:55:24PM +0100, Iljitsch van Beijnum wrote: > So how exactly do I build a prefix length filter that only applies to > allocations and not assignments? This is why people propose reserving a range for PI assignments, so that this range can have different filtering. No rocket science. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Thu Mar 24 16:22:02 2005 From: randy at psg.com (Randy Bush) Date: Thu, 24 Mar 2005 07:22:02 -0800 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy References: <5674c8fa63a03c91505782dccbc75766@c-l-i.net> <16962.52760.801861.318974@roam.psg.com> <94dad07cf9cbfd0634ff7ac21a9492b0@c-l-i.net> <16962.53330.599688.388744@roam.psg.com> <6a5ee1da4d8541d0f244e185969623c7@c-l-i.net> Message-ID: <16962.56090.969659.572991@roam.psg.com> >>>>> OK, so I guess my point altogether is that I dislike special-ness. >>>>> There seems to be agreement that DNS anycasting is here to stay >>>> and it's special enough to require special policy. i.e. one does >>>> not have to like consistency to dislike specialness. >>> one tries to limit it to the minimum. >> so, in this case, would that be >> o only tlds can get this specialness >> o only dns services can get this specialness >> o any anycasting services can get this specialness >> o any services which can justify address space get the space >> (which is what we theoretically have today)? > Dunno, you will have to ask the wg. What is your take on it? i am trying to understand this mess. seems to me that two points raised this morning (your daytime may vary:-) raise an interesting question. if /32 filters are to be no longer implied by allocation policy, i.e., folk should filter on /48, why can't anycasters just use a /48 out of their other v6 chunk? otoh, if we want allocation policy to imply filtering on /32 or whatever (i note the rightward creep in v4 from /19 to /21-/22), anycasters are suggesting we throw a rather large chunk of address space (79,228,162,514,264,337,593,543,950,336 hosts, i don't even know how to say it in american) at a handful of hosts. so we must think v6 space essentially infinite. but, if time has taught us anything about scaling, we've seen every hard and fast number picked in computing turn out to be insufficient in the long run. but here we don't seem to have the traditional conflict between conservation of address space and conservation of routing table, as an anycaster is gonna announce a prefix anyway. and i am not sure it is safe to assume anycasters will be few or the 'importance' of particular anycast services will show clear classes except in the minds of the folk deploying them. so i suspect that we are on a slippery slope and we have no real grasp of it's future angle or length. i suspect this is why so many of us are uneasy. it's actually a hard question and we have quite insufficient information. personally, i have no answer. sorry to make you read all this rubbish to find that. why not show a bit of wimsey and block out 42 /32 chunks for this and have a three month bidding period to see how much money the rirs can collect to donate to heal some of the horrifying wounds of the latest natural disaster or unnatural us imperialism? > On a separate issue, your 3rd bullet point: are there any more > results from your study on the routing of anycasted services? we were not really looking at anycast services per se, just using anycasted prefixes to highlight routing issues, as they seemed wont to do. we're hoping to present more come nanog time. randy From jon at lawrence.org.uk Thu Mar 24 16:44:42 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 24 Mar 2005 15:44:42 +0000 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324144459.GA29292@srv01.cluenet.de> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <9335bb3da80e9ca929fd809c2dd08c3d@muada.com> <20050324144459.GA29292@srv01.cluenet.de> Message-ID: <200503241544.42567.jon@lawrence.org.uk> On Thursday 24 March 2005 14:44, Daniel Roesen wrote: > On Thu, Mar 24, 2005 at 02:55:24PM +0100, Iljitsch van Beijnum wrote: > > So how exactly do I build a prefix length filter that only applies to > > allocations and not assignments? > > This is why people propose reserving a range for PI assignments, so > that this range can have different filtering. No rocket science. > But Daniel, there's no such thing as v6 PI :) As I read it, they're talking about reserving a block for what would effectively be micro-allocations no PI. Jon From woeber at cc.univie.ac.at Thu Mar 24 16:01:15 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Mar 2005 17:01:15 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <00A4141B.8DF464FE.9@cc.univie.ac.at> >personally, i have no answer. We seem to be coming to the bottom of the pit :-) > sorry to make you read all this rubbish to find that. Fine with me. > why not show a bit of wimsey and block out >42 /32 chunks for this and have a three month bidding period to see >how much money the rirs can collect to donate to heal some of the >horrifying wounds of the latest natural disaster or unnatural us >imperialism? Aah, so this time at least we don't want to raise money for poor routers, but for victims of some sort of disaster or another. And why 42? (other than being "this" universal number) Wouldn't we be able to raise more money if we would give away more prefixes ;-) Or maybe just 32 x /32? Funny times, Wilfried. From dr at cluenet.de Thu Mar 24 17:27:42 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 24 Mar 2005 17:27:42 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503241544.42567.jon@lawrence.org.uk> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <9335bb3da80e9ca929fd809c2dd08c3d@muada.com> <20050324144459.GA29292@srv01.cluenet.de> <200503241544.42567.jon@lawrence.org.uk> Message-ID: <20050324162742.GA30382@srv01.cluenet.de> On Thu, Mar 24, 2005 at 03:44:42PM +0000, Jon Lawrence wrote: > On Thursday 24 March 2005 14:44, Daniel Roesen wrote: > > On Thu, Mar 24, 2005 at 02:55:24PM +0100, Iljitsch van Beijnum wrote: > > > So how exactly do I build a prefix length filter that only applies to > > > allocations and not assignments? > > > > This is why people propose reserving a range for PI assignments, so > > that this range can have different filtering. No rocket science. > > > But Daniel, there's no such thing as v6 PI :) That's what THEY want to make you believe. :-)= > As I read it, they're talking about reserving a block for what would > effectively be micro-allocations no PI. And what's the difference please? Especially since those aren't allocations (you can't assign more-specifics to others) but assignments? Don't play with words. It's IPv6 PI for whoever-is-deemed-special. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Thu Mar 24 19:40:07 2005 From: randy at psg.com (Randy Bush) Date: Thu, 24 Mar 2005 10:40:07 -0800 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy References: <00A4141B.8DF464FE.9@cc.univie.ac.at> Message-ID: <16963.2439.711833.619217@roam.psg.com> > Aah, so this time at least we don't want to raise money for poor > routers, but for victims of some sort of disaster or another. in this case, they are members of the same set, but for the routers, you are making the disaster with knowledge of what you do. randy From gert at space.net Thu Mar 24 20:08:23 2005 From: gert at space.net (Gert Doering) Date: Thu, 24 Mar 2005 20:08:23 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503241544.42567.jon@lawrence.org.uk> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <9335bb3da80e9ca929fd809c2dd08c3d@muada.com> <20050324144459.GA29292@srv01.cluenet.de> <200503241544.42567.jon@lawrence.org.uk> Message-ID: <20050324190823.GX84850@Space.Net> Hi, On Thu, Mar 24, 2005 at 03:44:42PM +0000, Jon Lawrence wrote: > > This is why people propose reserving a range for PI assignments, so > > that this range can have different filtering. No rocket science. > But Daniel, there's no such thing as v6 PI :) > As I read it, they're talking about reserving a block for what would > effectively be micro-allocations no PI. Microallocations are PI in disguise - end users get address space directly from a RIR. If that's not PI, then what else is? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Thu Mar 24 20:16:14 2005 From: gert at space.net (Gert Doering) Date: Thu, 24 Mar 2005 20:16:14 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324130230.GT97739@new.detebe.org> References: <00A413ED.82251A8E.13@cc.univie.ac.at> <20050324130230.GT97739@new.detebe.org> Message-ID: <20050324191614.GY84850@Space.Net> Hi, On Thu, Mar 24, 2005 at 02:02:31PM +0100, Elmar K. Bins wrote: [..] > I believe the reason for this is conservation. Any LIR is entitled to > receiving a /20 up-front (allocation; certainly, assignments from this > need to be made explicitly), so handing out PI /24s where no more space > is needed looks like the better alternative. > > Of course, the right to the first allocation might be removed. This has > not happened yet. Sidetracking: actually we tried that (added criteria for the first IPv4 allocation) - result? People got 'me a handful of /24 PI networks, paying some small saving on the address space side with more pollution on the routing table size. So we changed it back. Policies interact. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From elmi at 4ever.de Thu Mar 24 21:35:38 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 24 Mar 2005 21:35:38 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324190823.GX84850@Space.Net> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <9335bb3da80e9ca929fd809c2dd08c3d@muada.com> <20050324144459.GA29292@srv01.cluenet.de> <200503241544.42567.jon@lawrence.org.uk> <20050324190823.GX84850@Space.Net> Message-ID: <20050324203537.GZ97739@new.detebe.org> gert at space.net (Gert Doering) wrote: > Microallocations are PI in disguise - end users get address space directly > from a RIR. If that's not PI, then what else is? Actually, the people (who argue to be) in need of v6 microallocations do not care what the baby is called. And there's no valid presumption they are not LIRs already. But AFAIR there's still a 200-customer problem which an end site (RIR-wise) cannot solve. Nonetheless they want to multihome, and they want to _really_ multihome, being that anycast instances are usually scattered all over the globe. This implies that there must be a way to get a (however big) routable block that's unlikely to be filtered - well, the proposal has it all. And frankly, I do not care whether it's a /32, /35, /48 or /64, as long as it's accepted and (if ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jon at lawrence.org.uk Thu Mar 24 21:47:12 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 24 Mar 2005 20:47:12 +0000 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324190823.GX84850@Space.Net> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <200503241544.42567.jon@lawrence.org.uk> <20050324190823.GX84850@Space.Net> Message-ID: <200503242047.12338.jon@lawrence.org.uk> On Thursday 24 March 2005 19:08, Gert Doering wrote: > > Microallocations are PI in disguise - end users get address space directly > from a RIR. If that's not PI, then what else is? > Yes, I agree that they are PI in disguise. But they are still a way of saying to general end users that there's no such thing as PI space - by general end users, I mean corporations not people like TLD (or ccTLD) operators (they should know full well what's what). Or are we just going to say, if you can create a good enough case then PI exists - come and get it. I think that giving every TLD (or every 'special' case if you like) a /32 is a complete waste of address space, and as Randy said have we learnt nothing from the past. It's not so much about conservation as about being sensible. We don't know and no one has been very successful (afaict) in predicting the growth of the 'net, so perhaps being sensible is a good idea :). If we (as in RIPE) are going to start handing out longer than /32's then all the RIR's have to make it abundantly clear that they don't support the idea of /32 filters - or should they (RIR's) make allocations/assignments (call them what you will) from a global pool for these micro allocations and everyone then shouts about how this specific /32 shouldn't be filtered. How soon do we think the routing tables are going to become unmanageable (and I mean unmanageable by the routers themselves) ?? 3 years, 5 years ?? Perhaps we ought to be asking the people who design/build the routers what they think their kit will be capable of by then. We have seen large increases (in % terms) of what routers can now do compared to 5 years ago, what's to say we're not going to see even bigger % increases over the next 5 years. Jon From dr at cluenet.de Thu Mar 24 22:54:54 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 24 Mar 2005 22:54:54 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503242047.12338.jon@lawrence.org.uk> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <200503241544.42567.jon@lawrence.org.uk> <20050324190823.GX84850@Space.Net> <200503242047.12338.jon@lawrence.org.uk> Message-ID: <20050324215454.GA377@srv01.cluenet.de> On Thu, Mar 24, 2005 at 08:47:12PM +0000, Jon Lawrence wrote: > Yes, I agree that they are PI in disguise. But they are still a way of saying > to general end users that there's no such thing as PI space - by general end > users, I mean corporations not people like TLD (or ccTLD) operators (they > should know full well what's what). Or are we just going to say, if you can > create a good enough case then PI exists - come and get it. PI will come or IPv6 not fly. Face it. > If we (as in RIPE) are going to start handing out longer than /32's > then all the RIR's have to make it abundantly clear that they don't > support the idea of /32 filters ARIN and LACNIC already do. RIPE (not NCC) folks are still trying to make policy around people's failure to properly maintain filters. It's like capitulating before the battle even started (looking at actual deployment out there, the few who don't get it [filtering] will learn it the hard way later). > or should they (RIR's) make allocations/assignments (call them what > you will) from a global pool for these micro allocations and everyone > then shouts about how this specific /32 shouldn't be filtered. Yes. ARIN: http://www.arin.net/registration/ipv6/micro_alloc.html (2001:0500::/29) LACNIC: http://lacnic.net/en/registro/index.html "IPv6: 2001:1200::/23 (minimum allocation /48)" "NAPs/IXP in the region: [...] 2001:12f8::/32" So basically you have to (judging from above statement) expect valid /48 announcements from whole LACNIC space. And from ARIN space within 2001:500::/29. > How soon do we think the routing tables are going to become > unmanageable (and I mean unmanageable by the routers themselves) ?? > 3 years, 5 years ?? Can you give some well-funded projection, or just hand-waving FUD? > Perhaps we ought to be asking the people who design/build the routers > what they think their kit will be capable of by then. They say that they test their RPs for 1 million RIB routes since years. Not the (then) high-end gear you have bought ten years ago, or even only a few years ago where you may have made questionable and/or short-sighted purchase decisions. > We have seen large increases (in % terms) of what routers can now do > compared to 5 years ago, what's to say we're not going to see even > bigger % increases over the next 5 years. We don't need. We don't even push (good) 5-year old gear to the limits with today's IPv4 junk DFZ RIB. Give every IPv6 ASN a prefix to announce and we'll add about 10-15% to this RIB. Big deal? I strongly disagree. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jon at lawrence.org.uk Fri Mar 25 00:41:18 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 24 Mar 2005 23:41:18 +0000 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050324215454.GA377@srv01.cluenet.de> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <200503242047.12338.jon@lawrence.org.uk> <20050324215454.GA377@srv01.cluenet.de> Message-ID: <200503242341.18978.jon@lawrence.org.uk> On Thursday 24 March 2005 21:54, Daniel Roesen wrote: > On Thu, Mar 24, 2005 at 08:47:12PM +0000, Jon Lawrence wrote: > > Yes, I agree that they are PI in disguise. But they are still a way of > > saying to general end users that there's no such thing as PI space - by > > general end users, I mean corporations not people like TLD (or ccTLD) > > operators (they should know full well what's what). Or are we just going > > to say, if you can create a good enough case then PI exists - come and > > get it. > > PI will come or IPv6 not fly. Face it. > > > If we (as in RIPE) are going to start handing out longer than /32's > > then all the RIR's have to make it abundantly clear that they don't > > support the idea of /32 filters > > ARIN and LACNIC already do. RIPE (not NCC) folks are still trying to > make policy around people's failure to properly maintain filters. It's > like capitulating before the battle even started (looking at actual > deployment out there, the few who don't get it [filtering] will learn > it the hard way later). > > > or should they (RIR's) make allocations/assignments (call them what > > you will) from a global pool for these micro allocations and everyone > > then shouts about how this specific /32 shouldn't be filtered. > > Yes. > > ARIN: http://www.arin.net/registration/ipv6/micro_alloc.html > (2001:0500::/29) > LACNIC: http://lacnic.net/en/registro/index.html > "IPv6: 2001:1200::/23 (minimum allocation /48)" > "NAPs/IXP in the region: [...] 2001:12f8::/32" > > So basically you have to (judging from above statement) expect valid /48 > announcements from whole LACNIC space. > > And from ARIN space within 2001:500::/29. > > > How soon do we think the routing tables are going to become > > unmanageable (and I mean unmanageable by the routers themselves) ?? > > 3 years, 5 years ?? > > Can you give some well-funded projection, or just hand-waving FUD? I can't give any projections - That's why I asked :) I'm sure someone could work out given the current growth rate, how long it would take to cripple todays routers. > > > Perhaps we ought to be asking the people who design/build the routers > > what they think their kit will be capable of by then. > > They say that they test their RPs for 1 million RIB routes since years. > Not the (then) high-end gear you have bought ten years ago, or even only > a few years ago where you may have made questionable and/or short-sighted > purchase decisions. > > > We have seen large increases (in % terms) of what routers can now do > > compared to 5 years ago, what's to say we're not going to see even > > bigger % increases over the next 5 years. > > We don't need. We don't even push (good) 5-year old gear to the limits > with today's IPv4 junk DFZ RIB. Give every IPv6 ASN a prefix to announce > and we'll add about 10-15% to this RIB. Big deal? I strongly disagree. > We don't push them now ?? - even the big guys ?? If even they don't push their routers hard, then even with phenomenal growth over the next 5 years or so then what ever the current routers are then will probably be able to cope. If the routers can cope then the size of the routing table becomes a non issue - that's what I'm trying to say. Jon From randy at psg.com Fri Mar 25 02:12:40 2005 From: randy at psg.com (Randy Bush) Date: Thu, 24 Mar 2005 17:12:40 -0800 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy References: <00A413E8.29BB620E.5@cc.univie.ac.at> <200503242047.12338.jon@lawrence.org.uk> <20050324215454.GA377@srv01.cluenet.de> <200503242341.18978.jon@lawrence.org.uk> Message-ID: <16963.25992.95711.324234@roam.psg.com> > I'm sure someone could work out given the current growth rate, > how long it would take to cripple todays routers. be suspicious of any answers you get to this question. i am not aware of any real *operational* (i.e. relevant to routers in the *real* network) solid work on this; but i sure would love to see some, done rigorously, of course, and not by some vendor's droids. randy From oliver at bartels.de Fri Mar 25 09:05:04 2005 From: oliver at bartels.de (Oliver Bartels) Date: Fri, 25 Mar 2005 09:05:04 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503242341.18978.jon@lawrence.org.uk> Message-ID: <200503250804.j2P84Zp0028221@alpha.bartels.de> On Thu, 24 Mar 2005 23:41:18 +0000, Jon Lawrence wrote: >> PI will come or IPv6 not fly. Face it. Full Ack. You won't force company decision makers to get back into the mercy of a single ISP and become dependent from it. Not with policies. You would have to order the army ;-/ >We don't push them now ?? - even the big guys ?? >If even they don't push their routers hard, then even with phenomenal growth >over the next 5 years or so then what ever the current routers are then will >probably be able to cope. >If the routers can cope then the size of the routing table becomes a non issue >- that's what I'm trying to say. *Todays* routers *are* able to handle +20K prefixes. And if they don't, the ISP has to *invest* into new gear. An ISP is a company like any other company, if the market requests that doors and windows should be build with 1mm precision, it won't help the carpenters with old manufacturing equipment to make a policy which defines that 5mm precision is good enough. Face it: Customers demand provider independent address space and multihoming, as a IPv6 provider you may either deliver some solution or you won't sell your product. There is enough IPv4 PI competition ... Best Regards Oliver P.s.: - A good *Engineer* would think of a router beeing capable of >>1 Mio. prefix entries with >>100K different paths. And yes, this is possible. And no, there are customers who need more than 640KB of memory, and yes, there are PC's with more than 640KB ... - A good *Marketing Guy* would then sell Engineers products with the Label "IPv6-PI-ready" and would create a new "this is hip you must have it" *premium* IPv6 product which permits $customer to just *install* his IPv6 prefix at the ISP of his choice. If $customer is on vacation: Just install the prefix there. Such "Customer: you should not have this and that" policies are for the buerocrats (the bad ones, a good buerocrat would see its job in assigning the "IPv6-PI-ready" label ;-) and the market has shown that such policies don't survive. Ceterum Censeo: Either IPv6 PI routing or IPv6 will die. Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From woeber at cc.univie.ac.at Fri Mar 25 11:50:21 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 25 Mar 2005 12:50:21 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy Message-ID: <00A414C1.AB56598E.11@cc.univie.ac.at> >If even they don't push their routers hard, then even with phenomenal growth >over the next 5 years or so then what ever the current routers are then will >probably be able to cope. >If the routers can cope then the size of the routing table becomes a non issue >- that's what I'm trying to say. Looking at the fact that for a couple of years already the majority no longer cares (or even reads? much less acts on) the weekly routing table reports suggests that you are right. >Jon Wilfried. From Michael.Dillon at radianz.com Tue Mar 29 16:42:00 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 29 Mar 2005 15:42:00 +0100 Subject: [address-policy-wg] Policies interact In-Reply-To: <20050324191614.GY84850@Space.Net> Message-ID: > Sidetracking: actually we tried that (added criteria for the first > IPv4 allocation) - result? People got 'me a handful of /24 PI networks, > paying some small saving on the address space side with more pollution > on the routing table size. So we changed it back. When we transition to IPv6, we lose any benefits of the savings in IPv4 addresses, however, the penalty of pollution in the routing table is multiplied. Savings in IPv4 space, do not carry over into IPv6. That is why we lose these savings. But the size of the routing table increases by 4 times therefore requiring 4 times as much RAM and 4 times as much time to send/receive full routes. No doubt one could apply some weighting factors and conclude that the overall penalty is multiplied by less than 4 times, however the fact is that the penalty is greater. Therefore, is it false economy to have policies which put IPv4 address space conservation higher on the agenda than routing table size conservation? Policies interact, including interaction between IPv4 and IPv6 policy. With IPv6 we can afford to be generous. --Michael Dillon From Michael.Dillon at radianz.com Tue Mar 29 16:47:03 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 29 Mar 2005 15:47:03 +0100 Subject: [address-policy-wg] Real multihoming or anycast? In-Reply-To: <20050324203537.GZ97739@new.detebe.org> Message-ID: > Nonetheless they want to multihome, and they want to _really_ multihome, > being that anycast instances are usually scattered all over the globe. > This implies that there must be a way to get a (however big) routable > block that's unlikely to be filtered - well, the proposal has it all. Why not learn from the lessons of radio spectrum? A fixed number of 3G frequency allocations were put up for auction (or beauty contest). Why should RIPE not offer a limited number of /32 allocations for operators of anycast fabrics? I suggest that RIPE offer 16 allocations of /32 to organizations who intend to operate diverse anycast fabrics globally to serve TLD operators and others who can benefit from an anycast fabric. Select the winners by beauty contest based on technical and commercial fitness. --Michael Dillon From jeroen at unfix.org Wed Mar 30 18:04:30 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 30 Mar 2005 18:04:30 +0200 Subject: [address-policy-wg] Real multihoming or anycast? In-Reply-To: References: Message-ID: <1112198670.3436.17.camel@firenze.zurich.ibm.com> On Tue, 2005-03-29 at 15:47 +0100, Michael.Dillon at radianz.com wrote: > > Nonetheless they want to multihome, and they want to _really_ multihome, > > being that anycast instances are usually scattered all over the globe. > > This implies that there must be a way to get a (however big) routable > > block that's unlikely to be filtered - well, the proposal has it all. > > Why not learn from the lessons of radio spectrum? A fixed number of > 3G frequency allocations were put up for auction (or beauty contest). > > Why should RIPE not offer a limited number of /32 allocations for > operators of anycast fabrics? I suggest that RIPE offer 16 allocations > of /32 to organizations who intend to operate diverse anycast fabrics > globally to serve TLD operators and others who can benefit from > an anycast fabric. Select the winners by beauty contest based on > technical and commercial fitness. Very simple answer for what is possible with _CURRENT_ policy: 8<------------------- jeroen at purgatory:~$ whois -h whois.arin.net GOOGLE-IPV6 OrgName: Google Inc. OrgID: GOGL Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US NetRange: 2001:4860:0000:0000:0000:0000:0000:0000 - 2001:4860:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:4860:0000:0000:0000:0000:0000:0000/32 NetName: GOOGLE-IPV6 NetHandle: NET6-2001-4860-1 Parent: NET6-2001-4800-0 NetType: Direct Allocation Comment: RegDate: 2005-03-14 Updated: 2005-03-14 ----------------->8 Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From Michael.Dillon at radianz.com Wed Mar 30 18:19:58 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 30 Mar 2005 17:19:58 +0100 Subject: [address-policy-wg] Real multihoming or anycast? In-Reply-To: <1112198670.3436.17.camel@firenze.zurich.ibm.com> Message-ID: > > Why not learn from the lessons of radio spectrum? A fixed number of > > 3G frequency allocations were put up for auction (or beauty contest). > > > > Why should RIPE not offer a limited number of /32 allocations for > > operators of anycast fabrics? I suggest that RIPE offer 16 allocations > > of /32 to organizations who intend to operate diverse anycast fabrics > > globally to serve TLD operators and others who can benefit from > > an anycast fabric. Select the winners by beauty contest based on > > technical and commercial fitness. > > Very simple answer for what is possible with _CURRENT_ policy: > $ whois -h whois.arin.net GOOGLE-IPV6 As far as I know, Google is not a service provider. They operate their own network for their own business. I am suggesting that a certain number of /32's should be given to companies which will provide global anycast meshes as a service to 3rd party customers. That way, TLD operators can choose one or more anycast hosting services to host their "critical" service. This makes more sense than giving a /32 to everyone who feels that their service is "critical". If you analyse the situation by the 80/20 rule, then Google represents the 20% of "critical" services that are big enough to be their own ISP. My suggestion is meant to support the 80% of "critical" services that could benefit from the same technology as Google, but which are not large enough to go it alone. --Michael Dillon From elmi at 4ever.de Wed Mar 30 18:28:37 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 30 Mar 2005 18:28:37 +0200 Subject: [address-policy-wg] Real multihoming or anycast? In-Reply-To: References: <1112198670.3436.17.camel@firenze.zurich.ibm.com> Message-ID: <20050330162837.GJ97739@new.detebe.org> Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) wrote: > This makes more sense than giving a /32 to everyone who > feels that their service is "critical". If you analyse the > situation by the 80/20 rule, then Google represents the > 20% of "critical" services that are big enough to be their > own ISP. My suggestion is meant to support the 80% of > "critical" services that could benefit from the same > technology as Google, but which are not large enough to > go it alone. Yet, we do not have a solution (in the RIPE area) for your 20%. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From oppermann at pipeline.ch Wed Mar 30 18:30:09 2005 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 30 Mar 2005 18:30:09 +0200 Subject: [address-policy-wg] Real multihoming or anycast? References: Message-ID: <424AD411.B3A6E39E@pipeline.ch> Michael.Dillon at radianz.com wrote: > > > > Why not learn from the lessons of radio spectrum? A fixed number of > > > 3G frequency allocations were put up for auction (or beauty contest). > > > > > > Why should RIPE not offer a limited number of /32 allocations for > > > operators of anycast fabrics? I suggest that RIPE offer 16 allocations > > > of /32 to organizations who intend to operate diverse anycast fabrics > > > globally to serve TLD operators and others who can benefit from > > > an anycast fabric. Select the winners by beauty contest based on > > > technical and commercial fitness. > > > > Very simple answer for what is possible with _CURRENT_ policy: > > $ whois -h whois.arin.net GOOGLE-IPV6 > > As far as I know, Google is not a service provider. They > operate their own network for their own business. I am > suggesting that a certain number of /32's should be given > to companies which will provide global anycast meshes > as a service to 3rd party customers. That way, TLD operators > can choose one or more anycast hosting services to host > their "critical" service. > > This makes more sense than giving a /32 to everyone who > feels that their service is "critical". If you analyse the > situation by the 80/20 rule, then Google represents the > 20% of "critical" services that are big enough to be their > own ISP. My suggestion is meant to support the 80% of > "critical" services that could benefit from the same > technology as Google, but which are not large enough to > go it alone. Sounds great! Do you work for ITU perhaps? Any such criteria as you propose are broken by design. Even more so than many of the other IPv6 thingies. This is not the way to go. -- Andre From jeroen at unfix.org Wed Mar 30 19:26:05 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 30 Mar 2005 19:26:05 +0200 Subject: [address-policy-wg] Real multihoming or anycast? In-Reply-To: <424AD411.B3A6E39E@pipeline.ch> References: <424AD411.B3A6E39E@pipeline.ch> Message-ID: <1112203565.3436.40.camel@firenze.zurich.ibm.com> On Wed, 2005-03-30 at 18:30 +0200, Andre Oppermann wrote: > Michael.Dillon at radianz.com wrote: > > > > > > Why not learn from the lessons of radio spectrum? A fixed number of > > > > 3G frequency allocations were put up for auction (or beauty contest). > > > > > > > > Why should RIPE not offer a limited number of /32 allocations for > > > > operators of anycast fabrics? I suggest that RIPE offer 16 allocations > > > > of /32 to organizations who intend to operate diverse anycast fabrics > > > > globally to serve TLD operators and others who can benefit from > > > > an anycast fabric. Select the winners by beauty contest based on > > > > technical and commercial fitness. > > > > > > Very simple answer for what is possible with _CURRENT_ policy: > > > $ whois -h whois.arin.net GOOGLE-IPV6 > > > > As far as I know, Google is not a service provider. Which is exactly my point. They don't serve the '200 customer rule'. They might have 200 anycast nodes though, but not disjunct organizations. Unless they reported every tld as a separate org ;) Akamai, who also got an alloc on the same day, might be easily able to claim it though. > They > > operate their own network for their own business. I am > > suggesting that a certain number of /32's should be given > > to companies which will provide global anycast meshes > > as a service to 3rd party customers. That way, TLD operators > > can choose one or more anycast hosting services to host > > their "critical" service. Thus you basically say that TLD operators should go to say, Easynet/Tiscali/Telia/$bigcarriers etc who already have IPv6 connectivity in place and ask them to give them a /48 out of their /32, they can do the carry service and presto? Sounds like a perfect plan, those carriers are already present, can fix their internal routing and usually also have perfect colo facilities in place. But..... this is already there, so why change policy? > > This makes more sense than giving a /32 to everyone who > > feels that their service is "critical". If you analyse the > > situation by the 80/20 rule, then Google represents the > > 20% of "critical" services that are big enough to be their > > own ISP. Every entity that is big enough can always buy themselves what they want, policy or not. > > My suggestion is meant to support the 80% of > > "critical" services that could benefit from the same > > technology as Google, but which are not large enough to > > go it alone. As mentioned above, let them request some address space from one of the larger carriers. Oh oops, there is one problem there, they actually wanted Independent Address Space, that is if they suddenly hate their upstream, it goes belly up etc that they don't have to change anything. Ergo sum they want a slot in the routing table and nothing else. > Sounds great! Do you work for ITU perhaps? > > Any such criteria as you propose are broken by design. Even more > so than many of the other IPv6 thingies. This is not the way to > go. I suspect Andre also to visit the upcoming (May 1+2) ITU/IETF NGN workshop in Geneva? :) See: http://www.itu.int/ITU-T/worksem/ngn/200505/index.html Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From hpholen at tiscali.no Wed Mar 30 21:30:38 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 30 Mar 2005 21:30:38 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503242341.18978.jon@lawrence.org.uk> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <200503242047.12338.jon@lawrence.org.uk> <20050324215454.GA377@srv01.cluenet.de> <200503242341.18978.jon@lawrence.org.uk> Message-ID: <424AFE5E.4070904@tiscali.no> Jon Lawrence wrote: > >>PI will come or IPv6 not fly. Face it. >> >> >> I agree that IPv6 needs multi-homing to fly - but I was hoping there would be other technical implementations of multi-homing than PI. I do however undersand how multi-homing works with PI addresses - I am not shure I can say the same of other proposals. -hph From oliver at bartels.de Wed Mar 30 22:53:14 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 30 Mar 2005 22:53:14 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <424AFE5E.4070904@tiscali.no> Message-ID: <200503302053.j2UKrEp0001461@alpha.bartels.de> On Wed, 30 Mar 2005 21:30:38 +0200, Hans Petter Holen wrote: >I agree that IPv6 needs multi-homing to fly - but I was hoping there >would be other technical implementations of multi-homing than PI. It seems we need a thing called "wonder". Call it PI, Prefix or whatever, here is what we have: - A *arbitrarily* connected set of nodes - called AS'es- in a graph, called "Internet". - A set of destinations, called "prefixes". - Things called "packets", which should be routed thru the graph on a short (best: the shortest) path. If one can find a way to route these packets on the shortest path in any topology without telling the nodes something about each destination, - even a source route is such information and requires knowledge about the structure of the graph - he will probably receive the Fields medal and/or a Nobel price ;-/ The original idea behind the IPv6 TLA, NLA, SLA was a geographical and administrative hierachical design, in the century of *competitive* operators this concept is *broken by design*. In this competitive network world, where operator A charges B for transit, the only chance to implement *true* multihoming is to pass information about the destination to all relevant nodes. But I don't see why we should have a problem doing so. Memory is cheap. However there *are* possible technical improvements, example given: - Use a two level address distribution concept: Level 1 : Pass path information about ISP AS'es only* Level 2 : Flood address origination information separate. ( Example: Multihoming Customer 1 is using AS1 and AS2 for prefix X, Customer 2 is using AS2 and AS3 for prefix Y, then a far AS would see Level 1 : Paths : (AS5 AS4 AS1), (AS5 AS6 AS7 AS2), (AS3) This is sufficient to avoid loops and build policies. Level 2 : Offers: AS1:(X), AS2(X,Y), AS3(Y) No path information is required in these floods. ) - Pass information on demand ( However this should only be done in a two level concept for stability reasons, think of "bad weather" DDoS Flood conditions. ) *However* all this solutions have one impact: - New BGP protocol, new routers, new budget ... Ceterum Censeo: Either there is way to *route* the IPv6 address space, *at least* *with the IPv4 quality* - which means serving the customer demand "true multihoming", or IPv6 is dead. If a large address space is offered, it must be *usable*, which means *routable*, at least with the capabilities of the good old IPv4. No one needs a 40 digit ZIP code for letters for a human postman, a 5 digit code is suffiicient. And a postal service offering 40 digits ZIP codes as "premium service" for standard letters will probably economically fail ;-/ Best Regards Oliver P.s.: Think of UMTS. Design driven by comissions and managers. Today: Billions spend. >270ms ping time. B.t.d.t. Same for IPv6 ?! Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From dr at cluenet.de Thu Mar 31 00:44:35 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 31 Mar 2005 00:44:35 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <424AFE5E.4070904@tiscali.no> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <200503242047.12338.jon@lawrence.org.uk> <20050324215454.GA377@srv01.cluenet.de> <200503242341.18978.jon@lawrence.org.uk> <424AFE5E.4070904@tiscali.no> Message-ID: <20050330224435.GA2488@srv01.cluenet.de> On Wed, Mar 30, 2005 at 09:30:38PM +0200, Hans Petter Holen wrote: > >>PI will come or IPv6 not fly. Face it. > > I agree that IPv6 needs multi-homing to fly - but I was hoping there > would be other technical implementations of multi-homing than PI. > I do however undersand how multi-homing works with PI addresses - I am > not shure I can say the same of other proposals. http://www.6net.org/publications/deliverables/D4.5.3.pdf Interesting reading, especially the nice table on page 31. All proposals on the table fall short. None can provide all the benefits of true multihoming. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Michael.Dillon at radianz.com Thu Mar 31 12:45:59 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 31 Mar 2005 11:45:59 +0100 Subject: [address-policy-wg] Real multihoming or anycast? In-Reply-To: <1112203565.3436.40.camel@firenze.zurich.ibm.com> Message-ID: > > > My suggestion is meant to support the 80% of > > > "critical" services that could benefit from the same > > > technology as Google, but which are not large enough to > > > go it alone. > > As mentioned above, let them request some address space from one of the > larger carriers. I don't know of any large carrier that operates a globally diverse network offering globally diverse hosting of the sort that these anycast meshes need. And I don't think we should be trying to create such things either. However, if we give a /32 to a company who will offer anycast services similar to the anycast services used by some root DNS servers, then we make it possible for TLD operators to buy the anycasting rather than forcing them to build their own. However, if you want to force them to build their own then you have to support giving every one of them their own /32. I think the world is better off if we encourage 3rd parties to build anycast meshes and offer them as a service to TLD operators and others. > Oh oops, there is one problem there, they actually wanted Independent > Address Space, that is if they suddenly hate their upstream, it goes > belly up etc that they don't have to change anything. Ergo sum they want > a slot in the routing table and nothing else. The idea is that anycasting is a solution for services which are "critical" and therefore they need independent address space. However, this could be provided by an anycast mesh operator who aggregates many networks and who offers an escrow agreement in their customer contracts to ensure continuity. Also, if RIPE enables several of these anycast meshes, I would expect that most TLD operators would use two or three independent anycast meshes. When you consider that they can easily use up to 13 IP addresses, it is easy to configure 3 addresses from 3 different anycast mesh operators, along with 10 diverse unicast addresses. > See: http://www.itu.int/ITU-T/worksem/ngn/200505/index.html I really don't see how the ITU is relevant here. This has nothing to do with them. It is all about Internet infrastructure and Internet addressing. --Michael Dillon From Michael.Dillon at radianz.com Thu Mar 31 12:51:59 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 31 Mar 2005 11:51:59 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503302053.j2UKrEp0001461@alpha.bartels.de> Message-ID: > The original idea behind the IPv6 TLA, NLA, SLA was a geographical > and administrative hierachical design, in the century of *competitive* > operators this concept is *broken by design*. It was never tried so how can you say that it was broken by design? The IPv6 is so vast that perhaps we should offer some address space to be allocated by geography and see where it leads to. Let the market decide rather than forcing everyone into the "one true way". > *However* all this solutions have one impact: > - New BGP protocol, new routers, new budget ... New routers? Since when does BGP or any routing protocol have to run on the routers themselves. Look inside a modern router and you will often see that the routing and packet forwarding decisions are done on separate CPUs. And there are boxes on the market that do "route optimization" which is just a way of taking the routing decisions outside of the routers themselves. --Michael Dillon From he at uninett.no Thu Mar 31 15:54:21 2005 From: he at uninett.no (Havard Eidnes) Date: Thu, 31 Mar 2005 15:54:21 +0200 (CEST) Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: <200503302053.j2UKrEp0001461@alpha.bartels.de> Message-ID: <20050331.155421.67802696.he@uninett.no> > > The original idea behind the IPv6 TLA, NLA, SLA was a > > geographical and administrative hierachical design, in the > > century of *competitive* operators this concept is *broken by > > design*. > > It was never tried so how can you say that it was broken > by design? The IPv6 is so vast that perhaps we should offer > some address space to be allocated by geography and see where > it leads to. Let the market decide rather than forcing everyone > into the "one true way". If I've understood correctly, geographical addressing will lead to forced interconnection of providers in the geographical area (some might think this is good) but also of carriage of transit traffic destined to other providers' customers, i.e. you as a provider would be forced to shoulder costs with no way to recover them. Ensuring some semblance of equality of this burden for such interconnected providers appears difficult, and requires tight cooperation among them, which is "somewhat" at odds with the idea of independence and competition. Regards, - H?vard From Michael.Dillon at radianz.com Thu Mar 31 16:20:21 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 31 Mar 2005 15:20:21 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <20050331.155421.67802696.he@uninett.no> Message-ID: > If I've understood correctly, geographical addressing will lead > to forced interconnection of providers in the geographical area It would only be forced if geographical IPv6 addressing was the only kind available. But if geo IPv6 addressing is offered as an option, then market forces can sort out which way is better. To allow market forces to work, you would have to offer every company, both kinds of IPv6 addresses. > but also of carriage of transit > traffic destined to other providers' customers, i.e. you as a > provider would be forced to shoulder costs with no way to recover > them. One would assume that if you interconnect with your geographical neighbours for the purposes of exchanging geo-addressed traffic then you would also work out a cost-sharing agreement of some sort. As long as geo-addressing is optional, this type of problem will not exist. In the end we may find that geo-addressing dominates in some parts of the world, where it suits their culture and communication patterns. And the current random addressing dominates in other parts of the world, such as the USA, where chaos is highly valued in the culture. I don't see geo-addressing as a cure-all, just an option that we should make available using the vast reserved space in IPv6. 50 years from now the Internet will not be able to cope with global routing table size using the existing random addressing scheme because every small and mid-sized company will want to be multi-homed. Multi-homing is something that people learn to need when they see the disasters that happen to single-homed companies. Over time, basically every organization will want to be multi-homed in order to spread the risk. In fact, it may become a requirement of many business insurance policies. In a world where geo-addressing is widespread, a North American ISP can have a single route for all of Europe. A small German company can have geo-addresses, and be connected to three local ISPs who all peer locally to exchange geo-addressed traffic. Any two of those three ISPs can go off-line and the small German company will still be fully connected. We have enough knowledge of intercontinental cable routes today in order to design a geographical aggregation topology. There are unlikely to be any significantly new intercontinental or overland paths that could not be predicted based on today's knowledge. It would make an interesting university research project to design such an addressing topology and I hope that someone will take up the challenge. Until we have this kind of work on the table to discuss, it is hard to prove that geographic addressing will work or that it won't work. --Michael Dillon P.S. if anyone here is under the illusion that I am talking about assigning IPv6 addresses to countries in the same way as E.164 addressing, then you should check the difference between geographical and geopolitical in the dictionary. From oliver at bartels.de Thu Mar 31 16:35:08 2005 From: oliver at bartels.de (Oliver Bartels) Date: Thu, 31 Mar 2005 16:35:08 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: Message-ID: <200503311435.j2VEZ8p0022007@alpha.bartels.de> On Thu, 31 Mar 2005 11:51:59 +0100, Michael.Dillon at radianz.com wrote: >It was never tried so how can you say that it was broken >by design? I also never tried to drive my car with 200km/h against a tree but I can tell you definately its no good ... Geographical hierachies require a interconnection concept which is radically different from the concept required for a *competitive* ISP market. They would require "leading" operators and "sub-level" operators dependent from them. The time of "postal office" monopolies is over, *and this is good so*. >New routers? Since when does BGP or any routing protocol >have to run on the routers themselves. Look inside a modern >router and you will often see that the routing and >packet forwarding decisions are done on separate CPUs. >And there are boxes on the market that do "route optimization" >which is just a way of taking the routing decisions outside >of the routers themselves. At the end of day one - might require an update of a underdimensioned forwarding engine. - a new router because $VENDOR might not be willing to implement "IPv6-BGP 4+x" on an old box. I am not talking about *can't* implement, but the chance is high that $VENDOR sees this as an oportunity to gain additional $REVENUE. If you have a ten year old car, you probably won't get an "update" for the latest engine. The whole table discussion is just because of this resource-limiting policy build by several $VENDORS and some operators living in the past century with good old postal telco office "offical" services ("Bundespost"). Take 1 Mio. prefixes with 100 Byte (!) each. And 100 Byte is a *lot*, even with communities and paths, which even can be combined for several prefixes together in memory. This is 100 MByte. No problem today. Why do we talk about the table size here ? And in fact, if one would combine all IPv6 prefixes of some ISP in a *bundle* (remember my level 1/2 proposal), with e.g. 8 Byte routable address part, one mask length byte plus 7 bytes other stuff, we are talking about 16 bytes. 10 Mio. (!) prefixes are then 160 MBytes. Again no problem today. In this scenario you might give each customer its own prefix, if he want's one or not ... Conclusion: The "table problem" is a pseudo-problem and is easily solvalble with modern hardware. With more than 500K to 1 Mio. prefixes it might be usefull to think of a new two level BGP4. Below that: Take BGP4 as it is, no problem. +20K IPv6 Routes: Again no problem. We had an 30% increase in the number of IPv4 Routes and *nothing* happened. I am a friend of open words: - The *real* problem is that some big companies would be happy with a hierachical structure - of course with them on top of the hierachy :-| - and with totally dependend customers and smaller ISP's. - And there is a reluctance to invest into modern hardware, probably because of the dumping price offers within the ISP market. * These * are the points, not technology, not hardware or software. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From oliver at bartels.de Thu Mar 31 16:40:41 2005 From: oliver at bartels.de (Oliver Bartels) Date: Thu, 31 Mar 2005 16:40:41 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: Message-ID: <200503311440.j2VEeep0022097@alpha.bartels.de> On Thu, 31 Mar 2005 15:20:21 +0100, Michael.Dillon at radianz.com wrote: >We have enough knowledge of intercontinental cable routes >today in order to design a geographical aggregation topology. Do you *really* think anyone is willing to invest *real* money into a *real* project for a geographical aggregation topology ? Especially as switching and digging new cables can be avoided by putting a bit more computing power into these boxes called routers ? And all this in a world, where certain "we think we are big" operators are refusing peerings with smaller ISP's ? Do you *really* think these "big is best" policy operators would change their dominating policy for a geographical concept ? Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From Michael.Dillon at radianz.com Thu Mar 31 17:23:36 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 31 Mar 2005 16:23:36 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503311435.j2VEZ8p0022007@alpha.bartels.de> Message-ID: > Geographical hierachies require a interconnection concept > which is radically different from the concept required for a > *competitive* ISP market. They would require "leading" > operators and "sub-level" operators dependent from them. Not true. Geographical addressing means that a provider uses addresses from a city aggregate for all infrastructure and customers in that city. The city aggregate would be determined and administered by RIPE. All providers who have infrastructure in Paris, for instance, would ask RIPE for the number of Paris addresses that they need, regardless of the size of the operator or their dominance in the market. There already are "leading" operators and "sub-level" operators in the Internet access market. Geo addressing does not change this because geo-addressing is a technical solution to a technical problem of packet routing. > >New routers? Since when does BGP or any routing protocol > >have to run on the routers themselves. Look inside a modern > >router and you will often see that the routing and > >packet forwarding decisions are done on separate CPUs. > >And there are boxes on the market that do "route optimization" > >which is just a way of taking the routing decisions outside > >of the routers themselves. > At the end of day one > - might require an update of a underdimensioned forwarding engine. > - a new router because $VENDOR might not be willing to implement > "IPv6-BGP 4+x" on an old box. The vendor doesn't need to implement IPv6-BGP-4+x on the router if servers in the operator's management systems are doing the IPv6-BGP 4+x function and passing the instructions to the routers using plain BGP4. And the whole point of geo addressing is to avoid the update of underdimensioned forwarding engines when insurance companies require every company to be multihomed in order to qualify for business insurance. Why is it necessary for routers to speak BGP in order to maintain a view of the relatively stable mesh of AS interconnections? Why don't more people do this work with servers which are faster and cheaper and easier to swap(upgrade) than routers? --Michael Dillon From Michael.Dillon at radianz.com Thu Mar 31 17:26:42 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 31 Mar 2005 16:26:42 +0100 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <200503311440.j2VEeep0022097@alpha.bartels.de> Message-ID: > >We have enough knowledge of intercontinental cable routes > >today in order to design a geographical aggregation topology. > Do you *really* think anyone is willing to invest *real* money > into a *real* project for a geographical aggregation topology ? Yes I do. I know for a fact that universities invest a lot of real money into network research to evaluate many, many different possible futures. I regularly read research papers about these things and I think that design of a feasible geo-addressing topology is exactly the kind of thing that a university researcher or grad student would do. --Michael Dillon From oliver at bartels.de Thu Mar 31 17:38:08 2005 From: oliver at bartels.de (Oliver Bartels) Date: Thu, 31 Mar 2005 17:38:08 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: Message-ID: <200503311538.j2VFc8p0024005@alpha.bartels.de> On Thu, 31 Mar 2005 16:23:36 +0100, Michael.Dillon at radianz.com wrote: >Geographical addressing means that a provider uses addresses >from a city aggregate for all infrastructure and customers >in that city. The city aggregate would be determined and >administered by RIPE. All providers who have infrastructure >in Paris, for instance, would ask RIPE for the number of >Paris addresses that they need, regardless of the size of >the operator or their dominance in the market. I don't see the point behind this, you would create even *more* table entries with this approach. There is operator A with customers in Paris, London and Berlin and operator B with customers in London, Manchester and Birmingham. Result: 6 Prefixes instead of 2. Why: Operator networks are *not* interconnected in regional area categories and prefer internal and peer routes instead of regional upstreams. >There already are "leading" operators and "sub-level" operators >in the Internet access market. Geo addressing does not change >this because geo-addressing is a technical solution to a >technical problem of packet routing. Sorry, I don't see this as an solution. This is the old Telco approach which works with *one* main operator in Paris, one in London etc. It does not work in a market with non-regional variable interconnections. E.g. we prefer to receive our traffic for Stuttgart in Munich or Frankfurt, because in Stuttgart there is no international exchange. >And the whole point of geo addressing is to avoid the update >of underdimensioned forwarding engines when insurance companies >require every company to be multihomed in order to qualify >for business insurance. Ceterum Censeo: Routing capacity can only be replaced by routing capacity. Someone has to *calculate* the best path for the IP packets and this someone is called "router". Either it can handle the address space or it cannot, in the second case IPv6 is *useless*. The point: There is no way to make a 1 H.P. 1900 car competitive in a Formula One race. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0