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.dillon@xxxxxx 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@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf