From kurtis at kurtis.pp.se Thu Dec 1 09:11:48 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 1 Dec 2005 09:11:48 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130161647.GA12947@srv01.cluenet.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> Message-ID: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> On 30 nov 2005, at 17.16, Daniel Roesen wrote: > ISPs do exist for customers, not customers do exist to feed ISPs > in the > most convenient way for the ISPs. Some folks seem to forget that, > looking at all the discussion trying to ignore the demand for real > multihoming (and that includes TE and network-wide routing policy > implementation, neither being delivered by things like shim6). I think you are contradicting yourself here. Shim6 does give the end- user TE capability. It does not give the ISP the possibility to ignore it, as they could today. I am not sure what you mean with "network-wide routing policy implementation".... I have still to figure out what the "real multihoming" thing is, but I am sure it must be beautiful. > HOW the requirements are being delivered is another topic. multi6 has > resulted in the decision to ignore many critical requirements. We're > just asking for something that delivers on the targets. Wasting time > with half-solutions is not productive. Halting any development because > the magic bullet wasn't found yet ain't either. If you have alternative ideas you know how it works - send text. - kurtis - From heldal at eml.cc Thu Dec 1 11:37:20 2005 From: heldal at eml.cc (Per Heldal) Date: Thu, 01 Dec 2005 11:37:20 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> Message-ID: <1133433440.15956.248746502@webmail.messagingengine.com> On Thu, 1 Dec 2005 09:11:48 +0100, "Kurt Erik Lindqvist" said: > > On 30 nov 2005, at 17.16, Daniel Roesen wrote: > > > ISPs do exist for customers, not customers do exist to feed ISPs > > in the > > most convenient way for the ISPs. Some folks seem to forget that, > > looking at all the discussion trying to ignore the demand for real > > multihoming (and that includes TE and network-wide routing policy > > implementation, neither being delivered by things like shim6). > > I think you are contradicting yourself here. Shim6 does give the end- s/does/may ? ;) > user TE capability. It does not give the ISP the possibility to > ignore it, as they could today. Shim6 is work in progress and may be used as an argument to adjust adress-assignment policies sometime in the future. If we want ipv6 deployed today we have to provide a mechanism to support requirements about redundancy and independence from individual providers. > I am not sure what you mean with > "network-wide routing policy implementation".... I guess this relates to supporting infrastructure necessary for shim6 to support or replace current ipv4 technology like load-balancing, filtering etc. If standards are defined today and everyone agree to implement them asap it will still take years before such products are available and a commercially viable alternative. Shim6 has a potential to provide improved "granularity" in traffic management (individual path-selection for each source-destination HBA-pair) but that is irrelevant until the technology is actually there. Bottom line: it's fine to develop technology for the future, but operational procedures and policies must be supported by current technology. //per -- Per Heldal heldal at eml.cc From randy at psg.com Thu Dec 1 12:01:12 2005 From: randy at psg.com (Randy Bush) Date: Thu, 1 Dec 2005 01:01:12 -1000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> Message-ID: <17294.55288.858722.708230@roam.psg.com> > If you have alternative ideas you know how it works - send text. draft-ietf-ipngwg-gseaddr-00.txt same one the ietf has ignored and lied about for eight years now randy From cgray at netegral.co.uk Thu Dec 1 11:44:50 2005 From: cgray at netegral.co.uk (Cameron C. Gray) Date: Thu, 01 Dec 2005 10:44:50 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133433440.15956.248746502@webmail.messagingengine.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> Message-ID: <438ED422.9090904@netegral.co.uk> Per Heldal wrote: > Shim6 is work in progress and may be used as an argument to adjust > adress-assignment policies sometime in the future. If we want ipv6 > deployed today we have to provide a mechanism to support requirements > about redundancy and independence from individual providers. I think this hit the nail on the head. Providers (especially those non-LIR) will not accept something along the lines of SHIM6 or A.N.Other competing idea until it gives them just that -- INBOUND ROUTING INDEPENDENCE. The only way these people see achieving this is if they can announce their prefix (of whatever size or status) to each of their providers and have it form part of everybody's tables. Personally I don't have a view either way as whether it should be PI or Special Assignments or Become-A-LIR to achieve it, although everyones fees will drop with more LIRs (read: members). My view is relatively simple; either give everyone who wants one and has an AS-Number a /32 or allow /48s into the backbone table. This is of course if we actually want to give up using IPv4; without the above most providers will see it as a step backward and a bad thing (tm). I am fast gathering this is an unpopular position so I'll get the asbestos underwear ready, but in the smaller circles (read: Tier 3 and below) this is an absolute requirement. -- Best Regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | 0871 277 6845 From Michael.Dillon at btradianz.com Thu Dec 1 12:44:27 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 1 Dec 2005 11:44:27 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438ED422.9090904@netegral.co.uk> Message-ID: > The only way these people see achieving this is if they can announce > their prefix (of whatever size or status) to each of their providers and > have it form part of everybody's tables. Why should it form part of EVERYBODY's tables? If we had geotop addressing then people could announce their prefix (of whatever size or status) to each of their providers and it would only form part of the tables in the same geotopological aggregate, i.e. the same city. The rest of the world will not see it at all. There is a REAL problem with assuming that there will be a *SINGLE* global routing table. We know that there are limits to the growth of the global routing table due to RAM capacity of routers, CPU capacity of routers and the time required to load a full set of announcements over the circuits connecting to peers. These are all hard limits that require cash, and business cases in order to extend them. We cannot assume that announcing a route will result in it being added to the global routing table. It is highly likely that ISPs will filter announcements on one basis or another in order to keep their copy of the global routing table small enough for their network to handle. The end result is fragmentation into many global routing tables, none of which are complete. And this equals fragmentation of the Internet with widespread inability to reach other sites. --Michael Dillon From jeroen at unfix.org Thu Dec 1 13:51:18 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 01 Dec 2005 13:51:18 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: References: Message-ID: <438EF1C6.7040708@unfix.org> Michael.Dillon at btradianz.com wrote: >> The only way these people see achieving this is if they can announce >> their prefix (of whatever size or status) to each of their providers and >> have it form part of everybody's tables. > > Why should it form part of EVERYBODY's tables? > > If we had geotop addressing then people could announce their prefix > (of whatever size or status) to each of their providers and it would > only form part of the tables in the same geotopological aggregate, > i.e. the same city. The rest of the world will not see it at all. The huge problem with this is the costs model, who to charge for what. Next to that the person you quotes wants "full control" which is something he won't get when you do geo addressing, at least not with the proposals made so far. PS: Could you please keep attribution, looking into the archives or other mails to find out who you are quoting above is really annoying. > We cannot assume that announcing a route will result in it > being added to the global routing table. It is highly likely > that ISPs will filter announcements on one basis or another > in order to keep their copy of the global routing table small > enough for their network to handle. There is a simple answer here: pay enough cash to people and they will route anything you like. At a certain point only "payed prefixes" will be accepted and the rest can be filtered. Maybe a model where one can get a /48 from the RIR's when they pay them say $1000 dollar/month, the RIR then marks this prefix as 'payed' in the registry so that ISP's can filter on it will become viable at a certain point. Not paying your fee will make you filtered. *dream of global fully automated setups*. But this might already come with hopefully the (BGP) certificates that APNIC (*) is introducing. When your payment period expires and one didn't renew you don't have a valid certificate and thus your announcements are not accepted anymore... IP's will then really start costing money, but hey if your business is doing good, and you need the addresses then you get revenue for them anyway, simple business 101. Greets, Jeroen * = http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-address-certificate.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From hph at oslo.net Thu Dec 1 15:57:51 2005 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 01 Dec 2005 15:57:51 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130162129.GB12947@srv01.cluenet.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> Message-ID: <438F0F6F.5050409@oslo.net> Daniel Roesen wrote: > > BTW... in Germany, the phone operators were forced to implement phone > number portability by law. The regulator didn't care about all the > whining from the telcos about that being impossible, uneconomic, the > world will explode etc. If they manage to get that imposed on the > traditional telcos, I wonder how much easier it will be to do that on > the ISPs. > Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering. Hans Petter From president at ukraine.su Thu Dec 1 16:30:15 2005 From: president at ukraine.su (Max Tulyev) Date: Thu, 1 Dec 2005 18:30:15 +0300 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F0F6F.5050409@oslo.net> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> Message-ID: <200512011830.15947.president@ukraine.su> > Very easy. In the Internet the equivalent of phone numers, the DNS names > are alleady portable - so you can easily switch ISP and keep your email > address and URLs without renumbering. Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of them is even not under your control. You have 10 servers to host them (i.e. you need 10 IPs). Changing ISP is really easy? To be a LIR and grab /20 if really need only /28? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jeroen at unfix.org Thu Dec 1 16:53:44 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 01 Dec 2005 16:53:44 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <200512011830.15947.president@ukraine.su> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <200512011830.15947.president@ukraine.su> Message-ID: <438F1C88.8050901@unfix.org> Max Tulyev wrote: >> Very easy. In the Internet the equivalent of phone numers, the DNS names >> are alleady portable - so you can easily switch ISP and keep your email >> address and URLs without renumbering. > > Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of > them is even not under your control. You have 10 servers to host them (i.e. > you need 10 IPs). > Changing ISP is really easy? > > To be a LIR and grab /20 if really need only /28? With a /28 you won't appear far in the current IPv4 routing tables either. Most sites filter prefixes longer than 24. How do you currently use such a /28 as PI? Or did you become a LIR and got that /20, just like is possible now with IPv6? As an exercise for the readers try to remember why there are filters on IPv4 /24 boundaries and the try to figure out why there are quite a number of people not wanting IPv6 PI to fill their IPv6 routing tables. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From elmi at 4ever.de Thu Dec 1 17:13:27 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 1 Dec 2005 17:13:27 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F1C88.8050901@unfix.org> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <200512011830.15947.president@ukraine.su> <438F1C88.8050901@unfix.org> Message-ID: <20051201161326.GP44731@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > > To be a LIR and grab /20 if really need only /28? > > With a /28 you won't appear far in the current IPv4 routing tables > either. Most sites filter prefixes longer than 24. > How do you currently use such a /28 as PI? Or did you become a LIR and > got that /20, just like is possible now with IPv6? > > As an exercise for the readers try to remember why there are filters on > IPv4 /24 boundaries and the try to figure out why there are quite a > number of people not wanting IPv6 PI to fill their IPv6 routing tables. Even to the risk of upsetting you... These filters do not exist to blind out small PI assignments, they are in place to remove accidental leakage of IGP prefixes caused by some fat-fingered jerk like myself... Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From president at ukraine.su Thu Dec 1 17:28:41 2005 From: president at ukraine.su (Max Tulyev) Date: Thu, 1 Dec 2005 19:28:41 +0300 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F1A92.5080105@oslo.net> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <200512011830.15947.president@ukraine.su> <438F1A92.5080105@oslo.net> Message-ID: <200512011928.41342.president@ukraine.su> > Last time I was a hosting proivider I signed up as a LIR and built my > own network infrastructure to the nearest IX points. > This time I have outrourced the lot and my 300 server serverfarm is > behind a firewall on a handfull of IP addresses > > Changing ISP is really easy? > Yes. Stop. You have 10000 domains. You have IP address(es) from ISP A . You are moving to ISP B with OTHER address(es). And you don't need to send 10000 modify requests for these 10000 domains to change A (NS, MX) records. Where is the magic? ;-) > > To be a LIR and grab /20 if really need only /28? > Depends. Today I manage with a /23 PI or PA? Your own or upstream's? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From fw at deneb.enyo.de Thu Dec 1 17:34:23 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 01 Dec 2005 17:34:23 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F0F6F.5050409@oslo.net> (Hans Petter Holen's message of "Thu, 01 Dec 2005 15:57:51 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> Message-ID: <87mzjkkc8g.fsf@mid.deneb.enyo.de> * Hans Petter Holen: > Very easy. In the Internet the equivalent of phone numers, the DNS names > are alleady portable - so you can easily switch ISP and keep your email > address and URLs without renumbering. I can't put DNS names on network interfaces. But I can use private address space and NAT, or public address space, DNS rewriting and double NAT. Not pretty, but gets the job done. From jeroen at unfix.org Thu Dec 1 18:30:05 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 01 Dec 2005 18:30:05 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87mzjkkc8g.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> Message-ID: <438F331D.3060208@unfix.org> [multiple messages compressed into one] Florian Weimer wrote: > * Hans Petter Holen: > >> Very easy. In the Internet the equivalent of phone numers, the DNS names >> are alleady portable - so you can easily switch ISP and keep your email >> address and URLs without renumbering. > > I can't put DNS names on network interfaces. But I can use private > address space and NAT, or public address space, DNS rewriting and > double NAT. Not pretty, but gets the job done. (psst... 'double NAT' is one of the things shim6 is going to use) As for "DNS rewriting" any example of that? bmanning at vacation.karoshi.com wrote: > On Thu, Dec 01, 2005 at 04:53:44PM +0100, Jeroen Massar wrote: >> As an exercise for the readers try to remember why there are >> filters on >> IPv4 /24 boundaries and the try to figure out why there are quite a >> number of people not wanting IPv6 PI to fill their IPv6 routing >> tables. > > one might also ask why a RIB/FIB entry has more relevance > for one size prefix instead of another. Ease of filtering. Not much more. The 'worthiness' of a prefix depends more on the service provided in that prefix. One for instance would not really want to loose the connectivity to all the DNS root or TLD servers and most ISP's will have a nice red glowing phone when connectivity to google/msn etc is broken. Max Tulyev wrote: >> Last time I was a hosting proivider I signed up as a LIR and built my >> own network infrastructure to the nearest IX points. >> This time I have outrourced the lot and my 300 server serverfarm is >> behind a firewall on a handfull of IP addresses >>> Changing ISP is really easy? >> Yes. > > Stop. You have 10000 domains. You have IP address(es) from ISP A . > You are moving to ISP B with OTHER address(es). And you don't need to > send 10000 modify requests for these 10000 domains to change A (NS, > MX) records. Where is the magic? ;-) The same as the phone number system. One at a time. Or script your setup, you do know what 'management software' means do you? Look up the term ITIL or ASL once ;) With such a setup I suggest you outsource your "ISP" to the real ISP or plan ahead and become real good friends with your current ISP. You need a /28 and want "Provider Independence". I use a /28 at home. Lets say that I want "PI" too, that would mean I am going to get, pay for and maintain: - Multiple Redundant Routers - Multiple Redundant Links - Multiple Redundant Transits - Own 24/7 NOC (things will fail) - and a lot more... You are willing to do and pay for all that, but don't want to become an LIR? Nah, I rather let some real ISP handle all of that, they have the time to fiddle with peering and transit agreements, billing and all kinds of other time consuming things. Elmar K. Bins wrote: > Even to the risk of upsetting you... How can you calling yourself a 'fat-fingered jerk' upset me ? :) > These filters do not exist to blind out small PI assignments, they are > in place to remove accidental leakage of IGP prefixes caused by some > fat-fingered jerk like myself... So you filter on a /24 because of IGP, thus you will leak out a /23? Adding 8 or so prefixes doesn't really get noticed by many people, but adding 10k does. Filtering based on routing-DB information is thus much better than doing it based on some arbitrary limit. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From gih at apnic.net Thu Dec 1 19:09:23 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 02 Dec 2005 05:09:23 +1100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <17294.55288.858722.708230@roam.psg.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <17294.55288.858722.708230@roam.psg.com> Message-ID: <6.2.0.14.2.20051202045722.02de10b0@kahuna.telstra.net> At 10:01 PM 1/12/2005, Randy Bush wrote: > > If you have alternative ideas you know how it works - send text. > >draft-ietf-ipngwg-gseaddr-00.txt > >same one the ietf has ignored and lied about for eight years now I was not directly involved here, so when I looked into this a little, then I found the document draft-ietf-ipngwg-esd-analysis-05.txt was the ultimate version of a draft responding to the GSE approach. The observation that neither the GSE document, nor this response, ever made it past drafts could be an indicator that there may be more to this story than can be found in the IETF drafts from the period 1997 - 2000. I certainly found it interesting to review these two documents side by side, and others who may also be wondering what happened to GSE may find it useful to read the ESD analysis Geoff From randy at psg.com Thu Dec 1 19:55:30 2005 From: randy at psg.com (Randy Bush) Date: Thu, 1 Dec 2005 08:55:30 -1000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <17294.55288.858722.708230@roam.psg.com> <6.2.0.14.2.20051202045722.02de10b0@kahuna.telstra.net> Message-ID: <17295.18210.797714.378814@roam.psg.com> > I was not directly involved here, so when I looked into this a little, then > I found the document draft-ietf-ipngwg-esd-analysis-05.txt was the > ultimate version of a draft responding to the GSE approach. The > observation that neither the GSE document, nor this response, > ever made it past drafts could be an indicator that there may be more > to this story than can be found in the IETF drafts from the period > 1997 - 2000. I certainly found it interesting to review these two > documents side by side, and others who may also be wondering > what happened to GSE may find it useful to read the ESD analysis and that was the lie. in fact, the gse proposal was not reviewed for security and found wanting. many of the authors of the second document have since recanted. you also may want to read http://www.cs.columbia.edu/~smb/papers/esd-secure.txt randy From rogerj at jorgensen.no Thu Dec 1 20:14:44 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Thu, 1 Dec 2005 20:14:44 +0100 (CET) Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide tofix I Pv6 In-Reply-To: <17295.18210.797714.378814@roam.psg.com> References: <87slt m3p3n.fsf@mid.deneb.enyo.de><4386E053.73B661B3@networx.ch><43886509.6060600@unfix.org><87acf r1mjl.fsf@mid.deneb.enyo.de><002f01c5f43a$12631110$44eea2d5@l><6.2.0.14.2.2 0051129101355.02919160@kahuna.telstra.net><87fypfpm1e.fsf@mid.deneb.enyo.de ><6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net><20051130161647.GA1 2947@srv01.cluenet.de><08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se><1 7294.55288.858722.708230@roam.psg.com><6.2.0.14.2.20051202045722.02de10b0@k ahuna.telstra.net> <17295.18210.797714.378814@roam.psg.com> Message-ID: I might totaly missunderstand you, but I get the feeling you want us to go back to the root of the IPv6 discussion when it all was started and use some of the stuff that was done before instead of trying to figure it all out again? On Thu, 1 Dec 2005, Randy Bush wrote: > > and that was the lie. in fact, the gse proposal was not reviewed > for security and found wanting. many of the authors of the second > document have since recanted. > > you also may want to read > > http://www.cs.columbia.edu/~smb/papers/esd-secure.txt -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From randy at psg.com Thu Dec 1 20:24:58 2005 From: randy at psg.com (Randy Bush) Date: Thu, 1 Dec 2005 09:24:58 -1000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide tofix IPv6 Message-ID: <17295.19978.955771.823645@roam.psg.com> [ something did some horrifying things to the header of your mail as i received it, in particular the references: line, see appended. so i had to chop the refs off my reply. apologies to those who thread based on it. ] > I might totaly missunderstand you, but I get the feeling you want > us to go back to the root of the IPv6 discussion when it all was > started and use some of the stuff that was done before instead of > trying to figure it all out again? yep. though, since i come from the perspective of living it all these years, the "go back" part is a recent view :-). i.e. sane operational folk have been sining this song for years. there has been an amazing lack of ears listening to it. randy --- line breaks are not from here! References: <87slt m3p3n.fsf at mid.deneb.enyo.de><4386E053.73B661B3 at networx.ch><43886509.6060600 at unfix.org><87acf r1mjl.fsf at mid.deneb.enyo.de><002f01c5f43a$12631110$44eea2d5 at l><6.2.0.14.2.2 0051129101355.02919160 at kahuna.telstra.net><87fypfpm1e.fsf at mid.deneb.enyo.de ><6.2.0.14.2.20051130053430.02d015d0 at kahuna.telstra.net><20051130161647.GA1 2947 at srv01.cluenet.de><08D2E092-8FB3-4C5D-9837-4433C77F0B46 at kurtis.pp.se><1 7294.55288.858722.708230 at roam.psg.com><6.2.0.14.2.20051202045722.02de10b0 at k ahuna.telstra.net> <17295.18210.797714.378814 at roam.psg.com> From elmi at 4ever.de Thu Dec 1 21:03:19 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 1 Dec 2005 21:03:19 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F331D.3060208@unfix.org> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> Message-ID: <20051201200319.GS44731@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > Elmar K. Bins wrote: > How can you calling yourself a 'fat-fingered jerk' upset me ? :) ;-) > > These filters do not exist to blind out small PI assignments, they are > > in place to remove accidental leakage of IGP prefixes caused by some > > fat-fingered jerk like myself... > > So you filter on a /24 because of IGP, thus you will leak out a /23? Wrong train of thought. I am of course not leaking anything from my network (first, I train my fingers every day, so they don't get fat, second, I do not redistribute IGP prefixes). The /24 filters we are talking about here are filtering other people's longer-than-/24s out. The /24 filter is just a partly brain-damaged, partly geniously simple way of removing a lot of fat-fingering from my routing table (I am not one of the big transit ISPs, so I'm very happy with that). > Adding 8 or so prefixes doesn't really get noticed by many people, but > adding 10k does. There are companies that run a /20 or bigger nicely sliced into small networks (hundreds or thousands), and sometimes their IGP prefixes leak. > Filtering based on routing-DB information is thus much > better than doing it based on some arbitrary limit. The effort of rebuilding an appropriate ACL every day, the length of the ACL and the router processing degradation or - even worse - running into hard limits, alongside the "update how often?" question prohibit that largely. Of course, having an up-to-date ACL in sync with the routing databases would be the ideal solution, or would it? How many people don't register? How many DBs are there to track? Well... But you have distracted me from the matter at hand, so I repeat again that the /24 filters are not in place to filter out small PI blocks. It's not nice, it's not perfect, but it's there. So any authority that gives out networks (hello RIPE!) should consider everything longer than a /24 as "non routable", and not give out such blocks as v4 PI. Cheers, Elmi. From elmi at 4ever.de Thu Dec 1 21:05:57 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 1 Dec 2005 21:05:57 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F331D.3060208@unfix.org> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> Message-ID: <20051201200556.GT44731@new.detebe.org> Oh, I overlooked that part of your email, but it shows part of your misconception... jeroen at unfix.org (Jeroen Massar) wrote: > You need a /28 and want "Provider Independence". I use a /28 at home. > Lets say that I want "PI" too, that would mean I am going to get, pay > for and maintain: > - Multiple Redundant Routers > - Multiple Redundant Links > - Multiple Redundant Transits > - Own 24/7 NOC (things will fail) > - and a lot more... > > You are willing to do and pay for all that, but don't want to become an > LIR? The point to this is, that with v6 it is not sufficient to be a LIR to get an independently routable block. You can have as many AS numbers as you want - you get them, when you need them - but you will simply not get a v6 block if you do not have 200 customers, prospective or not. That's the independently-networking end-user problem we have. PI would solve that. Removal of the 200 customer rule would solve that. One-block- per-LIR would solve that. Elmar. From woeber at cc.univie.ac.at Thu Dec 1 22:54:44 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Dec 2005 21:54:44 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201200319.GS44731@new.detebe.org> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200319.GS44731@new.detebe.org> Message-ID: <438F7124.4020801@cc.univie.ac.at> Elmar K. Bins wrote: [ ... ] > But you have distracted me from the matter at hand, so I repeat again that > the /24 filters are not in place to filter out small PI blocks. It's not > nice, it's not perfect, but it's there. So any authority that gives out > networks (hello RIPE!) should consider everything longer than a /24 as > "non routable", and not give out such blocks as v4 PI. >From ripe-357 ( http://www.ripe.net/ripe/docs/pi-requestsupport.html ), Supporting Notes for the Provider Independent (PI) Assignment Request Form "You must ensure that the End User understands and accepts that PI address space may be more difficult or more expensive to route than PA address space and then confirm this in the "confirmation:" field. You can find more details on the consequences and disadvantages of PI address space in the "IPv4 Address Allocation and Assignment Policy for the RIPE region" (see above for url)." > Cheers, > Elmi. > > From elmi at 4ever.de Thu Dec 1 23:02:36 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 1 Dec 2005 23:02:36 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F7124.4020801@cc.univie.ac.at> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200319.GS44731@new.detebe.org> <438F7124.4020801@cc.univie.ac.at> Message-ID: <20051201220236.GY44731@new.detebe.org> woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) wrote: > From ripe-357 ( http://www.ripe.net/ripe/docs/pi-requestsupport.html ), > Supporting Notes for the Provider Independent (PI) Assignment Request Form (which I know quite well) Yes, of course nobody guarantees routeability. That's impossible. But even RIPE has changed PI assignment policy a couple of years ago and doesn't give out longer-than-/24 any more. That's not guaranteeing anything, but it raises the probability. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From bmanning at vacation.karoshi.com Thu Dec 1 17:31:10 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 1 Dec 2005 16:31:10 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F1C88.8050901@unfix.org> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <200512011830.15947.president@ukraine.su> <438F1C88.8050901@unfix.org> Message-ID: <20051201163110.GB20986@vacation.karoshi.com.> On Thu, Dec 01, 2005 at 04:53:44PM +0100, Jeroen Massar wrote: > Max Tulyev wrote: > >> Very easy. In the Internet the equivalent of phone numers, the DNS names > >> are alleady portable - so you can easily switch ISP and keep your email > >> address and URLs without renumbering. > > > > Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of > > them is even not under your control. You have 10 servers to host them (i.e. > > you need 10 IPs). > > > Changing ISP is really easy? > > > > To be a LIR and grab /20 if really need only /28? > > With a /28 you won't appear far in the current IPv4 routing tables > either. Most sites filter prefixes longer than 24. > How do you currently use such a /28 as PI? Or did you become a LIR and > got that /20, just like is possible now with IPv6? > > As an exercise for the readers try to remember why there are filters on > IPv4 /24 boundaries and the try to figure out why there are quite a > number of people not wanting IPv6 PI to fill their IPv6 routing tables. > > Greets, > Jeroen one might also ask why a RIB/FIB entry has more relevance for one size prefix instead of another. --bill From leo at ripe.net Fri Dec 2 11:58:56 2005 From: leo at ripe.net (leo vegoda) Date: Fri, 2 Dec 2005 11:58:56 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201220236.GY44731@new.detebe.org> Message-ID: <004c01c5f72f$6427a310$1d0200c1@RIPENCCRS5> Hi Elmar, You wrote: > woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) wrote: > > > From ripe-357 ( > http://www.ripe.net/ripe/docs/pi-requestsupport.html ), > > Supporting Notes for the Provider Independent (PI) > Assignment Request Form > > (which I know quite well) > > Yes, of course nobody guarantees routeability. That's impossible. > But even RIPE has changed PI assignment policy a couple of years > ago and doesn't give out longer-than-/24 any more. That's not quite right. There was no policy change introducing a minimum size for IPv4 PI assignments. PI assignments are made on the same basis as PA assignments. It's not unusual for people to request PI assignments longer than a /24 and we have made a couple of dozen so far this year. Regards, -- leo vegoda RIPE NCC Registration Services Manager From gert at space.net Fri Dec 2 13:10:50 2005 From: gert at space.net (Gert Doering) Date: Fri, 2 Dec 2005 13:10:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <200512011830.15947.president@ukraine.su> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <200512011830.15947.president@ukraine.su> Message-ID: <20051202121050.GD69925@Space.Net> Hi, On Thu, Dec 01, 2005 at 06:30:15PM +0300, Max Tulyev wrote: > > Very easy. In the Internet the equivalent of phone numers, the DNS names > > are alleady portable - so you can easily switch ISP and keep your email > > address and URLs without renumbering. > > Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of > them is even not under your control. You have 10 servers to host them (i.e. > you need 10 IPs). > > Changing ISP is really easy? Sounds fairly easy to me - as long as you avoid the mistake of having the DNS not under your control. Which will always make problems anyway - just imagine having high load on one of your servers, and wanting to move those domains hosted there to other servers with less load. So what you saying is "because of not-so-good planning on the side of the hosting provider, the whole world needs to reserve some memory in their routers to route their /28"? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Fri Dec 2 13:13:16 2005 From: gert at space.net (Gert Doering) Date: Fri, 2 Dec 2005 13:13:16 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <200512011928.41342.president@ukraine.su> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <200512011830.15947.president@ukraine.su> <438F1A92.5080105@oslo.net> <200512011928.41342.president@ukraine.su> Message-ID: <20051202121316.GE69925@Space.Net> Hi, On Thu, Dec 01, 2005 at 07:28:41PM +0300, Max Tulyev wrote: > Stop. You have 10000 domains. You have IP address(es) from ISP A . You are > moving to ISP B with OTHER address(es). And you don't need to send 10000 > modify requests for these 10000 domains to change A (NS, MX) records. Where > is the magic? ;-) Be primary DNS for those 10000 domains, run a perl/sed/... script on the DNS zones to replace all the IPs from ISP A with IPs from ISP B. Send out two e-mails to update the IP of your primary nameserver: - to your secondary name server operators (DNS slaves) - to the TLD that contains your nameserver, to get the glue record updated Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 dr at cluenet.de Fri Dec 2 14:32:36 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 2 Dec 2005 14:32:36 +0100 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201200556.GT44731@new.detebe.org> References: <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> Message-ID: <20051202133236.GA2489@srv01.cluenet.de> On Thu, Dec 01, 2005 at 09:05:57PM +0100, Elmar K. Bins wrote: > That's the independently-networking end-user problem we have. [...] > Removal of the 200 customer rule would solve that. One-block-per-LIR > would solve that. No, it wouldn't. IPv6 allocation policy excludes end-sites, no matter wether they are LIR or not. DENIC is clearly an end site. At least I'm not aware that it's in the business of providing Internet connectivity to other entities. Currently, it's not even enough to throw money at the problem (pay LIR fees for not being a LIR but getting IP space), you also have to be sufficiently large to claim being an enterprise-internal ISP. Then again, even some school in Switzerland and one/three-man living room consulting companies manage that, surprisingly. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From elmi at 4ever.de Fri Dec 2 15:01:35 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 2 Dec 2005 15:01:35 +0100 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051202133236.GA2489@srv01.cluenet.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <20051202133236.GA2489@srv01.cluenet.de> Message-ID: <20051202140134.GE44731@new.detebe.org> dr at cluenet.de (Daniel Roesen) wrote: > No, it wouldn't. IPv6 allocation policy excludes end-sites, no matter > wether they are LIR or not. DENIC is clearly an end site. At least I'm > not aware that it's in the business of providing Internet connectivity > to other entities. Then you have skipped some press releases ;-) But you're right, the "no end user" thing has to go. I just forgot about that. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From hph at oslo.net Sat Dec 3 13:35:20 2005 From: hph at oslo.net (Hans Petter Holen) Date: Sat, 03 Dec 2005 13:35:20 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for global uniqe IP space In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <43919108.5010802@oslo.net> Roger Jorgensen wrote: > > * become LIR and request the needed IP space. > >From a couple projects I have done in the past - this is the path I would follow. The reasoning would be that your network will connect to the Internet or networks connected to the Internet. That you TODAY use firewalls or NATs sould not prevent you from getting address space. -hph From olav at avalonia.dk Sat Dec 3 22:29:53 2005 From: olav at avalonia.dk (Olav Noergaard) Date: Sat, 3 Dec 2005 22:29:53 +0100 Subject: [address-policy-wg] Dynamic or Message-ID: Are there a difference between what IP-addresses can be uset for, like some are only for dynamic addresses and some are for stationary addresses, and if there are a difference, where can I see that? -- Olav From pim at bit.nl Mon Dec 5 09:01:12 2005 From: pim at bit.nl (Pim van Pelt) Date: Mon, 5 Dec 2005 09:01:12 +0100 Subject: [address-policy-wg] Dynamic or In-Reply-To: References: Message-ID: <20051205080112.GC11038@localhost.localdomain> On Sat, Dec 03, 2005 at 10:29:53PM +0100, Olav Noergaard wrote: | Are there a difference between what IP-addresses can be uset for, like some | are only for dynamic addresses and some are for stationary addresses, and | if there are a difference, where can I see that? There is no difference. When you request them with the RIPE NCC, you have to explain briefly what they are for. If they are dynamic, simply note that in your request. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From kurtis at kurtis.pp.se Mon Dec 5 14:15:16 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 5 Dec 2005 14:15:16 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133433440.15956.248746502@webmail.messagingengine.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> Message-ID: <48A89582-ADA6-4429-8593-9E725B4D6BDC@kurtis.pp.se> On 1 dec 2005, at 11.37, Per Heldal wrote: >> user TE capability. It does not give the ISP the possibility to >> ignore it, as they could today. > > Shim6 is work in progress and may be used as an argument to adjust > adress-assignment policies sometime in the future. If we want ipv6 > deployed today we have to provide a mechanism to support requirements > about redundancy and independence from individual providers. Ok, that I agree with. - kurtis - From kurtis at kurtis.pp.se Mon Dec 5 14:17:25 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 5 Dec 2005 14:17:25 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438ED422.9090904@netegral.co.uk> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> Message-ID: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> On 1 dec 2005, at 11.44, Cameron C. Gray wrote: > Per Heldal wrote: >> Shim6 is work in progress and may be used as an argument to adjust >> adress-assignment policies sometime in the future. If we want ipv6 >> deployed today we have to provide a mechanism to support requirements >> about redundancy and independence from individual providers. > > I think this hit the nail on the head. Providers (especially those > non-LIR) will not accept something along the lines of SHIM6 or > A.N.Other > competing idea until it gives them just that -- INBOUND ROUTING > INDEPENDENCE. Now you are mixing two issues that Per separated though. Per pointed out that shim6 is work in progress while we need a policy now. > My view is relatively simple; either give everyone who wants one > and has > an AS-Number a /32 or allow /48s into the backbone table. This is of > course if we actually want to give up using IPv4; without the above > most > providers will see it as a step backward and a bad thing (tm). I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me... - kurtis - From kurtis at kurtis.pp.se Mon Dec 5 14:18:07 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 5 Dec 2005 14:18:07 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <17294.55288.858722.708230@roam.psg.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <17294.55288.858722.708230@roam.psg.com> Message-ID: <24AF46D5-7C8F-4AB7-B584-A6FAA7F1B727@kurtis.pp.se> On 1 dec 2005, at 12.01, Randy Bush wrote: >> If you have alternative ideas you know how it works - send text. > > draft-ietf-ipngwg-gseaddr-00.txt > > same one the ietf has ignored and lied about for eight years now I am looking forward to the BOF....:-) - kurtis - From mohta at necom830.hpcl.titech.ac.jp Mon Dec 5 14:33:32 2005 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 05 Dec 2005 22:33:32 +0900 Subject: [address-policy-wg] Re: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> Message-ID: <439441AC.1060902@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist wrote: > So AFAIK the state of the art routers does 40G line-rate deep-packet > inspection with any pattern matching. Once upon a time, there are people who thought 45Mbps were fast. > So remind me again what the > problem is? Price? Sure, that is a question of demand and volume > production... Terabit routers and corresponding bandwidth consumption. Recent findings on the amount of router buffers made terabit electrical routers much less expensive and terabit optical routers, which may be even less expensive than electrical ones, viable. > When MPLS was new I remember being told by vendors that it was the only > way we could forward IPv4 at 10G line-rate. Go figure. When I proposed MPLS, it was over ATM and I already noticed and warned that MPLS (over ATM) inherently is about 10 times slower than IP routers and that MPLS over Ethernet is no better than IP routers. Masataka Ohta From jeroen at unfix.org Mon Dec 5 14:38:06 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 05 Dec 2005 14:38:06 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <439442BE.2010509@unfix.org> Kurt Erik Lindqvist wrote: > I think each LIR should get a /32 and we should drop the 200 "customer" > rule. But that is just me... A question which most likely only RIPE NCC can answer: has there ever been a LIR who requested an IPv6 allocation and got rejected? LIR's are usually already have 200+ customers, let alone in planning. The people who are complaining (and not proposing what could be done) on this list don't want to be an LIR in the first place. Removing the 200 rule thus would not have much effect in all those cases. Also, they are usually end-sites (eg companies) thus would not pass that rule of the current policy. ISP's with less than 200 customers would indeed. But does it make sense to assign a complete /32 to a company that would not even allocate 200 /48's out of 65k in that /32? Looks a lot like address waste to me. Indeed a /48 to a dailup is also exactly that, for that matter out of my /48 I also only use one single /64, as bridging is more convenient than routing, though I could make my network using a couple of /64's if I wanted, but why should I? Now I can move boxes around without having to renumber them, which I already did 3 times. Kurt Erik Lindqvist wrote: > > On 1 dec 2005, at 12.01, Randy Bush wrote: > >>> If you have alternative ideas you know how it works - send text. >> >> draft-ietf-ipngwg-gseaddr-00.txt >> >> same one the ietf has ignored and lied about for eight years now > > I am looking forward to the BOF....:-) The BOF or the WAR? :) Kidding aside, the distribution of address space doesn't have much to do with routing table size, which is where most people seem to be concerned over. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From cgray at netegral.co.uk Mon Dec 5 14:33:23 2005 From: cgray at netegral.co.uk (Cameron C. Gray) Date: Mon, 05 Dec 2005 13:33:23 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <439441A3.2050904@netegral.co.uk> Kurt Erik Lindqvist wrote: >> I think this hit the nail on the head. Providers (especially those >> non-LIR) will not accept something along the lines of SHIM6 or A.N.Other >> competing idea until it gives them just that -- INBOUND ROUTING >> INDEPENDENCE. > > Now you are mixing two issues that Per separated though. Per pointed out > that shim6 is work in progress while we need a policy now. Kurt, I agree with you they are separate concerns, however as I pointed out they must be addressed similarly if IPv6 is to be adopted on any meaningful scale. I think as far as possible policies should speak to the assumed use and be extensible rather than a stopgap - "we do it this way now, but we now its not good and will change". My point was that yes SHIM6 is a work-in-progress but is not a solution that non-LIR providers will accept willingly; many would rather welcome doomsday of no more address space than work with something that limits their independence. Addressing previous criticisms, As far as the recurring argument of investment to support growing routing tables and memory requirements - how many of you had this when specifying individual hosts? Why can't every server just have the 64K Bill Gates promised would be enough? And wait, didn't he also say the Internet wasn't worth worrying about? Routing equipment will grow and adapt to the technical needs and business will have to fund it or send their customers elsewhere, its an evolution not something we all have to be protected from. (Not that RIPE is a place to dictate business cases and budgets anyway...) Can anyone digest for me into simple bullet points the other arguments for not allowing end site multihoming (and possibly PI therefore), other than: a) routing table size and therefore equipment concerns b) growing/padding RIPE membership numbers c) other immature solutions which border on NAT-insanity which don't actually address the independence angle I see the a) and c) above as cosmetic and easy to work around, and i think that b) would only be a good thing (tm) as all our fees drop with more members. Otherwise I can't see any more limiting factors to running it almost the same way as v4, instead of multiple prefixes per applicant its one. -- Best Regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | 0871 277 6845 From gert at space.net Mon Dec 5 18:06:48 2005 From: gert at space.net (Gert Doering) Date: Mon, 5 Dec 2005 18:06:48 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <20051205170648.GE69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > I think each LIR should get a /32 and we should drop the 200 > "customer" rule. But that is just me... Actually I like the "every AS should get a " approach (with a yearly recurring fee for AS and network, to guarantee return of the resources as soon as the importance of having a slot in the global routing table doesn't outweigh the costs anymore). "Every LIR gets a /32 (upon request), no questions asked" is a concept that I'm also happy with - as I have said before. For those that are afraid of the landrush: limit that policy to 5.000 LIRs per region. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 dr at cluenet.de Mon Dec 5 18:27:24 2005 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 5 Dec 2005 18:27:24 +0100 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051205170648.GE69925@Space.Net> References: <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> Message-ID: <20051205172724.GA6858@srv01.cluenet.de> On Mon, Dec 05, 2005 at 06:06:48PM +0100, Gert Doering wrote: > On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > > "customer" rule. But that is just me... > > Actually I like the "every AS should get a " approach (with > a yearly recurring fee for AS and network, That sounds good, if the fee is reasonable (means: covers the cost of this only, and not subsidizing LIR operations of others). > "Every LIR gets a /32 (upon request), no questions asked" is a concept > that I'm also happy with - as I have said before. For those that are > afraid of the landrush: limit that policy to 5.000 LIRs per region. Those kind of ideas can only come from folks who are already in the business and have their own allocation already. *shaking head* "Sorry, you're to late in the game - the market already has 5000 players, but we have this nice transit offering with PA space here...". Brilliant. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Mon Dec 5 18:39:10 2005 From: randy at psg.com (Randy Bush) Date: Mon, 5 Dec 2005 07:39:10 -1000 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> Message-ID: <17300.31550.633549.662266@roam.psg.com> >> "Every LIR gets a /32 (upon request), no questions asked" is a concept >> that I'm also happy with - as I have said before. For those that are >> afraid of the landrush: limit that policy to 5.000 LIRs per region. > Those kind of ideas can only come from folks who are already in the > business and have their own allocation already. *shaking head* actually, they usually come from non-op idealists who have never met a lawyer. remember TLAs? randy From gert at space.net Mon Dec 5 18:58:30 2005 From: gert at space.net (Gert Doering) Date: Mon, 5 Dec 2005 18:58:30 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fi x IPv6 In-Reply-To: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> Message-ID: <20051205175830.GF69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 06:13:03PM +0100, Bonness, Olaf wrote: > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > > that I'm also happy with - as I have said before. For those that are > > afraid of the landrush: limit that policy to 5.000 LIRs per region. > > Not sure if that works. Kind of "First come - first serve" thing. Yes, so what shall we do instead? "Nobody gets addresses, no mistakes made"? The whole point of this discussion is that there are two fractions: - one side is so afraid of doing the wrong thing that they want to delay everything until the perfect solution is found - the other side wants to get things rolling, and is willing to risk a few thousand entries in the global BGP table (whatever that is). and I don't think we'll ever reach consensus between those groups. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 ripe-wgs.cs at schiefner.de Mon Dec 5 19:14:33 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 05 Dec 2005 19:14:33 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> Message-ID: <43948389.6050309@schiefner.de> Bonness, Olaf wrote: >Von: Gert Doering [mailto:gert at space.net] >>"Every LIR gets a /32 (upon request), no questions asked" is a concept >>that I'm also happy with - as I have said before. For those that are >>afraid of the landrush: limit that policy to 5.000 LIRs per region. > > Not sure if that works. Kind of "First come - first serve" thing. > Regards Also, such a policy is most likely in direct conflict with one of the basic paradigms of a RIR - which is equal treatment of its members in equal circumstances. Best, -C. From jeroen at unfix.org Tue Dec 6 00:32:44 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 06 Dec 2005 00:32:44 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051205175830.GF69925@Space.Net> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <20051205175830.GF69925@Space.Net> Message-ID: <4394CE1C.6060103@unfix.org> Gert Doering wrote: > Hi, > > On Mon, Dec 05, 2005 at 06:13:03PM +0100, Bonness, Olaf wrote: >>> "Every LIR gets a /32 (upon request), no questions asked" is a concept >>> that I'm also happy with - as I have said before. For those that are >>> afraid of the landrush: limit that policy to 5.000 LIRs per region. >> Not sure if that works. Kind of "First come - first serve" thing. > > Yes, so what shall we do instead? > > "Nobody gets addresses, no mistakes made"? 2000::/3 is only 1/8th of the total IPv6 address space, we can make mistakes 8 times :) But the problem then is that we will have 8 swamps of crappy managed address space which most likely nobody will return. For that matter, there is not much force to get folks to return address space but having the parties they want to talk with filter it out. I wonder what would happen if eg Google would ask (access) ISP's to start paying for traffic 'or else' :) > The whole point of this discussion is that there are two fractions: > > - one side is so afraid of doing the wrong thing that they want to > delay everything until the perfect solution is found > > - the other side wants to get things rolling, and is willing to risk > a few thousand entries in the global BGP table (whatever that is). > > and I don't think we'll ever reach consensus between those groups. Especially as there are no proper argumented proposals being made by the second group, except that the current one is not to their liking and that things that get proposed doesn't fit their bill. My view on all of this is the following (hinting group #2 :) : - reserve a global, thus all the RIR's in one slot and split that up under the RIR's, block for 'multihoming purposes' (3ffe::/16 seems very appropriate as it is already swamp) - give people who want to multihome a /48(*) out of this block. - let them pay an annual fee for it that makes it a real incentive to maintain it and use it. - let them sign a document that when proper multihoming (eg SHIM6) comes that they will start using that and after X time stop announcing their /48 more specific. Also let other people filter at wish. (Add lawyer style wording in the above ;) * = or other appropriate size, maybe per /40 is better so that each multihomer could have 256 sites behind them, though then they are at the 200-rule which they seem to be bothered with already... :) This gives them PI address space, when SHIM6 or a similar method gets realized the swamp gets cleaned. Of course the swamp will only be cleansed when everybody cooperates and I don't see that happening. One advantage of the "multihoming block" is that it will be very easy to filter out. Of course such multihoming blocks can have private peerings and people that don't filter them won't see them. But HEY isn't that exactly what is already happening now? Check GRH* to see how many /48's from separate ASN's can already be seen (~60 at the moment). I guess that 6bone space will be a perfect example on what happens with swamp space that is supposed to be returned. The big issue in the above is that many people will not like SHIM6 or other methods because it is not what they have now and they will claim that they don't have proper control over the route announcements of that block. I am then inclined to ask them how much control they have over their route announcements when it leaves their ASN... ;) Greets, Jeroen * = http://www.sixxs.net/tools/grh/lg/?show=endsite&find=::/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Tue Dec 6 00:46:57 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 06 Dec 2005 00:46:57 +0100 Subject: [address-policy-wg] De-aggregation of assigned IPv6 prefixes? Message-ID: <4394D171.6080601@unfix.org> Hi, http://www.ripe.net/ripe/docs/ipv6policy.html#initial_criteria reads amongst others: 8<------------------- c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation -------------------->8 According to the above, after the /48, can one announce more specifics or should/must one not do this? (*) The RIPE Registry allows registering more specific route6 objects. If this is allowed, then why is the above parrt, after '/48', then included in the policy? What is the exact intention of the sentence? Greets, Jeroen *= of course one is lord of their own network and thus can announce whatever one wants and just hope/agree that others accept it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From marcus.gerdon at mainz-kom.de Tue Dec 6 02:30:56 2005 From: marcus.gerdon at mainz-kom.de (Marcus Gerdon) Date: Tue, 6 Dec 2005 02:30:56 +0100 Subject: [address-policy-wg] IPv6 prefixes / PI References: <4394D171.6080601@unfix.org> Message-ID: <004901c5fa04$b4c24190$d32f1fac@avalon> Hi @All, (in advance I'm sorry for the typo's and mis-chosen wordings as I'm not native English and just out of my favourite pub ...) I'm following this discussion for quite some time now, but to me it looks like many of you are going for a 'holy war'. Although I'm surely misunderstood, I've the impression (as for most discussions & votes) only the larger members here will get heard and/or will discuss this as the larger part of the members can't effort someone getting payed exclusively for community work. Let me start introducing a simple statement: Drop IPv6! No one (ok, nearly no one) is going to use IPv6. I'm speaking out of experience for de.mainzkom (a few months ago merger to de.citykom) being a regional ISP in Germany. Out of approx. 50 business customers I've spoken to TWO were interested in IPv6 trials. Only ONE of our transit customers explicitly asked for v6 (a university). How do you think a 'very large' member is going into the discussion for a lot more than a /32 ? Same way I stated need for our /32: let's count ANY end consumer (may it be a dynamic DSL account) a /64 and each business customer a /48. I had worries myself satisfying the 200-customer-rule - I solved it by assuming each of our DSL customers getting assigned a /48 ... regardless whether he needs/uses it. In the meanwhile applying this method the /32 is filled and to small ... could I argue for another one or maybe /30 or even more ? There's a point to the increasing number of IPv4 PI space allocated: Enterprise customers WANT to be independent f their ISP. Quite a number of them being governmental organizations or such HAVE TO open a Request for Proposal every few years (2-3) and change their ISP equivalently. Last time I had to explain that there's IPv4 PI but no IPv6 PI available. What do you think ? They dropped v6 completely! Surely, you'd have to recitate RIPE rules and deny the request for PI - but what would happen to your relationship towards your potential customer ? Can you afford dropping them - multiple a year ? Making v6 PI available may overload memory of current routers. And I'm the last ignoring this matter. There IS a limit any ISP can effort expenses on equipment. At least in Germany by the current market structure I'm glad of anybody NOT signing an end-consumer DSL contract. The 'the-cheaper-the-better' mentality is sooner or later killing all of us. By a 20 month ROI for a single DSL where do I get the money for upgrading routers from ? By not offering IPv6 so I can keep with my current routers ? Enterprise customers are asking (seldom enough, but they do) for Multicast and increasingly for v6 in addition to MPLS services - but these are the minority. Where's the point the average ISP is eaerning money ? Many of you (I've had no sense for looking up each one's approx. size specifically) sounds like one of these german (wanna-be)-monopolists: we're that large, customer have to come to us. You deny any small ISP their right for existence. Maybe there's need for an organized structure of the internet. Let's get the routing and address design be dictated by the known tier 1's & maybe 2's. You want that ? I think the mayority of attendents of these discussions do (as none of the smaller is able to effort time for RIPE-WG's, DECIX-WG's, AMS-IX-WG's etc...). When I get time for these I follow and sometimes response to WG's, but that's neither part of my job nor paid. You'd prefer a 200 pseudo-customer enterprise above a 100-customer ISP. To my personal opinion there're already too many non-ISP AS'es out there and much more - sadly mostly ISP - announcing nonsense (Gerd, I appreciated the discussion about aggregation some time ago) but HOW do you want to distinguish ? Maybe RIPE - and/or becoming a LIR in general - should be closed for non-ISP ... But where to draw the line ? Therefore I think we should go for IPv6 PI - with some constraints: - PI space (no matter whether v4 or v6) should be charged an annual fee - AS numbers should be charged an annual fee - a minimum size for PI assignments should be established I once got assigned a /24, /26, /27 of v4-PI. This satisfied the request made but when asked for routing we had to deny this as longer than /24 is simple pollution of the routing table. Why not go for v4 PI always being a multiple of /24 (if at least /25 is explained - any longer is nonsense by itself) and v6 being at most /40 (out of a 'dedicated' /32 or shorter) with more stringent criteria ? I always have a hard thought about equipment needs and cost - but do you remember the primary reason there's such a variety of ISP ? This reason are the variety of customer needs and the CUSTOMER's will. regards, Marcus PS: I'm sorry for the mix of thoughts above ... just had a '42' day .... :-| From gert at space.net Tue Dec 6 08:41:24 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 08:41:24 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] De-aggregation of assigned IPv6 prefixes? In-Reply-To: <4394D171.6080601@unfix.org> References: <4394D171.6080601@unfix.org> Message-ID: <20051206074124.GG69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:46:57AM +0100, Jeroen Massar wrote: > http://www.ripe.net/ripe/docs/ipv6policy.html#initial_criteria > reads amongst others: > 8<------------------- > c) plan to provide IPv6 connectivity to organisations to which it will > assign /48s by advertising that connectivity through its single > aggregated address allocation > -------------------->8 > > According to the above, after the /48, can one announce more specifics > or should/must one not do this? (*) When this came up last time, the explanation was "it is the LIR's duty to make sure that the aggregate will always be visible!" (so that the individual networks need not be announced). It's not meant to prohibit announcing more-specifics, though (which RIPE can't do anyway). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 tjc at ecs.soton.ac.uk Mon Dec 5 17:32:51 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 5 Dec 2005 16:32:51 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <20051205163251.GC1458@login.ecs.soton.ac.uk> On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > "customer" rule. But that is just me... That would be too easy :) -- Tim/::1 From tjc at ecs.soton.ac.uk Mon Dec 5 17:34:19 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 5 Dec 2005 16:34:19 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <439442BE.2010509@unfix.org> References: <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <439442BE.2010509@unfix.org> Message-ID: <20051205163419.GD1458@login.ecs.soton.ac.uk> On Mon, Dec 05, 2005 at 02:38:06PM +0100, Jeroen Massar wrote: > > A question which most likely only RIPE NCC can answer: has there ever > been a LIR who requested an IPv6 allocation and got rejected? > > LIR's are usually already have 200+ customers, let alone in planning. > > The people who are complaining (and not proposing what could be done) on > this list don't want to be an LIR in the first place. > Removing the 200 rule thus would not have much effect in all those cases. There are certainly organisations that cannot meet the 200 rule that have a /32.. RIPE-NCC is not inflexible. Tim::/1 From Olaf.Bonness at t-systems.com Mon Dec 5 18:13:03 2005 From: Olaf.Bonness at t-systems.com (Bonness, Olaf) Date: Mon, 5 Dec 2005 18:13:03 +0100 Subject: AW: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fi x IPv6 Message-ID: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> Hi Gerd, > -----Ursprungliche Nachricht----- > Von: Gert Doering [mailto:gert at space.net] > Gesendet: Montag, 5. Dezember 2005 18:07 > An: Kurt Erik Lindqvist > Cc: Cameron C. Gray; Per Heldal; address-policy-wg at ripe.net; > ipv6-wg at ripe.net > Betreff: Re: [ipv6-wg] Re: Re: [address-policy-wg] Re: > Andre's guide to > fix IPv6 > > > Hi, > > On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > > "customer" rule. But that is just me... > > Actually I like the "every AS should get a " approach (with > a yearly recurring fee for AS and network, to guarantee return of the > resources as soon as the importance of having a slot in the global > routing table doesn't outweigh the costs anymore). > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > that I'm also happy with - as I have said before. For those that are > afraid of the landrush: limit that policy to 5.000 LIRs per region. Not sure if that works. Kind of "First come - first serve" thing. Regards Olaf > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 81421 > > 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 oppermann at networx.ch Mon Dec 5 18:34:50 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Mon, 05 Dec 2005 18:34:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> Message-ID: <43947A3A.CE80737B@networx.ch> Gert Doering wrote: > > Hi, > > On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > > "customer" rule. But that is just me... > > Actually I like the "every AS should get a " approach (with > a yearly recurring fee for AS and network, to guarantee return of the > resources as soon as the importance of having a slot in the global > routing table doesn't outweigh the costs anymore). > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > that I'm also happy with - as I have said before. For those that are > afraid of the landrush: limit that policy to 5.000 LIRs per region. You can't use this kind of arbitrary limit. Doing it this way is seriously hot water in terms of anti-trust law. In general some of the discussed (and the current) IPv6 policy has troublesome aspects from an EU anti-trust point of view. To be on the safe side all policy must be on pure technical, equality and justifyable terms. RIPE NCC and its membership system may be deemed to be an illegal monopoly under certain circumstances if equality rules are not strictly followed and requests for membership are treated selectively. Also the current IPv6 policy that only ISPs can get independently routeable address space is a fine line into anti-competitive behaviour which may be illegal according to EU anti-trust law. I think is very important that RIPE NCC conducts a legal assertion through some EU anti-trust specialized law firm to assert the problematic aspects of any current and future IPv6 policy or policy proposal. With IPv4 there are no anti-trust problems because everyone may get any justifyable amount of address space. AS numbers are equally available too and only bound on the actual use of them. All this is deemed fair under EU anti-trust law. -- Andre From gert at space.net Tue Dec 6 09:18:50 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:18:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43948389.6050309@schiefner.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <43948389.6050309@schiefner.de> Message-ID: <20051206081850.GI69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 07:14:33PM +0100, Carsten Schiefner wrote: > >Von: Gert Doering [mailto:gert at space.net] > >>"Every LIR gets a /32 (upon request), no questions asked" is a concept > >>that I'm also happy with - as I have said before. For those that are > >>afraid of the landrush: limit that policy to 5.000 LIRs per region. > > Also, such a policy is most likely in direct conflict with one of the > basic paradigms of a RIR - which is equal treatment of its members in > equal circumstances. Circumstances before and after reaching a given number of routes are not "equal". Right now, nobody knows whether we will *ever* reach 10.000 IPv6 routes in the global BGP table - if we hit 10.000, we know that there is a given possibility of having "very very very many routes", and that conservation of routing table slots might be more of an issue than right now (where the issue is more along the lines of "get it going, or abandon it"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 09:21:22 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:21:22 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <4394CE1C.6060103@unfix.org> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <20051205175830.GF69925@Space.Net> <4394CE1C.6060103@unfix.org> Message-ID: <20051206082122.GJ69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:32:44AM +0100, Jeroen Massar wrote: > > - the other side wants to get things rolling, and is willing to risk > > a few thousand entries in the global BGP table (whatever that is). > > > > and I don't think we'll ever reach consensus between those groups. > > Especially as there are no proper argumented proposals being made by the > second group, except that the current one is not to their liking and > that things that get proposed doesn't fit their bill. That's not fully correct. There are a number of fairly specific proposals (to name three, in the order of "radicality": "abandon 200-customer rule", "give every LIR a /32", "give every AS holder a prefix"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 09:27:59 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:27:59 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051205172724.GA6858@srv01.cluenet.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> Message-ID: <20051206082759.GM69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 06:27:24PM +0100, Daniel Roesen wrote: > Those kind of ideas can only come from folks who are already in the > business and have their own allocation already. *shaking head* Unlike some other participants on this list, I'm actually aiming for something that could reach consensus. Otherwise, all this is wasted time, and we could directly go to ITU and ask them to fix the Internet. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 09:31:53 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:31:53 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43947A3A.CE80737B@networx.ch> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <43947A3A.CE80737B@networx.ch> Message-ID: <20051206083152.GN69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 06:34:50PM +0100, Andre Oppermann wrote: > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > > that I'm also happy with - as I have said before. For those that are > > afraid of the landrush: limit that policy to 5.000 LIRs per region. > > You can't use this kind of arbitrary limit. Doing it this way is seriously > hot water in terms of anti-trust law. It depends on how you handle it. My line of reasoning is "we don't have enough experience to judge how things will evolve, but there are some serious doubts on whether we can handle unreasonably large number of BGP routes - so we put a limit in there, and then reconsider in a few years whether our strategy is useful or not". I don't really expect the "5000" number to be a serious issue - but if it turns out to be, policy needs changing, of course. In whatever direction. [..] > Also the current IPv6 policy that only ISPs can get independently routeable > address space is a fine line into anti-competitive behaviour which may be > illegal according to EU anti-trust law. As nobody is preventing you from becoming an ISP, this line of argument is completly cr**. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 leo at ripe.net Tue Dec 6 09:42:09 2005 From: leo at ripe.net (leo vegoda) Date: Tue, 6 Dec 2005 09:42:09 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <439442BE.2010509@unfix.org> Message-ID: <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> Hi Jeroen, Jeroen Massar wrote: > > > I think each LIR should get a /32 and we should drop the > 200 "customer" > > rule. But that is just me... > > A question which most likely only RIPE NCC can answer: has there ever > been a LIR who requested an IPv6 allocation and got rejected? We analysed the requests and questions we have received and presented the details at RIPE 50. http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6nu mbers.pdf mms://webcast.ripe.net/ripe-50/address-policy-1.wmv http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html (section F) Basically, ~2% of requests did not end in address space being registered. We don't know how many requests are not sent in. Regards, -- leo vegoda RIPE NCC Registration Services Manager From rogerj at jorgensen.no Tue Dec 6 09:43:56 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Tue, 6 Dec 2005 09:43:56 +0100 (CET) Subject: [address-policy-wg] a consensus, about what? In-Reply-To: <20051206082759.GM69925@Space.Net> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfp m1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telst ra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837- 4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingeng ine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205D A32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA68 58@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> Message-ID: took me the liberty to change the subject line yet again... On Tue, 6 Dec 2005, Gert Doering wrote: > Unlike some other participants on this list, I'm actually aiming for > something that could reach consensus. > > Otherwise, all this is wasted time, and we could directly go to ITU and > ask them to fix the Internet. After this quite long but interesting discussion on the two working group mailing lists involved I guess the above sums it up quite well, where do we want to go tomorrow and the day after tomorrow? The future of Internet to put it short... and I'm not sure any of the above are the right place for that discussion. so what sort of consensus are we aiming for, and about what? A new policy for AS, a net block, routing policy, multihoming, or just IPv6 in general? This entire discussion have been sidetracked alot, not a bad thing either, quite alot of topics have been discussed and interesting thoughts brought forward.. but what are our goal with all this? -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From gert at space.net Tue Dec 6 09:56:04 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:56:04 +0100 Subject: [address-policy-wg] Re: a consensus, about what? In-Reply-To: References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> Message-ID: <20051206085604.GO69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 09:43:56AM +0100, Roger Jorgensen wrote: > so what sort of consensus are we aiming for, and about what? A new policy > for AS, a net block, routing policy, multihoming, or just IPv6 in general? > This entire discussion have been sidetracked alot, not a bad thing either, > quite alot of topics have been discussed and interesting thoughts brought > forward.. but what are our goal with all this? The basic policy issue seems to me: - who can get a (globally routeable [1]) IPv6 prefix it might affect the policy "who can get an AS number". The basic technical issue seems to be: - is "IPv4-style" BGP multihoming the correct way to do in IPv6 [1] globally routeable in the sense of "the majority of the participants in the global IPv6 routing system will be able to send packets that way". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 cfriacas at fccn.pt Tue Dec 6 10:25:04 2005 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 6 Dec 2005 09:25:04 +0000 (WET) Subject: [address-policy-wg] IPv6 prefixes / PI In-Reply-To: <004901c5fa04$b4c24190$d32f1fac@avalon> References: <4394D171.6080601@unfix.org> <004901c5fa04$b4c24190$d32f1fac@avalon> Message-ID: Hi, On Tue, 6 Dec 2005, Marcus Gerdon wrote: > Hi @All, > > (in advance I'm sorry for the typo's and mis-chosen wordings as I'm not > native English and just out of my favourite pub ...) > > I'm following this discussion for quite some time now, but to me it looks > like many of you are going for a 'holy war'. I also would say that is a strong possibility. :-) > Although I'm surely misunderstood, I've the impression (as for most > discussions & votes) only the larger members here will get heard and/or will > discuss this as the larger part of the members can't effort someone getting > payed exclusively for community work. > > Let me start introducing a simple statement: > > Drop IPv6! Wow! Quite a radical statement. However, if we are going to talk about IPv6 deployment, i can agree that the population using IPv6 is rather small than the one not using it... so, convincing everyone to remove IPv6 from their networks is a shorter path than getting worldwide IPv6 deployment... (but not as interesting!) :-) > No one (ok, nearly no one) is going to use IPv6. Besides the fact people are already using it, some people are also using it without any knowledge about it (i.e. apps using Teredo, transparent proxying, newsfeeds, ...). If we look at the current active ASNs, we should see that networks (ASNs) using IPv6 are still a small set, yes! - but we don't know how will this evolve in the (near) future. Any crystal ball around? I usually keep my antennas tunned in with what Geoff Huston says about IPv4 address exaustion, and try to keep an eye on IANA's list... i hope we don't get a new "Y2K" issue, but i've been more optimistic about it than nowadays. > I'm speaking out of experience for de.mainzkom (a few months ago merger to > de.citykom) being a regional ISP in Germany. Out of approx. 50 business > customers I've spoken to TWO were interested in IPv6 trials. Only ONE of > our transit customers explicitly asked for v6 (a university). I read this as: Do you want to satisfy your customer demand? even if that means only 2% of your customer base? Then, some interesting questions arise: - is the customer able to pay for what he is demanding? (IPv6 is not free, you know... IPv6 also means packets getting in and out of your network...) - is this an opportunity to deploy a service, that 98% of the current customer base is not interested, but that can help bring new customers? - are you sure, that 98% figure won't go down in a year's time? and in 2 year's time? > How do you think a 'very large' member is going into the discussion for a > lot more than a /32 ? Same way I stated need for our /32: let's count ANY > end consumer (may it be a dynamic DSL account) a /64 and each business > customer a /48. > > I had worries myself satisfying the 200-customer-rule - I solved it by > assuming each of our DSL customers getting assigned a /48 ... regardless > whether he needs/uses it. In the meanwhile applying this method the /32 is > filled and to small ... could I argue for another one or maybe /30 or even > more ? Usually people don't bother. a /32 is perfectly ok for a small-medium ISP. And about the 200-rule... well, that will fade out with time, and when sensible policy proposals are accepted! *hint*, *hint*... > There's a point to the increasing number of IPv4 PI space allocated: > > Enterprise customers WANT to be independent f their ISP. Quite a number of > them being governmental organizations or such HAVE TO open a Request for > Proposal every few years (2-3) and change their ISP equivalently. Last time > I had to explain that there's IPv4 PI but no IPv6 PI available. What do you > think ? They dropped v6 completely! As I see it, most of LIRs are ISPs, hence ISPs are making policies. ISPs like to keep their customers. Saying to a customer they'll have to go through the pain of a renumbering process is a good argument to keep anyone aboard their network. :-) 1+1=2 Then there is "the routing table size problem" -- if everyone gets its own PI, some routers will not be able to keep up... but that's also a danger on the IPv4 world... if someone wants a PI, it's only a matter of money and imagination. :-) > Surely, you'd have to recitate RIPE rules and deny the request for PI - but > what would happen to your relationship towards your potential customer ? Can > you afford dropping them - multiple a year ? Surely not. :-) If ISP1 doesnt find a way to adapt the customer's situation to the rules in order to please the customer, ISP2 or ISP3 gladly will... > Making v6 PI available may overload memory of current routers. And I'm the > last ignoring this matter. What is a "current router" ? My ASN uses a Juniper M10, a Cisco 7206 and a Cisco 12410 to deal with BGP4+ (about 175k v4 routes + about 500 v6 routes). Every one of them deals with IPv4 and IPv6 routes, if i may add. Some years ago we used two Cisco 75xx. I dont really know which equipment will form my "border router team" 2-3 years from now... > There IS a limit any ISP can effort expenses on equipment. Surely. And if you provide a better network, you should mirror the costs of a better network to your customers... > At least in > Germany by the current market structure I'm glad of anybody NOT signing an > end-consumer DSL contract. The 'the-cheaper-the-better' mentality is sooner > or later killing all of us. By a 20 month ROI for a single DSL where do I > get the money for upgrading routers from ? By not offering IPv6 so I can > keep with my current routers ? Last 4 year experience says you can deploy IPv6 with minimal costs. Just use simple engineering... :-) If you don't want/cant to mess out with the IPv4 routers, just use a cheap alternative (quagga/zebra/...) > Enterprise customers are asking (seldom > enough, but they do) for Multicast and increasingly for v6 in addition to > MPLS services - but these are the minority. Luckly, we would expect most of the multicast thinggy to be intra-domain :-) > Where's the point the average ISP is eaerning money ? The point where it satisfies customer demand, without charging less for the usage of their infrastructure? > Many of you (I've had no sense for looking up each one's approx. size > specifically) sounds like one of these german (wanna-be)-monopolists: we're > that large, customer have to come to us. You deny any small ISP their right > for existence. > > Maybe there's need for an organized structure of the internet. Let's get the > routing and address design be dictated by the known tier 1's & maybe 2's. That's even a dangerous path. ISPs also want tier-1/tier-2 independence! :-))) > You want that ? I think the mayority of attendents of these discussions do > (as none of the smaller is able to effort time for RIPE-WG's, DECIX-WG's, > AMS-IX-WG's etc...). When I get time for these I follow and sometimes > response to WG's, but that's neither part of my job nor paid. Strongly agree. :-) > You'd prefer a 200 pseudo-customer enterprise above a 100-customer ISP. > > To my personal opinion there're already too many non-ISP AS'es out there and > much more - sadly mostly ISP - announcing nonsense (Gerd, I appreciated the > discussion about aggregation some time ago) but HOW do you want to > distinguish ? Maybe RIPE - and/or becoming a LIR in general - should be > closed for non-ISP ... But where to draw the line ? > > Therefore I think we should go for IPv6 PI - with some constraints: > > - PI space (no matter whether v4 or v6) should be charged an annual fee > - AS numbers should be charged an annual fee > - a minimum size for PI assignments should be established That is a possible set of ideas, yes. You can also raise the question of charging or not to your customers when announcing their PI prefixes. Thruthfully, when an ISP announces an extra PI prefix, its peers will have to accept it or not. Usually they do, but how about if they asked: "Hey, what do i gain by accepting it? I only agreed to receive your PA prefixes in the first place..." > I once got assigned a /24, /26, /27 of v4-PI. This satisfied the request > made but when asked for routing we had to deny this as longer than /24 is > simple pollution of the routing table. Is there an authority that can regulate what is pollution and what is not? :-) > Why not go for v4 PI always being a multiple of /24 (if at least /25 is > explained - any longer is nonsense by itself) and v6 being at most /40 (out > of a 'dedicated' /32 or shorter) with more stringent criteria ? > > I always have a hard thought about equipment needs and cost - but do you > remember the primary reason there's such a variety of ISP ? This reason are > the variety of customer needs and the CUSTOMER's will. Sure. And often *one* customer will get a better service from an ISP with a 50 customer base, than *one* customer on an ISP network with a 5000 customer base... unless its monthly numbers enter the TOP-whatever in the ISP's accounting dept. :-) > regards, > > Marcus > > PS: I'm sorry for the mix of thoughts above ... just had a '42' day .... :-| Found your e-mail to be very useful, and very, very market-wise. Thanks! Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (175261/555), naming (millions) and... people!" From slz at baycix.de Tue Dec 6 11:09:12 2005 From: slz at baycix.de (Sascha Lenz) Date: Tue, 06 Dec 2005 11:09:12 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206082759.GM69925@Space.Net> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> Message-ID: <43956348.4040506@baycix.de> Hi, Gert Doering wrote: > Hi, > > On Mon, Dec 05, 2005 at 06:27:24PM +0100, Daniel Roesen wrote: >>Those kind of ideas can only come from folks who are already in the >>business and have their own allocation already. *shaking head* > > Unlike some other participants on this list, I'm actually aiming for > something that could reach consensus. > > Otherwise, all this is wasted time, and we could directly go to ITU and > ask them to fix the Internet. yes, please, fix the internet. I'd say we elect an Internet king which gives out all the rules! Worked for some hundret years. ...joke aside. The problem with consensus is, that it won't be reached with discussions, because in the internet world there is no "tie-breaker" who will finally make the descision about the outcome of the discussion ("no king"). The only way is to post some detailed policy suggestions and have some kind of voting about it, either in public (e.g. usenet-wise) or on RIPE/RIR level. That will give you at least some more exact numbers on the majority for or against a certain suggestion. I can't really tell about what's the most favoured policy for IPv6 Allocations and PI Address Assignments at the moment. It's not nescessarily the policy favoured by the ones who bark the loudest during the discussions. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From contact at ripe.net Tue Dec 6 11:22:08 2005 From: contact at ripe.net (Paul Rendek) Date: Tue, 06 Dec 2005 11:22:08 +0100 Subject: [address-policy-wg] RIPE NCC Regional Meeting, Qatar, 17 - 18 January 2006: Updates to Agenda Message-ID: <5.2.1.1.2.20051206105703.03082308@mailhost.ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, A revised agenda for the RIPE NCC Regional Meeting in Doha, Qatar (17 - 18 January 2006), is now available at: http://www.ripe.net/meetings/regional/qatar-2006/agenda.html This meeting is specifically designed to provide participants with a forum to discuss topics related to IP networking in the region. Topics on the agenda include: - A review of the World Summit on the Information Society (WSIS) and the way forward - IPv4 exhaustion and IPv6 consumption - Site Multihoming by IPv6 Intermediation (Shim6) - Internet security and new developments in Internet routing - The RIPE Policy Development Process (PDP) - RIPE NCC training seminars on Routing Registry and DNSSEC. The meeting will also feature demonstrations of services such as the Routing Information Service (RIS), BGPlay and Test Traffic Measurements (TTM) that help users analyse network behaviour. More information about these demonstrations is available at: http://www.ripe.net/meetings/regional/qatar-2006/demos/index.html In addition, RIPE NCC IP Resource Analysts will be at the meeting to answer any questions about IPv4 / IPv6 allocations and assignments. REGISTRATION Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. Registration for the Regional Meeting is now open. Registration will close on Friday, 13 January 2006. To register, please see: http://www.ripe.net/qatar2006/register PRESENTATIONS FROM THE LOCAL COMMUNITY We have reserved space in the agenda for presentations from the local community on current issues affecting the region. If there is a particular presentation or topic you would like included in the agenda, please send your suggestion to: MORE INFORMATION More information about the RIPE NCC Regional Meeting in Qatar is available from: http://www.ripe.net/qatar2006 Any further questions can be sent directly to: Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From gert at space.net Tue Dec 6 11:46:12 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 11:46:12 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43956348.4040506@baycix.de> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> Message-ID: <20051206104612.GQ69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 11:09:12AM +0100, Sascha Lenz wrote: > The only way is to post some detailed policy suggestions and have some > kind of voting about it, either in public (e.g. usenet-wise) or on > RIPE/RIR level. OK, so now we need to find consensus on how we want to do voting. - does every LIR get one vote (I hear Daniel Roesen yelling)? - does every person on the Internet get one vote? - How do you prevent abuse due to "ok, all employees of $big_carrier vote X" (by coprorate order)? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 tjc at ecs.soton.ac.uk Tue Dec 6 11:51:56 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 6 Dec 2005 10:51:56 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206083152.GN69925@Space.Net> References: <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <43947A3A.CE80737B@networx.ch> <20051206083152.GN69925@Space.Net> Message-ID: <20051206105156.GD20142@login.ecs.soton.ac.uk> On Tue, Dec 06, 2005 at 09:31:53AM +0100, Gert Doering wrote: > > [..] > > Also the current IPv6 policy that only ISPs can get independently routeable > > address space is a fine line into anti-competitive behaviour which may be > > illegal according to EU anti-trust law. > > As nobody is preventing you from becoming an ISP, this line of argument > is completly cr**. That's true. It didn't take much effort, and 'only' maybe 1,500 Euros p.a. for our site to in effect become an LIR. I guess for some people the fee is an issue, but the old argument is if PI is that important to you as a corporate organisation, that money is small change. So who exactly are these people calling for their IPv4 equivalent PI space? Are they all corporate enterprise networks? If not, who represents the other major consumers? And how many PI prefixes are in use today for IPv4? 10,000? 30,000? More? -- Tim/::1 From tjc at ecs.soton.ac.uk Tue Dec 6 11:55:39 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 6 Dec 2005 10:55:39 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> Message-ID: <20051206105539.GE20142@login.ecs.soton.ac.uk> On Tue, Dec 06, 2005 at 09:42:09AM +0100, leo vegoda wrote: > > We analysed the requests and questions we have received and presented > the details at RIPE 50. > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6nu > mbers.pdf > > mms://webcast.ripe.net/ripe-50/address-policy-1.wmv > > http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html > (section F) > > Basically, ~2% of requests did not end in address space being > registered. We don't know how many requests are not sent in. Thanks Leo, very interesting. We noted one knockon effect of RIPE policy. I don't know the full details, but essentially for a tunnel broker service we wanted to offer a /48 to end sites out of an existing /32, but were unable to do so because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed in advance for the ISP owning the /32 to allocate a (say) /40 to the broker service, and that added a notable hurdle. So we ended up using a /48 for the broker and allocating /56 and /64 blocks. Is this the way it's meant to be, or should the ISP owning the /32 only need to report usage when asking for more space itself? -- Tim/::1 From slz at baycix.de Tue Dec 6 12:09:59 2005 From: slz at baycix.de (Sascha Lenz) Date: Tue, 06 Dec 2005 12:09:59 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206104612.GQ69925@Space.Net> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> <20051206104612.GQ69925@Space.Net> Message-ID: <43957187.3070108@baycix.de> Hi, Gert Doering wrote: > Hi, > > On Tue, Dec 06, 2005 at 11:09:12AM +0100, Sascha Lenz wrote: >>The only way is to post some detailed policy suggestions and have some >>kind of voting about it, either in public (e.g. usenet-wise) or on >>RIPE/RIR level. > > OK, so now we need to find consensus on how we want to do voting. . o O(...) > - does every LIR get one vote (I hear Daniel Roesen yelling)? > > - does every person on the Internet get one vote? > > - How do you prevent abuse due to "ok, all employees of $big_carrier vote X" > (by coprorate order)? actually, it's a RIR Policy. So it would be quite quite logical to follow the RIR policy process and only let RIR-members ("LIR" or whatever it's called outside RIPE) vote. Don't really know if Daniel would yell on that. But actually that's what i was thinking about (we're exclusively on RIPE WG Mailinglists here anyways). Don't know why i added the "in public" part in first place. No real reason. It would be stupid to think about a "at large" vote on that issue, ICANN failed trying to establish such things :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From ripe-wgs.cs at schiefner.de Tue Dec 6 12:12:32 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 06 Dec 2005 12:12:32 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206081850.GI69925@Space.Net> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <43948389.6050309@schiefner.de> <20051206081850.GI69925@Space.Net> Message-ID: <43957220.7070008@schiefner.de> Hi Gert, Gert Doering wrote: >On Mon, Dec 05, 2005 at 07:14:33PM +0100, Carsten Schiefner wrote: >>Also, such a policy is most likely in direct conflict with one of the >>basic paradigms of a RIR - which is equal treatment of its members in >>equal circumstances. > > Circumstances before and after reaching a given number of routes are > not "equal". where _eaxctly!_ sits the difference between LIR #5000 and LIR #5001 - to pick up your example? And why is '5,000' _not!_ totally arbitrary? Although I am mostly agnostic wrt. the general discussion here so far, I am absolutely in line with Andre Oppermann's comment that we better have profound and sound answers to those questions ready before such a policy would be put in place - because they would be asked the second after anyways, most likely by these well-known, interested third parties... Best, Carsten From gert at space.net Tue Dec 6 12:29:42 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 12:29:42 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206105539.GE20142@login.ecs.soton.ac.uk> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> Message-ID: <20051206112942.GX69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 10:55:39AM +0000, Tim Chown wrote: > a /48 for the broker and allocating /56 and /64 blocks. Is this the > way it's meant to be, or should the ISP owning the /32 only need to > report usage when asking for more space itself? Well, it depends. If you want to "ASSIGN" a /40 to the tunnel broker, it falls into the category "assignment of networks larger than a /48 to the end user", and that's paperwork. The way it was meant to be done is doing a sub-allocation (which never goes to "end-users", unlike an assignment), and IPv6 sub-allocations, as far as I understand the policy, don't need to be approved by the NCC beforehand. Of course, when you sub-allocate all of your space away, and the receipients don't use it, you won't be able to get more space for you - so use with care. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 dogwallah at gmail.com Tue Dec 6 12:32:01 2005 From: dogwallah at gmail.com (McTim) Date: Tue, 6 Dec 2005 14:32:01 +0300 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43957187.3070108@baycix.de> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> <20051206104612.GQ69925@Space.Net> <43957187.3070108@baycix.de> Message-ID: Hi Sascha, On 12/6/05, Sascha Lenz wrote: > actually, it's a RIR Policy. So it would be quite quite logical to > follow the RIR policy process and only let RIR-members ("LIR" or > whatever it's called outside RIPE) vote. LIRs in the RIPE region vote only on RIPE NCC activities/budget/association stuff. The Policy Development Process is open to all. This is true in other regions as well. But actually that's what i was thinking about (we're exclusively on RIPE > WG Mailinglists here anyways). I am not an LIR, and I can play in this sandbox! BTW, I live in Africa now, (that's why you don't see me @ meetings anymore), but I can still participate on the lists. -- Cheers, McTim $ whois -h whois.afrinic.net mctim -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Dec 6 12:39:50 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 12:39:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43957220.7070008@schiefner.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <43948389.6050309@schiefner.de> <20051206081850.GI69925@Space.Net> <43957220.7070008@schiefner.de> Message-ID: <20051206113950.GY69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:12:32PM +0100, Carsten Schiefner wrote: > Gert Doering wrote: > >On Mon, Dec 05, 2005 at 07:14:33PM +0100, Carsten Schiefner wrote: > >>Also, such a policy is most likely in direct conflict with one of the > >>basic paradigms of a RIR - which is equal treatment of its members in > >>equal circumstances. > > > >Circumstances before and after reaching a given number of routes are > >not "equal". > > where _eaxctly!_ sits the difference between LIR #5000 and LIR #5001 - > to pick up your example? It's like growing up, and being 18 years old, over night. Nothing but a small number change, but lots of effect. > And why is '5,000' _not!_ totally arbitrary? I didn't say that it's not completely arbitrary. It's a limit that is loosely in the same range as the current number of LIRs per RIR, and well below the limits that will cause problems for currently deployed router architectures. I don't seriously see us reaching this number anyway in the near future - but I've put it there in case that I'm wrong, and those people that are afraid of a massive land rush are right. > Although I am mostly agnostic wrt. the general discussion here so far, I > am absolutely in line with Andre Oppermann's comment that we better have > profound and sound answers to those questions ready before such a policy > would be put in place - because they would be asked the second after > anyways, most likely by these well-known, interested third parties... I'm open for any proposal that will fulfill all the necessary criteria (in no specific order, and I'm sure I forgot one or two): - fair - not-ITU-problematic - not-monopoly-problematic - not using up BGP routing table slots - giving anybody maximum independence from anything else in the Internet - not wasting address space - giving anybody maximum address space so that they can be maximum convenient (internal hierarchy and allocation, etc.) - having a one-size-fits-all model for end users, to discourage bureaucracy - giving machines on a link the benefit of autoconfiguration - not wasting a /64 on links, and /48s on users as you can easily see, there is no way any policy can fulfill all of this at the same time. So the only thing that can ever reach consensus is a foul compromise (or a miracle from the IETF). "Foul compromise" = "nobody is happy with it, but everybody can *live* with it". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 12:42:46 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 12:42:46 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43957187.3070108@baycix.de> References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> <20051206104612.GQ69925@Space.Net> <43957187.3070108@baycix.de> Message-ID: <20051206114246.GZ69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:09:59PM +0100, Sascha Lenz wrote: > > - does every LIR get one vote (I hear Daniel Roesen yelling)? > > > > - does every person on the Internet get one vote? > > > > - How do you prevent abuse due to "ok, all employees of $big_carrier vote X" > > (by coprorate order)? > > actually, it's a RIR Policy. So it would be quite quite logical to > follow the RIR policy process and only let RIR-members ("LIR" or > whatever it's called outside RIPE) vote. > > Don't really know if Daniel would yell on that. Sure, because it's "the ISP monopoly deciding things that hurt all the poor end users". Also, in the RIPE land, it has *never* been the way that "only LIRs decide" - to the contrary, all RIPE processes are open to anyone to come to meetings (or subscribe to mailing lists) and enter discussions. > But actually that's what i was thinking about (we're exclusively on RIPE > WG Mailinglists here anyways). > Don't know why i added the "in public" part in first place. No real > reason. It would be stupid to think about a "at large" vote on that > issue, ICANN failed trying to establish such things :-) Doing it in a non-open way would directly play into ITUs hands. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 14:55:47 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 14:55:47 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <437DBBED.1080605@baycix.de> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> <437DBBED.1080605@baycix.de> Message-ID: <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> My apologies for replying to such an old message, but I couldn't let this one go. On 18-nov-2005, at 12:33, Sascha Lenz wrote: > In particular, noone came up with an equal solution to BGP Multihoming > with "PI"-space, which i hoped for back then. Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago. The only thing I got was perplexed stares. You really can't expect to keep doing the same thing we've been doing in IPv4 in IPv6 but now with different results (= more reasonable routing tables). Iljitsch -- I've written another book! http://www.runningipv6.net/ From fw at deneb.enyo.de Tue Dec 6 14:58:50 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 06 Dec 2005 14:58:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201200556.GT44731@new.detebe.org> (Elmar K. Bins's message of "Thu, 1 Dec 2005 21:05:57 +0100") References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> Message-ID: <877jaiqqcl.fsf@mid.deneb.enyo.de> * Elmar K. Bins: > That's the independently-networking end-user problem we have. PI would > solve that. Removal of the 200 customer rule would solve that. One-block- > per-LIR would solve that. Doesn't need DENIC two blocks, one for their production network, and one for anycast? Or would you be willing to subject yourself to an ISP for the production network? Why not for anycast service? From dr at cluenet.de Tue Dec 6 15:36:57 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 6 Dec 2005 15:36:57 +0100 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43947A3A.CE80737B@networx.ch> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <43947A3A.CE80737B@networx.ch> Message-ID: <20051206143657.GA17054@srv01.cluenet.de> On Mon, Dec 05, 2005 at 06:34:50PM +0100, Andre Oppermann wrote: > Also the current IPv6 policy that only ISPs can get independently routeable > address space is a fine line into anti-competitive behaviour which may be > illegal according to EU anti-trust law. Not only that, the billing scheme too. Every year it becomes more expensive to receive resources. See the time factor in the score algo. Given that this scheme is not a community-based decision, but a membership decision, this may (or may not, IANAL) subject to anti-trust laws as well. I think that RIPE needs a means to poll for votes in the RIPE region in an open manner, and base policy decisions on the outcome of those, not on the opinions of a few vocal folks who have the time and money to invest in mailing lists and RIPE meetings to bring forward their agenda, with someone then concluding "rough consensus" (or not). At least on a membership level that should be easy to achieve. Mail policy proposals to LIR contacts and ask to vote. Without having to read hundreds of mailing list postings and voicing opinions there. Of course the current policy discussion does affect members (LIRs) the least - they do already have their addresses (most of them), so asking only the membership to vote would be again the wrong thing to do. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From slz at baycix.de Tue Dec 6 15:59:44 2005 From: slz at baycix.de (Sascha Lenz) Date: Tue, 06 Dec 2005 15:59:44 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> <437DBBED.1080605@baycix.de> <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> Message-ID: <4395A760.6070608@baycix.de> Hi, Iljitsch van Beijnum wrote: > My apologies for replying to such an old message, but I couldn't let > this one go. > > On 18-nov-2005, at 12:33, Sascha Lenz wrote: > >> In particular, noone came up with an equal solution to BGP Multihoming >> with "PI"-space, which i hoped for back then. > > Well, you haven't been paying attention, because I've presented > "provider-internal aggregation based on geography" at two different > RIPE meetings a while ago. Actually, i did pay attention, but why do you think i consider that as an equal solution to BGP Multihoming with "PI"-space? It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table. Why do i want this at all? Because there are globally distributed prefixes right now, there is no geographically based assigment in sight anywhere and yes your presentation was a while ago. IIRC even your presentation said that this would require geographically based assigments "right now". Right? Do you expect everyone with a prefix today to give it back and renumber? "Too late" at least for a full solution. This is just another suggestion that might be helpful for preventing some amount of global prefixes (see below), but not god's own solution to the problem. > The only thing I got was perplexed stares. > > You really can't expect to keep doing the same thing we've been doing > in IPv4 in IPv6 but now with different results (= more reasonable > routing tables). *think* Of course... as mentioned before by many people, IPv6 implicitly solves some of the problems with "too many routes". Again, this leads to: - "usually" only one Prefix per AS even with nowerdays IPv6 policy ==> "more reasonable routing table" per default because almost noone needs a second Prefix - no impact on the IPv4 Routing Table size which you have to carry around for decades anyways. ==> no relief for any router in sight, regardless of the the IPv6 policy - There _ARE_ multihoming solutions besides world-wide prefix announcements, there are many. You can suggest all of them to your customers when they ask for "redundancy" or so. You even could be required by policy to tell your customers about the solutions as i suggested during the current thread. BUT - if someone insists on BGP Multihoming with worldwide prefix distribution for whatever reason he/she might have, noone must be forbidden to do so! ==> Even less End-site-customers who want an AS and PI-Prefixes because some actually _ARE_ OK with alternative. Noone denies the fact that there are most likely too many prefixes and probably even too many ASes in todays IPv4 Internet Routing Table. It's also a fact that many of them are not really needed, and the desired redundancy could be achieved by other means. Some customers might even be happy if they don't need to care for BGP Speaking Routers or so in their network and are pleased if you suggest a different solution. The main problem is just people who want to tell "me" (not literally) what's best for "my" network, and disallow "me" in the pond with the big fish. ..and there are absolutely no technical reasons which would forbid "me" in this pond if i want to swim there. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From elmi at 4ever.de Tue Dec 6 16:10:47 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 6 Dec 2005 16:10:47 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <877jaiqqcl.fsf@mid.deneb.enyo.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> Message-ID: <20051206151046.GF33656@new.detebe.org> fw at deneb.enyo.de (Florian Weimer) wrote: > > That's the independently-networking end-user problem we have. PI would > > solve that. Removal of the 200 customer rule would solve that. One-block- > > per-LIR would solve that. > > Doesn't need DENIC two blocks, one for their production network, and > one for anycast? Or would you be willing to subject yourself to an > ISP for the production network? Why not for anycast service? How come, it's always you who knows what other people need? Of course we are happy enough to connect our office to a potent ISP on a PA block, no hassle. If they let us advertise the assignment on some peering matrix and the partners take it, the better; but that's not really necessary for an office. Apart from that, we're working on solutions, both for registry services production and for the DNS problem, and I am sure we will find them. Elmar. From fw at deneb.enyo.de Tue Dec 6 16:18:02 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 06 Dec 2005 16:18:02 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206151046.GF33656@new.detebe.org> (Elmar K. Bins's message of "Tue, 6 Dec 2005 16:10:47 +0100") References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> <20051206151046.GF33656@new.detebe.org> Message-ID: <8764q2p845.fsf@mid.deneb.enyo.de> * Elmar K. Bins: > fw at deneb.enyo.de (Florian Weimer) wrote: > >> > That's the independently-networking end-user problem we have. PI would >> > solve that. Removal of the 200 customer rule would solve that. One-block- >> > per-LIR would solve that. >> >> Doesn't need DENIC two blocks, one for their production network, and >> one for anycast? Or would you be willing to subject yourself to an >> ISP for the production network? Why not for anycast service? > > How come, it's always you who knows what other people need? This was a real question, not a rhetorical one. I was genuinely wondering whether "one-block-per-LIR" would be enough. Not everything I wrote is intended to be provocative. 8-) From elmi at 4ever.de Tue Dec 6 16:21:26 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 6 Dec 2005 16:21:26 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <8764q2p845.fsf@mid.deneb.enyo.de> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> <20051206151046.GF33656@new.detebe.org> <8764q2p845.fsf@mid.deneb.enyo.de> Message-ID: <20051206152126.GG33656@new.detebe.org> fw at deneb.enyo.de (Florian Weimer) wrote: > >> Doesn't need DENIC two blocks, one for their production network, and > >> one for anycast? Or would you be willing to subject yourself to an > >> ISP for the production network? Why not for anycast service? > > > > How come, it's always you who knows what other people need? > > This was a real question, not a rhetorical one. I was genuinely > wondering whether "one-block-per-LIR" would be enough. Not everything > I wrote is intended to be provocative. 8-) Ok, then that's a misunderstanding (my memory has more than a week backlog or so). Actually, it's like I wrote - we're working on something. Not sure how to do it, though. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From iljitsch at muada.com Tue Dec 6 16:30:25 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 16:30:25 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <4395A760.6070608@baycix.de> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> <437DBBED.1080605@baycix.de> <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> <4395A760.6070608@baycix.de> Message-ID: <0DEF8DA7-3400-43C2-A921-043B2A98A1B8@muada.com> On 6-dec-2005, at 15:59, Sascha Lenz wrote: >>> In particular, noone came up with an equal solution to BGP >>> Multihoming >>> with "PI"-space, which i hoped for back then. >> Well, you haven't been paying attention, because I've presented >> "provider-internal aggregation based on geography" at two different >> RIPE meetings a while ago. > Actually, i did pay attention, but why do you think i consider that as > an equal solution to BGP Multihoming with "PI"-space? I don't understand what you're trying to say... But I'm happy that someone noticed what I was trying to say back then. > It's _ONE_ alternative solution one might suggest, but still no reason > for disallowing anyone in the globally distributed prefix table. To me, it's pretty obvious that if we can have aggregatable PI space, then that's an excellent reason to NOT have non-aggregatable PI space. Note however that the aggregation is optional in my plan: everyone can implement it in their own network independent of what everyone else does. In the beginning, there certainly won't be any reason to aggregate so this type of PI is completely equivalent to regular PI. > Why do i want this at all? Well, I don't know. I can get by with my PA /48 just fine. But apparently some people like to multihome and some of them insist that shim6 doesn't address their needs. And others want a portable prefix for other reasons. > Because there are globally distributed > prefixes right now, there is no geographically based assigment in > sight > anywhere So? If we really want this we can start doing this in a manner of weeks: the only requirement is that the RIRs start giving out prefixes that are aggregatable. In practice, it will take about the same amount of time as any other policy change. > Do you expect everyone with a prefix today to give it back and > renumber? Today, there is no PI in IPv6 so that's a moot question. > BUT - if someone insists on BGP Multihoming with worldwide prefix > distribution for whatever reason he/she might have, noone must be > forbidden to do so! I'd rather have a working internet without PI than a non-working one with it. Nobody can guarantuee that we won't run into trouble with PI so the only way we can be sure we won't have this trouble is to not have PI. If you want PI as it exists today in IPv4, the burden is on you to show, yes, SHOW that it can scale for decades to come. > The main problem is just people who want to tell "me" (not literally) > what's best for "my" network, and disallow "me" in the pond with > the big > fish. Do whatever you want, as long as you don't do it in my routing table. The internet only works as long as 99% of all people carry 99% of all routes. When a sizeable number of people starts filtering a sizeable number of routes for whatever reason, either technical (won't fit in their routers) or political (don't agree with the policies) then we're in knee-deep brown stuff. -- I've written another book! http://www.runningipv6.net/ From oliver at bartels.de Tue Dec 6 17:36:19 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 06 Dec 2005 17:36:19 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <0DEF8DA7-3400-43C2-A921-043B2A98A1B8@muada.com> Message-ID: <200512061635.jB6GZshq028157@alpha.bartels.de> On Tue, 6 Dec 2005 16:30:25 +0100, Iljitsch van Beijnum wrote: >On 6-dec-2005, at 15:59, Sascha Lenz wrote: [...] >>> Well, you haven't been paying attention, because I've presented >>> "provider-internal aggregation based on geography" at two different >>> RIPE meetings a while ago. >> It's _ONE_ alternative solution one might suggest, but still no reason >> for disallowing anyone in the globally distributed prefix table. Ack. >To me, it's pretty obvious that if we can have aggregatable PI space, >then that's an excellent reason to NOT have non-aggregatable PI space. You may aggregatable PI space if you can convince the router manufacturers create and implement a new RFC which adds an additional layer for prefix aggregation within the BGP protocol. Geographical aggregation however, is _for_sure_ not the solution for the new centrury. Geographical solutions happened in the last century. Nowadays carriers use DWDM technology, and yes, a link between Frankfurt and London or even New York is cheaper and easier to obtain than a link between Frankfurt and Wiesbaden. The key issue is whether competing dark fiber or leased line carriers are available at a certain location and _not_ the distance between those. >Well, I don't know. I can get by with my PA /48 just fine. But >apparently some people like to multihome and some of them insist that >shim6 doesn't address their needs. And others want a portable prefix >for other reasons. Yes, and as these people make a significant part out of the IPv4 internet world, as ISP's we can either support their requirement or keep IPv6 experimental. Period. >So? If we really want this we can start doing this in a manner of >weeks: the only requirement is that the RIRs start giving out >prefixes that are aggregatable. In practice, it will take about the >same amount of time as any other policy change. The key issues is: What today might look like an aggregate, won't be one tomorrow. Today A might be related to B and C to D, thus (AB) or (CD) might sound like good aggregates, tommorow A is related to C and B to D. Math limits the aggregation possibilities for ABCD. In this case, a bit mask could help: (A=x00y, B=x01y, C=x10y, D=x11y, thus first case mask 10, second 01) but it is obviously not possible to find an aggregation solution for any possible combination (e.g. ABC vs. D). As routing was not really considered by the designers of the IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered a lousy solution under this view), we can either live with it or give it up. Living with it means providing a solution for the PI requesting organisations and waiting for an aggregation enhancement of the routing protocols or keep it experimental, which probably means: Let it die. Even if the PI question is solved these days, I won't be sure if the answer isn't already too late. The market will tell us. >I'd rather have a working internet without PI than a non-working one >with it. Nobody can guarantuee that we won't run into trouble with PI >so the only way we can be sure we won't have this trouble is to not >have PI. This argument is unreal, you can stop _any_ project with it, in Germany we call it "Vollkaskomentatlitaet" and our country suffers a lot from it. There is simply no way to prove that a given solution won't have a side effect. If you write: "Nobody can guarantee ..." then I will tell you: Nobody can _guarantee_ that your posting by its formating or content can't cause a significant harm to an important server, cause a worldwide crash of the internet, thus impairs water and electricity supply and at the end let the aliens conquer earth. Thus you shouldn't post to this list ... Of course this is very very unlikely to happen, but, who knows, a word sequence within your comment might trigger this by a unknown bug within a common microprocessor type. You can't gurantee that your posts don't harm, thus by your own logic you should really consider not to post anymore ... More realistic: I'd rather like a internet with IPv6 and PI and the very low probability of of trouble which can with a high probably be fixed than no real-in-use IPv6 because of arguments which request gurantees that can't be given for _any_ solution on this planet. Up to now engineers have always proven to find solutions for networking problems like the PI issue, thus there will be some solution for sure if required. However I doubt there will be ever this requirement. > Do whatever you want, as long as you don't do it in my routing table. You are free to implement _your_ routing table as you like and to filter what you like, however: The global routing table is not _your_ routing table. Please don't block further enhancements of the Internet and please don't damage IPv6 by spreading out FUD. Thank You! Best regards Oliver Bartels P.s. @RIPE NCC: Question: Is there a practical way to replace the slow and cumbersome "consensus" principle of the RIPE by a democratic majority vote of the RIPE NCC members to stop further damage to IPv6, perhaps with a decision at the next RIPE NCC general meeting ? Of course some RIPE participants might then discuss adresss policies for ever, but for the RIPE NCC members we would then probably have practically acceptale policies for implementation in real world networks. Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From iljitsch at muada.com Tue Dec 6 18:08:40 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 18:08:40 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512061635.jB6GZshq028157@alpha.bartels.de> References: <200512061635.jB6GZshq028157@alpha.bartels.de> Message-ID: <69C9413F-A032-491D-8B50-3396284E7A32@muada.com> On 6-dec-2005, at 17:36, Oliver Bartels wrote: >> To me, it's pretty obvious that if we can have aggregatable PI space, >> then that's an excellent reason to NOT have non-aggregatable PI >> space. > You may aggregatable PI space if you can convince the router > manufacturers create and implement a new RFC which adds an > additional layer for prefix aggregation within the BGP protocol. I can't imagine what such a layer would look like... > Geographical aggregation however, is _for_sure_ not the > solution for the new centrury. Geographical solutions happened > in the last century. In IP? Don't think so. If you have pointers, please enlighten me. > Nowadays carriers use DWDM technology, and yes, a link > between Frankfurt and London or even New York is cheaper and > easier to obtain than a link between Frankfurt and Wiesbaden. Sure. But trying to aggregate on network topology is never going to work for two very simple reasons: 1. It changes all the time 2. You can't express a topology with loops in it in an addressing hierarchy The reason to choose geography to aggregate on is not because it is somehow magically always the best fit with topology, because it isn't. However, it has two very important things going for it: it's not subject to change, and it allows for optimization on distance, which in turn has the potential to be be good for cost and performance. Please don't assume you understand my proposal just because it contains the term "geography". If you want to know what it entails have a look at http://www.muada.com/drafts/draft-van-beijnum-multi6- isp-int-aggr-01.txt > The key issue is whether competing dark fiber or leased line > carriers are available at a certain location and _not_ the distance > between those. Distance is actually very important. It's very hard to do decent high speed file transfer on out of the box OSes and applications with high delay. Also, it often makes sense to backhaul traffic over SOME distance, but that doesn't mean it also makes sense to backhaul it over even larger distances. I.e., even if a link to New York is cheap, you don't want to go over Palo Alto. > As routing was not really considered by the designers of the > IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered > a lousy solution under this view), we can either live with it > or give it up. Living with it means providing a solution for > the PI requesting organisations and waiting for an aggregation > enhancement of the routing protocols or keep it experimental, > which probably means: Let it die. Your conclusions don't follow from your assumptions. Yes, IPv6 doesn't do anything for routing except allow very large aggregates. However, the choice isn't between allowing unlimited growth and hoping we can fix it later and not using IPv6, the choice is between: - Not allowing PI - Coming up with aggregatable PI of some kind - Give up and make the exact same mess of IPv6 as we did with IPv4 Today, IPv4 routing works but it has come close to the edge of the cliff twice (early 1990s just before CIDR routing tables were too large and late 1990s flapping cost too much CPU) and it's still pushing towards that edge, which we can't see clearly but know is out there somewhere. And that happened in 25 years. We'll very likely have to live with IPv6 for much longer than that, so we HAVE to be careful from the outset. Shim6 is coming, aggregation with PI is unexplored, IPv6 is still in the extremely early stages, so this is NOT the time to do stupid things. If we're still in the same boat in 5 years when we're down to 18 months of IPv4 addresses, sure, we can revisit this issue. But we still have some time. Let's use it. > Even if the PI question is solved these days, I won't be sure > if the answer isn't already too late. The market will tell us. What kind of logic makes this too late? >> I'd rather have a working internet without PI than a non-working one >> with it. Nobody can guarantuee that we won't run into trouble with PI >> so the only way we can be sure we won't have this trouble is to not >> have PI. > This argument is unreal, you can stop _any_ project with it, > in Germany we call it "Vollkaskomentatlitaet" and our country > suffers a lot from it. Well, then apply some of that mentality to PI in IPv6 and free it up elsewhere. :-) > There is simply no way to prove that a given solution won't > have a side effect. So because you can't prove that you're right I should just believe you without proof? > If you write: "Nobody can guarantee ..." then I will tell you: > Nobody can _guarantee_ that your posting by its formating or > content can't cause a significant harm to an important server, > cause a worldwide crash of the internet, thus impairs water and > electricity supply and at the end let the aliens conquer earth. No, but there's no reasonable scenario that makes this happen either. The scenario that de facto unlimited PI in IPv6 will make routing tables so large that it becomes problematic in some way or another is entirely reasonable, on the other hand. > More realistic: > I'd rather like a internet with IPv6 and PI and the very low > probability > of of trouble which can with a high probably be fixed than no real- > in-use > IPv6 because of arguments which request gurantees that can't be > given for _any_ solution on this planet. Yes, I've heard it all before. Why don't we work on something that we can all get behind? The beauty of my geographical aggregation thing is that you still get PI even if it turns out that it doesn't work. So you get what you want regardless of who's right. Pretty good deal, don't you think? > Up to now engineers have always proven to find solutions > for networking problems like the PI issue, thus there will > be some solution for sure if required. Sure, we can always implement some kind of aggregation later. This of course requires renumbering of all PI space. And isn't the idea behind PI space that you never have to renumber out of it...? > P.s. @RIPE NCC: Question: Is there a practical way to replace the > slow and cumbersome "consensus" principle of the RIPE by a democratic > majority vote of the RIPE NCC members to stop further damage to IPv6, > perhaps with a decision at the next RIPE NCC general meeting ? Please replace "RIPE NCC members" with "people who have to pay for bigger routers world wide" (not just the RIPE region) and I'm all for it. Iljitsch -- I've written another book! http://www.runningipv6.net/ From david.kessens at nokia.com Tue Dec 6 19:32:49 2005 From: david.kessens at nokia.com (David Kessens) Date: Tue, 6 Dec 2005 10:32:49 -0800 Subject: [address-policy-wg] Crossposting to address policy and ipv6 working group mail lists In-Reply-To: <20051206085604.GO69925@Space.Net> References: <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> Message-ID: <20051206183249.GC27914@nokia.com> I am seeing a lot of crosspostings on the ipv6 wg and address policy wg list. Before replying to a message, please consider who your intended audience is: is interested in technical topics related to the deplyment of ipv6 is concerned about the policies related to ip allocations and assignments in the RIPE region Please remove a working group list from the CC list if your message is not on topic for that particular working group. Thanks, David Kessens Chairperson ipv6 working group --- From david.kessens at nokia.com Tue Dec 6 20:02:57 2005 From: david.kessens at nokia.com (David Kessens) Date: Tue, 6 Dec 2005 11:02:57 -0800 Subject: [address-policy-wg] Re: a consensus, about what? In-Reply-To: <20051206085604.GO69925@Space.Net> References: <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> Message-ID: <20051206190257.GD27914@nokia.com> Gert, On Tue, Dec 06, 2005 at 09:56:04AM +0100, Gert Doering wrote: > > The basic policy issue seems to me: > > - who can get a (globally routeable [1]) IPv6 prefix > > it might affect the policy "who can get an AS number". It seems a really bad idea to connect this to AS number assignments. Currently, the policy for getting AS # assignments is quite clear (one has to multihome to get an AS #!) I don't believe it is smart to change IP number allocation policies in such a way that people are going to multihome (or lie that they are multihoming) so that they can get an AS # (that they don't need) and a PI address allocation. These things are two separate things and should stay separate. > The basic technical issue seems to be: > > - is "IPv4-style" BGP multihoming the correct way to do in IPv6 No. The RIPE policies should not make any assumptions on what is "correct" or not. Operators run the Internet and they will decide how to do multihoming. It does not matter whether anybody thinks it is correct or not, it matters whether operators decide to honor your route announcement. Multihoming has in fact very little to do with this whole PI discussion. One can multihome with PI or PA space. However, the most important underlying reason for PI address space allocations is number independance of one's provider. In fact the so called PA blocks are exactly the same: how many ISPs who have a PA block want to be dependant on their transit providers IPs ? Basically, all blocks that a RIR gives out are PI. It is only the customers of the LIRs who get PA address space. I believe that it is much better to drop this whole discussion on PI. The discussion should focus on who can get an IP address space allocation from the RIR and how large. As somebody else mentioned, the Internet is a collection of connected networks and it does not matter whether one is a business, non-profit or ISP. As an example, I don't believe we can justify that a very large entity has (perceived) difficulties in obtaining ipv6 addresses while a tiny ISP that has plans for 200 customers but doesn't quite have that many customers yet and in total has less users than the large entity will get a /32 without any problem. Basically, we don't need additional policies, we need a modification of the current policy to make sure that users of address space of similar size will get and can get similar sized blocks of address space. David Kessens --- From oliver at bartels.de Tue Dec 6 20:10:09 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 06 Dec 2005 20:10:09 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <69C9413F-A032-491D-8B50-3396284E7A32@muada.com> Message-ID: <200512061909.jB6J9chq022181@alpha.bartels.de> On Tue, 6 Dec 2005 18:08:40 +0100, Iljitsch van Beijnum wrote: >On 6-dec-2005, at 17:36, Oliver Bartels wrote: >> You may aggregatable PI space if you can convince the router >> manufacturers create and implement a new RFC which adds an >> additional layer for prefix aggregation within the BGP protocol. > >I can't imagine what such a layer would look like... Clustering all PI-prefixes originating at the same AS to form a single "super-prefix" makes policy processing a lot easier, because it need to be done just once for the whole block. This is obvious for single homed PI and even saves processing time on multihomed PI. Whether the address space occupied by this prefix is homogenous or not is a "don't care" nowadays, as a large forwarding table isn't a problem at all. With as few as 256MByte of DDRAM plus a 64K TCAM chip it is possible to handle max. 8 Million Forwarding entries at full 128 bit resolution with appx. 10 GBit/s typical and 1.5 GBit/s "bad weather" (small packets only) line rate. I personally just received a patent on such router hardware concept. >In IP? Don't think so. If you have pointers, please enlighten me. In POTS and X.25 networks. The latter died ... >> Nowadays carriers use DWDM technology, and yes, a link >> between Frankfurt and London or even New York is cheaper and >> easier to obtain than a link between Frankfurt and Wiesbaden. > >Sure. But trying to aggregate on network topology is never going to >work for two very simple reasons: > >1. It changes all the time The same is true for geographical aggregation. Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models. There is no free transit and thus it doesn't work. Business relations changes all the time and in a global markets world these business relations don't stop on country boundaries. Such boundaries are artifical, the EU tries to avoid them. Thus the only aggregation you would gain is: Americas / Europe-Asia / Asia-Pacific. Not even Africa and with huge problems in Asia. Everything below this continental boundaries can be treated local and, with your own words : It changes all the time ( Why: See below, dimensions. ) Thus with a geographical approach your aggregation gain is near zero (might be a factor of 2..3 in the table, which is near zero in this context). Sorry, but geographical aggregation won't work in these days any more. >2. You can't express a topology with loops in it in an addressing >hierarchy Avoiding loops is the job of the routing protocol, not the topology. >Distance is actually very important. It's very hard to do decent high >speed file transfer on out of the box OSes and applications with high >delay. Also, it often makes sense to backhaul traffic over SOME >distance, but that doesn't mean it also makes sense to backhaul it >over even larger distances. I.e., even if a link to New York is >cheap, you don't want to go over Palo Alto. If I would be located in Seattle, Palo Alto might be an alternative way point as well as Chicago or even Dallas. What you are trying is: Map a two-and-a-half-dimensional world on a one-dimensional address range. This won't work by Math. Dimensions can only be replaced by dimensions. Asked a database programmer how difficult it is to implement a geographical 10km around some place search on a database and ask them about the algorithms in use. What they try is interleaving the West-East (X) and North-South (Y) coordinates bitwise in the search key and handle overruns by exceptions, like: X_MSB Y_MSB X_2SB Y_2SB X_3SB Y_3SB ... However this requires a _significant_ exception handling effort, nothing someone would like to implement in a fast forwarding engine for packet routing. Beleave me: The cost for 256MBytes of DDRAM is in the lower two digits Euro range, nothing to be discussed with high end routers. A large forwarding table is much cheaper than a geographical packet resolution. >However, the choice isn't between allowing unlimited growth and >hoping we can fix it later and not using IPv6, the choice is between: > >- Not allowing PI >- Coming up with aggregatable PI of some kind >- Give up and make the exact same mess of IPv6 as we did with IPv4 > >Today, IPv4 routing works but it has come close to the edge of the >cliff twice (early 1990s just before CIDR routing tables were too >large and late 1990s flapping cost too much CPU) and it's still >pushing towards that edge, which we can't see clearly but know is out >there somewhere. It works. Period. And it will continue to work, because of the economic pressure. Engineers have found a solution, thus: Don't worry. >So because you can't prove that you're right I should just believe >you without proof? Yes, because the theory of computer sience gives you the prrof that there are theorems in this world which can't be proven. Computer Software belongs to this sort of items, someone can just test it, make assumptions, but can't prove it will be correct for any but the most simple algorithms. And this is proven. Try to build an algorithm which checks that any other algorithm will correctly terminate. Try to apply this algorithm to itself, think about the consequences and then you might understand: Real technology is always believe at some point and not proof. There is no way to get a _proof_ that your post (or my) doesn't trigger a nasty CPU or router operating system bug which causes the internet meltdown. There is just believe and trust that reasonable router manufacturers will deliver reasonable products. >No, but there's no reasonable scenario that makes this happen either. Of course there is. Think of the nasty multiplication bug with the Intel 486 CPU. This happened just with a few numbers. Intel replaced a huge amount of these chips free of charge. Think of a race condition in a chip, which processes your post and creates a checksum. Under very rare circumstances the race condition applies for your checksum (see multiply bug), cascades to a bus collision and melts down the router. However the forwarding hardware already received the ok to output the dangerous packet to the next router in the chain without further intervention of the hardware which just died. >The scenario that de facto unlimited PI in IPv6 will make routing >tables so large that it becomes problematic in some way or another is >entirely reasonable, on the other hand. The current experience let us make a reasonable and responsible assumption that a IPv6 routing table would take not much more growth than the current IPv4 table, whereas current technology permits tables of 10 to 100 times that size. >Yes, I've heard it all before. Why don't we work on something that we >can all get behind? The beauty of my geographical aggregation thing >is that you still get PI even if it turns out that it doesn't work. >So you get what you want regardless of who's right. Pretty good deal, >don't you think? Again: 2 dimensions -> 1 dimension doesn't work. >Please replace "RIPE NCC members" with "people who have to pay for >bigger routers world wide" (not just the RIPE region) and I'm all for >it. People who pay for big routers pay for big pipes, too. They pay significantly more for big pipes than for big routers. If you give them the choice to save 10% on the pipe for using the cheaper offer instead of the one-dimensional-geographical ordering-correct offer, and increase the router price by 30% percent for increased routing flexibility and larger tables, they still will vote for the cheaper pipe. 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 gert at space.net Tue Dec 6 20:38:40 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 20:38:40 +0100 Subject: [address-policy-wg] Re: a consensus, about what? In-Reply-To: <20051206190257.GD27914@nokia.com> References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> Message-ID: <20051206193840.GC69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 11:02:57AM -0800, David Kessens wrote: > On Tue, Dec 06, 2005 at 09:56:04AM +0100, Gert Doering wrote: > > > > The basic policy issue seems to me: > > > > - who can get a (globally routeable [1]) IPv6 prefix > > > > it might affect the policy "who can get an AS number". > > It seems a really bad idea to connect this to AS number assignments. This wasn't my intention, just an observation. If it's easy to get a "prefix that can be used for BGP multihoming", then the customer will also quite likely need an AS number. This is why the "prefix policy" will inevitably have some effect on the way AS numbers are allocated - maybe not on the AS# policy itself, but at least on the going rate. > Currently, the policy for getting AS # assignments is quite clear (one > has to multihome to get an AS #!) Yes, and this is a Good Thing. > I don't believe it is smart to change IP number allocation policies in > such a way that people are going to multihome (or lie that they are > multihoming) so that they can get an AS # (that they don't need) and a > PI address allocation. These things are two separate things and should > stay separate. They are not the same thing, but not fully separable either... [..] > independance of one's provider. In fact the so called PA blocks are > exactly the same: how many ISPs who have a PA block want to be > dependant on their transit providers IPs ? Basically, all blocks that > a RIR gives out are PI. It is only the customers of the LIRs who get > PA address space. > > I believe that it is much better to drop this whole discussion on PI. > The discussion should focus on who can get an IP address space > allocation from the RIR and how large. Sure, in the end, there the IPv6 address looks the same, whether you tag it PI or PA. They differ only when it comes to giving part of your address space to third parties (and still want to keep the aggregate together) -> PA. [..] > As an example, I don't believe we can justify that a very large entity > has (perceived) difficulties in obtaining ipv6 addresses while a tiny > ISP that has plans for 200 customers but doesn't quite have that many > customers yet and in total has less users than the large entity will > get a /32 without any problem. > > Basically, we don't need additional policies, we need a modification > of the current policy to make sure that users of address space of > similar size will get and can get similar sized blocks of address space. Partly I agree, and to some extent I disagree - the *size* of the block isn't what people seem to be worrying about. The sheer fact that someone can get (or not) an "independent BGP routing table slot" - which is always "one", no matter how big the network is - seems to be. Starting to hand out different sizes might lead people to connecting "importance" to "network size", which would be a wrong signal. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 20:42:57 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 20:42:57 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <877jaiqqcl.fsf@mid.deneb.enyo.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> Message-ID: <20051206194257.GD69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 02:58:50PM +0100, Florian Weimer wrote: > > That's the independently-networking end-user problem we have. PI would > > solve that. Removal of the 200 customer rule would solve that. One-block- > > per-LIR would solve that. > > Doesn't need DENIC two blocks, one for their production network, and > one for anycast? Or would you be willing to subject yourself to an > ISP for the production network? That's what DENIC is doing right now, doing BGP-multihoming with a /48 from their upstream ISP. (Which is certainly something people *do* disagree upon - but as they seem to be happy with their ISPs reliability, it will still work even if someone filters out the /48). > Why not for anycast service? It could certainly be done, but as there are going to be *many* instances, distributed all over the place, it would be a lot less hassle to have a network from a well-known block that people would know "hey, permit this through our filters, it's a TLD anycast network". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 20:53:36 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 20:53:36 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] a consensus, about what? In-Reply-To: References: Message-ID: <20051206195336.GF69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 11:08:47AM -0500, peter.sherbin at bell.ca wrote: > Get rid of the current hierarchy which requires ISP in order to > connect to the network. The Internet is an aggregation of interconnected > networks. We want to replicate what the Mother Nature has already > given us, i.e. a brain like structure where neurons (individual > networks) have multiple direct connections with each other. As brain > cells networks should have about the same size. Network prefix > determines the size. Ah, back to the source-route-bridged times of (ring-) explorer packets... Sounds like a nice idea, would even be much more resilient than the current structure. Any IETF proposals where we can read up on how this is gonna work? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Tue Dec 6 21:42:57 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 21:42:57 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512061909.jB6J9chq022181@alpha.bartels.de> References: <200512061909.jB6J9chq022181@alpha.bartels.de> Message-ID: <4D7F8529-5BBA-4C70-8025-A589AF42EAD9@muada.com> On 6-dec-2005, at 20:10, Oliver Bartels wrote: >> I can't imagine what such a layer would look like... > Clustering all PI-prefixes originating at the same AS to form > a single "super-prefix" makes policy processing a lot easier, > because it need to be done just once for the whole block. I'm not sure I understand the "superprefix" but obviously a lot of work that now happens per-prefix in BGP should happen per-AS. But that's mostly moot in IPv6 as we should never reach the numbers of prefixes per AS that we see in IPv4. > With as few as 256MByte of DDRAM plus a 64K TCAM chip it is > possible to handle max. 8 Million Forwarding entries at full 128 bit > resolution I guess that means you throw everything in the TCAM first to get from 8M to about 125 entries and then look those up in a tree or hash table? Obviously it's possible to build architectures that allow fast forwarding with big tables. However, this doesn't come free: it takes more iron to do this, and also more power. TCAMs suck down the juice like a depressed alcoholic. This is bad for your design (both the box itself and the datacenter), your wallet and the environment. > I personally just received a patent on such router hardware concept. So big routing tables are good business for you, then? >> Sure. But trying to aggregate on network topology is never going to >> work for two very simple reasons: >> 1. It changes all the time > The same is true for geographical aggregation. I guess I you live in California or another place that is plagued by frequent earthquakes... > Geographical aggregation would require free transit, otherwise > it is not compatible with the ISP's business models. The point is to keep the aggregation inside the ISP network. Tier-1 ISPs would still have a full routing table, but rather than have a copy in each router, it's distributed over the network. So there is no free transit requirement. > country boundaries. > Such boundaries are artifical, the EU tries to avoid them. The idea behind aggregation is that you can move up or down. If country borders get in the way, drill down a bit and start looking at provinces or cities. In our design there are potentially 64k distinct areas (mostly cities) so if you want, you can have a route for each of those in your routing table and never run into country borders. >> 2. You can't express a topology with loops in it in an addressing >> hierarchy > Avoiding loops is the job of the routing protocol, not the > topology. ??? Are we talking about spanning tree now? Loops in the topology are good. You can't remove them. Routing is also dynamic, BTW. >> Distance is actually very important. It's very hard to do decent high >> speed file transfer on out of the box OSes and applications with high >> delay. Also, it often makes sense to backhaul traffic over SOME >> distance, but that doesn't mean it also makes sense to backhaul it >> over even larger distances. I.e., even if a link to New York is >> cheap, you don't want to go over Palo Alto. > If I would be located in Seattle, Palo Alto might be an alternative > way point as well as Chicago or even Dallas. Of course. But we're in Europe. If you're in Seattle you'll see a lot of your traffic to other people in Seattle flow through Palo Alto. That's normal, because it's not economical to peer with everyone everywhere. It's not so cool when intra-Seattle traffic starts to flow through Miami. > What you are trying is: > Map a two-and-a-half-dimensional world on a one-dimensional > address range. This won't work by Math. > Dimensions can only be replaced by dimensions. Ah, but we're not mathematicians but engineers. In software, you have one dimensional memory. Still, you can have multidimensional arrays. > Asked a database programmer how difficult it is to implement > a geographical 10km around some place search on a database > and ask them about the algorithms in use. Easy: select everything that's in a 20x20 km grid around the center point and then do the real distance calculation on everything in that grid. Obviously you'll select stuff that's at x+8 y+8 = ~12km from the center but that's only true for a relatively small part of the intermediate results. > What they try is interleaving the West-East (X) and North-South (Y) > coordinates bitwise in the search key and handle overruns by > exceptions, That sounds like Tony Hain's geographical addressing. The variant Michel Py and myself came up with is based on administrative borders such as countries so you already have on dimension: the alphabet. (Ok, not entirely how it works, but still.) > However this requires a _significant_ exception handling effort, > nothing someone would like to implement in a fast forwarding > engine for packet routing. Geography is long gone by the time we're forwarding packets. >> Today, IPv4 routing works but it has come close to the edge of the >> cliff twice (early 1990s just before CIDR routing tables were too >> large and late 1990s flapping cost too much CPU) and it's still >> pushing towards that edge, which we can't see clearly but know is out >> there somewhere. > It works. Period. Hm, if you only descern "works" / "doesn't work" it's hard to say anything about the routing system... Some quantitative and qualitative analysis can be helpful. > And it will continue to work, because of the > economic pressure. Engineers have found a solution, thus: > Don't worry. Guess what. I'm an engineer. I'm working on this stuff. And I'm saying: when de facto unlimited PI is allowed, it may not mean the end of the internet, but it's certainly reason to worry. Of course things will continue to work. However, they'll be less reliable and more expensive. >> So because you can't prove that you're right I should just believe >> you without proof? > Yes, because the theory of computer sience gives you the > prrof that there are theorems in this world which can't be proven. There are also many theorems that turn out to be false. Proof is a pretty good method to avoid those. If we can't have proof we'll need to have less reliable methods to avoid them. Just accept anything is not the solution. >> The scenario that de facto unlimited PI in IPv6 will make routing >> tables so large that it becomes problematic in some way or another is >> entirely reasonable, on the other hand. > The current experience let us make a reasonable and responsible > assumption that a IPv6 routing table would take not much more > growth than the current IPv4 table, whereas current technology > permits tables of 10 to 100 times that size. Today, people sometimes deaggregate a /16. That's bad: 255 unnecessary routes. What if they do the same thing with a /32 in IPv6? 65535 unnecessary routes. That will probably kill most existing IPv6 routers today. 10 times is 1.75M routes, 100 = 17.5. The former is probably doable for IPv4 on some extremely high end boxes but I'm not sure how those would handle real issues such as flapping, lots of full feeds etc. I don't believe the latter exists or will exist in the forseeable future, at least not in a way that anyone can afford to actually use. Even those 1.75M boxes will be very expensive and only affordable by the largest networks. Don't forget you and I all pay for their hardware, directly or indirectly. Iljitsch -- I've written another book! http://www.runningipv6.net/ From david.kessens at nokia.com Tue Dec 6 21:51:31 2005 From: david.kessens at nokia.com (David Kessens) Date: Tue, 6 Dec 2005 12:51:31 -0800 Subject: [address-policy-wg] Re: a consensus, about what? In-Reply-To: <20051206193840.GC69925@Space.Net> References: <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051206193840.GC69925@Space.Net> Message-ID: <20051206205131.GB28506@nokia.com> Gert, On Tue, Dec 06, 2005 at 08:38:40PM +0100, Gert Doering wrote: > > As an example, I don't believe we can justify that a very large entity > > has (perceived) difficulties in obtaining ipv6 addresses while a tiny > > ISP that has plans for 200 customers but doesn't quite have that many > > customers yet and in total has less users than the large entity will > > get a /32 without any problem. > > > > Basically, we don't need additional policies, we need a modification > > of the current policy to make sure that users of address space of > > similar size will get and can get similar sized blocks of address space. > > Partly I agree, and to some extent I disagree - the *size* of the block > isn't what people seem to be worrying about. The sheer fact that someone > can get (or not) an "independent BGP routing table slot" - which is always > "one", no matter how big the network is - seems to be. > > Starting to hand out different sizes might lead people to connecting > "importance" to "network size", which would be a wrong signal. I didn't say that sizes have to be different. I said that an organization with X number of users should get a similar amount of address space as another organization that has X number of users whether it is an ISP or not. As it is however, we currently do give out different sizes as a /32 is the minimum. My personal opinion is that we should keep this minimum as is if we decide to only give out address space to organizations with a very large number of users. My opinion is different if it is decided that organizations with a fairly small numbers of users can get address space directly from the RIPE NCC. A /32 is already extremely generous and at some point it just gets completely ridiculous. David Kessens --- From dr at cluenet.de Wed Dec 7 01:58:47 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 7 Dec 2005 01:58:47 +0100 Subject: [address-policy-wg] Re: Re: a consensus, about what? In-Reply-To: <20051206190257.GD27914@nokia.com> References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> Message-ID: <20051207005847.GA23383@srv01.cluenet.de> On Tue, Dec 06, 2005 at 11:02:57AM -0800, David Kessens wrote: > The discussion should focus on who can get an IP address space > allocation from the RIR and how large. And at which price. It's ridiculous to ask the same price from someone who does a single request for IP space and ~never come back, and from someone who starts as a real LIR (you [not you personally] remember? Local Internet REGISTRY!) which does subassigments to hundreds of end users, have those requests validated by NCC hostmasters, take part in LIR trainings etc. pp. You have an AS and do multihome? Pay a small one-time fee (reg effort) and small annual fee (to verify that you still do exist care for the prefix to stay registered, and to cover costs for the database entries for your prefix) and be done with it.[1] But that would be too simple, too fair, too non-discriminating, offer too much independency to mere mortal entities. All those folks who question the right of ASses (AUTONOMOUS systems) to have their own IP space and a routing table slot (in lieu of a better, sufficiently!capable replacement architecture) for technical reasons ("but our routers will break!") should ask themselves one question: are YOU ready to return YOUR prefix(es) because you are NOT in the routing tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s don't have any TECHNICAL need to announce their own allocations. All other non-upstream-free ISPs only have ECONOMIC reasons to do so. You want to tell others that they are not entitled to that as well? Interesting. In which way are you special? I hereby ask anyone who publicly denies the right for PI to others to explain why THEY are entitled to PI themselves (PA is as David correctly explained nothing else than PI for ISPs, with the allowance to use parts of the address space for customers). And check twice that you aren't deploying double standards and split tongue. Best regards, Daniel [1] Perhaps I'll be annoyed enough by this topic over the christmas/new year's holidays to draft something up... but with the current policy finding process I see almost no chance to get the so-call "consensus" [of a few vocal folks], so it's prolly just wasted time. All those enterprises, non-commercial organizations and clubs who want/need PI aren't really represesented here. -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jeroen at unfix.org Wed Dec 7 08:31:43 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 07 Dec 2005 08:31:43 +0100 Subject: [address-policy-wg] Re: Re: a consensus, about what? In-Reply-To: <20051207005847.GA23383@srv01.cluenet.de> References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> Message-ID: <43968FDF.9000502@unfix.org> Daniel Roesen wrote: > On Tue, Dec 06, 2005 at 11:02:57AM -0800, David Kessens wrote: >> The discussion should focus on who can get an IP address space >> allocation from the RIR and how large. > > And at which price. > > It's ridiculous to ask the same price from someone who does a single > request for IP space and ~never come back, and from someone who starts > as a real LIR (you [not you personally] remember? Local Internet > REGISTRY!) which does subassigments to hundreds of end users, have those > requests validated by NCC hostmasters, take part in LIR trainings etc. > pp. > > You have an AS and do multihome? Pay a small one-time fee (reg effort) > and small annual fee (to verify that you still do exist care for the > prefix to stay registered, and to cover costs for the database entries > for your prefix) and be done with it.[1] Note that the billing should then still be 'more' expensive than a LIR's individual allocation otherwise most LIR's will convert into independents which gives one more power over prefixes than the above. A LIR should know the procedures which should make requests very easy to process, at least that is the idea, which lowers load on the RIR's. Also, what is your equipment budget? At least 2 routers, 2 uplinks, man-power and a lot of other things. What is ~2K EUR then anyway? Or are you already saving for a bigger fatter router? > But that would be too simple, too fair, too non-discriminating, offer > too much independency to mere mortal entities. But isn't a RIR, or IANA/ICANN then not directly monopolitic? They are the only ones you can get address space from "and ruled by the US" etc. > All those folks who question the right of ASses (AUTONOMOUS systems) to > have their own IP space and a routing table slot (in lieu of a better, > sufficiently!capable replacement architecture) for technical reasons > ("but our routers will break!") should ask themselves one question: are > YOU ready to return YOUR prefix(es) because you are NOT in the routing > tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s > don't have any TECHNICAL need to announce their own allocations. All > other non-upstream-free ISPs only have ECONOMIC reasons to do so. You With a too large routing table (which are indeed far from there) for the currently deployed routers it will indeed be very economical as they need to be upgraded. But this does depend on landrush. Running out of 65k ASN's is the first thing that will happen. Though I wonder if some smaller routers still deployed at endsites will like to handle that. Economics, that is people who won't be able to update their routers, will then figure out who can have a slot there or not. RIR's fortunately do not guarantee routability, thus them giving out /48's from a single global /16 or so, to sites 'that desperately need them', allows people who don't want them to filter when table pressure become tight. Adding some geography in that big block might even allow one to at least carry the traffic to a 'local' IX to hand it off. > All those > enterprises, non-commercial organizations and clubs who want/need PI > aren't really represesented here. Very simple answer: find them and let them speak up. Setup a union to represent them if you want etc. This is politics crap: if you don't raise your voice, don't complain that you are not heard. Same in real 'technical' places, which are usually downright political also and usually the big buck is what matters. Unfortunately that will always be the case, but that is the world of politics. Just ask around how many of your neighbors voted for Miss Merkel, does that match the national German votes? Not even asking who voted for Bush :) Greets, Jeroen (Who still thinks what I wrote up at http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01269.html can work fine, then the economy, that is other ASN's will limit what they will accept at a certain point) (And who doesn't want his own "PI" space, I'll let other people take care of all, who can do it much better :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From peter.sherbin at bell.ca Tue Dec 6 17:08:47 2005 From: peter.sherbin at bell.ca (peter.sherbin at bell.ca) Date: Tue, 6 Dec 2005 11:08:47 -0500 Subject: [address-policy-wg] Re: [ipv6-wg] a consensus, about what? Message-ID: >Date: Tue, 6 Dec 2005 09:43:56 +0100 (CET) >From >To: Gert Doering > cc: address-policy-wg at ripe.net, ipv6-wg at ripe.net > Subject: [ipv6-wg] a consensus, about what? >so what sort of consensus are we aiming for...? A new policy >for AS, a net block, routing policy, multihoming, or just IPv6 in general? >...quite a lot of topics have been discussed ... but what are our goal with all this? Get rid of the current hierarchy which requires ISP in order to connect to the network. The Internet is an aggregation of interconnected networks. We want to replicate what the Mother Nature has already given us, i.e. a brain like structure where neurons (individual networks) have multiple direct connections with each other. As brain cells networks should have about the same size. Network prefix determines the size. Peter Sherbin Bell Canada From oliver at bartels.de Wed Dec 7 08:51:20 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 07 Dec 2005 08:51:20 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <4D7F8529-5BBA-4C70-8025-A589AF42EAD9@muada.com> Message-ID: <200512070750.jB77onhq003924@alpha.bartels.de> On Tue, 6 Dec 2005 21:42:57 +0100, Iljitsch van Beijnum wrote: >I'm not sure I understand the "superprefix" but obviously a lot of >work that now happens per-prefix in BGP should happen per-AS. Yes. As typically all prefixes of an ISP are impacted by an upstream pipe break, it would make sense to bundle them together by the means of a protocol item and perform updates on the bundle/super-prefix only for as much operations as possible and use incremental superprefix member operations. This could be made hierachical, but on a protocol layer, not by a fixed adressing policy. It would save computing time on updates which is an issue. >I guess that means you throw everything in the TCAM first to get from >8M to about 125 entries and then look those up in a tree or hash table? A bit different, otherwise it won't be an invention. DDRAM's have a special characteristic that helps a lot. >Obviously it's possible to build architectures that allow fast >forwarding with big tables. Yes. > However, this doesn't come free: it takes >more iron to do this, and also more power. TCAMs suck down the juice >like a depressed alcoholic. This is bad for your design (both the box >itself and the datacenter), your wallet and the environment. No. FUD only. A small single height eurocard is sufficient which draws less power than an average PC. >The point is to keep the aggregation inside the ISP network. Tier-1 >ISPs would still have a full routing table, but rather than have a >copy in each router, it's distributed over the network. So there is >no free transit requirement. [...] >The idea behind aggregation is that you can move up or down. If >country borders get in the way, drill down a bit and start looking at >provinces or cities. In our design there are potentially 64k distinct >areas (mostly cities) so if you want, you can have a route for each >of those in your routing table and never run into country borders. Even we as a small ISP don't care about _city_ boundaries, they are absolutely irrelevant. In some cases there is no routing at all, it is just switched. Again: Country/City etc. boundaries are irrelevant, we have a directive in the EU which permits telco operation from any company in any member country in any other member country without license. It is just "hello, we do it now" registration. If an ISP specialises in the Elsass, it is likely that half of the net is in France and half in Germany. On the other hand for historical/business relation reasons our net is partially Bavaria and Baden-Wuerttemberg. The next ISP will support Bavaria and Saxonia, or Bavaria and Hessen (very likely due to existing infrastructure, I know several), than again Hessen and Baden-Wuertemberg, or Saarland, Luxembourg (nearby) and Hessen (DeCIX pipe, just taking additional customers there). Don't forget Bavaria and Austria, Bavaria and Switzerland or Austria and Switzerland. There is simply no mathematical consistent way to aggregate this by administrative boundaries. I am a friend of clear wording: Your RFC-suggestion paper is not functional in practice. Sorry for your paper, but math, physical laws and law's of economy don't care about personal oppinions expressed in papers. >??? Are we talking about spanning tree now? Loops in the topology are >good. You can't remove them. Routing is also dynamic, BTW. Again: Loop removal is the job of routing protocols, thus BGP contains a path attribute. As long as there is a usable and unrestricted (transit) connection, it works, as the Internet proves every day. We don't need to discuss problems which do not exist. Problems will arise if you arbitrarily split the routing table as you sugest in your RFC proposal. Thus simply don't do it and the problem is solved. >Ah, but we're not mathematicians but engineers. In software, you have >one dimensional memory. Still, you can have multidimensional arrays. Engineers should consider mathematical laws, otherwise they produce low quality. You may store multidimensional arrays, but this doesn't help you here in this task, which is exactly what your "algo" would require: >Easy: select everything that's in a 20x20 km grid around the center >point and then do the real distance calculation on everything in that >grid. Aha: We take the already available solution and then do some additional calculation to present it ... No, if you sort the data inside a grid, you have to consider the eight neighbor grids, too, thus _nine_ checks. The grid size is fixed (we are talking about a database), which is very similar to the geographical address-policy problem: It is fixed, too. The grid works fine only for distances below the grid distance and not much below that, it requires nine grid cell checks for a single query etc. >Obviously you'll select stuff that's at x+8 y+8 = ~12km from >the center but that's only true for a relatively small part of the >intermediate results. Obviously you have to consider neigbour grids, which is exactly the same problem as with the adressing policy: You have to consider neighbour countries, cities etc. with totally different prefixes in your model. My definately last argument to explain it, thereafter I will consider it as "trotzdem" and won't give further arguments: There is no reason to put Kehl and Strassbourg (Eurobridge) in different routing tables because they are in different countries. It is just a cable over the Rhine. >The variant Michel Py and myself came up with is based on >administrative borders such as countries so you already have on >dimension: the alphabet. (Ok, not entirely how it works, but still.) Administrative border are _artificial_, the laws of math and economy don't care about them. Sorry, but for a working geographical adressing you would have to take a different scheme and even if RIPE would issue some address space based on interleaved coordinates you will find that even a geographical range search is a non-trivial task a router won't do on the fly. It takes much more computing power than a large table. >Guess what. I'm an engineer. I'm working on this stuff. And I'm >saying: when de facto unlimited PI is allowed, it may not mean the >end of the internet, but it's certainly reason to worry. It definately doesn't mean the end of the internet, other RIR's issue PI, too. You might worry that an asteroid will hit us tomorrow, but this is not the issue of the address policy wg. >10 times is 1.75M routes, 100 = 17.5. The former is probably doable >for IPv4 on some extremely high end boxes but I'm not sure how those >would handle real issues such as flapping, lots of full feeds etc. Today they can do. 1,75M is expected (except vendors with a customer-should-buy-new-box-because-we-limit-resources-by-company-policy attitude), 17.5M is really high end, but sounds not impossible. >Even those 1.75M boxes will be very expensive and only affordable by >the largest networks. Don't forget you and I all pay for their >hardware, directly or indirectly. We pay much more for pipes than for hardware. 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 leo at ripe.net Wed Dec 7 09:16:26 2005 From: leo at ripe.net (leo vegoda) Date: Wed, 7 Dec 2005 09:16:26 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512061635.jB6GZshq028157@alpha.bartels.de> Message-ID: <002501c5fb06$84bd6f30$1d0200c1@FluffyBunny> Hi Oliver, You wrote: [...] > P.s. @RIPE NCC: Question: Is there a practical way to replace the > slow and cumbersome "consensus" principle of the RIPE by a democratic > majority vote of the RIPE NCC members to stop further damage to IPv6, > perhaps with a decision at the next RIPE NCC general meeting ? > > Of course some RIPE participants might then discuss adresss policies > for ever, but for the RIPE NCC members we would then probably have > practically acceptale policies for implementation in real > world networks. I suppose that changes to the Policy Development Process (PDP) have to go through the PDP. If you want to submit a proposal to that effect then you need to complete a proposal template and pass it to the relevant WG chair. You can find the template at: http://www.ripe.net/ripe/policies/proposals/template/ There are also links to the main documents on that page. Regards, -- leo vegoda RIPE NCC Registration Services Manager From Michael.Dillon at btradianz.com Wed Dec 7 11:32:20 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 10:32:20 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> Message-ID: > Well, you haven't been paying attention, because I've presented > "provider-internal aggregation based on geography" at two different > RIPE meetings a while ago. > > The only thing I got was perplexed stares. If your presentation was as cursory as the slides I saw on the web, I'm not surprised that you got perplexed stares. I think that people need to be led through the concept step by step in more detail. Also, you need to deal with existing prejudices. Most people have preconcieved notions about geographical addressing which boils down to geo = bad. They either think it is some flaky idea about encoding physical coordinates in addressing, or some idea about giving nation states control over addressing or something that was rejected by the IETF in the past and therefore cannot be retrofitted in the IPv6 protocol. It is a big job to get past these prejudices and get people to actually think about things. The root of the idea is for the RIRs to cooperate in allocating IP addresses so that they can be aggregated more widely. In other words, so that it is not necessary for every allocation to become an announcement in the global routing table. Of course, this means that RIRs and ISPs have to cooperate in allocating IPv6 addresses using a rough kind of geographical plan. I suggest that this plan be anchored to the major cities where most interconnecting is done. This is also roughly aligned with the topology of the network if you can manage to visualize an entire city (Paris, London, Hannover, Krivoy Rog) as a single node in a network. It's that level of abstraction that leads to making sense of this kind of aggregation. As you pointed out in the slides, it is not necessary for interconnect to happen in a specific geographical location in order to gain some benefit from this. Of course, one would hope that eventually every ISP will migrate to interconnecting in each city where they carry traffic, but that is not a precondition. I have taken to calling this kind of thing "geotop" addressing because it comes from noticing that there is a "rough" alignment between geography and topology. I think we should leverage that rough alignment to dampen routing table growth, and therefore buy time in the same way that we bought time with CIDR and dampening of growth in IP address allocation. --Michael Dillon From Michael.Dillon at btradianz.com Wed Dec 7 11:37:46 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 10:37:46 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <4395A760.6070608@baycix.de> Message-ID: > "Too late" at least for a full solution. This is just another suggestion > that might be helpful for preventing some amount of global prefixes (see > below), but not god's own solution to the problem. The world does not need full solutions. In regard to IP addressing policy, it is sufficient for the RIRs to start doing things more wisely. If the RIRs would open up another 1/8th of the IPv6 address space for geotop allocations then they would no longer be blocking this solution. It is not up to the RIRs to tell ISPs how to operate their networks, i.e. the RIRs cannot say that ISPs must accept announcements of PI /26s allocated by the RIRs. The ISPs are in control of what they do. But, in the area of geo-topological aggregation of announcements, ISPs are currently prevented from acting because the RIRs won't give out geotop allocations. --Michael Dillon From Michael.Dillon at btradianz.com Wed Dec 7 11:42:21 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 10:42:21 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <0DEF8DA7-3400-43C2-A921-043B2A98A1B8@muada.com> Message-ID: > The internet only works as long as 99% of all people carry 99% of all > routes. When a sizeable number of people starts filtering a sizeable > number of routes for whatever reason, either technical (won't fit in > their routers) or political (don't agree with the policies) then > we're in knee-deep brown stuff. And this is something that RIPE and ARIN cannot directly change. RIR policy can only encourage or discourage ISPs from carrying 99% of all routes. I think that the current policy for IPv6 is one which discourages people from using IPv6. Adding a second type of IPv6 address that is allocated geographically to allow greater topological aggregation (i.e. based on which city the network is in) will encourage use of IPv6 by making it easier for people to get IPv6 addresses. --Michael Dillon From dr at cluenet.de Wed Dec 7 11:54:02 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 7 Dec 2005 11:54:02 +0100 Subject: [address-policy-wg] Re: Re: Re: a consensus, about what? In-Reply-To: <43968FDF.9000502@unfix.org> References: <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> Message-ID: <20051207105402.GA28312@srv01.cluenet.de> On Wed, Dec 07, 2005 at 08:31:43AM +0100, Jeroen Massar wrote: > > You have an AS and do multihome? Pay a small one-time fee (reg effort) > > and small annual fee (to verify that you still do exist care for the > > prefix to stay registered, and to cover costs for the database entries > > for your prefix) and be done with it.[1] > > Note that the billing should then still be 'more' expensive than a LIR's > individual allocation otherwise most LIR's will convert into > independents which gives one more power over prefixes than the above. Nonsense. PI doesn't let the LIR assign IP space to their customers. End site PI ain't an option for real LIRs. Then again, IPv6 PA allocations are extremely easy on NCC workload as the LIR doesn't have to get back to hostmasters for each assignment below the AW (which is 0 in the beginning). So perhaps the cost (score) for IPv6 PA allocations should be SIGNIFICANTLY lower than IPv4 PA allocations. Which would also mean that in relation there should be a XXXXS membership category for folks with only ASN and IPv6 PA alloc which fits the actual workload level... which is almost zero until this LIR comes back and asks for more than the initial no-questions-asked /32 allocation. > A LIR should know the procedures which should make requests very easy to > process, at least that is the idea, which lowers load on the RIR's. Should. Please come back with some hard data from NCC to explain to us that PI holders place a higher workload on NCC staff than any real LIR. Good luck. > Also, what is your equipment budget? At least 2 routers, 2 uplinks, > man-power and a lot of other things. What is ~2K EUR then anyway? You mean "you invested already, so throw some more money out the window, it doesn't hurt too much more"? Especially for non-commercial orgs routers can be donations too, e.g. because they got phased out. > > All those folks who question the right of ASses (AUTONOMOUS systems) to > > have their own IP space and a routing table slot (in lieu of a better, > > sufficiently!capable replacement architecture) for technical reasons > > ("but our routers will break!") should ask themselves one question: are > > YOU ready to return YOUR prefix(es) because you are NOT in the routing > > tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s > > don't have any TECHNICAL need to announce their own allocations. All > > other non-upstream-free ISPs only have ECONOMIC reasons to do so. You > > With a too large routing table (which are indeed far from there) for the > currently deployed routers it will indeed be very economical as they > need to be upgraded. But this does depend on landrush. Running out of > 65k ASN's is the first thing that will happen. Though I wonder if some > smaller routers still deployed at endsites will like to handle that. There is no need for that. Read again. Noone except the real Tier 1s have the _technical_ _necessity_ to run default-free. All others can filter as much as they want, and use default route(s) for all else. > Economics, that is people who won't be able to update their routers, > will then figure out who can have a slot there or not. No, they will start to default as they still need to access the content. > RIR's fortunately do not guarantee routability, thus them giving out > /48's from a single global /16 or so, to sites 'that desperately need > them', allows people who don't want them to filter when table pressure > become tight. Adding some geography in that big block might even allow > one to at least carry the traffic to a 'local' IX to hand it off. Hand it off to whom? You need paid transit for that. That complicates things enormously. That's the whole can-of-worms related to geographic/ geopolitic addressing+routing. I won't delve into that here as it was discussed at length elsewhere. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dogwallah at gmail.com Wed Dec 7 12:13:15 2005 From: dogwallah at gmail.com (McTim) Date: Wed, 7 Dec 2005 14:13:15 +0300 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: <4395A760.6070608@baycix.de> Message-ID: On 12/7/05, Michael.Dillon at btradianz.com wrote: > > In regard to IP addressing policy, it is sufficient for the > RIRs to start doing things more wisely. If the RIRs would open > up another 1/8th of the IPv6 address space for geotop allocations > then they would no longer be blocking this solution. IIUC, the RIRs don't have another 1/8 of the space to "open up". they don't even have the whole of the first 1/8. IANA holds the global pool. The NRO *could* be helpful in lobbying for this, if their communities asked it of them. -- Cheers, McTim $ whois -h whois.afrinic.net mctim From heldal at eml.cc Wed Dec 7 12:17:20 2005 From: heldal at eml.cc (Per Heldal) Date: Wed, 07 Dec 2005 12:17:20 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: Message-ID: <1133954240.7700.249226231@webmail.messagingengine.com> On Wed, 7 Dec 2005 10:32:20 +0000, Michael.Dillon at btradianz.com said: [snip] > Of course, this means that RIRs and ISPs have to cooperate in > allocating IPv6 addresses using a rough kind of geographical > plan. I suggest that this plan be anchored to the major cities > where most interconnecting is done. This is also roughly aligned > with the topology of the network if you can manage to visualize > an entire city (Paris, London, Hannover, Krivoy Rog) as a single > node in a network. It's that level of abstraction that leads to > making sense of this kind of aggregation. ... and free transit into each geographical region would be mandatory ??? Aggregation across multiple administrative domains isn't just a minor technical change. It would eliminate the transit-provider business model. Disruptive technologies are facts of life and nobody has a god-given right to existence, but don't expect long-haul carriers to give up their business without a fight. //per -- Per Heldal heldal at eml.cc From Michael.Dillon at btradianz.com Wed Dec 7 12:44:36 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 11:44:36 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512061909.jB6J9chq022181@alpha.bartels.de> Message-ID: > The same is true for geographical aggregation. > Geographical aggregation would require free transit, otherwise > it is not compatible with the ISP's business models. Geographical aggregation does not REQUIRE free transit. It is up to the ISPs to decide how to leverage geographical aggregation, how to recover transit costs and how to construct and change their business models. We should not assume that any of these things are static and unchangeable. > There is no free transit and thus it doesn't work. > Business relations changes all the time and in a global markets > world these business relations don't stop on country boundaries. > > Such boundaries are artifical, the EU tries to avoid them. Nevertheless, the Rhine river still exists. The Alps still exist. Is it easier to get fiber across the Rhine or through the Alps? This kind of geography affects the roads, railways and fiber paths throughout Europe. It affects the economy of European cities which determines the location and size of these cities. The city level of geographical aggregation clearly works. The real question is whether or not there is a level of aggregation possible between city and continent. I think that this question will only be solved by looking a the cities and the communication between them. In some regions there will be natural clusters of cities that form a natural aggregation grouping, for instance the U.S. East Coast. But in other areas there may be no clusters. In any case, national boundaries will almost never be related to these clusters except maybe someplace like China where culture, language and economy are closely tied to the national borders. But that is an exceptional case and perhaps it is no longer valid. Hong Kong, China has close ties with Singapore, another country. And cities like Khabarovsk, Russia probably have more economic ties with China than with Moscow. It's really a question for geographers to answer, not network engineers. So where are the geographers on this policy mailing list? > What they try is interleaving the West-East (X) and North-South (Y) > coordinates bitwise in the search key and handle overruns by exceptions, > like: Geographical aggregation does NOT require geographical coordinates to be encoded in address bits. In fact, once the RIRs have decided how many addresses to reserve for each city greater than 100,000 population, and how to cluster cities in to larger groupings, there is no need for anyone to think about the geographical issues again. --Michael Dillon From Michael.Dillon at btradianz.com Wed Dec 7 12:53:08 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 11:53:08 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <1133954240.7700.249226231@webmail.messagingengine.com> Message-ID: > ... and free transit into each geographical region would be mandatory > ??? > > Aggregation across multiple administrative domains isn't just a minor > technical change. It would eliminate the transit-provider business > model. Disruptive technologies are facts of life and nobody has a > god-given right to existence, but don't expect long-haul carriers to > give up their business without a fight. Transit provider business models are not the same everywhere. Nobody will be forced to give anyone free transit. Yes, it is true that geotop aggregation leads to more use of cold-potato routing, but that is a problem for the providers to deal with. If they want to use geotop aggregation and if it results in a shift of traffic patterns and if that requires negotiating new business models or transit contracts then there are no technical barriers to doing this. RIRs can only make addressing policy, not mandate business models. As long as geotop addressing is implemented in addition to the classical IPv6 addressing model, nobody will be forced to do anything that they don't want to. However, new entrants into the market will be able to do things that are impossible today. This will lead to change. The fact that a new addressing policy does not create miracles, only possibilities, is not sufficient reason to oppose such a policy. In fact, it is likely that existing providers will dip their toes in the water and make some limited use of geotop addressing to enable them to offer new metro-multihoming services to small organizations that only need multihoming within a single city. This is fairly straightfoward to do. In addition to geotop addressing, it only requires two providers to negotiate a local peering agreement and that is probably already in place for classic IPv4 peering. In any case, none of these problems are insurmountable and none of them dilute the case for geotop addressing as AN ADDITIONAL OPTIONAL TYPE OF IPV6 ADDRESSING. --Michael Dillon From oliver at bartels.de Wed Dec 7 13:12:10 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 07 Dec 2005 13:12:10 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: Message-ID: <200512071211.jB7CBfhq013442@alpha.bartels.de> On Wed, 7 Dec 2005 11:44:36 +0000, Michael.Dillon at btradianz.com wrote: >Geographical aggregation does not REQUIRE free transit. >It is up to the ISPs to decide how to leverage geographical >aggregation, how to recover transit costs and how to >construct and change their business models. A Management Consultant would say: "Our solution, your problem" >Nevertheless, the Rhine river still exists. http://www.spiegel.de/politik/deutschland/0,1518,388814,00.html ( In English: Kehl and Strassbourg want to work jointly together to form a single Eurodistrict / city with e.g. a single phone network. ) The Rhine is no border at all for bits and bytes, use a STM-1 directional radio link. >The Alps still exist. ... and offer great opportunities for radio links, too. Again: A STM-1 between Frankfurt and London will be typically less expensive than between Frankfurt and Wiesbaden. >In fact, once the RIRs have decided how many addresses to >reserve for each city greater than 100,000 population, and how >to cluster cities in to larger groupings, there is no need for >anyone to think about the geographical issues again. And then every ISP puts in a prefix for his part of the geopolitical address range of every city in which it shows presence, thus giving us an enormous growth in the number of routing table prefixes. Great idea, obviously suitable for the "big prize" of the association of memory chip makers ... 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 heldal at eml.cc Wed Dec 7 13:12:01 2005 From: heldal at eml.cc (Per Heldal) Date: Wed, 07 Dec 2005 13:12:01 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: Message-ID: <1133957521.12940.249228673@webmail.messagingengine.com> On Wed, 7 Dec 2005 11:44:36 +0000, Michael.Dillon at btradianz.com said: > > The same is true for geographical aggregation. > > Geographical aggregation would require free transit, otherwise > > it is not compatible with the ISP's business models. > > Geographical aggregation does not REQUIRE free transit. [Does Fedex deliver goods to everybody in a region if only one customer in the region pays for their service?] An alternative way to keep things local would be through enforced confederations or similar construct, where partitipants would have to share a common external routing-policy and transit costs. I suspect that quite a few small providers would object to be forced to cooperate with all their competitors. In some places it may even be considered anti-competitive by law. There may however be places where such cooperation is appropriate, in which case RIR-policies should accomodate such a construct. ISP's who want such cooperation should probably establish an independent organisation that would act as the LIR for their region. There's nothing (exept possibly the 200 customer limit) in the current RIR-policy that prevents such a construct. //per -- Per Heldal heldal at eml.cc From marcus.gerdon at mainz-kom.de Wed Dec 7 13:13:07 2005 From: marcus.gerdon at mainz-kom.de (Marcus Gerdon) Date: Wed, 7 Dec 2005 13:13:07 +0100 Subject: [address-policy-wg] Re: Re: a consensus, about what? References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> Message-ID: <005d01c5fb27$95345ba0$df2f1fac@avalon> Hi @all, first: thanks @Carlos for your response. I've read a lot of statements and position herein, some making sense to me, some hinting a way to go on and some simply sounding like 'ground-keeping'. I'd like to try to sum up the problems (real, possible future, self-made) and add a few thoughts myself. Currently there're ~35.000 AS'es handed out with ~180.000 prefixes carried in the v4 table. The v6 table houlds about 500-600 prefixes now. According RIPE-353 about 1/4 to 1/3 of the ASN handed out aren't seen in the forwarding paths. This leads to the first (and I think most urgent problem) taking a look at the rate ASN's a assigned nowadays. In rough numbers there're about 10.000 ASN not being visible in the routing table. And like someone else already mentioned in the 'multi-homing v6' discussion, how many of the newly handed out ASN are really required for multihoming ? I don't want to open a discussion about 'proper' way to multihome (again), but how many of the 'corporate' ASN handed out are really going to connect to more than one upstream provider ? (I know of LIR's operating their network with dual uplinks for the same upstream and a 'fake' secondary. Before someone starts shouting how to know: one of our aligned companies had been on of these.) During my years in ISP networking bussiness I've more than once come upon a network with fake entries and customers/potential customers multihoming to one upstream and asking for an ASN request with a second upstream being 1/50th to 1/10th of the primary bandwidth to satisfy requirements. These setups I'm almost sure don't need an ASN. And how about the non-visible ASN ? They may be hoarded, used for confed's after mergers & takeovers, a few for test networks (if reasonable argumented I agree here) or simply not returned to the pool after removal due to laziness. So first point to consider when talking 'needless' resources is: how to possibly limit the number of multihoming-ASN handed out to the ones really needed and how to move people to hand them back when no longer needed ? In case of PI space this is a bit more complicated. Adresses hasn't to be visible in the global routing tables to satisfy a need for globally unique adresses. Although in v4 world, RFC1918 & NAT are a fine thing to conserve address space, but forcing their use would be dictating others how to operate their network. This gets me to the assumption not every PI address space will get through to the routing tables. Surely PI space mostly not being aggregatable is filling up the tables with prefixes. But don't the de-aggregated PA's also do ? And what about invalid announcements (take a look to your table and search for ASN >=65512 !) ? What about the (IMHO) pollution of the table with nonsene of entries longer - let's say - /24 ? Did you ever take a look about your table in regard to prefix sizes ? There's a lot of /28 - /30 flowing around. At least for the /30 I think there're guys messing up their redist and BGP filters. Before we - the LIR admins - aren't able to agree on senseful filters and what's mess not to be announced (prefix length) and behave ourselves (de-aggregates) where's the right to discussing other peoples needs ? (just a comment: I've read someone here stating something like: do what you want, but not in my table. Hopefully there's no flaw to find in YOUR announcements ....) I've written in my previous (messy) post, but again: are we the ones entitled to decide how a customer has to run it's network and what he needs and what not ? Let me ask a simple question: how many of you do work directly in first line on your customers (in means of consulting your sales guys) ? Customers (especially corporate) nowadays are striving for redundant / multihomed connectivity and - the Level3/Cogent de-peer a few months ago showed this - how can you be 100% sure connectivity even by multiple links to one ISP won't take you offline ? There could be a serious network issue, a de-peer, the network could be blown by one of those nasty bot-nets etc. Many companies are moving ever more bussiness towards their internet access and therefore they reasonably ask for best connectivity possible (at reasonable cost). You can shake your head as furiously you like, but the primary target won't change: customer's demand. Did you always try to tell your boss that you wouldn't submit a PI or ASN request for a potential customer ? I bet you wouldn't do that often - maybe more than once, but you'd soon be looking for a job. Often a solution can be worked out together with the customer but not always. The customer will simply move on to another ISP willing to - at least try to - fulfil his wishes. PI space in v6 in demanded by customers the same way it is for v4. Either there'll be a way to satisfy this need or a solution to the multihoming dilemma with globally unique adresses SHORTLY or IPv6 can be dropped RIGHT NOW. This get's the second and third thing to consider: how do we get people to hand back no longer needed PI space and how will we handle IPv6 PI ? On side of the ISP's there're worries about size of the routing tables and the costs to replace your routers. But did you take a look at the growth rate of utilized bandwidth ? All these 'high-bandwidth' consumer links like DSL and such are driving bandwidth requirements up and up steadily. How long do you think your routers can keep with the traffic volume ? With number and bandwidth of consumer internet access increasing also the risk of floods and the basic 'trash' flowing around increases. On customers side there're worries about stablility and cost also, but maybe taken in another perspective. Corporate customers are willing (at least most of them) to pay more for a stable setup lowering (or at least pinning) their TCO. This includes not having to renumber regularly and/or being dependent on one ISP. But even if they are willing to pay more for true multihoming I'd like to hear how you sell them becoming a LIR themselves although they will never provide internet services to others but would have to care for a lot rules and administrative work in addition. PI as it's administrative nature is now is exactly what the want and need. So regardless where you put your eyes upon, it always comes back to money. So why not take (try) a simple approach. - get IPv6 (corporate-)ready by handing out PI space out of a well-known address space in chunks of /40 to /48 - limit the routing table size by agreeing on 'best practice' filters for prefix-length - limit the routing table size by bashing de-aggregators --- just kidding ... --- - limit routing table size and assigned resources by creating a motivation to hand resourced back. The last item is IMHO the crucial. RIPE-330 charging scheme states: Note: For AS Numbers and PI IPv4 allocations, only the allocations from the past 12 months dating back from the 30 September 2004 are taken into account as these resources are allocated or assigned on behalf of third parties. WHY ??? Let non-LIR's pay for their resources as well, but without requiring them to become a LIR. I'd propose something like: Add a new member category 'corporate' for those who don't provide internet services to others but are in need of resources and assign a charging scheme without any time variable. One-time: 500 EUR yearly: 250 EUR per ASN: 250 EUR (per year) per PI assignment: 150 EUR (per year) With at least 650 EUR a year people would think twice about their needs. In addition remove the ASN's for ISP's from this charging scheme and also charged fixed 250 EUR per ASN/year. This would hopefully push at least some people to hand back no longer used ASN or 'official' ASN used for confed's. regards, Marcus ---------------------------------------------------------- Tropolys Rhein-Main GmbH Network Engineering and Administration Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 Mombacher Str. 40, 55122 Mainz, Germany ---------------------------------------------------------- AS15837 | AS8638 | MG3031-RIPE ---------------------------------------------------------- From marcus.gerdon at mainz-kom.de Wed Dec 7 13:39:22 2005 From: marcus.gerdon at mainz-kom.de (Marcus Gerdon) Date: Wed, 7 Dec 2005 13:39:22 +0100 Subject: AddOn --- Re: [address-policy-wg] Re: Re: a consensus, about what? References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> <005d01c5fb27$95345ba0$df2f1fac@avalon> Message-ID: <008c01c5fb2b$3fd1d990$df2f1fac@avalon> A thought just crossed my mind: those of you striving to deny slots in the routing tables to non-LIRs, what do you think about splitting a PA and announcing parts out of different AS'es ? This isn't really a de-aggregate, serves the 'address conservation' constraint but is utilizing routing table space. Wasn't the 'sub-allocation' type intended for this and must have had some consensus to become implemented ? Maybe there should be added a PA allocation rule that each PA has to be announced only out of one AS. No ? We can't do this ? Why not ? Be splitting PA's this way the LIR create a address space type that can be moved along very similar to PI, just without being handed out directly to the customer. Would be an idea: I split one of our PA into /24's and lend them to enterprise customers free for announcement via their favourite ISP charging a yearly fee (obvisously the fee only for administering the RIPE data, as charging for addresses isn't allowed.). Marcus ---------------------------------------------------------- Tropolys Rhein-Main GmbH Network Engineering and Administration Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 Mombacher Str. 40, 55122 Mainz, Germany ---------------------------------------------------------- AS15837 | AS8638 | MG3031-RIPE ---------------------------------------------------------- ----- Original Message ----- From: "Marcus Gerdon" To: Sent: Wednesday, December 07, 2005 1:13 PM Subject: Re: [address-policy-wg] Re: Re: a consensus, about what? From debecker at etno.be Wed Dec 7 13:41:26 2005 From: debecker at etno.be (Debecker J.L.) Date: Wed, 7 Dec 2005 13:41:26 +0100 Subject: [address-policy-wg] ETNO and ETNO Member participation in RIPE Address Policy WG Message-ID: <000001c5fb2b$8a4dd7d0$0b01a8c0@etno.be> Hans Petter Holen Chairman RIPE Address Policy WG Dear Mr. Holen, Thank you for your e-mail dated 7 November seeking clarification about ETNO's input by means of our Expert Contribution EC064 on IPv4 address space allocation. Attached and below you will find a reply message from Michael Bartholomew, ETNO Director. In summary our views are that: - individual ETNO Members contribute substantially to RIPE and they are encouraged by the Association to do so - ETNO fully recognises and supports RIPE, its committees and decisions - ETNO actively participates in RIPE activities and contributes among others by inputting the collective, formally approved views of 41 operator companies - which would probably be difficult to match by means of direct participation. Best regards, Leo Debecker Executive Manager, Operations ------------ Hans Petter Holen, Chairman RIPE Address Policy WG Dear Sir, Thank you for the e-mail you sent to the RIPE Address Policy WG mailing list on 7 November and the concerns you expressed as RIPE Address Policy WG Chairman. ETNO (1) believes it would be of use to explain the rationale behind the IPv4 address space allocation contribution that you refer to. As you are aware, ETNO represents 41 major telecommunications operators from 34 European countries. Its Members participate in about 20 ETNO working groups addressing common areas of specific interest. One of these deals with Naming, Numbering and Addressing Issues (NANI WG) from a policy perspective. Its participants have recognised expertise in relevant policy issues, but are not necessarily involved in the day-to-day management of IP Addresses. The NANI WG is an important forum to discuss common E164 and IP related policy areas of specific interest to ETNO's membership. ETNO views are expressed in position papers, which are approved by its Members using formal processes and documented rules. These position papers are publicly available on ETNO's web site. It should be stressed that ETNO Members represent a significant share of large and extra large registries in Europe. These registries follow all the processes and policies issued by RIPE. In addition, ETNO Members rely on commonly and formally agreed ETNO position papers to provide input into the RIPE community. There is thus two-way interaction between RIPE and individual ETNO Members. As for ETNO itself: the Association and its Members are committed to contribute to the RIPE community, with the participation of an ETNO representative in RIPE meetings who disseminates feedback to ETNO Members. As mentioned, some ETNO Members participate at RIPE meetings as company representatives. ETNO encourages its Members to actively participate in RIPE. RIPE is the forum dealing with Address Policy issues for the RIPE region that includes Europe, and ETNO supports this through its contributions and participation. IP Addressing has become a major issue in recent years as all ETNO Members have established ISPs. IP addressing will increase in importance in the future as operators move towards the introduction of Next Generation Networks (NGN). In the past ETNO has adopted a number of positions on IP addressing policy issues, the last one being on the IPv4 HD ratio issue, which was unanimously approved. ETNO's position was communicated to the RIPE community through the RIPE Address Policy WG mailing list. This shouldn't be thought of as challenge to RIPE and it's working methods but as a supportive input. ETNO is of the opinion that by engaging within the RIPE community, delivering the joint concerns of its 41 Members and assisting in the development of an appropriate IP address policy, we act to the benefit all interested stakeholders - a role which ETNO is happy to fulfil. Yours sincerely, Michael Bartholomew, ETNO Director (1) ETNO (European Telecommunications Networks Operators' Association) is the recognised voice of the European Telecommunications network operators with over a decade of experience in shaping EU telecoms policy. The association represents 41 companies from 34 European countries. They account for an aggregate turnover of more than 210 billion Euros within Europe and employ more than one million people. The association is widely recognised for its expertise on various topics including technical and regulatory matters, but also issues such as network naming and addressing, environmental protection, sustainability and network security. An indication of the scope of issues and the work undertaken by ETNO can be demonstrated by the information on its web site (www.etno.be). -------------- next part -------------- A non-text attachment was scrubbed... Name: RIPE policy WG Chair letter.doc Type: application/msword Size: 47104 bytes Desc: not available URL: From president at ukraine.su Wed Dec 7 13:53:04 2005 From: president at ukraine.su (Max Tulyev) Date: Wed, 7 Dec 2005 15:53:04 +0300 Subject: AddOn --- Re: [address-policy-wg] Re: Re: a consensus, about what? In-Reply-To: <008c01c5fb2b$3fd1d990$df2f1fac@avalon> References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <005d01c5fb27$95345ba0$df2f1fac@avalon> <008c01c5fb2b$3fd1d990$df2f1fac@avalon> Message-ID: <200512071553.05075.president@ukraine.su> Hi! As I can see, the main idea of these threads is large carriers trying to implement a kind of trust agreement policy (monopoly) that deny non-carriers (ideally small carriers too) to be the independent part of the Internet, but only their end-users. Like it is now in PSTN. If the community accept that, your though will be denied too. The main question is Internet is for carriers (' profit) or carriers is for Internet (community). What is the main thing? > A thought just crossed my mind: > > those of you striving to deny slots in the routing tables to non-LIRs, what > do you think about splitting a PA and announcing parts out of different > AS'es ? This isn't really a de-aggregate, serves the 'address conservation' > constraint but is utilizing routing table space. Wasn't the > 'sub-allocation' type intended for this and must have had some consensus to > become > implemented ? > > Maybe there should be added a PA allocation rule that each PA has to be > announced only out of one AS. > > No ? We can't do this ? Why not ? Be splitting PA's this way the LIR create > a address space type that can be moved along very similar to PI, just > without being handed out directly to the customer. > > Would be an idea: > I split one of our PA into /24's and lend them to enterprise customers free > for announcement via their favourite ISP charging a yearly fee (obvisously > the fee only for administering the RIPE data, as charging for addresses > isn't allowed.). > > Marcus > > ---------------------------------------------------------- > Tropolys Rhein-Main GmbH > > Network Engineering and Administration > > Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 > Mombacher Str. 40, 55122 Mainz, Germany > ---------------------------------------------------------- > AS15837 | AS8638 | MG3031-RIPE > ---------------------------------------------------------- > > > ----- Original Message ----- > From: "Marcus Gerdon" > To: > Sent: Wednesday, December 07, 2005 1:13 PM > Subject: Re: [address-policy-wg] Re: Re: a consensus, about what? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From clive at demon.net Wed Dec 7 13:20:49 2005 From: clive at demon.net (Clive D.W. Feather) Date: Wed, 7 Dec 2005 12:20:49 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: <200512061909.jB6J9chq022181@alpha.bartels.de> Message-ID: <20051207122049.GM62433@finch-staff-1.thus.net> Michael.Dillon at btradianz.com said: > Nevertheless, the Rhine river still exists. The Alps still > exist. Is it easier to get fiber across the Rhine or through > the Alps? It's not that hard any more. > This kind of geography affects the roads, railways > and fiber paths throughout Europe. It affects the economy > of European cities which determines the location and size > of these cities. The city level of geographical aggregation > clearly works. Not so. To a first approximation, there is *no* level of aggregation in the UK that works below UK-wide. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From jeroen at unfix.org Wed Dec 7 15:12:02 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 07 Dec 2005 15:12:02 +0100 Subject: AddOn --- Re: [address-policy-wg] Re: Re: a consensus, about what? In-Reply-To: <008c01c5fb2b$3fd1d990$df2f1fac@avalon> References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> <005d01c5fb27$95345ba0$df2f1fac@avalon> <008c01c5fb2b$3fd1d990$df2f1fac@avalon> Message-ID: <4396EDB2.9050206@unfix.org> Marcus Gerdon wrote: > A thought just crossed my mind: > > those of you striving to deny slots in the routing tables to non-LIRs, what > do you think about splitting a PA and announcing parts out of different > AS'es ? This isn't really a de-aggregate, serves the 'address conservation' > constraint but is utilizing routing table space. Wasn't the 'sub-allocation' > type intended for this and must have had some consensus to become > implemented ? See my message about "De-aggregation of assigned IPv6 prefixes?" and Gert's response on it. ISP's are already doing this in IPv6. The only thing to 'stop' it is to have "most" ISP's filter those announcements. But even if you filter then the prefix is still reachable through the aggregate, thus connectivity isn't lost. > Maybe there should be added a PA allocation rule that each PA has to be > announced only out of one AS. This rule can be configured on your the router(s) in your network. It's called filters and that is up to you to configure or not. > No ? We can't do this ? Why not ? Be splitting PA's this way the LIR create > a address space type that can be moved along very similar to PI, just > without being handed out directly to the customer. Cool huh :) > Would be an idea: > I split one of our PA into /24's and lend them to enterprise customers free > for announcement via their favourite ISP charging a yearly fee (obvisously > the fee only for administering the RIPE data, as charging for addresses > isn't allowed.). You have a mostly valid business case here (IANAManager/Banker :) Instead of an end-site going to the RIRs for IP space, let them come to you, you being LIR. You as a LIR give them a /48 (or more) and say they can use their own ASN to announce it to their peers and transits. As long as those parties accept it they are fine. This also means you will have a plan for 200 potential customers :) The first side-effect is that your customers are (partially) dependent of you, you as LIR disappears, then they don't have squat. Then again if RIPE disappears, what then? :) Also they depend on you to carry the PA of their prefix in case their PI breaks, but they can see that as 'extra service. When their /48 gets filtered with normal PI they would not have anything at all, now their packets can still be delivered. Note also that there is no need for requirement that you as a LIR actually carry packets for them as long as their route is available. Good thing: LIR costs/members = low costs :) WARNING: Also note that there are a number of places where there is quite some strict filtering happening. This might result that your small /48 gets filtered out by fast/good "transits", but accepted by slow/bad "transits", thus causing you to be pretty unreachable over those ASN's. This has already been seen a couple of times in IPv6 routing tables! Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From Michael.Dillon at btradianz.com Wed Dec 7 15:29:10 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 14:29:10 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <1133957521.12940.249228673@webmail.messagingengine.com> Message-ID: > [Does Fedex deliver goods to everybody in a region if only one customer > in the region pays for their service?] Yes. That is part of their business model. The sender pays Fedex to deliver the parcel and they offer their service in regions that are receiver-dense as well as regions that are sender-dense or balanced. > An alternative way to keep things local would be through enforced > confederations or similar construct, Indeed, pointing a gun in somebody's face is always an option. However, in the realm of politics which we are discussing, this is an option that should not be under consideration. RIR policy is only concerned with address allocation, not with network provider contracts or with peering policy or facilities construction or anything else. The only thing that RIRs can enforce is address allocation policy and practice. > There may however be places where such cooperation is appropriate, in > which case RIR-policies should accomodate such a construct. ISP's who > want such cooperation should probably establish an independent > organisation that would act as the LIR for their region. There's nothing > (exept possibly the 200 customer limit) in the current RIR-policy that > prevents such a construct. As has been repeatedly pointed out by others, the 200 customer limit is a REAL block to deployment of IPv6 by many companies. Until IPv6 allocation policies are made reasonable without silly artificial constraints with no reasoning behind them, then it is a little early to discuss regional cooperative LIRs. One data point that we already have is exchange points. How many exchange points in Europe have been successful in receiving a /20 allocation from RIPE? How many in other regions? I suspect that the answer is zero because RIR policies discourage the allocation of IP addresses to such confederations. --Michael Dillon From Michael.Dillon at btradianz.com Wed Dec 7 15:40:47 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 14:40:47 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512071211.jB7CBfhq013442@alpha.bartels.de> Message-ID: > Again: A STM-1 between Frankfurt and London will be > typically less expensive than between Frankfurt and > Wiesbaden. This is not about cost. Does an STM-1 between Wiesbaden and London cost less than one between Wiesbaden and Frankfurt? Or does it pass through Frankfurt because it is a neighbouring city? If we did use a geotopological allocation scheme for another 1/8th of the IPv6 address space, this is an example of an area where there is a logical clustering of cities into a larger geographical aggregate. Wiesbaden, Mainz, Darmstadt and Frankfurt are all over 100,000 population. It is logical to reserve a single aggregate for them that covers all 4 city aggregates. That way, providers can choose to accept all city-level aggregate routes or to only see the single regional aggregate. Chances are that North American providers will only use the one regional aggregate while man Europeans will distinguish all 4 cities. > And then every ISP puts in a prefix for his part of the geopolitical > address range of every city in which it shows presence, thus > giving us an enormous growth in the number of routing table prefixes. That's not how IP routing works. Anyone can announce any route that they want, but network providers filter incoming route announcements based on some sort of logical view of the network topology. In other words, they refuse to see details that they believe are unimportant to them. Geotopological addressing provides a nice framework for ISP filtering because they can ignore longer prefixes within a city aggregate if it makes sense for them to treat the entire city as a single destination. Geotop addressing doesn't mandate how filtering is done, it is just an enabler. --Michael Dillon From gert at space.net Wed Dec 7 15:44:21 2005 From: gert at space.net (Gert Doering) Date: Wed, 7 Dec 2005 15:44:21 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: <1133957521.12940.249228673@webmail.messagingengine.com> Message-ID: <20051207144421.GG69925@Space.Net> Hi, On Wed, Dec 07, 2005 at 02:29:10PM +0000, Michael.Dillon at btradianz.com wrote: > One data point that we already have is exchange points. How many > exchange points in Europe have been successful in receiving a > /20 allocation from RIPE? How many in other regions? I suspect > that the answer is zero because RIR policies discourage the allocation > of IP addresses to such confederations. Help me with this: how many customers (each getting a /48) does a typical exchange point have, and how do you reach a /20 from there? If you're going to split it into separate /32s or so, per connected ISP - where's the benefit for the ISP in getting address space from an IXP? (It might be cost effective, but that's not very much related to the IXP being an exchange point, more to being a "mega-LIR" with some cost benefits to its members). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 Michael.Dillon at btradianz.com Wed Dec 7 15:51:35 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 14:51:35 +0000 Subject: [address-policy-wg] Re: Re: a consensus, about what? In-Reply-To: <005d01c5fb27$95345ba0$df2f1fac@avalon> Message-ID: > This leads to the first (and I think most urgent problem) taking a look at > the rate ASN's a assigned nowadays. In rough numbers there're about 10.000 > ASN not being visible in the routing table. And like someone else already > mentioned in the 'multi-homing v6' discussion, how many of the newly handed > out ASN are really required for multihoming ? There are a thousand ways in which an ASN used for multihoming between two upstreams will fail to appear in RIS or routeviews. If anybody is really serious about figuring out what is going on, then they will do a REAL research project using telephone and email to contact the human beings who know the facts behind the use of these ASNs. No doubt some of those human beings will confirm that an ASN is no longer in use, but many others will point out how their ASN is in use even if it is invisible to crude 3rd party probing technology. > During my years in ISP networking bussiness I've more than once come upon a > network with fake entries and customers/potential customers multihoming to > one upstream and asking for an ASN request with a second upstream being > 1/50th to 1/10th of the primary bandwidth to satisfy requirements. Sounds to me like a live circuit plus a failover circuit. Some people call this good engineering. > These setups I'm almost sure don't need an ASN. If they were engineered to use BGP then they definitely do NEED an ASN. If you are saying that they should be engineered differently, then I have to ask you to move your discussion to RIPE's "ISP Engineering rules" working group because you have gone beyond IP addressing policy. > So first point to consider when talking 'needless' resources is: > how to possibly limit the number of multihoming-ASN handed out to the ones > really needed and how to move people to hand them back when no longer needed > ? No, actually the first point to consider is whether or not recovering every last "missing" ASN will solve the ASN shortage problem. People did consider this and the answer was NO. Therefore, the focus has been on making longer ASNs rather than recovering the few missing ones. > Although in v4 world, RFC1918 & NAT are a fine thing to conserve > address space, but forcing their use would be dictating others how to > operate their network. I suppose that you don't believe in dictating how people should operate their networks? What about how people should engineer their networks? --Michael Dillon From jeroen at unfix.org Wed Dec 7 15:51:30 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 07 Dec 2005 15:51:30 +0100 Subject: [address-policy-wg] Re: Re: Re: a consensus, about what? In-Reply-To: <20051207105402.GA28312@srv01.cluenet.de> References: <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> <20051207105402.GA28312@srv01.cluenet.de> Message-ID: <4396F6F2.9070001@unfix.org> Daniel Roesen wrote: > On Wed, Dec 07, 2005 at 08:31:43AM +0100, Jeroen Massar wrote: >>> You have an AS and do multihome? Pay a small one-time fee (reg effort) >>> and small annual fee (to verify that you still do exist care for the >>> prefix to stay registered, and to cover costs for the database entries >>> for your prefix) and be done with it.[1] >> Note that the billing should then still be 'more' expensive than a LIR's >> individual allocation otherwise most LIR's will convert into >> independents which gives one more power over prefixes than the above. > > Nonsense. PI doesn't let the LIR assign IP space to their customers. End > site PI ain't an option for real LIRs. This is not what I meant. But why would endsite PI not be an option for 'real LIR's? What is a 'real LIR' actually according to you and what isn't? They all are in it for the money in the end. If their business is renting out "address space" (like the RIR's do effectively) then so be it, that is their business. > Then again, IPv6 PA allocations are extremely easy on NCC workload as > the LIR doesn't have to get back to hostmasters for each assignment > below the AW (which is 0 in the beginning). So perhaps the cost (score) > for IPv6 PA allocations should be SIGNIFICANTLY lower than IPv4 PA > allocations. Which would also mean that in relation there should be a > XXXXS membership category for folks with only ASN and IPv6 PA alloc > which fits the actual workload level... which is almost zero until this > LIR comes back and asks for more than the initial no-questions-asked /32 > allocation. This is indeed what I meant with 'more expensive'. There are maybe some LIR's now though who don't want to be a LIR, but only did so to get address space. These might want to drop to the xxxxxs membership category to reduce cost at a certain point. >> A LIR should know the procedures which should make requests very easy to >> process, at least that is the idea, which lowers load on the RIR's. > > Should. Please come back with some hard data from NCC to explain to us > that PI holders place a higher workload on NCC staff than any real LIR. > Good luck. There might not be one, but you can expect it to be this way. Maybe add a 'failed request' 'extra work' 'number of requests' etc to the scoring scheme to take care of this? One time requesters most likely don't know the policy, while LIR's do as they should be doing it way more often. Of course some independent contractor could do a lot of PI requests for independent organisations, but then that entity is sort of working like a LIR, but then differently. >> Also, what is your equipment budget? At least 2 routers, 2 uplinks, >> man-power and a lot of other things. What is ~2K EUR then anyway? > > You mean "you invested already, so throw some more money out the window, > it doesn't hurt too much more"? Especially for non-commercial orgs > routers can be donations too, e.g. because they got phased out. Then let them donate a bit of money too. There seems to be a lot of 'free money' floating around on the web. Just for your enjoyment, getting $430 US to smash up a brand new Xbox 360 seems possible: http://www.lapblog.com/xbox-360-smash-up/151/ Getting 2k EUR for something you apparently desperately want, call critical and useful is not a problem then anymore I would assume. >>> All those folks who question the right of ASses (AUTONOMOUS systems) to >>> have their own IP space and a routing table slot (in lieu of a better, >>> sufficiently!capable replacement architecture) for technical reasons >>> ("but our routers will break!") should ask themselves one question: are >>> YOU ready to return YOUR prefix(es) because you are NOT in the routing >>> tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s >>> don't have any TECHNICAL need to announce their own allocations. All >>> other non-upstream-free ISPs only have ECONOMIC reasons to do so. You >> >> With a too large routing table (which are indeed far from there) for the >> currently deployed routers it will indeed be very economical as they >> need to be upgraded. But this does depend on landrush. Running out of >> 65k ASN's is the first thing that will happen. Though I wonder if some >> smaller routers still deployed at endsites will like to handle that. > > There is no need for that. Read again. Noone except the real Tier 1s > have the _technical_ _necessity_ to run default-free. All others can > filter as much as they want, and use default route(s) for all else. I thought you needed PI because you wanted to do "traffic engineering", how are you going to do traffic engineering with the following in your tables: ::/0 fe80::2 eth0 ::/0 fe80::1 eth1 Or you only want "Inbound TE" ($world to you) and not "Outbound TE"? Some people might want to do it differently. >> Economics, that is people who won't be able to update their routers, >> will then figure out who can have a slot there or not. > > No, they will start to default as they still need to access the content. Thus add extra prefixes to the routing tables, let everybody upgrade their routers, but don't do it yourself. Nice. Letting others pay for your dirt. >> RIR's fortunately do not guarantee routability, thus them giving out >> /48's from a single global /16 or so, to sites 'that desperately need >> them', allows people who don't want them to filter when table pressure >> become tight. Adding some geography in that big block might even allow >> one to at least carry the traffic to a 'local' IX to hand it off. > > Hand it off to whom? You need paid transit for that. You want everything for free? :) I know the OCCAID folks are getting close to a global free transit network, but they also only arrive at IX's, your equipment still needs to be there to use those resources. People are not coming to you. But hey you know that very well :) Also note the 'might' in the above block of text, it is an idea for helping out the people who want things for free. > That complicates > things enormously. That's the whole can-of-worms related to geographic/ > geopolitic addressing+routing. I won't delve into that here as it was > discussed at length elsewhere. Oh don't worry, I don't see that working either. Too much politics. Greets, Jeroen PS: where are all those companies who are in desperate need for this? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Wed Dec 7 15:52:39 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 07 Dec 2005 15:52:39 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: Message-ID: <4396F737.3000400@unfix.org> Michael.Dillon at btradianz.com wrote: > Non-attributed person wrote: >> There may however be places where such cooperation is appropriate, in >> which case RIR-policies should accomodate such a construct. ISP's who >> want such cooperation should probably establish an independent >> organisation that would act as the LIR for their region. There's nothing >> (exept possibly the 200 customer limit) in the current RIR-policy that >> prevents such a construct. > > As has been repeatedly pointed out by others, the 200 customer > limit is a REAL block to deployment of IPv6 by many companies. Which companies? According to the stats* Leo gave only 6 requests where ever denied based on this. Can these companies please come forward and explain what they exactly want? * = http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6numbers.pdf > Until IPv6 allocation policies are made reasonable without silly > artificial constraints with no reasoning behind them, then it > is a little early to discuss regional cooperative LIRs. "Regional cooperative LIRs" can already be made now, with current policy. > One data point that we already have is exchange points. How many > exchange points in Europe have been successful in receiving a > /20 allocation from RIPE? Why would an exchange point need a /20? (IPv4 or IPv6?). Most IX's, not any I know of, don't have a need for so much address space and certainly, to stay neutral will not be able to provide address space to customers. If IX's did do that they would be a LIR-ISP again and there goes the I from PI. > How many in other regions? I suspect > that the answer is zero because RIR policies discourage the allocation > of IP addresses to such confederations. Dig a bit and find live data: http://www.ripe.net/rs/ipv6/stats/ Also check: http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html Greets, Jeroen BTW: GRH doesn't cover IX assignments (yet), does it need to maybe? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From Michael.Dillon at btradianz.com Wed Dec 7 15:58:22 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 14:58:22 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <20051207122049.GM62433@finch-staff-1.thus.net> Message-ID: > To a first approximation, there is *no* level of aggregation in the UK that > works below UK-wide. If that were really true, and I suspect that it is only true for the very largest providers, then there is an easy solution. Providers who see no benefit in using geotop addressing should continue to use classical IPv6 addressing. Geotop addressing is not a prescription for rearchitecting the Internet, just an enabler for ISPs who want to give small and medium size organizations real multihomed diverse connectivity to the Internet. These organizations will consume hundreds of thousands of AS numbers and global routing slots unless their routes can be collapsed into city aggregates. --Michael Dillon From oliver at bartels.de Wed Dec 7 16:35:01 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 07 Dec 2005 16:35:01 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: Message-ID: <200512071534.jB7FYWhq018998@alpha.bartels.de> On Wed, 7 Dec 2005 14:40:47 +0000, Michael.Dillon at btradianz.com wrote: >This is not about cost. Does an STM-1 between Wiesbaden >and London cost less than one between Wiesbaden and >Frankfurt? Between the right end points: Yes. Thanks to DWDM. The cost of leased lines is mostly dominated by - competition / available number of carriers - spare capacity - (central) locations of the end points It is no longer dominated by line length. This holds even true for regulated pricings like DTAG SFV/CVF in Germany, the new price list contains huge discounts for connections between backbone cities, smaller discounts between other cities and backbone cities versus full price for arbitrary connections, even thru there is still a distance component. However the influence of the distance component on pricing becomes very small on long distance leased lines. >Or does it pass through Frankfurt because it >is a neighbouring city? No. Frankfurt contains a lot of telco infrastructure with huge competition. You might even get a leased line between Frankfurt and New York with a pricing comparable to a local line. There is simply enough spare capacity, with DWDM you may put e.g. 400 GBit/s on a _single_ fiber pair. The whole DECIX has a peak throughput around 50 GBit/s. As long as there is a dark fiber, bandwidth is no longer an real issue. >If we did use a geotopological allocation scheme for >another 1/8th of the IPv6 address space, this is an >example of an area where there is a logical clustering >of cities into a larger geographical aggregate. Wiesbaden, >Mainz, Darmstadt and Frankfurt are all over 100,000 population. >It is logical to reserve a single aggregate for them that >covers all 4 city aggregates. That way, providers can choose >to accept all city-level aggregate routes or to only see the >single regional aggregate. Chances are that North American >providers will only use the one regional aggregate while >man Europeans will distinguish all 4 cities. The key point is: The property "traffic belongs to ISP X" is _much_ more important than the property "traffic belongs to region Y". E.g. one might have a peering with ISP X, which means settlement free traffic exchange, compared to transit. Thus there is always the need for the full table if one would like to implement complex routing policies to consider quality and economical facts. As there is just one sorting criteria possible for an linear ordered address space, one must be the dominant, and this is by decision of the huge majority of the participants in the game: "ISP X". A regional ordering as dominant criteria would blow up the table dramatically, because of the need of the "from ISP" information for every region. What you can do: Make a proprosal to sort the minor adressing inside an ISP's allocation to regions. So one could use this additional information. But to be honest: I don't believe you will get acceptance on such a proposal, the infrastructure and distribution of customers to regions is too different between ISP's. >That's not how IP routing works. Anyone can announce any route >that they want, Of course you might filter out all routes and get no connectivity at all. Or you would need a default route which moves the job to the next Tier level, but doesn't solve the problem. >but network providers filter incoming route >announcements based on some sort of logical view of the network >topology. As there is no guranteed transit or peering between different ISP's in a region, however as a peering or transit agreeement between ISP's typically covers the whole _company_, the primary sorting criteria for functional routing decisions and thus the MSB's in the Prefix address is the ISP company id. and not the region id. Again: Sorry, that I have no better news, it is the way it is. 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 btradianz.com Wed Dec 7 17:11:50 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 7 Dec 2005 16:11:50 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512071534.jB7FYWhq018998@alpha.bartels.de> Message-ID: > The cost of leased lines is mostly dominated by > - competition / available number of carriers > - spare capacity > - (central) locations of the end points > > It is no longer dominated by line length. Of course, you are talking about esoteric costs measured in Euros that are only of interests to a few providers. To the vast majority of Internet users it is clear that a path between Wiesbaden and Frankfurt is much cheaper that a path from Wiesbaden to London to Frankfurt. That's because the vast majority of Internet users measure the cost of a path in milliseconds of delay. > >Or does it pass through Frankfurt because it > >is a neighbouring city? > > No. Well actually, your first response could be interpreted to mean that it often does pass through Frankfurt but that someone determined to find the best price can find a path directly to London for a lower price. In any case, if everyone in the Frankfurt-Mainz-Darmstadt-Wiesbaden area decided to start using geotop addressing for their IPv6 routing that does not prevent Wiesbaden from favouring a direct path to London over a path through Frankfurt. And since Wiesbaden is over 100,000 population, it will have its own city reservation which will likely be accepted in route announcements in London even if it is filtered in route announcements in New York. And none of this has anything to do with what routes an ISP carries internally in their network. If a New York ISP sells a direct link to a Wiesbaden ISP, I would expect them to carry a Wiesbaden prefix in their IBGP even though most New York ISPs filter at the regional Fr-Ma-Da-Wi boundary. As for free transit, if this New York ISP accepts traffic for Wiesbaden in their San Francisco PoP then they can easily identify it and pass through a charge to the Wiesbaden ISP. But if the Wiesbaden ISP does not agree to pay such charges then the New York provider can also easily block such traffic at their San Francisco PoP. An address allocation scheme does not mandate operational or business activities. > The key point is: The property "traffic belongs to ISP X" is > _much_ more important than the property "traffic belongs > to region Y". End users, especially in the USA, disagree with you. They think that the traffic belongs to the end user and that the ISP is paid to carry it to its destination, period. > E.g. one might have a peering with ISP X, > which means settlement free traffic exchange, compared > to transit. Thus there is always the need for the full table > if one would like to implement complex routing policies > to consider quality and economical facts. A smart ISP would consider that settlements and similar things would be better handled in OSS servers rather than in routers. And then the routing table size is no longer such an issue. > A regional ordering as dominant criteria would blow up the > table dramatically, because of the need of the "from ISP" > information for every region. Nothing will blow up the table dramatically because routes do not get into the table unless they get past ISP filters. An ISP with PoPs in 30 cities is free to announce all their city level allocations to all their peers, and the peers are free to ignore any prefixes that are longer than the city-level prefixes as issued by the RIR route registry. --Michael Dillon From oliver at bartels.de Wed Dec 7 18:00:43 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 07 Dec 2005 18:00:43 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: Message-ID: <200512071702.jB7H1xhq009684@alpha.bartels.de> On Wed, 7 Dec 2005 16:11:50 +0000, Michael.Dillon at btradianz.com wrote: >Of course, you are talking about esoteric costs measured >in Euros that are only of interests to a few providers. Aha. Then probably you own an interesting device called legal_bank_note_production_engine, because typically providers as real companies tend to charge their cost to their customers in one or the other way. Please let me know where I can obtain such a device, but please be aware I can accept legal offers only. >To the vast majority of Internet users it is clear that >a path between Wiesbaden and Frankfurt is much cheaper >that a path from Wiesbaden to London to Frankfurt. "Trotzdem". For me the discussion dosn't make any further sense at this point. Ask the carrier of your choice about pricing. Btw.: Latency UK/Germany is typically around 30ms. DSL Latency home to BBRAR/LAC ist typically 60ms. People take the DSL ... So much about your theory. >End users, especially in the USA, disagree with you. They >think that the traffic belongs to the end user and that >the ISP is paid to carry it to its destination, period. It is paid in "esoteric costs measured in Euros", not in latency time units. Probably US dollars, swiss franc or yen are acceptable, too. And yes, cost is a primary issue for most customers. 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 leo at ripe.net Wed Dec 7 19:08:03 2005 From: leo at ripe.net (leo vegoda) Date: Wed, 7 Dec 2005 19:08:03 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206105539.GE20142@login.ecs.soton.ac.uk> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> Message-ID: <1E4CABCC-4C4A-4F58-9AEC-DFDF8D5DB9D2@ripe.net> Hi, On 6 Dec 2005, at 11:55, Tim Chown wrote: [...] >> Basically, ~2% of requests did not end in address space being >> registered. We don't know how many requests are not sent in. > > Thanks Leo, very interesting. > > We noted one knockon effect of RIPE policy. I don't know the full > details, but essentially for a tunnel broker service we wanted to > offer > a /48 to end sites out of an existing /32, but were unable to do so > because the 'paperwork' to be sent on to RIPE-NCC for each /48 was > needed > in advance for the ISP owning the /32 to allocate a (say) /40 to the > broker service, and that added a notable hurdle. So we ended up > using > a /48 for the broker and allocating /56 and /64 blocks. Is this the > way it's meant to be, or should the ISP owning the /32 only need to > report usage when asking for more space itself? I think someone else mentioned that a sub-allocation would have worked quite nicely in a case like this. It's worth noting that the current policy does not require an LIR to get approval before making a sub-allocation of any size. Regards, -- leo vegoda Registration Services Manager RIPE NCC From jeroen at unfix.org Wed Dec 7 19:54:13 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 07 Dec 2005 19:54:13 +0100 Subject: [address-policy-wg] Re: /48 or /56 to 'home' end-sites? In-Reply-To: <1E4CABCC-4C4A-4F58-9AEC-DFDF8D5DB9D2@ripe.net> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> <1E4CABCC-4C4A-4F58-9AEC-DFDF8D5DB9D2@ripe.net> Message-ID: <43972FD5.2010202@unfix.org> leo vegoda wrote: [ Cut from the end, to reply on the former thread, replyers might want to snip this part ] > On 6 Dec 2005, at 11:55, Tim Chown wrote: >> Is this the >> way it's meant to be, or should the ISP owning the /32 only need to >> report usage when asking for more space itself? > > I think someone else mentioned that a sub-allocation would have worked > quite nicely in a case like this. It's worth noting that the current > policy does not require an LIR to get approval before making a > sub-allocation of any size. It's also the way SixXS gets assigned a prefix, usually a /40, for a PoP from an ISP to be used for that ISP's PoP and manages this for that ISP, allocating toward endusers. One could see this as if one is 'outsourcing tunneled IPv6 end-user connectivity'. [ New Thread ] > On 6 Dec 2005, at 11:55, Tim Chown wrote: >> We noted one knockon effect of RIPE policy. I don't know the full >> details, but essentially for a tunnel broker service we wanted to offer >> a /48 to end sites out of an existing /32, but were unable to do so >> because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed >> in advance for the ISP owning the /32 to allocate a (say) /40 to the >> broker service, and that added a notable hurdle. So we ended up using >> a /48 for the broker and allocating /56 and /64 blocks. /56's are most likely enough for most 'home end-site'. A single /56 provides 2^(64-56 = 8) = 256 /64's. Let's introduce some terms: end-site: a location where IP connectivity is delivered and managed by a single "IT/IS staff"/person. ISP: organization that provides connectivity to end-site. Then we get two types of endsites: 'home end-site': a location (residence) where living (fun,sleeping,eating) is the prime objective. 'work end-site': a location where work is the prime objective and no sleeping is done. Of course there are a couple of nice things like hotels or resthouses, but those are delivering work to let the people live there, people there are being serviced to get living conditions (internet is a a requirement for that don't you think? :) etc. Another one could be home-workers. Maybe the city planning could determine it better, in many buildings you are not allowed to spend the night as they where not planned to be used for that. Currently both kinds of end-sites get /48's. For the work end-site the /48 should suffice all those sites as defined by the current policy. For home end-sites I believe that a /48 really is way too much. I have to see, let alone dream up, a home where even 25 separate networks would be used. Personally(*) I even ditched the routed network thing completely even though I effectively could setup at least 4 links, separately routed, thus 4x /64. Bridging seemed much easier in my case. I personally don't home users ever go over the 256 /64's, thus a /56 should be sufficient. Of course future might change but still. Routing implies that people would configure it or that it would be autonomicly configured which is not available yet either. Prefix Delegation might work, but on 256 levels? There where before a couple of other people noting the change of HD ratio, though I haven't seen much about that discussion recently, Tim's note above reminded me of it. In SixXS we typically use a /40 for a PoP, after 255 subnets (the first /48 is for tunnels) this assignment is full. In Tim's case with the same amount of users he will only use a single /48, which is 1/256th of what we just "burned". As noted above I personally believe that a /48 for 'work' sites is good. They can then always easily move between sites, and this will for certain be enough for 99.99% (or so) of the endsites that fall in this category. For a home-site situation a full /48 is IMHO really overkill, as noted above. One of the reasons for saying 'all endsites a /48' was that all ISP's would give everybody a /48, renumbering would then not involve replanning onces network because one didn't get enough IP space. Creating a difference for home and work sites could only cause a problem when a work site becomes a home site, but I don't see that happening. Home to work, in case that happens, would get more address space at that point, thus that is not an issue either (except for the renumbering but let's not think about that, that is a different ballpark ;) Is it maybe time to look at this /48 policy and change it in the direction of the above that home endsites get a /56 instead of a full blown /48 which they will never use. Or do people think that it is fine and that we should not bother here at all? Greets, Jeroen * = http://unfix.org/~jeroen/network/ in case one is wondering. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From rogerj at jorgensen.no Wed Dec 7 20:02:41 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Wed, 7 Dec 2005 20:02:41 +0100 (CET) Subject: [address-policy-wg] Re: /48 or /56 to 'home' end-sites? In-Reply-To: <43972FD5.2010202@unfix.org> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIP ENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> <1E4CABCC-4C4A-4F58 -9AEC-DFDF8D5DB9D2@ripe.net> <43972FD5.2010202@unfix.org> Message-ID: quite sure there was a discussion about this some months back and most people could agree on that a /56, maybe even /52 was a better size than /48. But maybe it was on ipv6-wg at ripe.net ? On Wed, 7 Dec 2005, Jeroen Massar wrote: > leo vegoda wrote: > > [ Cut from the end, to reply on the former thread, > replyers might want to snip this part ] > > > On 6 Dec 2005, at 11:55, Tim Chown wrote: > >> Is this the > >> way it's meant to be, or should the ISP owning the /32 only need to > >> report usage when asking for more space itself? > > > > I think someone else mentioned that a sub-allocation would have worked > > quite nicely in a case like this. It's worth noting that the current > > policy does not require an LIR to get approval before making a > > sub-allocation of any size. > > It's also the way SixXS gets assigned a prefix, usually a /40, for a PoP > from an ISP to be used for that ISP's PoP and manages this for that ISP, > allocating toward endusers. One could see this as if one is 'outsourcing > tunneled IPv6 end-user connectivity'. > > > [ New Thread ] > > > On 6 Dec 2005, at 11:55, Tim Chown wrote: > > >> We noted one knockon effect of RIPE policy. I don't know the full > >> details, but essentially for a tunnel broker service we wanted to offer > >> a /48 to end sites out of an existing /32, but were unable to do so > >> because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed > >> in advance for the ISP owning the /32 to allocate a (say) /40 to the > >> broker service, and that added a notable hurdle. So we ended up using > >> a /48 for the broker and allocating /56 and /64 blocks. > > /56's are most likely enough for most 'home end-site'. A single /56 > provides 2^(64-56 = 8) = 256 /64's. > > Let's introduce some terms: > > end-site: a location where IP connectivity is delivered and managed by a > single "IT/IS staff"/person. > ISP: organization that provides connectivity to end-site. > > Then we get two types of endsites: > > 'home end-site': a location (residence) where living > (fun,sleeping,eating) is the prime objective. > > 'work end-site': a location where work is the prime objective and no > sleeping is done. > > Of course there are a couple of nice things like hotels or resthouses, > but those are delivering work to let the people live there, people there > are being serviced to get living conditions (internet is a a requirement > for that don't you think? :) etc. Another one could be home-workers. > Maybe the city planning could determine it better, in many buildings you > are not allowed to spend the night as they where not planned to be used > for that. > > > Currently both kinds of end-sites get /48's. For the work end-site the > /48 should suffice all those sites as defined by the current policy. > > For home end-sites I believe that a /48 really is way too much. > I have to see, let alone dream up, a home where even 25 separate > networks would be used. Personally(*) I even ditched the routed network > thing completely even though I effectively could setup at least 4 links, > separately routed, thus 4x /64. Bridging seemed much easier in my case. > I personally don't home users ever go over the 256 /64's, thus a /56 > should be sufficient. Of course future might change but still. Routing > implies that people would configure it or that it would be autonomicly > configured which is not available yet either. Prefix Delegation might > work, but on 256 levels? > > There where before a couple of other people noting the change of HD > ratio, though I haven't seen much about that discussion recently, Tim's > note above reminded me of it. In SixXS we typically use a /40 for a PoP, > after 255 subnets (the first /48 is for tunnels) this assignment is > full. In Tim's case with the same amount of users he will only use a > single /48, which is 1/256th of what we just "burned". As noted above I > personally believe that a /48 for 'work' sites is good. They can then > always easily move between sites, and this will for certain be enough > for 99.99% (or so) of the endsites that fall in this category. For a > home-site situation a full /48 is IMHO really overkill, as noted above. > > One of the reasons for saying 'all endsites a /48' was that all ISP's > would give everybody a /48, renumbering would then not involve > replanning onces network because one didn't get enough IP space. > Creating a difference for home and work sites could only cause a problem > when a work site becomes a home site, but I don't see that happening. > Home to work, in case that happens, would get more address space at that > point, thus that is not an issue either (except for the renumbering but > let's not think about that, that is a different ballpark ;) > > > Is it maybe time to look at this /48 policy and change it in the > direction of the above that home endsites get a /56 instead of a full > blown /48 which they will never use. Or do people think that it is fine > and that we should not bother here at all? > > Greets, > Jeroen > > * = http://unfix.org/~jeroen/network/ in case one is wondering. > > -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From iljitsch at muada.com Wed Dec 7 21:47:24 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 Dec 2005 21:47:24 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <1133957521.12940.249228673@webmail.messagingengine.com> References: <1133957521.12940.249228673@webmail.messagingengine.com> Message-ID: <11FBF334-2B68-414A-9349-29EFEBF66C0B@muada.com> On 7-dec-2005, at 13:12, Per Heldal wrote: >> Geographical aggregation does not REQUIRE free transit. > [Does Fedex deliver goods to everybody in a region if only one > customer > in the region pays for their service?] That's not the right analogy. The right analogy is: does a Fedex truck driver in New York have a street map for Berlin? Answer: no. The NY Fedex driver knows that packages for Berlin should go to Europe. More specific routing information becomes available as the package gets closer to its destination. So Fedex does aggregate on geography, but only _internally_. Fedex as a whole still has all the detailed information for the entire world. (Well, the parts they serve at least.) Iljitsch -- I've written another book! http://www.runningipv6.net/ From iljitsch at muada.com Wed Dec 7 21:55:39 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 Dec 2005 21:55:39 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512071211.jB7CBfhq013442@alpha.bartels.de> References: <200512071211.jB7CBfhq013442@alpha.bartels.de> Message-ID: <7EA5C612-8334-4311-A610-468E60DD5571@muada.com> On 7-dec-2005, at 13:12, Oliver Bartels wrote: > ( In English: Kehl and Strassbourg want to work jointly > together to form a single Eurodistrict / city with e.g. a single > phone > network. ) The point isn't that geographical addressing fits perfectly with the way network topologies are laid down. The point is that there is a decent saving, of say, a factor 10 or better. In practical terms: if Kehl and Strassbourg (Stra?burg?) are on different sides of a national border but they're part of the same topological entity in the network, you simply have the Kehl routes in Strassbourg and the Strassbourg routes in Kehl. So rather than have one set of routes you have two. Obviously that means twice as many routes as you'd have when the geographical addressing was aligned with topology, but it's still a factor 32768 better than what you'd have with flat PI so who cares. And, for 90% of the routers throughout the world, both aggregate to "western europe" anyway. -- I've written another book! http://www.runningipv6.net/ From iljitsch at muada.com Wed Dec 7 22:04:28 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 Dec 2005 22:04:28 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: <4395A760.6070608@baycix.de> Message-ID: On 7-dec-2005, at 12:13, McTim wrote: >> In regard to IP addressing policy, it is sufficient for the >> RIRs to start doing things more wisely. If the RIRs would open >> up another 1/8th of the IPv6 address space for geotop allocations >> then they would no longer be blocking this solution. > IIUC, the RIRs don't have another 1/8 of the space to "open up". they > don't even have the whole of the first 1/8. IANA holds the global > pool. The NRO *could* be helpful in lobbying for this, if their > communities asked it of them. When Michel Py and I worked on this, our design goal was to support 1 billion multihomers, or 1 multihomed geographically aggregatable PI (GAPI) prefix per 10 inhabitants of the world in the year 2050. We decided to assume upto 65536 regions with upto 65536 multihomers in them. That's over 4 billion and takes just a /16, with a factor 4 margin for error and assignment inefficiencies. It would be possible to increase to a slightly shorter prefix but that's not really needed in the forseeable future: we're currently at one in 25000 multihomers or lower in the US and Europe, so there is room for a factor 2500 growth before the /16 is depleted. Also, there is no reasonable way to do geographical aggregation within a metropolitan area, and at more than 1 in 10 we're quickly going to run into routing table problems within the world's largest cities (2.5 million multihomers in Mexico City...). -- I've written another book! http://www.runningipv6.net/ From iljitsch at muada.com Wed Dec 7 22:09:05 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 Dec 2005 22:09:05 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: Message-ID: <4E4B3452-C676-4437-878B-5B00E6C1D7DF@muada.com> On 7-dec-2005, at 15:58, Michael.Dillon at btradianz.com wrote: >> To a first approximation, there is *no* level of aggregation in >> the UK >> that works below UK-wide. > If that were really true, and I suspect that it is only true > for the very largest providers, then there is an easy solution. > Providers who see no benefit in using geotop addressing should > continue to use classical IPv6 addressing. Rather than debate wheter someone in Aberdeen is really going to multihome to ISPs in Norwich and Belfast, let me observe that aggregating at the European national level is just fine. The largest countries in Europe each have about 1% of the world's population. So if they also have 1% of the routing table we can have 100 times as many routes as we could without geographical aggregation. That should give us plenty of breathing room. It's harder for the US because there are no easy demarcations there. -- I've written another book! http://www.runningipv6.net/ From bmanning at vacation.karoshi.com Wed Dec 7 23:01:48 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 7 Dec 2005 22:01:48 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <11FBF334-2B68-414A-9349-29EFEBF66C0B@muada.com> References: <1133957521.12940.249228673@webmail.messagingengine.com> <11FBF334-2B68-414A-9349-29EFEBF66C0B@muada.com> Message-ID: <20051207220148.GA11705@vacation.karoshi.com.> On Wed, Dec 07, 2005 at 09:47:24PM +0100, Iljitsch van Beijnum wrote: > On 7-dec-2005, at 13:12, Per Heldal wrote: > > >>Geographical aggregation does not REQUIRE free transit. > > >[Does Fedex deliver goods to everybody in a region if only one > >customer > >in the region pays for their service?] > > That's not the right analogy. The right analogy is: does a Fedex > truck driver in New York have a street map for Berlin? Answer: no. > The NY Fedex driver knows that packages for Berlin should go to > Europe. More specific routing information becomes available as the > package gets closer to its destination. > > So Fedex does aggregate on geography, but only _internally_. Fedex as > a whole still has all the detailed information for the entire world. > (Well, the parts they serve at least.) Interior Gateway Protocols... kind of like OSPFv3 for v6? --bill > > Iljitsch > > -- > I've written another book! http://www.runningipv6.net/ > From jwkckid1 at ix.netcom.com Thu Dec 8 12:01:26 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Dec 2005 03:01:26 -0800 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 References: Message-ID: <43981283.429580C3@ix.netcom.com> Michael and all, Good point here Michael... Michael.Dillon at btradianz.com wrote: > > The internet only works as long as 99% of all people carry 99% of all > > routes. When a sizeable number of people starts filtering a sizeable > > number of routes for whatever reason, either technical (won't fit in > > their routers) or political (don't agree with the policies) then > > we're in knee-deep brown stuff. > > And this is something that RIPE and ARIN cannot directly > change. RIR policy can only encourage or discourage ISPs from > carrying 99% of all routes. I think that the current policy for > IPv6 is one which discourages people from using IPv6. Adding > a second type of IPv6 address that is allocated geographically > to allow greater topological aggregation (i.e. based on which > city the network is in) will encourage use of IPv6 by making it > easier for people to get IPv6 addresses. > > --Michael Dillon Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obediance of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From tjc at ecs.soton.ac.uk Wed Dec 14 13:22:49 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 14 Dec 2005 12:22:49 +0000 Subject: [address-policy-wg] Re: /48 or /56 to 'home' end-sites? In-Reply-To: References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> <1E4CABCC-4C4A-4F58-9AEC-DFDF8D5DB9D2@ripe.net> <43972FD5.2010202@unfix.org> Message-ID: <20051214122249.GH10508@login.ecs.soton.ac.uk> On Wed, Dec 07, 2005 at 08:02:41PM +0100, Roger Jorgensen wrote: > quite sure there was a discussion about this some months back and most > people could agree on that a /56, maybe even /52 was a better size than > /48. But maybe it was on ipv6-wg at ripe.net ? I guess you mean this: http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt Tim From tjc at ecs.soton.ac.uk Wed Dec 14 13:26:03 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 14 Dec 2005 12:26:03 +0000 Subject: [address-policy-wg] Re: /48 or /56 to 'home' end-sites? In-Reply-To: <43972FD5.2010202@unfix.org> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> <1E4CABCC-4C4A-4F58-9AEC-DFDF8D5DB9D2@ripe.net> <43972FD5.2010202@unfix.org> Message-ID: <20051214122603.GI10508@login.ecs.soton.ac.uk> On Wed, Dec 07, 2005 at 07:54:13PM +0100, Jeroen Massar wrote: > > /56's are most likely enough for most 'home end-site'. A single /56 > provides 2^(64-56 = 8) = 256 /64's. > > ... > > For home end-sites I believe that a /48 really is way too much. > > ... > > One of the reasons for saying 'all endsites a /48' was that all ISP's > would give everybody a /48, renumbering would then not involve > replanning onces network because one didn't get enough IP space. > Creating a difference for home and work sites could only cause a problem > when a work site becomes a home site, but I don't see that happening. > Home to work, in case that happens, would get more address space at that > point, thus that is not an issue either (except for the renumbering but > let's not think about that, that is a different ballpark ;) > > Is it maybe time to look at this /48 policy and change it in the > direction of the above that home endsites get a /56 instead of a full > blown /48 which they will never use. Or do people think that it is fine > and that we should not bother here at all? So I guess people should comment on Thomas' IETF I-D... I was just surprised that policy seemed to adversely affect the 'ease of deployment' of a broker service. I personally would be fine with a /56 for home use. I do think it's important that ISPs have a common reference for sizes to allocate, though inevitably there will be different offerings (ISPs will look for ways to charge more, as they do by 'selling' IPv4 addresses today). -- Tim/::1 From jorgen at hovland.cx Wed Dec 14 15:21:36 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 14 Dec 2005 15:21:36 +0100 Subject: [address-policy-wg] Re: /48 or /56 to 'home' end-sites? References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> <1E4CABCC-4C4A-4F58-9AEC-DFDF8D5DB9D2@ripe.net> <43972FD5.2010202@unfix.org> <20051214122603.GI10508@login.ecs.soton.ac.uk> Message-ID: <008f01c600b9$b0f67750$6503a8c0@tungemaskin> ----- Original Message ----- From: "Tim Chown" Sent: Wednesday, December 14, 2005 1:26 PM >> >> Is it maybe time to look at this /48 policy and change it in the >> direction of the above that home endsites get a /56 instead of a full >> blown /48 which they will never use. Or do people think that it is fine >> and that we should not bother here at all? > > So I guess people should comment on Thomas' IETF I-D... > I'd like, I see it is that time of the year again when we try to (re)define magic constants because the standard deviation is out of the dynamic "most people" scope. Can't we just respect the physical upper and lower limit instead of trying to decide what the mean value should be? I know it is only a recomendation, but we are still trying to alter it. There are no good reasons for having predefined inner boundaries unless you argue that your software/hardware would better support a,b,c,d and not a-z because the author didn't assume you would use anything else. The reason for that again might just be because they followed previous recomendations in the past for what these numbers usually should be. I would rather see recomendations more like "make sure you assign a subnet which is large enough to handle at least NN times the userbase in two years" than "use prefixlength 48". J?rgen Hovland From maryline.bourasseau at francetelecom.com Thu Dec 15 12:13:26 2005 From: maryline.bourasseau at francetelecom.com (BOURASSEAU Maryline ROSI/DAS) Date: Thu, 15 Dec 2005 12:13:26 +0100 Subject: [address-policy-wg] HD ratio - 2005-01 Message-ID: I confirm that France Telecom supports the IPV4 HD-Ratio proposal (Policy proposal 2005-01) Regards. Maryline Bourasseau LIR - fr.telecom ******************************** Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. Le Groupe France Telecom decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur. ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at ripe.net Tue Dec 20 11:52:44 2005 From: leo at ripe.net (leo vegoda) Date: Tue, 20 Dec 2005 11:52:44 +0100 Subject: [address-policy-wg] Draft minutes: RIPE 51 Address Policy WG session Message-ID: <00ae01c60553$81e96960$1d0200c1@FluffyBunny> Dear Colleagues, Draft minutes from the Address Policy Working Group session at RIPE 51 can be found at: http://www.ripe.net/ripe/wg/address-policy/r51-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, archives of the webcast can be found at: mms://webcast.ripe.net/ripe-51/ap.wmv http://www.ripe.net/ripe/meetings/ripe-51/webcast-files/ap.wmv There is also a copy of the Jabber/IRC session available at: http://www.ripe.net/ripe/meetings/ripe-51/feedback/ap.txt Kind regards, -- leo vegoda RIPE NCC Registration Services Manager From contact at ripe.net Tue Dec 20 17:06:15 2005 From: contact at ripe.net (Paul Rendek) Date: Tue, 20 Dec 2005 17:06:15 +0100 Subject: [address-policy-wg] Updated Information: RIPE NCC Regional Meeting Qatar, 17-18 January 2006 Message-ID: <43A82BF7.3030500@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, There is still time to register for the RIPE NCC Regional Meeting taking place in Doha, Qatar, on 17-18 January 2006. This Regional Meeting is specifically designed to provide participants with a forum to discuss topics related to IP networking in the Middle East region. The draft meeting agenda is available at: http://www.ripe.net/meetings/regional/qatar-2006/agenda.html RIPE NCC IP RESOURCE ANALYSTS During the meeting, RIPE NCC IP Resource Analysts will be available for members to discuss issues relating to their business face-to-face with RIPE NCC staff. For more information, or to schedule an appointment with one of the RIPE NCC IP Resource Analysts, please see: http://www.ripe.net/meetings/regional/qatar-2006/ip-resource-analysts.html SEMINARS All meeting attendees are also invited to attend the two RIPE NCC seminars, the DNSSEC Seminar and the Routing Registry Seminar. Both seminars will take place on Tuesday 18 January, from 14:00. - The DNSSEC Seminar outlines the features of DNSSEC and related tools and to introduce the relevant RIPE NCC services. - The Routing Registry (RR) Seminar aims to teach the features of Routing Registry and related tools, introduce the relevant RIPE NCC services and explain the basics of Routing Policy Specification Language (RPSL). REGISTRATION If you have not yet registered for the RIPE NCC Regional Meeting in Doha, Qatar, please register at: www.ripe.net/qatar2006/register Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. Registration will close on Friday, 13 January 2006. MORE INFORMATION More information about the RIPE NCC Regional Meeting in Qatar is available at: http://www.ripe.net/qatar2006 Any questions can be sent to: Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From filiz at ripe.net Wed Dec 21 13:30:11 2005 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 21 Dec 2005 13:30:11 +0100 Subject: [address-policy-wg] New IPv6 Address Block Allocated to the RIPE NCC Message-ID: <20051221123011.GE6801@ripe.net> [Apologies for Duplicates] Dear Colleagues The RIPE NCC received the IPv6 address range 2A01:0000::/16 from the IANA in December 2005. 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This latest range includes that previous allocation. You may wish to adjust any filters you have in place accordingly. You can find more information about the IP space administered by the RIPE NCC on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Regards, Filiz Yilmaz RIPE NCC From jeroen at unfix.org Wed Dec 21 13:42:26 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Dec 2005 13:42:26 +0100 Subject: [address-policy-wg] Re: New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <20051221123011.GE6801@ripe.net> References: <20051221123011.GE6801@ripe.net> Message-ID: <43A94DB2.6050304@unfix.org> Filiz Yilmaz wrote: > The RIPE NCC received the IPv6 address range 2A01:0000::/16 from > the IANA in December 2005. !Finally! IANA is passing /16's directly to the RIR's! That is a good thing to see happening. Congrats (Or did somebody request a /17 ? :) > 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This > latest range includes that previous allocation. > > You may wish to adjust any filters you have in place accordingly. See http://www.space.net/~gert/RIPE/ipv6-filters.html I expect Gert to update those later today, give him a few moments ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From gert at space.net Wed Dec 21 13:52:55 2005 From: gert at space.net (Gert Doering) Date: Wed, 21 Dec 2005 13:52:55 +0100 Subject: [address-policy-wg] Re: [routing-wg]Re: New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <43A94DB2.6050304@unfix.org> References: <20051221123011.GE6801@ripe.net> <43A94DB2.6050304@unfix.org> Message-ID: <20051221125255.GL69925@Space.Net> Hi, On Wed, Dec 21, 2005 at 01:42:26PM +0100, Jeroen Massar wrote: > > 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This > > latest range includes that previous allocation. > > > > You may wish to adjust any filters you have in place accordingly. > > See http://www.space.net/~gert/RIPE/ipv6-filters.html > I expect Gert to update those later today, give him a few moments ;) *done*, thanks for reminding me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 pim at ipng.nl Wed Dec 21 14:54:37 2005 From: pim at ipng.nl (Pim van Pelt) Date: Wed, 21 Dec 2005 14:54:37 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <20051221123011.GE6801@ripe.net> References: <20051221123011.GE6801@ripe.net> Message-ID: <20051221135437.GM2702@bfib.ipng.nl> Hi Filiz, | The RIPE NCC received the IPv6 address range 2A01:0000::/16 from | the IANA in December 2005. Yaay, finally decently sized chunks to RIRs. Well done. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From dr at cluenet.de Thu Dec 22 00:01:10 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 22 Dec 2005 00:01:10 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <20051221135437.GM2702@bfib.ipng.nl> References: <20051221123011.GE6801@ripe.net> <20051221135437.GM2702@bfib.ipng.nl> Message-ID: <20051221230110.GA18975@srv01.cluenet.de> On Wed, Dec 21, 2005 at 02:54:37PM +0100, Pim van Pelt wrote: > | The RIPE NCC received the IPv6 address range 2A01:0000::/16 from > | the IANA in December 2005. > Yaay, finally decently sized chunks to RIRs. Well done. You're jumping to conclusions. As Jeroen mentioned, it could be just someone getting an /17 (with a /17 above reserved for expansion). Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From webmaster at ripe.net Thu Dec 22 14:30:32 2005 From: webmaster at ripe.net (RIPE NCC Policy Coordinator) Date: Thu, 22 Dec 2005 14:30:32 +0100 Subject: [address-policy-wg] 2005-12 New Policy Proposal (4-Byte AS Number Policy Proposal) Message-ID: <18858.1135258232@cat.ripe.net> PDP Number: 2005-12 4-Byte AS Number Policy Proposal Dear Colleagues A new RIPE policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-12.html We encourage you to review this proposal and send your comments to before 22 January 2006. After this date, we will prepare a draft RIPE Document. We will let you know when this is available. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager From rogerj at jorgensen.no Fri Dec 23 12:03:06 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 23 Dec 2005 12:03:06 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for g loba l uniqe IP space In-Reply-To: <20051125103844.GO69925@Space.Net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net > <20051125103844.GO69925@Space.Net> Message-ID: On Fri, 25 Nov 2005, Gert Doering wrote: > The idea is that ULAs are random-generated in a way that makes it "fairly > unlikely" that you end up in an address collision. But there is no > guarantee, of course. > > There is also a second sort of ULAs that are globally unique but still > private, but as far as I know, there is no registry yet that will hand > them out. So these can't be used yet. Who would know more about this? I'm in the process of writing down some startup thoughts about how we can (and maybe should) implement IPv6 here where I work. It's a closed national network where security is prio 1 and we might also have to work/connect to other network of the same type in other countries... in short, we need to be globaly unique so we actually need that registrary to be there:) -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From gert at space.net Fri Dec 23 14:57:13 2005 From: gert at space.net (Gert Doering) Date: Fri, 23 Dec 2005 14:57:13 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for g loba l uniqe IP space In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net> <20051125103844.GO69925@Space.Net> Message-ID: <20051223135713.GW69925@Space.Net> Hi, On Fri, Dec 23, 2005 at 12:03:06PM +0100, Roger Jorgensen wrote: > [ globally unique ULAs ] > Who would know more about this? Geoff Houston mentioned that APNIC is researching this topic. As for implementing it, the NRO/RIR structure sounds like a logical candidate for me. They just need to make sure that it's adequately lightweight so people won't need to pay thousands of Euro/Dollars to get a ULA prefix. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 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 gih at apnic.net Fri Dec 23 22:01:32 2005 From: gih at apnic.net (Geoff Huston) Date: Sat, 24 Dec 2005 08:01:32 +1100 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for global uniqe IP space In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net > <20051125103844.GO69925@Space.Net> Message-ID: <6.2.0.14.2.20051224074752.02b41018@kahuna.telstra.net> At 10:03 PM 23/12/2005, Roger Jorgensen wrote: >On Fri, 25 Nov 2005, Gert Doering wrote: > > > The idea is that ULAs are random-generated in a way that makes it "fairly > > unlikely" that you end up in an address collision. But there is no > > guarantee, of course. indeed. The chances of collision exceed 0.5 once the pool of random;y drawn numbers exceeds 1.24 million. > > > > There is also a second sort of ULAs that are globally unique but still > > private, but as far as I know, there is no registry yet that will hand > > them out. So these can't be used yet. > >Who would know more about this? I'm in the process of writing down some >startup thoughts about how we can (and maybe should) implement IPv6 here >where I work. It's a closed national network where security is prio 1 and >we might also have to work/connect to other network of the same type in >other countries... in short, we need to be globaly unique so we actually >need that registrary to be there:) the original ULA document combined both self-selected ULAs and registry-selected ULAs. Over the period of a year of IETF consideration they were split in two, and the random self-selction method became RFC 4193 and the so-called centrally assigned IDs draft expired . Some URLS: - the history of the drafts: http://smakd.potaroo.net/ietf/idref/draft-ietf-ipv6-unique-local-addr/index.html - the centrally assigned drafts: http://smakd.potaroo.net/ietf/idref/draft-ietf-ipv6-ula-central/index.html There was a long discussion on the IPv6 list about the issues with the operation of a registry. I've forgotten when, but around May - July 2003 sounds familiar for some reason. The concept of a central register of unique 40bit sequences is not completely dead. At RIPE 51 I described some current work at APNIC that includes a certificate identity scheme that uses this same concept (http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-address-certificate.pdf (see page 14 of the presentation). I also did some maths of the collision probability of random 40bit long numbers (the so-called "birthday problem" in an expired draft (http://smakd.potaroo.net/ietf/idref/draft-huston-ipv6-local-use-comments/index.html). It _may_ be the case that a form of centrally assigned unique 40 bit strings for use in the context of the original model of centrally-assigned unique local addresses may be a useful by-product of the certification work - but if it proceeds that this is likely to be some time away yet from becoming part of the service portfolio associated with certification. regards, Geoff From bmanning at vacation.karoshi.com Sat Dec 24 03:08:31 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 24 Dec 2005 02:08:31 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for global uniqe IP space In-Reply-To: <6.2.0.14.2.20051224074752.02b41018@kahuna.telstra.net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net> <20051125103844.GO69925@Space.Net> <6.2.0.14.2.20051224074752.02b41018@kahuna.telstra.net> Message-ID: <20051224020831.GA32377@vacation.karoshi.com.> On Sat, Dec 24, 2005 at 08:01:32AM +1100, Geoff Huston wrote: > At 10:03 PM 23/12/2005, Roger Jorgensen wrote: > >On Fri, 25 Nov 2005, Gert Doering wrote: > > > >> The idea is that ULAs are random-generated in a way that makes it "fairly > >> unlikely" that you end up in an address collision. But there is no > >> guarantee, of course. > > indeed. The chances of collision exceed 0.5 once the pool of random;y drawn > numbers exceeds 1.24 million. presuming random generation... wearing a black hat tells me that random selection is not what i want or need to attack some other machine, not when i can hijack its number and then claim plausable deniability .. > Geoff > --bill From gih at apnic.net Mon Dec 26 21:28:55 2005 From: gih at apnic.net (Geoff Huston) Date: Tue, 27 Dec 2005 07:28:55 +1100 Subject: [address-policy-wg] 2005-12 New Policy Proposal (4-Byte AS Number Policy Proposal) In-Reply-To: <18858.1135258232@cat.ripe.net> References: <18858.1135258232@cat.ripe.net> Message-ID: <6.2.0.14.2.20051227071718.02b6e640@kahuna.telstra.net> At 04:27 PM 23/12/2005, RIPE NCC Policy Coordinator wrote: >PDP Number: 2005-12 >4-Byte AS Number Policy Proposal > >Dear Colleagues > >A new RIPE policy has been proposed and is now available for >discussion. > >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2005-12.html > >We encourage you to review this proposal and send your comments to > before 22 January 2006. > >After this date, we will prepare a draft RIPE Document. We will let >you know when this is available. This policy was submitted to all five RIRs in early December. In the intervening period the discussion on the ARIN policy discussion mailing list has undoubtedly been the most active of all the regions. For those who do not follow the ARIN list, the points arising from that discussion as they relate to changes in the text of the policy so far appear to be: a) that the section on terminology should use a period as a separator between the high and low 16 bit fields rather than a colon as originally proposed, in order to reduce confusion with delimiters in BGP communities b) that the proposal replace the term "2 byte" with "16 bit" and "4 byte" with "32 bit" due to the somewhat imprecise nature of the definition of a "byte" Other topics of discussion on the ARIN list have been - whether the terminology and nomenclature sessions should be included in the policy proposal - whether the specification of dates are reasonable in this context - whether the policy alters the current sequential number allocation registry practice - the criteria (if any) that should be applied to a request for an AS number of the "other" type - the desireable size of the private use AS number pool No further changes to the policy are proposed at this point in time as a clear outcome of these discussions. Its also worth noting that this is intended to be a temporary policy associated with transition to the larger number pool, and at the end of the period, proposed to be 1 January 2010, this policy is no longer in force, and the larger 32-bit AS number space will be managed as a single pool using the current policies and procedures. regards, Geoff From dr at cluenet.de Wed Dec 28 06:56:39 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 28 Dec 2005 06:56:39 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] Re: Re: Re: Andre's guide to fix IPv6 In-Reply-To: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> References: <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> Message-ID: <20051228055639.GA25461@srv01.cluenet.de> On Thu, Dec 01, 2005 at 09:11:48AM +0100, Kurt Erik Lindqvist wrote: > >ISPs do exist for customers, not customers do exist to feed ISPs > >in the > >most convenient way for the ISPs. Some folks seem to forget that, > >looking at all the discussion trying to ignore the demand for real > >multihoming (and that includes TE and network-wide routing policy > >implementation, neither being delivered by things like shim6). > > I think you are contradicting yourself here. Shim6 does give the end- > user TE capability. It doesn't. Unless I'm missing on how I can influence e.g. inbound routing like I can do with BGP announcements, tagged with special communities to tweak announcement properties (yes/no, prepending etc.) and things like routing preference ("local-pref" in BGP semantics) in my upstream's network or even more far reaching than that. I cannot. And as far as I hear, folks at NANOG (IESG BoF on IPv6 multihoming) have clearly laid out why shim6 is NOT what we're looking for - and why. [this is hearsay, I didn't get around to check minutes and/or slides yet] > I am not sure what you mean with "network-wide routing policy > implementation".... As a network administrator I want to define routing properties for my whole network in a consistent way, not to tweak each policy decision in each IPv6 stack on each host. The routing policy of a network is a network property, not a host property. I don't want to HAVE to control (read: administer!) each and every end device on the network just to provide proper global routing to it. That's just ridiculous. > I have still to figure out what the "real multihoming" thing is, That's the basic problem. The IETF folks either don't understand, or chose to ignore the requirements. There is a nice 6NET document detailing all requirements and showing a matrix outlining requirements against proposed solutions. Outcome: NONE except BGP offer a solution to ALL requirements. I'm happy to look into any solution proposed that fulfils the needs. Unfortunately that's not there yet. I'm sure we all would be happy to get rid of the latent possible danger of BGP. > >HOW the requirements are being delivered is another topic. multi6 has > >resulted in the decision to ignore many critical requirements. We're > >just asking for something that delivers on the targets. Wasting time > >with half-solutions is not productive. Halting any development because > >the magic bullet wasn't found yet ain't either. > > If you have alternative ideas you know how it works - send text. I don't, as stated. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Wed Dec 28 07:21:59 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 28 Dec 2005 07:21:59 +0100 Subject: [address-policy-wg] Re: Re: Re: Re: a consensus, about what? In-Reply-To: <4396F6F2.9070001@unfix.org> References: <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> <20051207105402.GA28312@srv01.cluenet.de> <4396F6F2.9070001@unfix.org> Message-ID: <20051228062159.GB25461@srv01.cluenet.de> On Wed, Dec 07, 2005 at 03:51:30PM +0100, Jeroen Massar wrote: > Daniel Roesen wrote: > > On Wed, Dec 07, 2005 at 08:31:43AM +0100, Jeroen Massar wrote: > >>> You have an AS and do multihome? Pay a small one-time fee (reg effort) > >>> and small annual fee (to verify that you still do exist care for the > >>> prefix to stay registered, and to cover costs for the database entries > >>> for your prefix) and be done with it.[1] > >> Note that the billing should then still be 'more' expensive than a LIR's > >> individual allocation otherwise most LIR's will convert into > >> independents which gives one more power over prefixes than the above. > > > > Nonsense. PI doesn't let the LIR assign IP space to their customers. End > > site PI ain't an option for real LIRs. > > This is not what I meant. But why would endsite PI not be an option for > 'real LIR's? What is a 'real LIR' actually according to you and what > isn't? A "real LIR" is a Local Internet Registry. A Local Internet Registery assigns resources they got allocated by a RIR to hand out to end users. As PI space isn't subassignable, PI is not an option for LIRs. > They all are in it for the money in the end. If their business is > renting out "address space" (like the RIR's do effectively) then so be > it, that is their business. But we're talking about independent IP space for "end users", not for LIRs. > There are maybe some LIR's now though who don't want to be a LIR, but > only did so to get address space. These might want to drop to the xxxxxs > membership category to reduce cost at a certain point. Yep. XXXXXS membership (not "LIR" - there's no registry operation involved) with a small basic fee for the essential one-off tasks of assigning and maintaining the records for an ASN, an IPv4 PI and an IPv6 PI block (read: a basic multihomer setup). > >> A LIR should know the procedures which should make requests very easy to > >> process, at least that is the idea, which lowers load on the RIR's. > > > > Should. Please come back with some hard data from NCC to explain to us > > that PI holders place a higher workload on NCC staff than any real LIR. > > Good luck. > > There might not be one, but you can expect it to be this way. Sorry, cannot believe that. I was hoping that NCC folks would chime in and add some statistics to this point.... any takers? > Maybe add a 'failed request' 'extra work' 'number of requests' etc to > the scoring scheme to take care of this? Difficult. Who decides what incidents are actually extra-billed? > One time requesters most likely don't know the policy, while LIR's do as > they should be doing it way more often. *cough* > Of course some independent contractor could do a lot of PI requests > for independent organisations, but then that entity is sort of working > like a LIR, but then differently. I cannot follow this analogy, sorry. This contractor isn't responsible for the assigned resources in the future, but the receiving end user is. Unlike LIR PA space where the LIR is in charge. > >>> All those folks who question the right of ASses (AUTONOMOUS systems) to > >>> have their own IP space and a routing table slot (in lieu of a better, > >>> sufficiently!capable replacement architecture) for technical reasons > >>> ("but our routers will break!") should ask themselves one question: are > >>> YOU ready to return YOUR prefix(es) because you are NOT in the routing > >>> tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s > >>> don't have any TECHNICAL need to announce their own allocations. All > >>> other non-upstream-free ISPs only have ECONOMIC reasons to do so. You > >> > >> With a too large routing table (which are indeed far from there) for the > >> currently deployed routers it will indeed be very economical as they > >> need to be upgraded. But this does depend on landrush. Running out of > >> 65k ASN's is the first thing that will happen. Though I wonder if some > >> smaller routers still deployed at endsites will like to handle that. > > > > There is no need for that. Read again. Noone except the real Tier 1s > > have the _technical_ _necessity_ to run default-free. All others can > > filter as much as they want, and use default route(s) for all else. > > I thought you needed PI because you wanted to do "traffic engineering", > how are you going to do traffic engineering with the following in your > tables: > > ::/0 fe80::2 eth0 > ::/0 fe80::1 eth1 > > Or you only want "Inbound TE" ($world to you) and not "Outbound TE"? I want to do both. Read again. You're in the camp denying all but ISPs the "right" to do BGP, because it's technically not necessary. Of course it isn't if you ignore all requirements put forward, but then it's also not necessary for the ISPs - except the real Tier 1s. Outbound TE is the easy part anyway, inbound TE is the tricky one. But I know that you understood BGP, so I'm not telling news here. :-) > >> Economics, that is people who won't be able to update their routers, > >> will then figure out who can have a slot there or not. > > > > No, they will start to default as they still need to access the content. > > Thus add extra prefixes to the routing tables, let everybody upgrade > their routers, but don't do it yourself. Nice. Letting others pay for > your dirt. Who are the others who NEED to upgrade? Only real Tier 1s. Only they NEED to have a "full table". All others can default to various degree, even to the extremes. Don't ignore that fact. > >> RIR's fortunately do not guarantee routability, thus them giving out > >> /48's from a single global /16 or so, to sites 'that desperately need > >> them', allows people who don't want them to filter when table pressure > >> become tight. Adding some geography in that big block might even allow > >> one to at least carry the traffic to a 'local' IX to hand it off. > > > > Hand it off to whom? You need paid transit for that. > > You want everything for free? :) No, I just want costs that aren't artificially inflated costs in order to push some political/economical agenda put forward by an (at large) ISP lobby. Regarding your mentioned scenario: this kind of routing structure would definately need a complete redesign of how money flows in the global Internet, aligning more to the POTS interconnection fee model. That'll be bureaucracy unseen yet in the Internet, even with the most telcoish peering heavyweights. > I know the OCCAID folks are getting close to a global free transit > network, but they also only arrive at IX's, your equipment still > needs to be there to use those resources. People are not coming to > you. But hey you know that very well :) Uhm, I'm not OCCAID, I'm just a random invited technical advisor to them. I'm for sure not representing OCCAID in any fashion. How do you get to this connection?!? I didn't even think of them in this whole discussion. > > That complicates > > things enormously. That's the whole can-of-worms related to geographic/ > > geopolitic addressing+routing. I won't delve into that here as it was > > discussed at length elsewhere. > > Oh don't worry, I don't see that working either. Too much politics. :-) I'm not sure wether we won't arrive there anyway. The current pretty much strictly tree-like money flow (with small artefacts like paid peering) will prolly have to adapt to a much more interconnected, meshed structure in the future... which will also allow things like geo-routing to have a chance of working at all. > PS: where are all those companies who are in desperate need for this? Not here. And my POV is more the non-commercial organization. Those had a respected place in the Internet once and weren't seen as a "nuisance who don't want to spend VC money left and right". Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Wed Dec 28 07:38:32 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 28 Dec 2005 07:38:32 +0100 Subject: [address-policy-wg] Re: AddOn --- Re: Re: Re: a consensus, about what? In-Reply-To: <4396EDB2.9050206@unfix.org> References: <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> <005d01c5fb27$95345ba0$df2f1fac@avalon> <008c01c5fb2b$3fd1d990$df2f1fac@avalon> <4396EDB2.9050206@unfix.org> Message-ID: <20051228063832.GC25461@srv01.cluenet.de> On Wed, Dec 07, 2005 at 03:12:02PM +0100, Jeroen Massar wrote: > ISP's are already doing this in IPv6. The only thing to 'stop' it is to > have "most" ISP's filter those announcements. But even if you filter > then the prefix is still reachable through the aggregate, thus > connectivity isn't lost. Wrong. It's lost if your link to the aggregate provider is down at that time, or this network having BGP/IGP problems. The more-specific multihoming idea works only if noone filters, and then you lose the only advantage that scheme has: the ability to filter. Doesn't work, next try... ;) > Instead of an end-site going to the RIRs for IP space, let them come to > you, you being LIR. You as a LIR give them a /48 (or more) and say they > can use their own ASN to announce it to their peers and transits. As > long as those parties accept it they are fine. This also means you will > have a plan for 200 potential customers :) The first side-effect is that > your customers are (partially) dependent of you, you as LIR disappears, > then they don't have squat. Not only then, but also for things like IRR and DNS reverse delegations. Again, only a half-solution. > Then again if RIPE disappears, what then? :) Then we have other problems, as has each and every LIR. > WARNING: Also note that there are a number of places where there is > quite some strict filtering happening. This might result that your small > /48 gets filtered out by fast/good "transits", but accepted by slow/bad > "transits", thus causing you to be pretty unreachable over those ASN's. Luckily this situation is actually changing, and the good networks nowadays tend to ACCEPT /48s and the bad networks still try to keep some weird classful filtering concepts alive. Not the prefix length makes an announcement valid or not... the prefix length can only be some kind of heuristic for that. In IPv4 /24 is the common stop-gap for IBGP leaks, for IPv6 it should be /48. > This has already been seen a couple of times in IPv6 routing tables! Yep, but times are a-a-changing. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From leo at ripe.net Wed Dec 28 11:32:01 2005 From: leo at ripe.net (leo vegoda) Date: Wed, 28 Dec 2005 11:32:01 +0100 Subject: [address-policy-wg] Re: Re: Re: Re: a consensus, about what? In-Reply-To: <20051228062159.GB25461@srv01.cluenet.de> Message-ID: <000d01c60b99$f080ea00$1d0200c1@FluffyBunny> Hi Daniel, Daniel Roesen wrote: [...] > Yep. XXXXXS membership (not "LIR" - there's no registry operation > involved) with a small basic fee for the essential one-off tasks of > assigning and maintaining the records for an ASN, an IPv4 PI > and an IPv6 > PI block (read: a basic multihomer setup). > > > >> A LIR should know the procedures which should make > requests very easy to > > >> process, at least that is the idea, which lowers load on > the RIR's. > > > > > > Should. Please come back with some hard data from NCC to > explain to us > > > that PI holders place a higher workload on NCC staff than > any real LIR. > > > Good luck. > > > > There might not be one, but you can expect it to be this way. > > Sorry, cannot believe that. I was hoping that NCC folks would chime in > and add some statistics to this point.... any takers? I'm not sure exactly which statistics you'd like us to provide. I've attached a graph showing the number of PI prefixes assigned over the last few years, plotted against the PA prefixes we allocated. However, as has been stated, outcomes are not the always a good measure of energy expended. For instance, the assignment window policy means LIRs with PA allocations often need to submit a number of requests for approval to make PA assignments. However, the workload in handling these requests has been reduced in the last couple of years by improved documentation, training and tools like the PA Wizard on the LIR Portal. If you would like a specific set of statistics then please let me know and we will do our best to provide them for you. Regards, -- leo vegoda RIPE NCC Registration Services Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: PA -vs- PI over time (Q3 2005).pdf Type: application/pdf Size: 166146 bytes Desc: not available URL: From Joao_Damas at isc.org Wed Dec 28 16:11:36 2005 From: Joao_Damas at isc.org (=?ISO-8859-1?Q?Jo=E3o_Damas?=) Date: Wed, 28 Dec 2005 16:11:36 +0100 Subject: [address-policy-wg] 2005-12 New Policy Proposal (4-Byte AS Number Policy Proposal) In-Reply-To: <6.2.0.14.2.20051227071718.02b6e640@kahuna.telstra.net> References: <18858.1135258232@cat.ripe.net> <6.2.0.14.2.20051227071718.02b6e640@kahuna.telstra.net> Message-ID: <108F45FB-333C-4016-8BDF-9A70AA08D22B@isc.org> On 26 Dec, 2005, at 21:28, Geoff Huston wrote: > > b) that the proposal replace the term "2 byte" with "16 bit" and "4 > byte" with "32 bit" due to the somewhat imprecise nature of the > definition of a "byte" why not use octet, which is the language used in the i-d? > > Other topics of discussion on the ARIN list have been > - whether the terminology and nomenclature sessions should be > included in the policy proposal If policy is what decides if a requester gets the resource or not, then no, as this sounds more like local implementation (procedure), like most of the text (except for the dates, perhaps, which set what gets assigned and when) > - whether the specification of dates are reasonable in this context is this a question of whether the suggested dates are appropriate or whether any dates are appropriate? > - whether the policy alters the current sequential number > allocation registry practice > - the criteria (if any) that should be applied to a request for an > AS number of the "other" type > - the desireable size of the private use AS number pool Would the policy need a reference to the IANA as the ultimate caretaker of the registry? Joao From gih at apnic.net Wed Dec 28 21:38:46 2005 From: gih at apnic.net (Geoff Huston) Date: Thu, 29 Dec 2005 07:38:46 +1100 Subject: [address-policy-wg] 2005-12 New Policy Proposal (4-Byte AS Number Policy Proposal) In-Reply-To: <108F45FB-333C-4016-8BDF-9A70AA08D22B@isc.org> References: <18858.1135258232@cat.ripe.net> <6.2.0.14.2.20051227071718.02b6e640@kahuna.telstra.net> <108F45FB-333C-4016-8BDF-9A70AA08D22B@isc.org> Message-ID: <6.2.0.14.2.20051229073458.02b6dba8@kahuna.telstra.net> At 02:11 AM 29/12/2005, Jo?o Damas wrote: >On 26 Dec, 2005, at 21:28, Geoff Huston wrote: > >> >>b) that the proposal replace the term "2 byte" with "16 bit" and "4 >>byte" with "32 bit" due to the somewhat imprecise nature of the >>definition of a "byte" > >why not use octet, which is the language used in the i-d? no particular reason - I'm sure in any room half would prefer "bits" and half "octets" I'm personally inclined to use "bits" in preference to "octets" >>Other topics of discussion on the ARIN list have been >>- whether the terminology and nomenclature sessions should be >>included in the policy proposal > >If policy is what decides if a requester gets the resource or not, >then no, as this sounds more like local implementation (procedure), >like most of the text (except for the dates, perhaps, which set what >gets assigned and when) However it does make the policy proposal clearer to read! >>- whether the specification of dates are reasonable in this context > >is this a question of whether the suggested dates are appropriate or >whether any dates are appropriate? the latter - the ARIN discussion has appeared to head towards a conclusion that the dates are the critical part of the proposal, and to remove them from the proposal would make the entire exercise somewhat meaningless. I concur with that view. >>- whether the policy alters the current sequential number >>allocation registry practice >>- the criteria (if any) that should be applied to a request for an >>AS number of the "other" type >>- the desireable size of the private use AS number pool > >Would the policy need a reference to the IANA as the ultimate >caretaker of the registry? No I do not think so. Nothing else changes in the policy proposal. regards, Geoff From Joao_Damas at isc.org Thu Dec 29 11:38:05 2005 From: Joao_Damas at isc.org (=?ISO-8859-1?Q?Jo=E3o_Damas?=) Date: Thu, 29 Dec 2005 11:38:05 +0100 Subject: [address-policy-wg] 2005-12 New Policy Proposal (4-Byte AS Number Policy Proposal) In-Reply-To: <6.2.0.14.2.20051229073458.02b6dba8@kahuna.telstra.net> References: <18858.1135258232@cat.ripe.net> <6.2.0.14.2.20051227071718.02b6e640@kahuna.telstra.net> <108F45FB-333C-4016-8BDF-9A70AA08D22B@isc.org> <6.2.0.14.2.20051229073458.02b6dba8@kahuna.telstra.net> Message-ID: <119DF830-F6EA-4F6C-AFF8-1936FF6B94E2@isc.org> On 28 Dec, 2005, at 21:38, Geoff Huston wrote: > > >>> - whether the specification of dates are reasonable in this context >> >> is this a question of whether the suggested dates are appropriate or >> whether any dates are appropriate? > > the latter - the ARIN discussion has appeared to head towards a > conclusion that the dates are the critical part of the proposal, > and to remove them from the proposal would make the entire exercise > somewhat meaningless. I concur with that view. > I do too. The way I read this text, the dates are the only real important content of this document. Joao From adrian at ripe.net Fri Dec 30 10:42:11 2005 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Fri, 30 Dec 2005 10:42:11 +0100 Subject: [address-policy-wg] 2005-01 New Draft Document Published (HD-ratio proposal) Message-ID: <20051230094211.0A6C6726A3@cod.ripe.net> PDP Number: 2005-01 HD-ratio proposal Dear Colleagues We have published a draft document that proposes a change to RIPE Document ripe-324. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-1.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 27 January 2006. If you have not yet signed up for the Policy Announcement Mailing List, you can do this by going to: http://www.ripe.net/mailman/listinfo/policy-announce Regards Adrian Bedford RIPE NCC Policy Coordinator From jeroen at unfix.org Sat Dec 31 10:51:51 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 31 Dec 2005 10:51:51 +0100 Subject: [address-policy-wg] Re: New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <43A94DB2.6050304@unfix.org> References: <20051221123011.GE6801@ripe.net> <43A94DB2.6050304@unfix.org> Message-ID: <43B654B7.1000501@unfix.org> Jeroen Massar wrote: > Filiz Yilmaz wrote: >> The RIPE NCC received the IPv6 address range 2A01:0000::/16 from >> the IANA in December 2005. > !Finally! IANA is passing /16's directly to the RIR's! That is a good > thing to see happening. Congrats (Or did somebody request a /17 ? :) Cheered to early, it's just a big block again: inet6num: 2a01:c000::/19 netname: FR-TELECOM-20051230 descr: France Telecom But it could mean that the wine lovers will get a broad availability of IPv6!!! Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Sat Dec 31 13:41:13 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 31 Dec 2005 13:41:13 +0100 Subject: [address-policy-wg] Re: AddOn --- Re: Re: Re: a consensus, about what? In-Reply-To: <20051228063832.GC25461@srv01.cluenet.de> References: <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> <20051206190257.GD27914@nokia.com> <20051207005847.GA23383@srv01.cluenet.de> <43968FDF.9000502@unfix.org> <005d01c5fb27$95345ba0$df2f1fac@avalon> <008c01c5fb2b$3fd1d990$df2f1fac@avalon> <4396EDB2.9050206@unfix.org> <20051228063832.GC25461@srv01.cluenet.de> Message-ID: <43B67C69.2000901@unfix.org> Daniel Roesen wrote: > On Wed, Dec 07, 2005 at 03:12:02PM +0100, Jeroen Massar wrote: >> ISP's are already doing this in IPv6. The only thing to 'stop' it is to >> have "most" ISP's filter those announcements. But even if you filter >> then the prefix is still reachable through the aggregate, thus >> connectivity isn't lost. > > Wrong. It's lost if your link to the aggregate provider is down at that > time, or this network having BGP/IGP problems. Why would that impact your connectivity when you are properly announcing your prefix? Except of course when there are ISP's that filter your prefix out. But hey that is their choice. They can also filter out a /32 if they like to do that. Their network. You can ask them to not do it. Or we can have a single block that contains all these prefixes so that they basically have to do it. Isn't the idea of having a more specific prefix that you actually make sure that your more-specific prefix actually get announced properly. If you have a IPv4 /24 and you cut it up in /28's and start announcing those at the moment, isn't it then your own responsibility to make sure those /28's actually get propagated properly? Indeed this requires asking people to lift their filters. This is the same as for IPv6 with /48's. As long as your more-specific /48 is correctly in the routing tables you get reached over those. When it is not, well you are not. > The more-specific multihoming idea works only if noone filters, and then > you lose the only advantage that scheme has: the ability to filter. It also works when there is a clear defined block that is used for this purpose so that ISP's can filter less strictly for that block. > Doesn't work, next try... ;) Indeed doesn't work for folks who don't want to read and can only complain but can't come up with their own solutions or think along. >> Instead of an end-site going to the RIRs for IP space, let them come to >> you, you being LIR. You as a LIR give them a /48 (or more) and say they >> can use their own ASN to announce it to their peers and transits. As >> long as those parties accept it they are fine. This also means you will >> have a plan for 200 potential customers :) The first side-effect is that >> your customers are (partially) dependent of you, you as LIR disappears, >> then they don't have squat. > > Not only then, but also for things like IRR and DNS reverse delegations. > > Again, only a half-solution. What is the difference of going to "Organisation X", who are a LIR, or "Organisation Y", who are a RIR ? >> Then again if RIPE disappears, what then? :) > > Then we have other problems, as has each and every LIR. What is the difference of a RIR disappearing with whom you do business or a LIR with whom you do business? >> What is a 'real LIR' actually according to you and whatisn't? > > A "real LIR" is a Local Internet Registry. A Local Internet Registery > assigns resources they got allocated by a RIR to hand out to end > users. > As PI space isn't subassignable, PI is not an option for LIRs. If you haven't noticed, current LIR's get an IPv6 PA prefix. You are trying to get address space for an end-site (you don't subassign, if you did you could become a LIR, okay at 200 customers). Thus my suggestion is that you can go to a LIR and get a part of their PA prefix and announce that. Simple. >> They all are in it for the money in the end. If their business is >> renting out "address space" (like the RIR's do effectively) then >> so be it, that is their business. > > But we're talking about independent IP space for "end users", not for > LIRs. Apparently my description of what I meant was too difficult to understand, thus I'll try to make it more clear: *) IANA has all the address space *) RIR's get address space from IANA *) LIR's get address space from RIR's *) end-sites get address space from LIR's Thus a LIR has a PA prefix. This LIR acts as a "PI provider for ISP's". Then an endsite comes to them (eg you) and asks for a /48. LIR gives you a /48, you announce that /48 as it being PI. You make sure that you announce that prefix properly, maintain multiple links and generally don't care about the PA prefix that is getting announced. The LIR might not even announce the PA prefix. The only reason left for having a link to the LIR would be because some people filter out the more specifics. Indeed the "PI prefix" is not registered as such at the RIR's, but you can still insert route6 objects in the RIR's db (if they support that :) and you can route it. WOW surprise: this is already being done today! PS: see Gert's anwer to my very related question and then wonder why I asked it in the first place: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01272.html [..] >> Of course some independent contractor could do a lot of PI requests >> for independent organisations, but then that entity is sort of >> working like a LIR, but then differently. > > I cannot follow this analogy, sorry. This contractor isn't responsible > for the assigned resources in the future, but the receiving end user > is. > Unlike LIR PA space where the LIR is in charge. The employees at a LIR never change jobs/functions/roles? LIR's don't sometimes actually hire a contractor to do their work? The contractor also knows how to fill in the paperwork. As you didn't notice the above was in defense for non-LIR's doing requests. [..] >> I thought you needed PI because you wanted to do "traffic >> engineering", how are you going to do traffic engineering with >> the following in your tables: >> >> ::/0 fe80::2 eth0 >> ::/0 fe80::1 eth1 >> >> Or you only want "Inbound TE" ($world to you) and not "Outbound TE"? > > I want to do both. Read again. You only claimed to be wanting to do "Traffic Engineering", never stated what kind of direction. > You're in the camp denying all but ISPs the "right" to do BGP, > because it's technically not necessary. Currently it is technically necessary, as there is no alternative. Which is why I suggest a big block where these "endsite PI" assignments can come from, or a special LIR which handles these blocks. So that in the future we can see 'those blocks are actually "endsite PI"' and let them solve their problems with the new technologies that have risen. Note that the 'camp' I am in is my very own little private club where I am the sole member and nobody else can join. There is nobody giving me any money for this stuff either. > Of course > it isn't if you ignore all requirements put forward, but then > it's also not necessary for the ISPs - except the real Tier 1s. If you would actually *read* what I am writing, summed up for the xth time again above, maybe I need to add pictures or something; I have already suggested a number of times that ISP's should be able to get a /48 or whatever prefix from either a LIR or directly from the RIR's so that they can announce it into BGP, just like that is already currently happening... > Outbound TE is the easy part anyway, inbound TE is the tricky one. But > I know that you understood BGP, so I'm not telling news here. :-) > >>>> Economics, that is people who won't be able to update their routers, >>>> will then figure out who can have a slot there or not. >>> No, they will start to default as they still need to access the content. >> Thus add extra prefixes to the routing tables, let everybody upgrade >> their routers, but don't do it yourself. Nice. Letting others pay for >> your dirt. > > Who are the others who NEED to upgrade? Only real Tier 1s. Only they > NEED to have a "full table". All others can default to various degree, > even to the extremes. Don't ignore that fact. If you don't have a full table, you can't do much Traffic Engineering either. Or are you going to say "2003::/16 is europe that goes over Transit X" ? Then you should not have a problem with a chunk of space from a PA provider either. >>>> RIR's fortunately do not guarantee routability, thus them giving out >>>> /48's from a single global /16 or so, to sites 'that desperately need >>>> them', allows people who don't want them to filter when table pressure >>>> become tight. Adding some geography in that big block might even allow >>>> one to at least carry the traffic to a 'local' IX to hand it off. >>> Hand it off to whom? You need paid transit for that. >> You want everything for free? :) > > No, I just want costs that aren't artificially inflated costs in order > to push some political/economical agenda put forward by an (at large) > ISP lobby. The only lobby gaining money with this are Vendor X, Y and Z they need to build the bigger iron, not the ISP's nor the Tier1's or any other of those folks who pay those vendors... > Regarding your mentioned scenario: this kind of routing structure would > definately need a complete redesign of how money flows in the global > Internet, aligning more to the POTS interconnection fee model. That'll > be bureaucracy unseen yet in the Internet, even with the most telcoish > peering heavyweights. There is a relatively simple charging scheme: x EUR or US$ per Gigabytes Of course you can add a wild variety of special cases like "US traffic", "Asian Traffic" etc. But this all has nothing to do with address policy, that is financial politics which you need to take care of with your upstreams. >> I know the OCCAID folks are getting close to a global free transit >> network, but they also only arrive at IX's, your equipment still >> needs to be there to use those resources. People are not coming to >> you. But hey you know that very well :) > > Uhm, I'm not OCCAID, That was not the reason I mentioned them. The reason I mentioned it was because it demonstrates that you as an endsite still need to get a link to the IX's or some other place where to interconnect with some transit providers. These links and equipment still costs money. [..] >> PS: where are all those companies who are in desperate need for this? > > Not here. And my POV is more the non-commercial organization. Those > had a respected place in the Internet once and weren't seen as a > "nuisance who don't want to spend VC money left and right". If they are not here, and this is the place where policies are made they apparently don't give much about all of this. If they don't know about this list: invite them. If they don't care: then there is no problem. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: