Noel Chiappa wrote:
> From: Keith Moore <moore(_at_)network-heretics(_dot_)com>
>>> these limitations don't inherently apply to NAT between v4 and v6,
>> I thought the inherent problems ... would apply to an IPv4-IPv6 NAT,
>> when such a device is used to allow a group of hosts with only IPv6
>> addresses to communicate with IPv4-only machines. What am I missing?
> one of the worst assumptions in v4 NAT design was the assumption that
> the endpoints don't need to know about the NATs. By now it should be
> obvious that for a great many reasons, they do. For example, they
> clearly need to know about the address binding across the NAT
> ...
> For similar reasons you can make the management of the address:port
> binding an explicit agreement between the host or app and the NAT.
> ...
> Explicit management of address bindings goes a long way toward getting
> rid of the fragility due to address bindings in the NAT.
Ah, got it. I hadn't realized this was what you meant by "NAT between v4 and
v6", because to me these are the kind of things that (in IPv4) were being
explored by the middle-box (MidCom) WG, so I think of them as 'middle box
functionality', not 'NAT' (since to me, part of what NAT means is that 'you
don't have to modify the hosts').
But clearly, this assumption wasn't true even for v4 NAT, because hosts
are shipping with support for UPnP and similar hacks to (minimally) deal
with it, and apps are using significant amounts of code and
infrastructure to deal with it.
> The cost of this is that you need an established relationship between a
> host and its v4/v6 NAT
Not just that, but to make this really useful, you'd have to add this 'NAT
interaction' stuff to the core IPv6 spec, get it added to all IPv6
implementations, and then get it deployed to all existing IPv6-capable boxes.
Actually, no.
You do have to have a spec for it, of course, but there is no reason to
add it to the core IP spec. And IMHO it would be a bad idea for reasons
unrelated to the overhead of doing so. The NATs and their support
should still be thought of as a stopgap measure.
You don't need to add it to all (or most) IPv6 implementations. (Not
that this is terribly difficult in these days where updates regularly
get downloaded over the net.) If the hacks needed to allow apps to deal
with NATs are designed with this in mind, they can be implemented in
separate libraries - even in shared libraries/DLLs that get associated
with applications as needed.
The goal (in my mind) is not to magically make all boxes and apps
suddenly be able to communicate with both IPv4-only and IPv6-only hosts
as if there were no difference between the two. It is merely to provide
a standard way to allow a network operator OR an application vendor, by
providing such a NAT, to allow v4/v6-NAT aware apps on that network to
bridge the gap.
(note that - because it has an explicit relationship with the apps and
hosts that use it - such a v4/v6 NAT can live anywhere on the network
where it has access to both public v4 and v6 networks. so an enterprise
network operator could provide it for use on that enterprise network, or
an application vendor could provide it for use by its products, or a
third-party could sell the service to anyone who needed to give a
v4-only app presence on the public v6 network or similarly for v6-only
apps and v4.)
And it doesn't have to be applied to every app on every host. For many
apps, only one end of the app (say the server of a client-server pair)
has to be aware of the hack. The other end can just use whatever native
IP access is available to it.
And the apps don't always have to be directly aware of the hack. For
some apps you can arrange them to be associated with a shared
library/DLL that is aware of the hack. They won't see the correct IP
addresses but for some apps you can live with this. (But it's important
to not universally impose the hack on all hosts or apps.)
Leaving aside the engineering/logistical difficulties involved in doing all
that, it seems to me that this would basically amount to formally 'adding NAT
to IPv6', which is a claim made in the story which some people were saying
was inaccurate. The fact that it's not necesarily used in v6/v6 interactions
is an awfully fine hair to split, to claim that 'well, we're not actually
adding NAT to IPv6'. If it's in the core spec, it's in IPv6.
But there's no need for it to be part of the core spec.
(And that v6/v6 exemption might not stand, if people deal with v6's inability
to give them provider independence, due to its retention of the obsoleteq
IPv4 single-namespace architecture, by using v6-v6 NATs to give them provider
independece - which is a big driver for v4-v4 NATs, I gather.)
That's a huge topic, way too big for a reply to an email message on the
IETF list. But even though that is one of the drivers for v4 NATs, I
don't think v6 will end up the same way. Enterprise network management
will continue to evolve and they'll see the benefits of using v6. And
while I admit that some kind of network address translation combined
with ULIAs might end up playing a role here, I don't think it will look
like the role played by IPv4 NAT today. (actually I think that if you
do NAT properly, it starts to look more and more like tunneling, because
one of the things the NAT really needs to do is communicate the "real"
remote endpoint address of the peer to the host behind the NAT)
Anyway, it seems like the story is more accurate than many people realized...
Either this functionality is added to the IPv6 core spec, or the IPv6/v4 NAT
boxes (which many people now seem to feel are required for a viable
deployment plan) will display the same crippling problems as v4/v4 NAT...
No, because (a) you're not trying to impose this on all hosts or apps,
but rather use them in specific apps on a case-by-case basis, (b) you
provide from the start a way for apps to be aware of these hacks, and
(c) you engineer these boxes from day one in such a way as to avoid the
crippling problems we've experience in v4 NAT.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf