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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
