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

From: Elwyn Davies <[email-masked]>
Date: Thu, 06 Sep 2018 08:40:49 -0700

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dhc-dhcp4o6-saddr-opt-04
Reviewer: Elwyn Davies
Review Date: 2018-09-06
IETF LC End Date: 2018-09-07
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits. Thanks - well written and almost all quite clear.

Major issues:
None

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.

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.

Nits/editorial comments:
General: s/e.g./e.g.,/g

Abstract, sentence 2: Introduce DHCP 4o6 abbreviation: s/For DHCPv4 over
DHCPv6/For DHCPv4 over DHCPv6 (DHCP 4o6)/.

Abstract: Add mention of RFC 6346 and RFC 7598 for explanation of softwire
scheme.

Abstract, para 2: Expand ORO (Option Request Option) and give ref to rfc3315bis.

s1, para 3:  s/attached to any routable IPv6 prefix/attached to a network
segment using any routable IPv6 prefix/

s4, para 1: It would be useful to remind readers of the expansion of BR in
OPTION_S46_BR:  Maybe s/the remote IPv6 address for the softwire/the remote
IPv6 address used for the softwire border router/

s4, para 1: Expand ULA (not a well-known abbreviation).

s7.2.1, para 1: 'flash' is colloquial and may not be generally understood.  I
think it can safely be removed.

s7.4, para after bullets: s/For either of these cases,/If either check fails,/

s10: To be absolutely clear, there are two instances where the following change
ought to be made: OLD: in the table at
https://www.iana.org/assignments/dhcpv6-parameters: NEW: in the Option Codes
table at https://www.iana.org/assignments/dhcpv6-parameters: ENDS

---

From: [email-masked]
Date: Tue, 11 Sep 2018 13:41:46 +0200

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

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

> 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

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Sep 2018 20:32:11 +0000

Hi.

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

Other comments/responses seem OK.

- Bernie

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

Hi 

Cheers,
Ian

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.

-