From randy at psg.com Tue Dec 1 00:18:23 2009 From: randy at psg.com (Randy Bush) Date: Tue, 01 Dec 2009 08:18:23 +0900 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20091130160506.GF32226@Space.Net> References: <28E139F46D45AF49A31950F88C49745804488407@E03MVZ2-UKDY.domain1.systemhost.net> <82k4x89z9b.fsf@mid.bfk.de> <20091130160506.GF32226@Space.Net> Message-ID: > When and if the IETF decides that non-/64-subnets are a desirable > feature, waiting for the ietf to catch up to ops reality is broken. rough consensus and running code, and they are often quite unrelated. subnets longer than /64 are extremely common in practice, particularly point to point links. and yes, we can rat-hole on other uses, auto-conf, ... but let's not. randy From ip-office at kpn.com Tue Dec 1 09:12:23 2009 From: ip-office at kpn.com (IP-Office KPN) Date: Tue, 1 Dec 2009 09:12:23 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <0B6F9CD2-47E7-41CC-BCA0-5FAFB83FEC43@marcoh.net> References: <28E139F46D45AF49A31950F88C497458044FE07F@E03MVZ2-UKDY.domain1.systemhost.net> <0B6F9CD2-47E7-41CC-BCA0-5FAFB83FEC43@marcoh.net> Message-ID: I agree with Marco here. The policy (RIPE-481) states: 5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). With kind regards, ir. A.W. Hettema IP-Office KPN Internet +31(0)70 45 13398 ip-office at kpn.com -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Marco Hogewoning Sent: maandag 30 november 2009 22:21 To: michael.dillon at bt.com Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > That's not the point. A /60 assignment is wrong. If software > developers and equipment vendors get the idea that /60 is > normal, then they will embed that assumption in their products > and it will make the transition from 6RD to native v6 more > difficult. You keep repeating this but which document or standard says /60 is wrong ? > There is no need to make customer assignments smaller > than /56. But why ? I can imagine /60 is enough for Joe the plumber even if sensor networks would take off... MarcoH From remi.despres at free.fr Tue Dec 1 10:13:11 2009 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Tue, 1 Dec 2009 10:13:11 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458044FE07F@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458044FE07F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <31D74927-FB7C-4FD7-9248-63EE7465BEE2@free.fr> Le 30 nov. 2009 ? 22:15, a ?crit : > >> - Since RIRs allocate /32s and recommend to assign /48s to >> customers, each ISP having more than 64K customers should get >> at least a /28. With such a /28, any ISP that has several >> IPv4 prefixes can deploy 6rd with /60s assigned to all its >> customers (typically more than 64K). > > Wait a minute. If a /28 allocation is enough to assign /60 > blocks, then by giving the ISP 4 more subnetting bits, i.e. > a /24 allocation, they should be able to give /56 assignments > to all their customers. That is the way to do this properly. No objection to /24s being allocated, just the opposite: /24 is better than /28 and should IMHO be provided, but each RIR makes its own decisions, and ISPs have to adapt best to what they get. (If an ISP obtains only a /28, whatever the reason, offering /60s to its customers is better than /64s, and much better than no no IPv6 at all.) >> - A /60 per customer site is largely enough to start using >> IPv6, even for sophisticated users that configure several >> LANs in their sites. > > That's not the point. A /60 assignment is wrong. See the note above. > If software > developers and equipment vendors get the idea that /60 is > normal, then they will embed that assumption in their products > and it will make the transition from 6RD to native v6 more > difficult. They have no reason to do this. Equipment vendors don't have in general such poor designers. > There is no need to make customer assignments smaller > than /56. True if /24s are always available, which should be the goal. > >> - For an ISPs that initially gets only as /32 and has several >> IPv4 prefixes, assigning /64s to its customers is much better >> than no IPv6 at all (as Free has demonstrated, and because >> most sites don't support several LANs anyway). > > No, assigning /64s is far worse because their people will not > be properly trained, and when the word gets out, nobody will > want to work there because it will be a black mark on their > CV. Different view here. Free customers were happy to have native IPv6 as early as in December 2007, and many of them were proud to be among the first ones to use Google with native IPv6 addresses. I don't believe that my CV has been black marked for having pioneered IPv6 actual usage. > It is better to go back to RIPE, explain the situation, > and get a /24 or /21. That is doing both, depending on the case, which is better. >> o ISPs that don't obtain more generous IPv6 prefixes than >> /32s can at least start with /64s assigned to customers. > > This is called compounding your mistakes. Do not do this. Sorry: no regret for what you call a mistake, and what has been a great step in favor of IPv6. >> o RIRs should allocate at least /28s to ISPs that have >> several IPv4 prefixes and plan to deploy 6rd. > > Wrong. At least /28 includes /24 (and /24 is clearly better than /28). > RIRs should evaluate the size of allocation needed to > properly deploy 6RD using /56 assignments for customers, and > then allocate a block big enough to handle this deployment. Again, this seems fine to me. >> o These ISPs should return these prefixes if, for any reason, >> they become more generous than needed. > > That has always been part of the RIR rules. > And that is a major reason why people should be given huge > allocations to deploy 6RD, if they have decided that 6RD > is the best way to go. We do not want ISPs to get locked > into 6RD because of bad architectural decisions, so we > must ensure that they have enough address space to assign > /56 or /48 to all customer sites. Full agreement on this point ;-). Regards, RD > > --Michael Dillon > From michael.dillon at bt.com Tue Dec 1 11:00:47 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Dec 2009 10:00:47 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <31D74927-FB7C-4FD7-9248-63EE7465BEE2@free.fr> Message-ID: <28E139F46D45AF49A31950F88C497458044FE375@E03MVZ2-UKDY.domain1.systemhost.net> > > If software > > developers and equipment vendors get the idea that /60 is > normal, then > > they will embed that assumption in their products and it > will make the > > transition from 6RD to native v6 more difficult. > > They have no reason to do this. > Equipment vendors don't have in general such poor designers. What you say is true about major equipment vendors and maybe true about major software vendors. But for IPv6 to replace IPv4 as the Internet Protocol, we need thousands of minor vendors to provide products, including new products that were not possible with IPv4. For instance a home video system that runs on its own /64 subnet within the home. > Different view here. > Free customers were happy to have native IPv6 as early as in > December 2007, and many of them were proud to be among the > first ones to use Google with native IPv6 addresses. > I don't believe that my CV has been black marked for having > pioneered IPv6 actual usage. Pioneers get special benefits but if ISPs start to copy Free and use /60 blocks, the people at those ISPs aren't pioneering and their CVs will not look as pretty as yours. > Sorry: no regret for what you call a mistake, and what has > been a great step in favor of IPv6. Here in RIPE we have the opportunity to correct the situation that led to this mistake. Whether that means educating people that they can get big allocations and use /56 assignment blocks or whether that means changing policy, here we can do something about it. > At least /28 includes /24 (and /24 is clearly better than /28). I disagree in using arbitrary numbers here. The policy for allocations to ISPs is an area where IPv6 allocation rules are still based on justified need, like in IPv4. So the right way to do this is to recognize that 6RD is a new technology which creates a justified need for larger allocations than native IPv6. The only place for a specific number would be to have a maximum allocation size such as /24 or /21 in which case we would say "up to /21". > >> o These ISPs should return these prefixes if, for any reason, they > >> become more generous than needed. > > > > That has always been part of the RIR rules. > > And that is a major reason why people should be given huge > allocations > > to deploy 6RD, if they have decided that 6RD is the best > way to go. We > > do not want ISPs to get locked into 6RD because of bad > architectural > > decisions, so we must ensure that they have enough address space to > > assign > > /56 or /48 to all customer sites. > > Full agreement on this point ;-). --Michael Dillon From michael.dillon at bt.com Tue Dec 1 11:42:47 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Dec 2009 10:42:47 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <0B6F9CD2-47E7-41CC-BCA0-5FAFB83FEC43@marcoh.net> Message-ID: <28E139F46D45AF49A31950F88C497458044FE4D4@E03MVZ2-UKDY.domain1.systemhost.net> > > That's not the point. A /60 assignment is wrong. If software > > developers and equipment vendors get the idea that /60 is > normal, then > > they will embed that assumption in their products and it > will make the > > transition from 6RD to native v6 more difficult. > > You keep repeating this but which document or standard says > /60 is wrong ? RFC 3177 says that ISPs should assign a /48 to every site except in the case of very large subscribers. Geoff Huston did a paper some time ago that demonstrated a slim possibility of running out of IPv6 addresses using /48 everywhere and proposed a couple of small changes, one to the HD ratio, and dropping to /56 assignments for private residences. Some RIRs have adopted this into policy, but regardless of whether or not it is in RIPE policy, the /56 for private residences is still good practice and is being tracked by vendors. > > There is no need to make customer assignments smaller than /56. > > > But why ? I can imagine /60 is enough for Joe the plumber > even if sensor networks would take off... Because the whole point of giving sites a /48 is to ensure that they have more than enough so that 99% of them will never ever have to expand beyond /48. This business of /64, /48 and /32 quasi-classful boundaries is meant to stop the network architecture reshuffle that IPv4 forced on people whose networks were growing. There is a competition law aspect to this too. If everyone assigns their customers a /48 (or a /56 for private residences) then customers will be able to move to another ISP (competition) without restructuring their network. It will be a simple prefix change. This is one of the features of IPv6 to make renumbering easier. If an ISP assigns their customers /60 blocks then they are at risk that some of those customers could sue them under the competition laws because the /60 becomes an artificial barrier to changing ISPs. There just isn't any technical requirement to assign customers less than a /56 prefix. Even if RIPE policy does not yet mention /56 prefixes, they are still a good practice based on the findings of Geoff Huston. --Michael Dillon From swmike at swm.pp.se Tue Dec 1 12:10:21 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 1 Dec 2009 12:10:21 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458044FE4D4@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458044FE4D4@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Tue, 1 Dec 2009, michael.dillon at bt.com wrote: > regardless of whether or not it is in RIPE policy, the /56 > for private residences is still good practice and is being > tracked by vendors. Just for the record, I've reconsidered and now agree with Michael that we should hand out /24 to ISPs who want to run 6RD, to facilitate /56 handouts to end customers. I would want a discussion on this being 6RD exclusive use and a 5 year temporary handout with option for 5 year extension per time until the community deems that 6RD is depreciated and this space should no longer be used for that. Should we reserve a /8 for 6RD use, approximately one per ASN? Should we just say that a certain /8 is for 6RD use and it's not even handled by RIRs but instead handled like GLOP space for multicast, ie that it's just the ASN mapped into this space? Do we need a /6 to handle future 32bit ASN increase in the next 10 years? Perhaps there should be this kind of IPv4-mapped-into-IPv6-per-ASN space available for general use, not being 6RD exclusive? I do think this should be temporary though, with the aim at this being deprecated in 5-10 years. -- Mikael Abrahamsson email: swmike at swm.pp.se From remco.vanmook at eu.equinix.com Tue Dec 1 12:29:51 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Tue, 01 Dec 2009 12:29:51 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Message-ID: "Nothing is so permanent as a temporary government program." -- Dr. Milton Friedman If we decide to hand out /24s to 6RD and we think that?s not a waste of address space (even though nobody has been able to give me an satisfactory answer I?m willing to throw in the towel) make that a permanent allocation, not a temporary one. The pretense that people will actually hand back that prefix is, let?s say, not consistent with current experiences in IPv4. Once it?s out of the bag it?s out of the bag, never to return. Remco On 01-12-09 12:10, "Mikael Abrahamsson" wrote: > On Tue, 1 Dec 2009, michael.dillon at bt.com wrote: > >> > regardless of whether or not it is in RIPE policy, the /56 >> > for private residences is still good practice and is being >> > tracked by vendors. > > Just for the record, I've reconsidered and now agree with Michael that we > should hand out /24 to ISPs who want to run 6RD, to facilitate /56 > handouts to end customers. > > I would want a discussion on this being 6RD exclusive use and a 5 year > temporary handout with option for 5 year extension per time until the > community deems that 6RD is depreciated and this space should no longer be > used for that. > > Should we reserve a /8 for 6RD use, approximately one per ASN? Should we > just say that a certain /8 is for 6RD use and it's not even handled by > RIRs but instead handled like GLOP space for multicast, ie that it's just > the ASN mapped into this space? Do we need a /6 to handle future 32bit ASN > increase in the next 10 years? > > Perhaps there should be this kind of IPv4-mapped-into-IPv6-per-ASN space > available for general use, not being 6RD exclusive? > > I do think this should be temporary though, with the aim at this being > deprecated in 5-10 years. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue Dec 1 13:00:07 2009 From: jim at rfc1035.com (Jim Reid) Date: Tue, 1 Dec 2009 12:00:07 +0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: On 1 Dec 2009, at 11:29, Remco van Mook wrote: > If we decide to hand out /24s to 6RD and we think that?s not a waste > of > address space (even though nobody has been able to give me an > satisfactory > answer I?m willing to throw in the towel) make that a permanent > allocation, > not a temporary one. The pretense that people will actually hand > back that > prefix is, let?s say, not consistent with current experiences in > IPv4. Once > it?s out of the bag it?s out of the bag, never to return. Remco, all, I think these two issues should be separated. You're quite right to underline the absurdity of a policy discussion which is centred around "temporary" allocations. Once the space is given out, it's gone and will never be returned. So I agree wholeheartedly that the policy language should only concern itself with permanent allocations. If there's some other policy that requires temporary allocations for something, then there should be a clear time component to that, like the RIR reclaims the space from the LIR N months after its allocation. Not that that would apply to these 6RD allocations... As for the mechanics of /24s for 6RD, I'm still confused and uncertain. It's not clear why so much space is needed and if such allocations are wasteful or not. They don't look like an efficient use of address space. Then again, almost no IPv6 allocations can be space- efficient... [For some definition of that term.] My main concerns are how many LIRs will need/want these /24s, the precedents this sets and the impact they have on the overall supply of v6 address space. I fear we could be treating the abundance of IPv6 space the same way as a lottery winner might spend their money in a bar or casino: a *lot* of fun while it lasts. From michael.dillon at bt.com Tue Dec 1 13:06:45 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Dec 2009 12:06:45 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458044FE74B@E03MVZ2-UKDY.domain1.systemhost.net> > If we decide to hand out /24s to 6RD and we think that's not > a waste of address space (even though nobody has been able to > give me an satisfactory answer I'm willing to throw in the > towel) make that a permanent allocation, not a temporary one. Didn't we already see a quote from current RIPE policy telling us that all RIPE allocations are temporary? > The pretense that people will actually hand back that prefix > is, let's say, not consistent with current experiences in > IPv4. Once it's out of the bag it's out of the bag, never to return. Nowadays there are contracts to sign, and contracts can be enforced in the courts. --Michael Dillon From florian at frotzler.priv.at Tue Dec 1 13:16:27 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Tue, 1 Dec 2009 13:16:27 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> Jim, I can tell you that being forced to implement multiple SP prefixes might be a show-stopper for a numerous of ISPs to implement 6RD, including Swisscom, this is fact. It is a huge operational burden, especially for the IT stack, and means $$$ needed to be spend. So do we want to hamper the v6 rollout because we like to conserve some bits in an almost endless address space? Cheers, Florian 2009/12/1 Jim Reid : > On 1 Dec 2009, at 11:29, Remco van Mook wrote: > >> If we decide to hand out /24s to 6RD and we think that?s not a waste of >> address space (even though nobody has been able to give me an satisfactory >> answer I?m willing to throw in the towel) make that a permanent >> allocation, >> not a temporary one. The pretense that people will actually hand back that >> prefix is, let?s say, not consistent with current experiences in IPv4. >> Once >> it?s out of the bag it?s out of the bag, never to return. > > Remco, all, I think these two issues should be separated. > > You're quite right to underline the absurdity of a policy discussion which > is centred around "temporary" allocations. Once the space is given out, it's > gone and will never be returned. So I agree wholeheartedly that the policy > language should only concern itself with permanent allocations. If there's > some other policy that requires temporary allocations for something, then > there should be a clear time component to that, like the RIR reclaims the > space from the LIR N months after its allocation. Not that that would apply > to these 6RD allocations... > > As for the mechanics of /24s for 6RD, I'm still confused and uncertain. It's > not clear why so much space is needed and if such allocations are wasteful > or not. They don't look like an efficient use of address space. Then again, > almost no IPv6 allocations can be space-efficient... [For some definition of > that term.] My main concerns are how many LIRs will need/want these /24s, > the precedents this sets and the impact they have on the overall supply of > v6 address space. > > I fear we could be treating the abundance of IPv6 space the same way as a > lottery winner might spend their money in a bar or casino: a *lot* of fun > while it lasts. > From jim at rfc1035.com Tue Dec 1 13:47:36 2009 From: jim at rfc1035.com (Jim Reid) Date: Tue, 1 Dec 2009 12:47:36 +0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> Message-ID: <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> On 1 Dec 2009, at 12:16, Florian Frotzler wrote: > I can tell you that being forced to implement multiple SP prefixes > might be a show-stopper for a numerous of ISPs to implement 6RD, > including Swisscom, this is fact. It is a huge operational burden, > especially for the IT stack, and means $$$ needed to be spend. That may well be true Florian. I have no way of knowing because the case for these 6RD allocations compared to other approaches hasn't been made clearly enough. > So do we want to hamper the v6 rollout because we like to conserve > some bits > in an almost endless address space? Of course nobody wants to hamper v6 deployment. But that does not mean we should have a cavalier attitude to v6 allocations. It troubles me when people say v6 is "almost endless". It's not. And it will run out fairly quickly if the world and its dog can get a /24 (or more) from an RIR simply by saying "it's for 6RD" or whatever might be tomorrow's flavour-of-the-month v6 transition/deployment scheme. I'm reminded of the parallels of the early days of the Internet when Class B nets were automatically handed out by the NIC from the "almost endless" supply of IPv4. Please note that I'm not opposed to /24 allocations (or higher) for 6RD. If there's a clear need for them, then it should happen. Nobody should contest that. However the justification for these requests seems somewhat fuzzy. Which explains my caution/scepticism. From florian at frotzler.priv.at Tue Dec 1 13:54:43 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Tue, 1 Dec 2009 13:54:43 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> Message-ID: <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> Jim, I understand your sceptiscism but in the end the dog will never be a LIR, he will always be an endsite and the numeber of LIRs will always be finite. Cheers, Florian 2009/12/1 Jim Reid : > On 1 Dec 2009, at 12:16, Florian Frotzler wrote: > >> I can tell you that being forced to implement multiple SP prefixes >> might be a show-stopper for a numerous of ISPs to implement 6RD, >> including Swisscom, this is fact. It is a huge operational burden, >> especially for the IT stack, and means $$$ needed to be spend. > > That may well be true Florian. I have no way of knowing because the case for > these 6RD allocations compared to other approaches hasn't been made clearly > enough. > >> So do we want to hamper the v6 rollout because we like to conserve some >> bits >> in an almost endless address space? > > Of course nobody wants to hamper v6 deployment. But that does not mean we > should have a cavalier attitude to v6 allocations. It troubles me when > people say v6 is "almost endless". It's not. And it will run out fairly > quickly if the world and its dog can get a /24 (or more) from an RIR simply > by saying "it's for 6RD" or whatever might be tomorrow's > flavour-of-the-month v6 transition/deployment scheme. > > I'm reminded of the parallels of the early days of the Internet when Class B > nets were automatically handed out by the NIC from the "almost endless" > supply of IPv4. > > Please note that I'm not opposed to /24 allocations (or higher) for 6RD. If > there's a clear need for them, then it should happen. Nobody should contest > that. However the justification for these requests seems somewhat fuzzy. > Which explains my caution/scepticism. > From andy at nosignal.org Tue Dec 1 13:45:48 2009 From: andy at nosignal.org (Andy Davidson) Date: Tue, 1 Dec 2009 12:45:48 +0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458044FE4D4@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458044FE4D4@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <644BD683-AC63-4E9A-83D6-CABE948441A0@nosignal.org> On 1 Dec 2009, at 10:42, wrote: > If an ISP assigns their customers /60 blocks then they are at risk > that some of those customers could sue them under the competition > laws because the /60 > becomes an artificial barrier to changing ISPs. LOL. Andy From randy at psg.com Tue Dec 1 14:07:32 2009 From: randy at psg.com (Randy Bush) Date: Tue, 01 Dec 2009 22:07:32 +0900 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> Message-ID: > I understand your sceptiscism but in the end the dog will never be a > LIR, he will always be an endsite and the numeber of LIRs will always > be finite. the number of lirs, end sites, ipv6 addresses, ... will always be finite. so? randy From florian at frotzler.priv.at Tue Dec 1 14:14:45 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Tue, 1 Dec 2009 14:14:45 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> Message-ID: <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> so...we don't need to fear giving out /24 to LIRs, because LIRs are not coffee machines, refrigerators or other things which will get v6 in the future, so we will not run out of address space by handing out /24. I just wanted to contradict the metaphor Jim described. Cheers, Florian 2009/12/1 Randy Bush : >> I understand your sceptiscism but in the end the dog will never be a >> LIR, he will always be an endsite and the numeber of LIRs will always >> be finite. > > the number of lirs, end sites, ipv6 addresses, ... will always be > finite. ?so? > > randy > From randy at psg.com Tue Dec 1 14:17:01 2009 From: randy at psg.com (Randy Bush) Date: Tue, 01 Dec 2009 22:17:01 +0900 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> Message-ID: > so...we don't need to fear giving out /24 to LIRs, because LIRs are > not coffee machines, refrigerators or other things which will get v6 > in the future, so we will not run out of address space by handing out > /24. I just wanted to contradict the metaphor Jim described. i guess you are younger than jim or i. no fix sized bit string has even withstood the test of time. none. randy From florian at frotzler.priv.at Tue Dec 1 14:26:41 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Tue, 1 Dec 2009 14:26:41 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> Message-ID: <966645c70912010526p1a5147adre55b16aa27f562dd@mail.gmail.com> Do you expect IPv6 to last forever and that there will -> never <- be a successor? Me not. Everything has its life cycle (even if it's a very long one) because demands change over time. Florian 2009/12/1 Randy Bush : >> so...we don't need to fear giving out /24 to LIRs, because LIRs are >> not coffee machines, refrigerators or other things which will get v6 >> in the future, so we will not run out of address space by handing out >> /24. I just wanted to contradict the metaphor Jim described. > > i guess you are younger than jim or i. > > no fix sized bit string has even withstood the test of time. ?none. > > randy > From randy at psg.com Tue Dec 1 14:30:56 2009 From: randy at psg.com (Randy Bush) Date: Tue, 01 Dec 2009 22:30:56 +0900 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912010526p1a5147adre55b16aa27f562dd@mail.gmail.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <966645c70912010526p1a5147adre55b16aa27f562dd@mail.gmail.com> Message-ID: > Do you expect IPv6 to last forever with folk using profligacy in a naive nerd attempt at marketing, quite definitely not. probably about as long as ipv4. that is if the ipv6 priests don't prevent its serious use entirely by not allowing ops to roll it out parallel to v4 in dhcp, and all the other simple tools. randy From lutz at iks-jena.de Tue Dec 1 14:36:45 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 1 Dec 2009 13:36:45 +0000 (UTC) Subject: [address-policy-wg] IPv6 allocations for 6RD References: Message-ID: * Jim Reid wrote: > As for the mechanics of /24s for 6RD, I'm still confused and > uncertain. It's not clear why so much space is needed and if such > allocations are wasteful or not. They don't look like an efficient use > of address space. 6to4 is a transition technology based on anycast routing. Because several 6to4 anycast routers are badly managed, some people patched some implementations of the protocol to use PA-space instead of anycast. By switching the address space, the badly behaving routers out there needs not to be fixed, because anycast is not longer in use. The 6to4 mapping algorithm simply embed the whole IPv4 space into the 6to4-addresses. That's a clever trick and IPv6 encourages such tricks. By moving the address space, a lot of bits are determined by the existing IPv4 PA space of the ISP. A clever mapping is provided and possible with 6rd, but this configuration requires some clue to be done right. If the ISP has several disjunct PA spaces, configruation and provisioning can become complex. The question to the APWG is now: Do we want to hand out much more IPv6 space then necessary in order to allow the ISP to: - postphone the IPv6 deployment in the backbone (use 6rd instead) - do not fix the misbehaving routers out there (use unicast instead) - simplify the provisioning system (use a single, trival mapping instead) If the APWG does consider rapid rollout higher than address space, the policy should be changed. If the APWG does not consider changing addresses for saving money, the policy should remain as it is. My personal impression is, that all those problems does not exist. In order to overcome the anycast problems quickly, I submitted an IETF draft which allows unicast routing below an anycast fallback. This technology was tested years ago and worked well. For the other points, I personally feel bad by handing out addresses to those ISP which does not spend the necessary money in their infrastructure and managment systems. From florian at frotzler.priv.at Tue Dec 1 15:13:13 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Tue, 1 Dec 2009 15:13:13 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: <966645c70912010613v714d7406l995fac0d185c9271@mail.gmail.com> That's really funny, you explicitly mention "waste of address space" in your draft, trying to bash on the 6RD draft. You propagate waste of router memory and all the other funny stuff caused by large routing tables, which is really much better than handing out more bits to the LIRs. Cheers, Florian Am 1. Dezember 2009 14:36 schrieb Lutz Donnerhacke : > * Jim Reid wrote: >> As for the mechanics of /24s for 6RD, I'm still confused and >> uncertain. It's not clear why so much space is needed and if such >> allocations are wasteful or not. They don't look like an efficient use >> of address space. > > 6to4 is a transition technology based on anycast routing. > > Because several 6to4 anycast routers are badly managed, some people patched > some implementations of the protocol to use PA-space instead of anycast. By > switching the address space, the badly behaving routers out there needs not > to be fixed, because anycast is not longer in use. > > The 6to4 mapping algorithm simply embed the whole IPv4 space into the > 6to4-addresses. That's a clever trick and IPv6 encourages such tricks. > > By moving the address space, a lot of bits are determined by the existing > IPv4 PA space of the ISP. A clever mapping is provided and possible with > 6rd, but this configuration requires some clue to be done right. If the ISP > has several disjunct PA spaces, configruation and provisioning can become > complex. > > The question to the APWG is now: Do we want to hand out much more IPv6 space > then necessary in order to allow the ISP to: > ?- postphone the IPv6 deployment in the backbone (use 6rd instead) > ?- do not fix the misbehaving routers out there (use unicast instead) > ?- simplify the provisioning system (use a single, trival mapping instead) > > If the APWG does consider rapid rollout higher than address space, the > policy should be changed. If the APWG does not consider changing addresses > for saving money, the policy should remain as it is. > > My personal impression is, that all those problems does not exist. In order > to overcome the anycast problems quickly, I submitted an IETF draft which > allows unicast routing below an anycast fallback. This technology was tested > years ago and worked well. > > For the other points, I personally feel bad by handing out addresses to > those ISP which does not spend the necessary money in their infrastructure > and managment systems. > > From lutz at iks-jena.de Tue Dec 1 15:58:44 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 1 Dec 2009 14:58:44 +0000 (UTC) Subject: [address-policy-wg] IPv6 allocations for 6RD References: <966645c70912010613v714d7406l995fac0d185c9271@mail.gmail.com> Message-ID: * Florian Frotzler wrote: > That's really funny, you explicitly mention "waste of address space" > in your draft, trying to bash on the 6RD draft. You propagate waste of > router memory and all the other funny stuff caused by large routing > tables, which is really much better than handing out more bits to the > LIRs. Going personal in the discussion is not a recommended rethorical method. With an anycast fallback an router operator can safely remove more specific routing entries which are too far away. The problem is to fix the broken routers, not to throw away a whole /16. From florian at frotzler.priv.at Tue Dec 1 17:38:46 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Tue, 1 Dec 2009 17:38:46 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010613v714d7406l995fac0d185c9271@mail.gmail.com> Message-ID: <966645c70912010838k179bbf57j51932db0b462d95d@mail.gmail.com> Lutz, Discussing pros and cons of two different drafts on the mailing list is a good thing, bashing other drafts in your own, is not. What is a waste of address space in your point of view is a legitimate method for others. Nothing personal about this or anything I commented on your draft. Florian Am 1. Dezember 2009 15:58 schrieb Lutz Donnerhacke : > * Florian Frotzler wrote: >> That's really funny, you explicitly mention "waste of address space" >> in your draft, trying to bash on the 6RD draft. You propagate waste of >> router memory and all the other funny stuff caused by large routing >> tables, which is really much better than handing out more bits to the >> LIRs. > > Going personal in the discussion is not a recommended rethorical method. > > With an anycast fallback an router operator can safely remove more specific > routing entries which are too far away. The problem is to fix the broken > routers, not to throw away a whole /16. > > From drc at virtualized.org Tue Dec 1 18:06:35 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 1 Dec 2009 09:06:35 -0800 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> Message-ID: <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> On Dec 1, 2009, at 5:14 AM, Florian Frotzler wrote: > so...we don't need to fear giving out /24 to LIRs, because LIRs are > not coffee machines, refrigerators or other things which will get v6 > in the future, so we will not run out of address space by handing out > /24. I just wanted to contradict the metaphor Jim described. First, you are making the assumption that the connectivity model used with IPv4 will remain unchanged with IPv6. I am not so confident this will always be the case. Second, there are a bit under 2.1 million /24s in the global unicast IPv6 space. How long would you expect 2.1 /24s to last? Regards, -drc From florian at frotzler.priv.at Tue Dec 1 19:37:21 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Tue, 1 Dec 2009 19:37:21 +0100 Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> Message-ID: <000601ca72b5$523543f0$f69fcbd0$@priv.at> Hi, Sorry, I am not following, what do you mean with "the" connectivity model? @second: you are talking about the "001" FP space, I see plenty of reserved space if needed, also again the scope of the discussion is limited to ISPs who need the address space to do 6RD or similar transition methods, no one is asking to change the minimum allocation size to /24. I don?t assume that millions of ISPs will do 6RD. Cheers, Florian -----Urspr?ngliche Nachricht----- Von: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von David Conrad Gesendet: Dienstag, 1. Dezember 2009 18:07 An: Florian Frotzler Cc: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] IPv6 allocations for 6RD On Dec 1, 2009, at 5:14 AM, Florian Frotzler wrote: > so...we don't need to fear giving out /24 to LIRs, because LIRs are > not coffee machines, refrigerators or other things which will get v6 > in the future, so we will not run out of address space by handing out > /24. I just wanted to contradict the metaphor Jim described. First, you are making the assumption that the connectivity model used with IPv4 will remain unchanged with IPv6. I am not so confident this will always be the case. Second, there are a bit under 2.1 million /24s in the global unicast IPv6 space. How long would you expect 2.1 /24s to last? Regards, -drc From marc.neuckens at belgacom.be Tue Dec 1 21:53:10 2009 From: marc.neuckens at belgacom.be (marc.neuckens at belgacom.be) Date: Tue, 1 Dec 2009 21:53:10 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: All, Maybe some info to put this discussion in context. 1) Current Ipv6 allocations I made a distribution of Ipv6 allocations made by RIPE until now : Most are /32, but you see a few allocations bigger than /32, up to /19. /19 2 /20 2 /21 2 /22 2 /23 1 /24 2 /25 1 /26 3 /27 2 /28 1 /31 3 /32 1580 /33 51 /34 51 /35 102 This means that some LIR did a request with an address plan that justifies the bigger allocation. I might expect that most of them are not based on 6rd deployments. The biggest ones have been allocated in 2004, 2005, 2006. Conclusion : Even without 6rd some LIR can justify the allocation of big IPv6 allocations. I would expect that they have some vision on how they will use this big allocation in their network(s). Because of this I'm not in favour of temporary allocations for migration using 6rd. 2) Current LIR Today we have less than 7000 LIR in the RIPE region. (source : draft RIPE NCC charging scheme) Around 1650 LIR are Medium or bigger. Around 330 of these are Large or bigger. Less than 70 are Extra Large. These Large or Extra Large LIR have several 100.000 or millions of customers and multiple allocations Based on this info I see no issue that the IPRA (IP Resource Analyst) can allocate a bigger allocation than /32 based on a realistic address plan and good justification. Justification can be 6rd in a first phase and something else in a later phase. No need for special policy, just follow the existing Ipv6 address policy. Do you think that more than 1000 LIR will apply for an allocation bigger than /32 in the coming 3 years ? Marc Neuckens Belgacom **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From Remco.vanMook at eu.equinix.com Tue Dec 1 22:45:44 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Tue, 1 Dec 2009 22:45:44 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> Message-ID: <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> On the contrary. If 6RD is accepted as an argument for an allocation, and 6RD without any v4 prefix compression because of convenience, then every single applicant from then on will say they've got plans to deploy 6RD and can we please have the /24. They don't even need to lie, just be let's say 'optimistic'. It's not going to be temporary and it's not going to be 'a few' - also I shudder to think what the 1500-ish LIRs who already have a /32 allocation will do based on this. Probably get the extra /24 and not return the /32 because there's already some stuff in there that can't be migrated because it's too expensive and will hurt IPv6 deployment. The same arguments supporting 6RD right now. The good news is, this will double the IPv6 routing table in size. The bad news is, this will double the IPv6 routing table in size. Remco -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Florian Frotzler Sent: dinsdag 1 december 2009 19:37 To: 'David Conrad' Cc: address-policy-wg at ripe.net Subject: AW: [address-policy-wg] IPv6 allocations for 6RD Hi, Sorry, I am not following, what do you mean with "the" connectivity model? @second: you are talking about the "001" FP space, I see plenty of reserved space if needed, also again the scope of the discussion is limited to ISPs who need the address space to do 6RD or similar transition methods, no one is asking to change the minimum allocation size to /24. I don?t assume that millions of ISPs will do 6RD. Cheers, Florian -----Urspr?ngliche Nachricht----- Von: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von David Conrad Gesendet: Dienstag, 1. Dezember 2009 18:07 An: Florian Frotzler Cc: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] IPv6 allocations for 6RD On Dec 1, 2009, at 5:14 AM, Florian Frotzler wrote: > so...we don't need to fear giving out /24 to LIRs, because LIRs are > not coffee machines, refrigerators or other things which will get v6 > in the future, so we will not run out of address space by handing out > /24. I just wanted to contradict the metaphor Jim described. First, you are making the assumption that the connectivity model used with IPv4 will remain unchanged with IPv6. I am not so confident this will always be the case. Second, there are a bit under 2.1 million /24s in the global unicast IPv6 space. How long would you expect 2.1 /24s to last? Regards, -drc This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From marcoh at marcoh.net Wed Dec 2 08:43:14 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 2 Dec 2009 08:43:14 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> Message-ID: On 1 dec 2009, at 22:45, Remco van Mook wrote: > On the contrary. If 6RD is accepted as an argument for an > allocation, and 6RD without any v4 prefix compression because of > convenience, then every single applicant from then on will say > they've got plans to deploy 6RD and can we please have the /24. They > don't even need to lie, just be let's say 'optimistic'. > > It's not going to be temporary and it's not going to be 'a few' - > also I shudder to think what the 1500-ish LIRs who already have a / > 32 allocation will do based on this. Probably get the extra /24 and > not return the /32 because there's already some stuff in there that > can't be migrated because it's too expensive and will hurt IPv6 > deployment. The same arguments supporting 6RD right now. > > The good news is, this will double the IPv6 routing table in size. > The bad news is, this will double the IPv6 routing table in size. Let's not forget that I will probably announce my 6rd as more specifics to aid in load balancing traffic just as I do with my multiple IPv4 allocations. So routing table times 8 I guess, if we're lucky. I still find this a really bad idea, like Remco says everybody just happens to have plans for 6rd so if they please can get a /24, we might as well make it the default allocation size so people don't have to lie, uhhh be optismistic, about it. MarcoH From swmike at swm.pp.se Wed Dec 2 08:49:04 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Dec 2009 08:49:04 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> Message-ID: On Wed, 2 Dec 2009, Marco Hogewoning wrote: > Let's not forget that I will probably announce my 6rd as more specifics > to aid in load balancing traffic just as I do with my multiple IPv4 > allocations. So routing table times 8 I guess, if we're lucky. > > I still find this a really bad idea, like Remco says everybody just > happens to have plans for 6rd so if they please can get a /24, we might > as well make it the default allocation size so people don't have to lie, > uhhh be optismistic, about it. If we have separate space for /24 allocation policy then at least I can filter the de-aggregation and stop some of the madness. -- Mikael Abrahamsson email: swmike at swm.pp.se From marcoh at marcoh.net Wed Dec 2 08:53:40 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 2 Dec 2009 08:53:40 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> Message-ID: <839034CA-CC17-419F-B073-8E53E2E9F4F7@marcoh.net> On 2 dec 2009, at 08:49, Mikael Abrahamsson wrote: > On Wed, 2 Dec 2009, Marco Hogewoning wrote: > >> Let's not forget that I will probably announce my 6rd as more >> specifics to aid in load balancing traffic just as I do with my >> multiple IPv4 allocations. So routing table times 8 I guess, if >> we're lucky. >> >> I still find this a really bad idea, like Remco says everybody just >> happens to have plans for 6rd so if they please can get a /24, we >> might as well make it the default allocation size so people don't >> have to lie, uhhh be optismistic, about it. > > If we have separate space for /24 allocation policy then at least I > can filter the de-aggregation and stop some of the madness. Yeah and please make it a seperate policy then with hard words on actual deployment, you get the /24 and have 12 months to show up in google's statistics or you need to give it back. The same as some countries did with UMTS frequencies: use it or loose it. MarcoH From mueller at syr.edu Tue Dec 1 23:02:30 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 1 Dec 2009 17:02:30 -0500 Subject: [address-policy-wg] RE: IPv6 allocations for 6RD In-Reply-To: <20091129110004.31969.92849.Mailman@postboy.ripe.net> References: <20091129110004.31969.92849.Mailman@postboy.ripe.net> Message-ID: <75822E125BCB994F8446858C4B19F0D79AB7356C@SUEX07-MBX-04.ad.syr.edu> > 3.5. Conservation and Administrative Ease > Although IPv6 provides an extremely large pool of address space, > historical evidence shows that what now seems infinit might one day > turn out to become a scarce resource, Address policies should avoid > unnecessarily wasteful practices of such resources. Requests for > address space should be supported by appropriate documentation and > stockpiling of unused addresses should be avoided. Assignment of > address space based on the sole argument of administrative > ease is not permitted. Examples of this include, but are not limited > to, ease of billing administration and network management. I strongly agree with the concern that v6 addresses could be depleted quickly. This problem will never be solved appropriately until you impose fees for addresses that increase with the size of the block being requested. What you seem to be learning, the hard way, is that charging nothing for addresses requires you to ration the address space using highly subjective and purely verbal, unquantifiable criteria. Such as, the term "unnecessarily wasteful" which manages to be both tautological and unprecise. Or the term "administrative ease"; ok, after that becomes a policy no one will admit that they are requesting addresses for administrative ease but will that actually alter their request? Appropriately graduated annual fees enforce conservation AND reclamation while relieving the allocator of engaging in these verbal and categorical games Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From marcoh at marcoh.net Wed Dec 2 09:05:43 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 2 Dec 2009 09:05:43 +0100 Subject: [address-policy-wg] RE: IPv6 allocations for 6RD In-Reply-To: <75822E125BCB994F8446858C4B19F0D79AB7356C@SUEX07-MBX-04.ad.syr.edu> References: <20091129110004.31969.92849.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D79AB7356C@SUEX07-MBX-04.ad.syr.edu> Message-ID: On 1 dec 2009, at 23:02, Milton L Mueller wrote: > > >> 3.5. Conservation and Administrative Ease >> Although IPv6 provides an extremely large pool of address space, >> historical evidence shows that what now seems infinit might one day >> turn out to become a scarce resource, Address policies should avoid >> unnecessarily wasteful practices of such resources. Requests for >> address space should be supported by appropriate documentation and >> stockpiling of unused addresses should be avoided. Assignment of >> address space based on the sole argument of administrative >> ease is not permitted. Examples of this include, but are not limited >> to, ease of billing administration and network management. > > I strongly agree with the concern that v6 addresses could be > depleted quickly. > > This problem will never be solved appropriately until you impose > fees for addresses that increase with the size of the block being > requested. What you seem to be learning, the hard way, is that > charging nothing for addresses requires you to ration the address > space using highly subjective and purely verbal, unquantifiable > criteria. Such as, the term "unnecessarily wasteful" which manages > to be both tautological and unprecise. Or the term "administrative > ease"; ok, after that becomes a policy no one will admit that they > are requesting addresses for administrative ease but will that > actually alter their request? > > Appropriately graduated annual fees enforce conservation AND > reclamation while relieving the allocator of engaging in these > verbal and categorical games Hi Milton, There is already a coupling between charging and allocation size: http://www.ripe.net/ripe/docs/charging2010.html It might not be enough, but then again if we run out policies will be modified eventually like it happend with v4...from /8 to /21 initial in just 30 years. MarcoH From lutz at iks-jena.de Wed Dec 2 09:09:16 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Dec 2009 08:09:16 +0000 (UTC) Subject: [address-policy-wg] IPv6 allocations for 6RD References: Message-ID: * Mikael Abrahamsson wrote: > If we have separate space for /24 allocation policy then at least I can > filter the de-aggregation and stop some of the madness. Use the 2002::/16 space for 6to4 unicast routing. You do not need special software (works out of the box), you do not need special allocations, you only have to ask for route objects. If you do not accept those routes, the system still works. And if 6to4 get's depreceated sometimes, all those more specific routes, setup etc. will vanish altogether by dropping 2002::/16 ge 16 routes. From swmike at swm.pp.se Wed Dec 2 09:17:27 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Dec 2009 09:17:27 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: On Wed, 2 Dec 2009, Lutz Donnerhacke wrote: > * Mikael Abrahamsson wrote: >> If we have separate space for /24 allocation policy then at least I can >> filter the de-aggregation and stop some of the madness. > > Use the 2002::/16 space for 6to4 unicast routing. You do not need special > software (works out of the box), you do not need special allocations, you > only have to ask for route objects. If you do not accept those routes, the > system still works. > > And if 6to4 get's depreceated sometimes, all those more specific routes, > setup etc. will vanish altogether by dropping 2002::/16 ge 16 routes. No no no no. I do NOT want to duplicate the IPv4 table into IPv6 by doing that. I'd rather have a single /24 route per ASN for 6RD than multiple routes per ASN into 2002::/16. Also, the problem 6RD tries to solve won't be solved if I filter to only 2002::/16 and don't accept more specifics. -- Mikael Abrahamsson email: swmike at swm.pp.se From marcoh at marcoh.net Wed Dec 2 09:17:59 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 2 Dec 2009 09:17:59 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: On 2 dec 2009, at 09:09, Lutz Donnerhacke wrote: > * Mikael Abrahamsson wrote: >> If we have separate space for /24 allocation policy then at least I >> can >> filter the de-aggregation and stop some of the madness. > > Use the 2002::/16 space for 6to4 unicast routing. You do not need > special > software (works out of the box), you do not need special > allocations, you > only have to ask for route objects. If you do not accept those > routes, the > system still works. > > And if 6to4 get's depreceated sometimes, all those more specific > routes, > setup etc. will vanish altogether by dropping 2002::/16 ge 16 routes. If 6to4 would be the solution we don't need 6rd at all, there are already modems which implement 6to4, even more as there are which support 6rd. Based on last weeks discussion I don't think 6to4 is considered a solution at large. MarcoH From lutz at iks-jena.de Wed Dec 2 09:43:13 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Dec 2009 08:43:13 +0000 (UTC) Subject: [address-policy-wg] IPv6 allocations for 6RD References: Message-ID: * Mikael Abrahamsson wrote: > No no no no. I do NOT want to duplicate the IPv4 table into IPv6 by doing > that. I'd rather have a single /24 route per ASN for 6RD than multiple > routes per ASN into 2002::/16. Those people deploying 6rd are the only people which will announce more specifics. OTOH the discussion here raises a similar concern about 6rd address policy: "I do NOT want to duplicate the LIR table into IPv6 /24 allocations and announcements, especially if they are going to traffic engineer those further." > Also, the problem 6RD tries to solve won't be solved if I filter to only > 2002::/16 and don't accept more specifics. Which problem addresses 6rd? Using 6to4 technology to avoid deployment costs without fixing the broken anycast routers? From swmike at swm.pp.se Wed Dec 2 10:07:22 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Dec 2009 10:07:22 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: On Wed, 2 Dec 2009, Lutz Donnerhacke wrote: > Which problem addresses 6rd? Using 6to4 technology to avoid deployment > costs without fixing the broken anycast routers? Yes, that is my understanding. -- Mikael Abrahamsson email: swmike at swm.pp.se From florian at frotzler.priv.at Wed Dec 2 10:20:42 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 2 Dec 2009 10:20:42 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> Message-ID: <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> Hi Marco, I am slow in understanding, please clarify on this. Why exactly would 6RD lead to more specifics? There are certainly reasons for load balancing v6 traffic, but what changes 6RD in comparison to dual stack? Cheers, Florian 2009/12/2 Marco Hogewoning : > > On 1 dec 2009, at 22:45, Remco van Mook wrote: > >> On the contrary. If 6RD is accepted as an argument for an allocation, and >> 6RD without any v4 prefix compression because of convenience, then every >> single applicant from then on will say they've got plans to deploy 6RD and >> can we please have the /24. They don't even need to lie, just be let's say >> 'optimistic'. >> >> It's not going to be temporary and it's not going to be 'a few' - also I >> shudder to think what the 1500-ish LIRs who already have a /32 allocation >> will do based on this. Probably get the extra /24 and not return the /32 >> because there's already some stuff in there that can't be migrated because >> it's too expensive and will hurt IPv6 deployment. The same arguments >> supporting 6RD right now. >> >> The good news is, this will double the IPv6 routing table in size. The bad >> news is, this will double the IPv6 routing table in size. > > > Let's not forget that I will probably announce my 6rd as more specifics to > aid in load balancing traffic just as I do with my multiple IPv4 > allocations. So routing table times 8 I guess, if we're lucky. > > I still find this a really bad idea, like Remco says everybody just happens > to have plans for 6rd so if they please can get a /24, we might as well make > it the default allocation size so people don't have to lie, uhhh be > optismistic, about it. > > MarcoH > > From marcoh at marcoh.net Wed Dec 2 10:31:11 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 2 Dec 2009 10:31:11 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> Message-ID: On 2 dec 2009, at 10:20, Florian Frotzler wrote: > Hi Marco, > > I am slow in understanding, please clarify on this. Why exactly would > 6RD lead to more specifics? There are certainly reasons for load > balancing v6 traffic, but what changes 6RD in comparison to dual > stack? Well I can only assume what happens, but given the number of perfectly good /16's that get broken into small pieces 'because it is otherwise hard to loadbalance' What those people usually struggle with is that they have 2 uplinks, but one large CDN picking a particulair route will saturate one of them, so the break it up to split the traffic over multiple upstreams. It lead to the same problem if all of a sudden a large portion of their traffic moves to the /24 single annoucement, especially since they haven't invested too much in IPv6 connectivity. This of course can be solved by buying a bigger pipe, but then again the whole /24 can be avoided by running multiple instances of 6RD, since that was put down as additional cost I have no hopes on the /24 as well. MarcoH From florian at frotzler.priv.at Wed Dec 2 10:38:50 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 2 Dec 2009 10:38:50 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> Message-ID: <966645c70912020138u42fa2c81t501904c05a6c9a61@mail.gmail.com> Hi Marco, I think you're having a bug in your model. The larger prefix for 6RD is needed to stuff the 32 bit v4 addresses into the v6 addresses. The larger prefix does not mean there are more customers or more traffic than with implementing dual stack. So in terms of bandwidth your argument is false. If there are reasons to load balance, they are exactly the same with 6RD as with dual stack. Cheers, Florian 2009/12/2 Marco Hogewoning : > > On 2 dec 2009, at 10:20, Florian Frotzler wrote: > >> Hi Marco, >> >> I am slow in understanding, please clarify on this. Why exactly would >> 6RD lead to more specifics? There are certainly reasons for load >> balancing v6 traffic, but what changes 6RD in comparison to dual >> stack? > > > Well I can only assume what happens, but given the number of perfectly good > /16's that get broken into small pieces 'because it is otherwise hard to > loadbalance' What those people usually struggle with is that they have 2 > uplinks, but one large CDN picking a particulair route will saturate one of > them, so the break it up to split the traffic over multiple upstreams. > > It lead to the same problem if all of a sudden a large portion of their > traffic moves to the /24 single annoucement, especially since they haven't > invested too much in IPv6 connectivity. This of course can be solved by > buying a bigger pipe, but then again the whole /24 can be avoided by running > multiple instances of 6RD, since that was put down as additional cost I have > no hopes on the /24 as well. > > MarcoH > > From marcoh at marcoh.net Wed Dec 2 10:45:28 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 2 Dec 2009 10:45:28 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912020138u42fa2c81t501904c05a6c9a61@mail.gmail.com> References: <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> <966645c70912020138u42fa2c81t501904c05a6c9a61@mail.gmail.com> Message-ID: On 2 dec 2009, at 10:38, Florian Frotzler wrote: > Hi Marco, > > I think you're having a bug in your model. The larger prefix for 6RD > is needed to stuff the 32 bit v4 addresses into the v6 addresses. The > larger prefix does not mean there are more customers or more traffic > than with implementing dual stack. So in terms of bandwidth your > argument is false. If there are reasons to load balance, they are > exactly the same with 6RD as with dual stack. If there is any bug in whatever model it's 6RD itself which does not permit to use a from of compression to mapp multiple prefixes into a smaller block. Regarding bandwidth, what would happen if you provide your customers with 6RD and all of a sudden youtube advertises a AAAA ? If bandwidth is not an argument, then please explain why people deaggregate ? MarcoH From florian at frotzler.priv.at Wed Dec 2 10:52:49 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 2 Dec 2009 10:52:49 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> <966645c70912020138u42fa2c81t501904c05a6c9a61@mail.gmail.com> Message-ID: <966645c70912020152k3e9a141bn4f3246dddc56cd85@mail.gmail.com> 2009/12/2 Marco Hogewoning : > > On 2 dec 2009, at 10:38, Florian Frotzler wrote: > >> Hi Marco, >> >> I think you're having a bug in your model. The larger prefix for 6RD >> is needed to stuff the 32 bit v4 addresses into the v6 addresses. The >> larger prefix does not mean there are more customers or more traffic >> than with implementing dual stack. So in terms of bandwidth your >> argument is false. If there are reasons to load balance, they are >> exactly the same with 6RD as with dual stack. > > > If there is any bug in whatever model it's 6RD itself which does not permit > to use a from of compression to mapp multiple prefixes into a smaller block. We had this discussion already, don't know why we have to discuss it again, the draft does allow for compression but in operational reality this is a nightmare, as I already stated multiple times. > Regarding bandwidth, what would happen if you provide your customers with > 6RD and all of a sudden youtube advertises a AAAA ? If bandwidth is not an > argument, then please explain why people deaggregate ? You understood me wrong. I will try to explain it differently. If you migrate 1 million customers to IPv6 using 6RD or dual stack, they have native IPv6 in both cases so there will be no difference in traffic. So it just doesn't matter with which technology I bring IPv6 to my customers regarding load balancing (and hence announcing more specifics) requirements. But it does very much matter in terms of $$$ I have to spend to bring IPv6 to my customers. > MarcoH > > Florian From marcoh at marcoh.net Wed Dec 2 10:57:55 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 2 Dec 2009 10:57:55 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70912020152k3e9a141bn4f3246dddc56cd85@mail.gmail.com> References: <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> <966645c70912020138u42fa2c81t501904c05a6c9a61@mail.gmail.com> <966645c70912020152k3e9a141bn4f3246dddc56cd85@mail.gmail.com> Message-ID: <87F61A01-87EE-45C3-89C1-876853D5507D@marcoh.net> On 2 dec 2009, at 10:52, Florian Frotzler wrote: > 2009/12/2 Marco Hogewoning : >> >> On 2 dec 2009, at 10:38, Florian Frotzler wrote: >> >>> Hi Marco, >>> >>> I think you're having a bug in your model. The larger prefix for 6RD >>> is needed to stuff the 32 bit v4 addresses into the v6 addresses. >>> The >>> larger prefix does not mean there are more customers or more traffic >>> than with implementing dual stack. So in terms of bandwidth your >>> argument is false. If there are reasons to load balance, they are >>> exactly the same with 6RD as with dual stack. >> >> >> If there is any bug in whatever model it's 6RD itself which does >> not permit >> to use a from of compression to mapp multiple prefixes into a >> smaller block. > > We had this discussion already, don't know why we have to discuss it > again, the draft does allow for compression but in operational reality > this is a nightmare, as I already stated multiple times. Yeah and you almost got me convinced, I have a small portion of my network which I know will not do IPv6 native for the next decade. I might deploy 6RD there and since we intend to go for /48 on native, I have to do /48 on 6RD as well, does this entitle me to a /16 ? You seem to keep ignoring the fact that I don't think 'administrative ease' is a valid argument to waste addresses. >> Regarding bandwidth, what would happen if you provide your >> customers with >> 6RD and all of a sudden youtube advertises a AAAA ? If bandwidth is >> not an >> argument, then please explain why people deaggregate ? > > You understood me wrong. I will try to explain it differently. If you > migrate 1 million customers to IPv6 using 6RD or dual stack, they have > native IPv6 in both cases so there will be no difference in traffic. > So it just doesn't matter with which technology I bring IPv6 to my > customers regarding load balancing (and hence announcing more > specifics) requirements. But it does very much matter in terms of $$$ > I have to spend to bring IPv6 to my customers. 6RD encapsulation and decapsulation comes for free ? MarcoH From florian at frotzler.priv.at Wed Dec 2 11:07:44 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 2 Dec 2009 11:07:44 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <87F61A01-87EE-45C3-89C1-876853D5507D@marcoh.net> References: <000601ca72b5$523543f0$f69fcbd0$@priv.at> <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> <966645c70912020120g28a929d0l15cdd578b7255ac7@mail.gmail.com> <966645c70912020138u42fa2c81t501904c05a6c9a61@mail.gmail.com> <966645c70912020152k3e9a141bn4f3246dddc56cd85@mail.gmail.com> <87F61A01-87EE-45C3-89C1-876853D5507D@marcoh.net> Message-ID: <966645c70912020207x739ae6b2na0630819eabdfedd@mail.gmail.com> > Yeah and you almost got me convinced, I have a small portion of my network > which I know will not do IPv6 native for the next decade. I might deploy 6RD > there and since we intend to go for /48 on native, I have to do /48 on 6RD > as well, does this entitle me to a /16 ? > > You seem to keep ignoring the fact that I don't think 'administrative ease' > is a valid argument to waste addresses. No, Marco, be both stated our point of views, we obviously have different networks to manage and it seems we will not agree on this issue. Let's just accept that and go on. >>> Regarding bandwidth, what would happen if you provide your customers with >>> 6RD and all of a sudden youtube advertises a AAAA ? If bandwidth is not >>> an >>> argument, then please explain why people deaggregate ? >> >> You understood me wrong. I will try to explain it differently. If you >> migrate 1 million customers to IPv6 using 6RD or dual stack, they have >> native IPv6 in both cases so there will be no difference in traffic. >> So it just doesn't matter with which technology I bring IPv6 to my >> customers regarding load balancing (and hence announcing more >> specifics) requirements. But it does very much matter in terms of $$$ >> I have to spend to bring IPv6 to my customers. > > > 6RD encapsulation and decapsulation comes for free ? Again, your network seems to be a nice one, where almost all network devices and IT tools are v6 ready. Congratulations. But I think we develop policys here for all kind of networks, shouldn't we? 6RD is not for free but it is -> much <- cheaper than dual stack in some scenarios, like the one I am faced with when deploying v6. > MarcoH > > Florian From michael.dillon at bt.com Wed Dec 2 12:50:06 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 Dec 2009 11:50:06 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34D89@NLEN1EX1.eu.win.equinix.com> Message-ID: <28E139F46D45AF49A31950F88C4974580455EC80@E03MVZ2-UKDY.domain1.systemhost.net> > It's not going to be temporary and it's not going to be 'a > few' - also I shudder to think what the 1500-ish LIRs who > already have a /32 allocation will do based on this. 6RD costs money. There will not be very many ISPs doing 6RD and the 1500 LIRs are not going to derail their existing deployment efforts. It costs money to implement 6RD, it costs money to operate 6RD and it costs money to remove/replace 6RD with native IPv6. The organizations that will use 6RD are the ones who get a financial benefit from delaying spending on native IPv6. Perhaps they have older routers in their network that are not yet end-of-life. Or perhaps their systems support tools are coded in unreadable PERL code by people who left the company 10 years ago. 6RD is not a magic bullet, just one more option to consider for migrating the complex path between today's IPv4 Internet and the native IPv6 Internet of 2015. And as others have pointed out, we can afford to give every RIPE LIR a /24 if we have to. There is no reason to panic and this is not a slippery slope situation since real-world considerations limit the number of LIRs who would use 6RD. > Probably > get the extra /24 and not return the /32 because there's > already some stuff in there that can't be migrated because > it's too expensive and will hurt IPv6 deployment. The same > arguments supporting 6RD right now. This is not a question of arguments. The 1500 LIRs who already have IPv6 allocations are already running IPv6 services. Many of them have customers using their IPv6 services already. It is possible that some of them might decide to use 6RD for their broadband because of complex issues with the broadband access network, but given that leased line and data centre services are generally more profitable, or tied to more profitable customer contracts, I don't see why anyone would want to migrate away from an existing /32 allocation. > The good news is, this will double the IPv6 routing table in > size. The bad news is, this will double the IPv6 routing > table in size. Not very relevant. The IPv6 routing table is not that big right now, the addressing architecture tends to limit growth of this table and vendors have already demonstrated the ability to handle much bigger routing tables than today. --Michael Dillon From michael.dillon at bt.com Wed Dec 2 13:03:04 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 Dec 2009 12:03:04 -0000 Subject: [address-policy-wg] RE: IPv6 allocations for 6RD In-Reply-To: <75822E125BCB994F8446858C4B19F0D79AB7356C@SUEX07-MBX-04.ad.syr.edu> Message-ID: <28E139F46D45AF49A31950F88C4974580455ECC4@E03MVZ2-UKDY.domain1.systemhost.net> > I strongly agree with the concern that v6 addresses could be > depleted quickly. > > This problem will never be solved appropriately until you > impose fees for addresses that increase with the size of the > block being requested. Wrong! We can solve this problem the same way that we solved IPv4 runout. As long as we have IPv9 ready to deploy by 2050, we can avoid any risks of IPv6 addresses running out. And because of the timeline, we can address other issues such as making the minimum MTU 9192, allocating both global unicast and geographical unicast address ranges, upgrading core routing to BGP5extensible, integrating the RIR's PKI and identifier/locator registry into the routing, and so on. We don't even have to start work on the IPv9 design until 2030 or so, which gives plenty of time for people to gain large-scale IPv6 operational experience. --Michael Dillon P.S. Some problems just melt away when you look up and see the context. It's like looking down the barrel of a loaded 45 magnum pointed at you by a hardened criminal, and looking up to see the TV screen in your living room and attached Playstation 3. What looks like a problem, really isn't one. From michael.dillon at bt.com Wed Dec 2 13:04:57 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 Dec 2009 12:04:57 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C4974580455ECD0@E03MVZ2-UKDY.domain1.systemhost.net> > > Which problem addresses 6rd? Using 6to4 technology to avoid > deployment > > costs without fixing the broken anycast routers? > > Yes, that is my understanding. What are the broken anycast routers? Why can't they be fixed? --Michael Dillon From jim at rfc1035.com Wed Dec 2 13:50:14 2009 From: jim at rfc1035.com (Jim Reid) Date: Wed, 2 Dec 2009 12:50:14 +0000 Subject: [address-policy-wg] gazing into the future In-Reply-To: <28E139F46D45AF49A31950F88C4974580455ECC4@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580455ECC4@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <80E201FF-066F-4068-A6B9-76425DF37355@rfc1035.com> On 2 Dec 2009, at 12:03, wrote: > As long as we have IPv9 ready to deploy by 2050, > we can avoid any risks of IPv6 addresses running out. First, I find it staggering that anyone is contemplating -- even in passing -- a replacement for IPv6 and a shopping list of features for that when the level of IPv6 uptake is so low. It's unwise to assume there is no risk of IPv6 addresses running out. The same mistake was made ~25 years ago when ARPAnet transitioned from NCP to IP. A 32-bit address space was then considered too big to fill. ISTR similar claims being made when 32-bit and 64-bit CPUs were introduced: nobody could ever use all of that address space. The same goes for disks. These are almost always full, no matter how big they get. A variant of Parkinson's Law probably applies here, namely bloat and inefficiency will always expand to fill or exceed whatever addressing capability is provided. Remember too that since each customer will in all probability get a / 64 from their ISP, the effective size of the IPv6 address space in the core of the network is 64 bits. It's still a very big number: just not as big as first thought. And that won't last long if the world and its dog gets a /24 or more for 6RD or whatever... > We don't even have to start work on the IPv9 design until > 2030 or so, which gives plenty of time for people to gain > large-scale IPv6 operational experience. Assuming there is wide-scale IPv6 deployment and usage by then. BTW if your claims are correct, this presumes the IETF can complete the development of IPv9 in 20 years. Which seems... well... optimistic. :-) The DNSSEC protocol been chugging through the IETF machine for over 10 years. From swmike at swm.pp.se Wed Dec 2 13:56:32 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Dec 2009 13:56:32 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C4974580455ECD0@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580455ECD0@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Wed, 2 Dec 2009, michael.dillon at bt.com wrote: > What are the broken anycast routers? Why can't they be fixed? Because we (humanity) keep screwing up regarding MTU, capacity planning and other general operational practices, I postulate that 6to4 is never going to be a fully working service, there will always be users affected by badly run 6to4 anycasted relays. Running MTU1280 when doing 6to4 solves quite a lot of the problems, but it's still hard to localise problems when they occur because of the asymmetric nature of 6to4. -- Mikael Abrahamsson email: swmike at swm.pp.se From remi.despres at free.fr Wed Dec 2 14:34:11 2009 From: remi.despres at free.fr (=?ISO-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Wed, 02 Dec 2009 14:34:11 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <28E139F46D45AF49A31950F88C4974580455ECD0@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B166CD3.2080403@free.fr> Mikael Abrahamsson a ?crit : > Running MTU1280 when doing 6to4 solves quite a lot of the problems, Agreed. > but > it's still hard to localise problems when they occur because of the > asymmetric nature of 6to4. Agreed too. As long as it is not guaranteed that all tier-1 operators have 6to4 relays, there will be 6to4 black holes, hard to predict and identify. This is avoided with 6rd which is safe, as theory shows and practice confirms. RD From luis.g.cunha at netcabo.pt Wed Dec 2 14:40:09 2009 From: luis.g.cunha at netcabo.pt (Luis Cunha) Date: Wed, 2 Dec 2009 13:40:09 +0000 Subject: [address-policy-wg] Allocated net 109.48/14 having problems accessing aome web sites Message-ID: Hello, ZON is a major ISP in Portugal, and the complains from customers with an IP address within 109.48/14 trying to access some web sites is increasing daily. Anybody with a solution different from sending a mail to each webmaster? Regards, Luis Cunha From lutz at iks-jena.de Wed Dec 2 15:20:10 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Dec 2009 14:20:10 +0000 (UTC) Subject: [address-policy-wg] IPv6 allocations for 6RD References: <4B166CD3.2080403@free.fr> Message-ID: * R?mi Despr?s wrote: > This is avoided with 6rd which is safe, as theory shows and practice > confirms. More specific unicast of 2002::/16 also proofed to work in production. And now? Nobody has an interest in fixing the broken routers for 2002::/16? So let's take a new prefix from the pool and iterate until other technical problems occur? Then take the next prefix ... Sorry, drop and waste is not the recommended allocation policy for any ressource. From michael.dillon at bt.com Wed Dec 2 15:53:21 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 Dec 2009 14:53:21 -0000 Subject: [address-policy-wg] RE: gazing into the future In-Reply-To: <80E201FF-066F-4068-A6B9-76425DF37355@rfc1035.com> Message-ID: <28E139F46D45AF49A31950F88C4974580455F03E@E03MVZ2-UKDY.domain1.systemhost.net> > First, I find it staggering that anyone is contemplating -- > even in passing -- a replacement for IPv6 and a shopping list > of features for that when the level of IPv6 uptake is so low. Some of us are dreamers and wonder what could be done if we could just sweep away the old. If you look at history, sweeping away the old does happen from time to time. Stroll down London's Regent Street and there is not a trace of the squalid slum that was there before the Prince Regent swept it away. On most Central London streets you can still see the traces of the medieval city in the layout and size of the buildings. But not on Regent Street. There are some serious researchers also doing work on redesigning the Internet from scratch. Perhaps the reason for doing this is BECAUSE the uptake of IPv6 is currently so low, and BECAUSE we realize that many of the reasons for this is that IPv6 ideas were tacked onto the IPv4 network and therefore we won't get the benefit of those ideas from upgrading. This lays bare all the inadequacies of IPv6 and people naturally look for ways to remove those inadequacies but replacing IPv6 is not currently feasible. Also, it is likely that a new generation of engineers without the baggage of IPv4, will be better able to make a fresh start on IPv9. > It's unwise to assume there is no risk of IPv6 addresses > running out. That's what I said. Since there is a risk of it running out in 100 years or so, we should plan to create a better replacement for it in 30-50 years, and avoid the whole issue. > The same mistake was made ~25 years ago when ARPAnet > transitioned from NCP to IP. A 32-bit address space was then > considered too big to fill. The arithmetic was rather different in those days. You really should read Geoff Huston's. One source of these numbers is this ARIN presentation We really should ask Geoff to revisit the numbers in light of 6RD and the larger allocations that might happen. I get the sense that this would not cause a problem as long as we assume that 6RD will be decommissioned within 5 to 10 years. There is no point in discussing possible runout without some actual figures in the discussion because IPv4 and IPv6 are several orders of magnitude different. It becomes obvious when you work through the figures. > Remember too that since each customer will in all probability get a / > 64 from their ISP, No, a /56 or /48 > the effective size of the IPv6 address > space in the core of the network is 64 bits. IPv6 addresses are 128 bits everywhere. The core uses full addresses. > BTW if your claims are correct, this presumes the IETF can > complete the development of IPv9 in 20 years. Which seems... well... > optimistic. :-) I never mentioned IETF. In any case, the people who do the work 30 years from now will not be the same people who did the IPv6 work. --Michael Dillon From drc at virtualized.org Wed Dec 2 17:29:14 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 2 Dec 2009 08:29:14 -0800 Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <000601ca72b5$523543f0$f69fcbd0$@priv.at> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> Message-ID: <4D98FE1A-3B7F-407B-A092-7DB8E54752D8@virtualized.org> On Dec 1, 2009, at 10:37 AM, Florian Frotzler wrote: > Sorry, I am not following, what do you mean with "the" connectivity model? Apologies, I should have said 'allocation' instead of 'connectivity'. You appear to be assuming a small number of LIRs because that's what we have now. Given the proliferation of PI allocation policies and the likelihood (at least in my mind) of increased dependence on IP connectivity as a basic service implying less tolerance for even momentary outages resulting in increased demand for multi-homing, it is unclear to me that the current model will hold. > @second: you are talking about the "001" FP space, Yes. > I see plenty of reserved space if needed, You may see it, but to put that space into play would require the IETF to tell IANA that another FP has been specified as global unicast since we blew through 001 because we were allocating 1,099,511,627,776 /64s to every ISP that asked. Might be a bit of a hard sell. > also again the scope of the discussion is limited to ISPs > who need the address space to do 6RD or similar transition methods, no one > is asking to change the minimum allocation size to /24. I don?t assume that > millions of ISPs will do 6RD. As has been pointed out by others, why bother accepting the minimum when you can simply (and honestly) claim 6RD? Regards, -drc From gert at space.net Wed Dec 2 17:53:19 2009 From: gert at space.net (Gert Doering) Date: Wed, 2 Dec 2009 17:53:19 +0100 Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4D98FE1A-3B7F-407B-A092-7DB8E54752D8@virtualized.org> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <4D98FE1A-3B7F-407B-A092-7DB8E54752D8@virtualized.org> Message-ID: <20091202165319.GY32226@Space.Net> Hi, On Wed, Dec 02, 2009 at 08:29:14AM -0800, David Conrad wrote: > As has been pointed out by others, why bother accepting the minimum > when you can simply (and honestly) claim 6RD? Because it's big enough? Speaking as the LIR contact for a smallish ISP - we received a /32 from RIPE, and we expect this to be sufficient to number all our customers (and all their friends) from it. We're a hosting and business ISP these days, and we just don't have 100.000+ customers to worry about. There would not be any benefit in a larger allocation (except when trying to win ****-size boasting), but it would most likely move us to a larger billing category at RIPE. Which is not a huge amount of money, if there were a benefit to it - but if all the reason is "because we like numbers!", my management would not be happy with me. So - permit the question: why should a LIR bother explaining their 6rd deployment plans (and I'm sure that the IPRAs would ask some questions) *and* pay more, just to get a bit larger huge amount of numbers...? Gert Doering -- LIR contact -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From drc at virtualized.org Wed Dec 2 17:56:27 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 2 Dec 2009 08:56:27 -0800 Subject: [address-policy-wg] RE: IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C4974580455ECC4@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580455ECC4@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Dec 2, 2009, at 4:03 AM, wrote: > We can solve this problem the same way that we solved IPv4 runout. Heh. We haven't solved IPv4 runout. We've largely investigated interesting geometries we can rearrange the deck chairs into on the Titanic. As far as I can tell, the jury is still out as to whether IPv6 will win over IPv4 + multilayer NAT. > As long as we have IPv9 ready to deploy by 2050, > we can avoid any risks of IPv6 addresses running out. One of the reasons IPv6 has had some difficulty getting off the ground is due to the large installed base of IPv4 that sees no particular benefit in moving to IPv6. IPv4 is now a core component of critical infrastructure all over the planet. Switching out critical global infrastructure is not something that is trivially done; you need deployable transition plans, business cases, backwards compatibility, etc., all stuff that was not really addressed with IPv6 because it is really, really hard. And (assuming IPv6 does win) you're suggesting that after we've spent half a century of deploying critical infrastructure globally on IPv6 that we'll just go and redeploy IPv9? Are you assuming the Singularity will have been reached and a god-like AI will solve the problems for us? Regards, -drc From florian at frotzler.priv.at Wed Dec 2 18:39:04 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 2 Dec 2009 18:39:04 +0100 Subject: AW: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4D98FE1A-3B7F-407B-A092-7DB8E54752D8@virtualized.org> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <4D98FE1A-3B7F-407B-A092-7DB8E54752D8@virtualized.org> Message-ID: <000001ca7376$582252a0$0866f7e0$@priv.at> If I take a look at the latest CIDR report, we have about 33k different AS numbers in the current routing table. Assuming that 1 AS = 1 LIR, just for simplicity, can someone explain me why the business models could ever change in the next 30 to 60 years that we will have 2 million LIRs? And even if we have 2.000.000 LIRs in 2070, I am quite sure IETF would open a new FP range at that time for another 2.000.000 LIRs without questioning anything. Contrary to that I can easily imagine that some LIRs might increase the number of endsites by some factors because of new business models. So they would then need to ask for larger allocations, which pollutes the routing table and we are again in the same situation as today. Cheers, Florian -----Urspr?ngliche Nachricht----- Von: David Conrad [mailto:drc at virtualized.org] Gesendet: Mittwoch, 2. Dezember 2009 17:29 An: Florian Frotzler Cc: address-policy-wg at ripe.net Betreff: Re: AW: [address-policy-wg] IPv6 allocations for 6RD On Dec 1, 2009, at 10:37 AM, Florian Frotzler wrote: > Sorry, I am not following, what do you mean with "the" connectivity model? Apologies, I should have said 'allocation' instead of 'connectivity'. You appear to be assuming a small number of LIRs because that's what we have now. Given the proliferation of PI allocation policies and the likelihood (at least in my mind) of increased dependence on IP connectivity as a basic service implying less tolerance for even momentary outages resulting in increased demand for multi-homing, it is unclear to me that the current model will hold. > @second: you are talking about the "001" FP space, Yes. > I see plenty of reserved space if needed, You may see it, but to put that space into play would require the IETF to tell IANA that another FP has been specified as global unicast since we blew through 001 because we were allocating 1,099,511,627,776 /64s to every ISP that asked. Might be a bit of a hard sell. > also again the scope of the discussion is limited to ISPs > who need the address space to do 6RD or similar transition methods, no one > is asking to change the minimum allocation size to /24. I don?t assume that > millions of ISPs will do 6RD. As has been pointed out by others, why bother accepting the minimum when you can simply (and honestly) claim 6RD? Regards, -drc From drc at virtualized.org Wed Dec 2 19:49:10 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 2 Dec 2009 10:49:10 -0800 Subject: AW: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <000001ca7376$582252a0$0866f7e0$@priv.at> References: <966645c70912010416h557a0f2cq42580057a88475c4@mail.gmail.com> <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <4D98FE1A-3B7F-407B-A092-7DB8E54752D8@virtualized.org> <000001ca7376$582252a0$0866f7e0$@priv.at> Message-ID: On Dec 2, 2009, at 9:39 AM, Florian Frotzler wrote: > If I take a look at the latest CIDR report, we have about 33k different AS > numbers in the current routing table. Assuming that 1 AS = 1 LIR, just for > simplicity, can someone explain me why the business models could ever change > in the next 30 to 60 years that we will have 2 million LIRs? As I said in the message you top-posted on: "Given the proliferation of PI allocation policies and the likelihood (at least in my mind) of increased dependence on IP connectivity as a basic service implying less tolerance for even momentary outages resulting in increased demand for multi-homing, it is unclear to me that the current model will hold." Just one example. Hard to predict what will happen in 30 to 60 years. 30 years ago the Internet as we know it didn't exist. Seems a bit questionable to me to allocate the IPv6 equivalent of class As when we haven't the slightest idea how things will evolve and we have experience in blowing through an "inconceivably large address space". > And even if we > have 2.000.000 LIRs in 2070, I am quite sure IETF would open a new FP range > at that time for another 2.000.000 LIRs without questioning anything. "Without questioning"? Have you actually participated in the IETF? Regards, -drc From florian at frotzler.priv.at Thu Dec 3 06:12:07 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Thu, 3 Dec 2009 06:12:07 +0100 Subject: AW: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <8CF266A5-C54D-465B-A873-64BDCA7B415B@rfc1035.com> <966645c70912010454u37cf9a2cwc4b53500f97ac5df@mail.gmail.com> <966645c70912010514p5a51d441uc2a999235e23f0eb@mail.gmail.com> <31C54F48-ACC6-4549-B296-DEF7DF9F83C9@virtualized.org> <000601ca72b5$523543f0$f69fcbd0$@priv.at> <4D98FE1A-3B7F-407B-A092-7DB8E54752D8@virtualized.org> <000001ca7376$582252a0$0866f7e0$@priv.at> Message-ID: <966645c70912022112u22656aau8a519ae909205ca8@mail.gmail.com> 2009/12/2 David Conrad : > On Dec 2, 2009, at 9:39 AM, Florian Frotzler wrote: >> If I take a look at the latest CIDR report, we have about 33k different AS >> numbers in the current routing table. Assuming that 1 AS = 1 LIR, just for >> simplicity, can someone explain me why the business models could ever change >> in the next 30 to 60 years that we will have 2 million LIRs? > > As I said in the message you top-posted on: > > "Given the proliferation of PI allocation policies and the likelihood > (at least in my mind) of increased dependence on IP connectivity as a basic > service implying less tolerance for even momentary outages resulting in > increased demand for multi-homing, it is unclear to me that the current > model will hold." > > Just one example. ?Hard to predict what will happen in 30 to 60 years. 30 years ago the Internet as we know it didn't exist. Seems a bit questionable to me to allocate the IPv6 equivalent of class As when we haven't the slightest idea how things will evolve and we have experience in blowing through an "inconceivably large address space". I don't know what will be in 30 years either but your statement does not contain any argument why I should believe that the number of LIRs will explode. >> And even if we >> have 2.000.000 LIRs in 2070, I am quite sure IETF would open a new FP range >> at that time for another 2.000.000 LIRs without questioning anything. > > "Without questioning"? ?Have you actually participated in the IETF? This was maybe a little bit of a bad wording, it was more meant as a kind of figure of speech. > Regards, > -drc Florian From michael.dillon at bt.com Thu Dec 3 10:51:28 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 Dec 2009 09:51:28 -0000 Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20091202165319.GY32226@Space.Net> Message-ID: <28E139F46D45AF49A31950F88C497458045BC424@E03MVZ2-UKDY.domain1.systemhost.net> > So - permit the question: why should a LIR bother explaining > their 6rd deployment plans (and I'm sure that the IPRAs would > ask some questions) > *and* pay more, just to get a bit larger huge amount of numbers...? You should disclose your 6RD plans to pay less. RIPE issues a revised charging plan every year. See here for the 2010 plan The billing category is calculated according to an algorithm which is part of the charging plan. It is not that difficult to adjust the algorithm to not count 6RD allocations since they are a proxy for the IPv4 allocations that are already being scored. It is premature to claim that fees would be higher if you get a large allocation for 6RD. --Michael Dillon From fweimer at bfk.de Thu Dec 3 10:55:13 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Dec 2009 09:55:13 +0000 Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458045BC424@E03MVZ2-UKDY.domain1.systemhost.net> (michael dillon's message of "Thu\, 3 Dec 2009 09\:51\:28 -0000") References: <28E139F46D45AF49A31950F88C497458045BC424@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <82y6lkfkla.fsf@mid.bfk.de> * michael dillon: > The billing category is calculated according to an algorithm > which is part of the charging plan. It is not that difficult > to adjust the algorithm to not count 6RD allocations since > they are a proxy for the IPv4 allocations that are already > being scored. That's the way it is with 6to4. 6RD can (and should) be different in this regard. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From gert at space.net Thu Dec 3 10:58:12 2009 From: gert at space.net (Gert Doering) Date: Thu, 3 Dec 2009 10:58:12 +0100 Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458045BC424@E03MVZ2-UKDY.domain1.systemhost.net> References: <20091202165319.GY32226@Space.Net> <28E139F46D45AF49A31950F88C497458045BC424@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20091203095812.GA32226@Space.Net> Hi, On Thu, Dec 03, 2009 at 09:51:28AM -0000, michael.dillon at bt.com wrote: > It is premature to claim that fees would be higher if you get > a large allocation for 6RD. It's highly unlikely to assume there will be consensus for "give me more addresse for less money, if all I need to do is speak the magic word" in the AGM. Of course we *could* do that - but in that case, I see significant resistance for loosening up the address policy for 6rd deployments (quite obvious from the discussion so far). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From michael.dillon at bt.com Thu Dec 3 11:00:22 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 Dec 2009 10:00:22 -0000 Subject: AW: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458045BC45E@E03MVZ2-UKDY.domain1.systemhost.net> > Seems a bit questionable to me to allocate the IPv6 > equivalent of class As when we haven't the slightest idea how > things will evolve and we have experience in blowing through > an "inconceivably large address space". The IPv6 equivalent of a class A address block is a /8. We are not talking about allocating /8s to anyone, we are mainly talking about allocating /24s which are the equivalent of IPv4 class C blocks. This is one area where the IPv4 arithmetic and IPv6 arithemetic match up nicely. If you are worried about using up all the addresses, an IPv6 /24 and an IPv4 /24 use up the same percentage of the total address space. The very fact that we are discussing allocations in the region of /19 to /24 demonstrates the success of IPv6 in expanding the size of the address space. In IPv4, a really big ISP would get a /8. In IPv6 we can handle a really big ISP with one /13 and a medium sized ISP can fit into a /32, which in IPv4 can only handle a single host. When discussing the risk of runout, you have to look at actual numbers and actual percentages of the total number space. I suggest examining some of Geoff Huston's work in more detail. --Michael Dillon From jim at rfc1035.com Thu Dec 3 13:08:29 2009 From: jim at rfc1035.com (Jim Reid) Date: Thu, 3 Dec 2009 12:08:29 +0000 Subject: [address-policy-wg] an arithmetic lesson In-Reply-To: <28E139F46D45AF49A31950F88C497458045BC45E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458045BC45E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On 3 Dec 2009, at 10:00, wrote: > an IPv6 /24 and an IPv4 /24 use up the same percentage of the total > address space. How do you work that out? Please enlighten me. 2^24/2^128 x 100 is many orders of magnitude smaller than 2^24/2^32 x 100: gromit% bc scale=50 2^24/2^128*100 .00000000000000000000000000000493038065763132378300 2^24/2^32*100 .39062500000000000000000000000000000000000000000000 There are of course the same number of IPv4 and IPv6 /24s. From michael.dillon at bt.com Thu Dec 3 13:23:49 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 Dec 2009 12:23:49 -0000 Subject: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458045BC7ED@E03MVZ2-UKDY.domain1.systemhost.net> > On 3 Dec 2009, at 10:00, wrote: > > > an IPv6 /24 and an IPv4 /24 use up the same percentage of the total > > address space. > > How do you work that out? Please enlighten me. 2^24/2^128 x > 100 is many orders of magnitude smaller than 2^24/2^32 x 100: > gromit% bc > scale=50 > 2^24/2^128*100 > .00000000000000000000000000000493038065763132378300 > 2^24/2^32*100 > .39062500000000000000000000000000000000000000000000 > > There are of course the same number of IPv4 and IPv6 /24s. Percentage is calculated by dividing the number of things under consideration by the total number of things. When I used the word "an", I meant one thing. Assuming that the number of IPv4 and IPv6 /24s is 10 1/10 = 1/10 Assuming that the number of IPv4 and IPv6 /24s is 8192 1/8192 = 1/8192 Assuming that the number of IPv4 and IPv6 /24s is 2882873787 1/2882873787 = 1/2882873787 Do you see a pattern forming? --Michael Dillon From lutz at iks-jena.de Thu Dec 3 11:23:39 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 3 Dec 2009 10:23:39 +0000 (UTC) Subject: AW: AW: [address-policy-wg] IPv6 allocations for 6RD References: <966645c70912022112u22656aau8a519ae909205ca8@mail.gmail.com> Message-ID: * Florian Frotzler wrote: > I don't know what will be in 30 years either but your statement does > not contain any argument why I should believe that the number of LIRs > will explode. Deploying IP to the cars using the current policy can result in a bizzare result: Every car manufacturer becomes a LIR (category large) to supply /56 per car for mobile IPv6. Every equipment manufacturer becomes a LIR to supply a /64 for each sold entertainment fuzz to be connected via NEMOv6. From michael.dillon at bt.com Thu Dec 3 14:20:07 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 Dec 2009 13:20:07 -0000 Subject: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458045BC8E5@E03MVZ2-UKDY.domain1.systemhost.net> > As I understand: > Or not ? I don't know. The simple fact is that a /24 block is the set of addresses that use the same prefix which is defined by a 24-bit netmask. That means, that all of the addresses in the block will have the same pattern in the first 24 bits. Asking how many /24 blocks can be carved out of the total numberspace is equivalent to asking how many unique patterns there are of 24 binary digits. It should be obvious that the number of unique patterns of 24 binary digits is the same regardless of whether you use the first 24 bits out of a total of 32, or the first 24 bits out of a total of 128. One single /24 block is the same percentage of the total numberspace regardless of whether the protocol is v4 or v6. --Michael Dillon From DMenzulskiy at beeline.ru Thu Dec 3 13:55:29 2009 From: DMenzulskiy at beeline.ru (Dmitriy V Menzulskiy) Date: Thu, 3 Dec 2009 15:55:29 +0300 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: <28E139F46D45AF49A31950F88C497458045BC7ED@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: > > > On 3 Dec 2009, at 10:00, wrote: > > > > > an IPv6 /24 and an IPv4 /24 use up the same percentage of the total > > > address space. > > > > How do you work that out? Please enlighten me. 2^24/2^128 x > > 100 is many orders of magnitude smaller than 2^24/2^32 x 100: > > gromit% bc > > scale=50 > > 2^24/2^128*100 > > .00000000000000000000000000000493038065763132378300 > > 2^24/2^32*100 > > .39062500000000000000000000000000000000000000000000 > > > > There are of course the same number of IPv4 and IPv6 /24s. > > Percentage is calculated by dividing the number of things > under consideration by the total number of things. When > I used the word "an", I meant one thing. > > Assuming that the number of IPv4 and IPv6 /24s is 10 > > 1/10 = 1/10 > > Assuming that the number of IPv4 and IPv6 /24s is 8192 > > 1/8192 = 1/8192 > > Assuming that the number of IPv4 and IPv6 /24s is 2882873787 > > 1/2882873787 = 1/2882873787 > > Do you see a pattern forming? > > --Michael Dillon > As I understand: IPv4 /24 is (Total IPv4)/(2^24) IPv6 /24 is (Total IPv6)/(2^24) Or not ? WBR, Dmitry Menzulskiy, DM3740-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexlh at ripe.net Thu Dec 3 14:28:51 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Thu, 3 Dec 2009 14:28:51 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: <3CA66B76-B6E9-4E2D-A248-E9A5BB3162EF@ripe.net> Dear Colleagues, During the discussion on the APWG list about 6rd, several people have inquired about the exact way Registration Services evaluates requests for 6rd deployment. This email will try to answer these inquiries. The RIPE NCC considers current policy to be completely agnostic to 6rd, it neither specifically supports nor disallows 6rd deployment. This means that Registration Services will evaluate IPv6 allocation requests that include 6rd deployments according to the established policies and procedures of justified need. During the evaluation of an IPv6 allocation request the IPRA will look at the assignment size and the expected number of assignments to arrive at the size of the allocation that is justified. When an LIR wants to deploy 6rd by encoding the full 32 bits of the IPv4 addresses in the IPv6 end-user prefix, the allocation that would be needed is often much larger than would otherwise be justified using this principle as almost all of the reserved end-user prefixes would remain unused. Two examples with some numbers: An average size ISP has 1 million residential customers, intends to deploy 6rd and assign each end-user a /48. 1 million /48 end-site assignments would justify a /28, ignoring for the moment other requirements such as LIR infrastructure that might require more space. Deploying 6rd by encoding the full 32 bits of the IPv4 address would inflate the need to a /16. Currently, in this case, the IPRA would not consider allocating a /16 to be justified. Another LIR, who has 3 million customers, intends to deploy 6rd with / 60 assignments. Currently, the IPRA would consider 3 million /60 assignments to fit into a /38, thus the default /32, while the 6rd deployment would require a /28. Note that neither of these LIRs would qualify easily for an additional allocation under the HD-ratio rules. Best regards, Alex Le Heux RIPE NCC From Martin.Hindley at Level3.com Thu Dec 3 14:54:38 2009 From: Martin.Hindley at Level3.com (Hindley, Martin) Date: Thu, 3 Dec 2009 13:54:38 +0000 Subject: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: <28E139F46D45AF49A31950F88C497458045BC8E5@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458045BC8E5@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: /24 is ~0.000006% of whole ipv4 space (256 / 4294967296) /24 is ~0.000006% of whole ipv6 space (2^104 / 2^128) Regards Martin Hindley -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of michael.dillon at bt.com Sent: 03 December 2009 13:20 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] RE: an arithmetic lesson > As I understand: > Or not ? I don't know. The simple fact is that a /24 block is the set of addresses that use the same prefix which is defined by a 24-bit netmask. That means, that all of the addresses in the block will have the same pattern in the first 24 bits. Asking how many /24 blocks can be carved out of the total numberspace is equivalent to asking how many unique patterns there are of 24 binary digits. It should be obvious that the number of unique patterns of 24 binary digits is the same regardless of whether you use the first 24 bits out of a total of 32, or the first 24 bits out of a total of 128. One single /24 block is the same percentage of the total numberspace regardless of whether the protocol is v4 or v6. --Michael Dillon From Ray.Bellis at nominet.org.uk Thu Dec 3 15:03:38 2009 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Thu, 3 Dec 2009 14:03:38 +0000 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: References: <28E139F46D45AF49A31950F88C497458045BC7ED@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: > As I understand: > > IPv4 /24 is (Total IPv4)/(2^24) > IPv6 /24 is (Total IPv6)/(2^24) > > Or not ? Sort of - that's the right math for the total number of addresses, but not the right math for what _proportion_ of the IP space it represents, which was the original question. The /24 is from the _left_ hand (or most significant) bit, not the right hand. Hence a /24 is always 1:16777216 of the IP space. Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsako at 3c-hungary.hu Thu Dec 3 14:30:19 2009 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 03 Dec 2009 14:30:19 +0100 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: References: Message-ID: <4B17BD6B.7040106@3c-hungary.hu> Dear Dmitry, > As I understand: > > IPv4 /24 is (Total IPv4)/(2^24) > IPv6 /24 is (Total IPv6)/(2^24) > > Or not ? Yes, you are right, but this is not what Michael was saying. What you prove above is that a /24 in IPv6 is a much larger address space than a /24 in IPv4, which is correct (and obvious to most people, as this is the very reason for introducing IPv6 in the first place). Michael said: "an IPv6 /24 and an IPv4 /24 use up the same percentage of the total address space", which is true. This percentage is 1/2^24 x 100. Best regards, Janos From ulrich.kiermayr at univie.ac.at Thu Dec 3 15:02:28 2009 From: ulrich.kiermayr at univie.ac.at (Ulrich Kiermayr) Date: Thu, 3 Dec 2009 15:02:28 +0100 Subject: [address-policy-wg] an arithmetic lesson In-Reply-To: References: <28E139F46D45AF49A31950F88C497458045BC45E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: Hello, On 03.12.2009, at 13:08, Jim Reid wrote: > On 3 Dec 2009, at 10:00, wrote: > >> an IPv6 /24 and an IPv4 /24 use up the same percentage of the total address space. > > How do you work that out? Please enlighten me. 2^24/2^128 x 100 is many orders of magnitude smaller than 2^24/2^32 x 100: > gromit% bc > scale=50 > 2^24/2^128*100 > .00000000000000000000000000000493038065763132378300 > 2^24/2^32*100 > .39062500000000000000000000000000000000000000000000 Actually the size of a /24 is 2^(128-24) or 2^(32-24), sooo: 2^(32-24) / 2^32 * 100 = 1/2^24 * 100 and 2^(128-24) / 2^128 * 100 = 1/2^24 * 100 Or am I missing something here: > There are of course the same number of IPv4 and IPv6 /24s. If the Number of /24s is the same every one of them uses the same percentage of the Address-Space: 100 / (# of /24s) lGuk -- Ulrich Kiermayr jabber xmpp:uk at jabber.univie.ac.at Leiter der Abteilung Datennetz und Telefonie skype:kiermayr Vienna University Computer Center phone +43 1 4277 14020 Universitaetsstrasse 7, 1010 Wien, AT fax +43 1 4277 9140 From tme at multicasttech.com Thu Dec 3 15:20:22 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 3 Dec 2009 09:20:22 -0500 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: References: Message-ID: <1B8CEBF2-8402-4EA4-BECC-752CE61B3D14@multicasttech.com> On Dec 3, 2009, at 7:55 AM, Dmitriy V Menzulskiy wrote: > > > > > > On 3 Dec 2009, at 10:00, wrote: > > > > > > > an IPv6 /24 and an IPv4 /24 use up the same percentage of the > total > > > > address space. > > > > > > How do you work that out? Please enlighten me. 2^24/2^128 x > > > 100 is many orders of magnitude smaller than 2^24/2^32 x 100: > > > gromit% bc > > > scale=50 > > > 2^24/2^128*100 > > > .00000000000000000000000000000493038065763132378300 > > > 2^24/2^32*100 > > > .39062500000000000000000000000000000000000000000000 > > > > > > There are of course the same number of IPv4 and IPv6 /24s. > > > > Percentage is calculated by dividing the number of things > > under consideration by the total number of things. When > > I used the word "an", I meant one thing. > > > > Assuming that the number of IPv4 and IPv6 /24s is 10 > > > > 1/10 = 1/10 > > > > Assuming that the number of IPv4 and IPv6 /24s is 8192 > > > > 1/8192 = 1/8192 > > > > Assuming that the number of IPv4 and IPv6 /24s is 2882873787 > > > > 1/2882873787 = 1/2882873787 > > > > Do you see a pattern forming? > > > > --Michael Dillon > > > > As I understand: > > IPv4 /24 is (Total IPv4)/(2^24) > IPv6 /24 is (Total IPv6)/(2^24) > > Or not ? > Not. The ratio you want, using your formalism, is (2^(size of address space - 24)) / (Total IPvX) which is 2^(N - 24) / 2^N = 1 / 2^24 (where N is the number of bits in the address space). Regards Marshall > > WBR, > > Dmitry Menzulskiy, DM3740-RIPE > From Remco.vanMook at eu.equinix.com Thu Dec 3 16:03:30 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 3 Dec 2009 16:03:30 +0100 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson Message-ID: <25B76451F7215744AFD4195362E55A1C04A24E@NLEN1EX1.eu.win.equinix.com> To upset some more sentiments; compare v4 /24s with the available v4 unicast; do the same with v6 /24s and current v6 unicast space. Rough arithmetic shows then that in that line of reasoning, a v6 /24 is more comparable to a v4 /20. Remco ----- Original Message ----- From: address-policy-wg-admin at ripe.net To: Dmitriy V Menzulskiy Cc: michael.dillon at bt.com ; address-policy-wg at ripe.net Sent: Thu Dec 03 14:20:22 2009 Subject: Re: Ha: [address-policy-wg] RE: an arithmetic lesson On Dec 3, 2009, at 7:55 AM, Dmitriy V Menzulskiy wrote: > > > > > > On 3 Dec 2009, at 10:00, wrote: > > > > > > > an IPv6 /24 and an IPv4 /24 use up the same percentage of the > total > > > > address space. > > > > > > How do you work that out? Please enlighten me. 2^24/2^128 x > > > 100 is many orders of magnitude smaller than 2^24/2^32 x 100: > > > gromit% bc > > > scale=50 > > > 2^24/2^128*100 > > > .00000000000000000000000000000493038065763132378300 > > > 2^24/2^32*100 > > > .39062500000000000000000000000000000000000000000000 > > > > > > There are of course the same number of IPv4 and IPv6 /24s. > > > > Percentage is calculated by dividing the number of things > > under consideration by the total number of things. When > > I used the word "an", I meant one thing. > > > > Assuming that the number of IPv4 and IPv6 /24s is 10 > > > > 1/10 = 1/10 > > > > Assuming that the number of IPv4 and IPv6 /24s is 8192 > > > > 1/8192 = 1/8192 > > > > Assuming that the number of IPv4 and IPv6 /24s is 2882873787 > > > > 1/2882873787 = 1/2882873787 > > > > Do you see a pattern forming? > > > > --Michael Dillon > > > > As I understand: > > IPv4 /24 is (Total IPv4)/(2^24) > IPv6 /24 is (Total IPv6)/(2^24) > > Or not ? > Not. The ratio you want, using your formalism, is (2^(size of address space - 24)) / (Total IPvX) which is 2^(N - 24) / 2^N = 1 / 2^24 (where N is the number of bits in the address space). Regards Marshall > > WBR, > > Dmitry Menzulskiy, DM3740-RIPE > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drc at virtualized.org Thu Dec 3 19:33:17 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 3 Dec 2009 10:33:17 -0800 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: <25B76451F7215744AFD4195362E55A1C04A24E@NLEN1EX1.eu.win.equinix.com> References: <25B76451F7215744AFD4195362E55A1C04A24E@NLEN1EX1.eu.win.equinix.com> Message-ID: <21AA3BC2-6878-4C55-BD76-A59A2CEB1B98@virtualized.org> Hmm.. It is (or rather, should be) obvious that there are exactly the same number of /24s or /8s or /s in IPv4 as there are in IPv6. It is (or should be) equally obvious to state that the amount addressed by an IPv6 / is VASTLY larger than in IPv4. Except when you blow away the lower 96 bits in an IPv6 address for protocol reasons. When I mentioned class As, I was speaking figuratively. The point that I was attempting to make was that early adopters of IPv4 were able to obtain "class As" with minimal justification. As the IPv4 free pool depletes, it becomes increasingly hard to obtain (the equivalent of) "class As". I suspect most of us now look at the "class A" allocations as historical mistakes that we'd like to remedy, but don't because it is undoubtedly too much trouble (and please, can we not rathole on reclamation of legacy address space yet again?). Allocating IPv6 /24 now when we have "plenty" of IPv6 address space because it makes a particular protocol proposal more convenient is, in my view, simply repeating history. It is _the equivalent of_ allocating "class As". Regards, -drc On Dec 3, 2009, at 7:03 AM, Remco van Mook wrote: > To upset some more sentiments; compare v4 /24s with the available v4 unicast; do the same with v6 /24s and current v6 unicast space. Rough arithmetic shows then that in that line of reasoning, a v6 /24 is more comparable to a v4 /20. > > Remco > > ----- Original Message ----- > From: address-policy-wg-admin at ripe.net > To: Dmitriy V Menzulskiy > Cc: michael.dillon at bt.com ; address-policy-wg at ripe.net > Sent: Thu Dec 03 14:20:22 2009 > Subject: Re: Ha: [address-policy-wg] RE: an arithmetic lesson > > > On Dec 3, 2009, at 7:55 AM, Dmitriy V Menzulskiy wrote: > > > > > > > > > > On 3 Dec 2009, at 10:00, wrote: > > > > > > > > > an IPv6 /24 and an IPv4 /24 use up the same percentage of the > > total > > > > > address space. > > > > > > > > How do you work that out? Please enlighten me. 2^24/2^128 x > > > > 100 is many orders of magnitude smaller than 2^24/2^32 x 100: > > > > gromit% bc > > > > scale=50 > > > > 2^24/2^128*100 > > > > .00000000000000000000000000000493038065763132378300 > > > > 2^24/2^32*100 > > > > .39062500000000000000000000000000000000000000000000 > > > > > > > > There are of course the same number of IPv4 and IPv6 /24s. > > > > > > Percentage is calculated by dividing the number of things > > > under consideration by the total number of things. When > > > I used the word "an", I meant one thing. > > > > > > Assuming that the number of IPv4 and IPv6 /24s is 10 > > > > > > 1/10 = 1/10 > > > > > > Assuming that the number of IPv4 and IPv6 /24s is 8192 > > > > > > 1/8192 = 1/8192 > > > > > > Assuming that the number of IPv4 and IPv6 /24s is 2882873787 > > > > > > 1/2882873787 = 1/2882873787 > > > > > > Do you see a pattern forming? > > > > > > --Michael Dillon > > > > > > > As I understand: > > > > IPv4 /24 is (Total IPv4)/(2^24) > > IPv6 /24 is (Total IPv6)/(2^24) > > > > Or not ? > > > Not. > > The ratio you want, using your formalism, is > > (2^(size of address space - 24)) / (Total IPvX) > > which is 2^(N - 24) / 2^N = 1 / 2^24 > > (where N is the number of bits in the address space). > > Regards > Marshall > > > > > > WBR, > > > > Dmitry Menzulskiy, DM3740-RIPE > > > > > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From lorenzo at google.com Thu Dec 3 21:47:27 2009 From: lorenzo at google.com (Lorenzo Colitti) Date: Thu, 3 Dec 2009 12:47:27 -0800 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C4974580455ECD0@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580455ECD0@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Wed, Dec 2, 2009 at 4:04 AM, wrote: > What are the broken anycast routers? They are routers that announce 2002::/16 and 192.88.99.1, but are very far away, drop packets, have unreliable connectivity, etc. etc. etc. Our data shows that 6to4 and Teredo have a ~50ms latency penalty compared to native IPv6, and we know of at least one case in which a third-party 6to4 gateway was causing connectivity problems because the network that set it up had put in place, and then neglected to increase a bandwidth throttle on it. > Why can't they be fixed? Because they are in someone else's network and it's an operational burden to create specific BGP policy to avoid them. Even if you maintain your own 6to4 relays, that only takes care of the outgoing path - you're still subject to them on the way back. From gert at space.net Thu Dec 3 23:12:04 2009 From: gert at space.net (Gert Doering) Date: Thu, 3 Dec 2009 23:12:04 +0100 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: <21AA3BC2-6878-4C55-BD76-A59A2CEB1B98@virtualized.org> References: <25B76451F7215744AFD4195362E55A1C04A24E@NLEN1EX1.eu.win.equinix.com> <21AA3BC2-6878-4C55-BD76-A59A2CEB1B98@virtualized.org> Message-ID: <20091203221204.GF32226@Space.Net> Hi, On Thu, Dec 03, 2009 at 10:33:17AM -0800, David Conrad wrote: > Allocating IPv6 /24 now when we have "plenty" of IPv6 address > space because it makes a particular protocol proposal more convenient > is, in my view, simply repeating history. It is _the equivalent > of_ allocating "class As". The math *and* the economics disagree with you. IPv4 class A have been limited to 127 pieces, and they came for free. There's 2 million IPv6 /24s inside FP001, and they come with a yearly price tag, so "not everybody or their dog" are going to ask for one (and, as I said, I know at least one LIR who is most definitely not going to ask for one - so not even every LIR that does deploy IPv6 wants a /24). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Remco.vanMook at eu.equinix.com Thu Dec 3 23:21:04 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 3 Dec 2009 23:21:04 +0100 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson References: <25B76451F7215744AFD4195362E55A1C04A24E@NLEN1EX1.eu.win.equinix.com> <21AA3BC2-6878-4C55-BD76-A59A2CEB1B98@virtualized.org> <20091203221204.GF32226@Space.Net> Message-ID: <25B76451F7215744AFD4195362E55A1CF35149@NLEN1EX1.eu.win.equinix.com> Gert, here's a hard one - if all new allocations in IPv6 are now going to be /24s, don't you think that will affect the charging scheme since it vastly increases the average amount of address space allocated, therefore lowering the amount that would be charged for such a resource? All of a sudden that large block is just an average size; while I don't claim to understand all the intricacies of the charging scheme I will claim that handing out a larger block isn't necessarily more work than handing out a smaller one, and the way the charging scheme works is not to maximize income, but to match the sum of expenses the NCC makes in order to provide their services. Not that I'm looking for an argument to increase the 'standard' allocation size, but the charging scheme isn't a good argument against, I think. Remco (There were also 2 million Class C blocks, that doesn't make it a good idea to hand out IPv6 in a similar way. Party like it's 1993 stopped in well, 1994.) -----Original Message----- From: Gert Doering [mailto:gert at Space.Net] Sent: donderdag 3 december 2009 23:12 To: David Conrad Cc: Remco van Mook; tme at multicasttech.com; DMenzulskiy at beeline.ru; michael.dillon at bt.com; address-policy-wg at ripe.net Subject: Re: Ha: [address-policy-wg] RE: an arithmetic lesson Hi, On Thu, Dec 03, 2009 at 10:33:17AM -0800, David Conrad wrote: > Allocating IPv6 /24 now when we have "plenty" of IPv6 address > space because it makes a particular protocol proposal more convenient > is, in my view, simply repeating history. It is _the equivalent > of_ allocating "class As". The math *and* the economics disagree with you. IPv4 class A have been limited to 127 pieces, and they came for free. There's 2 million IPv6 /24s inside FP001, and they come with a yearly price tag, so "not everybody or their dog" are going to ask for one (and, as I said, I know at least one LIR who is most definitely not going to ask for one - so not even every LIR that does deploy IPv6 wants a /24). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From gert at space.net Thu Dec 3 23:41:28 2009 From: gert at space.net (Gert Doering) Date: Thu, 3 Dec 2009 23:41:28 +0100 Subject: Ha: [address-policy-wg] RE: an arithmetic lesson In-Reply-To: <25B76451F7215744AFD4195362E55A1CF35149@NLEN1EX1.eu.win.equinix.com> References: <25B76451F7215744AFD4195362E55A1C04A24E@NLEN1EX1.eu.win.equinix.com> <21AA3BC2-6878-4C55-BD76-A59A2CEB1B98@virtualized.org> <20091203221204.GF32226@Space.Net> <25B76451F7215744AFD4195362E55A1CF35149@NLEN1EX1.eu.win.equinix.com> Message-ID: <20091203224128.GG32226@Space.Net> Hi, On Thu, Dec 03, 2009 at 11:21:04PM +0100, Remco van Mook wrote: > here's a hard one - if all new allocations in IPv6 are now going to be > /24s, don't you think that will affect the charging scheme since it > vastly increases the average amount of address space allocated, > therefore lowering the amount that would be charged for such a resource? This is actually mixing two different arguments from my end. One argument was "if every LIR gets a /24, we still have just scratched the amount of /24s available, so the world would not stop turning". What you are replying-to was in the context of "if we give LIRs the option(!) to ask for a bigger allocation for 6RDs, this is bad, because all of a sudden every single LIR is going to claim 'we want 6rd!'" (without mentioning a specific "large block!!" size for 6rd deployment) - and in this scenario, blocks of different size would continue to exist, and quite likely have different price tags attached to it (and very likely, different amount of discussion with the IPRAs). So - your assumption "if we give all of them an IPv6 /24, this will be the common size, and the score is very likely going to be lower than for an IPv6 /24 today" is reasonable, but doesn't contradict what I wrote, because that was in the context of "there's different block sizes". > All of a sudden that large block is just an average size; while I don't > claim to understand all the intricacies of the charging scheme I will > claim that handing out a larger block isn't necessarily more work than > handing out a smaller one, and the way the charging scheme works is not > to maximize income, but to match the sum of expenses the NCC makes in > order to provide their services. Yes. > Not that I'm looking for an argument to increase the 'standard' > allocation size, but the charging scheme isn't a good argument against, > I think. No, there was confusion between two different lines of argument. Note that I did not propose a certain way forward. I was trying to point out why certain "we can't do that, because " statments usually don't properly take the numbers involved into account, or are based on "everbody will..." arguments that are just not so. (The old argument "and everybody thought 640k was enough!" also gets boring after a few repetitions (and has never been helpful in any way, except as a poor excuse of not looking at the bits and doing some math).) > Remco > (There were also 2 million Class C blocks, that doesn't make it a good > idea to hand out IPv6 in a similar way. Party like it's 1993 stopped in > well, 1994.) I'm not sure why that is an argument for or against anything - we still give out IPv4 in chunks of /24 or bigger. And anybody who goes to the RIPE NCC and asks for IPv4 PI and claims "I have more than 128 machines to number!" *will* get an IPv4 /24. IPv6 /24s would be for LIRs, potentially only for LIRs that fulfill some creative criteria why they need more than chunks of addresses. As I said: our LIR wouldn't need a /24. So the number of potential IPv6 /24 holders would be vastly lower than for IPv4. Gert Doering -- no specific hat -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From lorenzo at google.com Fri Dec 4 23:41:32 2009 From: lorenzo at google.com (Lorenzo Colitti) Date: Fri, 4 Dec 2009 14:41:32 -0800 Subject: [address-policy-wg] RE: gazing into the future In-Reply-To: <28E139F46D45AF49A31950F88C4974580455F03E@E03MVZ2-UKDY.domain1.systemhost.net> References: <80E201FF-066F-4068-A6B9-76425DF37355@rfc1035.com> <28E139F46D45AF49A31950F88C4974580455F03E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Wed, Dec 2, 2009 at 6:53 AM, wrote: > of 6RD and the larger allocations that might happen. I get the > sense that this would not cause a problem as long as we assume > that 6RD will be decommissioned within 5 to 10 years. You are assuming that address space will be returned when 6RD is decommissioned? That doesn't sound likely to me. From ingrid at ripe.net Mon Dec 7 13:53:23 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Mon, 07 Dec 2009 13:53:23 +0100 Subject: [address-policy-wg] 2009-03 Proposal Accepted (Run Out Fairly) Message-ID: <20091207125323.3AF122F583@herring.ripe.net> PDP Number: 2009-03 Run Out Fairly Dear Colleagues Consensus has been reached, and the proposal described in 2009-03, "Run Out Fairly" has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-484.html You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html The RIPE NCC will implement this new policy within one month. Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC From remi.despres at free.fr Mon Dec 7 14:06:10 2009 From: remi.despres at free.fr (=?ISO-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Mon, 07 Dec 2009 14:06:10 +0100 Subject: [address-policy-wg] RE: gazing into the future In-Reply-To: References: <80E201FF-066F-4068-A6B9-76425DF37355@rfc1035.com> <28E139F46D45AF49A31950F88C4974580455F03E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B1CFDC2.7050309@free.fr> Lorenzo Colitti a ?crit : > On Wed, Dec 2, 2009 at 6:53 AM, wrote: >> of 6RD and the larger allocations that might happen. I get the >> sense that this would not cause a problem as long as we assume >> that 6RD will be decommissioned within 5 to 10 years. > > You are assuming that address space will be returned when 6RD is > decommissioned? That doesn't sound likely to me. 1. As a matter of fact, it would not even need to be decommissioned in most cases: - If an ISP has only one IPv4 prefix, it doesn't need a more generous prefix than /32 for 6rd. There is nothing to be decommissioned. - If it has several IPv4 prefixes, but also an installed base of more than 64K customers (or a short term plan to have it), then, to assign /48s to its customers as currently recommended, it deserves from its RIR a more generous prefix than a /32 anyway (even when 6rd is replaced by native IPv6 routing). No need to decommission. It is only for those that still have several IPv4 prefixes an no short term plan to exceed 64K customers that the need to decommission would exist. This makes it a secondary consideration. It may IMHO be ignored. 2. IPv6 introduced TTLs of assigned prefixes so that, combined with DNS dynamic updates, renumbering becomes realistic. Some ISPs, when they get a more generous prefix than before, e.g. going from a /32 to a /28, may therefore prefer, after some coexistence delay, to route only on the shorter prefix. They can then be decommissioned without problem. This simplifies their network, and helps keeping tier-1 routing tables short. Regards, RD From sergey at devnull.ru Wed Dec 9 17:58:58 2009 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 9 Dec 2009 17:58:58 +0100 Subject: [address-policy-wg] 2006-01 IPv6 PI implementation Message-ID: <655040386.20091209175858@devnull.ru> Hello, can anyone explain me is there a restriction in policy for assigning /48 PI IPv6 to ISP which will use /64-/128 prefixes to connect broadband customers? -- Sergey From gert at space.net Wed Dec 9 19:06:54 2009 From: gert at space.net (Gert Doering) Date: Wed, 9 Dec 2009 19:06:54 +0100 Subject: [address-policy-wg] 2006-01 IPv6 PI implementation In-Reply-To: <655040386.20091209175858@devnull.ru> References: <655040386.20091209175858@devnull.ru> Message-ID: <20091209180654.GV32226@Space.Net> Hi, On Wed, Dec 09, 2009 at 05:58:58PM +0100, Sergey Myasoedov wrote: > can anyone explain me is there a restriction in policy for assigning /48 PI IPv6 to ISP > which will use /64-/128 prefixes to connect broadband customers? IPv6 PI is for *your* network. IPv6 PI space is not to be used for assigning prefixes to customers - and this is very clear from the policy documents. If you want to assign prefixes to customers, become a LIR and get a /32 IPv6 PA (or larger). (Yes, this is different from the way one could run an "ISP" in IPv4 land, assigning single IPv4 addresses to customers, and declaring those to be "ISP infrastructure" - this is permitted by the current IPv4 policy, but this loop hole does not make any sense in IPv6 where you are supposed to assign whole /64 or /56 networks to customers) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From michael.dillon at bt.com Wed Dec 9 23:37:45 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 9 Dec 2009 22:37:45 -0000 Subject: [address-policy-wg] 2006-01 IPv6 PI implementation In-Reply-To: <655040386.20091209175858@devnull.ru> Message-ID: <28E139F46D45AF49A31950F88C49745804763F37@E03MVZ2-UKDY.domain1.systemhost.net> > can anyone explain me is there a restriction in policy for > assigning /48 PI IPv6 to ISP which will use /64-/128 prefixes > to connect broadband customers? Minimum IPv6 allocation to ISPs is /32 which will allow you to assign /48 prefixes to broadband customers. This makes network design simple and you would be following the same mainstream IPv6 implementation rules as most other ISPs. This will make it much easier for you to get support from your vendors and advice from other ISPs who are deploying IPv6. It also prevents your competitors from telling your customers that your service is bad because you give customers a smaller block of addresses/subnets. Really, only mobile phones or other devices should get /128 prefixes. Anything that is a network with potentially two or more devices on it should get a /64. And a broadband customer is a "site" so they should get a whole /48 unless you are very big. Some very big ISPs are giving /56 to customers in their private homes and only give /48 to an office or some kind of business. --Michael Dillon From noreply at ripe.net Thu Dec 10 10:50:32 2009 From: noreply at ripe.net (Nathalie Trenaman) Date: Thu, 10 Dec 2009 10:50:32 +0100 Subject: [address-policy-wg] 2009-08 Implementation: IPv6 PI Assignments for LIRs Message-ID: <4B20C468.2000801@ripe.net> [Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that RIPE Policy Proposal 2009-08,"IPv6 Provider Independent (PI) Assignments for LIRs", has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. This proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-08.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ipv6-policies.html The following document has also been updated to reflect this policy implementation: http://ripe.net/ripe/docs/ipv6-pi-support.html Regards, Nathalie Trenaman Registration Services RIPE NCC From mir at ripe.net Thu Dec 10 16:03:27 2009 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 10 Dec 2009 16:03:27 +0100 Subject: [address-policy-wg] List of IPv6 measurements published on RIPE Labs Message-ID: <4B210DBF.3020108@ripe.net> [I am sorry if you receive this more than once.] Dear colleagues, Please see two articles related to IPv6 Measurements recently published on RIPE Labs: 1. A list of IPv6 measurements various people and organisations are doing with a short description and pointers to the actual results of the measurements http://labs.ripe.net/content/ipv6-measurement-compilation 2. An interview with Alain Durand about the IPv6 measurements he is doing at Comcast together with the University of Pennsylvania http://labs.ripe.net/content/ipv6-monitor We would like to get feedback from you about the measurements presented. How would you chose to measure the growing deployment of IPv6? Have you set criteria for when you will deploy IPv6? Let us know what information and analysis would be helpful to assist you in the deployment of IPv6. And would measurements influence your decision to deploy IPv6 or not? Please go to the forum at http://labs.ripe.net/node/ipv6-measurements or contact me directly at labs at ripe.net. Kind Regards, Mirjam Kuehne RIPE NCC From president at ukraine.su Tue Dec 22 12:14:23 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 22 Dec 2009 13:14:23 +0200 Subject: [address-policy-wg] IPv6 PI for HOSTING Message-ID: <4B30AA0F.5050804@ukraine.su> Hi All, I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;) The main problem in IPv6 implementation in the real life is a lack of resources. A lot of ISPs (including our company) providing broadband and corporate access to IPv6 Internet. And now it is running globally, pings are pinging, traces are tracing... and so what? The main question users ask us "and so, what we can do with that new IPv6 Internet?". The answer is NOTHING! There is almost NO RESOURCES in IPv6 net! No sites, no pages, no freemails - NOTHING! This makes IPv6 Internet absolutely USELESS for users. Really, unlike us, they do not become happy running bgpd and traceroute6. They need web resources. So why do you think all they change their common network to absolutely useless thing for them after IPv4 will run out? Let's go forward. Yes, a few hosters I know are big companies, LIRs, trade their traffic and so on. But majority are small companines have from one server to one-two racks of hosting servers. They will never become a LIR only for [useless now] IPv6 address space. But they host a huge piece of resources need by a lot of regular users. Yes, IPv6 can provide hosting users a lot of good things, such as unique IP for every site, FTP/SSL/SMB/torrent/personal IP-based ACLs/... without extra costs and so on - this sure will stimulate them to move to IPv6. Yes, some of hosters are ready to obtain IPv6 network and play with it right now. And NO, most of them don't want to use upstream's networks, as there is almost impossible to change it after hundred of thousands of domains are linked with this network. So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jim at rfc1035.com Tue Dec 22 13:08:41 2009 From: jim at rfc1035.com (Jim Reid) Date: Tue, 22 Dec 2009 12:08:41 +0000 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B30AA0F.5050804@ukraine.su> References: <4B30AA0F.5050804@ukraine.su> Message-ID: <655AA6F4-485B-4070-83E4-29E04E4B0590@rfc1035.com> On 22 Dec 2009, at 11:14, Max Tulyev wrote: > So I think we should ASAP change IPv6 PI policy to let hosting be the > issue for IPv6 PI assignment. Max, I'm not sure this would result in anything useful. It might even be harmful by encouraging or facilitating route de-aggregation. You are quite right to note the chicken-and-egg problems IPv6 faces and the reasons why IPv6 deployment has been slow. However these factors still exist no matter how an organisation gets its IPv6 space. For instance most content providers don't offer stuff over IPv6 because there are very few people using IPv6. So, in general, from their perspective there's a small audience for v6 content that doesn't justify the costs of providing it. That isn't likely to change even if the content providers got v6 space "for free". I doubt address allocation policies are having an impact on IPv6 deployment or uptake. IMO the drivers for that have still to emerge: like the lack of v4 space (or its price compared to v6) or the operational pain of even more NAT and ALGs. From marcoh at marcoh.net Tue Dec 22 13:16:21 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 22 Dec 2009 13:16:21 +0100 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <655AA6F4-485B-4070-83E4-29E04E4B0590@rfc1035.com> References: <4B30AA0F.5050804@ukraine.su> <655AA6F4-485B-4070-83E4-29E04E4B0590@rfc1035.com> Message-ID: <44F7C4BD-BFAD-4E45-BAC7-DEF4F54357FF@marcoh.net> On 22 dec 2009, at 13:08, Jim Reid wrote: > On 22 Dec 2009, at 11:14, Max Tulyev wrote: > >> So I think we should ASAP change IPv6 PI policy to let hosting be the >> issue for IPv6 PI assignment. > > Max, I'm not sure this would result in anything useful. It might even be harmful by encouraging or facilitating route de-aggregation. > > You are quite right to note the chicken-and-egg problems IPv6 faces and the reasons why IPv6 deployment has been slow. However these factors still exist no matter how an organisation gets its IPv6 space. For instance most content providers don't offer stuff over IPv6 because there are very few people using IPv6. So, in general, from their perspective there's a small audience for v6 content that doesn't justify the costs of providing it. That isn't likely to change even if the content providers got v6 space "for free". > > I doubt address allocation policies are having an impact on IPv6 deployment or uptake. IMO the drivers for that have still to emerge: like the lack of v4 space (or its price compared to v6) or the operational pain of even more NAT and ALGs. I can't agree more, hopefully LTE will become some form of IPv6 killer app but at the moment indeed AP is not the problem causing the lack in IPv6 deployment. MarcoH From michael.dillon at bt.com Tue Dec 22 13:51:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 22 Dec 2009 12:51:27 -0000 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B30AA0F.5050804@ukraine.su> Message-ID: <28E139F46D45AF49A31950F88C497458049A9434@E03MVZ2-UKDY.domain1.systemhost.net> > I just hear I can't use IPv6 PI network for hosting service. > And I want to talk about it ;) Where did you hear this? I just looked at section 8 of RIPE-472 and there is nothing mentioned there. > Yes, a few hosters I know are big companies, LIRs, trade > their traffic and so on. But majority are small companines > have from one server to one-two racks of hosting servers. > They will never become a LIR only for [useless now] IPv6 > address space. But they host a huge piece of resources need > by a lot of regular users. Yes, this is true. > So I think we should ASAP change IPv6 PI policy to let > hosting be the issue for IPv6 PI assignment. I don't see any problem with IPv6 PI and I don't understand what you want to change. Please tell us which document to change, and provide a suggestion for the new words to put in the document. --Michael Dillon From mohta at necom830.hpcl.titech.ac.jp Tue Dec 22 14:03:33 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Dec 2009 22:03:33 +0900 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B30AA0F.5050804@ukraine.su> References: <4B30AA0F.5050804@ukraine.su> Message-ID: <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> Max Tulyev wrote: > I just hear I can't use IPv6 PI network for hosting service. And I want > to talk about it ;) OK. > The main problem in IPv6 implementation in the real life is a lack of > resources. So, just use IPv4. What is the problem? > So why do you think all they change their common network to > absolutely useless thing for them after IPv4 will run out? Hugh? With port restricted IP, IPv4 address space won't run out. > Let's go forward. No, you should just stay here at IPv4. > Yes, IPv6 can provide hosting users a lot of good things, Hugh? > such as unique > IP for every site, A+P without legacy NAT, or end to end NAT, is more than enough. > FTP/SSL/SMB/torrent/personal IP-based ACLs/... > without extra costs and so on A+P without legacy NAT, or end to end NAT, is more than enough. > - this sure will stimulate them to move to > IPv6. Yes, No, not at all. > So I think we should ASAP change IPv6 PI policy to let hosting be the > issue for IPv6 PI assignment. With port restricted IPv4, you can just ignore IPv6 and keep using IPv4 without losing the end to end transparency. So, why do you bother with IPv6? Masataka Ohta From mark at streamservice.nl Tue Dec 22 13:58:57 2009 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 22 Dec 2009 13:58:57 +0100 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B30AA0F.5050804@ukraine.su> References: <4B30AA0F.5050804@ukraine.su> Message-ID: <03dd01ca8306$85f21e00$91d65a00$@nl> > Hi All, > > I just hear I can't use IPv6 PI network for hosting service. And I want > to talk about it ;) > > The main problem in IPv6 implementation in the real life is a lack of > resources. > A lot of ISPs (including our company) providing broadband and corporate > access to IPv6 Internet. And now it is running globally, pings are > pinging, traces are tracing... and so what? The main question users ask > us "and so, what we can do with that new IPv6 Internet?". > > The answer is NOTHING! > > There is almost NO RESOURCES in IPv6 net! No sites, no pages, no > freemails - NOTHING! > > This makes IPv6 Internet absolutely USELESS for users. Really, unlike > us, they do not become happy running bgpd and traceroute6. They need > web > resources. So why do you think all they change their common network to > absolutely useless thing for them after IPv4 will run out? > > Let's go forward. > > Yes, a few hosters I know are big companies, LIRs, trade their traffic > and so on. But majority are small companines have from one server to > one-two racks of hosting servers. They will never become a LIR only for > [useless now] IPv6 address space. But they host a huge piece of > resources need by a lot of regular users. > > Yes, IPv6 can provide hosting users a lot of good things, such as > unique > IP for every site, FTP/SSL/SMB/torrent/personal IP-based ACLs/... > without extra costs and so on - this sure will stimulate them to move > to > IPv6. Yes, some of hosters are ready to obtain IPv6 network and play > with it right now. And NO, most of them don't want to use upstream's > networks, as there is almost impossible to change it after hundred of > thousands of domains are linked with this network. > > So I think we should ASAP change IPv6 PI policy to let hosting be the > issue for IPv6 PI assignment. > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) Changing it in a way that it is allowed (as it is technically possible) to use IPv6 PI for co location/dedicated servers/shared hosting/VPS hosting/etc. would be a good point. Currently it is for us a reason not to support it yet. Another reason is that PFsense doesn't support it yet. Mark From president at ukraine.su Tue Dec 22 15:36:15 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 22 Dec 2009 16:36:15 +0200 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <655AA6F4-485B-4070-83E4-29E04E4B0590@rfc1035.com> References: <4B30AA0F.5050804@ukraine.su> <655AA6F4-485B-4070-83E4-29E04E4B0590@rfc1035.com> Message-ID: <4B30D95F.8070103@ukraine.su> Jim Reid wrote: > I doubt address allocation policies are having an impact on IPv6 > deployment or uptake. IMO the drivers for that have still to emerge: > like the lack of v4 space (or its price compared to v6) or the > operational pain of even more NAT and ALGs. For me and companies around us, there IS a a difference. First is the cost (direct cost and cost of pain with abroad contracts) for just playing with something. This cost will not be returned back, and there is still the financial crisis. Some of our existing hosting customers asked us for IPv6. And they say be never deploy IPv6 just because of direct and indirect costs needs to be payed to RIPE NCC. But wanted to do that before. Users can demand IPv6 from their ISPs to access to some sites. But I don't believe right now users can demand IPv6 visibility from any web site. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Tue Dec 22 15:45:28 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 22 Dec 2009 16:45:28 +0200 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> Message-ID: <4B30DB88.3050807@ukraine.su> I can say even more: hosters can really use ONLY ONE IPv4 public address for anything they need. This is not a hoster company problem in general. So they do use IPv4 as you say. The problem is IPv6 Internet is still useless. If it will be when IPv4 runs out, the world will NOT be moved to IPv6, but will use NATs, trade the rest of IPv4 blocks and so on. IPv6 will be ignored as working, but useless thing. I repeat my lovely phrase: If a majority (a half) of web resources will be reachable via IPv6 when IPv4 will be finished, then MAY BE will be the migration to IPv6. If not - then it fails. Now I know NONE of resources reachable. Only some single experiments. Masataka Ohta wrote: > Max Tulyev wrote: > >> I just hear I can't use IPv6 PI network for hosting service. And I want >> to talk about it ;) > > OK. > >> The main problem in IPv6 implementation in the real life is a lack of >> resources. > > So, just use IPv4. What is the problem? > >> So why do you think all they change their common network to >> absolutely useless thing for them after IPv4 will run out? > > Hugh? With port restricted IP, IPv4 address space won't run out. > >> Let's go forward. > > No, you should just stay here at IPv4. > >> Yes, IPv6 can provide hosting users a lot of good things, > > Hugh? > >> such as unique >> IP for every site, > > A+P without legacy NAT, or end to end NAT, is more than enough. > >> FTP/SSL/SMB/torrent/personal IP-based ACLs/... >> without extra costs and so on > > A+P without legacy NAT, or end to end NAT, is more than enough. > >> - this sure will stimulate them to move to >> IPv6. Yes, > > No, not at all. > >> So I think we should ASAP change IPv6 PI policy to let hosting be the >> issue for IPv6 PI assignment. > > With port restricted IPv4, you can just ignore IPv6 and keep using > IPv4 without losing the end to end transparency. > > So, why do you bother with IPv6? > > Masataka Ohta > > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Tue Dec 22 15:47:51 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 22 Dec 2009 16:47:51 +0200 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <28E139F46D45AF49A31950F88C497458049A9434@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458049A9434@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B30DC17.6090002@ukraine.su> michael.dillon at bt.com wrote: >> I just hear I can't use IPv6 PI network for hosting service. >> And I want to talk about it ;) > > Where did you hear this? I just looked at section 8 of RIPE-472 > and there is nothing mentioned there. I hear it from colleague told me hear it from hostmaster ;) I can't find this in the policy too. So who is wrong? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From andy at nosignal.org Tue Dec 22 21:42:28 2009 From: andy at nosignal.org (Andy Davidson) Date: Tue, 22 Dec 2009 20:42:28 +0000 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B30AA0F.5050804@ukraine.su> References: <4B30AA0F.5050804@ukraine.su> Message-ID: <673C7EE0-B487-4C90-92A1-01E1F92F5068@nosignal.org> Hi, Max. On 22 Dec 2009, at 11:14, Max Tulyev wrote: > I just hear I can't use IPv6 PI network for hosting service. Yes you can. Hi, Mark. On 22 Dec 2009, at 12:58, Mark Scholten wrote: > Changing it in a way that it is allowed (as it is technically > possible) to > use IPv6 PI for co location/dedicated servers/shared hosting/VPS > hosting/etc. would be a good point. You can do this. Best wishes, Andy From mohta at necom830.hpcl.titech.ac.jp Fri Dec 25 00:09:15 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 25 Dec 2009 08:09:15 +0900 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B30DB88.3050807@ukraine.su> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> Message-ID: <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> Max Tulyev wrote: > The problem is IPv6 Internet is still useless. It's not a problem. Use port restricted IPv4. > If it will be when IPv4 > runs out, the world will NOT be moved to IPv6, but will use NATs, trade > the rest of IPv4 blocks and so on. IPv6 will be ignored as working, but > useless thing. IPv6 will be ignored, because IPv6 is, technically, useless, which has nothing to do with IPv6 address allocation policy. Because IPv4 NAT can be fully transparent end to end, it's fine to use port restricted IPv4 with NAT. > I repeat my lovely phrase: If a majority (a half) of web resources will > be reachable via IPv6 when IPv4 will be finished, then MAY BE will be > the migration to IPv6. If not - then it fails. It's impossible because attempts of optional headers, path MTU discovery, stateless autoconfiguration, aggressive introduction of multicast etc. to make IPv6 better than IPv4 have totally failed only to make IPv6 and its operation a lot more complex and a lot less consistent than IPv4. Masataka Ohta From lorenzo at google.com Fri Dec 25 03:14:03 2009 From: lorenzo at google.com (Lorenzo Colitti) Date: Fri, 25 Dec 2009 03:14:03 +0100 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, Dec 25, 2009 at 12:09 AM, Masataka Ohta wrote: > IPv6 will be ignored, because IPv6 is, technically, useless, which > has nothing to do with IPv6 address allocation policy. > > Because IPv4 NAT can be fully transparent end to end, it's fine to use > port restricted IPv4 with NAT. Well, but there are lots of things you can't do with port restricted IPv4 and NAT. For example, run a peer-to-peer program with 1000 simultaneous connections. Run itunes and Google maps on or your computer, your girlfriend's computer, and your phone at the same time. Run proper VOIP and skype call without using third parties, which degrade your call quality if their internet connections drop packets. On the server side, IP address sharing on a large scale means lack of geolocation, and lack of geolocation means no location-aware services. Search for ramen from your hotel room and expect to find places nearby? Who knows, you might find something in Hokkaido. Want to stream a baseball game in San Francisco? You might not be able to, because the licensing for that content requires you not to be in San Jose and your IP address might mostly be in use by people in San Jose. Trying to go to a website? Better hope your IP address neighbors aren't sending it too many queries, because otherwise the website operator might block your IP address for excessive use. Without IPv6, there will be more and more pressure on port space as user numbers continue to grow, so these problems are likely to get worse and worse. What happens then is anybody's guess. Maybe the quality of Internet connections will get worse and worse and you'll need to pay more for a better connection? Maybe the only reliable services will be the services of the ISP you subscribe to, so we'll go back to a walled garden model? > It's impossible because attempts of optional headers, path MTU > discovery, stateless autoconfiguration, aggressive introduction > of multicast etc. to make IPv6 better than IPv4 have totally > failed only to make IPv6 and its operation a lot more complex > and a lot less consistent than IPv4. As someone who has designed and operated IPv6 networks, I can say it's not more complex, it's just different. In some ways it's easier, too: for example, the large address space eliminates allocation problems and allows addressing plans that are much easier to manage. Autoconfiguration is very useful, and so on. But of course, if you already know how IPv4 works and you don't want to learn anything new it will seem complex. As regards it being impossible, I disagree, and so would the hundreds of thousands of users who use Google over IPv6 every day (assuming they knew they were in fact using it). From mohta at necom830.hpcl.titech.ac.jp Fri Dec 25 05:52:32 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 25 Dec 2009 13:52:32 +0900 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> Message-ID: <4B344510.7030206@necom830.hpcl.titech.ac.jp> Lorenzo Colitti wrote: >>IPv6 will be ignored, because IPv6 is, technically, useless, which >>has nothing to do with IPv6 address allocation policy. >> >>Because IPv4 NAT can be fully transparent end to end, it's fine to use >>port restricted IPv4 with NAT. > Well, but there are lots of things you can't do with port restricted > IPv4 and NAT. FYI, I'm not talking about A+P, which is a combination of port restricted IP and poor legacy NAT with no end to end transparency. I'm talking about port restricted IP with full end to end transparency for all the applications including skype. See how all the applications, including ftp port command and skype, works as is. An implementation is already running. > For example, run a peer-to-peer program with 1000 > simultaneous connections. As a transport connection is identified by both source and destinaiton port numbers, you only need a single port to have 1000 simultaneous connections with 1000 other hosts. > Run itunes and Google maps on or your > computer, your girlfriend's computer, and your phone at the same time. It's trivially easy. Problems caused by improperly behaving applications should be solved by the improperly behaving applications. That's all. > On the server side, IP address sharing on a large scale means lack of > geolocation, and lack of geolocation means no location-aware services. If you want to destroy location privacy, you should better forbid ISPs use PPPoE, which destroys detailed geolocation already today. As there will be no port-wise routers at the backbone (there is no routing protocol to support port wise routing), hosts sharing an IP address are assured to be confined in small geographical area, unless you do yet another tunneling such as PPPoE. > Better hope your IP address neighbors > aren't sending it too many queries, because otherwise the website > operator might block your IP address for excessive use. That's no different from the situation today with DHCP assigned /24 or /16 shared by you and your neighbours. Still, it is a lot better than using IPv6, with which you can hardly reach any web site. > Without IPv6, there will be more and more pressure on port space as > user numbers continue to grow, so these problems are likely to get > worse and worse. So far, there is no problem of port restricted IP exist. > As someone who has designed and operated IPv6 networks, I can say it's > not more complex, You shouldn't > But of course, if you > already know how IPv4 works and you don't want to learn anything new > it will seem complex. As a person who changed IPv6 address structure from 10+6 to 8+8, trying to make IPv6 a little better than the worst, I know very well how IPv6 fails to work. If you don't want to learn anything new from your experience, it's your problem. Masataka Ohta From lorenzo at google.com Fri Dec 25 12:12:21 2009 From: lorenzo at google.com (Lorenzo Colitti) Date: Fri, 25 Dec 2009 12:12:21 +0100 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B344510.7030206@necom830.hpcl.titech.ac.jp> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, Dec 25, 2009 at 5:52 AM, Masataka Ohta wrote: > If you don't want to learn anything new from your experience, it's > your problem. Ah, of course, I understand now - it's my problem. Funny I didn't think of that :-) But it occurs to me that an address policy mailing list is not the right place to have a discussion on whether or not IPv6 makes sense. Apologies to the others on this list for following off-topic. I'll stop now. Regards, Lorenzo