On Mar 23, 2009, at 2:05 PM, Keith Moore wrote:
The application doesn't care about the exact number of the address.
However it might care that the same address work for all of its
peers,
or that if it opens multiple connections to a peer that they all
originate at the same address, or that each of its peers to which
it has
an open connection will see the same source address, etc.
OK. So what you told me was, perhaps, that hairpinning is a concern.
hairpinning is certainly necessary.
OK.
The implications of hairpinning are...
<aside>
For those of us who don't know what "hairpinning" is, the term derives
from telephony. There are cases where a call goes down a trunk to some
kind of translator or interchange, but instead of going across the
exchange point, it turns around and goes right back the way it came.
The same thing can happen in IP.
In this context, it would relate to a system inside a network using an
address appropriate to systems outside the network. The datagram goes
to the DMZ, but instead of crossing it and going out of house, it
turns around and goes back in.
</aside>
The simplest way to accomplish this in NAT66 will be for the DMZ to
hand it upstream to its ISP. In doing so, it converts the source
address to the DMZ's prefix. The ISP PE router turns it around and
sends it back, resulting in the translation of the destination
address. The target system's reply goes through a similar route.
The more appropriate case, called for in RFC 4787, might be to
recognize that this is about to happen and instead of changing the
source address, change the destination address. This results in the
target seeing a datagram from/to the ULA. One direction goes through
the DMZ, but the replies are direct.
IMHO, an even more appropriate solution would be to drop the datagram
and reply "Destination Unreachable", to cause the originating host to
do a better job of address selection. If the system has both an
internal and an external address, I don't see the argument for not
expecting the peer to use the appropriate one.
The draft states that hairpinning is required, but doesn't go into how
it is done.
NAT66 devices MUST support hairpinning behavior, as defined in the
NAT Behavioral Requirements for UDP document [RFC4787]. This means
that when a NAT66 device receives a packet on the internal interface
that has a destination address that matches the site's external
prefix, it will translate the packet and forward it internally.
This
allows internal nodes to reach other internal nodes using their
external, global addresses when necessary.
o Added hairpining requirement and discussion of applicability of
other NAT behavioral requirements.
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
