RE: [dhcwg] Genart last call review of draft-ietf-dhc-dhcp4o6-saddr-opt-04

["Bernie Volz (volz)" <[e-mail]>]

Hi.

One comment (as DHC WG co-chair and shepherd). See inline below (BV>).

Other comments/responses seem OK.

- Bernie

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Tuesday, September 11, 2018 7:42 AM
To: Elwyn Davies <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [dhcwg] Genart last call review of draft-ietf-dhc-dhcp4o6-saddr-opt-04

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.

BV> How about just following RFC2131, section 3.1 (step 5):

     The client times out and retransmits the DHCPREQUEST message if the
     client receives neither a DHCPACK or a DHCPNAK message.  The client
     retransmits the DHCPREQUEST according to the retransmission
     algorithm in section 4.1.  The client should choose to retransmit
     the DHCPREQUEST enough times to give adequate probability of
     contacting the server without causing the client (and the user of
     that client) to wait overly long before giving up; e.g., a client
     retransmitting as described in section 4.1 might retransmit the
     DHCPREQUEST message four times, for a total delay of 60 seconds,
     before restarting the initialization procedure.  If the client
     receives neither a DHCPACK or a DHCPNAK message after employing the
     retransmission algorithm, the client reverts to INIT state and
     restarts the initialization process.  The client SHOULD notify the
     user that the initialization process has failed and is restarting.


> 
> 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.
]