Margaret,
Better late than never, comments below.
Regards,
RD
Margaret Wasserman - le (m/j/a) 9/14/31 11:59 AM:
Hi Remi,
I ran some numbers this morning, and you are right.
If the _original_ value of the 16-bit checksum correction field is
0x0000, it will be restored to 0xFFFF, which is wrong. The checksum
correction works fine (as Fred's tests have proven), but the
restoration of the value doesn't work properly. It can be made to
work properly for either 0x0000 or 0xFFFF, but I haven' t figured out
a way to make it work right for both values as the information to
distinguish between them is lost.
There are three approaches we can take to fix this
1) As you have proposed, we could changing NAT66 so that it modifies
the transport header checksum.
This would involve every NAT66 box knowing how to traverse the IPv6
extension header chain,
Yes, but IMHO this is not very complex, even in limit cases, and very
fast in typical cases.
and might effectively limit IPv6 NAT to transporting ICMPv6, TCP and
UDP-based protocols, because we wouldn't know how to correct the
checksum in other protocols.
Could you explain?
I don't see this limit:
- If there is no transport, then no checksum adjustment is not needed.
- For other transport protocols than TCP and UDP, the problem seems to
be the same with your proposal (it assumes one's complement checksum in
the transport protocol.)
2) The NAT66 device can store one-bit-per-host of state for any host
that has 0xFFFF or 0x0000 in the field that is used for the checksum
correction.
Finding the tra&nsport next header seems simpler, and in any case
stateless, which is important for scalability.
Although we would be required to implement this, we could explain to
network administrators how to avoid it, at least in the case where the
bits used for checksum correction are the subnet bits.
IMHO, a terrible perspective, to be avoided by all means.
I'm not sure if this would be better or worse than updating the
transport layer checksum, though, as it would result in inferior
service for a small set of hosts, but would provide better service to
most hosts.
2) We can do the checksum correction in a 16-bit field that we _know_
will never contain one of the two one's complement 0 values (0x0000 or
0xFFFF). There are two different cases here, but I think there are
choices for both that would work:
I don't see this working. The problem seems more an intrinsic
characteristic of One's complement, but looking at detailed cases could
be necessary to reach a common understanding.
2a) For the case of /48 or shorter prefixes, we could still do the
checksum correction in the lowest order 16 subnet bits and document
that subnet values containing 0xFFFF in their lowest order 16 bits
should not be used with NAT66. This has the advantage of retaining
the IID value unchanged, but might result in some misconfigurations
and support calls.
Same concern.
2b) For longer prefixes, we could perform the checksum correction in
the highest order 16 bits of the IID.
I've looked into this in the IEEE specs, and we should never have an
IID with both the "g" bit and the "u" bit set.
True for full 64 bit IIDs, but subnet prefixes longer than /64 are
already considered for some cases. They should not be made impossible
just because a one's complement problem has not been solved as it
should, i.e. without interfering with IPv6 address formats.
The "g" (individual/group) bit should always be '0' in EUI 64s that
are assigned to specific interfaces (a "1" indicates that this is a
"group" address, similar to an Ethernet multicast address), and if a
host uses an IID that was generated some other way, it is expected to
clear the "u" bit to indicate that the value isn't a universally
scoped EUI-64. So, we should be able to safely assume that the first
2 bits of an IID will never be "11". Therefore, the first 16 bits can
never contain 0xFFFF. The issues here is that we would end-up
generating IIDs that have the "universal" bit set that are not
universally scoped. I am not sure how big of an issue that is, as we
don't have any documents that use the fact that a universally scoped
IID contains an EUI-64, at least not to my knowledge.
Thoughts?
See above.
Margaret
On Nov 26, 2008, at 4:39 AM, Rémi Després wrote:
Fred Baker (1-12/1-31/200x) 11/24/08 10:23 PM:
Not sure I buy that. In UDP and TCP, the value stored in the header
is set of 0xFFFF if the sum adds to 0x0000, but I don't see any
reason that has to be the case in the modification of the IP address.
No reason, you are right, but the point I was making is different.
It concerns the 16 bits in which the prefix checksum difference is
subtracted, in outgoing packets, when these 16 bits happen to be 0000
(i.e. +0 in one's complement). After the subtraction, which in
general gives a non-zero result, it will no longer be possible to
determine whether the original value was -0 or +0.
If the checksum difference to be subtracted from 0000 is for example
0001, the result is FFFE (i.e. - 1).
When trying to reverse the mapping, adding 0001 to FFFE gives FFFF
(i.e. -0), while the original value in the outbound packet was 0000
(i.e. +0) :-(.
I'll let you look at the code I put up to test this if you like. You
can tell me what I missed.
ftp://ftpeng.cisco.com/fred/gse/checksum.c
What had been missed is not in the code, which seems perfectly fine,
but in the specification.
Regards,
RD
On Nov 25, 2008, at 10:15 AM, Rémi Després wrote:
Margaret, Fred,
In section 5.1 of your draft, you propose a technique for
Checksum-Neutral Mapping.
Due to the two ways to represent 0 in one's complement, it doesn't
work in all cases:
In 16 bits, +0 is 0x0000 and -0 is 0xFFFF.
If the field which is modified contains -0 or +0, adding to it, or
subtracting from it, any non zero value wipes out the difference
between the two zeros.
For example, in one's complement:
. 0x0000 - 0x0001 = 0xFFFE
. 0xFFFF - 0x0001 = 0xFFFE
I therefore believe that it is unavoidable to modify the UDP or TCP
checksum if we want a reversible mapping between a local and a
global address (which I believe is a good approach to avoid
classical NATs in IPv6). This modification can be done
incrementally. Finding the UDP/TCP header may require in IPv6 to
parse a few headers, but this seems quite acceptable.
Regards,
RD
_______________________________________________
Behave mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
