From pekkas at netcore.fi Tue Nov 1 12:20:48 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 1 Nov 2005 13:20:48 +0200 (EET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051014122508.G77157@mignon.ki.iif.hu> References: <20051010124501.S40670@mignon.ki.iif.hu> <20051014122508.G77157@mignon.ki.iif.hu> Message-ID: On Fri, 14 Oct 2005, Mohacsi Janos wrote: > Dear All, > I did not see any answers except one from Bill Manning - who was > supporting the 4. options. FWIW, I do not see a problem with option 3 -- the .hu servers would not need to get addresses from each an every ISP, two or three of them should be enough. I would be opposed to option 4. > So this means this is the accepted and RIPE reccomended method. > Basically allow allocating portable IPv6 address: > * root domain name system (DNS) server; > * global top level domain (gTLD) nameservers; > * country code TLD (ccTLDs) nameservers; > > When the RIPE policy will reflect this changes? > > Thanks Regards, > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > On Mon, 10 Oct 2005, Mohacsi Janos wrote: > >> Dear All, >> I have a question regarding the IPv6 address assignment to >> cc level DNS server. >> >> If you don't have answer to this question please forward it to an >> appropriate working group - sorry for cross-posting this mail to two wg. >> >> We have here in Hungary a dilemma: >> >> - Traditionally, the IPv4 address of the primary cc level DNS server in of >> belonged to NIIF/HUNGARNET. >> >> - The DNS registration service a while ago was delegated to Council of >> Hungarian Internet Providers (ISZT) who is also operating the biggest >> Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including >> NIIF/HUNGARNET) has right to do the registration via a special interface. >> >> - The IPv4 address of the primary cc level DNS server announced by >> NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate >> address from a new PI type IPv4 address space to DNS servers. >> >> - The primary hu DNS server is connected to BIX - to be well connected. >> >> >> What IPv6 address space should we allocate to hu primary DNS server? >> >> 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? >> - not very optimal since the only transit to hu primary will be >> NIIF/HUNGARNET >> - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET >> >> >> 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 >> and ripe-310)? >> - According to the RIPE documents: "Networks assigned under this policy may >> not be globally routable" - which problematical since primary DNS servers >> should be globally reachable. >> >> 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS >> server? >> - This can be problematical since the answers to DNS queries might be quite >> big. >> >> 4. Allocate /48 to primary hu DNS server that is globally routable? >> Are there similar to /48 from 2001:0500::/30 in RIPE region? >> >> - I think this is the cleanest solution. >> >> Can we discuss this issue on the working group or mailing lists? >> >> I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html >> >> In my opinion this can solve the problem.... >> >> Best Regards, >> >> >> Janos Mohacsi >> Network Engineer, Research Associate >> NIIF/HUNGARNET, HUNGARY >> Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 >> >> > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From baess at denic.de Tue Nov 1 16:53:37 2005 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Tue, 1 Nov 2005 16:53:37 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: Dear Pekka, I have not seen you on the last RIPE meeting when we had a short update on my policy proposal for anycasted TLD nameservers which is referenced later as the 4th option for the hungarian nameservers. > I would be opposed to option 4. > > >> 4. Allocate /48 to primary hu DNS server that is globally routable? > >> Are there similar to /48 from 2001:0500::/30 in RIPE region? > >> > >> - I think this is the cleanest solution. > >> > >> Can we discuss this issue on the working group or mailing lists? > >> > >> I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html > >> > >> In my opinion this can solve the problem.... I have not seen any discussions that think it is a bad idea to assign several network resources to TLD administrators which will enable them to operate their nameservers according to RFC3258. When we have reviewed the discussions we felt that your objection against the proposal was because of the size of the assignment. I'm planning to submit revised proposal with a reduced prefix length which better fits with other assignment policies. If you are opposing to the new proposal I would be glad to know as soon as it is submitted. If you are suggesting that .hu should start using IPv6 addresses from carriers to start deploying V6 with some of their nameservers and renumber them later as the V6 infrastructure matures I would agree. Looking at the query rates on V6 interfaces the impact of loosing one nameserver in the V6 cloud is not as crucial as in the V4 world at the moment. However this might change faster than sone people think at the moment making V6 anycasting of TLD nameservers a top priority for their administrators. Regards Andreas Baess -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess at denic.de From gert at space.net Wed Nov 2 16:39:15 2005 From: gert at space.net (Gert Doering) Date: Wed, 2 Nov 2005 16:39:15 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <87mzkuy3np.fsf@mid.deneb.enyo.de> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> <87mzkuy3np.fsf@mid.deneb.enyo.de> Message-ID: <20051102153915.GH65405@Space.Net> Hi, On Fri, Oct 28, 2005 at 12:51:38AM +0200, Florian Weimer wrote: > > On Mon, Oct 17, 2005 at 08:10:15PM +0200, Florian Weimer wrote: > >> > There is no option to give "10 addresses" to a user - period. > >> What about transfer networks? How do you handle those? > > > > The RFC says "all networks get a /64" (unless running unnumbered). > > I'm not concerned with the network, but with the IP addresses which > are given to routers. Or are you expected to run autoconfiguration > on transfer networks? Indeed, this is an interesting issue, and each ISP will find his own way to handle this. Currently, we tend to use the "::1" on our side of all links, and the customer can use whatever he likes - which is usually ::2. Autoconfiguration for routers works, but is not overly helpful, as the other router on the network needs to know the router's IP to route packets in its direction... - unless you run OSPFv3 (or ISIS), in which case IPv6 autoconfig (or "just use link-locals") would actually work fine. 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 jorgen at hovland.cx Wed Nov 2 19:24:02 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 2 Nov 2005 19:24:02 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> <87mzkuy3np.fsf@mid.deneb.enyo.de> <20051102153915.GH65405@Space.Net> Message-ID: <007d01c5dfda$99c53530$45eea2d5@j2> ----- Original Message ----- From: "Gert Doering" > Hi, > > On Fri, Oct 28, 2005 at 12:51:38AM +0200, Florian Weimer wrote: >> > On Mon, Oct 17, 2005 at 08:10:15PM +0200, Florian Weimer wrote: >> >> > There is no option to give "10 addresses" to a user - period. >> >> What about transfer networks? How do you handle those? >> > >> > The RFC says "all networks get a /64" (unless running unnumbered). >> >> I'm not concerned with the network, but with the IP addresses which >> are given to routers. Or are you expected to run autoconfiguration >> on transfer networks? > > Indeed, this is an interesting issue, and each ISP will find his own > way to handle this. > > Currently, we tend to use the "::1" on our side of all links, > and the customer can use whatever he likes - which is usually ::2. > > Autoconfiguration for routers works, but is not overly helpful, as the > other router on the network needs to know the router's IP to route > packets in its direction... - unless you run OSPFv3 (or ISIS), in > which case IPv6 autoconfig (or "just use link-locals") would actually > work fine. > Hi, >From the input I received I got the impression that you have to assign a /64 no matter what. So it means you use 2 IPs (or 10 in my case) and toss the other 2 - 2^64 away and then continue with next customer and assign a new /64 and so on. I hope I see the point of all this address waste in a few years. In the mean time I'll just do it(tm). Cheers, Joergen Hovland From gert at space.net Wed Nov 2 23:13:07 2005 From: gert at space.net (Gert Doering) Date: Wed, 2 Nov 2005 23:13:07 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <007d01c5dfda$99c53530$45eea2d5@j2> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> <87mzkuy3np.fsf@mid.deneb.enyo.de> <20051102153915.GH65405@Space.Net> <007d01c5dfda$99c53530$45eea2d5@j2> Message-ID: <20051102221307.GR65405@Space.Net> Hi, On Wed, Nov 02, 2005 at 07:24:02PM +0100, J?rgen Hovland wrote: > >From the input I received I got the impression that you have to assign a > >/64 > no matter what. Yes, and there are good reasons for that. (Personally, I disagree with the choice of a /64 for "any sort of network segments", but there *are* good reasons, and this is more an IETF engineering decision than a RIPE address policy thing) > So it means you use 2 IPs (or 10 in my case) and toss the > other 2 - 2^64 away and then continue with next customer and assign a new > /64 and so on. I hope I see the point of all this address waste in a few > years. In the mean time I'll just do it(tm). I hope you'll learn a little bit of math in the next few years - there are enough /64s. Whatever you want to do with it. And no, the standard argument "and everybody said 640K was enough" does *not* hold. Just do the math. (Inside a single /32, there are 4 *billion* /64s. How many customers did you say that you're going to connect to your 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 randy at psg.com Wed Nov 2 23:20:47 2005 From: randy at psg.com (Randy Bush) Date: Wed, 2 Nov 2005 12:20:47 -1000 Subject: [address-policy-wg] 2005-08 New Policy Proposal References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> <87mzkuy3np.fsf@mid.deneb.enyo.de> <20051102153915.GH65405@Space.Net> <007d01c5dfda$99c53530$45eea2d5@j2> <20051102221307.GR65405@Space.Net> Message-ID: <17257.15295.101937.582774@roam.psg.com> > I hope you'll learn a little bit of math in the next few > years - there are enough /64s. Whatever you want to do with > it. some of us are old enough to remember when we thought that about 32 bits of address. i really wish i could find the famous quote that said (about computer memory addressing, i believe) that, no matter what size you choose, it will be too small sooner than you planned. randy From gert at space.net Wed Nov 2 23:23:39 2005 From: gert at space.net (Gert Doering) Date: Wed, 2 Nov 2005 23:23:39 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <17257.15295.101937.582774@roam.psg.com> References: <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> <87mzkuy3np.fsf@mid.deneb.enyo.de> <20051102153915.GH65405@Space.Net> <007d01c5dfda$99c53530$45eea2d5@j2> <20051102221307.GR65405@Space.Net> <17257.15295.101937.582774@roam.psg.com> Message-ID: <20051102222339.GU65405@Space.Net> Hi, On Wed, Nov 02, 2005 at 12:20:47PM -1000, Randy Bush wrote: > > I hope you'll learn a little bit of math in the next few > > years - there are enough /64s. Whatever you want to do with > > it. > > some of us are old enough to remember when we thought that > about 32 bits of address. Now *this* part of math is easy. "Less IPs than people around are not going to make everybody happy". Yes, IPv6 could eventually be too small, if you end up ging every single RFID chip its own /64 - but nobody is proposing that. If you give every "reasonable" subnet a /64, I find it hard to envision a way to connect 4 billion subnets to a single (and small!) ISP. > i really wish i could find the famous quote that said (about > computer memory addressing, i believe) that, no matter what > size you choose, it will be too small sooner than you planned. So what's your suggestion? Turn off the Internet, and go fishing? 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 randy at psg.com Wed Nov 2 23:34:14 2005 From: randy at psg.com (Randy Bush) Date: Wed, 2 Nov 2005 12:34:14 -1000 Subject: [address-policy-wg] 2005-08 New Policy Proposal References: <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> <87mzkuy3np.fsf@mid.deneb.enyo.de> <20051102153915.GH65405@Space.Net> <007d01c5dfda$99c53530$45eea2d5@j2> <20051102221307.GR65405@Space.Net> <17257.15295.101937.582774@roam.psg.com> <20051102222339.GU65405@Space.Net> Message-ID: <17257.16102.907613.112637@roam.psg.com> >> i really wish i could find the famous quote that said (about >> computer memory addressing, i believe) that, no matter what >> size you choose, it will be too small sooner than you planned. > So what's your suggestion? Turn off the Internet, and go fishing? no, snorkeling. eat your heart out, cold weather boy! don't be silly. given the stupid political decision not to use variable length addressing, we need to be reasonably prudent. for p2p links, many of us use /126s. assign the customer the space they actually need. throw in one extra bit for insurance, two if you feel profligate. but not a /48. discuss getting rid of the /64 silliness. remember tlas? at least they're gone. yes, this is the "ipv4 mindset." but, after all, the v6 so-called architects only gave us ipv4 second system syndrome, no scalable routing, no extensible addressing, no loc/id sep, ... we've gone from a limit of 640k of ram to 1gb. big whoopiedoo. in ten years, we'll wish that was 1tb. randy From espen at fasthost.no Thu Nov 3 13:57:31 2005 From: espen at fasthost.no (Espen Holm Nilsen) Date: Thu, 03 Nov 2005 13:57:31 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <007d01c5dfda$99c53530$45eea2d5@j2> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> <87mzkuy3np.fsf@mid.deneb.enyo.de> <20051102153915.GH65405@Space.Net> <007d01c5dfda$99c53530$45eea2d5@j2> Message-ID: <436A093B.5000103@fasthost.no> J?rgen Hovland wrote: > From the input I received I got the impression that you have to assign > a /64 no matter what. So it means you use 2 IPs (or 10 in my case) and > toss the other 2 - 2^64 away and then continue with next customer and > assign a new /64 and so on. I hope I see the point of all this address > waste in a few years. In the mean time I'll just do it(tm). > Hi, *long time listener, first time speaking up'er* I share the views of Mr. Hovland, using a /64 for networks that only requires a few addresses seems like such a waste. Personally, I use /126 for p2p links. And, I see the point in 'we have more addresses than there are people in this world'. I haven't done the math for it, but if we waste 18446744073709551614 addresses for every single customer, will this stick? Will we regret it sometime in the future? (or rather; will our grandchildren think we were stupid in the future?) Me and a guy from work had a laugh, and visioned ourselvs being old, and being interviewed by 'Discovery History' because we ran out of IPv6 addresses saying: "I remember I was a kid back then, but that's what I thought would happen..' -- Sincerely, Espen Holm Nilsen From hph at oslo.net Mon Nov 7 19:21:31 2005 From: hph at oslo.net (Hans Petter Holen) Date: Mon, 07 Nov 2005 19:21:31 +0100 Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 Message-ID: <436F9B2B.2040701@oslo.net> Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG. -------------- next part -------------- An embedded message was scrubbed... From: "Debecker J.L." Subject: [address-policy-wg] ETNO comments on AD ratio for IPv4 addresses allocation Date: Thu, 16 Sep 2004 12:01:01 +0200 Size: 7904 URL: From pekkas at netcore.fi Tue Nov 8 02:43:59 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 8 Nov 2005 03:43:59 +0200 (EET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: References: Message-ID: On Tue, 1 Nov 2005, Andreas B??/Denic wrote: >>>> 4. Allocate /48 to primary hu DNS server that is globally routable? >>>> Are there similar to /48 from 2001:0500::/30 in RIPE region? >>>> >>>> - I think this is the cleanest solution. >>>> >>>> Can we discuss this issue on the working group or mailing lists? >>>> >>>> I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html >>>> >>>> In my opinion this can solve the problem.... > > I have not seen any discussions that think it is a bad idea to > assign several network resources to TLD administrators which will > enable them to operate their nameservers according to RFC3258. > > When we have reviewed the discussions we felt that your objection > against the proposal was because of the size of the assignment. I'm > planning to submit revised proposal with a reduced prefix length > which better fits with other assignment policies. If you are > opposing to the new proposal I would be glad to know as soon as it > is submitted. Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough; 2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended; 3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically. In addition, a) we have enough address space that allocating a (v6) /32 is not waste. b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a). So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fred at iwf.org.uk Tue Nov 8 12:21:41 2005 From: fred at iwf.org.uk (Fred Langford) Date: Tue, 8 Nov 2005 11:21:41 -0000 Subject: [address-policy-wg] RE: address-policy-wg digest, Vol 1 #315 - 2 msgs - Checking details of assignments Message-ID: <8AF3400A7DF1FA4E8CE2DCF9B7B11630804C99@newmarket.iwforguk.local> Hi, More of a general question but will RIPE be authenticating the details (address, abuse etc) of the IP assignments to ensure the integrity of the database? Regards Fred Langford Fred Langford Internet Research Analyst Internet Watch Foundation t +44 (0)1223 237700 www.iwf.org.uk -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of address-policy-wg-request at ripe.net Sent: 08 November 2005 11:00 To: address-policy-wg at ripe.net Subject: address-policy-wg digest, Vol 1 #315 - 2 msgs Send address-policy-wg mailing list submissions to address-policy-wg at ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request at ripe.net You can reach the person managing the list at address-policy-wg-admin at ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 (Hans Petter Holen) 2. Re: [ipv6-wg] IPv6 micro allocation or something else? (Pekka Savola) --__--__-- Message: 1 Date: Mon, 07 Nov 2005 19:21:31 +0100 From: Hans Petter Holen To: address-policy-wg at ripe.net Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 This is a multi-part message in MIME format. --------------050809070908030505050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG. --------------050809070908030505050308 Content-Type: message/rfc822; name*0="[address-policy-wg] ETNO comments on AD ratio for IPv4 addresses"; name*1=" allocation.eml" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename*0="[address-policy-wg] ETNO comments on AD ratio for IPv4 addre"; filename*1="sses allocation.eml" Return-Path: Received: from smtp220.tiscali.dk (smtp220.tiscali.dk [62.79.79.114]) by i.dont.no (8.12.10/8.12.10) with ESMTP id i8GD3O9Z028063 for ; Thu, 16 Sep 2004 12:03:24 -0100 Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159]) by smtp220.tiscali.dk (8.12.11/8.12.11) with ESMTP id i8GD3OPS091657 for ; Thu, 16 Sep 2004 15:03:24 +0200 (CEST) (envelope-from address-policy-wg-admin at ripe.net) Delivered-To: hpholen at tiscali.no Received: from postboy.ripe.net (193.0.0.201) by cpmail.dk.tiscali.com (6.7.018) id 412F265D0014F272 for hpholen at tiscali.no; Thu, 16 Sep 2004 15:03:22 +0200 Received: from postboy.ripe.net (localhost [127.0.0.1]) by postboy.ripe.net (Postfix) with ESMTP id 12CB179C2D; Thu, 16 Sep 2004 14:59:02 +0200 (CEST) Delivered-To: address-policy-wg at lists.ripe.net Received: by postboy.ripe.net (Postfix, from userid 8) id 9C0C079D57; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by postboy.ripe.net (Postfix) with ESMTP id 8FF5479D56 for ; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: by postman.ripe.net (Postfix, from userid 8) id 8A7D34FC46; Thu, 16 Sep 2004 12:01:21 +0200 (CEST) Received: from etno.be (138.206-78-194.adsl-fix.skynet.be [194.78.206.138]) by postman.ripe.net (Postfix) with ESMTP id 8FE554E26F for ; Thu, 16 Sep 2004 12:01:20 +0200 (CEST) Received: from etnodebecker ([192.168.1.1]) by etno.be (etno.be [192.168.1.253]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 44-md50000000012.tmp for ; Thu, 16 Sep 2004 12:01:04 +0200 Reply-To: From: "Debecker J.L." To: Cc: , , "Michael Bartholomew" Organization: ETNO Message-ID: <001101c49bd4$126111e0$0101a8c0 at etno.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Processed: etno.be, Thu, 16 Sep 2004 12:01:04 +0200 (not processed: message from valid local sender) X-Lookup-Warning: HELO/EHLO lookup on etnodebecker does not match 192.168.1.1 X-MDRemoteIP: 192.168.1.1 X-Return-Path: debecker at etno.be X-MDaemon-Deliver-To: address-policy-wg at ripe.net X-RIPE-Spam-Level: ** X-RIPE-Spam-Status: U 0.499986 / 1.8 / 0.0 / disabled X-RIPE-Signature: 80201789b55f74e2c7bf4670a81825e0 Subject: [address-policy-wg] ETNO comments on AD ratio for IPv4 addresses allocation Sender: address-policy-wg-admin at ripe.net Errors-To: address-policy-wg-admin at ripe.net X-BeenThere: address-policy-wg at ripe.net X-Mailman-Version: 2.0.13 Precedence: bulk List-Id: Developing policies relating to the management and registration of Internet addresses and routing identifiers List-Post: X-RIPE-Lists: Developing policies relating to the management and registration of Internet addresses and routing identifiers List-Subscribe: , List-Unsubscribe: , List-Help: List-Archive: Date: Thu, 16 Sep 2004 12:01:01 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by i.dont.no id i8GD3O9Z028063 RIPE ? Dear Sir, Madam, ? ETNO, representing?41 major telecom operators from 34 European countries, has studied the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by criteria based on AD (Assignment Density) ratio. Our conclusions are formulated in the attached Expert Contribution EC064. The document is the unanimous opinion of ETNO Members represented in the ETNO Frequency Management Working Group and has been endorsed by the ETNO Board. ? We are all prepared to discuss these comments in more detail and whenever useful. ETNO will be pleased to contribute to the further development of Europe's views on the issue. ? Best regards, ? Michael Bartholomew ETNO Director ------------------------- September 2004 ETNO Expert Contribution on AD ratio for IPv4 addresses allocation Executive Summary ETNO (1) has considered the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by a criteria based on AD (Assignment Density) ratio. ETNO strongly support the proposal and suggest selecting an AD ratio of 0.966. ETNO further suggest to the RIRs to monitor the impact of this measure on address consumption and periodically report on it to the addressing community. Background During the RIPE 48 meeting in Amsterdam, a proposal was presented by APNIC to replace the fixed utilisation criteria of 80% to request additional IPv4 addresses blocks, by a criteria based on "AD ratio" value. This ratio value corresponds to a logarithmic scale and corresponds to a percentage utilisation, which decreases as the size of the address space grows. The presentation can be downloaded at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio.p df The decision was made to take the discussion to the RIPE Address-policy working group mailing list and to ask for some feed back from the community. As most European Telecommunications Network Operators' Association 1(ETNO) members are large or extra-large Local Internet Registries in Europe, representing an important part of these categories in the RIPE region, this proposal was considered and analysed with attention. Findings 1- This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries. 2- The Local Internet Registries using the 80% criteria may continue to do so and will not be impacted by the new policy. 3- Complicated calculation or administrative burden should be easily avoided to registries choosing this method using simple chart or software through LIR portal. 4- As analysed by APNIC, the impact on address consumption is limited to a maximum around 20% and can be easily controlled and monitored using a rather conservative approach (AD ratio of 0.966). 5- This impact can be partly counterbalanced by reducing the number of small and extra-small registries whose existence is only justified by management overhead of large registries with current 80% criteria, and has a positive impact on address aggregation. 6- No additional impact on registrations is seen in RIPE region, as infrastructure assignments are already registered in the database. Conclusion ETNO strongly supports this proposal and suggest selecting a conservative AD ratio value of 0.966. ETNO also suggest to the RIRs to monitor the use of this facility and its impact on address consumption, and periodically report on it to the addressing community. (1) The European Telecommunications Network Operators' Association is representing 41 major companies from 34 European countries, providing electronic communications networks over fixed, mobile or personal communications systems. ETNO's primary purpose is to establish a constructive dialogue between its member companies and actors involved in the development of the European Information Society to the benefit of users. More information on ETNO can be found at: www.etno.be ETNO Expert Contribution EC064 (2004/09) --------------050809070908030505050308-- --__--__-- Message: 2 Date: Tue, 8 Nov 2005 03:43:59 +0200 (EET) From: Pekka Savola To: Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?= cc: address-policy-wg at ripe.net, ipv6-wg at ripe.net, ipv6-wg-admin at ripe.net, Mohacsi Janos Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1824570081-1131332849=:12767 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 1 Nov 2005, Andreas B??/Denic wrote: >>>> 4. Allocate /48 to primary hu DNS server that is globally routable? >>>> Are there similar to /48 from 2001:0500::/30 in RIPE region? >>>> >>>> - I think this is the cleanest solution. >>>> >>>> Can we discuss this issue on the working group or mailing lists? >>>> >>>> I saw a proposal: >>>> http://www.ripe.net/ripe/policies/proposals/2005-2.html >>>> >>>> In my opinion this can solve the problem.... > > I have not seen any discussions that think it is a bad idea to assign > several network resources to TLD administrators which will enable them > to operate their nameservers according to RFC3258. > > When we have reviewed the discussions we felt that your objection > against the proposal was because of the size of the assignment. I'm > planning to submit revised proposal with a reduced prefix length which > better fits with other assignment policies. If you are opposing to the > new proposal I would be glad to know as soon as it is submitted. Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough; 2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended; 3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically. In addition, a) we have enough address space that allocating a (v6) /32 is not waste. b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a). So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1824570081-1131332849=:12767-- End of address-policy-wg Digest -- This message has been scanned for viruses and potentially harmful content by StreamShield Protector. From baess at denic.de Thu Nov 10 10:46:48 2005 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Thu, 10 Nov 2005 10:46:48 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: Dear Pekka, > Yes. Let me clarify my objections: > 1) special policy for ccTLDs (if they do not anycast) is not > IMHO needed as assignments from (some of the) transits should be > enough; I agree that if a DNS operator is below a certain limit of DNS servers he does not have the need for anycast at all. But once you grow your farm beyond a limit anycast is the current best solution. DENIC for example had 11 different NS before we have started to deploy anycast to further enhance network diversity and capacity and simultaniously introducing AAAA records for our nameservers. > 2) special policy for any arbitrary service, if anycast, does not > seem justified because it's too open-ended; In my first presentation I have voted for a more open policy. However I have seen no acceptance to this approach as the process of defining a network critical resource would take too long while I felt consensus that TLD nameservers are critical enough to justify special treatment. So I wrote a policy proposal that is only applicable for TLD nameservers. Why do you think this is open ended? > 3) ccTLD combined with requirement to anycast it appears to be > suitably well justified operationally and technically. I have not limited my proposal to ccTLDs but includes any TLD. > In addition, > a) we have enough address space that allocating a (v6) /32 is not > waste. If you have seen the updated version of my proposal I hope you will not see any problem iwth a /48 prefix. > b) I'm strongly opposed to creating any special micro-allocation > blocks which is just waiting for getting the worms out hence a). I don't see why you think that it is a bad idea to do the assignments for anycasted nameservers from a bigger block. Can you explain what makes the difference from spreading them all over the address range. Sounds like a security through obscurity approach to me. I haven't made a suggestion on how RIPE should manage their microallocation assignments. From my personal experience I would be an favour of a microallocation block as this bundles the efforts to eliminate routing problems that might exist. > So, I'd say that if the policy proposal is 3) with a (v6) /32, I > shouldn't have a problem with it. As said before, it is a superset of 3. with /48 V6 prefixes. Maybe it's best to take a quick look at the current proposal. Regards Andreas Baess From jorgen at hovland.cx Thu Nov 10 12:28:10 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 10 Nov 2005 12:28:10 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: <200511101128.jAABSApQ007741@mail03.hipercom.no> Hi, I would like to comment on this topic. --- From: Andreas B??/Denic Date: Mon, 4 Apr 2005 18:18:22 +0200 >1. Is there a need for anycasting at all ? > >I was surprised to see this question on the list. >I think that anycasted nameservers are an accepted standard and there >is no need to discuss pros and cons anymore. If anycasting involves creating special prefix allocation policies, then I am 100% against anycast. We are currently running anycast on our own nameservers, but we don't require our own v4 or v6 prefix just for that. I don't see why you can't do the same with your already 11 nameservers (on 11 networks?), but maybe that's just me. Furthermore, nameservers should not be specially treated. It is impossible to define what is important and what is not (like defining what spam is). The only anycast service at all I would be willing to exempt is root nameservers and give them their own prefix if needed. Nothing, and by nothing I mean any service (dns, web, mail etc), is justified for their own anycast prefix unless you can implement it with standard allocation policies. Microallocations might be a standard allocation policy. What I don't want to see is that RIRs hand out microallocations for the sole purpose of running anycast. Then I would probably be asking for at least 50 microallocations just for myself, oh pretty please. I am therefore against any proposal about anycast prefix allocations no matter whom and what it concerns. Do whatever you want between your peers if your agreement permits; just don?t put the prefix in the dfz. I don't think it belongs there. Thank you, Joergen Hovland -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Andreas B??/Denic Dear Pekka, > Yes. Let me clarify my objections: > 1) special policy for ccTLDs (if they do not anycast) is not > IMHO needed as assignments from (some of the) transits should be > enough; I agree that if a DNS operator is below a certain limit of DNS servers he does not have the need for anycast at all. But once you grow your farm beyond a limit anycast is the current best solution. DENIC for example had 11 different NS before we have started to deploy anycast to further enhance network diversity and capacity and simultaniously introducing AAAA records for our nameservers. > 2) special policy for any arbitrary service, if anycast, does not > seem justified because it's too open-ended; In my first presentation I have voted for a more open policy. However I have seen no acceptance to this approach as the process of defining a network critical resource would take too long while I felt consensus that TLD nameservers are critical enough to justify special treatment. So I wrote a policy proposal that is only applicable for TLD nameservers. Why do you think this is open ended? > 3) ccTLD combined with requirement to anycast it appears to be > suitably well justified operationally and technically. I have not limited my proposal to ccTLDs but includes any TLD. > In addition, > a) we have enough address space that allocating a (v6) /32 is not > waste. If you have seen the updated version of my proposal I hope you will not see any problem iwth a /48 prefix. > b) I'm strongly opposed to creating any special micro-allocation > blocks which is just waiting for getting the worms out hence a). I don't see why you think that it is a bad idea to do the assignments for anycasted nameservers from a bigger block. Can you explain what makes the difference from spreading them all over the address range. Sounds like a security through obscurity approach to me. I haven't made a suggestion on how RIPE should manage their microallocation assignments. From my personal experience I would be an favour of a microallocation block as this bundles the efforts to eliminate routing problems that might exist. > So, I'd say that if the policy proposal is 3) with a (v6) /32, I > shouldn't have a problem with it. As said before, it is a superset of 3. with /48 V6 prefixes. Maybe it's best to take a quick look at the current proposal. Regards Andreas Baess From he at uninett.no Thu Nov 10 15:53:25 2005 From: he at uninett.no (Havard Eidnes) Date: Thu, 10 Nov 2005 15:53:25 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511101128.jAABSApQ007741@mail03.hipercom.no> References: <200511101128.jAABSApQ007741@mail03.hipercom.no> Message-ID: <20051110.155325.51808449.he@uninett.no> > [...] > I am therefore against any proposal about anycast prefix > allocations no matter whom and what it concerns. Do whatever > you want between your peers if your agreement permits; just > don't put the prefix in the dfz. I don't think it belongs > there. Hear, hear! Concisely put. Regards, - H?vard From kelaidi at ote.gr Fri Nov 11 13:17:52 2005 From: kelaidi at ote.gr (Kelaidi Christina) Date: Fri, 11 Nov 2005 14:17:52 +0200 Subject: [address-policy-wg] HD Ratio for IPv4 Message-ID: <12CD8406D55B7C4185BF83C2C1D587F101383188@MAILSRV.central-domain.root.ote.gr> My company believes that the proposal for the calculation of the HD ratio to measure IPv4 usage is a an improvement to the existing one and we would like to support once again this new policy proposal. Christina Kelaidi GD Regulatory Affairs OTE S.A. 99 Kifissias Av. 15124 Maroussi Greece tel: +30 2106117205 e-mail: kelaidi at ote.gr From Michael.Dillon at btradianz.com Fri Nov 11 15:09:30 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 11 Nov 2005 14:09:30 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511101128.jAABSApQ007741@mail03.hipercom.no> Message-ID: > I am therefore against any proposal about anycast prefix allocations no > matter whom and what it concerns. Do whatever you want between your peers > if your agreement permits; just don?t put the prefix in the dfz. I don't > think it belongs there. I think that some anycast prefixes *DO* belong in the dfz. However, I think that it is wrong to give out anycast prefix allocations to organizations whose only intent is to run their own internal services. The .de TLD is proposing that they should get a prefix just for their own anycast services. Instead, I think that RIPE and other RIRs should give out a small number of prefix allocations to "network operators" who intend to run anycast network services for their customers. Does anyone see the parallel with Internet access network operators who run networks to provide Internet access to their customers? In theory, an anycast operator will sell anycast services to other organizations. Those organizations will place their servers in facilities where the anycast operator has some kind of presence, i.e. a router and a rack. The organizations such as DENIC, will receive a *SUBSET* of the anycast prefix for their servers but that subset will not be visible outside of the anycast operator's network. If customers, such as DENIC, do not feel that a single anycast network operator can supply the coverage that they require then they can buy services from more than one anycast network operator. It is interesting to note that domain hosting uses the DNS protocol which allows for a server to have up to 13 unique IP addresses. Theoretically a domain hosting company like DENIC could use the services of 13 different anycast operators. If a company like DENIC was willing to sign an undertaking with RIPE that they would offer the use of their own anycast architecture commercially to other organizations, then DENIC should also be able to qualify for an anycast prefix allocation. --Michael Dillon From jorgen at hovland.cx Fri Nov 11 17:20:44 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 17:20:44 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: <30507014-1131726357@hovland.cx> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Michael.Dillon at btradianz.com Sent: 11. november 2005 15:10 >> I am therefore against any proposal about anycast prefix allocations no >> matter whom and what it concerns. Do whatever you want between your >>peers >> if your agreement permits; just don?t put the prefix in the dfz. I don't >> think it belongs there. > >I think that some anycast prefixes *DO* belong in the dfz. >However, I think that it is wrong to give out anycast >prefix allocations to organizations whose only intent >is to run their own internal services. The .de TLD is >proposing that they should get a prefix just for their >own anycast services. We are probably thinking the same but have two different solutions for it. If you have a medium/large international network you can implement anycast without using prefixes assigned to you by the RIR for anycast usage. If you do not have a medium/large international network then you can contact someone who has. If this is a question about money then I am sure some network operator eventually will lower their prices to meet your satisfaction. Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers around the world at their collocation facilities. MCI may then assign DENIC one /64 prefix from their /32 prefix which will be routed to the closest DENIC server in MCIs network. Would this be a suitable solution? This /32 has not been given to MCI by the RIR explicit for anycast purposes. The other solution is that DENIC builds their own international network and do the same - as long as the prefix has not been given to DENIC by the RIR solely for anycast purposes. Cheers, Joergen Hovland From gert at space.net Fri Nov 11 19:01:46 2005 From: gert at space.net (Gert Doering) Date: Fri, 11 Nov 2005 19:01:46 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <30507014-1131726357@hovland.cx> References: <30507014-1131726357@hovland.cx> Message-ID: <20051111180146.GG69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 05:20:44PM +0100, J?rgen Hovland wrote: > Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers > around the world at their collocation facilities. MCI may then assign DENIC > one /64 prefix from their /32 prefix which will be routed to the closest > DENIC server in MCIs network. > Would this be a suitable solution? This /32 has not been given to > MCI by the RIR explicit for anycast purposes. I'm not sure whether you understand what this is all about. DENIC is providing a public service (namely: DNS for the .de TLD) - and *the whole world* wants to reach their DNS servers. (No different to .com and other large TLDs) Due to the fact that DNS has packet size limits (the DNS WG says so, and it's not the address policy WG's job to know DNS better than the DNS WG), anycast is a necessary workaround if a DNS operator wants to increase reliability and reachability for their DNS servers - after they have exhausted all other options (like "using very short server names" and so on). So where's the benefit if DENIC sets up something inside MCI's network that only MCI customers can see? And *if* the route is leaked outside, what is gained, except people will have to maintain explicit white-lists ("hey, this /64 is DENIC-anycast, so we permit it, while not permitting other /64s")? I don't really understand what you are worrying about, and why, and how this "solution" is going to help anyone. 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 elmi at 4ever.de Fri Nov 11 19:27:38 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 11 Nov 2005 19:27:38 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <30507014-1131726357@hovland.cx> References: <30507014-1131726357@hovland.cx> Message-ID: <20051111182738.GC22271@new.detebe.org> jorgen at hovland.cx (J?rgen Hovland) wrote: > Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers > around the world at their collocation facilities. MCI may then assign DENIC > one /64 prefix from their /32 prefix which will be routed to the closest > DENIC server in MCIs network. > Would this be a suitable solution? This /32 has not been given to > MCI by the RIR explicit for anycast purposes. Vendor/ISP dependence has never been a solution for better availability. Michael and you are somewhat off the track IMHO. Read Gert's comment, too. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From randy at psg.com Fri Nov 11 19:53:04 2005 From: randy at psg.com (Randy Bush) Date: Fri, 11 Nov 2005 08:53:04 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? References: <30507014-1131726357@hovland.cx> <20051111180146.GG69925@Space.Net> Message-ID: <17268.59536.75539.506928@roam.psg.com> > DENIC is providing a public service (namely: DNS for the .de TLD) - and > *the whole world* wants to reach their DNS servers. (No different > to .com and other large TLDs) or anywhere else in the dns tree, tends of thousands of servers but i am sure denic is very important randy From jorgen at hovland.cx Fri Nov 11 20:01:36 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 20:01:36 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111180146.GG69925@Space.Net> Message-ID: <33177606-1131736010@hovland.cx> -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: 11. november 2005 19:02 >So where's the benefit if DENIC sets up something inside MCI's network >that only MCI customers can see? And *if* the route is leaked outside, >what is gained, except people will have to maintain explicit white-lists >("hey, this /64 is DENIC-anycast, so we permit it, while not permitting >other /64s")? I will try to explain more detailed: A large network provider can have hundreds/thousands of peers. These peers receive the same /32 prefix. A large network provider has housing facilities many places in many countries. * Put your server in some or all of these housing facilities. * Give every server the same IP address. * Tell large network provider to use the closest path and make a route to this IP address where you have your servers (use a routing protocol or whatever) * The peers of large network provider will be routed to the closest DENIC server in large network providers network. * If a server is down, the next closest DENIC server will get the traffic. * There is no single point of failure here. * You are using anycast. * You have a multiple failover solution. I hope this was clear enough. Cheers, Joergen Hovland From jorgen at hovland.cx Fri Nov 11 20:01:36 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 20:01:36 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111180146.GG69925@Space.Net> Message-ID: <33177606-1131736010@hovland.cx> -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: 11. november 2005 19:02 >So where's the benefit if DENIC sets up something inside MCI's network >that only MCI customers can see? And *if* the route is leaked outside, >what is gained, except people will have to maintain explicit white-lists >("hey, this /64 is DENIC-anycast, so we permit it, while not permitting >other /64s")? I will try to explain more detailed: A large network provider can have hundreds/thousands of peers. These peers receive the same /32 prefix. A large network provider has housing facilities many places in many countries. * Put your server in some or all of these housing facilities. * Give every server the same IP address. * Tell large network provider to use the closest path and make a route to this IP address where you have your servers (use a routing protocol or whatever) * The peers of large network provider will be routed to the closest DENIC server in large network providers network. * If a server is down, the next closest DENIC server will get the traffic. * There is no single point of failure here. * You are using anycast. * You have a multiple failover solution. I hope this was clear enough. Cheers, Joergen Hovland From gert at space.net Fri Nov 11 22:06:06 2005 From: gert at space.net (Gert Doering) Date: Fri, 11 Nov 2005 22:06:06 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <17268.59536.75539.506928@roam.psg.com> References: <30507014-1131726357@hovland.cx> <20051111180146.GG69925@Space.Net> <17268.59536.75539.506928@roam.psg.com> Message-ID: <20051111210606.GH69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 08:53:04AM -1000, Randy Bush wrote: > > DENIC is providing a public service (namely: DNS for the .de TLD) - and > > *the whole world* wants to reach their DNS servers. (No different > > to .com and other large TLDs) > > or anywhere else in the dns tree, tends of thousands of servers Yes. I think we can agree that there are lots of domain service providers that have 2, 3, maybe 5 name servers in their NS set (and those can grow without anycasting), and that there are some that really use up all that you can fit in those small packets, and want to provide even *more* resiliency. Looking at DNS, I see "lots of nameservers" primarily for root, and some gTLD/ccTLD zones. Haven't seen that for "further down" stuff (.co.uk is "sort of ccTLD" stuff). And really - I don't care who they are and what they do, but if they think it's a good thing to have more than 11 different primary name servers for whatever they are hosting, it must be important to them, and at leat to whoever is providing the funding. > but i am sure denic is very important The second largest DNS zone in the world *does* sound somewhat important to me. I don't have query numbers to compare .com and .de requests/second (which would be more useful than sheer zone size), but I'd assume that there are also plenty of request for .de domains. 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 jorgen at hovland.cx Fri Nov 11 23:44:40 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 23:44:40 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111210606.GH69925@Space.Net> Message-ID: <200511112244.jABMiYpQ011727@mail03.hipercom.no> Some final comments from me, -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering Sent: 11. november 2005 22:06 >Yes. I think we can agree that there are lots of domain service >providers that have 2, 3, maybe 5 name servers in their NS set (and those >can grow without anycasting), and that there are some that really use >up all that you can fit in those small packets, and want to provide >even *more* resiliency. Looking at DNS, I see "lots of nameservers" >primarily for root, and some gTLD/ccTLD zones. Haven't seen that for >"further down" stuff (.co.uk is "sort of ccTLD" stuff). Gert, you can configure 1000 anycast servers, all with the same IP address, in your own network no matter how small/large your network is. You can place them next to each other on the same rack or you can place 500 of them in your Frankfurt serverhall and 500 in D?sseldorf as long as they are in your network. You do _not_ need an anycast prefix from your RIR for this. Your growth problem is now solved. The next problem is that you want better redundancy(?). Then buy more connectivity. If you for some reason can't afford better connectivity, please look at my MCI example and put your servers elsewhere. >And really - I don't care who they are and what they do, but if they >think it's a good thing to have more than 11 different primary name >servers for whatever they are hosting, it must be important to them, >and at least to whoever is providing the funding. > >The second largest DNS zone in the world *does* sound somewhat important >to me. I don't have query numbers to compare .com and .de requests/second >(which would be more useful than sheer zone size), but I'd assume that >there are also plenty of request for .de domains. If it wasn't for the fact that I do business in Germany I couldn't care less if .de was dead or not. You can only decide what is important to you, not for the rest of the crowd. If you try you will find out that everything is important. To cover everyones needs we would need 42 billion prefixes in the global routing table. Most of it wouldn't make sense anyway, just like this anycast discussion is starting to get. Cheers, Joergen Hovland From gert at space.net Sat Nov 12 08:43:23 2005 From: gert at space.net (Gert Doering) Date: Sat, 12 Nov 2005 08:43:23 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511112244.jABMiYpQ011727@mail03.hipercom.no> References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> Message-ID: <20051112074323.GL69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 11:44:40PM +0100, J?rgen Hovland wrote: > >Yes. I think we can agree that there are lots of domain service > >providers that have 2, 3, maybe 5 name servers in their NS set (and those > >can grow without anycasting), and that there are some that really use > >up all that you can fit in those small packets, and want to provide > >even *more* resiliency. Looking at DNS, I see "lots of nameservers" > >primarily for root, and some gTLD/ccTLD zones. Haven't seen that for > >"further down" stuff (.co.uk is "sort of ccTLD" stuff). > > Gert, you can configure 1000 anycast servers, all with the same IP address, > in your own network no matter how small/large your network is. That's the point. DENIC isn't doing this for themselves. They do this for *you* (and for me, and even for Randy). So putting up the anycast servers somewhere where half of the internet might not see them is not useful. For maximum resiliency (against DoS and outages), one wants to spread the anycast servers over as many different (!) networks as possible. And this cannot be done without a dedicated prefix for 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 randy at psg.com Sat Nov 12 08:52:53 2005 From: randy at psg.com (Randy Bush) Date: Fri, 11 Nov 2005 21:52:53 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> Message-ID: <17269.40789.639973.680372@roam.psg.com> > That's the point. DENIC isn't doing this for themselves. They > do this for *you* in a peer2peer or client/server world, this statement is fatuous randy From gert at space.net Sat Nov 12 09:26:21 2005 From: gert at space.net (Gert Doering) Date: Sat, 12 Nov 2005 09:26:21 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <17269.40789.639973.680372@roam.psg.com> References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> <17269.40789.639973.680372@roam.psg.com> Message-ID: <20051112082621.GM69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 09:52:53PM -1000, Randy Bush wrote: > > That's the point. DENIC isn't doing this for themselves. They > > do this for *you* > > in a peer2peer or client/server world, this statement is fatuous So we abandon DNS, because it's a model from the last century? (Now that would be a policy proposal for the DNS WG, not for address policy -- but I'm all for it, this whole hassle with "finding a free domain name" and "going to court with name right holders" and so on is really annoying) 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 randy at psg.com Sat Nov 12 14:12:47 2005 From: randy at psg.com (Randy Bush) Date: Sat, 12 Nov 2005 03:12:47 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> <17269.40789.639973.680372@roam.psg.com> <20051112082621.GM69925@Space.Net> Message-ID: <17269.59983.585022.797869@roam.psg.com> >>> That's the point. DENIC isn't doing this for themselves. They >>> do this for *you* >> in a peer2peer or client/server world, this statement is fatuous > So we abandon DNS, because it's a model from the last century? you can if you want to. i did not suggest doing so, so i guess you would like to. whatever rocks your boat. my point was simple, aside from the total end user (ones not running edonkey or having bought sony cds), most hosts provide to others, certainly all interesting hosts. while folk who need to look up in the de namespace appreciate what denic does, i don't think they do it for free. so we'll withold the gold medals if you don't mind. randy From hph at oslo.net Sun Nov 13 00:29:53 2005 From: hph at oslo.net (Hans Petter Holen) Date: Sun, 13 Nov 2005 00:29:53 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511112244.jABMiYpQ011727@mail03.hipercom.no> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> Message-ID: <43767AF1.4000302@oslo.net> J?rgen Hovland wrote: > The next problem is that you want better redundancy(?). Then buy more > connectivity. If you for some reason can't afford better connectivity, > please look at my MCI example and put your servers elsewhere. > > What if I want to plan for more disasters than that ? Like MCI going out of business? I guess I could agree with MCI to place some servers with their IP addresses outside their network and agree with other providers to carry my more specific routes. In order to have universal access and plan for any network failure I would have to sign such agreement with all ISPs. This could be a business idea for somebody: to set up an "anycast registry" - sign agreement with all the major ISPs to not aggregate my addresses. Then I could offer a guaranteed minimum routability for thoose prefixes. What we are discussing is really to make this mechanism available by addressing policy. Traditionally the RIRs does not set routing policy. Hans Petter From jorgen at hovland.cx Sun Nov 13 15:20:31 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun, 13 Nov 2005 15:20:31 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43767AF1.4000302@oslo.net> Message-ID: <200511131420.jADEKNpQ013501@mail03.hipercom.no> -----Original Message----- From: Hans Petter Holen [mailto:hph at oslo.net] Sent: 13. november 2005 00:30 >What if I want to plan for more disasters than that ? Like MCI going out >of business? Hi, If you honestly believe that all 11 internet service providers which you are running your nameservers with (these 11 also run anycast and have multiple servers each) at the exact same time will go bankrupt and shutdown their network at around the same time then I don't think it is the nameservers we should worry about but the internet itself. >I guess I could agree with MCI to place some servers with their IP >addresses outside their network and agree with other providers to carry >my more specific routes. In order to have universal access and plan for >any network failure I would have to sign such agreement with all ISPs. > Will it not satisfy your needs placing 200 servers at 100 (numbers randomly selected) MCI locations world wide using IP space assigned by MCIs /32? Or is this discussion simply about the fact that the /32 prefix is not yours and you want to use your "own"? Take the following: 1 server at ISP x in London. /32 announced by ISP x's ASN. Your ip is assigned from this /32. 1 server at ISP x in Amsterdam. /32 announced by ISP x's ASN. Your ip is assigned from this /32. and 1 server at ISP g in London. /32 announced by your ASN through ISP g. It is your /32 1 server at ISP k in Amsterdam. /32 announced by your ASN through ISP k. It is your /32 What is really the difference here? Yes, ISP x, g or k can go bankrupt so you loose that redundancy in the first scenario. Any others? I can't think of any. Either way, there is no difference here network wise? You get exactly the same reachability/redundancy. So, should we alter the address policy because ISP x can go bankrupt and we need redundancy for that? You still have 10 more ISPs you have placed your servers at if you use all 11 IPs. >This could be a business idea for somebody: to set up an "anycast >registry" - sign agreement with all the major ISPs to not aggregate my >addresses. Then I could offer a guaranteed minimum routability for >thoose prefixes. > For medium/large operators that wouldn't make any sense at all since they already have a global network and can do fully redundant anycasting anytime with any IP address. For smaller ones it might. Conclusion: I am against a policy that would let LIRs receive prefixes from RIRs when the intention is to use the prefix for anycast. I have hopefully shown that you don't need a dedicated prefix for that. It is a bad hack to the existing solution and as I see it, would give the same benefits. This bad hack is one thing. I am sure everyone can agree on that it is impossible to decide whom and what services should be granted anycast prefixes if it was accepted. The only solution would be to permit everyone or have some rule saying "you must have more than N anycast servers at Y locations" which basically again means that everyone can and will get a prefix. I am not against 42 billion prefixes in dfz. I am sure we will get there eventually:) I am however against the ones that don't make any sense. Cheers, Joergen Hovland From kurtis at kurtis.pp.se Sun Nov 13 15:32:24 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 13 Nov 2005 15:32:24 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511131420.jADEKNpQ013501@mail03.hipercom.no> References: <200511131420.jADEKNpQ013501@mail03.hipercom.no> Message-ID: <80F7DFEA-67E6-46B1-9D8D-EF6864FC3728@kurtis.pp.se> On 13 nov 2005, at 15.20, J?rgen Hovland wrote: > Take the following: > > 1 server at ISP x in London. /32 announced by ISP x's ASN. Your ip is > assigned from this /32. > 1 server at ISP x in Amsterdam. /32 announced by ISP x's ASN. Your > ip is > assigned from this /32. > > and > > 1 server at ISP g in London. /32 announced by your ASN through ISP > g. It is > your /32 > 1 server at ISP k in Amsterdam. /32 announced by your ASN through > ISP k. It > is your /32 > > > What is really the difference here? Yes, ISP x, g or k can go > bankrupt so > you loose that redundancy in the first scenario. Any others? I > can't think > of any. Either way, there is no difference here network wise? You get > exactly the same reachability/redundancy. So, should we alter the > address > policy because ISP x can go bankrupt and we need redundancy for > that? You > still have 10 more ISPs you have placed your servers at if you use > all 11 > IPs. In the first scenario you are forced to the routing policies of ISP x and only to the locations of ISP x. In the second example you can co- locate, connect to and IXP and do your own routing decisions as well as be present at locations you choose (without "vasting" or even having to go to 11 servers). - kurtis - From woeber at cc.univie.ac.at Sun Nov 13 16:38:56 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Sun, 13 Nov 2005 15:38:56 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43767AF1.4000302@oslo.net> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> Message-ID: <43775E10.3020604@cc.univie.ac.at> Having listened for a while 'cause I am neither an expert in anycasting nor in running name services for a large zone, I'd like to step back a couple of yards/meters/. >From that perspective I seem to see 2 aspects in the recent discussion: - you shall not receive address space for builing a service, you are to buy that from some "big-folk". This is an intersting point of view, and taken to the extreme will make us end up with a _very small_ number of _very big_ entities. Traditionally these things were called monopolies. Nothing I would be too happy to see coming back ;-) - there has been th discussion regarding "anycast" but isnt this just a special(?) case of th PI-topic? I might easily have overlooked something, pls. see my initial disclaimer. Wilfried. Hans Petter Holen wrote: > J?rgen Hovland wrote: > >>The next problem is that you want better redundancy(?). Then buy more >>connectivity. If you for some reason can't afford better connectivity, >>please look at my MCI example and put your servers elsewhere. >> >> > > What if I want to plan for more disasters than that ? Like MCI going out > of business? > > I guess I could agree with MCI to place some servers with their IP > addresses outside their network and agree with other providers to carry > my more specific routes. In order to have universal access and plan for > any network failure I would have to sign such agreement with all ISPs. > > This could be a business idea for somebody: to set up an "anycast > registry" - sign agreement with all the major ISPs to not aggregate my > addresses. Then I could offer a guaranteed minimum routability for > thoose prefixes. > > What we are discussing is really to make this mechanism available by > addressing policy. Traditionally the RIRs does not set routing policy. > > Hans Petter > > _______________________________________________ > ipv6 mailing list > ipv6 at ls.aco.net > http://noc.aco.net/mailman/listinfo/ipv6 > From jorgen at hovland.cx Sun Nov 13 16:47:14 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun, 13 Nov 2005 16:47:14 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <80F7DFEA-67E6-46B1-9D8D-EF6864FC3728@kurtis.pp.se> Message-ID: <200511131547.jADFl5pQ015856@mail03.hipercom.no> Hi, -----Original Message----- From: Kurt Erik Lindqvist [mailto:kurtis at kurtis.pp.se] Sent: 13. november 2005 15:32 >In the first scenario you are forced to the routing policies of ISP x >and only to the locations of ISP x. In the second example you can co- >locate, connect to and IXP and do your own routing decisions as well >as be present at locations you choose (without "vasting" or even >having to go to 11 servers). You will always be forced to obey the rules of whatever provider you are using, ISP or IXP. I get the impression that you believe ISP x's routing policies will always be insufficient for you. Nameservers are not the only anycast service so it would be tricky to discuss this in general. But you want your nameserver to be reachable, that I know. Both scenarios will accomplish that with the same amount of redundancy. What kind of routing policies do you mean? Do you want to restrict your reachability? Joergen Hovland From jorgen at hovland.cx Sun Nov 13 17:22:37 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun, 13 Nov 2005 17:22:37 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43775E10.3020604@cc.univie.ac.at> Message-ID: <200511131622.jADGMSpQ016583@mail03.hipercom.no> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Wilfried Woeber, UniVie/ACOnet Hi Wilfried, >From that perspective I seem to see 2 aspects in the recent discussion: > >- you shall not receive address space for builing a service, you are to > buy that from some "big-folk". > > This is an intersting point of view, and taken to the extreme will > make us end up with a _very small_ number of _very big_ entities. > > Traditionally these things were called monopolies. Nothing I would be > too happy to see coming back ;-) > >- there has been th discussion regarding "anycast" but isnt this just > a special(?) case of th PI-topic? You are right; the differences between PI and anycast are few. Perhaps it would be a (good?) idea to merge the anycast and PI discussion into a single discussion instead. > This is an intersting point of view, and taken to the extreme will > make us end up with a _very small_ number of _very big_ entities. Strictly speaking; All you need to do is to create a network and ask for address space. The "anycasters" won't even do that. They want the address space without the network. That is what I don't support. Joergen Hovland From kurtis at kurtis.pp.se Sun Nov 13 18:34:06 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 13 Nov 2005 18:34:06 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511131547.jADFl5pQ015856@mail03.hipercom.no> References: <200511131547.jADFl5pQ015856@mail03.hipercom.no> Message-ID: On 13 nov 2005, at 16.47, J?rgen Hovland wrote: > From: Kurt Erik Lindqvist [mailto:kurtis at kurtis.pp.se] > Sent: 13. november 2005 15:32 > > >> In the first scenario you are forced to the routing policies of ISP x >> and only to the locations of ISP x. In the second example you can co- >> locate, connect to and IXP and do your own routing decisions as well >> as be present at locations you choose (without "vasting" or even >> having to go to 11 servers). >> > > You will always be forced to obey the rules of whatever provider > you are > using, ISP or IXP. I get the impression that you believe ISP x's > routing > policies will always be insufficient for you. Nameservers are not > the only > anycast service so it would be tricky to discuss this in general. > But you want your nameserver to be reachable, that I know. Both > scenarios > will accomplish that with the same amount of redundancy. What kind of > routing policies do you mean? Do you want to restrict your > reachability? If you are connected to the IXP with your own peerings, you will have control of the routing policies. If you host with ISP x, you will have to follow ISP x peerings and depeerings. You claimed the two cases to be equal. I just pointed out that they are not. - kurtis - From elmi at 4ever.de Mon Nov 14 09:31:47 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 14 Nov 2005 09:31:47 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511131622.jADGMSpQ016583@mail03.hipercom.no> <200511131547.jADFl5pQ015856@mail03.hipercom.no> <200511131420.jADEKNpQ013501@mail03.hipercom.no> References: <43775E10.3020604@cc.univie.ac.at> <200511131622.jADGMSpQ016583@mail03.hipercom.no> <80F7DFEA-67E6-46B1-9D8D-EF6864FC3728@kurtis.pp.se> <200511131547.jADFl5pQ015856@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <200511131420.jADEKNpQ013501@mail03.hipercom.no> Message-ID: <20051114083147.GG96756@new.detebe.org> Hello J?rgen, my responses to three emails from you to the lists, jorgen at hovland.cx (J?rgen Hovland) wrote: > Will it not satisfy your needs placing 200 servers at 100 (numbers randomly > selected) MCI locations world wide using IP space assigned by MCIs /32? Certainly not - why should one be satisfied with such a pseudo-solution? A service provider (we _are_ talking about Internet infrastructure service providers currently, keep that in mind) that has come to the conclusion they want to "anycast" (aka shared unicast) their services, surely has thought about going to a big ISP before and decided that that' not what they want. > Or is this discussion simply about the fact that the /32 prefix is not yours > and you want to use your "own"? It is - currently, talking DNS providers - about the fact that you cannot accumulate too many server addresses in a DNS UDP packet. > Either way, there is no difference here network wise? You get > exactly the same reachability/redundancy. Only if you limit your thoughts to a very small world. Sorry, but the fallacy of your argument is so obvious that the words fail me here. > I am against a policy that would let LIRs receive prefixes from RIRs when > the intention is to use the prefix for anycast. I have hopefully shown that > you don't need a dedicated prefix for that. No. You have shown that _you_ don't need that. You try to decide here how other people run their services. I honestly believe that's none of your business, but up to the respective service provider. You can give them good advice, of course. But you must be open to accepting arguments for the way they intend to do it. jorgen at hovland.cx (J?rgen Hovland) wrote: > You will always be forced to obey the rules of whatever provider you are > using, ISP or IXP. I get the impression that you believe ISP x's routing > policies will always be insufficient for you. The problem arises when the sole ISP's routing policies are insufficient at _any_ point in time. > Nameservers are not the only > anycast service so it would be tricky to discuss this in general. DNS is a special service (UDP packet size stuff) and needs a special solution - unfortunately. jorgen at hovland.cx (J?rgen Hovland) wrote: > Hi, > > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis at kurtis.pp.se] > Sent: 13. november 2005 15:32 > > >In the first scenario you are forced to the routing policies of ISP x > >and only to the locations of ISP x. In the second example you can co- > >locate, connect to and IXP and do your own routing decisions as well > >as be present at locations you choose (without "vasting" or even > >having to go to 11 servers). > > You will always be forced to obey the rules of whatever provider you are > using, ISP or IXP. I get the impression that you believe ISP x's routing > policies will always be insufficient for you. Nameservers are not the only > anycast service so it would be tricky to discuss this in general. > But you want your nameserver to be reachable, that I know. Both scenarios > will accomplish that with the same amount of redundancy. What kind of > routing policies do you mean? Do you want to restrict your reachability? > > > Joergen Hovland > > jorgen at hovland.cx (J?rgen Hovland) wrote: > >From that perspective I seem to see 2 aspects in the recent discussion: > > > >- you shall not receive address space for builing a service, you are to > > buy that from some "big-folk". > > > > This is an intersting point of view, and taken to the extreme will > > make us end up with a _very small_ number of _very big_ entities. > > > > Traditionally these things were called monopolies. Nothing I would be > > too happy to see coming back ;-) You did not comment on this part. Why? From jorgen at hovland.cx Mon Nov 14 10:51:58 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 14 Nov 2005 10:51:58 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114083147.GG96756@new.detebe.org> Message-ID: <200511140951.jAE9pwpQ007320@mail03.hipercom.no> -----Original Message----- From: Elmar K. Bins [mailto:elmi at 4ever.de] > Hello J?rgen, Hello >> Will it not satisfy your needs placing 200 servers at 100 (numbers randomly >> selected) MCI locations world wide using IP space assigned by MCIs /32? > >Certainly not - why should one be satisfied with such a pseudo-solution? Because that?s what everybody else are doing? That?s why we currently have 600 routes in dfz and not one per server on the internet? Should DNS be excused only because the protocol itself supports a finite amount of IP addresses? >A service provider (we _are_ talking about Internet infrastructure service >providers currently, keep that in mind) that has come to the conclusion >they want to "anycast" (aka shared unicast) their services, surely has >thought about going to a big ISP before and decided that that' not what >they want. Ok, but I would still like to hear from people who have tried that but had to reject the solution for valid reasons where the ISP offered you this service. Anyone? >> Either way, there is no difference here network wise? You get >> exactly the same reachability/redundancy. > >Only if you limit your thoughts to a very small world. Sorry, but >the fallacy of your argument is so obvious that the words fail me here. Could you be more specific? I am sure there are ISPs that are not willing to sell anycast services, but if you have buyers then the sellers will always show up eventually. >> I am against a policy that would let LIRs receive prefixes from RIRs when >> the intention is to use the prefix for anycast. I have hopefully shown that >> you don't need a dedicated prefix for that. > > No. You have shown that _you_ don't need that. Obviously some people have different needs. It is good that we try to figure those out. > You try to decide here how > other people run their services. No, I am trying to prevent excessive defragmentation of the routing table. I am trying to prevent a special case of PI where you are not even required to have your own network. The requirement to this special PI case is so low that anyone would be able to apply for it - and anyone _will_ apply for it. In order to prevent that we only permit DNS? Are there any other services that should be permitted? > I honestly believe that's none of your > business, but up to the respective service provider. You can give them > good advice, of course. But you must be open to accepting arguments for > the way they intend to do it. So far we have two reasons why anycast prefixes, "anycast PI", should be permitted: * Bankruptcy * Routing policies >> Nameservers are not the only >> anycast service so it would be tricky to discuss this in general. > >DNS is a special service (UDP packet size stuff) and needs a special >solution - unfortunately. I disagree. DNS is certainly not a special service. The importance of it is however perhaps greater than many others - many, but far from all. The packet size thing is a general design problem. As far as I know, there are currently two methods to solve it: * EDNS0 * TC flag If you are going to use the packet size problem as an argument to use anycast, then I think it would be a good idea to hear reasons why none of these solutions would be suitable (also because I don't really know it myself) and perhaps if there are any other solutions that would help solving the problem? > >From that perspective I seem to see 2 aspects in the recent discussion: > > > >- you shall not receive address space for builing a service, you are to > > buy that from some "big-folk". > > > > This is an intersting point of view, and taken to the extreme will > > make us end up with a _very small_ number of _very big_ entities. > > > > Traditionally these things were called monopolies. Nothing I would be > > too happy to see coming back ;-) > > You did not comment on this part. Why? I was probably just a bit unclear. "All you need to do is to create a network and ask for address space.." There is no monopoly threat as long as you follow the requirements. If the requirements are too strict, then it would become a problem. Currently, I think they are not. Joergen Hovland From elmi at 4ever.de Mon Nov 14 11:12:12 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 14 Nov 2005 11:12:12 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511140951.jAE9pwpQ007320@mail03.hipercom.no> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> Message-ID: <20051114101211.GK96756@new.detebe.org> jorgen at hovland.cx (J?rgen Hovland) wrote: > >Certainly not - why should one be satisfied with such a pseudo-solution? > > Because that?s what everybody else are doing? That?s why we currently have > 600 routes in dfz and not one per server on the internet? > Should DNS be excused only because the protocol itself supports a finite > amount of IP addresses? Should SPs be forbidden valid, redundant, Tier-whatever independent, autonomous solutions because we don't want an arbitrary number (prefixes in the DFZ) to change? As much as I don't like a big DFZ, as much I'm obliged to let the service provider decide on how they want to conduct business. > >Only if you limit your thoughts to a very small world. Sorry, but > >the fallacy of your argument is so obvious that the words fail me here. > > Could you be more specific? I am sure there are ISPs that are not willing to > sell anycast services, but if you have buyers then the sellers will always > show up eventually. I'll try to be a bit more specific. I think about those big ISPs and how they are present in some regions, but not in others - tough luck if you chose them - should have chosen another, so renumber your ccTLD server. I think of this big ISP not peering with regional ISPs, Tier-3+ etc.; well, you should have chosen a Tier-2 or -3 then. But again, they are not present, where you need it. I think of connecting directly to regional communities at IXes. I think of delivering special services to special target audiences. I can think of some more things, all of which can be solved by making a compromise here and there. But everything taken together, (a) the compromises you have to make don't make a coherent picture (some cancel each other out) and (b) there's maybe still things left over you cannot cover. > > No. You have shown that _you_ don't need that. > > Obviously some people have different needs. It is good that we try to figure > those out. I'm still not sure why we are talking about how businesses should provide their services here - it's not our concern, really. We are not the judges of other people's decisions (sometimes I'd like to, yeah...). > > You try to decide here how > > other people run their services. > > No, I am trying to prevent excessive defragmentation of the routing table. I can see what you're trying to do, and that is a good thing in itself. It nonetheless needs tampering with other people's decisions, and that's nothing you can do freely. And that's why I'm saying that you're trying to take over the service provider's engineering and operations departments. > I > am trying to prevent a special case of PI where you are not even required to > have your own network. The requirement to this special PI case is so low > that anyone would be able to apply for it - and anyone _will_ apply for it. Well, in the least, anycasting a service costs money (setup aside, operations costs money, too, transit line cost money, etc). So it is pretty unlikely "anyone" would apply for it. Well, maybe anyone, but not everyone. But you're trying to lure us away from the proposal we're discussing which states a special case of DNS for _ccTLDs_, which some people may consider Internet infrastructure (I mentioned this in my previous email). So back to the topic - I have no problem with _all_ ccTLDs and gTLDs applying for five prefixes each. > The packet size thing is a general design problem. As far as I know, there > are currently two methods to solve it: > > * EDNS0 > * TC flag Which are fine for any non-TLD provider to presume. TLD operators need to find a way to service all the folks, even those with broken resolvers. > > > Traditionally these things were called monopolies. Nothing I would be > > > too happy to see coming back ;-) > > > > You did not comment on this part. Why? > > I was probably just a bit unclear. "All you need to do is to create a > network and ask for address space.." There is no monopoly threat as long as > you follow the requirements. If the requirements are too strict, then it > would become a problem. Currently, I think they are not. The requirements for v6 space in the RIPE region includes having transit customers (at all, the 200 is just an arbitrary number). No ccTLD registry that's not also conducting other business may receive an allocation. That's the entire point of the special case being made. ccTLDs cannot deliver services in v6 like in v4. This - IMHO - is a v6 showstopper. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jorgen at hovland.cx Mon Nov 14 12:19:05 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 14 Nov 2005 12:19:05 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114101211.GK96756@new.detebe.org> Message-ID: <200511141119.jAEBJ5pQ011498@mail03.hipercom.no> -----Original Message----- From: Elmar K. Bins [mailto:elmi at 4ever.de] >But you're trying to lure us away from the proposal we're discussing which >states a special case of DNS for _ccTLDs... > >The requirements for v6 space in the RIPE region includes having transit >customers (at all, the 200 is just an arbitrary number). No ccTLD registry >that's not also conducting other business may receive an allocation. That's >the entire point of the special case being made. ccTLDs cannot deliver >services in v6 like in v4. This - IMHO - is a v6 showstopper. So we are back at the beginning; I say no to anycast PI for TLDs/ccTLDs. I don't believe it is a special case so it doesn't need a special policy. TLDs/ccTLDs could/should however be used as an argument to allow v6 PI prefixes in general. V6 PI compared to v4 surely is a showstopper for many, or at least for some. Cheers, Joergen Hovland From tim.streater at dante.org.uk Mon Nov 14 14:41:48 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Mon, 14 Nov 2005 13:41:48 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511141119.jAEBJ5pQ011498@mail03.hipercom.no> References: <20051114101211.GK96756@new.detebe.org> <200511141119.jAEBJ5pQ011498@mail03.hipercom.no> Message-ID: <6.2.3.4.2.20051114134048.04e37a00@mail.dante.org.uk> At 11:19 14/11/2005, J?rgen Hovland wrote: >So we are back at the beginning; >I say no to anycast PI for TLDs/ccTLDs. I don't believe it is a special case >so it doesn't need a special policy. TLDs/ccTLDs could/should however be >used as an argument to allow v6 PI prefixes in general. >V6 PI compared to v4 surely is a showstopper for many, or at least for some. It's a showstopper for us on one of the networks we manage. We can't get V6 PI for it like we could v4 PI. -- Tim From gert at space.net Mon Nov 14 18:01:46 2005 From: gert at space.net (Gert Doering) Date: Mon, 14 Nov 2005 18:01:46 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511140951.jAE9pwpQ007320@mail03.hipercom.no> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> Message-ID: <20051114170146.GZ69925@Space.Net> Hi, On Mon, Nov 14, 2005 at 10:51:58AM +0100, J?rgen Hovland wrote: > > You try to decide here how > > other people run their services. > > No, I am trying to prevent excessive defragmentation of the routing table. I > am trying to prevent a special case of PI where you are not even required to > have your own network. The requirement to this special PI case is so low > that anyone would be able to apply for it - and anyone _will_ apply for it. > In order to prevent that we only permit DNS? Are there any other services > that should be permitted? This is the type of argument that I love most - "if we permit this to you, everybody will want it, too!!!". I read into this that you are afraid that the initial criteria are not strict enough. As far as I can see, the criteria are pretty explicit, and verificable. [..] > >DNS is a special service (UDP packet size stuff) and needs a special > >solution - unfortunately. > > I disagree. DNS is certainly not a special service. The importance of it is > however perhaps greater than many others - many, but far from all. > The packet size thing is a general design problem. As far as I know, there > are currently two methods to solve it: > > * EDNS0 > * TC flag > > If you are going to use the packet size problem as an argument to use > anycast, then I think it would be a good idea to hear reasons why none of > these solutions would be suitable (also because I don't really know it > myself) and perhaps if there are any other solutions that would help solving > the problem? Please. We have been through this part of the discussion half a year ago, and we've asked those that know (the DNS WG) and they tell us "we can't rely on EDNS0, and truncation is bad". It would be very helpful if you could do us the favour and read up on old arguments in the archives. To repeat myself: it's not the AP WG's job to tell the DNS WG how DNS works. We're making policy, (partly) based on the expertise of other working 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 he at uninett.no Mon Nov 14 23:31:44 2005 From: he at uninett.no (Havard Eidnes) Date: Mon, 14 Nov 2005 23:31:44 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114170146.GZ69925@Space.Net> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> <20051114170146.GZ69925@Space.Net> Message-ID: <20051114.233144.79281105.he@uninett.no> > Please. We have been through this part of the discussion half a year ago, > and we've asked those that know (the DNS WG) and they tell us "we can't > rely on EDNS0, and truncation is bad". It would be very helpful if you > could do us the favour and read up on old arguments in the archives. Really? I always got the sense of earlier comments (not here, though -- I seem to recall this from IETF circles) saying that if you're running so newfangled software that you speak IPv6 you would be expected to also implement EDNS0. Regards, - H?vard From gert at space.net Mon Nov 14 23:46:11 2005 From: gert at space.net (Gert Doering) Date: Mon, 14 Nov 2005 23:46:11 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114.233144.79281105.he@uninett.no> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> <20051114170146.GZ69925@Space.Net> <20051114.233144.79281105.he@uninett.no> Message-ID: <20051114224611.GD69925@Space.Net> Hi, On Mon, Nov 14, 2005 at 11:31:44PM +0100, Havard Eidnes wrote: > > Please. We have been through this part of the discussion half a year ago, > > and we've asked those that know (the DNS WG) and they tell us "we can't > > rely on EDNS0, and truncation is bad". It would be very helpful if you > > could do us the favour and read up on old arguments in the archives. > > Really? I always got the sense of earlier comments (not here, though > -- I seem to recall this from IETF circles) saying that if you're > running so newfangled software that you speak IPv6 you would be > expected to also implement EDNS0. I don't see the connection. The set of NS records returned by the root name servers for ".de" needs to be small enough so that the results fit into a non-EDNS0-UDP response packets, no matter whether the client can do IPv6 or not - even very old clients should get a complete answer. OTOH, I am way out of my technical league here - I refer to the DNS WG, and they said "don't do this". 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 jorgen at hovland.cx Mon Nov 14 23:49:00 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 14 Nov 2005 23:49:00 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114170146.GZ69925@Space.Net> Message-ID: <200511142249.jAEMn9pQ003111@mail03.hipercom.no> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering >I read into this that you are afraid that the initial criteria are not >strict enough. As far as I can see, the criteria are pretty explicit, >and verificable. If you mean afraid of a large routing table, then the answer is no. From the archives you might see that I say "who cares, it's the vendors problem". Anyway, as I said in the email after the one you replied to; I don't think there is anything special about DNS (it's just another protocol) so it would be better to discuss general PI allocations instead of specific cases of PI which is after my opinion a waste of time (but this discussion was not). >Please. We have been through this part of the discussion half a year ago, >and we've asked those that know (the DNS WG) and they tell us "we can't >rely on EDNS0, and truncation is bad". It would be very helpful if you >could do us the favour and read up on old arguments in the archives. It would be very helpful if you didn't assume I don't know what I am talking about. >To repeat myself: it's not the AP WG's job to tell the DNS WG how DNS >works. We're making policy, (partly) based on the expertise of other >working >groups. Ok, since I am with the DNS WG maybe it would be okay anyway to mention slightly off-topic but related material? EDNS0 works, just like any other working protocol. The problem is deploying it, also just like any other protocol - like IPv6. Since there is no critical problem today with IPv4, or DNS, there will always be problems deploying the next versions of it when the first people screams "hey this is not working!!!!". We could wait for it to happen. We could use it as an excuse to find temporary workarounds. We can even make special address policies for special cases that would give us more time, but sooner or later it is going to happen - because the protocol itself is not sufficient and that is your axiom. Please do give me comments, but I think I have finished discussing this topic now. Joergen Hovland From Michael.Dillon at btradianz.com Tue Nov 15 11:53:04 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 15 Nov 2005 10:53:04 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111180146.GG69925@Space.Net> Message-ID: > DENIC is providing a public service (namely: DNS for the .de TLD) - and > *the whole world* wants to reach their DNS servers. (No different > to .com and other large TLDs) OK, DENIC is providing a public service. But DENIC's network is still only serving DENIC itself. RIRs give out address allocations to network operators whose networks are serving many organizations. If DENIC's newtork was serving many organizations and allowing .FR, .SK, .RU and .PE to provide their public services over the DENIC global anycast network, then RIPE should give you addresses to run your anycast network. But if DENIC is not going to serve other organizations then RIPE should not give you the addresses but should tell you to go and find a global anycast network operator to assist you. --Michael Dillon From Michael.Dillon at btradianz.com Tue Nov 15 12:02:07 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 15 Nov 2005 11:02:07 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051112074323.GL69925@Space.Net> Message-ID: > That's the point. DENIC isn't doing this for themselves. They do this > for *you* (and for me, and even for Randy). The Red Cross Society is also doing it for *you* and for me and even for Randy. But that doesn't make their network special. If DENIC really wants to build a special network then they should share that special network with other TLD operators. Then I would be happy to support their requests for IP addresses. But if they are not going to share their network then there is nothing special and they must buy service on the open market. I really do want DENIC to build their anycast network. But I want them to share it so that all the other important TLDs don't have to build their own separate networks all doing the same thing as DENIC. In fact, now that DENIC is selling resilient domain name hosting around the world, I would be interested in having them host my second level domains as well. > So putting up the anycast servers somewhere where half of the internet > might not see them is not useful. For maximum resiliency (against > DoS and outages), one wants to spread the anycast servers over as many > different (!) networks as possible. And this cannot be done without > a dedicated prefix for it. I agree with you Gert but this is such a good idea that every TLD will want to do the same. You need to either outsource this to a company that specializes in anycast hosting or you need to separate DENIC into a hosting network business and the .DE name registry business. --Michael Dillon From fw at deneb.enyo.de Wed Nov 16 19:35:52 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Nov 2005 19:35:52 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051112074323.GL69925@Space.Net> (Gert Doering's message of "Sat, 12 Nov 2005 08:43:23 +0100") References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> Message-ID: <87ek5gv3sn.fsf@mid.deneb.enyo.de> * Gert Doering: >> Gert, you can configure 1000 anycast servers, all with the same IP address, >> in your own network no matter how small/large your network is. > > That's the point. DENIC isn't doing this for themselves. They do this > for *you* (and for me, and even for Randy). >From a technical perspective, there is no reason to give DENIC special treatment. I would even say that DENIC (or even DNS) is merely a red herring. Has it already been decided that it's a good idea to port the IPv4 anycasting scheme to IPv6? Wouldn't it be better to start over with something which is more sound from a technical perspective? Just because addressing tweaks can solve a perceived problem, it doesn't follow that a solution based on addressing is the best one. This might be simply one of those "IPv6 will really take off when you do X" things. But given that IPv6 among DNS servers is rather widespread (in relative terms, of course), I'm not sure if this move is really necessary. From fw at deneb.enyo.de Wed Nov 16 19:44:48 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Nov 2005 19:44:48 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43767AF1.4000302@oslo.net> (Hans Petter Holen's message of "Sun, 13 Nov 2005 00:29:53 +0100") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> Message-ID: <877jb8v3dr.fsf@mid.deneb.enyo.de> * Hans Petter Holen: > What if I want to plan for more disasters than that ? Like MCI going out > of business? Or operator error destroys the zone beyond easy recovery. If DNS operators really cared about the availability of their data, they would allow the general public to mirror it. However, some of them seem to think that such a precaution against disaster would negatively impact their current business model. From fw at deneb.enyo.de Wed Nov 16 19:55:56 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Nov 2005 19:55:56 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43775E10.3020604@cc.univie.ac.at> (Wilfried Woeber's message of "Sun, 13 Nov 2005 15:38:56 +0000") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> Message-ID: <87y83otoar.fsf@mid.deneb.enyo.de> * Wilfried Woeber: >>From that perspective I seem to see 2 aspects in the recent discussion: > > - you shall not receive address space for builing a service, you are to > buy that from some "big-folk". > > This is an intersting point of view, and taken to the extreme will > make us end up with a _very small_ number of _very big_ entities. > > Traditionally these things were called monopolies. Nothing I would be > too happy to see coming back ;-) Oligopolies is the term, I think. IPv6 addressing policy seems to be geared towards that. We know from the IPv4 experience that 20,000+ indepedent entities in the global routing table can be handled easily. So why not try to duplicate this success? > - there has been th discussion regarding "anycast" but isnt this just > a special(?) case of th PI-topic? It depends on the PI criteria. If slots in the global routing tables are kept in short supply *and* you get at most one if you aren't an ISP *and* you need to do IPv6 anycast, you might have a problem because you need two globally visible prefixes (one for your production network, one for anycast). But I think you are right that it makes sense to resolve the PI first, either negatively or positively. From Mohsen.Souissi at nic.fr Thu Nov 17 11:50:32 2005 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Thu, 17 Nov 2005 11:50:32 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <87y83otoar.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> Message-ID: <20051117105032.GO99793@kerkenna.nic.fr> Florian & all, On 16 Nov, Florian Weimer wrote: [...] | It depends on the PI criteria. If slots in the global routing tables | are kept in short supply *and* you get at most one if you aren't an | ISP *and* you need to do IPv6 anycast, you might have a problem | because you need two globally visible prefixes (one for your | production network, one for anycast). | | But I think you are right that it makes sense to resolve the PI first, | either negatively or positively. ==> This is just amazing! I have been follwing this topic for more than two years and I have the feeling that we are making again and again the history! I remember that when the IPv6 "PI" issue was first raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that time), the answer was "PI is out of scope of this wg". Then came the first draft proposel of Andreas in the AP wg asking for a /32 for ccTLDs wishing to deploy anycast. At that time, the wg said "let's not talk about "PI", which is still out of scope of this wg. Let's rather talk about specific needs of TLDs wishing to do anycast and see what we can do for them in termes of (micro-)allocation." Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem... If that's to be done and while we ar at it, we can see again how RIPE is the only RIR not considering TLD networks as "critical infrastructure" while an appropriate policy has been already implemented in all other existing RIRs for a long while (please revisit the comparative matrix of RIR policies at http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and see how RIPE is lagging behind in this matter. Some of this mailing-list member would say: "that was our choice!"). Isn't it a European speciality to discuss over again and again issues without coming to any solution? Some people on RIPE mailing-lists are now used to coming after a consensus is almost reached and try to break everything just for the sake of building CLEAN solutions... (cc)TLD need an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop. To recall only a few of the arguments for deploying anycast for a TLD, I would say: Redundance & Resilience against DDoS attacks, better global time response, a greater flexibility in adding and removing name servers without notifying IANA! Btw, I'd like to remind some of this mailing-list readers that the request of DENIC is not isolated since AFNIC asked even before Adndreas first draft for a constency between all RIRs in the way IPv6 allocation were made for "critical infrastructure". AFNIC has then strongly supported Andreas proposal from the beginning and hoped that the solution would come rapidly because AFNIC is still needing such a solution to start deploying anycast in IPv4 AND in IPv6 in a consistent way! I still hope this debate will lead to a concrete solution within the coming 3 years! Good luck :-) Mohsen. From Michael.Dillon at btradianz.com Thu Nov 17 12:01:08 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 17 Nov 2005 11:01:08 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051117105032.GO99793@kerkenna.nic.fr> Message-ID: > Btw, I'd like to remind some of this mailing-list readers that the > request of DENIC is not isolated since AFNIC asked even before > Adndreas first draft for a constency between all RIRs in the way IPv6 > allocation were made for "critical infrastructure". AFNIC has then > strongly supported Andreas proposal from the beginning and hoped that > the solution would come rapidly because AFNIC is still needing such a > solution to start deploying anycast in IPv4 AND in IPv6 in a > consistent way! This reinforces the position that RIPE should not give out address allocations to TLD operators to use for their anycast deployments. There is nothing special about DENIC. If AFNIC and DENIC form a consortium to operate anycast deployments for TLD operators, then that is a different question entirely. I think it would be right for RIPE to allocate addresses to such a consortium just like we now do with other network operators. --Michael Dillon From jeroen at unfix.org Thu Nov 17 12:26:40 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 Nov 2005 12:26:40 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051117105032.GO99793@kerkenna.nic.fr> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> Message-ID: <437C68F0.7080709@unfix.org> Mohsen Souissi wrote: > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... > (cc)TLD need an allocation (whether it is a /32 or whatever "routable > prefix") because they need to do anycast, full stop. "example.net DNS servers needs an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop." What makes .de more important then example.net DNS servers? I am quite sure that a large part of the world can live perfectly without complete *.de (especially older french people :) but would hate it when google.com (they have already a /32) or ebay.com or say cnn.com (the latter who don't have an allocation yet), are not reachable. These kind of sites also require what you want with 'anycast', a server as close as possible to the enduser for resiliency, latency, DDoS etc... For that matter .com/.net/.org don't have it (yet) either. My points for this, which are mostly also reflected in the proposal: - Special policy only for accredited ccTLD's - Give them a /32 (bigger is only filtering nightmare already) (in another message) Michael Dillon wrote: > If AFNIC and DENIC form a consortium to operate anycast > deployments for TLD operators, then that is a different > question entirely. I think it would be right for RIPE to > allocate addresses to such a consortium just like we now > do with other network operators. You mean clustering up all ccTLD's into 1 prefix? Then why not have a single /32 with a caching recursive DNS server which answers to all queries, see section 4 of: http://unfix.org/~jeroen/archive/drafts/draft-massar-dnsop-service-00.txt But proposing that gets one into 4 holy wars I understood, especially the 'anycast' part seems to be very hurting to a number of people... Note also that clustering them together causes loss of diversity. Thus a /32 per ccTLD seems appropriate here. > I still hope this debate will lead to a concrete solution within the > coming 3 years! Only 3? :) If you really want to get over all of this use the current policy: just define DENIC and anything else as being an LIR (just pay some cash), providing end connectivity to 200+ *planned* sites. Those 200 sites consist out of: - 13 /48's for the anycasted PoPs - 1 /48 for the main office - X /48's for branch offices. - 100+ VPN connections to endsites (for management, employee 'dailin' etc). Done. Please read through: http://www.sixxs.net/tools/grh/dfp/all/ and see what kind of organisations have already got an allocation. Then go over to your favourite colo facility and see what equipment they have. I am quite sure that quite many don't have a lot of equipment (or customers). But they have planned it... and back to everybodies normal schedule.... 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 Thu Nov 17 12:43:21 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 17 Nov 2005 11:43:21 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437C68F0.7080709@unfix.org> Message-ID: > Note also that clustering them together causes loss of diversity. > Thus a /32 per ccTLD seems appropriate here. I didn't suggest clustering all TLD servers together. I suggested that two TLD server operators could cooperate in operating a joint anycast deployment and offer the use of this to other TLD operators. I expect that some other organizations will see this as a business opportunity and will also operate separate anycast deployments. Then, TLDs which are concerned about diversity will use two or more of these anycast network operators. I believe that a network operator should be able to justify a portable prefix of normal size and an AS number. But I don't think that an end user like DENIC should be able to claim that they are "special" and get the same address prefix. I also don't believe there should be any microallocations at all. > If you really want to get over all of this use the current policy: just > define DENIC and anything else as being an LIR (just pay some cash), > providing end connectivity to 200+ *planned* sites. Combine AFNIC's servers and a couple of other TLDs and you will easily meet that number of anycasted DNS servers. --Michael Dillon From Karsten.Koepp at lambdanet.net Thu Nov 17 13:36:08 2005 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Thu, 17 Nov 2005 13:36:08 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else? Message-ID: <39F27E3F569FD4119EF200508BAF85B9067A6C8C@CCGNT30> Hi all, I also followed the discussion, not stepping in here because of no background in TLD operations. Getting a bit frustrated as I see NO movement here. Unlike others, I do see dns being _critical_ to the infrastructure. No other protocol is that much subject of political discussions. As an operator being dependent on TLD operations I want to see a stable operations of the dns tree. Consequently I support giving the TLD operators the tools they need to make it a stable service. I have read an _expressed need_ of the tld community for anycast where I have not seen any constructive proposal against. Hence I have to ACCEPT that large TLDs need it. It brings us no step further towards a stable dns chain if we deny this. What is the impact onto my network if I accept to grant special resources to this need? I can see hardly any besides at most 200 prefixes polluting the DFZ. I can question whether the anycast allocations should be /32 or /48 or something else. It doesn't make a difference in terms of resources stressing my network provided I have a finite number of objects here. Operationally I believe /32 assignments are more stable, so I tend handing out /32 to TLD operators. Current policy does not allow to allocate routeable blocks to TLDs, so we have to change the policy. Before you start flaming I do not regard this opening the flooding gates, as I don't see the flood. TLD operators are being defined as critical infrastructure. It can be decided case by case to allow further infrastructure - by the RIPE members, but I haven't seen such case yet. Let it be xyz.com, have they ever claimed a need for themselves? regards Karsten > -----Original Message----- > From: Mohsen Souissi [mailto:Mohsen.Souissi at nic.fr] > Sent: Thursday, November 17, 2005 11:51 AM > To: Florian Weimer > Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 micro > allocation or > something else? > > > Florian & all, > > On 16 Nov, Florian Weimer wrote: > [...] > | It depends on the PI criteria. If slots in the global > routing tables > | are kept in short supply *and* you get at most one if you aren't an > | ISP *and* you need to do IPv6 anycast, you might have a problem > | because you need two globally visible prefixes (one for your > | production network, one for anycast). > | > | But I think you are right that it makes sense to resolve > the PI first, > | either negatively or positively. > > ==> This is just amazing! I have been follwing this topic for more > than two years and I have the feeling that we are making again and > again the history! I remember that when the IPv6 "PI" issue was first > raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that > time), the answer was "PI is out of scope of this wg". Then came the > first draft proposel of Andreas in the AP wg asking for a /32 for > ccTLDs wishing to deploy anycast. At that time, the wg said "let's not > talk about "PI", which is still out of scope of this wg. Let's rather > talk about specific needs of TLDs wishing to do anycast and see what > we can do for them in termes of (micro-)allocation." > > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... > > If that's to be done and while we ar at it, we can see again how RIPE > is the only RIR not considering TLD networks as "critical > infrastructure" while an appropriate policy has been already > implemented in all other existing RIRs for a long while (please > revisit the comparative matrix of RIR policies at > http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and > see how RIPE is lagging behind in this matter. Some of this > mailing-list member would say: "that was our choice!"). Isn't it a > European speciality to discuss over again and again issues without > coming to any solution? Some people on RIPE mailing-lists are now > used to coming after a consensus is almost reached and try to break > everything just for the sake of building CLEAN solutions... > > (cc)TLD need an allocation (whether it is a /32 or whatever "routable > prefix") because they need to do anycast, full stop. To recall only a > few of the arguments for deploying anycast for a TLD, I would say: > Redundance & Resilience against DDoS attacks, better global time > response, a greater flexibility in adding and removing name servers > without notifying IANA! > > Btw, I'd like to remind some of this mailing-list readers that the > request of DENIC is not isolated since AFNIC asked even before > Adndreas first draft for a constency between all RIRs in the way IPv6 > allocation were made for "critical infrastructure". AFNIC has then > strongly supported Andreas proposal from the beginning and hoped that > the solution would come rapidly because AFNIC is still needing such a > solution to start deploying anycast in IPv4 AND in IPv6 in a > consistent way! > > I still hope this debate will lead to a concrete solution within the > coming 3 years! > > Good luck :-) > > Mohsen. > > From randy at psg.com Thu Nov 17 15:18:08 2005 From: randy at psg.com (Randy Bush) Date: Thu, 17 Nov 2005 06:18:08 -0800 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else? References: <39F27E3F569FD4119EF200508BAF85B9067A6C8C@CCGNT30> Message-ID: <17276.37152.757181.203339@roam.psg.com> > Unlike others, I do see dns being _critical_ to the infrastructure. i think most folk think of dns as critical infrastructure > No other protocol is that much subject of political discussions. and this says what about the dns, other than the need to taks a shower often? > As an operator being dependent on TLD operations I want to see > a stable operations of the dns tree. as am i. as do i. > Consequently I support giving the TLD operators the tools they > need to make it a stable service. yes. and how do you go from here to special address allocations? do we also need special computers? special electricity? special racks? randy From Michael.Dillon at btradianz.com Thu Nov 17 16:12:11 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 17 Nov 2005 15:12:11 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else? In-Reply-To: <17276.37152.757181.203339@roam.psg.com> Message-ID: > > Consequently I support giving the TLD operators the tools they > > need to make it a stable service. > > yes. and how do you go from here to special address allocations? > do we also need special computers? special electricity? special > racks? I also agree that DNS is part of the Internet's critical infrastructure and that TLD's are more critical than the average end user domain. That is why I am opposed to DENIC's application to change policy and impose a bureaucratic process around building anycast deployments. There is no barrier preventing DENIC and AFNIC and others from deploying global anycast to serve the domains that they host from their TLD registries. Many, many companies in Europe are happily operating hosting facilities that host all sorts of applications using a wide range of protocols including the DNS protocol that is used in DENIC's hosting service. But DENIC's customers should be asking themselves why DENIC is wasting their time in this political process to change RIPE policy instead of building their anycast infrastructure. If they don't move quickly, then someone else will build that anycast infrastructure and both DENIC and AFNIC will be reduced to being customers instead of network operators. As long as they keep running the critical DNS infrastructure I am happy. Whether they outsource the anycast network entirely or participate in building their own, it doesn't matter much. --Michael Dillon From marc.van.selm at nc3a.nato.int Thu Nov 17 17:15:05 2005 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 17 Nov 2005 17:15:05 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 Message-ID: <200511171715.05767.marc.van.selm@nc3a.nato.int> Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this. During RIPE-51 the proposal to remove the rule caught serious objections. I can sympathise with those but I do have an issue that I'd like feedback on. I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations. They operate independently and are like an ISP (and more) for that matter. They are just not selling outside NATO. At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request". Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct. Having said that, I get the feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like: Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48 Note that the numbers are fiction but they are not very unrealistic as we also need to include standby elements that are ready to go (power up, aim dish and run) systems. Although close to the truth, RIPE-NCC would have no way of verifying this and providing a detailed list would bury RIPE-NCC in details that they don't care about and also cannot verify. I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for? Any views? Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From jeroen at unfix.org Thu Nov 17 17:23:25 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 Nov 2005 17:23:25 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <200511171715.05767.marc.van.selm@nc3a.nato.int> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> Message-ID: <437CAE7D.3070700@unfix.org> Marc van Selm wrote: > I am investigating how NATO should acquire IPv6 address space. NATO will use > multiple transmission providers, NATO owned transmission and national > networks. Also transmission contracts will have to be opened for bidding > every few years. That makes requesting IP space from an ISP a non starter. So > we explore the LIR route. Note that NATO has a service provider under its > umbrella that provides service towards the other NATO organisations. This is already good enough. Because the "ISP" is providing connectivity to the other NATO organisations. Done. > At this time it is reasonably hard to specify the 200 /48 that will be given > out for the "IPv6 Initial Allocation Request". The 200 is a *PLAN*. Also, if you have 200 employees and every one is going to connect to your network, then they need 200 /48's. As they are endsites connecting using a VPN tool and these endsites might just have more than 1 device in their network which need to access your site over the VPN. > Having reached about 130 or so > on my list (not finished yet) I can't help wondering why RIPE-NCC should care > about a list of sites that they only a vague clue of what they are and have > no means of verification if the list is correct. They don't care. Having said that, I get the > feeling that the 200 rule only ads admin overhead and has limited actual > power. Now NATO could include a summarised version in the Initial Allocation > and do something like: > > Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) > Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site > = 5x 20x /48 = 100 /48) > Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) > Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = > 70 x /48) > Total: 215x /48 That is PERFECT. > I can't help feeling this rule is written for ISPs but will be counter > productive for NATO and organisations with a very large privately operated > enterprice network. The 200 rule is there to make sure that there will be no entity that is going to request a /32, while they will never even use even a single /48 of hosts. So: Become LIR, pay the fees, fill in the forms and request that /32. 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 jordi.palet at consulintel.es Thu Nov 17 17:26:20 2005 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Nov 2005 17:26:20 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <200511171715.05767.marc.van.selm@nc3a.nato.int> Message-ID: I fully agree, the 200 customers requirement should go away. We are probably the last RIR doing so, funny :-( There are lots of similar examples as the NATO one. It make no sense at all Regards, Jordi > De: Marc van Selm > Organizaci?n: NATO C3 Agency > Responder a: "address-policy-wg-admin at ripe.net" > > Fecha: Thu, 17 Nov 2005 17:15:05 +0100 > Para: > Asunto: [address-policy-wg] 200 customer requirements for IPv6 > > Following up on the discussion during RIPE-51, I have not heard much > discussion on "200 customer requirement for IPv6" rule. So I would like to > hear your views on this. > > During RIPE-51 the proposal to remove the rule caught serious objections. I > can sympathise with those but I do have an issue that I'd like feedback on. > > I am investigating how NATO should acquire IPv6 address space. NATO will use > multiple transmission providers, NATO owned transmission and national > networks. Also transmission contracts will have to be opened for bidding > every few years. That makes requesting IP space from an ISP a non starter. So > we explore the LIR route. Note that NATO has a service provider under its > umbrella that provides service towards the other NATO organisations. They > operate independently and are like an ISP (and more) for that matter. They > are just not selling outside NATO. > > At this time it is reasonably hard to specify the 200 /48 that will be given > out for the "IPv6 Initial Allocation Request". Having reached about 130 or so > on my list (not finished yet) I can't help wondering why RIPE-NCC should care > about a list of sites that they only a vague clue of what they are and have > no means of verification if the list is correct. Having said that, I get the > feeling that the 200 rule only ads admin overhead and has limited actual > power. Now NATO could include a summarised version in the Initial Allocation > and do something like: > > Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) > Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site > = 5x 20x /48 = 100 /48) > Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) > Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = > 70 x /48) > Total: 215x /48 > > Note that the numbers are fiction but they are not very unrealistic as we also > need to include standby elements that are ready to go (power up, aim dish and > run) systems. Although close to the truth, RIPE-NCC would have no way of > verifying this and providing a detailed list would bury RIPE-NCC in details > that they don't care about and also cannot verify. > > I can't help feeling this rule is written for ISPs but will be counter > productive for NATO and organisations with a very large privately operated > enterprice network. I also can't help the feeling that its a paper tiger. So > isn't there another way to achieve the same result as this rule was intended > for? > > Any views? > > Marc > -- > Marc van Selm > NATO C3 Agency > CIS Division > E-mail: marc.van.selm at nc3a.nato.int (PGP capable) > ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From tim.streater at dante.org.uk Thu Nov 17 17:23:54 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 17 Nov 2005 16:23:54 +0000 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <200511171715.05767.marc.van.selm@nc3a.nato.int> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> Message-ID: <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> At 16:15 17/11/2005, Marc van Selm wrote: [NATO scenario] >I can't help feeling this rule is written for ISPs but will be counter >productive for NATO and organisations with a very large privately operated >enterprice network. I also can't help the feeling that its a paper tiger. So >isn't there another way to achieve the same result as this rule was intended >for? > >Any views? It should go. We manage a transit network connecting Middle-eastern and North African national research networks (NRENs). The aim is that this grouping go independent of us at some point and manage everything themselves. I was able to get v4 PI space for this from RIPE, but the 200 rule appears to rule out these guys using v6. Oh well. -- Tim From jeroen at unfix.org Thu Nov 17 18:00:26 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 Nov 2005 18:00:26 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> Message-ID: <437CB72A.9020806@unfix.org> Tim Streater wrote: > It should go. We manage a transit network connecting Middle-eastern > and North African national research networks (NRENs). > The aim is that this grouping go independent of us at some point > and manage everything themselves. So in say 10 years you are not managing it anymore? Most NREN's already have plenty of address space, so why not use that address space? > I was able to get v4 PI space for > this from RIPE, but the 200 rule appears to rule out these guys using v6. Oh well. Do you need a /32 full of address space or do you want PI? If you only need a single /48, then requesting a /32 is quite silly don't you think? And also quite a waste. Do note, that this is nothing against you, but if you get a /32 because you want PI, then a lot of other small organisations (read: individuals) may want one. Constructive part, same style as to the NATO one: - You have 50 PoPs. - You have say 150 employees (both can be a plan, you might fail but hell.. it still is a plan) That is already 200. Become LIR and get it. 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 tim.streater at dante.org.uk Thu Nov 17 18:18:04 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 17 Nov 2005 17:18:04 +0000 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <437CB72A.9020806@unfix.org> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> Message-ID: <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> At 17:00 17/11/2005, Jeroen Massar wrote: >*** PGP Signature Status: good >*** Signer: Jeroen Massar (Invalid) >*** Signed: 17/11/2005 17:00:26 >*** Verified: 17/11/2005 17:08:46 >*** BEGIN PGP VERIFIED MESSAGE *** > >Tim Streater wrote: > >> It should go. We manage a transit network connecting Middle-eastern >> and North African national research networks (NRENs). >> The aim is that this grouping go independent of us at some point >> and manage everything themselves. > >So in say 10 years you are not managing it anymore? Most NREN's already >have plenty of address space, so why not use that address space? We are an LIR and we already have a /32 for the European NREN transit network that we also manage (GEANT). You don't use customer address space to address your transit network. What happens if that customer goes bankrupt or wants the space back or takes their custom elsewhere? And it's intended to be a couple of years, not 10. >> I was able to get v4 PI space for >> this from RIPE, but the 200 rule appears to rule out these guys using >v6. Oh well. > >Do you need a /32 full of address space or do you want PI? >If you only need a single /48, then requesting a /32 is quite silly >don't you think? And also quite a waste. We don't need a /32 obviously. Can we get a /48? And can we get it routed? >Do note, that this is nothing against you, but if you get a /32 because >you want PI, then a lot of other small organisations (read: individuals) >may want one. > >Constructive part, same style as to the NATO one: > - You have 50 PoPs. > - You have say 150 employees > >(both can be a plan, you might fail but hell.. it still is a plan) So you're saying we should lie to RIPE when necessary? Seems to me much better to adjust the policies to fit reality. >That is already 200. Become LIR and get it. See above. -- Tim From quin.collier at bt.com Thu Nov 17 18:48:50 2005 From: quin.collier at bt.com (quin.collier at bt.com) Date: Thu, 17 Nov 2005 17:48:50 -0000 Subject: FW: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 Message-ID: <578B9E49CCB6BC43B160BFB8C8B0E24E1395A556@i2km05-ukbr.domain1.systemhost.net> I can confirm that BT supports the proposal to move to an HD ratio approach for IPv4. Regards, Quin Collier -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Hans Petter Holen Sent: 07 November 2005 18:22 To: address-policy-wg at ripe.net Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Period: HD Ratio for IPv4 Dear WG, At the meeting in Amsterdam I requested participation from the signatories to the ETNO letter. As chair of the wg I would like to understand from the participants of this WG, representing the signatories to the ETNO position - why you have chosen not to participate in the discussion in the Address Policy WG but rather develop this position in another organization. I will not move this proposal to last call before this clarified to the Address Policy working group. Best Regards, Hans Petter Holen Address Policy WG. -------------- next part -------------- An embedded message was scrubbed... From: Subject: [address-policy-wg] ETNO comments on AD ratio for IPv4 addresses allocation Date: Thu, 16 Sep 2004 10:01:01 -0000 Size: 6328 URL: From jeroen at unfix.org Thu Nov 17 19:10:27 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 Nov 2005 19:10:27 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> Message-ID: <437CC793.3000306@unfix.org> Tim Streater wrote: > At 17:00 17/11/2005, Jeroen Massar wrote: >> Tim Streater wrote: >> >>> It should go. We manage a transit network connecting Middle-eastern >>> and North African national research networks (NRENs). >>> The aim is that this grouping go independent of us at some point >>> and manage everything themselves. >> So in say 10 years you are not managing it anymore? Most NREN's already >> have plenty of address space, so why not use that address space? > > We are an LIR and we already have a /32 for the European NREN transit > network that we also manage (GEANT). > You don't use customer address space to address your transit network. Hold on here. *You* are the LIR, have already a /32 and are already using it for management, but won't use it yourself? Or do you mean that you want multiple /32's because you have multiple projects which should actually be separate? If I understand correctly you see your own network GEANT, for which you have the /32 already, as a customer and you expect it to go away? Can you elaborate on this (again, as I recall that this came up before) maybe this time in ASCII or Visio style? That might better illustrate what exact problem you are having and what then the solutions might be. It seems to be a really strange construct, at least doesn't seem to make any sense to me. Could very well be me of course. > What happens if that customer goes bankrupt or wants the space back > or takes their custom elsewhere? And it's intended to be a couple of > years, not 10. Couple, thus 2 or 3? If you only plan to use it for a 'couple' of years, then you can also use other address space from other entities. Doesn't really matter if you change after X years or directly, you already planned to change anyway, thus if they go bankrupt, belly up, zapped to another dimension, you are changing anyway. >>> I was able to get v4 PI space for >>> this from RIPE, but the 200 rule appears to rule out these guys using >> v6. Oh well. >> >> Do you need a /32 full of address space or do you want PI? >> If you only need a single /48, then requesting a /32 is quite silly >> don't you think? And also quite a waste. > > We don't need a /32 obviously. Can we get a /48? And can we get it routed? One can get anything routed. Use ULA to generate your own random prefix and use it. I am quite sure that it will reach quite far. You only want to use it for management (and transit?) for your own network anyway and the ones who participate in your organisations can surely be persuaded to receive the route. >> Do note, that this is nothing against you, but if you get a /32 because >> you want PI, then a lot of other small organisations (read: individuals) >> may want one. >> >> Constructive part, same style as to the NATO one: >> - You have 50 PoPs. >> - You have say 150 employees >> >> (both can be a plan, you might fail but hell.. it still is a plan) > > So you're saying we should lie to RIPE when necessary? Why is that a lie? Unless you actually are a homeuser (which you are not) or some very small ISP who doesn't want customers (which isn't the case either). I really can't see why you can't get address space under the current policy. For that matter: did you ever try? Or even simpler, did you ask RIPE NCC? Instead of just saying "we can't, change the policy" > Seems to me much better to adjust the policies to fit reality. Reality looks more that you want PI space, or actually a slot in the routing tables. As ULA's already provide PI space, they just don't directly give a slot in the routing tables. Sidestep note: one can also use 2002::/16. You will have to run a 6to4 relay then, but this will give you "PI IPv6 space". You can then announce a more specific to your friendly neighbors. People who filter will use 2002::/16 to reach you. 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 tim.streater at dante.org.uk Thu Nov 17 19:27:48 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 17 Nov 2005 18:27:48 +0000 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <437CC793.3000306@unfix.org> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> Message-ID: <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> At 18:10 17/11/2005, Jeroen Massar wrote: >*** PGP Signature Status: good >*** Signer: Jeroen Massar (Invalid) >*** Signed: 17/11/2005 18:10:27 >*** Verified: 17/11/2005 18:10:45 >*** BEGIN PGP VERIFIED MESSAGE *** > >Tim Streater wrote: >> At 17:00 17/11/2005, Jeroen Massar wrote: >>> Tim Streater wrote: >>> >>>> It should go. We manage a transit network connecting Middle-eastern >>>> and North African national research networks (NRENs). >>>> The aim is that this grouping go independent of us at some point >>>> and manage everything themselves. >>> So in say 10 years you are not managing it anymore? Most NREN's already >>> have plenty of address space, so why not use that address space? >> >> We are an LIR and we already have a /32 for the European NREN transit >> network that we also manage (GEANT). >> You don't use customer address space to address your transit network. > >Hold on here. *You* are the LIR, have already a /32 and are already >using it for management, but won't use it yourself? Or do you mean that >you want multiple /32's because you have multiple projects which should >actually be separate? If I understand correctly you see your own network >GEANT, for which you have the /32 already, as a customer and you expect >it to go away? > >Can you elaborate on this (again, as I recall that this came up before) >maybe this time in ASCII or Visio style? That might better illustrate >what exact problem you are having and what then the solutions might be. >It seems to be a really strange construct, at least doesn't seem to make >any sense to me. Could very well be me of course. We have two network that we manage. GEANT, for which we have a /32 for the backbone and which we expect to continue for a long time. The customers on this are the European NRENs, they are all LIRs themselves, so we don't get space from them and they don't get space from us - this is a transit network. Note: we were set up by our customers and are owned by our customers - we have, therefore, a small number of large customers and this base is not expected to expand (unless the EU invades the rest of the world). The other network is one we are *currently* managing, EUMEDCONNECT. It is for the Middle-eastern and North African NRENs. The intention here is that we expect these NRENs to set up their own entity to manage it, and go their own way, in which case we gift them the infrastructure, which in this case has to include the address space. We can do that for v4 as I got PI space for that. Its v6 that is the problem. >> We don't need a /32 obviously. Can we get a /48? And can we get it routed? > >One can get anything routed. Use ULA to generate your own random prefix >and use it. I am quite sure that it will reach quite far. You only want >to use it for management (and transit?) for your own network anyway and >the ones who participate in your organisations can surely be persuaded >to receive the route. This may well suffice. Personally I feel this paranoia about the size of the v6 routing table is misplaced. You got lots of bits, you get lots of routing entries. But that's another story. >> So you're saying we should lie to RIPE when necessary? > >Why is that a lie? Unless you actually are a homeuser (which you are >not) or some very small ISP who doesn't want customers (which isn't the >case either). I really can't see why you can't get address space under >the current policy. For that matter: did you ever try? Or even simpler, >did you ask RIPE NCC? Instead of just saying "we can't, change the policy" Well, it asked for the plan to allocate space to 200 customers or some such (it's a while since I looked at it). We have no such plan and there won't be one. Telling RIPE that I got one is therefore not true. The policy should be expanded to cover the reasonable cases. -- Tim From jorgen at hovland.cx Thu Nov 17 20:03:30 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 17 Nov 2005 20:03:30 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> Message-ID: <001401c5eba9$9c754a60$43eea2d5@jh> ----- Original Message ----- From: "Tim Streater" > We are an LIR and we already have a /32 for the European NREN transit > network that we also manage (GEANT). You don't use customer address space > to address your transit network. What happens if that customer goes > bankrupt or wants the space back or takes their custom elsewhere? And it's > intended to be a couple of years, not 10. > >>> I was able to get v4 PI space for >>> this from RIPE, but the 200 rule appears to rule out these guys using >>v6. Oh well. >> Hi Tim, The 200 rule is for PA. You want/need PI so lets start/continue The PI discussion, not the "I am so special that I need a special PI policy just for my organisation" discussion if anybody is thinking in that direction. Joergen Hovland From pekkas at netcore.fi Thu Nov 17 20:05:22 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 17 Nov 2005 21:05:22 +0200 (EET) Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> Message-ID: On Thu, 17 Nov 2005, Tim Streater wrote: > The other network is one we are *currently* managing, EUMEDCONNECT. > It is for the Middle-eastern and North African NRENs. The intention > here is that we expect these NRENs to set up their own entity to > manage it, and go their own way, in which case we gift them the > infrastructure, which in this case has to include the address space. > We can do that for v4 as I got PI space for that. Its v6 that is the > problem. Did you actually *try* getting a separate /32 for this? RIPE NCC is known to be very reasonable towards transit networks, and I could bet good money you could get an allocation without a hitch. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From narten at us.ibm.com Thu Nov 17 23:32:55 2005 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 17 Nov 2005 17:32:55 -0500 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: Message from Pekka Savola of "Thu, 17 Nov 2005 21:05:22 +0200." Message-ID: <200511172232.jAHMWtdp006752@cichlid.raleigh.ibm.com> > On Thu, 17 Nov 2005, Tim Streater wrote: > > The other network is one we are *currently* managing, EUMEDCONNECT. > > It is for the Middle-eastern and North African NRENs. The intention > > here is that we expect these NRENs to set up their own entity to > > manage it, and go their own way, in which case we gift them the > > infrastructure, which in this case has to include the address space. > > We can do that for v4 as I got PI space for that. Its v6 that is the > > problem. > Did you actually *try* getting a separate /32 for this? > RIPE NCC is known to be very reasonable towards transit networks, and > I could bet good money you could get an allocation without a hitch. I don't think the Right Answer is always to say "did you try and did you get rejected"? I believe the current IPv6 policies are aimed at LIRs that delegate address space to other users/isps/customers (i.e., that is the group the are the main focus). It is not immediately clear to me what the policies are (or should be) for an ISP doing transit. Clearly, the don't need a full /32, since they aren't really assigning (directly, or via delegation) lots of addresses. But shouldn't they be able to get space? Seems like that is a valid policy discussion to have. Thomas From dr at cluenet.de Fri Nov 18 00:31:37 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 18 Nov 2005 00:31:37 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: <200511171715.05767.marc.van.selm@nc3a.nato.int> Message-ID: <20051117233137.GA24229@srv01.cluenet.de> On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote: > There are lots of similar examples as the NATO one. It make no sense > at all Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done. Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done. Too simple, too scary, too much independence again to the endsites, eh? I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often). Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward. My 0.02EUR Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots) -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From oppermann at networx.ch Thu Nov 17 17:33:49 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Thu, 17 Nov 2005 17:33:49 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> Message-ID: <437CB0ED.7C087FE8@networx.ch> Marc, you have just observed the biggest brokeness of the entire IPv6 policy. There are many (thousands in fact) having the same problem as you do. To make IPv6 a (commercial) success there MUST be PI address space to allow for corporations (non-ISPs) to natively multihome and to switch ISPs without renumbering the entire network. Neither problem has been solved yet in the current IPv6 policy or proposals. In its current state the IPv6 policy is a total non-starter. There is NO WAY for large corporate and government entities to put them at the mercy of any single random ISP again. They've learned it the hard way with IPv4 already and go exclusively with PI address space now. NATO is a prime example for this. I'm doing a lot of consulting for large enterprises regarding IP addressing, multihoming and ISP independence. Based on that experience I can say with ABSOLUTE CERTAINTY that with the current policy IPv6 does not NOT get adopted AT ALL in any large corp. To all the nay-sayers and ignorants in the die-hard IPv6 camp I can only recommend that they put yourself into the shoes of a large coporation with 10,000 employees for a day. And then ypu think about how to connect this shop to the Internet in a competitive way. You'll come to the conclusion that with IPv6 you simply can't. -- Andre Marc van Selm wrote: > > Following up on the discussion during RIPE-51, I have not heard much > discussion on "200 customer requirement for IPv6" rule. So I would like to > hear your views on this. > > During RIPE-51 the proposal to remove the rule caught serious objections. I > can sympathise with those but I do have an issue that I'd like feedback on. > > I am investigating how NATO should acquire IPv6 address space. NATO will use > multiple transmission providers, NATO owned transmission and national > networks. Also transmission contracts will have to be opened for bidding > every few years. That makes requesting IP space from an ISP a non starter. So > we explore the LIR route. Note that NATO has a service provider under its > umbrella that provides service towards the other NATO organisations. They > operate independently and are like an ISP (and more) for that matter. They > are just not selling outside NATO. > > At this time it is reasonably hard to specify the 200 /48 that will be given > out for the "IPv6 Initial Allocation Request". Having reached about 130 or so > on my list (not finished yet) I can't help wondering why RIPE-NCC should care > about a list of sites that they only a vague clue of what they are and have > no means of verification if the list is correct. Having said that, I get the > feeling that the 200 rule only ads admin overhead and has limited actual > power. Now NATO could include a summarised version in the Initial Allocation > and do something like: > > Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) > Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site > = 5x 20x /48 = 100 /48) > Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) > Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = > 70 x /48) > Total: 215x /48 > > Note that the numbers are fiction but they are not very unrealistic as we also > need to include standby elements that are ready to go (power up, aim dish and > run) systems. Although close to the truth, RIPE-NCC would have no way of > verifying this and providing a detailed list would bury RIPE-NCC in details > that they don't care about and also cannot verify. > > I can't help feeling this rule is written for ISPs but will be counter > productive for NATO and organisations with a very large privately operated > enterprice network. I also can't help the feeling that its a paper tiger. So > isn't there another way to achieve the same result as this rule was intended > for? > > Any views? > > Marc > -- > Marc van Selm > NATO C3 Agency > CIS Division > E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From marc.van.selm at nc3a.nato.int Fri Nov 18 09:34:28 2005 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Fri, 18 Nov 2005 09:34:28 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <200511171715.05767.marc.van.selm@nc3a.nato.int> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> Message-ID: <200511180934.28392.marc.van.selm@nc3a.nato.int> On Thursday 17 November 2005 17:15, Marc van Selm wrote: > Following up on the discussion during RIPE-51, I have not heard much > discussion on "200 customer requirement for IPv6" rule. So I would like to > hear your views on this. Nice to see this discussion reviving. From what I hear I can draw the following conclusions for NATO (and large enterprices with a private WAN): 1) RIPE-NCC would be happy with a summarised version of our plan and does not care about the details of 200+ /48 assignments. As soon as Leo Vegoda is back from his leave, I'll know for sure if RIPE-NCC will accept it. But I get the feeling they will. 2) The 200-rule, although strongly defended during RIPE-51, remains controversial. I guess another qualifier must be introduced to satisfy both camps. 3) PI IPv6 space seems to be the solution to the large enterprice problem. If the RIR would allocate it directly to the end-customer, orgs like NATO do not have to become a LIR. They just have a block that they "own" and can contract out to an ISP of their choice to route (and rebid the contract every few years or so as the procurement rules require) or route (part of it) via private circuits. I'd say replace the 200-rule with something like the intention to use at least X /48 subnets distributed over Y or more geographical locations while using private WAN infrastructure or more than one ISP. I think that X and Y should be not so large. (To the side, we could accept a smaller block, like a /34, also for now but we all know that growth in the next 10 years is imminent so RIPE-NCC would reserve the whole /32 and probably more anyway.) Anyway, I think something like this would do the same as the 200-rule was intended for while is it not such a straight jacket. Although I think the action to write something about that was on somebody else... What do you all think about this approach? Especially the Nee sayers during RIPE-51 that have been a bit quiet until now. Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From sabt at sabt.net Fri Nov 18 09:38:40 2005 From: sabt at sabt.net (Sebastian Abt) Date: Fri, 18 Nov 2005 09:38:40 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <200511172232.jAHMWtdp006752@cichlid.raleigh.ibm.com> References: <200511172232.jAHMWtdp006752@cichlid.raleigh.ibm.com> Message-ID: <20051118083840.GA665@shiva.sabt.net> Hi, * Thomas Narten wrote: > It is not immediately clear to me what the policies are (or should be) > for an ISP doing transit. Clearly, the don't need a full /32, since > they aren't really assigning (directly, or via delegation) lots of > addresses. But shouldn't they be able to get space? I think one should hand out /32s to transit ISPs even if they don't need as much addresses as others may because that makes deploying sane filters a lot easier. An ISP doing transit has mostly many POPs where it has to address own equipment and customer routers. Following the recommendations on IPv6 addressing one would assign /64s per transfer networks and some /128s per loopback. In order to achieve internal aggregation one would also want to allocate a bigger chunk per POP - following the recommendations, a /48. So you can see that a typically ISP doing transit needs n*/48, with n depending on the numbers of POPs they have. With handing out a /32 one can be sure that there are enough /48s available to cover the ISPs POPs (hence, this ISP will never use more than one routing table slot) and on the other hand there is no additional prefix length one has to make exceptions for when deploying filters. But, is it really a problem for an ISP doing transit to get an own allocation? regards, sebstian -- SABT-RIPE PGPKEY-D008DA9C From jorgen at hovland.cx Fri Nov 18 09:42:36 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 18 Nov 2005 09:42:36 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <437CB0ED.7C087FE8@networx.ch> Message-ID: <200511180842.jAI8ggpQ022602@mail03.hipercom.no> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Andre Oppermann >There is NO WAY for large corporate and government entities to put them >at the mercy of any single random ISP again. They've learned it the >hard way with IPv4 already and go exclusively with PI address space now. > >NATO is a prime example for this. I'm doing a lot of consulting for >large enterprises regarding IP addressing, multihoming and ISP >independence. >Based on that experience I can say with ABSOLUTE CERTAINTY that with >the current policy IPv6 does not NOT get adopted AT ALL in any large corp. I am not going to say you are incorrect because you aren't, but speaking as a LIR and internet service provider you need to have a look at the possibilities: We have customers of so high importance, "NATO style", that we need multihomed lines to them; multihomed in the way that they have multiple lines but only to us, but if one goes down then the others are still up using HSRP, BGP etc. So should these customers perhaps get PI instead because they sooner or later will as you say "learn" that we cannot provide a good service? I have also configured redundant lines for other companies to other ISPs than the one I work for where these lines only go to a single ISP. I have not received any indication of that they wanted PI instead and multiple ISPs, nor did I suggest that they should get PI so we could sell them a line too because I did not see the reason for it. Nobody here is thinking about bankruptcy anyway. I don't really have any valid arguments for or against PI. I am just telling some facts of what some non-PI holders do today. Joergen Hovland From jeroen at unfix.org Fri Nov 18 10:52:05 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 18 Nov 2005 10:52:05 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <437CB0ED.7C087FE8@networx.ch> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> Message-ID: <437DA445.6000507@unfix.org> Andre Oppermann wrote: > There is NO WAY for large corporate and government entities to put them > at the mercy of any single random ISP again. They've learned it the > hard way with IPv4 already and go exclusively with PI address space now. Have you ever taken a look at the list of companies that already have an IPv6 allocation??? FYI: Check http://www.sixxs.net/tools/grh/dfp/all/ There seem to be quite a large number of 'corporations' which don't typically fit the ISP bill according to many people. Again: Fill in the forms and go to RIPE/ARIN/LACNIC/AFRINIC/APNIC. If you are really too small, that is you have at most 10 sites, then you simply are too small. I still have not heared anybody getting rejected by RIPE, except for some home users wanting /32's over DSL and other silly stories. 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 EricS at t-com.net Fri Nov 18 10:46:58 2005 From: EricS at t-com.net (Erics) Date: Fri, 18 Nov 2005 10:46:58 +0100 Subject: [address-policy-wg] Fwd: 2005-01 One Week to End of Discussion Pe riod: HD Ratio for IPv4 Message-ID: <2EFC029342DA73419752CF1ADFA55479200E4B@S4DE9JSAAHY.nord.t-com.de> Hi all, i confirm that Deutsche Telekom still supports the FT proposal to establish the IPv4-HD-Ratio, because this is a good instrument for LIRs to manage the demand of address space. Especially in view of their internal topologies. kind regards Eric Schmidt - for LIR de.telekom From oppermann at networx.ch Fri Nov 18 11:46:55 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Fri, 18 Nov 2005 11:46:55 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> Message-ID: <437DB11F.FC988374@networx.ch> Jeroen Massar wrote: > > Andre Oppermann wrote: > > > There is NO WAY for large corporate and government entities to put them > > at the mercy of any single random ISP again. They've learned it the > > hard way with IPv4 already and go exclusively with PI address space now. > > Have you ever taken a look at the list of companies that already have an > IPv6 allocation??? > > FYI: Check http://www.sixxs.net/tools/grh/dfp/all/ > > There seem to be quite a large number of 'corporations' which don't > typically fit the ISP bill according to many people. Sorry, I've gone through the list and looked for familiar non-ISP names in the RIPE region and especially Germany/Switzerland. I haven't found any smoking gun with the exception of CH-KSZ-20050103 which clearly is not even remotely an ISP. For the APNIC region I don't see any obvious non-ISP entities but then I'm not familiar with that region. In the ARIN region I can find some non-ISP entities but in no way a majority. Most of the time they are a corp and an ISP (Microsoft & MSN for example). To summarize: From a coursory examination of the IPv6 allocation table more than 95% appear to be bona fide ISP allocations without having bent the rules. My feeling is the number is even closer to 99% than 95%. > Again: Fill in the forms and go to RIPE/ARIN/LACNIC/AFRINIC/APNIC. That the problem, I can't. I can't fill out a PI request for them and send it under my LIR name to RIPE. My friendly mega-corp customer would have to be become a LIR themselfes. While that is not that much of a problem they don't fulfill the 200 external customer requirement. They don't have any external customers. On top of it they are not the least bit interested in becoming a LIR with all the associated procedures and everything. They don't go to LIR training courses. It just makes the life miserable for them and the poor RIPE hostmaster who have to deal with their address requests. While I'm glad to consult with mega-corp it's not the way it should be. The IPv4 PI way was better dealing with this type of situation. > If you are really too small, that is you have at most 10 sites, then you > simply are too small. This just rules out getting a /32. It should not rule out getting the ability to properly multihome or to be ISP independent. > I still have not heared anybody getting rejected by RIPE, except for > some home users wanting /32's over DSL and other silly stories. I'd chances are high that you don't hear from them is because they are not ISPs and thus don't have any connections to (our) ISP community. -- Andre From slz at baycix.de Fri Nov 18 12:33:01 2005 From: slz at baycix.de (Sascha Lenz) Date: Fri, 18 Nov 2005 12:33:01 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <20051117233137.GA24229@srv01.cluenet.de> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> Message-ID: <437DBBED.1080605@baycix.de> Hi, Daniel Roesen wrote: > On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote: >>There are lots of similar examples as the NATO one. It make no sense >>at all > > Not issueing PI for multihomed entities makes no sense at all, in face > of the complete lack of a full replacement. I'm still waiting for the > heads to come out of the sand, but I'm waiting since long and don't see > _any_ light at the end of the tunnel (don't anybody dare to say "shim6" > if he/she doesn't want to disqualify her/himself immediately). The folks > all having their own /32 already allocated to them and trying to limit > independent address space to "service providers" (or those who manage to > pretend being it, which seems to be easy) are still arguing for "not for > them!" paradigm - easy position with having their own dishes already > done. ok, *handraise* That's not entirely true - while i have "my" /32, i'm still arguing against this current no-PI situation every this and then (i stopped getting involed in _every_ IPv6-PI-related flamewa^Wthread long ago though...) But indeed, that's still the main problem, that people don't get their head out of the sand, largely due to just not seeing this problem as an issue for themselves. > Until we have a clear full replacement (that means a solution which does > NOT ignore real requirements like shim6 does) there should be a very > simple PI policy which issues a /48 or whatever to end sites at a > nominal small fee, paid directly to the RIR. An initial setup fee and a > yearly renewal fee, paid by credit card or something equally simple. > No payment => assignment withdrawn. The initial fee covering the cost of > evaluation of the request, doing the assignment and setting up the > billing account and DNS reverse. The yearly fee covering the maintenance > of the entries in the database and DNS rev NS RRset and the yearly > recurring fee invoicing/billing. Done. > > Too simple, too scary, too much independence again to the endsites, eh? I think, the main argument against IPv6-PI _still_ is the routing table size, contradicting any reasonable predictions nowerdays (IMHO!). At least that was my own argument against(!) PI in first place, but times have changed since the last millenium. In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then. I can't even see any solution rising in the FAR future, so the only way to keep IPv6 from being completely useless is, go for allowing PI Space for organisations who really want that geniune kind of multihoming and are sure they don't want any workaround solution. A setup+renewal fee does not do much against the routing table size or so, but at least should stop having the IPv4-situation with swamp space(s) and unused, unowned or "joke" Prefixes floating in the databases. I wouldn't like to have anyone to get a Prefix without reasonable need just for the fun of it, like with el-chepo Domain-Names and Hostname ect.. One should know what he does. Of course the issuing organisation should point to alternative solutions and have the requesting one to check out on them if they might be sufficent for their needs (the famous "Did you consider using RfC1918?"-alike-question in the request form should do it with some pointers to good FAQs on alternatives). > I think it's ridiculous to have folks become LIR (and pretend/lie being > ISPish) just to get the PI space they need and having them pay the same > money every *real* LIR (you remember what LIR means? Local Internet > REGISTRY) which happens to open tickets with the hostmasters every now > and then (or much more often). ACK. That's ridiculous. Additionaly, some might not NEED a /32 and don't want to pay for services they don't need (Registry servies, voting at RIPE-meetings, Training Courses... whatver) > Setting aside my disbelieve in the FUD about the scalability problem of > real BGP multihoming (noone yet has shown that the relative amount of > multihomers does or will explode), I'm quite sure that we'd need a real > locator/ID split which is NOT shim6 but something going farther than > that. And we won't have it soon, if at all for IPv6. But keeping on > ignoring user's needs for further years and waiting for the magically > appearing 100% ideal solution is not the way forward. Well, if i say "there is no scalability" problem, that would be considered ignorant by most people, so i don't do that now. But i can't see any problems with BGP routing table size either, it will be significantly smaller than in the IPv4 world by design (one - or few - prefixes per AS), and even when it's growing again from PI-prefixes, probably beyond the current IPv4 table size, what's the problem? Nowerdays routers actually can handle that with >=1GB RAM and fast ASICs. ... and it will take YEARS if at all to raise above nowerdays size. Now let alone the fact that you need to carry on with the IPv4 table for decades anyways, so no relief in sight for the routers... But i'm not saying, there won't be a problem in 50years. > My 0.02EUR I add another 0.02EUR > Regards, > Daniel (having renumbered his IPv6 network already three times > completely and hoping not having to do it a fourth time anytime soon, > and not being able to properly multihome like I can do in IPv4 because > I'm not a commercial ISP, nor can afford the thousands of EUR for LIR > which usually finance MUCH more than just a one-time PI assignment > and some DB slots) > ...i rather invest in redundant Uplinks and routers than in becoming LIR for no apparent reason (i.e. not ASSIGNING Address space as primary purpose), hence i currently go for IPv4-PI for my non-profit organisation(s), utilizing a /40 Suballocation in the IPv6 world from "my" (commercial) LIR. Better than nothing but i'd prefer a completely independant IPv6-PI space and someone doing something against this /32-/35-filter-madness. "My" LIR is not very active in the ISP business lately, and i don't want to know how to deal with a CLOSE of the LIR with my more private, non-profit Address Space either. Am i allowed to keep the Suballocation when RIPE reclaims the LIR's /32? Can i announce the whole /32 when i can't reach some locations with the /40 Suballocation announcement? Can i have the whole /32 for free then not being a LIR? Do i ultimately have to renumber, too? How often? How do i maintain my multihoming properly? ...and so on...(NOTE: rethorical questions, i know the current procedures on the paper) Idependency is one of the basic things in the internet, i don't like people who want to tell me how much independency i need. I know that best for myself. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From dr at cluenet.de Fri Nov 18 13:58:36 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 18 Nov 2005 13:58:36 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <437DA445.6000507@unfix.org> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> Message-ID: <20051118125836.GA1109@srv01.cluenet.de> On Fri, Nov 18, 2005 at 10:52:05AM +0100, Jeroen Massar wrote: > If you are really too small, that is you have at most 10 sites, then you > simply are too small. Who are you to decide who is too small to be allowed independence? Who are you to decide that size is the determining factor for that? /me goes looking wether human rights are dependent on body size. [and before anyone starts argueing that technical and economical independence from their ISP(s) are not a human right: you know what an analogy is?] Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From marc.van.selm at nc3a.nato.int Fri Nov 18 14:38:18 2005 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Fri, 18 Nov 2005 14:38:18 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <200511180842.jAI8ggpQ022602@mail03.hipercom.no> References: <200511180842.jAI8ggpQ022602@mail03.hipercom.no> Message-ID: <200511181438.18745.marc.van.selm@nc3a.nato.int> On Friday 18 November 2005 09:42, J?rgen Hovland wrote: [...] > We have customers of so high importance, "NATO style", that we need > multihomed lines to them; multihomed in the way that they have multiple > lines but only to us, but if one goes down then the others are still up > using HSRP, BGP etc. So should these customers perhaps get PI instead > because they sooner or later will as you say "learn" that we cannot provide > a good service? Joergen, yes that are connectivity resilience issues with a strong relation to the ISP. You probably do not need PI for that. What I'm talking about is 2 or 3 providers that provide worldwide service between a large number of locations. Contracts are rebid with regular intervals (is required). Individual circuits are can be provided by local providers or national networks and NATO owned circuits. In other words, a true multi provider environment. We are not speaking about internet service but transmission services for enterprice VPNs. [...] > Joergen Hovland -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From narten at us.ibm.com Fri Nov 18 15:16:42 2005 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Nov 2005 09:16:42 -0500 Subject: [address-policy-wg] Re: [ipv6-wg] Re: 200 customer requirements for IPv6 In-Reply-To: Message from Daniel Roesen of "Fri, 18 Nov 2005 00:31:37 +0100." <20051117233137.GA24229@srv01.cluenet.de> Message-ID: <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> Daniel Roesen writes: > The folks all having their own /32 already allocated to them and > trying to limit independent address space to "service providers" (or > those who manage to pretend being it, which seems to be easy) are > still arguing for "not for them!" paradigm - easy position with > having their own dishes already done. With all due respect, these sorts of comments are not helpful. They imply bad motivations on some, that IMO, are simply false. There are (IMO) valid reasons for not giving out /32s to everyone. The original (and still compelling, IMO) rational behind the current policy is to ensure good aggregation for the long term, in order to keep the number of distinct prefixes in the DFZ manageable. Hence, the current policy is oriented not towards _all_ ISPs, but those who will (hopefully) have _many_ customers that they assign addresses too. That is, they aggregate addresses for _many_ customers. That is where the "plan for 200 customers" wording originally came from. The presumption is that an ISP/LIR that realistically expects to have 200 customers will be aggregating _many_ customer addresses. If an ISP will have (say) only 100 customers long term, its not at all clear that they will be aggregating significant amounts of address space. Note, I'm not defending the the "200 customer" rule per se; I understand that it is viewed as problematic. But I think the motivation that led to it is still valid, and when folk say "get rid of this requirement," I object to "forgetting" about the original concern when coming up with a replacement policy. > Until we have a clear full replacement (that means a solution which does > NOT ignore real requirements like shim6 does) there should be a very > simple PI policy which issues a /48 or whatever to end sites at a > nominal small fee, paid directly to the RIR. An initial setup fee and a > yearly renewal fee, paid by credit card or something equally simple. > No payment => assignment withdrawn. The initial fee covering the cost of > evaluation of the request, doing the assignment and setting up the > billing account and DNS reverse. The yearly fee covering the maintenance > of the entries in the database and DNS rev NS RRset and the yearly > recurring fee invoicing/billing. Done. Note that ARIN has been and continues to have discussions about how to give out PI space to end sites, but in a way that doesn't explode the routing tables going forward. I think there is (very strong) support for the idea of giving out more PI space, the difficulty has been in coming up with details that people are comfortable won't explode the routing tables going forward. I.e., that in five years we look back and say "oops, we should not have done that, now what do we do" > Setting aside my disbelieve in the FUD about the scalability problem of > real BGP multihoming (noone yet has shown that the relative amount of > multihomers does or will explode), Um, do the math. How many end sites do you think will want to multihome ten years from now? Can you honestly/realistically say it won't be a million? Can the routing infrastructure handle that? (Enough people say "not sure" that IMO it would be foolish to just assume we can do this). Thomas From narten at us.ibm.com Fri Nov 18 15:17:32 2005 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Nov 2005 09:17:32 -0500 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: Message from Andre Oppermann of "Thu, 17 Nov 2005 17:33:49 +0100." <437CB0ED.7C087FE8@networx.ch> Message-ID: <200511181417.jAIEHWac013123@cichlid.raleigh.ibm.com> > To all the nay-sayers and ignorants in the die-hard IPv6 camp I can only > recommend that they put yourself into the shoes of a large coporation > with 10,000 employees for a day. How many 10K employee organizations exist in the world today (or in ten years)? How many routing prefixes would be required in the DFZ to support this? Can the routing infrastructure handle that? If there were consensus that the answer to the above questions was "yes, it's manageable", I'm sure folk would support a modified policy to that effect in a heartbeat. But in the absence of some real data showing the implication of loosening the policy to allow the above, many (myself include) will be very concerned about the consequences of doing this. Thomas From Michael.Dillon at btradianz.com Fri Nov 18 15:29:51 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 18 Nov 2005 14:29:51 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> Message-ID: > Note that ARIN has been and continues to have discussions about how to > give out PI space to end sites, but in a way that doesn't explode the > routing tables going forward. I think there is (very strong) support > for the idea of giving out more PI space, the difficulty has been in > coming up with details that people are comfortable won't explode the > routing tables going forward. I.e., that in five years we look back > and say "oops, we should not have done that, now what do we do" On the ARIN Public Policy mailing list, I have suggested that we open up another chunk of the IPv6 address space to use for geotopological addresses that will enable aggregation at the city level and allow small and mid-size companies to multihome using BGP without adding to the global routing table. If these companies are using geotopological addresses then their detailled routes are only visible inside one city. In the rest of the world there is only a single city prefix, or, if we can create a second regional level that groups cities within a continent, then there would be even fewer routes visible globally. This reduces pressure on the global routing table so that people who cannot feasibly use geotopological addresses have more room to work with. If you go to the ARIN site and look at the PPML archives for November sorted by author, http://lists.arin.net/pipermail/ppml/2005-November/author.html then you can read the 11 messages that I posted, describing geotopological addressing and answering various questions about it. Feel free to continue the discussion on address-policy-wg at ripe.net if you wish. It doesn't really belong on the ipv6-wg list because it is a question of policy whether or not to allocate these addresses and which allocation rules to use. --Michael Dillon From peter.juul at uni-c.dk Fri Nov 18 15:40:11 2005 From: peter.juul at uni-c.dk (Peter B. Juul) Date: Fri, 18 Nov 2005 15:40:11 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> References: <20051117233137.GA24229@srv01.cluenet.de> <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> Message-ID: <20051118144010.GS6829@uni-c.dk> On Fri, Nov 18, 2005 at 09:16:42AM -0500, Thomas Narten wrote: > The original (and still compelling, IMO) rational behind the current > policy is to ensure good aggregation for the long term, in order to > keep the number of distinct prefixes in the DFZ manageable. Hence, the > current policy is oriented not towards _all_ ISPs, but those who will > (hopefully) have _many_ customers that they assign addresses too. That > is, they aggregate addresses for _many_ customers. And then we can discuss the definition of "many" for hours. I "do" the backbone at the danish NREN. We have no upstream provider from whom to ask for IP addresses and we almost completely employ two /16s and one /17 of IPv4 space. There's a certain pressure on NRENs to get going on IPv6, we were involved in the EU 6net project and now run IPv6 on the backbone, exerting what little pressure we can to get services running around the country. We have a bit more than 100 institutions. About six of those are major universities with a large number of institutes. We planned (and still plan) to get everybody running IPv6 and by setting a policy that every institute should have a /48, we were able to claim without exactly lying that we were planning at least 200 /48s. Of course, what makes sense is for a university to get a /48 and then let them subdivide that for institutes, but that would effectively make Forskningsnettet (the danish research network) incapable of obtaining IPv6 at all. Executive summary: I believe that the 200 customers demand halts IPv6 development rather than help it. If we really wanted to be cautious, we should forget about /32s and go /36 or /40 instead. A /40 would be plenty for Forskningsnettet. Now we have /32 and a completely absurd subassignment policy instead. Peter B. Juul, Uni?C (PBJ255-RIPE) From Michael.Dillon at btradianz.com Fri Nov 18 16:14:44 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 18 Nov 2005 15:14:44 +0000 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <200511181417.jAIEHWac013123@cichlid.raleigh.ibm.com> Message-ID: > How many 10K employee organizations exist in the world today (or in > ten years)? In the USA there are 930 such companies. This does not include non-commercial organizations. If you count companies with more than 2,500 employeees, then there are 3,316 in the USA. In the EU there are 10,000 large enterprises, that is companies and non-profits engaged in economic activity with more than 250 employees. I think that 10,000 employees is much too high as a cutoff for multihoming demand. Even 2,500 is too high. So let's say that there are 5,000 such enterprises in the USA and another 5,000 in Europe. This seems a reasonable guess. If we assume that the combined population of the EU and the USA is one fifth of the world's enterprise population, then we can expect five times 10,000 multihomers or 50,000 enterprises worldwide to multihome. On the face of it, that doesn't seem too bad but it misses some things. Government organizations. Smaller companies whose desire for multihoming does not come from the size of their business but from the nature of their business. For instance the family website that is running a transaction-based business that makes very slim margins on large numbers of transactions and therefore needs to be up 24x7. Or a web shop that has no storefront and relies on a steady stream of Internet orders, maybe a small taxi firm? This is a tough question to answer because it is entirely non-technical and we do not have the support from economists statisticians, and geographers to attempt a serious answer. If RIPE and the NRO would fund some studies, we would all be a lot better off in deciding the right policies. > If there were consensus that the answer to the above questions was > "yes, it's manageable", I'm sure folk would support a modified policy > to that effect in a heartbeat. > > But in the absence of some real data showing the implication of > loosening the policy to allow the above, many (myself include) will be > very concerned about the consequences of doing this. The wording could be changed without loosening it up much if we note that "customers" could refer to internal business units, not just external customers. --Michael Dillon From randy at psg.com Fri Nov 18 16:25:49 2005 From: randy at psg.com (Randy Bush) Date: Fri, 18 Nov 2005 07:25:49 -0800 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> <20051118125836.GA1109@srv01.cluenet.de> Message-ID: <17277.62077.581637.108662@roam.psg.com> >> If you are really too small, that is you have at most 10 sites, then you >> simply are too small. > Who are you to decide who is too small to be allowed independence? someone with routers which have to carry all those prefixes randy From ripe-wgs.cs at schiefner.de Fri Nov 18 16:27:03 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 18 Nov 2005 16:27:03 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <877jb8v3dr.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> Message-ID: <437DF2C7.903@schiefner.de> Florian, Florian Weimer wrote: > If DNS operators really cared about the availability of their data, > they would allow the general public to mirror it. However, some of > them seem to think that such a precaution against disaster would > negatively impact their current business model. of course, I can't speak for every DNS operator, but DENIC denying the transfer of the .de zone has no other reason than data protection, ie. making the harvesting of contact data of some 9 million plus domain name holders by just piping the zone through the whois impossible. Best regards, Carsten From ripe-wgs.cs at schiefner.de Fri Nov 18 16:28:17 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 18 Nov 2005 16:28:17 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: References: Message-ID: <437DF311.7020203@schiefner.de> Michael, Michael.Dillon at btradianz.com wrote: > [...] > If they don't move quickly, then someone else will build that > anycast infrastructure and both DENIC and AFNIC will be reduced > to being customers instead of network operators. why would that be? Best regards, Carsten From Michael.Dillon at btradianz.com Fri Nov 18 16:37:13 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 18 Nov 2005 15:37:13 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437DF311.7020203@schiefner.de> Message-ID: > > If they don't move quickly, then someone else will build that > > anycast infrastructure and both DENIC and AFNIC will be reduced > > to being customers instead of network operators. > > why would that be? Organizations who build and operate network are network operators. Organizations who buy network services from network operators are customers. --Michael Dillon From fw at deneb.enyo.de Fri Nov 18 16:44:20 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 18 Nov 2005 16:44:20 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437DF2C7.903@schiefner.de> (Carsten Schiefner's message of "Fri, 18 Nov 2005 16:27:03 +0100") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> Message-ID: <87hdaavu3v.fsf@mid.deneb.enyo.de> * Carsten Schiefner: > of course, I can't speak for every DNS operator, but DENIC denying the > transfer of the .de zone has no other reason than data protection, ie. > making the harvesting of contact data of some 9 million plus domain name > holders by just piping the zone through the whois impossible. Your claim is absurd. The real privacy issue comes form forced publication of WHOIS data. As a member of the DENIC executive board, you certainly know that, so please stop spreading such misinformation. From kurtis at kurtis.pp.se Fri Nov 18 17:08:09 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 18 Nov 2005 17:08:09 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> Message-ID: <06561D89-D9DC-44C9-AD1A-93BB25390529@kurtis.pp.se> On 17 nov 2005, at 20.05, Pekka Savola wrote: > On Thu, 17 Nov 2005, Tim Streater wrote: > >> The other network is one we are *currently* managing, >> EUMEDCONNECT. It is for the Middle-eastern and North African >> NRENs. The intention here is that we expect these NRENs to set up >> their own entity to manage it, and go their own way, in which case >> we gift them the infrastructure, which in this case has to include >> the address space. We can do that for v4 as I got PI space for >> that. Its v6 that is the problem. >> > > Did you actually *try* getting a separate /32 for this? > > RIPE NCC is known to be very reasonable towards transit networks, > and I could bet good money you could get an allocation without a > hitch. So what you say is "keep the current rule as the NCC will disobey it anyway". Why can't we just fix the broken policy.... - kurtis - From randy at psg.com Fri Nov 18 17:13:17 2005 From: randy at psg.com (Randy Bush) Date: Fri, 18 Nov 2005 08:13:17 -0800 Subject: [address-policy-wg] 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> <06561D89-D9DC-44C9-AD1A-93BB25390529@kurtis.pp.se> Message-ID: <17277.64925.489973.855151@roam.psg.com> >> RIPE NCC is known to be very reasonable towards transit networks, >> and I could bet good money you could get an allocation without a >> hitch. > So what you say is "keep the current rule as the NCC will disobey it > anyway". Why can't we just fix the broken policy.... how much should policy be twisted to cover up broken/incomplete technology? the need will be continual and infinite. randy From ripe-wgs.cs at schiefner.de Fri Nov 18 17:26:36 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 18 Nov 2005 17:26:36 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: References: Message-ID: <437E00BC.4090309@schiefner.de> Hi Michael, Michael.Dillon at btradianz.com wrote: >>>If they don't move quickly, then someone else will build that >>>anycast infrastructure and both DENIC and AFNIC will be reduced >>>to being customers instead of network operators. >> >>why would that be? > > Organizations who build and operate network are > network operators. Organizations who buy network > services from network operators are customers. that's clear - I just wondered where the conclusion came from that if someone would build an anycast infrastructure TLD operators had no other chance than to just become customers of those. Best, Carsten From kurtis at kurtis.pp.se Fri Nov 18 17:34:20 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 18 Nov 2005 17:34:20 +0100 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <17277.64925.489973.855151@roam.psg.com> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> <06561D89-D9DC-44C9-AD1A-93BB25390529@kurtis.pp.se> <17277.64925.489973.855151@roam.psg.com> Message-ID: <8A59D099-5F40-4E18-9E19-8812EC4E9F76@kurtis.pp.se> On 18 nov 2005, at 17.13, Randy Bush wrote: >>> RIPE NCC is known to be very reasonable towards transit networks, >>> and I could bet good money you could get an allocation without a >>> hitch. >>> >> So what you say is "keep the current rule as the NCC will disobey it >> anyway". Why can't we just fix the broken policy.... >> > > how much should policy be twisted to cover up broken/incomplete > technology? the need will be continual and infinite. You know Randy, you don't HAVE to do v6. You can stay at v4...:-) - kurtis - From ripe-wgs.cs at schiefner.de Fri Nov 18 17:51:56 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 18 Nov 2005 17:51:56 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <87hdaavu3v.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> <87hdaavu3v.fsf@mid.deneb.enyo.de> Message-ID: <437E06AC.5090606@schiefner.de> Florian, Florian Weimer wrote: >>of course, I can't speak for every DNS operator, but DENIC denying the >>transfer of the .de zone has no other reason than data protection, ie. >>making the harvesting of contact data of some 9 million plus domain name >>holders by just piping the zone through the whois impossible. > > Your claim is absurd. The real privacy issue comes form forced > publication of WHOIS data. As a member of the DENIC executive board, > you certainly know that, so please stop spreading such misinformation. it's interesting that you appear to know what I "certainly" know... What I indeed know is that DENIC's whois policy is well balanced between the interests of the individual domain name holder and the general public: bulk access to whois data is not possible, but only on a per-domain-name basis - ie. you need to have the domain name at hand to get the appropriate whois data. And besides that there is no other means (aka. 'key' - eg. last name, city of residence etc.) to access that data. This policy, BTW, is in full accordance with the relevant data protection bodies. But may I suggest that we have that discussion off this list - as RIPE's address policy and IPv6 WGs are IMHO the wrong fora to discuss DENIC's whois policy - and moved to a place of your choice? Best, Carsten From randy at psg.com Fri Nov 18 17:57:51 2005 From: randy at psg.com (Randy Bush) Date: Fri, 18 Nov 2005 08:57:51 -0800 Subject: [address-policy-wg] 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> <06561D89-D9DC-44C9-AD1A-93BB25390529@kurtis.pp.se> <17277.64925.489973.855151@roam.psg.com> <8A59D099-5F40-4E18-9E19-8812EC4E9F76@kurtis.pp.se> Message-ID: <17278.2063.925814.698089@roam.psg.com> >>>> RIPE NCC is known to be very reasonable towards transit networks, >>>> and I could bet good money you could get an allocation without a >>>> hitch. >>> So what you say is "keep the current rule as the NCC will disobey it >>> anyway". Why can't we just fix the broken policy.... >> how much should policy be twisted to cover up broken/incomplete >> technology? the need will be continual and infinite. > You know Randy, you don't HAVE to do v6. You can stay at v4...:-) the question is not about me, but thanks for turning the discussion personal. have you stopped beating your routers? the issue is can we 'fix' policy to cover for the fact that v6 was only 1/3 designed, long addresses but no routing and no transition plan? i am suggesting that the policy fixes will be infinite and ever more twisty, as there is only so much one can do to cover that the underlying technology is not even half-assed. randy From dr at cluenet.de Fri Nov 18 17:58:07 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 18 Nov 2005 17:58:07 +0100 Subject: [address-policy-wg] Re: Re: 200 customer requirements for IPv6 In-Reply-To: <17277.62077.581637.108662@roam.psg.com> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> <20051118125836.GA1109@srv01.cluenet.de> <17277.62077.581637.108662@roam.psg.com> Message-ID: <20051118165807.GA3165@srv01.cluenet.de> On Fri, Nov 18, 2005 at 07:25:49AM -0800, Randy Bush wrote: > >> If you are really too small, that is you have at most 10 sites, then you > >> simply are too small. > > Who are you to decide who is too small to be allowed independence? > > someone with routers which have to carry all those prefixes You mean the very small tier 1 club? All others can default and don't _have_ to carry all those prefixes. Or do you mean the ISP community at large which tries to fulfil customer requirements and make money with that? The customer requirement is full technical and economical independence from their suppliers. And the ISPs (minus the Tier 1s) can default to their upstreams, they don't need to carry full tables - unless their customers do ask for that. It's all about fulfilling customer requirements. What's _your_ solution to this problem _now_ in IPv6? Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Fri Nov 18 18:03:20 2005 From: randy at psg.com (Randy Bush) Date: Fri, 18 Nov 2005 09:03:20 -0800 Subject: [address-policy-wg] Re: Re: 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> <20051118125836.GA1109@srv01.cluenet.de> <17277.62077.581637.108662@roam.psg.com> <20051118165807.GA3165@srv01.cluenet.de> Message-ID: <17278.2392.684975.435037@roam.psg.com> >>> Who are you to decide who is too small to be allowed independence? >> someone with routers which have to carry all those prefixes > You mean the very small tier 1 club? All others can default and don't > _have_ to carry all those prefixes. no, that's not what i mean and you know it. the number of t1s is a very tiny percentage of those carrying full routing. you may wish it otherwise. i may wish it otherwise. but until there is solid technology to support better routing, that's life. get used to it. > What's _your_ solution to this problem _now_ in IPv6? stop deployment, which is negligible anyway, and fix the technology. and fixing is not applying endless half-assed hacks that don't actually do the job. we're gonna live with this stuff for a very long time. it should be very far more solid design than it is. if we're patching now, what will be the kludge level 20 years from now? randy From dr at cluenet.de Fri Nov 18 18:05:18 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 18 Nov 2005 18:05:18 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <17278.2063.925814.698089@roam.psg.com> References: <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> <06561D89-D9DC-44C9-AD1A-93BB25390529@kurtis.pp.se> <17277.64925.489973.855151@roam.psg.com> <8A59D099-5F40-4E18-9E19-8812EC4E9F76@kurtis.pp.se> <17278.2063.925814.698089@roam.psg.com> Message-ID: <20051118170518.GB3165@srv01.cluenet.de> On Fri, Nov 18, 2005 at 08:57:51AM -0800, Randy Bush wrote: > i am suggesting that the policy fixes will be infinite and ever > more twisty, as there is only so much one can do to cover that > the underlying technology is not even half-assed. What's your alternative? "I cannot make my way to the groceries store in less than 10 minutes, so I don't go shopping at all, until... when?" I'm very convinced that putting a proper v6 PI policy in place does buy us enough time for to find a real solution to the perceived problem (which, again, noone has proven to be more than a worst case scenario yet). That solution will most probably not be IPv6. But evolution is inherent to the Net. We need evolution. We cannot wait for the magic 42 to appear to fulfil all our needs, cover all worst case scenarios the Netstradami paint onto the walls. We won't be able to predict the future >>10 years, and we are far less able to design solutions now for problems we cannot even forsee. Or to view it from a different angle: always playing safe was never the formula for great success. It's usually the formula for an intellectual parking brake. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Fri Nov 18 18:07:52 2005 From: randy at psg.com (Randy Bush) Date: Fri, 18 Nov 2005 09:07:52 -0800 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 References: <6.2.3.4.2.20051117161846.04f919f0@mail.dante.org.uk> <437CB72A.9020806@unfix.org> <6.2.3.4.2.20051117170934.05017f68@mail.dante.org.uk> <437CC793.3000306@unfix.org> <6.2.3.4.2.20051117181243.04ed8fd8@mail.dante.org.uk> <06561D89-D9DC-44C9-AD1A-93BB25390529@kurtis.pp.se> <17277.64925.489973.855151@roam.psg.com> <8A59D099-5F40-4E18-9E19-8812EC4E9F76@kurtis.pp.se> <17278.2063.925814.698089@roam.psg.com> <20051118170518.GB3165@srv01.cluenet.de> Message-ID: <17278.2664.320973.683943@roam.psg.com> > "I cannot make my way to the groceries store in less than 10 minutes, > so I don't go shopping at all, until... when?" broken analogy. currently, the ipv4 grocery store delivers quite well. randy From dr at cluenet.de Fri Nov 18 18:09:13 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 18 Nov 2005 18:09:13 +0100 Subject: [address-policy-wg] Re: Re: Re: 200 customer requirements for IPv6 In-Reply-To: <17278.2392.684975.435037@roam.psg.com> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> <20051118125836.GA1109@srv01.cluenet.de> <17277.62077.581637.108662@roam.psg.com> <20051118165807.GA3165@srv01.cluenet.de> <17278.2392.684975.435037@roam.psg.com> Message-ID: <20051118170913.GC3165@srv01.cluenet.de> On Fri, Nov 18, 2005 at 09:03:20AM -0800, Randy Bush wrote: > >>> Who are you to decide who is too small to be allowed independence? > >> someone with routers which have to carry all those prefixes > > You mean the very small tier 1 club? All others can default and don't > > _have_ to carry all those prefixes. > > no, that's not what i mean and you know it. the number of t1s is > a very tiny percentage of those carrying full routing. you may > wish it otherwise. i may wish it otherwise. but until there is > solid technology to support better routing, that's life. get used > to it. You conveniently ignore the fact that all those others don't HAVE to carry all those prefixes. Which I even stated in the quoted paragraph. > > What's _your_ solution to this problem _now_ in IPv6? > > stop deployment, which is negligible anyway, and fix the technology. You're welcome to find 42. Others tried hard, unsuccessfully. > and fixing is not applying endless half-assed hacks that don't > actually do the job. Which job? For how long? > we're gonna live with this stuff for a very long time. it should > be very far more solid design than it is. if we're patching now, > what will be the kludge level 20 years from now? No idea. What will be problems in 20 years from now? You claim you can find the technology which won't impose problems on us for the next 20 years to come? Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From oppermann at pipeline.ch Fri Nov 18 18:37:25 2005 From: oppermann at pipeline.ch (Andre Oppermann) Date: Fri, 18 Nov 2005 18:37:25 +0100 Subject: [address-policy-wg] Re: Re: 200 customer requirements for IPv6 References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> <20051118125836.GA1109@srv01.cluenet.de> <17277.62077.581637.108662@roam.psg.com> <20051118165807.GA3165@srv01.cluenet.de> <17278.2392.684975.435037@roam.psg.com> Message-ID: <437E1155.99C9E0C8@pipeline.ch> Randy Bush wrote: > > >>> Who are you to decide who is too small to be allowed independence? > >> someone with routers which have to carry all those prefixes > > You mean the very small tier 1 club? All others can default and don't > > _have_ to carry all those prefixes. > > no, that's not what i mean and you know it. the number of t1s is > a very tiny percentage of those carrying full routing. you may > wish it otherwise. i may wish it otherwise. but until there is > solid technology to support better routing, that's life. get used > to it. > > > What's _your_ solution to this problem _now_ in IPv6? > > stop deployment, which is negligible anyway, and fix the technology. > and fixing is not applying endless half-assed hacks that don't > actually do the job. > > we're gonna live with this stuff for a very long time. it should > be very far more solid design than it is. if we're patching now, > what will be the kludge level 20 years from now? Here comes Andre's guide to fix IPv6(tm): 1. Make /32 the only routable entity so we can use perfect match in the DFZ instead of longest-prefix match. Perfect match scales better and is way more economically to implement in hard- and soft- ware. (MPLS is perfect match too.) Beyond /32 use longest-prefix up to /64. 32 bit in the DFZ give us 4 billion routable entities. See "Scalability issues in the Internet routing system" thread on NANOG, starting 18. October 2005. 2. Drop the Flow Label and Next Header fields from the IPv6 header. They are architectually broken and do not belong to this layer. Just encapsulate the packet in another layer like MPLS. Next Header is broken because it's just source routing again. Dead for a long time. Nobody in their right mind will allow header popping through their firewall/network. 3. Reinsert packet fragmentation into the IPv6 header. Path MTU discovery just ain't cutting it. 4. Drop 64 bits from the IPv6 address. The lower 64 bit are just pointless as host indentifier. Very poor overhead ratio. 6. Do away with those stupid ':' separators in IPv6 addresses. No, I'm not joking. It ain't to late yet to fix it. Details and variations can be discussed. ;-) -- Andre Oppermann oppermann at networx.ch - AS8271 andre at freebsd.org - TPC/IP Kernel Developer From gert at space.net Sat Nov 19 16:16:44 2005 From: gert at space.net (Gert Doering) Date: Sat, 19 Nov 2005 16:16:44 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051117105032.GO99793@kerkenna.nic.fr> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> Message-ID: <20051119151644.GB15782@Space.Net> Hi, On Thu, Nov 17, 2005 at 11:50:32AM +0100, Mohsen Souissi wrote: > ==> This is just amazing! I have been follwing this topic for more > than two years and I have the feeling that we are making again and > again the history! I remember that when the IPv6 "PI" issue was first > raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that > time), the answer was "PI is out of scope of this wg". I'm not sure which WG you are talking about (IPv6 WG or LIR WG?), but it's certainly in scope for the address policy WG. The topic of PI space for IPv6 just has been avoided like the plague so far - nobody seems to be able to define proper criteria for IPv6 PI, and I'm fairly sure we will not be able to reach consensus for IPv4-style PI ("come and ask for it, and that's all you need to do"). Personally, I've seen some doomsayers so far ("IPv6 will die if we have no PI!"), but I can't remember having seen a proposal for rules that let "those that we all agree should have it" have PI, and "those that we all agree should not have it" not have it. Which reflects on the problem - there are many readers here that have good arguments against any sort of PI (that is not needed for DNS purposes, due to protocol constraints [brokenness]), and others see any possible alternative as "this is just not going to work" (read "I'm politically opposing this, and because it isn't PI, it is not acceptable")... so getting consensus will be tough. > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... "We" aren't. These are just some comments by some of the participants. But of course "we" will, if someone formulates a specific policy proposal how to make PI work. > If that's to be done and while we ar at it, we can see again how RIPE > is the only RIR not considering TLD networks as "critical > infrastructure" while an appropriate policy has been already > implemented in all other existing RIRs for a long while (please > revisit the comparative matrix of RIR policies at > http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and > see how RIPE is lagging behind in this matter. Some of this > mailing-list member would say: "that was our choice!"). Isn't it a > European speciality to discuss over again and again issues without > coming to any solution? It certainly is an European speciality to bring up the same discussion again and again without any new facts that might affect the outcome. DNS is special, in that the protocol is fairly broken, but too widespread to re-do over night. This warrants special cases for the root, and maybe special cases for *anycast* - but nobody is asking for special cases for normal unicast DNS servers. That's what glue records are for, and they work fairly well. DNS is critical infrastructure, but nobody has explained properly yet why "critical infrastructure" (in itself) requires a different way to get IP addresses. Even so, Google is likely more critical to more people than some of the ccTLDs out there... 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 elmi at 4ever.de Sun Nov 20 12:19:03 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Sun, 20 Nov 2005 12:19:03 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051119151644.GB15782@Space.Net> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> Message-ID: <20051120111903.GI96756@new.detebe.org> Just to get the thing rolling again with something new :-) gert at space.net (Gert Doering) wrote: > Personally, I've seen some doomsayers so far ("IPv6 will die if we have > no PI!"), but I can't remember having seen a proposal for rules that let > "those that we all agree should have it" have PI, and "those that we > all agree should not have it" not have it. How about: Every ASN is entitled to an IPv6 block. Full stop. Then you can tie it to independency of routing and to the rules for ASNs. Anyone else think along these lines? Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From elmi at 4ever.de Sun Nov 20 12:49:49 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Sun, 20 Nov 2005 12:49:49 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43805CAD.5040104@netegral.co.uk> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> <43805CAD.5040104@netegral.co.uk> Message-ID: <20051120114949.GK96756@new.detebe.org> cgray at netegral.co.uk (Cameron C. Gray) wrote: > I think even the routing-table purists will agree that 64K routes > maximum size will be fine. In IPv6 it might just work ;-) Address space handout policies were deliberately tuned to be able to give every (valid) requestor a block that would fit their needs indefinitely. Some exceptions will of course exist... Elmar. PS: Don't bet on the 64K... -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From gert at space.net Sun Nov 20 17:28:27 2005 From: gert at space.net (Gert Doering) Date: Sun, 20 Nov 2005 17:28:27 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051120111903.GI96756@new.detebe.org> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> Message-ID: <20051120162827.GF15782@Space.Net> Hi, On Sun, Nov 20, 2005 at 12:19:03PM +0100, Elmar K. Bins wrote: > Just to get the thing rolling again with something new :-) Which is not so new. Pekka wrote a draft about that, some years ago. > gert at space.net (Gert Doering) wrote: > > > Personally, I've seen some doomsayers so far ("IPv6 will die if we have > > no PI!"), but I can't remember having seen a proposal for rules that let > > "those that we all agree should have it" have PI, and "those that we > > all agree should not have it" not have it. > > How about: Every ASN is entitled to an IPv6 block. Full stop. > Then you can tie it to independency of routing and to the rules for ASNs. > > Anyone else think along these lines? This will change the question "who is worthy to receive an IPv6 block" into "who is worthy to receive an AS number" - which is today defined on a pure technical basis, with the "hurdle" being the address acquisition, not the AS number. If you tie it to the *routing* policy thing ("verifiable dual upstreams" or such), it will indeed solve some parts of "the PI problem", without opening the flood gates to "everyone". OTOHO, it might make "everyone" want to get an AS number - and BGP "multihoming" isn't so hard to achieve, if it only serves the purpose of qualifying for an AS number... Now if the future would not be so cloudy today... 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 Sun Nov 20 17:29:07 2005 From: gert at space.net (Gert Doering) Date: Sun, 20 Nov 2005 17:29:07 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43805CAD.5040104@netegral.co.uk> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> <43805CAD.5040104@netegral.co.uk> Message-ID: <20051120162907.GG15782@Space.Net> Hi, On Sun, Nov 20, 2005 at 11:23:25AM +0000, Cameron C. Gray wrote: > I think even the routing-table purists will agree that 64K routes > maximum size will be fine. AS numbers are not really limited to 16 bits... 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 bmanning at vacation.karoshi.com Fri Nov 18 17:20:15 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 18 Nov 2005 16:20:15 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437DF311.7020203@schiefner.de> References: <437DF311.7020203@schiefner.de> Message-ID: <20051118162015.GA16936@vacation.karoshi.com.> On Fri, Nov 18, 2005 at 04:28:17PM +0100, Carsten Schiefner wrote: > Michael, > > Michael.Dillon at btradianz.com wrote: > >[...] > >If they don't move quickly, then someone else will build that > >anycast infrastructure and both DENIC and AFNIC will be reduced > >to being customers instead of network operators. > > why would that be? > > Best regards, > > Carsten because, apparently, customers aka service operators are inferior to network operators aka plumbers. a $DEITY forbid that an TLD operator ego be brused by not being considered in the same class as plumbers. tongue partly in cheek. perhaps there is the consideration that TLD ops are "special" in some unique way that preclueds them from fate-sharing with a plumber when the pipes break. e.g. they have not taken steps to distribute their service or content so that it is available over different carriers, on alternate power grids, in other countries. ... and perhaps ... using a variety of publishers ... instead of trying to run all that infrastructure in addition to operating the TLD. OR... why do tld operators have to have all the servers under infrastructure they run? when did this change? example: DEnic could have CNnic, BRnic, and CAnic run slave servers for them in their areas. Why is this a bad thing? --bill From cgray at netegral.co.uk Sun Nov 20 12:23:25 2005 From: cgray at netegral.co.uk (Cameron C. Gray) Date: Sun, 20 Nov 2005 11:23:25 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051120111903.GI96756@new.detebe.org> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> Message-ID: <43805CAD.5040104@netegral.co.uk> Elmar K. Bins wrote: >How about: Every ASN is entitled to an IPv6 block. Full stop. >Then you can tie it to independency of routing and to the rules for ASNs. > >Anyone else think along these lines? > Elmi. > > Hear! Hear! I think even the routing-table purists will agree that 64K routes maximum size will be fine. I'm for this approach. -- Best regards, Cameron Gray Director Netegral Limited Registry: uk.netegral From fw at deneb.enyo.de Mon Nov 21 09:28:08 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 21 Nov 2005 09:28:08 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437E06AC.5090606@schiefner.de> (Carsten Schiefner's message of "Fri, 18 Nov 2005 17:51:56 +0100") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> <87hdaavu3v.fsf@mid.deneb.enyo.de> <437E06AC.5090606@schiefner.de> Message-ID: <87zmnyjtgn.fsf@mid.deneb.enyo.de> * Carsten Schiefner: > Florian, > > Florian Weimer wrote: >>> of course, I can't speak for every DNS operator, but DENIC denying >>> the transfer of the .de zone has no other reason than data >>> protection, ie. making the harvesting of contact data of some 9 >>> million plus domain name holders by just piping the zone through >>> the whois impossible. >> Your claim is absurd. The real privacy issue comes form forced >> publication of WHOIS data. As a member of the DENIC executive board, >> you certainly know that, so please stop spreading such misinformation. > > it's interesting that you appear to know what I "certainly" know... Don't tell me you haven't been briefed on such issues. 8-/ Anyway, I have moved the discussion to a more appropriate list. Just to make myself clear, I understand that publishing zones in a ready-to-process manner might not be in the best interest of everyone. For example, if an ISP A suffers a significant outage, a competing ISP B might sift through zone data, enumerate all domains served by ISP A's name servers. When that ISP is back again, ISP B uses the imprints for said domains (that is. if there is a web server) to gather postal addresses of ISP A's customers, making them an offer to switch (by snail mail, of course, otherwise it would be spam). Incidentally this is one of the reasons why I don't publish all the zone data I've recovered, but this is not really related to privacy concerns. From lea.roberts at stanford.edu Mon Nov 21 16:12:45 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 21 Nov 2005 07:12:45 -0800 (PST) Subject: [address-policy-wg] IPv6 PI In-Reply-To: <20051120111903.GI96756@new.detebe.org> Message-ID: as long as it's "something new", let's get a fresh subject line... :-) On Sun, 20 Nov 2005, Elmar K. Bins wrote: > Just to get the thing rolling again with something new :-) > > > gert at space.net (Gert Doering) wrote: > > > Personally, I've seen some doomsayers so far ("IPv6 will die if we have > > no PI!"), but I can't remember having seen a proposal for rules that let > > "those that we all agree should have it" have PI, and "those that we > > all agree should not have it" not have it. > > How about: Every ASN is entitled to an IPv6 block. Full stop. > Then you can tie it to independency of routing and to the rules for ASNs. > > Anyone else think along these lines? > Elmi. this was the original ARIN proposal 2005-1, which could not reach consensus. The last time around it was re-worked to add more restrictions and again failed because other folks felt it was too restrictive. There are actually two issues: 1) the high cost of renumbering in a large organization 2) multi-homing for network reliability and resiliency the problem with using ASNs is that when you think over the projected lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN draft is entering the standards track in IETF. Don't think that tying PI to ASNs is anything more that passing the problem to the next generation (if that long... :-) It would seem obvious that as network connectivity becomes essential for doing business, it must be reliable. It is unwise to carry forward the IPv4 multi-homing model for network resilience with just faith that the system will be able to scale to an ever larger number of routes. IPv6 has so far failed to deliver on its original promise of seamless renumbering and multi-homing using multiple prefixes. The hard problems still need to be solved in a way that can scale for decades to come. regards, /Lea From Michael.Dillon at btradianz.com Mon Nov 21 16:46:35 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 21 Nov 2005 15:46:35 +0000 Subject: [address-policy-wg] IPv6 PI In-Reply-To: Message-ID: > the problem with using ASNs is that when you think over the projected > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN > draft is entering the standards track in IETF. Don't think that tying PI > to ASNs is anything more that passing the problem to the next generation > (if that long... :-) A policy that says "if you qualify for an AS number then you also qualify for one IPv6 /32 allocation" does not run into any problems with 16-bit AS numbers. That is because you still have to qualify for the AS number before you can get the address allocation. Of course, after 16-bit AS numbers come in, some people may wish to make it easier to get AS numbers and we would probably want to change the address allocation policy at the same time. If a policy works for 2 years, that is good enough. RIRs can change policies in a few months if there is a need. > It would seem obvious that as network connectivity becomes essential for > doing business, it must be reliable. It is unwise to carry forward the > IPv4 multi-homing model for network resilience with just faith that the > system will be able to scale to an ever larger number of routes. IPv6 has > so far failed to deliver on its original promise of seamless renumbering > and multi-homing using multiple prefixes. The hard problems still need to > be solved in a way that can scale for decades to come. That leads to geotopological IPv6 addresses but that is another thread... --Michael Dillon From elmi at 4ever.de Mon Nov 21 17:27:02 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 21 Nov 2005 17:27:02 +0100 Subject: [address-policy-wg] Re: IPv6 PI In-Reply-To: References: <20051120111903.GI96756@new.detebe.org> Message-ID: <20051121162702.GE96756@new.detebe.org> lea.roberts at stanford.edu (Lea Roberts) wrote: > this was the original ARIN proposal 2005-1, which could not reach > consensus. The last time around it was re-worked to add more restrictions > and again failed because other folks felt it was too restrictive. There > are actually two issues: > > 1) the high cost of renumbering in a large organization Why should they renumber, if it's their own block? > 2) multi-homing for network reliability and resiliency Where's the problem here? Someone who can afford and establish a case for _real_ multihoming can get an ASN and thus an assignment. Like was already said - loosening the ASN handout rules needs changes in assignment rules, too. But that's for years to come. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From lea.roberts at stanford.edu Mon Nov 21 17:56:35 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 21 Nov 2005 08:56:35 -0800 (PST) Subject: [address-policy-wg] IPv6 PI In-Reply-To: Message-ID: On Mon, 21 Nov 2005 Michael.Dillon at btradianz.com wrote: > > the problem with using ASNs is that when you think over the projected > > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte > ASN > > draft is entering the standards track in IETF. Don't think that tying > PI > > to ASNs is anything more that passing the problem to the next generation > > (if that long... :-) > > A policy that says "if you qualify for an AS number then you > also qualify for one IPv6 /32 allocation" does not run into > any problems with 16-bit AS numbers. That is because you still > have to qualify for the AS number before you can get the address > allocation. Of course, after 16-bit AS numbers come in, some people > may wish to make it easier to get AS numbers and we would probably > want to change the address allocation policy at the same time. > > If a policy works for 2 years, that is good enough. RIRs can > change policies in a few months if there is a need. this would create another "early adopter" bonus, now in the IPv6 space. some people believe that more fairness should be applied in this arena and we should learn from the mistakes of IPv4. From tim.streater at dante.org.uk Mon Nov 21 18:21:53 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Mon, 21 Nov 2005 17:21:53 +0000 Subject: [address-policy-wg] 200 customer requirements for IPv6 In-Reply-To: <437DA445.6000507@unfix.org> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <437CB0ED.7C087FE8@networx.ch> <437DA445.6000507@unfix.org> Message-ID: <6.2.3.4.2.20051121135042.04cacdc8@mail.dante.org.uk> At 09:52 18/11/2005, Jeroen Massar wrote: >If you are really too small, that is you have at most 10 sites, then you >simply are too small. Actually two sites at present. But I wouldn't call a network that will provide v6 transit for the NRENs of a dozen or so Mediterranean countries "small", in the sense of significance. As I said, I haven't looked at this issue for a while, but I do recall that the policy was: 1) Getting space required the 200 customer plan 2) No PI space for v6 If this is the stated policy, doesn't seem much point in making an enquiry. If I were able to get the space, (1), and (2) notwithstanding, what would be the point of the policy? The present policy models a small portion of reality, and appears to leave major portions unprovided for, as others e-mails have attested. -- Tim From lea.roberts at stanford.edu Mon Nov 21 18:40:08 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 21 Nov 2005 09:40:08 -0800 (PST) Subject: [address-policy-wg] Re: IPv6 PI In-Reply-To: <20051121162702.GE96756@new.detebe.org> Message-ID: On Mon, 21 Nov 2005, Elmar K. Bins wrote: > lea.roberts at stanford.edu (Lea Roberts) wrote: > > > this was the original ARIN proposal 2005-1, which could not reach > > consensus. The last time around it was re-worked to add more restrictions > > and again failed because other folks felt it was too restrictive. There > > are actually two issues: > > > > 1) the high cost of renumbering in a large organization > > Why should they renumber, if it's their own block? the point is that current policy only allocates to organizations who commit to assigning space to other organizations and perhaps a case could be made for a limited number of large organizations to qualify for a PI block of IPv6 addresses. the trick is finding the criteria which can reach consensus as "fair" but not "too complicated". such a policy would encourage IPv6 adoption in these large organizations, many of whom are unwilling to deploy it using PA addresses. > > 2) multi-homing for network reliability and resiliency > > Where's the problem here? Someone who can afford and establish > a case for _real_ multihoming can get an ASN and thus an assignment. > > Like was already said - loosening the ASN handout rules needs changes > in assignment rules, too. But that's for years to come. see also my reply to Michael Dillon. there is a legitimate fairness argument about trying to find policies that work into the future rather than policies that need to be made more restrictive later. We've already done that and prefer to make different mistakes this time. it's harder! there is no question that the easy way out is just give everyone the equivalent (or more :-) than they currently have in IPv4. that will work for now and some time into the future. sure. but why not design a future that is built to scale reliably? it's really time to try to get rid of the IPv4 mindset!! there will have to be new and better ways of solving how to use multiple providers than everybody's route going into the global routing table. some work is being done now and it's good to keep pointing out the need for creative and scaleable solutions. let's encourage the right solutions rather than short term work-arounds... /Lea From lea.roberts at stanford.edu Mon Nov 21 18:41:04 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 21 Nov 2005 09:41:04 -0800 (PST) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: Message-ID: On Mon, 21 Nov 2005, Roger Jorgensen wrote: > On Mon, 21 Nov 2005, Lea Roberts wrote: > > > the problem with using ASNs is that when you think over the projected > > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN > > draft is entering the standards track in IETF. Don't think that tying PI > > to ASNs is anything more that passing the problem to the next generation > > (if that long... :-) > > > > It would seem obvious that as network connectivity becomes essential for > > doing business, it must be reliable. It is unwise to carry forward the > > IPv4 multi-homing model for network resilience with just faith that the > > system will be able to scale to an ever larger number of routes. IPv6 has > > so far failed to deliver on its original promise of seamless renumbering > > and multi-homing using multiple prefixes. The hard problems still need to > > be solved in a way that can scale for decades to come. > > Can't we all just drop using the word multihoming and IPv6 PI? > They all reflect back to how thing was done with IPv4 and those ways are > doomed to fail with IPv6 simply due to the size of the IP space. Well said. From randy at psg.com Mon Nov 21 20:05:02 2005 From: randy at psg.com (Randy Bush) Date: Mon, 21 Nov 2005 09:05:02 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: Message-ID: <17282.6750.71566.966599@roam.psg.com> >> Can't we all just drop using the word multihoming and IPv6 PI? >> They all reflect back to how thing was done with IPv4 and those ways are >> doomed to fail with IPv6 simply due to the size of the IP space. > Well said. indeed. since, by this argument, we can now assume v6 sites will not multi-home, there is no need for PI space at all. randy From rogerj at jorgensen.no Mon Nov 21 17:10:10 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Mon, 21 Nov 2005 17:10:10 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: References: Message-ID: On Mon, 21 Nov 2005, Lea Roberts wrote: > the problem with using ASNs is that when you think over the projected > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN > draft is entering the standards track in IETF. Don't think that tying PI > to ASNs is anything more that passing the problem to the next generation > (if that long... :-) > > It would seem obvious that as network connectivity becomes essential for > doing business, it must be reliable. It is unwise to carry forward the > IPv4 multi-homing model for network resilience with just faith that the > system will be able to scale to an ever larger number of routes. IPv6 has > so far failed to deliver on its original promise of seamless renumbering > and multi-homing using multiple prefixes. The hard problems still need to > be solved in a way that can scale for decades to come. Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space. Last I checked around there were some promissing new proposal on the way for how to solve this very basic problem. And in the meantime, drop the thought about multihoming and PI space, start to think about other ways to use the possibility IPv6 give us. Just to mention maybe the biggest advantage, we have that extended header part of IPv6, it give us endless possibilities. and yes I do have some idea about how it can be done but no one really bother to consider geo-based IP's either so... :) Not to forget it quite likely will undermine the entire business case for how ISP's today operate. -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From elmi at 4ever.de Tue Nov 22 10:53:10 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 22 Nov 2005 10:53:10 +0100 Subject: [address-policy-wg] Re: IPv6 PI In-Reply-To: References: <20051121162702.GE96756@new.detebe.org> Message-ID: <20051122095309.GI96756@new.detebe.org> lea.roberts at stanford.edu (Lea Roberts) wrote: > > Like was already said - loosening the ASN handout rules needs changes > > in assignment rules, too. But that's for years to come. > > see also my reply to Michael Dillon. there is a legitimate fairness > argument about trying to find policies that work into the future rather > than policies that need to be made more restrictive later. Well, at least my crystal ball gets clouded if I try to look more than a year into the future. I believe, we should change policies as we see fit, and not try to solve all the riddles of the world and foresay the future of the Internet now. > it's really time to try to get rid of the IPv4 mindset!! there will have > to be new and better ways of solving how to use multiple providers than > everybody's route going into the global routing table. some work is being > done now and it's good to keep pointing out the need for creative and > scaleable solutions. let's encourage the right solutions rather than > short term work-arounds... /Lea I like your enthusiasm very much, but there is more to do than start (or continue) designing a different Internet. We have to take up with what we have today. A different type of routing will have to be designed, adopted, implemented, used. That takes a lot of time, and I strongly believe (I know that it's right for _my_ part) that we need a (alas interim) solution now. Not in ten years. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From ripe-wgs.cs at schiefner.de Tue Nov 22 11:45:49 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 22 Nov 2005 11:45:49 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <87zmnyjtgn.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> <87hdaavu3v.fsf@mid.deneb.enyo.de> <437E06AC.5090606@schiefner.de> <87zmnyjtgn.fsf@mid.deneb.enyo.de> Message-ID: <4382F6DD.3010400@schiefner.de> >>>Your claim is absurd. The real privacy issue comes form forced >>>publication of WHOIS data. As a member of the DENIC executive board, >>>you certainly know that, so please stop spreading such misinformation. >> >>it's interesting that you appear to know what I "certainly" know... > > Don't tell me you haven't been briefed on such issues. 8-/ Be assured, I consider myself very well up to speed with regard to DENIC's business. I was actually referring to my alleged knowledge of the absurdity of my "claim" and the existence of "privacy issues". > Anyway, I > have moved the discussion to a more appropriate list. Seen that; EOD here then. Regards, Carsten From simon at limmat.switch.ch Wed Nov 23 14:25:46 2005 From: simon at limmat.switch.ch (Simon Leinen) Date: Wed, 23 Nov 2005 14:25:46 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051118162015.GA16936@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 18 Nov 2005 16:20:15 +0000") References: <437DF311.7020203@schiefner.de> <20051118162015.GA16936@vacation.karoshi.com.> Message-ID: bmanning writes: > because, apparently, customers aka service operators are > inferior to network operators aka plumbers. a $DEITY forbid > that an TLD operator ego be brused by not being considered in > the same class as plumbers. [...] > > tongue partly in cheek. > > perhaps there is the consideration that TLD ops are "special" > in some unique way that preclueds them from fate-sharing with > a plumber when the pipes break. e.g. they have not taken > steps to distribute their service or content so that it is > available over different carriers, on alternate power grids, > in other countries. ... and perhaps ... using a variety of > publishers ... instead of trying to run all that > infrastructure in addition to operating the TLD. OR... why > do tld operators have to have all the servers under > infrastructure they run? when did this change? Well said, Bill. > example: > DEnic could have CNnic, BRnic, and CAnic run slave servers for > them in their areas. Why is this a bad thing? As Kurt Jaeger aka pi said in a previous posting (although in a different context): > That's a national security issue for some countries. So it's all a matter of control. In a similar vein, see http://www.imconf.net/imc-2005/papers/imc05efiles/ramasubramanian/ramasubramanian.pdf "Perils of Transitive Trust in the Domain Name System", V. Ramasubramanian and E. G?n Sirer, IMC 2005 Personally I don't share the opinion that more centralized control leads to safer systems, but then nobody asks me. -- Simon. Speaking only for himself, but partly getting paid for helping to operate some TLD nameservers. From fw at deneb.enyo.de Thu Nov 24 18:58:04 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 24 Nov 2005 18:58:04 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: (Roger Jorgensen's message of "Mon, 21 Nov 2005 17:10:10 +0100 (CET)") References: Message-ID: <87sltm3p3n.fsf@mid.deneb.enyo.de> * Roger Jorgensen: > Can't we all just drop using the word multihoming and IPv6 PI? > They all reflect back to how thing was done with IPv4 and those ways are > doomed to fail with IPv6 simply due to the size of the IP space. I'm a relative newcomer to this area. Could you give a pointer to some explanation *why* the IPv6 address space size causes this problem? From oliver at bartels.de Thu Nov 24 19:22:24 2005 From: oliver at bartels.de (Oliver Bartels) Date: Thu, 24 Nov 2005 19:22:24 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: Message-ID: <200511241822.jAOIMAfk018658@alpha.bartels.de> On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: >Can't we all just drop using the word multihoming and IPv6 PI? The better solution is the enemy of the good solution. If IPv4 offers PI = provider _independence_ and multihoming and IPv6 doesn't, then IPv4 is obviously the better solution for those who requires this functionallity. Thus they won't use IPv6. Please keep in mind: The _customer_ votes, not you, not me. And as the majority of the large and a significant portion of medium size businesses are obviously not willing to accept an IP protocol not providing this functionallity, IPv6 will remain at it's current status: A technical playground for technically interested people. >They all reflect back to how thing was done with IPv4 and those ways are >doomed to fail with IPv6 simply due to the size of the IP space. Could you please explain this a bit more in detail ? To me this sounds like "engines will never fly". >Last I checked around there were some promissing new proposal on the >way for how to solve this very basic problem. Could you please be a bit more verbose. >And in the meantime, drop >the thought about multihoming and PI space, start to think about other >ways to use the possibility IPv6 give us. Hmm, please let me translate: "Even if the car doesn't drive and the engine doesn't deliver a single horse power at the wheels, drop the thought about driving, start to think about other way to use the possibility this great car gives us." Sound like newspeak: If we _think_ we can't solve the problem, drop discussing the problem. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From rogerj at jorgensen.no Fri Nov 25 10:12:35 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 10:12:35 +0100 (CET) Subject: [address-policy-wg] closed network and need for global uniqe IP space In-Reply-To: <200511241822.jAOIMAfk018658@alpha.bartels.de> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: Sorry for cross-posting but not sure where it really belong... ----------- Hi, First, the question is more, what is the correct way of dealing with situation like this? I work for a entity with a big and closed network where security and being closed came first. We're not governement but we have our mandate defined by them. Our only connection to Internet are through several uplinks with few public IP where we run proxy solution for the little traffic that are allowed to hit internet. Are in reality no incoming routes to us, and none out. Internal we use RFC1918 IP space,(private IP) and we for now have enough IP space but we are experience conflicts between IP space when connecting to other big closed network. Not to forget the size, we will probably run out of IP space to... (and I know others have run out of RFC1918 space on their internal network) Most would suggest request a /48 or bigger from your uplink right now and that's not going to work for several reasons: * size, just one of bigger sites connected probably need more than a /48 just for themself, and we have several of them, and alot of smaller sites/network. We're probably talking /32 or more if I have to guess. * scalability, we could of course get /48 and break the /64 boundary, a thought I seriously hate. But that will give us other kind of problems, sites needing a /64 or more due to some equipment or so... * there are other BIGGER network of the same type. * control over who is using what IP and where etc... as said above, security and being closed are probably the two most important factors for us. * need global unique IP's since we're connecting to other network of the same type, and NAT are not really the way we want to go with IPv6 ... and probably more I can't remember right now. The solutions aren't really that tricky but let me mention a few options... * Site local would have solved our problem BUT it's obsolite, quite stupid really. * just take a prefix and use it... this will give us problem in the future due to not being unique. * extensiv usage of NAT, eh do we really want to even consider THAT for IPv6? * become LIR and request the needed IP space. * let one of our uplinks request the IP space for us. I'm in favour of the last two options, any of them... and they are as I see it the really two options as things are now. Any thoughts? comments? -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From rogerj at jorgensen.no Fri Nov 25 10:36:25 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 10:36:25 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <87sltm3p3n.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> Message-ID: On Thu, 24 Nov 2005, Florian Weimer wrote: > * Roger Jorgensen: > > > Can't we all just drop using the word multihoming and IPv6 PI? > > They all reflect back to how thing was done with IPv4 and those ways are > > doomed to fail with IPv6 simply due to the size of the IP space. > > I'm a relative newcomer to this area. Could you give a pointer to > some explanation *why* the IPv6 address space size causes this > problem? Just do the math yourself and consider all possibilities and how the IPv4 space are used... but some numbers - the address space is 128bit. - we have a 64bits host prefix at the lower end. - the above give us 64bits of network numbers, that's quite a few billions of networks. BUT - the /48 boundary leaving us with a usable globaly network space of 48bit - from the 48bits only a /8 are usable as it is now, the other 7 /8 are reserved for the future. The absolute max global routing table would by this be 40bits, of course the real one are alot smaller. That one is closer to 32bits, and that is STILL A huge number, probably more close to 20bits of entries. a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it will last 10, maybe 15-20 years, but that did IPv4 to...... -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From rogerj at jorgensen.no Fri Nov 25 10:55:54 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 10:55:54 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <200511241822.jAOIMAfk018658@alpha.bartels.de> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: On Thu, 24 Nov 2005, Oliver Bartels wrote: > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > If IPv4 offers PI = provider _independence_ and multihoming > and IPv6 doesn't, then IPv4 is obviously the better solution for > those who requires this functionallity. > > Thus they won't use IPv6. > > Please keep in mind: The _customer_ votes, not you, not me. > > And as the majority of the large and a significant portion of medium > size businesses are obviously not willing to accept an IP protocol not > providing this functionallity, IPv6 will remain at it's current status: > > A technical playground for technically interested people. a very true point in one way but that is again as I see it, we're still thinking IPv4 when talking IPv6. Why do they need multihoming and PI? They don't trust the ISP and vendors to deliver them uptime and freedom... isn't this a problem the ISP and vendors should try to solve? Of course, the idea of easy renumbering was suppose to solve this but again, we're thinking IPv4 so it's not easy to understand. Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit. > > Hmm, please let me translate: > "Even if the car doesn't drive and the engine doesn't deliver a single > horse power at the wheels, drop the thought about driving, > start to think about other way to use the possibility this great car > gives us." > > Sound like newspeak: > If we _think_ we can't solve the problem, drop discussing the problem. for several years this discussion have been going on, still no real solution. IPv6 give us the freedom todo ALOT of things, USE those possibilities, if we have to change how IP are done, some TCP headers etc, then do it... propose a good idea and prove it. That could give us multihoming. Actually there is a master thesis about howto create connectivity for TCP session even if one of the links went down, the session just used another IP (1)... the user don't notice anything either and it have zero problem working with standard tcp-stacks since it use the extended header of IPv6. That's just ONE of many possible ways... (1) it's a master thesis writting by a student related to University of Troms?? as part of the Pasta project, www.pasta.cs.uit.no -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From oppermann at networx.ch Fri Nov 25 10:58:43 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Fri, 25 Nov 2005 10:58:43 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <87sltm3p3n.fsf@mid.deneb.enyo.de> Message-ID: <4386E053.73B661B3@networx.ch> Roger Jorgensen wrote: > > On Thu, 24 Nov 2005, Florian Weimer wrote: > > * Roger Jorgensen: > > > > > Can't we all just drop using the word multihoming and IPv6 PI? > > > They all reflect back to how thing was done with IPv4 and those ways are > > > doomed to fail with IPv6 simply due to the size of the IP space. > > > > I'm a relative newcomer to this area. Could you give a pointer to > > some explanation *why* the IPv6 address space size causes this > > problem? > > Just do the math yourself and consider all possibilities and how the IPv4 > space are used... but some numbers > > - the address space is 128bit. > - we have a 64bits host prefix at the lower end. > - the above give us 64bits of network numbers, that's quite a few billions > of networks. BUT > - the /48 boundary leaving us with a usable globaly network space of 48bit > - from the 48bits only a /8 are usable as it is now, the other 7 /8 are > reserved for the future. > > The absolute max global routing table would by this be 40bits, of > course the real one are alot smaller. That one is closer to 32bits, and > that is STILL A huge number, probably more close to 20bits of entries. > > a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail > as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it > will last 10, maybe 15-20 years, but that did IPv4 to...... You post is still pretty content-free. You're waving with your hand but what do you propose exactly? I've posted my proposals under "Andre's guide to fix IPv6". When do you with yours? -- Andre From oppermann at networx.ch Fri Nov 25 11:02:45 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Fri, 25 Nov 2005 11:02:45 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <4386E145.F0748506@networx.ch> Roger Jorgensen wrote: > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > If IPv4 offers PI = provider _independence_ and multihoming > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > those who requires this functionallity. > > > > Thus they won't use IPv6. > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > And as the majority of the large and a significant portion of medium > > size businesses are obviously not willing to accept an IP protocol not > > providing this functionallity, IPv6 will remain at it's current status: > > > > A technical playground for technically interested people. > > a very true point in one way but that is again as I see it, we're still > thinking IPv4 when talking IPv6. We're thinking Real World(TM). > Why do they need multihoming and PI? They don't trust the ISP and vendors > to deliver them uptime and freedom... isn't this a problem the ISP and > vendors should try to solve? Of course, the idea of easy renumbering was > suppose to solve this but again, we're thinking IPv4 so it's not easy to > understand. > > Again, we don't need PI space and multihoming, what we need are a way to > give the users and GOOD connectivity (uptime, speed etc) and make it easy > for them to switch providers as they see fit. That's only part of the reasoning. Customers don't want to be locked in to any one ISP. They want to have bargaining power which only comes with the ability to switch ISPs at will. > > > > > Hmm, please let me translate: > > "Even if the car doesn't drive and the engine doesn't deliver a single > > horse power at the wheels, drop the thought about driving, > > start to think about other way to use the possibility this great car > > gives us." > > > > Sound like newspeak: > > If we _think_ we can't solve the problem, drop discussing the problem. > > for several years this discussion have been going on, still no real > solution. IPv6 give us the freedom todo ALOT of things, USE those > possibilities, if we have to change how IP are done, some TCP headers etc, > then do it... propose a good idea and prove it. That could give us > multihoming. Actually there is a master thesis about howto create > connectivity for TCP session even if one of the links went down, the > session just used another IP (1)... the user don't notice anything > either and it have zero problem working with standard tcp-stacks since it > use the extended header of IPv6. Yea, that's known as SCTP. > That's just ONE of many possible ways... You're only handwaiving and saying "no". We are looking for ways to fit IPv6 to the reality of how millions of people and corporations use and want to use the Internet, technically and commercially. -- Andre From gert at space.net Fri Nov 25 11:18:46 2005 From: gert at space.net (Gert Doering) Date: Fri, 25 Nov 2005 11:18:46 +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: <20051125101846.GM69925@Space.Net> Hi, On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > The solutions aren't really that tricky but let me mention a few > options... > * Site local would have solved our problem BUT it's obsolite, quite > stupid really. That's why there are ULA ("unique local addresses") now. They should fit your needs pretty well - as much addresses as you want, and the guarantee to be not officially assigned to anyone. 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 rogerj at jorgensen.no Fri Nov 25 11:25:07 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 11:25:07 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l uniqe IP space In-Reply-To: <20051125101846.GM69925@Space.Net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net> Message-ID: On Fri, 25 Nov 2005, Gert Doering wrote: > Hi, > > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > > The solutions aren't really that tricky but let me mention a few > > options... > > * Site local would have solved our problem BUT it's obsolite, quite > > stupid really. > > That's why there are ULA ("unique local addresses") now. They should > fit your needs pretty well - as much addresses as you want, and the > guarantee to be not officially assigned to anyone. what about the other part about globaly unique when we connect to other network of the same type? -- ------------------------------ 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 Nov 25 11:38:44 2005 From: gert at space.net (Gert Doering) Date: Fri, 25 Nov 2005 11:38:44 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l uniqe IP space In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net> Message-ID: <20051125103844.GO69925@Space.Net> Hi, On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote: > > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > > > The solutions aren't really that tricky but let me mention a few > > > options... > > > * Site local would have solved our problem BUT it's obsolite, quite > > > stupid really. > > > > That's why there are ULA ("unique local addresses") now. They should > > fit your needs pretty well - as much addresses as you want, and the > > guarantee to be not officially assigned to anyone. > > what about the other part about globaly unique when we connect to other > network of the same type? 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. 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 fw at deneb.enyo.de Fri Nov 25 12:10:39 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 25 Nov 2005 12:10:39 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: (Roger Jorgensen's message of "Fri, 25 Nov 2005 10:36:25 +0100 (CET)") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> Message-ID: <87y83dq8y8.fsf@mid.deneb.enyo.de> * Roger Jorgensen: > The absolute max global routing table would by this be 40bits, of > course the real one are alot smaller. That one is closer to 32bits, and > that is STILL A huge number, probably more close to 20bits of entries. Only 20 bits? IPv4 already has more than 17 bits of entries. I still don't see the problem. To the contrary, your numbers suggest that IPv6 is very similar to IPv4 in this regard. From jeroen at unfix.org Sat Nov 26 14:16:25 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 26 Nov 2005 14:16:25 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <4386E145.F0748506@networx.ch> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4386E145.F0748506@networx.ch> Message-ID: <43886029.4040601@unfix.org> Andre Oppermann wrote: > Roger Jorgensen wrote: >> for several years this discussion have been going on, still no real >> solution. IPv6 give us the freedom todo ALOT of things, USE those >> possibilities, if we have to change how IP are done, some TCP headers etc, >> then do it... propose a good idea and prove it. That could give us >> multihoming. Actually there is a master thesis about howto create >> connectivity for TCP session even if one of the links went down, the >> session just used another IP (1)... the user don't notice anything >> either and it have zero problem working with standard tcp-stacks since it >> use the extended header of IPv6. > > Yea, that's known as SCTP. I am always wondering why SCTP is not taking off. From the few tests I did it works perfectly well, the location/identifier separation is pretty cleanly handled in DNS and inside the protocol for quick updates. Unfortunately not much software supports it at the moment. One way to fix that is to add a small proxy/BIA tool which changes TCP+UDP into SCTP. This works for server and client side. But nobody wants to do this for some mysterious reason. 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 Nov 26 14:37:13 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 26 Nov 2005 14:37:13 +0100 Subject: Andre's guide to fix IPv6 (Was: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI) In-Reply-To: <4386E053.73B661B3@networx.ch> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> Message-ID: <43886509.6060600@unfix.org> Andre Oppermann wrote: > I've posted my proposals under "Andre's > guide to fix IPv6". When do you with yours? Ripped from: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01166.html > 1. Make /32 the only routable entity so we can use perfect match in > the DFZ instead of longest-prefix match. What about the organizations that have say a /19, want them to inject all their more specific /32's? You can currently already do a perfect match on the first 32bits and then check if there are more specifics for this block or not. But I guess that theory is much better known to you than to me ;) > Perfect match scales > better and is way more economically to implement in hard- and soft- > ware. (MPLS is perfect match too.) Beyond /32 use longest-prefix > up to /64. 32 bit in the DFZ give us 4 billion routable entities. > See "Scalability issues in the Internet routing system" thread on > NANOG, starting 18. October 2005. Should indeed work pretty well. This is also one of the many reasons for me to say that when there will be any "IPv6 PI" introduced it should either be of size /32 or come out of a globally single /20 or something large that should accommodate all these prefixes, so that routing engines can be configured to support longer prefixes in that prefix. > 2. Drop the Flow Label and Next Header fields from the IPv6 header. Next Header is required or how else do you know what follows the IPv6 header? Or do you only want to do TCP? What about UDP,SCTP and many other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc). > They are architectually broken and do not belong to this layer. > Just encapsulate the packet in another layer like MPLS. Then why not drop IP and just route with MPLS? :) > Next Header is broken because it's just source routing again. Dead > for a long time. Nobody in their right mind will allow header > popping through their firewall/network. That is only one of the many possibilities to use Next Header for. I guess what you wanted to state here is that you don't see a need for "Hop by Hop Options" and other such headers so that routers don't have to parse through the next header because they don't have to expect anything there. Next Header in itself is the same as the IPv4 protocol field stating that TCP/UDP/etc is following it. > 3. Reinsert packet fragmentation into the IPv6 header. Path MTU > discovery just ain't cutting it. And then have routers do fragmentation again? Nah. IMHO fragmentations at endhosts was one of the best things introduced in IPv6. Especially for routers. Also Path MTU works perfectly fine, unless somebody of course drops ICMP, well that is then your issue, not mine. > 4. Drop 64 bits from the IPv6 address. The lower 64 bit are just > pointless as host indentifier. Very poor overhead ratio. Maybe you would like to see something like IPv8/IPv16 then, which according to the fortunately vanished mr Fla^Heming used a "StarGate" model. Something like: +----------------------------------------------+ | Ethernet macsrc+dst next=IPv16_SG | +----------------------------------------------+ | IPv16 StarGate = 3ffe::1 next=IPv16_Planet | +----------------------------------------------+ | IPv16 Planet = 4526::1 next=TCP | +----------------------------------------------+ | TCP | +----------------------------------------------+ > 6. Do away with those stupid ':' separators in IPv6 addresses. That is just representation, if you want you can drop those, just don't expect any (afaik) tool to parse it for you. Most human brains will not like you dropping it though, they are quite comfortable reading hex nicely grouped in clusters of 16bits but would not like to read something that is not nicely clustered, YMMV. You can always easily patch your kernel to support it if you want. The whole idea with IP addresses is that you stick them in DNS in the first place, so you would not see them anyway. (Or are you mailing address-policy-wg@...) 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 fw at deneb.enyo.de Sat Nov 26 16:00:46 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 Nov 2005 16:00:46 +0100 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43886509.6060600@unfix.org> (Jeroen Massar's message of "Sat, 26 Nov 2005 14:37:13 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> Message-ID: <87acfr1mjl.fsf@mid.deneb.enyo.de> * Jeroen Massar: >> 1. Make /32 the only routable entity so we can use perfect match in >> the DFZ instead of longest-prefix match. > > What about the organizations that have say a /19, want them to inject > all their more specific /32's? You can inject a /19 as 8192 /32s. Shouldn't make a difference if the /19 is really used. At this stage, it's probably not too wise to embed the /32--/48--/64 in silicon, but vendors will undoubtedly do this if they can save a few bucks and current policies remain as inflexible as they are. >> 2. Drop the Flow Label and Next Header fields from the IPv6 header. > > Next Header is required or how else do you know what follows the IPv6 > header? Or do you only want to do TCP? What about UDP,SCTP and many > other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc). IPv6 was designed for ACL-free software forwarding. This is not what we need today. Real routers must be able to access some layer 4 information. A better header would do away with any layer 3 options or option replacement. It would consist of 7 64-bit words. The first word contains the IP protocol version number, a hop counter (not a TTL, because it can be spoofed), and a bidirectional next-layer protocol identifier (protocol number plus some optional data that is indepedent of the direction of the packet flow and constant for a given "connection"). You can include some bits for QoS if you want, but I'm not sure if this makes sense. This is the first word. After that, the source and destination address follow (two words each). The remaining two remaining words are the next-layer source and destination address identifier (think port number, but you can put some additional cookie in there to make blind spoofing harder). In order to create a reflexive ACL entry, a router would zap the header flags and the hop count (which are ignored during matching anyway) and swap the source and destination addresses. No more upgrades so that you can filter still-a-bit=obscure protocols such as SCTP. Of course, a discussion about header layout is a bit pointless. But it is still a bit unfortunate that a protocol header explicitly designed for efficient forwarding does not come anywhere near that goal. >> 3. Reinsert packet fragmentation into the IPv6 header. Path MTU >> discovery just ain't cutting it. > > And then have routers do fragmentation again? Nah. IMHO fragmentations > at endhosts was one of the best things introduced in IPv6. Sure, makes sesnse. But signaling that fragmentation is needed must be completely in-line. What about this: Truncate the packet, set a bit in the header, and forward it to the destination? The destination can request retransmission from the source and specify the exact packet size that went through. > Also Path MTU works perfectly fine, unless somebody of course drops > ICMP, well that is then your issue, not mine. The market has spoken. Dropping ICMP is fine, I'm afraid. >> 4. Drop 64 bits from the IPv6 address. The lower 64 bit are just >> pointless as host indentifier. Very poor overhead ratio. > > Maybe you would like to see something like IPv8/IPv16 then, which > according to the fortunately vanished mr Fla^Heming used a "StarGate" > model. Something like: This is indeed a bit drastic. I'd rather see this attacked from the other angle, wasting less then 64 bits for access networks. The main problem I see with the /64 approach is that the remaining number of bits (< 64, may less than 60) is not sufficient to stuff two unique identifiers into the address (provider identifier and globally unique customer site identifier). From gih at apnic.net Sun Nov 27 22:22:48 2005 From: gih at apnic.net (Geoff Huston) Date: Mon, 28 Nov 2005 08:22:48 +1100 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa 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: <6.2.0.14.2.20051128075740.02b04d48@kahuna.telstra.net> At 09:38 PM 25/11/2005, Gert Doering wrote: >Hi, > >On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote: > > > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > > > > The solutions aren't really that tricky but let me mention a few > > > > options... > > > > * Site local would have solved our problem BUT it's obsolite, quite > > > > stupid really. > > > > > > That's why there are ULA ("unique local addresses") now. They should > > > fit your needs pretty well - as much addresses as you want, and the > > > guarantee to be not officially assigned to anyone. > > > > what about the other part about globaly unique when we connect to other > > network of the same type? > >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. This is an area that has not gone completely dormant. The "unlikeliness" that Gert refers to is the classic birthday problem, and the probability that 2 parties have chosen the same number rises above 0.5 once the candidate population exceeds 1.24 million. So some form of central or coordinated registry action is necessary to ensure that there are no collisions in these numbers. At APNIC we've been looking at how such a system could be supported. Geoff From kurtis at kurtis.pp.se Mon Nov 28 09:04:26 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 28 Nov 2005 09:04:26 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87acfr1mjl.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> Message-ID: (deleted address-policy-wg from the cc:) On 26 nov 2005, at 16.00, Florian Weimer wrote: > >>> 2. Drop the Flow Label and Next Header fields from the IPv6 header. >> >> Next Header is required or how else do you know what follows the IPv6 >> header? Or do you only want to do TCP? What about UDP,SCTP and many >> other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc). > > IPv6 was designed for ACL-free software forwarding. This is not what > we need today. Real routers must be able to access some layer 4 > information. > > A better header would do away with any layer 3 options or option > replacement. It would consist of 7 64-bit words. The first word > contains the IP protocol version number, a hop counter (not a TTL, > because it can be spoofed), and a bidirectional next-layer protocol > identifier (protocol number plus some optional data that is indepedent > of the direction of the packet flow and constant for a given > "connection"). You can include some bits for QoS if you want, but I'm > not sure if this makes sense. This is the first word. > > After that, the source and destination address follow (two words > each). The remaining two remaining words are the next-layer source > and destination address identifier (think port number, but you can put > some additional cookie in there to make blind spoofing harder). > > In order to create a reflexive ACL entry, a router would zap the > header flags and the hop count (which are ignored during matching > anyway) and swap the source and destination addresses. No more > upgrades so that you can filter still-a-bit=obscure protocols such as > SCTP. > > Of course, a discussion about header layout is a bit pointless. But > it is still a bit unfortunate that a protocol header explicitly > designed for efficient forwarding does not come anywhere near that > goal. So AFAIK the state of the art routers does 40G line-rate deep-packet inspection with any pattern matching. So remind me again what the problem is? Price? Sure, that is a question of demand and volume production... 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. - kurtis - From ncc at ripe.net Mon Nov 28 17:14:21 2005 From: ncc at ripe.net (Axel Pawlik) Date: Mon, 28 Nov 2005 17:14:21 +0100 Subject: [address-policy-wg] RIPE NCC Reappoints Wilfried Woeber as NRO NC Member Message-ID: <5.2.1.1.2.20051128165601.03086e90@mailhost.ripe.net> Dear Colleagues, The RIPE NCC Executive Board has reappointed Wilfried Woeber to the Number Resource Organization (NRO) Number Council as a representative of the RIPE NCC region. Under the terms of the Memorandum of Understanding (MoU) signed between ICANN and the Regional Internet Registries (RIRs) in October 2004, the NRO Number Council (NRO NC) now performs the role of the Address Supporting Organization Address Council (ASO AC). The term of Mr. Woeber's appointment is from 1 January 2006 to 31 December 2008. Mr. Woeber has previously served on the NRO NC as an interim member during 2005 and on the Address Council under the previous ASO structure, from January 2003 to December 2004. More information about the NRO Number Council is available at: http://www.nro.net/about/number-council.html Regards, Axel Pawlik Managing Director RIPE NCC From jorgen at hovland.cx Mon Nov 28 17:37:47 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 17:37:47 +0100 Subject: [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> Message-ID: <002f01c5f43a$12631110$44eea2d5@l> ----- Original Message ----- From: "Florian Weimer" Sent: Saturday, November 26, 2005 4:00 PM >* Jeroen Massar: > >>> 1. Make /32 the only routable entity so we can use perfect match in >>> the DFZ instead of longest-prefix match. >> >> What about the organizations that have say a /19, want them to inject >> all their more specific /32's? > > You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > /19 is really used. > > At this stage, it's probably not too wise to embed the /32--/48--/64 > in silicon, but vendors will undoubtedly do this if they can save a > few bucks and current policies remain as inflexible as they are. > Hi, Perfect match is faster but far from better. What I think perhaps would be interesting to see in the future with regards to IPv6 and PI is the following: 1. No PI. _Only_ network operators get a prefix. 2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific. In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers? Yes, it will somehow create millions/billions of prefixes (atleasat with todays routing technology/protocols). Network operators should be able to handle that hence rule #1. Joergen Hovland From hph at oslo.net Mon Nov 28 19:15:40 2005 From: hph at oslo.net (Hans Petter Holen) Date: Mon, 28 Nov 2005 19:15:40 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> 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> Message-ID: <438B494C.4030102@oslo.net> J?rgen Hovland wrote: > - > 1. No PI. _Only_ network operators get a prefix. I am an operator of a network - do I get a prefix ? (we have lots of computers and need lots of IP addresses: currently the 5 PCs, 2 printers, a phone and some PDA and a server online) I guess you need to define the criteria in some other way. Perhaps beeing registered with the national regulator > 2. Customers of network operators can at any time change provider and > take their assigned prefix with them. The new provider will announce > it as a more specific overriding the aggregate. If the customer > decides to get multiple providers, then the network operator with the > /32 could also announce a more specific. > > In the country I live in I can change telecom provider and take my > phone number with me to the new provider. Why shouldn't I be able to > do that with internet providers? Maybe we live in the same country ? The National Reference DataBase NRDB will take care of the routing (http://www.nrdb.no - at some point in time I guess they will move to ENUM - so perhaps jump directly to such a solution. But then it will be more difficult to implement the payment model they have. (It costs the operator more to be connected to this database than to get IP addressess from RIPE in addition there is a quarterly service fee to port numbers and even a per lookup fee) > Yes, it will somehow create millions/billions of prefixes (atleasat > with todays routing technology/protocols). Network operators should be > able to handle that hence rule #1. Why should my last provider carry my traffic after I switch provider ? In POTS this may work because there is elaborate interconnect agreements between the providers - I dont know of too may ISPs doing pr user accounting of transit any more. >From the consumer point of view - this is great - from a routing point of view and ISP interconnect point of view - I am not quite sure... -hph From jorgen at hovland.cx Mon Nov 28 19:59:34 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 19:59:34 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438B494C.4030102@oslo.net> Message-ID: <200511281859.jASIxbpQ017235@mail03.hipercom.no> -----Original Message----- From: Hans Petter Holen [mailto:hph at oslo.net] Sent: 28. november 2005 19:16 J?rgen Hovland wrote: >> - >> 1. No PI. _Only_ network operators get a prefix. > >I am an operator of a network - do I get a prefix ? (we have lots of >computers and need lots of IP addresses: currently the 5 PCs, 2 >printers, a phone and some PDA and a server online) > >I guess you need to define the criteria in some other way. Perhaps >beeing registered with the national regulator True. The existing RIPE 200 customer rule for ipv6 PA for instance. > 2. Customers of network operators can at any time change provider and > take their assigned prefix with them. The new provider will announce > it as a more specific overriding the aggregate. If the customer > decides to get multiple providers, then the network operator with the > /32 could also announce a more specific. > > In the country I live in I can change telecom provider and take my > phone number with me to the new provider. Why shouldn't I be able to > do that with internet providers? >Maybe we live in the same country ? We sure do (well at least since a few months ago)! > The National Reference DataBase >NRDB will take care of the routing (http://www.nrdb.no - at some point >in time I guess they will move to ENUM - so perhaps jump directly to >such a solution. But then it will be more difficult to implement the >payment model they have. (It costs the operator more to be connected to >this database than to get IP addressess from RIPE in addition there is >a quarterly service fee to port numbers and even a per lookup fee) > >> Yes, it will somehow create millions/billions of prefixes (atleasat >> with todays routing technology/protocols). Network operators should be >> able to handle that hence rule #1. > >Why should my last provider carry my traffic after I switch provider ? >In POTS this may work because there is elaborate interconnect agreements >between the providers - I dont know of too may ISPs doing pr user >accounting of transit any more. The only thing the last provider has to pay for is the LIR fee for their /32, not the traffic. More specific routes usually get priority unless Andre?s magic 32 constant is implemented. I was talking about putting these prefixes in dfz ? or not. You decide by the amount of interconnections you got. Then you would also probably have to decide a payment model, but it is not my business what you do. >From the consumer point of view - this is great - from a routing point >of view and ISP interconnect point of view - I am not quite sure... Yes that?s a question I wasn?t even sure about myself. Cheers, Joergen Hovland From dogwallah at gmail.com Mon Nov 28 20:01:57 2005 From: dogwallah at gmail.com (McTim) Date: Mon, 28 Nov 2005 22:01:57 +0300 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> 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> Message-ID: HI, On 11/28/05, J?rgen Hovland > Hi, > Perfect match is faster but far from better. What I think perhaps would be > interesting to see in the future with regards to IPv6 and PI is the > following: > > 1. No PI. _Only_ network operators get a prefix. > 2. Customers of network operators can at any time change provider and take > their assigned prefix with them. #2 sounds like PI to me. What have I missed? -- Cheers, McTim $ whois -h whois.afrinic.net mctim From fw at deneb.enyo.de Mon Nov 28 20:18:11 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 28 Nov 2005 20:18:11 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> (=?iso-8859-1?Q?J=F8rgen?= Hovland's message of "Mon, 28 Nov 2005 17:37:47 +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> Message-ID: <877jas37kc.fsf@mid.deneb.enyo.de> * J?rgen Hovland: > > 1. No PI. _Only_ network operators get a prefix. > 2. Customers of network operators can at any time change provider and take > their assigned prefix with them. The new provider will announce it as a more > specific overriding the aggregate. If the customer decides to get multiple > providers, then the network operator with the /32 could also announce a more > specific. This would imply that you cannot filter the routing table at prefix lengths less than /48. What's worse, outage of an ISP routes traffic to a now-unrelated ISP, which must discard traffic at its own cost. Better get rid of the aggregates. 8-/ > In the country I live in I can change telecom provider and take my > phone number with me to the new provider. Why shouldn't I be able to > do that with internet providers? PSTN routing is completely different. In Germany, routing is mostly static AFAIK, and there is no expectation that you can reach all phone numbers from every phone (and it doesn't work in some cases). From jorgen at hovland.cx Mon Nov 28 20:23:15 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 20:23:15 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: Message-ID: <200511281923.jASJNFpQ017677@mail03.hipercom.no> -----Original Message----- From: McTim [mailto:dogwallah at gmail.com] > >#2 sounds like PI to me. What have I missed? Hello McTim, You are correct. That?s why I wrote PI in the email:-). It is an attempt to suggest an alternative idea to the PI discussion. Don't get me wrong. I am for PI. This idea is perhaps a bit more hierarchical instead of the standard flat one. Just making sure we have thought of everything before we reach consensus because this PI discussion is very important to ipv6. Cheers, Joergen Hovland From jorgen at hovland.cx Mon Nov 28 20:29:55 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 20:29:55 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <877jas37kc.fsf@mid.deneb.enyo.de> Message-ID: <200511281930.jASJU0pQ017813@mail03.hipercom.no> -----Original Message----- From: Florian Weimer [mailto:fw at deneb.enyo.de] >This would imply that you cannot filter the routing table at prefix >lengths less than /48. What's worse, outage of an ISP routes traffic >to a now-unrelated ISP, which must discard traffic at its own cost. >Better get rid of the aggregates. 8-/ > >> In the country I live in I can change telecom provider and take my >> phone number with me to the new provider. Why shouldn't I be able to >> do that with internet providers? > >PSTN routing is completely different. In Germany, routing is mostly >static AFAIK, and there is no expectation that you can reach all phone >numbers from every phone (and it doesn't work in some cases). I can agree to that. So unless there are more to discuss in this matter may I suggest that somebody that really needs it, hello DENIC!:-), write a general PI proposal to speed up the process. Then maybe we all can begin using IPv6! That would be great. Cheers, Joergen Hovland From gih at apnic.net Tue Nov 29 00:15:27 2005 From: gih at apnic.net (Geoff Huston) Date: Tue, 29 Nov 2005 10:15:27 +1100 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> 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> Message-ID: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> At 03:37 AM 29/11/2005, J?rgen Hovland wrote: >----- Original Message ----- From: "Florian Weimer" >Sent: Saturday, November 26, 2005 4:00 PM > > >>* Jeroen Massar: >> >>>>1. Make /32 the only routable entity so we can use perfect match in >>>> the DFZ instead of longest-prefix match. >>> >>>What about the organizations that have say a /19, want them to inject >>>all their more specific /32's? >> >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the >>/19 is really used. >> >>At this stage, it's probably not too wise to embed the /32--/48--/64 >>in silicon, but vendors will undoubtedly do this if they can save a >>few bucks and current policies remain as inflexible as they are. > >Hi, >Perfect match is faster but far from better. What I think perhaps would be >interesting to see in the future with regards to IPv6 and PI is the following: > >1. No PI. _Only_ network operators get a prefix. >2. Customers of network operators can at any time change provider and take >their assigned prefix with them. The new provider will announce it as a >more specific overriding the aggregate. If the customer decides to get >multiple providers, then the network operator with the /32 could also >announce a more specific. > >In the country I live in I can change telecom provider and take my phone >number with me to the new provider. Why shouldn't I be able to do that >with internet providers? >Yes, it will somehow create millions/billions of prefixes (atleasat with >todays routing technology/protocols). Network operators should be able to >handle that hence rule #1. Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing. Then what? Geoff From sasad at cisco.com Tue Nov 29 00:55:16 2005 From: sasad at cisco.com (Salman Asadullah) Date: Mon, 28 Nov 2005 15:55:16 -0800 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> You seem to be far away from the ground realities. Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason. Regards, Salman At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: >On Thu, 24 Nov 2005, Oliver Bartels wrote: > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > If IPv4 offers PI = provider _independence_ and multihoming > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > those who requires this functionallity. > > > > Thus they won't use IPv6. > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > And as the majority of the large and a significant portion of medium > > size businesses are obviously not willing to accept an IP protocol not > > providing this functionallity, IPv6 will remain at it's current status: > > > > A technical playground for technically interested people. > >a very true point in one way but that is again as I see it, we're still >thinking IPv4 when talking IPv6. > >Why do they need multihoming and PI? They don't trust the ISP and vendors >to deliver them uptime and freedom... isn't this a problem the ISP and >vendors should try to solve? Of course, the idea of easy renumbering was >suppose to solve this but again, we're thinking IPv4 so it's not easy to >understand. > >Again, we don't need PI space and multihoming, what we need are a way to >give the users and GOOD connectivity (uptime, speed etc) and make it easy >for them to switch providers as they see fit. > > > > > > > > Hmm, please let me translate: > > "Even if the car doesn't drive and the engine doesn't deliver a single > > horse power at the wheels, drop the thought about driving, > > start to think about other way to use the possibility this great car > > gives us." > > > > Sound like newspeak: > > If we _think_ we can't solve the problem, drop discussing the problem. > >for several years this discussion have been going on, still no real >solution. IPv6 give us the freedom todo ALOT of things, USE those >possibilities, if we have to change how IP are done, some TCP headers etc, >then do it... propose a good idea and prove it. That could give us >multihoming. Actually there is a master thesis about howto create >connectivity for TCP session even if one of the links went down, the >session just used another IP (1)... the user don't notice anything >either and it have zero problem working with standard tcp-stacks since it >use the extended header of IPv6. > >That's just ONE of many possible ways... > > > >(1) it's a master thesis writting by a student related to University of >Troms?? as part of the Pasta project, www.pasta.cs.uit.no > >-- > >------------------------------ >Roger Jorgensen | >rogerj at stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger at jorgensen.no >------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Nov 29 08:49:17 2005 From: randy at psg.com (Randy Bush) Date: Mon, 28 Nov 2005 21:49:17 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> Message-ID: <17292.2045.5948.933479@roam.psg.com> > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > issues for a good reason. i gather that the message that leslie daigle was given at the last nanog was not well-transmitted to the ietf. no big surprise. you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram randy From oppermann at networx.ch Tue Nov 29 10:13:39 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Tue, 29 Nov 2005 10:13:39 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> Message-ID: <438C1BC3.5A7C7C24@networx.ch> Salman Asadullah wrote: > > You seem to be far away from the ground realities. > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > issues for a good reason. Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be workable they'd have to be implemented on every end-host out there. That is every operating system in sufficient existence. That puts IPv6 even further in the already distant future considering common OS upgrade and replacement cycles. Second this doesn't solve the renumbering problem. Renumbering is not just giving hosts new IP addresses but alost managing DNS and Firewalls. No even remotely workable and scaleable solution has been presented yet. So nice try but no cookie. -- Andre > Regards, > Salman > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > those who requires this functionallity. > > > > > > Thus they won't use IPv6. > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > And as the majority of the large and a significant portion of medium > > > size businesses are obviously not willing to accept an IP protocol not > > > providing this functionallity, IPv6 will remain at it's current status: > > > > > > A technical playground for technically interested people. > > > > a very true point in one way but that is again as I see it, we're still > > thinking IPv4 when talking IPv6. > > > > Why do they need multihoming and PI? They don't trust the ISP and vendors > > to deliver them uptime and freedom... isn't this a problem the ISP and > > vendors should try to solve? Of course, the idea of easy renumbering was > > suppose to solve this but again, we're thinking IPv4 so it's not easy to > > understand. > > > > Again, we don't need PI space and multihoming, what we need are a way to > > give the users and GOOD connectivity (uptime, speed etc) and make it easy > > for them to switch providers as they see fit. > > > > > > > > > > > > > > Hmm, please let me translate: > > > "Even if the car doesn't drive and the engine doesn't deliver a single > > > horse power at the wheels, drop the thought about driving, > > > start to think about other way to use the possibility this great car > > > gives us." > > > > > > Sound like newspeak: > > > If we _think_ we can't solve the problem, drop discussing the problem. > > > > for several years this discussion have been going on, still no real > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > possibilities, if we have to change how IP are done, some TCP headers etc, > > then do it... propose a good idea and prove it. That could give us > > multihoming. Actually there is a master thesis about howto create > > connectivity for TCP session even if one of the links went down, the > > session just used another IP (1)... the user don't notice anything > > either and it have zero problem working with standard tcp-stacks since it > > use the extended header of IPv6. > > > > That's just ONE of many possible ways... > > > > > > > > (1) it's a master thesis writting by a student related to University of > > Troms?? as part of the Pasta project, www.pasta.cs.uit.no > > > > -- > > > > ------------------------------ > > Roger Jorgensen | > > rogerj at stud.cs.uit.no | - IPv6 is The Key! > > http://www.jorgensen.no | roger at jorgensen.no > > ------------------------------------------------------- From heldal at eml.cc Tue Nov 29 12:21:52 2005 From: heldal at eml.cc (Per Heldal) Date: Tue, 29 Nov 2005 12:21:52 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> Message-ID: <1133263312.2928.248556295@webmail.messagingengine.com> On Mon, 28 Nov 2005 15:55:16 -0800, "Salman Asadullah" said: > You seem to be far away from the ground realities. > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > issues for a good reason. > Regardless of the efforts, from a provider POV it's only "work in progress". Make sure your preferred technology is implemented across all platforms and accompanied by solutions for traffic-engineering, filtering and other issues. Then you may have a viable alternative to present to the operators community. Don't expect anybody to adopt new technologies unless they represent some progress. I'm not saying that shim6 is DOA. It *may become* an alternative, but it *is not*. Unless you can convince content-providers to trust their upstream to provide redundancy and thus eliminate the need for end-site multihoming you have the following realistic short-term alternatives: * Keep ipv6 experimental and postpone operational deployment until there's a good technical solution to the multi-homing problem or a way to eliminate the DFZ and the related concerns about routing- table size. * Adopt a PI policy for v6 similar to the current v4-policy, and hope that moore can keep up with the growth of the routing-table. >From there policies will have to evolve, along with the development of new technology. Evolution is a perpetual process, not a project with a finite deadline. PS! am I missing something, or is IETF/IAB trying to copy the ITU in the way they produce paper-standards? Is that really such a good idea? //per -- Per Heldal heldal at eml.cc From jkuijer at dds.nl Tue Nov 29 12:25:59 2005 From: jkuijer at dds.nl (jkuijer at dds.nl) Date: Tue, 29 Nov 2005 12:25:59 +0100 Subject: [address-policy-wg] unsubscribe jkuijer@dds.nl In-Reply-To: <20051129110003.17431.64118.Mailman@postboy.ripe.net> References: <20051129110003.17431.64118.Mailman@postboy.ripe.net> Message-ID: <1133263559.438c3ac7aefe7@webmail.dds.nl> Citeren address-policy-wg-request at ripe.net: > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-admin at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: Re: [ipv6-wg] IPv6 PI (Randy Bush) > 2. Re: Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > --__--__-- > > Message: 1 > From: Randy Bush > Date: Mon, 28 Nov 2005 21:49:17 -1000 > To: Salman Asadullah > Cc: Roger Jorgensen , > Oliver Bartels , > "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > roger at jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > i gather that the message that leslie daigle was given at the > last nanog was not well-transmitted to the ietf. no big > surprise. > > you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram > > randy > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 10:13:39 +0100 > From: Andre Oppermann > To: Salman Asadullah > CC: Roger Jorgensen , > Oliver Bartels , > "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > roger at jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > Salman Asadullah wrote: > > > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be > workable they'd have to be implemented on every end-host out there. > That is every operating system in sufficient existence. That puts IPv6 > even further in the already distant future considering common OS upgrade > and replacement cycles. > > Second this doesn't solve the renumbering problem. Renumbering is not > just giving hosts new IP addresses but alost managing DNS and Firewalls. > No even remotely workable and scaleable solution has been presented yet. > > So nice try but no cookie. > > -- > Andre > > > > Regards, > > Salman > > > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > > those who requires this functionallity. > > > > > > > > Thus they won't use IPv6. > > > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > > > And as the majority of the large and a significant portion of medium > > > > size businesses are obviously not willing to accept an IP protocol not > > > > providing this functionallity, IPv6 will remain at it's current status: > > > > > > > > A technical playground for technically interested people. > > > > > > a very true point in one way but that is again as I see it, we're still > > > thinking IPv4 when talking IPv6. > > > > > > Why do they need multihoming and PI? They don't trust the ISP and vendors > > > to deliver them uptime and freedom... isn't this a problem the ISP and > > > vendors should try to solve? Of course, the idea of easy renumbering was > > > suppose to solve this but again, we're thinking IPv4 so it's not easy to > > > understand. > > > > > > Again, we don't need PI space and multihoming, what we need are a way to > > > give the users and GOOD connectivity (uptime, speed etc) and make it easy > > > for them to switch providers as they see fit. > > > > > > > > > > > > > > > > > > > > Hmm, please let me translate: > > > > "Even if the car doesn't drive and the engine doesn't deliver a single > > > > horse power at the wheels, drop the thought about driving, > > > > start to think about other way to use the possibility this great car > > > > gives us." > > > > > > > > Sound like newspeak: > > > > If we _think_ we can't solve the problem, drop discussing the problem. > > > > > > for several years this discussion have been going on, still no real > > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > > possibilities, if we have to change how IP are done, some TCP headers > etc, > > > then do it... propose a good idea and prove it. That could give us > > > multihoming. Actually there is a master thesis about howto create > > > connectivity for TCP session even if one of the links went down, the > > > session just used another IP (1)... the user don't notice anything > > > either and it have zero problem working with standard tcp-stacks since it > > > use the extended header of IPv6. > > > > > > That's just ONE of many possible ways... > > > > > > > > > > > > (1) it's a master thesis writting by a student related to University of > > > Troms?? as part of the Pasta project, www.pasta.cs.uit.no > > > > > > -- > > > > > > ------------------------------ > > > Roger Jorgensen | > > > rogerj at stud.cs.uit.no | - IPv6 is The Key! > > > http://www.jorgensen.no | roger at jorgensen.no > > > ------------------------------------------------------- > > > > > End of address-policy-wg Digest > From fw at deneb.enyo.de Tue Nov 29 15:26:53 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 29 Nov 2005 15:26:53 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> (Geoff Huston's message of "Tue, 29 Nov 2005 10:15:27 +1100") 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> Message-ID: <87fypfpm1e.fsf@mid.deneb.enyo.de> * Geoff Huston: > Interesting - it will work for a while, and then you will get to the limit > of deployed capability of routing. > > Then what? You buy new routers. What's next? Do you plan to lobby Hollywood to reduce the number of movies create per year, so that your customers have fewer of them to download, and the capacity of your pipes is not exceeded? From randy at psg.com Tue Nov 29 17:17:54 2005 From: randy at psg.com (Randy Bush) Date: Tue, 29 Nov 2005 06:17:54 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <1133263312.2928.248556295@webmail.messagingengine.com> Message-ID: <17292.32562.222522.723483@roam.psg.com> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real >> issues for a good reason. > Regardless of the efforts, from a provider POV it's only "work in > progress". one of the key points from the nanog session was that shim6 is the *wrong* work in progress. what is needed is _site_ multi-homing, not host multi-homing. randy From gih at apnic.net Tue Nov 29 19:34:05 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 30 Nov 2005 05:34:05 +1100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <17292.32562.222522.723483@roam.psg.com> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <1133263312.2928.248556295@webmail.messagingengine.com> <17292.32562.222522.723483@roam.psg.com> Message-ID: <6.2.0.14.2.20051130052140.02d34f10@kahuna.telstra.net> At 03:17 AM 30/11/2005, Randy Bush wrote: > >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > >> issues for a good reason. > > Regardless of the efforts, from a provider POV it's only "work in > > progress". > >one of the key points from the nanog session was that shim6 is the >*wrong* work in progress. what is needed is _site_ multi-homing, >not host multi-homing. "wrong"? "right"? Usual response - if you believe that there is a better way of doing this work through the issues here, then write up an approach, gather support, get peer review etc etc. As I said at NANOG, part of the problem with distributed models where there is action at a distance is to understand and clearly identify instances of gratuitous packet header rewriting by hostile agents as compared to packet rewriting by agents who believe that they are doing this in a friendly and helpful fashion. This becomes a challenging problem,of course. I don't think any single approach today is the one true right approach at this point, but unless we explore this space with some diligence, allow for experimentation and keep an open mind on this work then you are going to get intractably wedged between the desire for greater flexibility in the use of addresses as a form of semi-persistent endpoint identifiers and the desire for reduced flexibility in the use of addresses as forwarding tokens in order to keep the routing space confined to readily computable dimensions. But of course _all_ this will be solved in MPLS - right? :-) Geoff From gih at apnic.net Tue Nov 29 19:36:11 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 30 Nov 2005 05:36:11 +1100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87fypfpm1e.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> Message-ID: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> At 01:26 AM 30/11/2005, Florian Weimer wrote: >* Geoff Huston: > > > Interesting - it will work for a while, and then you will get to the limit > > of deployed capability of routing. > > > > Then what? > >You buy new routers. So what you are saying is that _I_ want address portability and _you_ have to buy new routers. Well that sure works for me! How's the chequebook feeling on your side? (I'm not convinced that you've selected the best of business models, as there does appear to be a significant inconsistency going on in your model in that cost and benefit are not related all that well.) Geoff From gih at apnic.net Tue Nov 29 20:01:56 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 30 Nov 2005 06:01:56 +1100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <438C1BC3.5A7C7C24@networx.ch> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <438C1BC3.5A7C7C24@networx.ch> Message-ID: <6.2.0.14.2.20051130054611.02d206d8@kahuna.telstra.net> At 08:13 PM 29/11/2005, Andre Oppermann wrote: >Salman Asadullah wrote: > > > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > >Neither Multi6 nor SHIM6 are even in an draft RFC state yet Multi6 produced 5 WG drafts, all of which have been published as RFCs You can (and probably should) read through RFCs 3582, 4116, 4177, 4219, and 4218 SHIM6 is working on the following drafts - again I would recommend that you read though all of them:... draft-ietf-shim6-app-refer, draft-ietf-shim6-applicability, draft-ietf-shim6-arch, draft-ietf-shim6-failure-detection, draft-ietf-shim6-hba, draft-ietf-shim6-proto, and draft-ietf-shim6-reach-detect. > and to be >workable they'd have to be implemented on every end-host out there. >That is every operating system in sufficient existence. That puts IPv6 >even further in the already distant future considering common OS upgrade >and replacement cycles. yep - any form of locator / identity split is such a basic shift in the architectural model used by IP that changes to the stack are required. This is the case in mobility, nomadism, ad-hoc networking and this form of multi-homing. If you want agile locators and any form of persistence in endpoint identifiers then you are not going to get that without changes to the stack. Now if you are arguing that the deployed base of IPv6 is so large that further changes are impossible in this particular technology due to the inertia of the deployed IPv6 base, then that's certainly an interesting perspective, and not one I've heard all that often so far. If you are saying that this will take time to develop and deploy, then you are probably right, and a model that can use incremental deployment using a conventional initial context followed by a capability exchange to explore if there is mutual support for this form of communication capability, then you may well be onto something interesting. Although I'd hasten to add that this is the approach being taken within the SHIM6 architecture. >Second this doesn't solve the renumbering problem. Renumbering is not >just giving hosts new IP addresses but alost managing DNS and Firewalls. >No even remotely workable and scaleable solution has been presented yet. I'm not sure I agree with you about the DNS and renumbering - its not a clearly defined space, and the implications relating to the DNS are not clearly understood in communication models where feasible locator sets are dynamically exchanged rather than always loaded into third party rendezvous points, as in the DNS model. >So nice try but no cookie. Thank you, Geoff From Michael.Dillon at btradianz.com Wed Nov 30 10:54:58 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 30 Nov 2005 09:54:58 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> Message-ID: > So what you are saying is that _I_ want address portability and _you_ have > to buy new routers. Why does inter-AS routing have to be done on the packet-forwarding gateways commonly called "routers"? If routing was done on boxes separate from the packet-forwarding gateways, it would be possible to handle much larger routing tables at much lower cost. The internal architecture of current routers has basically arrived at this solution already except that you are tied to the router manufacturer's hardware and pricelist. --Michael Dillon From william at elan.net Wed Nov 30 10:53:49 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 30 Nov 2005 01:53:49 -0800 (PST) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <6.2.0.14.2.20051130052140.02d34f10@kahuna.telstra.net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <1133263312.2928.248556295@webmail.messagingengine.com> <17292.32562.222522.723483@roam.psg.com> <6.2.0.14.2.20051130052140.02d34f10@kahuna.telstra.net> Message-ID: On Wed, 30 Nov 2005, Geoff Huston wrote: > At 03:17 AM 30/11/2005, Randy Bush wrote: >> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these >> real >> >> issues for a good reason. >> > Regardless of the efforts, from a provider POV it's only "work in >> > progress". >> >> one of the key points from the nanog session was that shim6 is the >> *wrong* work in progress. what is needed is _site_ multi-homing, >> not host multi-homing. Yes, well if it goes forward, it may well end up being used for setting up site-multihoming: http://www.ietf.org/mail-archive/web/architecture-discuss/current/msg00095.html and will be seen as friendly and right solution (on what "friendly" and "right" can mean seen below). > "wrong"? "right"? > > Usual response - if you believe that there is a better way of doing this > work through the issues here, then write up an approach, gather support, get > peer review etc etc. > > As I said at NANOG, part of the problem with distributed models where there > is action at a distance is to understand and clearly identify instances of > gratuitous packet header rewriting by hostile agents as compared to packet > rewriting by agents who believe that they are doing this in a friendly and > helpful fashion. This becomes a challenging problem,of course. If its hostile or friendly behavior is in the eye of the beholder - but in fact it may not even be only one side or the other for the same person. If I sit under a NAT and it prevents my application from running, I'm hostile to that behavior. But same NAT box may well be protecting my home network from intrusion and allowing me to have multiple computers connected through the same dsl/cable/wireless connection, so I'd view it as a friendly. Since most people don't notice its hostile behavior (due to kind of applications they run) and all notice its friendly behavior it will overall be seen as a friend and "right" solution. So is there better way to do it and without NAT? Of course there is - have real firewall and have block of ips - but NAT is winning as a business case because it can do those several friendly things well for almost everyone and without dependence on network provider and those few users who are inconvenienced and their application are viewed as minor percentage and not a problem in the overall business case. So business case won but IETF end-end tcp/ip architecture broken ... > I don't think any single approach today is the one true right approach at > this point, but unless we explore this space with some diligence, Diligence is the right word. But is it really the size of the routing table that we're being most concerned (considering #of routes in ipv6 will most definitely be smaller then with ipv4 because of less fragmentation - generally one ip block per ASN) or business case of users who do not want to be dependent on IP provider and RIR to be able to multihome? And should due diligence be applied so that proposed solution both makes sense to do for those who will use it (i.e. small businesses in case of shim6) an does not break applications when that is done? -- William Leibzon Elan Networks william at elan.net From dr at cluenet.de Wed Nov 30 17:16:47 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 30 Nov 2005 17:16:47 +0100 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> 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> Message-ID: <20051130161647.GA12947@srv01.cluenet.de> On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote: > >> Interesting - it will work for a while, and then you will get to the > >> limit of deployed capability of routing. > >> > >> Then what? > > > >You buy new routers. > > So what you are saying is that _I_ want address portability and _you_ have > to buy new routers. No, what he's saying is "_you_ want _my_ business, so _you_ have to deliver what _I_ want. If you cannot deliver, there is no business for _you_". 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). 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. IMHO PI can buy us the time to find Something New[tm] which delivers without the associated possible problems. Until then, there are two options: halt IPv6 completely, now, or implement as sensible PI policy (1 PI prefix per ASN, no questions asked) to buy us the time. I don't know which way is the better one. But this whole "go to IPv6 but no cookies^WPI for you" ain't fly, that for sure (IMHO, YMMV). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Wed Nov 30 17:21:29 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 30 Nov 2005 17:21:29 +0100 Subject: [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: <20051130162129.GB12947@srv01.cluenet.de> On Wed, Nov 30, 2005 at 05:16:47PM +0100, Daniel Roesen wrote: > On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote: > > >> Interesting - it will work for a while, and then you will get to the > > >> limit of deployed capability of routing. > > >> > > >> Then what? > > > > > >You buy new routers. > > > > So what you are saying is that _I_ want address portability and _you_ have > > to buy new routers. > > No, what he's saying is "_you_ want _my_ business, so _you_ have to > deliver what _I_ want. If you cannot deliver, there is no business for > _you_". > > 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). 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. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jeroen at unfix.org Wed Nov 30 19:13:42 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 30 Nov 2005 19:13:42 +0100 Subject: [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: <438DEBD6.1000207@unfix.org> Daniel Roesen wrote: > On Wed, Nov 30, 2005 at 05:16:47PM +0100, Daniel Roesen wrote: >> On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote: >>>>> Interesting - it will work for a while, and then you will get to the >>>>> limit of deployed capability of routing. >>>>> >>>>> Then what? >>>> You buy new routers. >>> So what you are saying is that _I_ want address portability and _you_ have >>> to buy new routers. >> No, what he's saying is "_you_ want _my_ business, so _you_ have to >> deliver what _I_ want. If you cannot deliver, there is no business for >> _you_". The 'you' here is a remote site where you have no (direct) business relationship with. For that remote site, especially with those words, there is no reason at all to any business with you. They are not going to invest any cash to upgrade their network for you (the I in the sentence). >> 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). But is it PI or a slot in the routing tables you want? The slot can be bought by giving a lot of cash to ISP's so that they accept your prefix. > 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. Why do you even go near the analogy of a Telco? I, nor any other endsite (who isn't a telco) can't do TE nor network-wide routing policies nor any of the other things that people like so much about in the current IPv4 with telephone systems. Telephone is much more like DNS than IP. If you want telco-style "IP portability" then simply (ahem) change (renumber) the IP's on your servers/firewalls etc and update DNS. As that is how a number is 'ported'. Also telco style means that all incoming traffic gets routed over your old ISP. Andre Opperman had a large explanation on this subject on NANOG a couple of weeks ago. See the thread around: http://www.merit.edu/mail.archives/nanog/2005-10/msg00782.html What you seem to want is "IPv6 PI", exactly the same thing as "IPv4 PI". The worry here: routing table size. As not only you will want this, but it might be that suddenly a million or so others also will want this in the future, 20 years and more maybe even 50. We could make a policy to give out "IPv6 PI" the IPv4 way but then we automatically end up with IPv6 swamp when ISP's start restricting the prefixes they accept because they don't want to buy yet another new routing setup. Also remember that to participate in it, you have to see everything, thus all the small fish (the ones needing "IPv6 PI") will require that big fancy new router, got cash for that? The only solution I see here is somewhat of the lines of: +-------------+ | l3 src | | l3 dst | +-------------+ | shim src | | shim dst | +-------------+ Where the 'shim' addresses are "PI" prefixes given out from a special block (eg a /16) where /40's and /48's come out of for the simple purpose that one doesn't have to renumber, just add links and enable your edge boxes to move the original l3 header to shim, and then adding the l3 addresses from the ISP. When the other side receives it, verify&strip the l3's (which are only used between transit/ISP's) and tada done. It's something you can call double NAT or tunneling and this is as far as I understood an extreme simplification of what shim6 is going to do, first per host, but very easily also per site. Indeed that doesn't allow those nice routing tricks to be defined, but if you want to be able to do that, then don't ask for "provider independent address space" but just say that you want a prefix that can be stuck, and then work, in global bgp/dfz*. Greets, Jeroen * = before the obvious person asks, the routing table that is seen by most ISP's on the "internet". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From bmanning at vacation.karoshi.com Wed Nov 30 18:12:58 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 30 Nov 2005 17:12:58 +0000 Subject: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130162129.GB12947@srv01.cluenet.de> 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> <20051130162129.GB12947@srv01.cluenet.de> Message-ID: <20051130171258.GB6570@vacation.karoshi.com.> > > 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). > > 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. > > > Regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 why does this remind me of the law passed (in several different jurisdictions, if the urban myths are to be believed) that mandated PI == 3.2. ... legal talent can not change some laws. --bill