Re: [address-policy-wg] IPv6 allocations for 6RD
Le 27 nov. 2009 à 17:16, Rémi Després a écrit :
Mikael Abrahamsson wrote:
I do *not* think 6RD bad design (or implementation) should warrant giving each ISP a /24 or /28.
The objective of 6rd has been to make native IPv6 connectivity quickly available to millions of residential customers. For this, it was important to relieve the first concerned ISP of fear, uncertainty, and doubt, concerning expenses to be incurred. This objective has been brilliantly achieved when Free, after only 5 weeks, evolved from "we don't want to spend a Euro on IPv6" to "IPv6 is available to our customers who wish to activate it with a click". If promoting IPv6, not only with words but also in reality, is considered a legitimate objective, then it is fair to view 6rd as a "good design" for what it was set to achieve. Similarly, what Free did should be seen as a "remarkably fast and effective implementation". No hard feelings, but I felt this needed to be said. Regards, RD (Inventor of 6rd, no professional link with Free.)
On Fri, 27 Nov 2009, Rémi Després wrote:
No hard feelings, but I felt this needed to be said.
There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful. I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD. As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely. -- Mikael Abrahamsson email: swmike@swm.pp.se
No hard feelings, but I felt this needed to be said.
There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful.
This is not wasteful. It is an elegant extension to the IPv6 architecture. Using a standard /64 prefix for all network segments containing more than a single device, is also an elegant solution and is part of the IPv6 standard. The same is true of the standard /48 assignment per site which provides every site with 8 bits of space to subnet their site into /64 networks, regardless of whether they "need" 1 subnet or 100 subnets. Numbers cost nothing. By "wasting" lots of numbers, we can achieve a simpler design that saves real money, and real effort for millions of people building and managing IPv6 networks. IPv4 had a very limited address space and we had to be very careful about wasting numbers until there was a new protocol ready to replace it. That time has come, so there is no need to talk about wasting numbers any more. In reality, the issue wasn't how many numbers were wasted, but what percentage of the total number space was wasted. In IPv6, by design, we are putting entire ISPs into the same percentage of the total number space, /32, as a single host in IPv4.
I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD.
In IPv4, we gave out /24 blocks to actual real mom and pop ISPs not just metaphorical ones. I see no reason to treat IPv6 as a more scarce resource to IPv4, and therefore, if a mom and pop ISP really does need a /24 to transition using 6RD, then I would say we should give it to them. However, I suspect that small ISPs like that would not actually require a /24 to effectively do 6RD.
As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely.
You have probably written more detail on what a 6RD policy would look like than anyone so far. For the sake of clarity, perhaps you could submit a policy proposal and then we will all have something specific to discuss. I would support a special policy for 6RD even if it does nothing more than clarify how RIPE currently treats IPv6 requests for use with 6RD. --Michael Dillon
On Fri, 27 Nov 2009, michael.dillon@bt.com wrote:
This is not wasteful. It is an elegant extension to the IPv6 architecture. Using a standard /64 prefix for all network segments containing more than a single device, is also an elegant solution and is part of the IPv6 standard. The same is true of the standard /48 assignment per site which provides every site with 8 bits of space to subnet their site into /64 networks, regardless of whether they "need" 1 subnet or 100 subnets.
16 bits between /48 and /64, but apart from that I'm in total agreement with you.
Numbers cost nothing. By "wasting" lots of numbers, we can achieve a simpler design that saves real money, and real effort for millions of people building and managing IPv6 networks.
The thing here is that if you have an AS then you qualify for a /32. What I don't like about this policy is that then you come around and say "6RD" and then you get a /24 as well, this leads to DFZ pollution.
IPv4 had a very limited address space and we had to be very careful about wasting numbers until there was a new protocol ready to replace it. That time has come, so there is no need to talk about wasting numbers any more.
If all ASNs do this then we'll have done away with /8. That's not a large part of IPv6 space, so perhaps it's ok.
In IPv4, we gave out /24 blocks to actual real mom and pop ISPs
I didn't say this was right. DFZ pollution.
not just metaphorical ones. I see no reason to treat IPv6 as a more scarce resource to IPv4, and therefore, if a mom and pop ISP really does need a /24 to transition using 6RD, then I would say we should give it to them. However, I suspect that small ISPs like that would not actually require a /24 to effectively do 6RD.
How do you judge if they "really need it"?
You have probably written more detail on what a 6RD policy would look like than anyone so far. For the sake of clarity, perhaps you could submit a policy proposal and then we will all have something specific to discuss.
I'll write it in regular form then, grabbing some arbitrary numbers off the top of my head without any real motivation, because there are no hard limits. I'll put in some unjustified sticks with the carrots as well. here goes: An ISP/ASN qualifies for a /24 for 6RD if they fulfil the following criteria: * Have at least 4 different IPv4 subnets they have customers who will use 6RD in. * Will hand out /56 subnets to 6RD enabled customers. * Will return (if any) existing /32 IPv6 space already assigned, and use the highest /32 in the /24 for native IPv6 infrastructure and customers. When 6RD is no longer in use, the part of the /24 no longer motivated shall be returned. This proposal means no extra DFZ pollution, requires ISPs to use 6RD to actually hand out subnets and tells them to use the part of the /24 that maps into IPv4 class E space (240.0.0/4), thus not used, and when 6RD is no longer in use they keep that /32 unless they have grown and require more space. They can grow to /28 and still be in equivalent class E space. I'm not sure if we can even go to /27, I guess we don't need to map class D (224.0.0.0/4) either, the top /27 would be available? -- Mikael Abrahamsson email: swmike@swm.pp.se
Le 27 nov. 2009 à 19:36, Mikael Abrahamsson a écrit :
On Fri, 27 Nov 2009, Rémi Després wrote:
No hard feelings, but I felt this needed to be said.
There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful.
Right (that's the use of 6rd which can create problems, not it's design or its implementation in gateways and home gateways).
I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD.
As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely.
/28 for any ISP having several IPv4 prefixes and committed to deploy 6rd would be IMHO a good choice. In practice, /60s to customer sites is quite sufficient, at least in the short term. (Note that mom and pop ISPs, presumably having each only one IPv4 prefix, would remain with /32s.) Then, going up to /24 for ISPs that deploy 6rd with at least 4 IPv4 prefixes, as you propose in another mail, would not be necessary, but could be a useful option. Regards, RD
Hi Remi, could you help me in understanding why an ISP with, say, a /14 and 2 /16s of address space would need a /28 of space to do 6rd? In my understanding, even using a /56 per customer would give you a requirement for just 19 bits of ipv6 space (18 bits for the /14, 1 extra to also make the /16s fit) on top of the /56s, if you just use 3 instances of 6rd and prefix compression. This gives a requirement of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch of /15s and /24s to the mix, it will only add a few bits to the requirement, not 11. Not that I don't want to give out the space if needed, but I'm trying to understand the reasoning behind it. I find 'too complicated' a tough argument to swallow given that the current and working IPv4 setup in an environment like this is already way more complicated. Best, Remco -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Rémi Després Sent: zaterdag 28 november 2009 9:50 To: Mikael Abrahamsson Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Le 27 nov. 2009 à 19:36, Mikael Abrahamsson a écrit :
On Fri, 27 Nov 2009, Rémi Després wrote:
No hard feelings, but I felt this needed to be said.
There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful.
Right (that's the use of 6rd which can create problems, not it's design or its implementation in gateways and home gateways).
I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD.
As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely.
/28 for any ISP having several IPv4 prefixes and committed to deploy 6rd would be IMHO a good choice. In practice, /60s to customer sites is quite sufficient, at least in the short term. (Note that mom and pop ISPs, presumably having each only one IPv4 prefix, would remain with /32s.) Then, going up to /24 for ISPs that deploy 6rd with at least 4 IPv4 prefixes, as you propose in another mail, would not be necessary, but could be a useful option. Regards, RD 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.
On 28 nov 2009, at 15:57, Remco van Mook wrote:
Hi Remi,
could you help me in understanding why an ISP with, say, a /14 and 2 /16s of address space would need a /28 of space to do 6rd? In my understanding, even using a /56 per customer would give you a requirement for just 19 bits of ipv6 space (18 bits for the /14, 1 extra to also make the /16s fit) on top of the /56s, if you just use 3 instances of 6rd and prefix compression. This gives a requirement of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch of /15s and /24s to the mix, it will only add a few bits to the requirement, not 11.
Not that I don't want to give out the space if needed, but I'm trying to understand the reasoning behind it. I find 'too complicated' a tough argument to swallow given that the current and working IPv4 setup in an environment like this is already way more complicated.
My I propose to add the following to section 3.5 of RIPE-481 (or similair wording) analogues to 6.5 of the v4 policy: Current text: 3.5. Conservation Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. Proposed new text: 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. Rationale: Classfull addressing in IPv4 proofs a nice example, but one can also look at 16 bit ASN or the global supply of oil for proof that resources that once seemed infinite can become scarce. Especially in 'greenfield' deployments such as 6rd, which is still in the process of being standardized, and IPv6 in general, circumstances which may be considered 'wastefull' can be easily avoided. Arguments supporting the proposal: We slowly become aware what the costs of deploying a new technique or protocol are, one of the prime arguments global addoption of 32 bit ASN and IPv6 is slow is cost. We should try and prevent future cost by doing the same exercise twice by all means. We keep telling our selves and the rest of the world IPv6 is not different, "96 bits no difference", it seems logical to keep the policies as much the same as possible. One might argue that with standardizing an ethernet subnet to 64 bits all was lost anyway, this is not the case and mistakes from the past should be used as an example to prevent further damage instead of a validation to make the same mistake twice. Arguments against this proposal: By addopting this change now we again create a difference between the early adopters and people who follow, this is similair to the assignment of /8 address blocks in the early days of IPv4. By prohibiting assignment for administrative ease we will slow IPv6 adoption even more MarcoH
Current text:
3.5. Conservation Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.
Seems reasonable to me. It implies that giving someone a /21 based on their 6RD requirements is OK, but that they would have to return the allocation once they no longer need the transitional 6RD service.
Proposed new text:
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 disagree with this. If we are willing to accept that allocations can be temporary, and should be returned when no longer needed, then administrative ease is a good reason to justify a larger allocation, particular when this supports transition to native IPv6 networks. If a company needs a /21 to ease the burden of transition, and will return it to RIPE in 5 to 10 years after native IPv6 is fully deployed in their network then that seems reasonable to me. Any concerns that we have with possible shortages of IPv6 address space are well beyond the IPv6 transition, therefore 10 years should be considered short-term. --Michael Dillon
Le 28 nov. 2009 à 15:57, Remco van Mook a écrit :
Hi Remi,
could you help me in understanding why an ISP with, say, a /14 and 2 /16s of address space would need a /28 of space to do 6rd? In my understanding, even using a /56 per customer would give you a requirement for just 19 bits of ipv6 space (18 bits for the /14, 1 extra to also make the /16s fit) on top of the /56s, if you just use 3 instances of 6rd and prefix compression. This gives a requirement of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch of /15s and /24s to the mix, it will only add a few bits to the requirement, not 11.
The point is a tradeoff between simplicity, a condition for quick and safe deployment, and optimized use of address bits. 6rd is just what it is: a simple tool to offer quickly native IPv6 to customers, this without ISPs having, in a first step, to modify existing IPv4 infrastructures. Indeed, some more optimized address coding schemes are possible. But they introduce additional complexity (variable number of parameters, less readability of encoded addresses for maintenance, longer process to agree on detailed formats etc.). Now, drawbacks of not supporting this additional complexity, are in practice minimal: - 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). - A /60 per customer site is largely enough to start using IPv6, even for sophisticated users that configure several LANs in their sites. Furthermore, if 16 LANs is not enough in a site, ISATAP can be used to deploy IPv6 on its complex topology. - 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). In summary, and IMHO: o ISPs that don't obtain more generous IPv6 prefixes than /32s can at least start with /64s assigned to customers. o RIRs should allocate at least /28s to ISPs that have several IPv4 prefixes and plan to deploy 6rd. o These ISPs should return these prefixes if, for any reason, they become more generous than needed. Regards, RD
Not that I don't want to give out the space if needed, but I'm trying to understand the reasoning behind it. I find 'too complicated' a tough argument to swallow given that the current and working IPv4 setup in an environment like this is already way more complicated.
Best,
Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Rémi Després Sent: zaterdag 28 november 2009 9:50 To: Mikael Abrahamsson Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Le 27 nov. 2009 à 19:36, Mikael Abrahamsson a écrit :
On Fri, 27 Nov 2009, Rémi Després wrote:
No hard feelings, but I felt this needed to be said.
There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful.
Right (that's the use of 6rd which can create problems, not it's design or its implementation in gateways and home gateways).
I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD.
As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely.
/28 for any ISP having several IPv4 prefixes and committed to deploy 6rd would be IMHO a good choice. In practice, /60s to customer sites is quite sufficient, at least in the short term. (Note that mom and pop ISPs, presumably having each only one IPv4 prefix, would remain with /32s.)
Then, going up to /24 for ISPs that deploy 6rd with at least 4 IPv4 prefixes, as you propose in another mail, would not be necessary, but could be a useful option.
Regards, RD
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.
- 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.
- 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. 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. There is no need to make customer assignments smaller than /56.
- 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. It is better to go back to RIPE, explain the situation, and get a /24 or /21.
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.
o RIRs should allocate at least /28s to ISPs that have several IPv4 prefixes and plan to deploy 6rd.
Wrong. 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.
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. --Michael Dillon
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
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@kpn.com -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Marco Hogewoning Sent: maandag 30 november 2009 22:21 To: michael.dillon@bt.com Cc: address-policy-wg@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
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
On Tue, 1 Dec 2009, michael.dillon@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@swm.pp.se
"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" <swmike@swm.pp.se> wrote:
On Tue, 1 Dec 2009, michael.dillon@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@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.
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.
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 <jim@rfc1035.com>:
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.
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.
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 <jim@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.
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
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 <randy@psg.com>:
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
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
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 <randy@psg.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.
i guess you are younger than jim or i.
no fix sized bit string has even withstood the test of time. none.
randy
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
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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von David Conrad Gesendet: Dienstag, 1. Dezember 2009 18:07 An: Florian Frotzler Cc: address-policy-wg@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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Florian Frotzler Sent: dinsdag 1 december 2009 19:37 To: 'David Conrad' Cc: address-policy-wg@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@ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von David Conrad Gesendet: Dienstag, 1. Dezember 2009 18:07 An: Florian Frotzler Cc: address-policy-wg@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.
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
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@swm.pp.se
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
* 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.
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@swm.pp.se
* 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?
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@swm.pp.se
On Wed, 2 Dec 2009, michael.dillon@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@swm.pp.se
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
* 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.
On Wed, Dec 2, 2009 at 4:04 AM, <michael.dillon@bt.com> 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.
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
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 <marcoh@marcoh.net>:
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
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
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 <marcoh@marcoh.net>:
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
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
2009/12/2 Marco Hogewoning <marcoh@marcoh.net>:
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
On 2 dec 2009, at 10:52, Florian Frotzler wrote:
2009/12/2 Marco Hogewoning <marcoh@marcoh.net>:
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
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
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
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
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
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 <http://www.ripe.net/ripe/docs/charging2010.html> 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
* 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 <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Hi, On Thu, Dec 03, 2009 at 09:51:28AM -0000, michael.dillon@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
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@virtualized.org] Gesendet: Mittwoch, 2. Dezember 2009 17:29 An: Florian Frotzler Cc: address-policy-wg@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,
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
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. 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
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
2009/12/2 David Conrad <drc@virtualized.org>:
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
* 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.
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
On 3 Dec 2009, at 10:00, <michael.dillon@bt.com> 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.
On 3 Dec 2009, at 10:00, <michael.dillon@bt.com> 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
On 3 Dec 2009, at 10:00, <michael.dillon@bt.com> 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
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
/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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of michael.dillon@bt.com Sent: 03 December 2009 13:20 To: address-policy-wg@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
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
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
On Dec 3, 2009, at 7:55 AM, Dmitriy V Menzulskiy wrote:
On 3 Dec 2009, at 10:00, <michael.dillon@bt.com> 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
Hello, On 03.12.2009, at 13:08, Jim Reid wrote:
On 3 Dec 2009, at 10:00, <michael.dillon@bt.com> 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@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
* 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.
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 <lutz@iks-jena.de>:
* 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.
* 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.
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 <lutz@iks-jena.de>:
* 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.
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
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
On 1 Dec 2009, at 10:42, <michael.dillon@bt.com> <michael.dillon@bt.com> 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
Le 30 nov. 2009 à 22:15, <michael.dillon@bt.com> <michael.dillon@bt.com> 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
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
/28 for any ISP having several IPv4 prefixes and committed to deploy 6rd would be IMHO a good choice. In practice, /60s to customer sites is quite sufficient, at least in the short term.
No, /60s to customer sites is not sufficient. It breaks the IPv6 model of fixed size site allocations which assumes that all sites will have /48 assignments unless they are private residences in which case they will have /56 prefixes. This uniformity is essential in order to allow people to innovate with IPv6. We should not force 6RD ISPs into making this kind of mistake, especially since 6RD is only a transition measure, and if an ISP gets /60 encoded into all their systems and processes, then they will be stuck with it long after 6RD has disappeared. That would be an IPv6 equivalent of the swamp, i.e. a short sighted, short term decision with negative long term consequences. --Michael Dillon
* michael dillon:
No, /60s to customer sites is not sufficient. It breaks the IPv6 model of fixed size site allocations which assumes that all sites will have /48 assignments unless they are private residences in which case they will have /56 prefixes. This uniformity is essential in order to allow people to innovate with IPv6.
Ahem, future innovation with IPv6 (whatever that is, beyound disabling insecure protocol features) needs to take VSLM into account. It's also likely that the requirement that all unicast addresses most be within at least a /64 will be eventually overturned because those bits could be used in a more useful fashion. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Hi, On Mon, Nov 30, 2009 at 08:45:52AM +0000, Florian Weimer wrote:
Ahem, future innovation with IPv6 (whatever that is, beyound disabling insecure protocol features) needs to take VSLM into account. It's also likely that the requirement that all unicast addresses most be within at least a /64 will be eventually overturned because those bits could be used in a more useful fashion.
This is well out of scope for any address policy discussion going on today. When and if the IETF decides that non-/64-subnets are a desirable feature, it makes sense to discuss the consequences on address policy here - before that, it's a waste of bits. Please let's be focussed on the question at hand - which side do we want to err to? - be very conservative in giving out IPv6 address space, risking that IPv6 will just never take off - for fear of running out of space "if we happen to very radically move the boundary by 8 bits multiple times" - be very liberal in giving out IPv6 address space, risking that we run out of FP001 sooner than expected, and that we will have to do a more restrictive policy later on - but doing our best to actually get IPv6 out and deployed Whatever we decide, history will tell us that we have been wrong in our predictions... Given the original question: as far as I understood the question, the RIPE NCC IPRAs consider the request to be inside the boundaries permitted by policy, if a bit larger than "typical". So we don't really need a formal policy change here, just guidance to the IPRAs "this is a good thing, give them the address space" or "this is not a good thing, refuse!". 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 is a good thing, give them the address space <- Managing various SP prefix is a burden for large operators or might even be a show-stopper for 6RD rollout. Cheers, Florian 2009/11/30 Gert Doering <gert@space.net>:
Hi,
On Mon, Nov 30, 2009 at 08:45:52AM +0000, Florian Weimer wrote:
Ahem, future innovation with IPv6 (whatever that is, beyound disabling insecure protocol features) needs to take VSLM into account. It's also likely that the requirement that all unicast addresses most be within at least a /64 will be eventually overturned because those bits could be used in a more useful fashion.
This is well out of scope for any address policy discussion going on today.
When and if the IETF decides that non-/64-subnets are a desirable feature, it makes sense to discuss the consequences on address policy here - before that, it's a waste of bits.
Please let's be focussed on the question at hand - which side do we want to err to?
- be very conservative in giving out IPv6 address space, risking that IPv6 will just never take off - for fear of running out of space "if we happen to very radically move the boundary by 8 bits multiple times"
- be very liberal in giving out IPv6 address space, risking that we run out of FP001 sooner than expected, and that we will have to do a more restrictive policy later on - but doing our best to actually get IPv6 out and deployed
Whatever we decide, history will tell us that we have been wrong in our predictions...
Given the original question: as far as I understood the question, the RIPE NCC IPRAs consider the request to be inside the boundaries permitted by policy, if a bit larger than "typical". So we don't really need a formal policy change here, just guidance to the IPRAs "this is a good thing, give them the address space" or "this is not a good thing, refuse!".
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
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
* Rémi Després:
This objective has been brilliantly achieved when Free, after only 5 weeks, evolved from "we don't want to spend a Euro on IPv6" to "IPv6 is available to our customers who wish to activate it with a click".
Does this approach give the customer the ability to connect multiple devices? If not, stateless autoconfiguration is probably unnecessary, and 6RD could do without /64 subnets, freeing additional bits for internal addressing at the ISP level. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Le 30 nov. 2009 à 09:39, Florian Weimer a écrit :
* Rémi Després:
This objective has been brilliantly achieved when Free, after only 5 weeks, evolved from "we don't want to spend a Euro on IPv6" to "IPv6 is available to our customers who wish to activate it with a click".
Does this approach give the customer the ability to connect multiple devices?
Yes, and this is important. Each customer site can have as many Windows, OS X, and Linux PCs on its internal LAN. They automatically configure their IPv6 address (unless their IPv6 is not enabled), and then communicate in IPv6 with all servers that are IPv6 enabled (Google servers in particular) without users even noticing it. Having only a /64 in a residential site starts having consequences only if there is a need to install several LANs that are strictly independent (i.e. LANs that are not, like most Wifi and other Ethernet LANs, linked by layer 2 switches). Only sophisticated users would notice any limitation. Regards, RD
If not, stateless autoconfiguration is probably unnecessary, and 6RD could do without /64 subnets, freeing additional bits for internal addressing at the ISP level.
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
participants (22)
-
Andy Davidson -
David Conrad -
Dmitriy V Menzulskiy -
Florian Frotzler -
Florian Weimer -
Gert Doering -
Hindley, Martin -
IP-Office KPN -
Janos Zsako -
Jim Reid -
Lorenzo Colitti -
Lutz Donnerhacke -
marc.neuckens＠belgacom.be -
Marco Hogewoning -
Marshall Eubanks -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Randy Bush -
Ray.Bellis＠nominet.org.uk -
Remco van Mook -
Remco van Mook
-
Rémi Després -
Ulrich Kiermayr