Hi.
One comment (as DHC WG co-chair and shepherd). See inline below (BV>).
Other comments/responses seem OK.
- Bernie
-----Original Message-----
From: ianfarrer@xxxxxxx <ianfarrer@xxxxxxx>
Sent: Tuesday, September 11, 2018 7:42 AM
To: Elwyn Davies <elwynd@xxxxxxxxxxxxxx>
Cc: gen-art@xxxxxxxx; draft-ietf-dhc-dhcp4o6-saddr-opt.all@xxxxxxxx; dhcwg@xxxxxxxx; ietf@xxxxxxxx
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.
]
