On 2008-02-15 22:06, Stjepan Gros wrote:
...
All that said, what happens when organizations would like to use multihoming?
In that case NATs create problems as flows have to use the same
exit/entry point, and when one of the connections breaks all the flows
going through the given connection will also be broken?
How is this problem solved in current IPv4 networks?
It isn't. That's one of the reasons why NAT causes undiagnosable
session disconnects.
On 2008-02-16 03:44, Paul Francis wrote:
I wonder if standard approaches to NAT for IPv6 just isn't going to be much
of an issue even if the IETF ignores it. Since NAT for IPv6 is much simpler
than for IPv4, a bunch of the issues associated with IPv4 NAT usage don't
exist. Like, there should be no need for port translation. No need to time
out mappings. For the most part, NAT for IPv6 should be just a simple
substitution of prefix A for prefix B. What, exactly, are the range of
choices that NAT vendors need to agree on?
Exactly. In other words the hardest issues that NATv4 hits simply don't arise in
IPv6, which I believe is isomorphic with the statement that NAT is logically
unnecessary in IPv6 (and that's why we wrote RFC 4864, to show how the
*perceived* benefits of NAT beyond address sharing can be provided
without NAT). Dan Wing is of course correct that this won't automatically
stop corporate IT folk asking for NAT.
On 2008-02-16 04:09, michael(_dot_)dillon(_at_)bt(_dot_)com wrote:
Vendors need to agree on the timeout for mappings
As Paul observed, no timeout is needed (as long as the
untranslated address remains valid).
and on the
method for substituting prefixes.
Since this is a local operation, why is there anything
to standardise?
Even if ignoring port translation
seems obvious, a vendor who is adapting/upgrading old code might
include this in the absence of a standard. Also, an IPv6 NAT could
include features that are not in v4 NAT such as using RFC 3041
algorithms to generate the Interface ID portion of the mapped
address rather than passing the ID through unchanged.
It could, but all that is pointless - the host itself can use RFC 3041
if it wants. Why invent work for an unnecesary box?
An often used example of how IPv6 is better than IPv4, talks about
how every device can have its own IPv6 address, so that just like
a telephone set, every device can be "called" by any other device.
But if you look into how the telephone system works, many telephone
sets are not available to receive calls. Instead, they are in
communication with a PABX which may or may not forward phone calls
to the phone set. Since an IPv6 NAT device fills an analogous gateway
role in the Internet, one wonders why there is no IPv6 NAT standard
to cover things like local hosts registering with the NAT to receive
packets on a certain port, or local hosts registering a forwarding
address for packets on a certain port.
Because that has nothing to do with NAT. Those functions, if you
want them, are firewall functions.
On 2008-02-16 11:49, Jonathan Rosenberg wrote:
...
So, I think it would be good to define IPv6 NAT behavior, and do so NOW
before its too late, and define it in a way that it would appeal to the
admins that have deployed IPv4 NAT today.
That's a terrible idea, because it would pander to the myths that
NAT is a security or policy tool. I think Paul Francis' comment
shows that there is almost nothing to define, and that if we
write anything, it should be absolutely minimal, and contain appropriate
MUSTs and MUST NOTs for all the things that should be done
differently in IPv6.
Worst case, it doesn't get
used and we have this nice utopian NAT-free IPv6 network.
No, that's the best case. The worst case is that it encourages vendors
to implement it and corporate IT folk to deploy it.
Can you say
the same for the worst-case situation for NOT standardizing v6 NAT?
That's a very hard question to answer, because it depends very much
on how CPE and firewall vendors react in their product plans. Since they
all know that NAT isn't needed for IPv6, and product managers are not
known for funding unnecessary work, in the best case, it doesn't get
implemented. In the worst case, it gets implemented randomly.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf