Subject: Re: [BEHAVE] Non reversibility of address mappings in the "NAT66" draft

From: Rémi Després <[email-masked]>
Date: Wed, 25 Mar 2009 10:31:22 -0700

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-masked]
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>
>>
>
>
>