Re: [Softwires] 4rd Address Mapping - version-01

Hi Tetsuya-san  and Jacni,

Please see inline.

Le 28 sept. 2011 à 15:14, Jacni Qin a écrit :

> hi Tetsuya,
> 
> Inline please,
> 
> On 9/28/2011 1:36 PM, Tetsuya Murakami wrote:
>> 
>> Hi Remi,
>> 
>> I have one question about your new address mapping draft.
>> 
>> In the draft, you mentioned the special IID can be used for distinguishing 4rd packets from other IPv6 packet whose destination start with CE IPv6 prefixes.
>> 
>> But I think it is difficult to distribute the IPv6 prefix matching to the assigned Domain IPv6 prefix. Here is one example.
>> 
>> CE IPv6 Prefix:
>> +----------------------------+------------------+
>> | Domain IPv6 Prefix (36bit) | CE index (20bit) |
>> +----------------------------+------------------+
>> 
>> Domain IPv4 Prefix:
>> +--------------+
>> |   16 bits    |
>> +--------------+
>> 
>> In this case, the first 16bits of CE index can be embedded in the last 16bits of IPv4 address followed by Domain IPv4 prefix. And then the remaining 4bits of CE index can be embedded as PSID followed by 4bit port head.
>> 
>> At the BR, BR can generate the destination IPv6 address from the IPv4 destination and the destination port number as shown below.
>> 
>> <---------------------------------- 64bit --------------------------------------->
>> +----------------------------+--------------------------------+------------------+
>> | Domain IPv6 Prefix (36bit) | suffix of IPv4 address (16bit) | MAX PSID (12bit) |
>> +----------------------------+--------------------------------+------------------+
>> <---------------- CE IPv6 Prefix (56bit)--------------------------->
>> 
>> PSID can be derived from the port number after removing the first 4bit even though the length of the actual PSID is only 4bit.
> The last 8 bits can be just ignored, but the first 56 bits are still unique and enough for routing.
> 
>> In this case, CPE should terminate the packet whose IPv6 destination is matched to CE IPv6 Prefix and then process the decapsulation for 4rd. So, I think this means that any IPv6 prefix matching to CE IPv6 Prefix can be terminated at 4rd functionality in CE.
> If only talking about encapsulation approach, the CE can check the next header to see whether the packet is for 4rd (of course, the tunneling by hosts in LAN may not be allowed in this case).

Same understanding.
Thanks Jacni.

> While, generally to be compatible with double translation, the 4rd IID can be employed.

Actually, having a recognizable format for 4rd addresses makes it possible for hosts behind a 4rd CE to use any other IPv4-in-IPv6 encapsulation that 4rd without their packets being (inappropriately) processed as 4rd packets by the CE.

With a 4rd-recognizable IID, there is a guarantee that 4rd will never interfere with any non-4rd protocol.  

OK?

Thats AFAIK an important feature.
I remember a discussion with Wojciech about this, which maybe he could confirm.

RD

> That is, after receiving an packet, the CE will check whether the IPv6 destination address matches its delegated prefix, and a 4rd IID exists. if so, the packet will be processed by 4rd functionality. Otherwise, the packet will be routed natively to some host attached in LAN.
> 
>> For this, even though CE IPv6 Prefix can be delegated to the CE, CE can not delegate any IPv6 prefixes matching to CE IPv6 Prefix to any hosts connected on the LAN side of the CE. Usually, if the CE can get an IPv6 prefix whose length is 56bit, CE can delegate an IPv6 prefix having the different prefix length (i.e. 64bit) to the hosts locating on the LAN side of the CE. But I don't think it can be working because the IPv6 destination matching to CE IPv6 prefix (delegated prefix) should be terminated at CPE for 4rd processing. So, in order to provide Dual-stack for the hosts locating on the LAN side of the CE, an additional IPv6 prefix different from CE IPv6 Prefix needs to be delegated.
> Please see my comments above, the 4rd and IPv6 services can share the same delegated IPv6 prefix.
> 
> 
> Cheers,
> Jacni
> 
>> 
>> Is my understand correct?
>> 
>> Thanks,
>> Tetsuya Murakami
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires