Hi Simon,
>> >> [ian] More than one prefix (of the same scope) is a pretty likely case > >What do you mean by "scope"? [ian] RFC4007 scope. > >> here. Behaviour does need to be defined, as if the wrong prefix is >> selected for the source v6 encapsulation address, then it¹s going to be >> discarded by the lwAFTR, for some provisioning methods at least.. >>Suggest >> that we update to make this clear. > >I'm not following you. If the CPE picks the "wrong" prefix, sets up its >tunnel interface, then sends packets on it, they will get discarded by >the lwAFTR. How does the CPE handle this? How does it figure out which >one is the "right" prefix? How do we go from "the Internet doesn't work" >to "the Internet works"? [ian] The current text describes how the CPE creates the /128 prefix to use as its tunnel endpoint (when its provisioned with DHCPv6). This prefix has been constructed using an existing /64 prefix and a suffix that has been learnt through the v4 configuration information in OPTION_S46_LW4o6. The CPE can’t try and build a tunnel until it has received all of these parameters, as it wouldn’t have a tunnel endpoint address for the lwAFTR either. So, it learns the parameters over DHCPv6, creates the tunnel source /128 based on these parameters and builds the tunnel from there. In all likelihood, there is also a SLAAC or IA_NA address on also that interface, but as the lw4o6 client is configuring the source prefix as well as building the tunnel, the right prefix is the one that its just configured. Is the current text not conveying this, or do you think that there’s something wrong with the method? Cheers, Ian _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
