Le 8 nov. 2011 à 10:17, Ole Troan a écrit :
>>>>> 1. Checksum neutrality being an open question, it is relevant here.
>>>>> 2. It is useful AFAIK to distinguish CE addresses from BR addresses.
>>>>>
>>>>> The best proposal I know so far is as follows (with CNP = Checksum
>>>>> neutrality preserver)
>>>>>
>>>>> CE ADDRESS
>>>>>
>>>>> <- - - - - - IPv6 Unformatted address (104 bits) - - - ->
>>>>> +-------------------+----------+----------+---------------+
>>>>> | Rule IPv6 prefix |IPv4 suff.| Max PSID | Padding = 0 |
>>>>> +-------------------+----------+----------+---------------+
>>>>> :
>>>>> :<- - - - - - - - - 64 - - - - - >:<- - - - 40 - - - - ->:
>>>>> : :\ \
>>>>> : <8> :<- 16 ->
>>>>> : : : : :
>>>>> +----------------------------------'-'----------------------+--------+
>>>>> | IPv6 unformatted address (part 1)|V| | CNP |
>>>>>
>>>>> +----------------------------------+-+----------------------+--------+
>>>>> <- - - - - - - - - - - IPv6 address (108 bits) - - - - - - - - - - >
>>>>>
>>>>>
>>>>>
>>>>> BR ADDRESS
>>>>>
>>>>> +------------------------------------+-+-----------------+-+-------+
>>>>> | BR IPv6 prefix |V| IPv4 address |0| CNP |
>>>>> +------------------------------------+-+-----------------+-+-------+
>>>>> < - - - - - - - - - 64 - - - - - - ><8><- - - 32 - - -><8>< 16 >
>>>>>
>>>>
>>>> +1
>>>> The checksum neutrality is desirable for translation case.
>>>> I suggest to take above format into consideration
>>>
>>> the consequence of that is that the destination IPv6 address will change
>>> for every flow.
>>
>> If a source ignores the destination PSID length, yes, IPv6 addresses of two
>> flows going to the same CE may differ.
>> But so what?
>> - The IPv4 packet submitted to the CE NAT is the same as the source IPv4
>> packet
>> - The final destinations behind the NAT may differ too
>>
>>
>>> the MAP node cannot any longer listen to a single IPv6 address for MAP
>>> traffic, but has to intercept packets for a whole prefix.
>>
>> - BR's of double translation have always had this property.
>> - Talking with Mark townsley, I got the understanding that this wasn't a
>> real problem, at least with IOS.
>
> everything can be _implemented_, that's not the point.
The point you made in the past against this capability was that it was
difficult, if not even impossible, with the _current_ IOS.
If it is easy, we can focus the discussion on functional considerations (see
below).
>> => Clarifying this point would IMHO be useful.
>
> it is clearly requiring bigger changes to tunnel code. which unlike NAT code
> is attached to 'one' endpoint.
> it makes co-existence of a MAP endpoint and native IPv6 nodes within a single
> /64 much harder.
Hopefully, there will be implementers in Taipei to clarify this subject.
Still in serious doubt about "big changes".
> let us turn this around. what's the point in embedding a new set of CNP bits
> in the IPv6 address, when the L4 checksum can be incrementally updated.
> that's what everyone has existing code to do already...
Before answering this (good) question, let's make clear that the code to add or
subtract a few 16-bit fields is always trivial. This doesn't depend on whether
it applies to a field in the IP payload or in an IPv6 address.
Now, the difference, already explained in the context of 4rd-U, is between a
Reversible Header Mapping (nothing done to the IP payload), and a translation
that involves transport-layer considerations (checksum adjustment for specific
transport protocols):
IPv4 packet Reversible Header mapping IPv6 packet
+-----------------+ _ _ +-----------------+
| IPv4 Header | _| <----> | | IPv6 Header |
+-----------------+ | +-----------------+
| IP Data | |_ |IPv6 Frag. Header|
+-----------------+ +-----------------+
| IP Data |
+-----------------+
Translation per RFC 6145
+-----------------+ _ _ +-----------------+
| IPv4 Header | _| ----> | | IPv6 Header |
+-----------------+ _ | +-----------------+
|Transport Header | _| -. |_ |IPv6 Frag. Header| (if needed)
+-----------------+ \ _ +-----------------+
| Transport Data | '-> |_ |Transport Header | (adjusted checksum
+-----------------+ +-----------------+ if needed)
| Transport Data |
+-----------------+
(not transparent to IPv4 DF bit)
Cheers,
RD
>
> cheers,
> Ole
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
