Ian, > Currently, OPTION_S46_BR is limited to only be a sub-option carried within > one of the S46 container options (described in section 3). However, other > softwire provisioning mechanisms also need this configuration parameter, for > example if you’re using DHCPv4 over DHCPv6. > > To re-use this parameter for DHCPv4o6 as it stands within the container would > be very messy: A client needs to indicate its support for OPTION_S46_CONT_LW > and DHCPv4o6 in the ORO, it then gets the parameter from one end of the > softwire from DHCPv6 and the other end of the softwire using DHCPv4o6.
is the complete flow and options of how LW46 is provisioned with DHCPv4 described anywhere? half and half with DHCPv6 options and DHCPv4 options? > Two solutions spring to mind: > > 1, Loosen the restriction in this draft so that OPTION_S46_BR can be used > outside of one of the S46 Containers. This would then allow the possibility > of the client including the option within an ORO option in the > DHCPV4-QUERY/RESPONSE messages in the DHCPv4o6 message flow. > 2, Keep the restriction in the map-dhcp draft and create a new option for > provisioning the BR specifically for softwire clients using DHCPv4o6. > > The outcome of this may also have a knock on effect of what’s going to be > possible if we ever resurrect the unified-cpe work. if you need the OPTION_S46_BR option in particular, perhaps something else as well? I think the cleanest would be to specify a new container option for this "mode". cheers, Ole
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
