Jacni, >> 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. >> in the general case there is no way to guarantee that a host doesn't pick >> the same IID. 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... > Taking the EUI-64 into account, a careful design of the 4rd IID can make the > probability of conflicts quite low. Then as you mentioned, DAD would further > reduce it. > Anyway, that's not to say I'm in favor of this design, the reason I see, of > doing this is just to accommodate the double translation while not affect at > all the IPv6 addressing (a reserved prefix? no ...).
the DAD/ND redirect solution would fail in the routed home case. i.e. the case where there is multiple levels of routers in the network. that's why I think the recommendation should be to use one /64 of the delegated prefix to the translation "pool". cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
