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.