Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com) [LWN.net]

Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

Posted Oct 22, 2010 15:36 UTC (Fri) by tialaramex (subscriber, #21167)
In reply to: Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com) by dlang
Parent article: Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

They won't have to disguise it at all. With the termination of the IPv4 allocation function ARIN's role changes with it continuing to administrate the IPv4 registry but now tracking transfers not allocations. But it won't make enough difference to care about.

ARIN is a creature of its member organisations as are RIPE and the other RIRs.

This also somewhat answers neilbrown's point. RIRs are basically associations (the exact legal mechanics vary by jurisdiction) and their LIR members pay fees. I don't know what the fee schedule looks like for ARIN, but in RIPE the fees are partly proportional (not linearly) to allocation size. This is also reflected in the organisation's structures.

Now, an LIR may be an ISP passing those fees on indirectly to customers, or it may itself be an association, or a government body, or any other manner of entity which needs large address allocations. And the LIR's customers or members, or whatever, may not ever receive a bill saying "4 IP addresses $3.86 per year" but the cost of running the registry function is already being recovered, just not necessarily as a line item that's visible to you in your current position. There is no justification for recovering more than the cost, nor any mechanism to spend money raised in this way, whether somehow on IPv6 or on a giant model of the Starship Enterprise.

to post comments

Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

Posted Oct 22, 2010 18:04 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

I don't expect that the cost of IPv4 IP addresses will be paied to a LIR, I expect it to be paid to companies who have large IPv4 allocations, but who can reorginize their network to use fewer IPv4 addresses (probably by using NAT of some sort), who then sell their larger allocation to the highest bidder.

the issue is that until all the websites move onto IPv6 addresses, people trying to access them will need to seem like they have an IPv4 address. This can be done by either assigning them an IPv4 address (in which case, why do you need IPv6?), or by something like NAT64.

no company is going to setup a IPv6-only service until all the clients they want to serve have IPv6 addresses, no clients really care about having IPv6 addresses until there is something that they need to access on IPv6 that they can't access on IPv4.

This is a classic chicken and egg problem.

ISPs could eventually break this deadlock if they use something like NAT64 to give their users IPv6 addresses only and still let them access IPv4 resrouces.

but the question remains, why would they do this instead of just using the RFC IPv4 addresses and IPv4 NAT to access the Internet? what's in it for the ISP to use something new and experimental rather than something old and well understood?

Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

