Hi Woj, I think that we need to have a pointer (see comments below). What about if the text read:
The solution described in this document is suitable for provisioning IPv4 addressing and other configuration necessary for solely for establishing softwire connectivity using DHCPv6. This means that the lifetime of the IPv4 configuration is bound to the lifetime of the DHCPv6 lease. If de-coupling of IPv4 and IPv6 lease times is required, then DHCPv4 over DHCPv6 [ietf-dhc-dhcpv4-over-dhcpv6] should be used, although extensions may be required to provision the necessary parameters for all softwire mechanisms. Additional DHCPv4 options are not transported natively in DHCPv6. If these are required for client provisioning, then DHCPINFORM transported in DHCPv4 over DHCPv6 should be used. Cheers Ian Hi Wocjeich, 2013/11/11 Wojciech Dec (wdec) <[email protected]<mailto:[email protected]>> >The solution described in this document is suitable for provisioning IPv4 >addressing and other configuration necessary for establishing softwire >connectivity using DHCPv6. This means that the lifetime of the IPv4 >configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E and >MAP-T, this is necessary due to the mapping between the IPv4 and the IPv6 >address. Lightweight 4over6 allows for the de-coupling of the IPv4 and >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 >[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing. It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind (SLAAC can also be used). [ian] But the draft only describes MAP provisioning related to stateful DHCP, so it doesn’t make any requirements for how it would work if it was stateless. I think this paragraph should be added. For your concern, I think the text can be modified to: "This means that the lifetime of the IPv4 configuration is bound to the lifetime of the IPv6 configuration." Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, but doesn't have to be bound the IPv6 configuration. [ian] The point here is that if you’re provisioning any softwire over DHCPv6, then they’re coupled. If you want to decouple, then it needs to be DHCPv4 over DHCPv6. We could always open up the proposed wording so that it is applicable to any softwire mechanism (I only put in the limitation at Ole’s behest). As I said before, I do not think that the above "explanatory" text is suitable for this specification. The essence is that if someone want to use DHCPv4 (for DHCPv4 options, or DHCPv4 leases) then they should use DHCPv4 over DHCPv6. [ian] The reason that I requested it is that Bernie and Tomeck don’t want the map-dhcp draft to become a basis that people will then try and extend with DHCPv4 options in the future.
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
