Ran,
I agree with all the points you made.
I add that if all NAT66s, including that of Margaret (MW-NAT66 for
short), work for packets that have no other extension header than
fragmentation and transport, this will not prevent more extension
headers for connections that are not NATted.
The fact that MW-NAT66 doesn't work for longer prefixes than /48, and
with /48 forbids to use 0xFFFF as subnet ID, are real weaknesses which
are readily avoided if next headers are looked at.
Regards,
RD
RJ Atkinson - le (m/j/a) 4/3/09 6:12 PM:
On 3 Apr 2009, at 10:47, Margaret Wasserman wrote:
How do these mechanisms work with randomly generated privacy IIDs?
They work without any modifications or any special handling
being required.
(NOTA BENE: Margaret has not raised checksum recalculation
performance as an issue, but other folks have done so. It
is on topic for this note, so I'll discuss it here. :-)
Widely deployed very-lost-cost residential/small-office gateways
that perform NAT re-calculate the UDP/TCP checksums today
without any user-visible performance issues.
In fact, recalculating the Fletcher checksum (used by UDP/TCP)
is very easy to do purely in software on an ordinary very-low-cost
CPU.
So there are existence proofs that performance would be a
non-issue for the kinds of sites that are likely to be given
relatively longer IPv6 routing prefixes.
In IPv6, we have the added issue of _finding_ the TCP/UDP checksum.
There may be extension headers in the way,
In practice, I do not think extension headers are a real issue here.
A) MEASUREMENTS
First, I've done some measurements. MUCH MUCH less than 1% of
IPv6 traffic in real enterprise deployments contain ANY
optional header.
Virtually all of the packets that have any optional header
today only have either AH and/or ESP. In a NAT66 deployment,
such packets will be UDP-encapsulated anyway (as described
in my previous note), so aren't an issue.
B) CASE ANALYSIS
Separately, lets try a case analysis. Existing IPv6 optional
headers (according to IANA), other than ESP/AH, include:
1) Routing Header
There is limited use of these headers. I could not find any
use in measurements of real deployments. Type 0 Routing
Headers are deprecated. Type 1 were for NIMROD and have
no deployment. Type 2 are for Mobile IP, have a fixed
size, and hence are easy to parse past.
2) Hop-by-Hop Header
Other than the NULL option, which isn't seen alone, the only
deployment is of the IPv6 Router Alert option, and the only
proposal I've seen is draft-stjohns-sipso, which is ONLY deployed
in closed environments that will NEVER have any IPv6 NAT box
(that I-D has text explaining why "NEVER" is the right word).
Because of the TLV syntax of the Hop-by-Hop Header, it is also
trivially easy to parse past these even on a tiny/cheap CPU,
even for unrecognised sub-options carried inside the HbH header.
Further, the IPv6/6MAN WG is quite sceptical about specifying
any new Hop-by-Hop options, so no additional options in this
class are likely to be created.
3) Destination Options Header
Other than the NULL option, which isn't seen alone, there is a
Mobile IPv6 "Home Address Option". "Quick Start" is an experimental
sub-option for certain Transport protocol experiments; it has
nearly zero implementation or deployment. There is a Generic
Packet Tunneling "Tunnel Encapsulation Limit" option, which has
limited implementation and limited deployment. There is a Jumbo
Payload Length option. This probably has more implementations,
and some use (e.g. in super-computing environments), but I did not
encounter it even on Ethernets where 9K frames were configured/deployed.
As with the Hop-by-Hop Header, the TLV syntax of the overall
Destination Options Header makes it trivially easy to parse
past even on a tiny/cheap CPU, even for unrecognised sub-options
that might be carried inside the Dest Opts Header.
4) Fragmentation Header
This is the only case to consider more closely. A NAT66 box
would need to know how to find the TCP/UDP checksum inside
a *first* Fragmentation Header only. There are strict rules
both on IPv6 header order (generally) and for IPv6 fragmentation
(specifically). Supporting this case would not be a lot of
code in the NAT66 box.
5) Endpoint Identifier
This codepoint was allocated to Charles Lynn (BBN). I believe
this was intended for use with NIMROD experiments. I do not
believe that any deployments of this exist anywhere today.
(Corrections on this understanding would be welcome. :-)
and we would need to make
sure that a NAT66 device can handle arbitrary extension headers.
The IPv6 community's plan has been (and still seems to be) that
additional "extension headers" would not exist, but instead that
any additional IPv6 "options" would be placed either inside the
"Hop-by-Hop Header" or the "Destination Options Header".
Otherwise, we are effectively eliminating our ability
to add new IPv6 extension headers in the future.
I do not think we are.
Over time, IPv4 NAT devices have been updated to support various
extensions to TCP/UDP over IPv4 deployments, so there is good reason
to believe that NAT66 devices also could be enhanced over time.
In the case of the residential/SOHO implementation of NAT66,
a purely software implementation is likely to be common. Various
software loads, including some 3rd party software loads, exist
for at least some of the existing very-low-cost IPv4 NAT devices
(e.g. Linksys boxen).
Separately, what kind of IP option could one imagine that has
neither a "hop-by-hop" nature nor an "end-to-end" nature ?
(Anything that has either of those natures will fit *inside*
the existing HbH Header or Dest Opts Header, and would traverse
a NAT66 device without any code changes at all, so could be
added at will without any concern about whether one's NAT66
box were upgraded or not.)
Yours,
Ran
[email protected]
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
