Re: [Softwires] MAP Open issues: Interface-id

[Ole Troan <[e-mail]>]

>>>> 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.

> => 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.

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...

cheers,
Ole