[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-bagnulo-v6ops-6man-nat64-pb-statement-00.txt



I had not considered the example of the enterprise where what you describe makes a lot of sense.

From a carrier perspective once we move to dual-stack it seems unlikely that we would move towards an alternative for v4 (be it NAT64 or other). I suspect that once dual-stack has been adopted a carrier would be reluctant to change as there is minimal (financial) effort. In the enterprise space it would seem reasonable to do as you suggest, to employ NAT64 given the majority of the applications would be v6- enabled.

This leaves the question of NAT46 and what role it should play in a transition? Once we pass the point of v4/v6 equilibrium are there cases where legacy IPv4 devices may wish to access resources that can only support unsolicited inbound connections over IPv6 (servers). The alternative to use a public IPv4 address may not be possible if v4 is in short supply.

As always adoption of technology will be driven by three related attributes: cost, complexity and benefit (or revenue for a carrier). For a new network who's applications can be mostly IPv6 (and where OS support a v6-only approach) it may make sense to avoid IPv4 completely. For a network which supports applications that are predominately IPv4 a change to IPv6 with translation would be difficult to justify, and I'd think we are more likely to see a dual- stack approach.

Regards,

-David


On 25/11/2007, at 8:54 PM, Iljitsch van Beijnum wrote:

On 24 nov 2007, at 1:35, David Miles wrote:

After all, if we come up with a "translation" protocol for IPv6 to IPv4 then we have not absolved ourselves from solving the issue for non-IPv6 hosts.

Which issue?

What will you do with those devices that do not support IPv6?

Today, the assumption is that all services are available over IPv4. I expect this situation to continue for some time, probably even one or two years beyond the moment that the first IPv4 address request must go unsatisfied because of the depletion. During that time, IPv4- only hosts shouldn't have any problems, except of course those introduced by measures to conserve IPv4 addresses such as NAT.

At some point, either some services will be available over IPv4 and some over IPv6, or the assumption will be that all services are availble over IPv6. At that point, IPv4 hosts will need to use additional mechanisms but they'll still probably have trouble reaching certain services. This is a natural consequence of not adopting new technologies within a reasonable timeframe, and I don't think the IETF should go out of its way to create workarounds for this.

In an IPv4 address depleted world, non-IPv6 devices still need to work!

They do, you just can't add new ones.

I'm somewhat confused - are you suggesting the operator runs two versions of IP side by side?

Every ISP that is in business today obviously runs IPv4. In my opinion, they should also be running IPv6 within the next three years. So that would be a "yes". However, if I were to build an enterprise network, I would certainly see if I could limit IPv4 to the places where the services run and only do IPv6 in the access part. Running just IPv6 is simpler because addressing issues pretty much go away: there is no need for routes running OSPF etc to have addresses in the same IP subnet. You have more subnets than VLANs, simply encode the VLAN ID in the subnet bits and you've numbered all your IP subnets. Each of those is a /64 so they can all hold as many hosts as you can cram into them, no need to think about how large to make a subnet. With EUI-64 addressesing, you don't have to keep track of which router holds the .1 address, which holds the .2 address and so on.