On Apr 3, 2009, at 09:12, RJ Atkinson wrote:
On 3 Apr 2009, at 10:47, Margaret Wasserman wrote:
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.
In current practice, they are not a *huge* issue, but they are an issue.
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".
Consider the current status of draft-krishnan-ipv6-exthdr in the 6MAN
working group, which is that nobody wants to define a standard uniform
format for IPv6 extension headers. This draft keeps getting shot down
every time it's proposed as a working group item.
If the IPv6 community is planning that new extension headers are
required by IETF standards to conform to a uniform format, then 6MAN
should be persuaded to change its collective mind and put the standard
into writing. Otherwise, any NAT66 standard definition that requires
TCP/UDP checksum modification should be correctly viewed as implying
the need for a uniform extension header format standard which does not
now exist.
Separately, what kind of IP option could one imagine that has
neither a "hop-by-hop" nature nor an "end-to-end" nature ?
draft-woodyatt-ald tries very hard not to define an IP option that
only firewalls are expected to process. I have sometimes thought that
such an IP option would be a good idea. Whether the nature of such an
option can be regarded as a subtype of the hop-by-hop nature is a
debate I'd rather not have today.
(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.)
Yet, 6MAN has not seen fit to make such a promise to posterity
explicitly.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
