[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Follow-up work on NAT-PT
Brian, perhaps we need to better understand the reasoning behind the
request and what "real estate" mean?
I'd like to think there is a day that IPv4 can be retired from a
service provider's network. It is not necessarily the dual-stack
nature of the access network that will increase the cost, but the
amount of NAPT that may need to occur within the service provider to
continue v4 ops in a address-depleted environment. During transition
period there will be dual-stack and eventually v4-NAPT (for at least
some customers).
My view is that:
- During transition dual stack should be what every new device
supports (ie, IPv6-only stacks is a bad idea during the transition
period)
- During transition we will see a move from IPv4 towards IPv6
- We should support connectivity for legacy clients as best we can
until transition is complete
So, the last point is most interesting - support the legacy customer
base. These are the customers who have not got devices that are dual-
stack or who are accessing services/servers that are not yet IPv6-
enabled. With 79% of the market running Windows XP (Net Applications
Oct 2007) we need to consider how to transition the bulk of our
customers to IPv6. The methods are (in order of preference from the
Service Provider's perspective):
- Enable IPv6 in their existing OS
- Upgrade to a new OS
- Translation (along the lines of NAT-PT or the NAT46 component of
draft-durand-ngtrans-nat64-nat46)
Translation of any kind should be last resort, but this is where I'm
interested to get thoughts on NAT-PT revival for an IPv4-only host OS
contacting an IPv6 server (with the same limitation as today's IPv4
NA(P)T. I'm assuming that one day IPv4 resources will be too
impractical (cost) to obtain so some business may be faced with IPv6-
only connectivity for _servers_. Does anyone else think there may be a
day when IPv4-only clients may exist (through provider NAPT) and
because of v4 address shortages running a server on a well known port
(http) may be restricted to IPv6 - to me this is a case for NAT46/NAT-
PT - but its anyone's guess whether this day will come.
-d
On 11/11/2007, at 3:12 AM, Christian Huitema wrote:
I don't think that we need to optimize for IPv6 only hosts. In
practice, we can expect that IPv6 capable hosts will either be dual
stack. Device designers will want to accommodate situations where
their device connects to either an IPv6 network, or an IPv4 network.
Implementing "dual stack" is not much harder than implementing "IPv6
only", so this is pretty much a no-brainer.
We need to optimize for reliability and operation support. There, we
have to reconcile the tension between two goals: networks are
simpler and easier to operate if they support one protocol instead
of two; and, networks are simpler if they do not rely on complex and
error prone gateways.
Is it really more efficient for an ISP to operate an IPv6 only
network? If it is, then IPv4 services will have to be provided
through some kind of overlay. On the provider side, the overlay will
have connect to some IPv4 "gateways" that give access to the global
IPv4 service. On the client side, the overlay will extend either all
the way to the client itself, or terminate at the "access router".
If we just want to reuse old technology, the overlay can be built
with simple tunnels. Access routers routinely support protocols like
PPPoA or PPPoE. PPP over IPv6 (PPPo6?) would not be much of a
stretch. It would also not look to strange on the ISP side, since
after all ISP are quite used to support PPP servers.
If we don't like the hub and spoke nature of PPP, we can of course
be creative and build the overlay with some form of automatic
tunneling. But I am not sure that the automatic tunneling will
actually reduce operation costs, or increase reliability.
-- Christian Huitema