Hi Many thanks for your review. Most of your comments are straightforward and I’ve prepared a version which incorporates them. I’ve got a couple of suggestions/proposals in line below. Cheers, Ian > > Minor issues: > s7.4: >> o The received bindprefix6-len value is not larger than the number >> of bytes, divided by 8, received in the bind-ipv6-prefix field. >> (e.g. the bindprefix6-len is 128 but the bind-ipv6-prefix field is >> only 8 bytes long). > Given that s6.1 gives a deterministic algorithm for calculating the length of > the bind-ipv6-prefix field, I don't understand why the validation does not > check that the length of the field is exactly as specified by this algorithm > rather than using it as a lower limit. [if - Suggested re-word for the s7.4 bullet point: o The number of bytes received in the bind-ipv6-prefix field is consistent with the received bindprefix6-len value (calculated as described in Section 6.1). ] > s7.5 and s8 (last para): Given that the time constraints and number of retries > will interact and are implemented in different devices, I think these two > values need some sensible defaults defined so that devices from different > sources should interoperate successfully out of the box. [if - I think this is a reasonable suggestion, the question is what’s a sensible default? As I see it, the following things need to be considered: 1, If the client is trying to update the server because it’s IPV6 address has changed, therefore, the client’s 4 over 6 tunnel cannot function (new address is in use at the client, old address in the server and tunnel concentrators). A default on the lower side make sense here to try and get service restored as quickly as possible. 2, If the client is trying to update its IPv6 address and is not getting back a DHCPACK from the server, this is for one of two reasons - either the server is not available, or this is the 2nd attempt to update the address in less than the server’s update interval policy. In the first instance, going back to DHCPDISCOVER gives the client the best chance of finding a working server. In the second instance, it may be safe to a 3, The update interval on the server side is to deal with the second case - to stop clients from constantly sending updates (which may need to trigger other back-end provisioning functions) enabling a DOS attack, so needs to be long enough to reasonably protect against this. Trying to balance the above, I propose the following defaults for client and server: The client does 6 retries using the RFC2131 backoff interval timers. This means a minimum time of 182 seconds ((4-1)+(8-1)+(16-1)+(32-1)+(64-1)+(64-1)), and 180 seconds at the server side. If the 6th retry is not successful, the client resets to DHCPDISCOVER. I’d appreciate any thoughts on the above proposal. > > Abstract: Add mention of RFC 6346 and RFC 7598 for explanation of softwire > scheme. [if - I’m not sure why you suggest RFC6346 here as that describes A+P based routing. This draft is compatible with A+P routing provisioning using DHCP 4o6 (RFC7618, referenced in Sec. 7.6 of the draft), but it’s not essential to how it works and can be used without A+P. RFC4925 was the original softwire problem statement but that doesn’t really describe enough detail as to how the different mechanisms evolved. What about the following update to the first sentence to reference the specific mechanisms that this works with: DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g. RFC7596 or RFC7597), the operator... - Regarding RFC7598, what about the following updated paragraph in the Abstract to be more clear ab out the relevance of RFC7598?: "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients” (RFC7598), describes a deterministic DHCPv6 based mechanism for provisioning softwires. This document updates (RFC7598) allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's Option Request Option (ORO) request and appear directly within subsequent messages sent by the DHCPv6 server. ]
