Remi, >>>> 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?
this is the translation case for a routed home. DAD/ND wouldn't be done on any of the links the dIVI CE was connected to. for 4rd this isn't a problem since the packets are destined to the 4rd CE. the dIVI CE has to intercept packets not destined for itself. in that case it would make sense to reserve a prefix for that purpose. same as the 4rd CE address comes out of a /64 used for numbering internal interfaces on the CE. >> 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. I don't see that? I thought this discussion started out with the case where IPv6 hosts were sharing the same prefix as is used for translated addresses. I'm pointing out that this isn't a good idea. and I don't see why we need to describe that case in any of our documents. cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
