RE: [address-policy-wg] IPv6 allocations for 6RD
Michael key words here are 'average' and 'generous'. Perhaps you should try to read first. Same goes for your statement of counting addresses. In cases like these, I think orders of magnitude are more interesting than narrowly defined numbers. 4 million is roughly 0.1% of the IPv4 pool. Since I think the AVERAGE ISP is probably smaller than that (either in customer count or allocated space), giving all of them 32 bits (or the full IPv4 space) PLUS 4-8 bits of network space (not host space!) for their 6rd plan sounds wasteful to me. The 6rd draft has prefix compression for a reason. Sparse number spaces for expansion and automation are fine. Very sparse number spaces you know from the outset will never be filled or usable for other purposes, are not. That is why deploying multiple instances of 6rd in order to benefit from prefix compression to collapse that required number space without losing functionality sounds like the right direction for me. Remco (and if we decide that a /24 is a better standard to hand out to LIRs than a /32, I can predict today that somebody will come up with a very clever reason to say that /16s are probably even better. Repeat until bored - or out of space.) -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of michael.dillon@bt.com Sent: vrijdag 27 november 2009 11:04 To: address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD
Fair enough, I'll bite. Given 2^32(or 4 billion) IPv4 addresses, and say, 4 million IP's allocated to the average ISP (I'm being generous here) there's your 0.1%. The rest of the space will go unused since we're using 32 bits to identify these sparse blocks in the v4->v6 translation. Not counting customer /56s, 48s, /60s or whatever.
But customers, and /56s are the essential things to count. Again, you just throw in the number 4 million without explaining where it comes from. IPv4 ISPs come in all sizes with one /24 allocation and some with many allocations of sizes ranging from /17 to /12. Counting IP addresses in IPv6 makes no sense. The addressing hierarchy of IPv6 is designed to have large blocks of unused and unusable addresses. This is both to allow for expansion without changing the network architecture, and to allow for automated address assignment functions which rely on large sparse number spaces to avoid collisions. --Michael Dillon 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.
Remco van Mook wrote:
Michael
key words here are 'average' and 'generous'. Perhaps you should try to read first. Same goes for your statement of counting addresses. In cases like these, I think orders of magnitude are more interesting than narrowly defined numbers. 4 million is roughly 0.1% of the IPv4 pool. Since I think the AVERAGE ISP is probably smaller than that (either in customer count or allocated space), giving all of them 32 bits (or the full IPv4 space) PLUS 4-8 bits of network space (not host space!) for their 6rd plan sounds wasteful to me.
The 6rd draft has prefix compression for a reason. Sparse number spaces for expansion and automation are fine. Very sparse number spaces you know from the outset will never be filled or usable for other purposes, are not.
Actually, the main reason we added this is for easy and obvious compression for when an SP has decided to run NAT. The RFC1918 space is nicely aggregated. Please don't give SPs more reasons to deploy NATted IPv4 service. Most SPs I talk to don't really like the idea of compressing the global space, if nothing else because they have no assurance that the global IPv4 space they have now will be the same in the future. They'd sooner give the customer a /64, which I've already stated why I personally think is dangerous.
That is why deploying multiple instances of 6rd in order to benefit from prefix compression to collapse that required number space without losing functionality sounds like the right direction for me.
There is nothing prohibiting multiple instances of 6rd in the current version of the draft, however note that this does not come without operational complexity - which is exactly what 6rd is trying to allow an SP to avoid. So, there's a cost tradeoff here. Increased prudence of IPv6 space vs. increased cost for ISPs to deploy IPv6. It's quite easy to be penny-wise and pound-foolish here, and given the rate of native deployment of IPv6 thus far, I'd err on the side of getting IPv6 out the door in the short term until we are sure it no longer needs a boost. Consider it similar to stimulus funds to counter a depression if you must, but if an ISP which would otherwise qualify for a /30 needs a /28 or /26 to get IPv6 deployed now vs. later, I'd choose handing out a few more bits until we no longer think it necessary for native IPv6 adoption to occur. - Mark
participants (2)
-
Mark Townsley -
Remco van Mook