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

[Ian Farrer <[e-mail]>]

Forwarding to DHC as this is the current home for the draft.

Cheers,
Ian

> Begin forwarded message:
> 
> From: Jonas Gorski <[e-mail]>
> Subject: Re: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017
> Date: 19. May 2017 at 14:18:21 GMT+2
> To: [e-mail], [e-mail]
> Cc: [e-mail], [e-mail]
> 
> Hi,
> 
> On 22.02.2017 18:37, [e-mail] <mailto:[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
> 
> _______________________________________________
> Softwires mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>