Posted Oct 22, 2010 19:30 UTC (Fri) by lutchann (subscriber, #8872) [Link] (4 responses)

> but the question remains, why would they do this instead of just using the RFC IPv4 addresses and IPv4 NAT to access the Internet?

Because they already need far more addresses than what's available in the 1918 address space. It's not like large ISPs could just crack open 10.x.x.x/8 and never worry about address exhaustion again. In reality, virtually every provider has been using 1918 space for their infrastructure for years. Comcast exhausted the 1918 space in 2005.

Take a look at this presentation, which is actually from 2006 and outdated:

http://www.ripe.net/ripe/meetings/ripe-54/presentations/I...

Comcast expects to need 100 MILLION addresses FOR SET-TOP BOXES ALONE. There are only 17.9 million addresses in the entire RFC1918 space, assuming 100% usage, which is far from achievable in reality. And this doesn't even count VoIP or actual Internet access for customer PCs. They'd have to reuse 1918 space dozens of times and place NATs all over their network internally.

Ask the mobile phone companies how much fun it is to put this many devices behind NATs and try to manage them all. Verizon Wireless has more than 40 instances of 10.x.x.x/8 on their network, despite the fact that they've got more global IPv4 address space than any other mobile carrier. Traffic from millions of customers has to be hauled back to a few centralized NATs, who have to statefully translate millions of simultaneous sessions. That's a lot of long-distance transit and processing power that will be eliminated as the Internet transitions to IPv6.

You call IPv6 "new and experimental" but I think there is a lot more uncertainty and expense in deploying NAT at the scale that would be required to extend the lifetime of IPv4 for even ten more years.

Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

Posted Oct 22, 2010 19:34 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

it's not IPv6 that I'm saying is new and experimental, it's NAT64 which would allow IPv6-only systems to talk to IPv4 hosts.

just deploying IPv6 in addition to IPv4 doesn't do anyone any good, and until websites all move to IPv6 the ISPs can't eliminate IPv4 compatibility.

so the ISPs are going to have to NAT anyway. it makes more sense for them to NAT near the clients rather than to backhaul all the traffic to a handful of core NAT devices, and if they are doing NAT in multiple places anyway, what is the advantage of doing NAT from IPv6 sources vs IPv4 sources? (other than the "the internet will be IPv6 eventually anyway, so you should accept the pain and be the first on the block to go IPv6" argument)

Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

Posted Oct 22, 2010 20:32 UTC (Fri) by lutchann (subscriber, #8872) [Link] (2 responses)

Again, it's all about having enough addresses. For ISPs to continue providing native IPv4 service to customers (where "native" might mean 1918 addresses and provider-side NAT44) they'll need to maintain an IPv4 infrastructure, which, again, they don't have enough addresses for without using overlapping 1918 blocks and internal NAT. If customers are IPv6-only, the ISP's infrastructure can be IPv6-only.

As you point out, some customers may occasionally require access to IPv4-only services on the legacy Internet, at least for the first year or so.</sarcasm> There are three ways this could be handled. First, the ISP could provide native dual-stack service to customers using 1918 addresses and NAT44 for IPv4, but obviously, if they were able to do this, they wouldn't bother rolling out IPv6 in the first place.

The second option would be NAT64, which I agree is new and experimental, although T-Mobile has tested it extensively and says it works surprisingly well. The main problem is that all devices at the customer site must be able to operate IPv6-only, so Aunt Tilly with her Windows 98 laptop isn't going to be happy. In addition, many applications (especially games) don't have IPv6 support even when running on an IPv6-capable OS. So NAT64 isn't really viable for most residential customers.

The most promising option is DS-Lite, which provides NAT'd IPv4 service via an IPv4-in-IPv6 tunnel. One endpoint of the tunnel is the home router or cable modem and the other endpoint is a NAT44 in the provider's network. This allows the provider's core network to be IPv6 only, but customer devices will have both IPv4 and IPv6 service. NAT sessions in the CGN are indexed by both the source IPv4 address and the IPv6 tunnel endpoint, so if two customer sites use the same IPv4 address range, there's no problem.

DS-Lite neatly solves a lot of problems: legacy IPv4 devices and applications at the customer site will still work, providers only need to run one protocol on their core network, global IPv4 addresses can be utilized efficiently, and there is only one NAT in the path because there is no longer a need to NAT at the customer site. DS-Lite relies on two well-tested technologies, IP-in-IP tunnelling and NAT44.

A number of ISPs have indicated they'll probably be deploying DS-Lite, including Comcast.

Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

Posted Oct 22, 2010 21:00 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

is there something similar to NAT64 that could be run on the home routers that would let people run IPv4 internally, NAT to IPv6 on the router, and then NAT64 back to IPv4 later?

I cringe at even typing this, but it may be better than having to tunnel everything to specific endpoints. If enough ISPs were to go this route, they could start peering to each other with IPv6 and the traffic would just get converted to IPv4 as it goes to the servers.

I don't think that the DS-Lite approach will have the results you are expecting, because customers will still be running NAT on their devices.

Level Up to IPv6 with Ubuntu 10.10 on Comcast (Linux.com)

Posted Oct 23, 2010 14:51 UTC (Sat) by lutchann (subscriber, #8872) [Link]

> is there something similar to NAT64 that could be run on the home routers that would let people run IPv4 internally, NAT to IPv6 on the router, and then NAT64 back to IPv4 later?

That's called NAT464 and it's been discussed off and on as a possible transition tool, but I haven't seen a lot of support for it as DS-Lite is generally agreed to be the most robust approach. You'll probably see NAT464 in mobile phone networks to avoid the tunnelling overhead of DS-Lite.

> I cringe at even typing this, but it may be better than having to tunnel everything to specific endpoints. If enough ISPs were to go this route, they could start peering to each other with IPv6 and the traffic would just get converted to IPv4 as it goes to the servers.

Not sure I follow...if an IPv6-enabled host on one network wants to communicate with an IPv6-enabled host on another network, there will be no translators in the path. It will all be native IPv6. DS-Lite only tunnels and translates traffic headed for an IPv4-only destination.

> I don't think that the DS-Lite approach will have the results you are expecting, because customers will still be running NAT on their devices.

Regardless of the transition mechanism used, we have to expect that some people will just connect their old IPv4 NAT box to their shiny new v4/v6 box running DS-Lite or NAT464 or whatever. With DS-Lite, you'd then have double-NAT, and with NAT464, you'd then have triple NAT. It should generally work, it's just silly and adds one more point of failure.