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

[Rémi Després <[e-mail]>]

Le 29 sept. 2011 à 02:10, Ole Troan a écrit :

>>> 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). 
>> While, generally to be compatible with double translation, the 4rd IID can be employed.
>> 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.
> 
> I would be tempted to suggest that we write a "an implementation MUST NOT make this assumption" in the MAP draft.
> and that we in IETF documents write this as if there is a prefix reserved for address mapping.

No need for that AFAIK (see below).

> in the general case there is no way to guarantee that a host doesn't pick the same IID.

Well, "no guarantee"...  unless a safe way of doing it is specified!
And this is already the case with 4rd-addmapping-01.
(If you would keep doubts after a careful check, please share your understanding.)
 
The modified format discussed in Beijing with Xing Li, Congxiao Bao, and Wojciech Dec, to be documented soon, will have the same property.


> and we'll have to specify how this would work with DAD and proxy ND. I'd rather not.

> left up to the implementor is my suggestion...

No need for that (see above).

Cheers,
RD