On 1 Jan 2009, William Herrin wrote:
It is not immediately obvious to me how any form of NAT66 reduces
the demand for core routing slots. If it's obvious to you, I'm
listening.
draft-mrw-behave-nat66-01.txt
NAT66 is one example of an Architected NAT. Kindly note that
NAT66 still seems to be a work in progress, and hence might change,
although it seems very well written to me at present.
One can imagine other instances of an Architected NAT that might make
different design decisions and might target either IPv4 or both
IPv4 and IPv6. (NAT66 is an IPv6-specific approach.) [See also
other comments later in this note.]
(Depending upon perspective, some might consider SHIM6
another example of an "Architected NAT", albeit one where
the NAT function occurs inside the end system.)
Some other RG folks have suggested that NAT is a viable approach
for the group to consider:
<http://www.irtf.org/pipermail/rrg/2008-October/000009.html>
<http://www.irtf.org/pipermail/rrg/2008-October/000075.html>
<http://www.irtf.org/pipermail/rrg/2008-December/000614.html>
Of the last URL's concerns, NAT66 appears not to have the issues
mentioned with "N:1 multiplexing" or the issues of "session
survivability in the case of uplink failover", at least in some
modes of operation. (NAT66 defines several options.)
Also, as noted earlier today by Brian Carpenter:
http://www.cs.auckland.ac.nz/~brian/RRG0708.pdf
Link please?
draft-rja-ilnp-intro-02.txt contains a number of references.
Separately, also today, Scott Brim commented:
% If an endpoint appears to have two different addresses due to
% being NATted onto two different providers, and routing changes
% so that packets switch from flowing through one provider to
% flowing through the other one, connections break.
In an old IPv4 NAT, particularly those in low-cost consumer
devices, the above is commonly true.
With NAT66, if both sites are using NAT66 and both are using
it in "Algorithmic Translation" (Section 5.1.1) mode, it is
not obvious that this issue [1] still exists. The transport-layer
state can use, for example, ULA addresses (which are NOT in the
DFZ RIB/FIB) and the algorithmic mapping means no NAT session state
is required either.
I'm neither particularly advocating NAT-based approaches,
nor am I particularly opposed to NAT-based approaches. I
would prefer that the RG examine all of the options, and
this sort of an approach seems to be a viable option.
Cheers,
Ran
[email protected]
[1] I.e. the issue created by using different addresses,
with different ISP-aggregatable routing prefixes, on
the wire between sites, for a single session.
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
