[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.