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