Le 29 sept. 2011 à 14:00, Ole Troan a écrit : > 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.
Could you document more why you think that DAD/ND would fail if IPv6 addresses used to reach 4rd CEs would have a 4rd-distinguishable IID? > that's why I think the recommendation should be to use one /64 of the > delegated prefix to the translation "pool". This would defeat one important objective: possible operation without ANY impact of IPv4 on IPv6 prefixes delegated to CEs. As such, this would be AFAIK a step backward. RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
