Hi Ole, Qi beat me to it!
The option’s already defined in the DHCPv4overDHCPv6 draft. What we need to do here is to ensure that the Unified mechanism covers this as well. As for a complete picture (well a thumbnail sketch): ------------------ DHCPv6 (OPTION_S46_XX) provisions softwire IPv4 basic config only. Separate container options for MAP-E, MAP-T & lw4o6. These are: OPTION_S46_CONT_MAPE, OPTION_S46_CONT_MAPE, OPTION_S46_CONT_LW. DHCPv4overDHCPv6 does dynamic IPv4 leasing plus any other DHCPv4 options - it needs extending to deal with shared addressing, but work on this is a little stalled waiting for the outcome of the ‘how to provision DHCPv4 in v6 only networks?’ discussion in DHC. A DHCPv6 flag indicates support by the client and, if returned, indicates that the client attempts v4 configuration using normal IPv4 DHCPDISCOVER. This is option is called OPTION_DHCP4_O_DHCP6_ENABLE. PCP (this is not my area, so this is speculation about how I think it might work) - this would be similar to DHCPv4oDHCPv6 - I.e. Capability and configuration indicated by a DHCPv6 option. Not defined, but let’s call this: OPTION_S46_PCP_ENABLE. To roll this together (I.e. The basis for a unified CPE), is that a ‘priorities’ sub-option gets added to the options defined above. This allow an operator to signal to a device which one he would prefer them to use without having a load of server side logic saying ‘if you support these then provision that etc.’. A client signals everything it can do with the ORO and the server replies with a priority. The client configures it’s softwire with using the config mechanism received with the highest priority. Another point that hasn’t been discussed is how this would all work with DS-Lite. My suggestion here is that DS-lite has an implicit priority in the middle of the priority range. This way you can prioritise it or de-prioritise it and there doesn’t need to be any changes to existing DS-Lite implementations. One additional point: A client using DHCPv6 for softwire IPv4 config could use DHCPINFORM over DHCPv4overDHCPv6 to get additional v4 options. We could possibly use a DHCPv6 flag to turn this on (as above, but only for DHCPINFORM) - this hasn’t been discussed so far. How this sits in with the prioritisation would need to be worked through (possibly make it only allowable in use with the OPTION_S46_CONT_XXX option)s. ————————— That’s how I see it all working, today at least:-) Cheers, Ian On 15/11/2013 13:57, "Ole Troan" <[email protected]> wrote: >Ian, > >confused, so please bear with me. > >I thought the OPTION_SW_CONT_LW46 was going to be used to provision the >softwire, >regardless of how IPv4 was provisioned on top of it. >you seem to indicate below, that is not the case? >if so, there would be no reason to make OPTION_S46_IPV4ADDRESS optional. > >how would you then provision the softwires? >I think we need a complete picture to ensure we have the right thing in >MAP DHCP. > >cheers, >Ole > > >On 15 Nov 2013, at 13:23 , <[email protected]> ><[email protected]> wrote: > >> Hi Ole, >> >> >>> >>> if optional, we have to think through the corner cases: >>> - how does a CPE know when to initiate DHCPv4 (or PCP)? >> >> [ian] Unified CPE is scoped to solve this. >> >>> - can a CPE end up with an IPv4 address provisioned both with >>> OPTION_S46_IPV4ADDRESS >>> and DHCPv4 (and PCP)? >> >> [ian] Again, unified CPE describes how to deal with this, if it¹s >>possible >> to happen. >> >>> - what does the CPE do with IPv4 addresses with longer lifetimes than >>> the softwire? >> >> [ian] lw4o6 states that if the v6 prefix changes, it re-runs whatever v4 >> provisioning, so it would be up to the v4 config server to decide if the >> same or new parameters were given out. >>> >>> I'm sure there are more. >>> keeping choice down makes for a simpler solution. >> >> [ian] the problem that we have here is that we¹re trying to solve hybrid >> provisioning cases: If I get this parameter from DHCPv4 and this from >> DHCPv6, then how do I deal with it? >> >> The simple answer here is to say: don¹t do hybrid provisioning. If >> option_s46_xx provides all the v4 conf you need, need, then use it. If >>it >> doesn¹t, then use DHCPv4overDHCPv6. >> >> Thinking further about Simon¹s original question, which sparked this >> discussion: if you¹re implementing the OPTION_SW_CONT_LW46, then you >>have >> to implement all of the sub-options that it needs including the >> OPTION_S46_IPV4ADDRESS. Then it¹s a self-contained softwire provisioning >> mechanism in it¹s own right. >> >> Likewise, DHCPv4o6 and PCP need to provide self-contained softwire >> provisioning mechanisms in their own right. DHCPv6 may be used to switch >> them on, but all of the actual parameters that are necessary for >> provisioning the softwire come through DHCPv4o6 or PCP. >> >> If we go down this road, then adding the previously suggested priority >> field as a sub option into OPTION_S46_XX, >> OPTION_S46_DHCPV4OVERV6_ACTIVATE(?) and OPTION_S46_PCP_ACTIVATE(?) gives >> both the CPE a way of indicating what it can do, and for the operator to >> indicate what they would prefer without having to consider all 'Possible >> Parameters' x Œavailable configuration protocols¹. >> >> Cheers, >> Ian >> >> >> >> >> >> >> >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
