Re: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017

[Jonas Gorski <[e-mail]>]

Hi,

On 22.02.2017 18:37, [e-mail] wrote:
> Hi,
>
> This message initiates a two weeks long DHC WG adoption call on:
>
> Title: DHCPv4 over DHCPv6 Source Address Option
> Pages: 9
> Date: 2017-02-01
> Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07
> Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07
>
> This document initially started as work intended to be adopted in
> Softwires, but after a discussion with chairs, responsible AD (Suresh)
> and presenting this work in DHC, the conclusion is to aim for DHC
> adoption, not Softwires. Therefore this is a DHC adoption call.
>
> This message is cross-posted to Softwires to let Softwire experts weigh
> in their opinion. Please be sure to post your comments to DHC list,
> though. Comments sent by end of March 8th, 2017 are much appreciated.

I am working on implementing this draft (started in version 4), and like 
to add a few comments. It is based on an existing RFC 7341 client 
(DHCPv4 over DHCPv6) which wasn't written by me, which was done by 
modifying an existing DHCPv4 client to transparently wrap all messages in
DHCPv6 messages, so the DHCPv4 part doesn't really know about it.

My comments are split into three parts, first about the place of the 
options, then about handling them, and finally some nitpicks.

1. The placement of the new options

I'll start with the placement of the (new) options. Pre-draft, the 
DHCPv6 encapsulation was a strict transport and stateless. This draft 
now adds both new options to the outer DHCPv6 messages as well the inner 
DHCPv4 one. This seems quite awkward, as the client now needs to be able 
to access both the outer envelope as well the inner message at the same 
time for a full picture. IMHO especially awkward is the change from a 
DHCPv6 OPTION_DHCP4O6_SADDR_HINT to a DHCPv4 OPTION_DHCP4O6_SADDR. This 
caused a bit of spaghetti-code when trying to somehow pass information 
between the (separated) code responsible for the DHCPv6 
en-/decapsulation, and the actual DHCPv4 code. The DHCPv4 code needed to 
get the contents of the DHCPv6 envelope at the appropriate place.

Having all three as DHCPv4 options would make it much more consistent, 
as everything is now kept in one channel. This would also then preserve 
RFC 7341's statement that "The DHCPv6-relay encapsulation is used solely 
to deliver DHCPv4 packets to a DHCPv4-capable server, and does not 
allocate any IPv6 addresses nor does it provide IPv6-configuration 
information to the client."

The alternative that I could think of would be to move the _SADDR_HINT 
and _BR options to the original DHCPv6 message that contains the 
OPTION_DHCP4_O_DHCP6_SERVER option. Maybe create an container for them, 
similar to how RFC 7598 defines containers for software46. The RFC 7341 
client would then be able to already send the _SADDR in its discovers.

2. Handling the new options

The OPTION_S46_BR poses no large issues. The new 
OPTION_DHCP4O6_SADDR_HINT caused and still causes a lot of headaches for 
me. As far as my understanding with modern distributions (be they 
desktop or embedded) is that the DHCP clients usually do no 
configuration by their own, and just pass on the Lease's contents to a 
networking management deamon after they received the ACK. This works 
fine with DHCPv6, with DHCPv4, and with RFC 7341 DHCPv4overDHCPv6.

The new OPTION_DHCP4O6_SADDR_HINT now requires the network management 
daemon to (potentially) allocate/assign a new IP address during the 
offer/request phase (including the DAD), which makes the interaction 
quite a bit more complex, as there are a few new potential error 
transitions. There is now the awkward state where you might need to 
revert network configuration after a NACK or error from the server, or a 
timeout despite never having a valid lease. Of course if one wants to 
avoid complexity one can just hope that we have a global address on the 
wan interface already and always return that. This would be alleviated 
by already having this option in the original DHCPv6 lease, as then the 
network management daemon could allocate the IP address already during 
the DHCPv6 lease acquisition handling phase.

And finally when adding support for it to a client that does 
"transparent" DHCPv6 en-/decapsulation this means that the DHCPv6 code 
now needs access to the DHCPv4 state machine to know when to include the 
_SADDR option, and when to (not) expect it, as it has no DHCPv6 message 
types to rely on.

3. Nitpicks

The flow diagram in "5. IPv6/IPv4 Binding Message Flow" makes it look 
like the OPTION_DHCP4O6_SADDR is part of the DHCPv6 message, not part of 
the embedded DHCPv4 message.

The option OPTION_DHCP4O6_SADDR is described in a subsection of  "6. 
DHCPv6 Options", despite it being a DHCPv4 option (and there being only
one DHCPv6 option, so the plural doesn't help either).

Both make it easy to mistake OPTION_DHCP4O6_SADDR as a DHCPv6 option, 
and not a DHCPv4 one (as I did until I read the newest draft, and will 
need to fix).

Also it feels a bit like the draft doesn't handle potential error cases 
enough, although I can't really put my finger on it. One thing I am
wondering about is how the client should behave when it doesn't have any
assigned prefixes or global addresses? Is sending the link local address
fine? Should it abort in that case? How about ULA addresses? In case of
using  DHCPv6 broadcast address as DHCP4ov6 server this could happen
AFAICT.

I hope these comments help improving the proposed standard.


Regards
Jonas Gorski