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

Ian Farrer <ianfarrer@gmx.com> Tue, 23 May 2017 16:10 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 95E10129BB2 for <dhcwg@ietfa.amsl.com>; Tue, 23 May 2017 09:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6eVh8lE1ry03 for <dhcwg@ietfa.amsl.com>; Tue, 23 May 2017 09:10:05 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1BC129418 for <dhcwg@ietf.org>; Tue, 23 May 2017 09:10:04 -0700 (PDT)
Received: from [] ([]) by mail.gmx.com (mrgmx003 []) with ESMTPSA (Nemesis) id 0LnxQO-1dt6hd2sS8-00fyup for <dhcwg@ietf.org>; Tue, 23 May 2017 18:10:01 +0200
From: Ian Farrer <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1A629A9F-823A-4829-BC27-6255E46DEEAD"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <03C4A74B-918F-4ECF-B8FF-075CBF7477DF@gmx.com>
References: <65646669-e32f-958c-684c-a36d4272b046@gmail.com>
To: dhcwg <dhcwg@ietf.org>
Date: Tue, 23 May 2017 18:10:00 +0200
X-Mailer: Apple Mail (2.3273)
X-Provags-ID: V03:K0:1JLpeIH/CGFaXAvtvMdgZZDRaOSn2YWaEA8gEaX3HJcT/IgXaDB DBVSRlv+YndMkLTWZUqbrR5knTn5GnOBP+lXi9TJKgO+hHnEDDl+jpCvs4IUQkJ9Zwr34db UhUwhvPTFkXo9YoIl2tNI9LT6IyHPKUOXClbX5NiFeH1uMe3cPhtnpwn1fPla2CwkXzRRhr eaS0h8GJIH3yO2HWjPNGg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:G1HoC8xz/6U=:LSpNDK9jvyyeyvbWZbBHmn IC3qKPYR5tfVBSmIrXfp7fMCEd8dits272df24DLpGfM9rZYv8yViCVNQ++FLBm3wRpwz287X JiLsi/Xc0MEEZ2WujJQ1O3FiC9EXnmBCu9qvIHxzPZE67Cp2GK4ih3bIafJEB48ZKY5b/vjcE JZkuMOj/YDr/5qK318NMzZYKSonaN4ua1MQRsGB5RwXTFTq+XagUW33prhj/G9g0dvfwwx3bH W2AFfNw2WPqhBvQR2pGSUocwmXZbc73S5teUvvRPKS6fryjMGml8yjUD7e8/Eqm5b6P210eUq 9lOkfshc5XlL/EKmLYSWBFGiYsnCi18asVcF202/tAdMa6gT+IHTdCMg/ZKLEfN8bE3+NJu14 4qabY/pkEjdxQ/hqxScDaSikFeDQg5frHWJmGfVbPaYVJKCrngzuCktIOEx5c+B2pfG9rGRkx Al58rxKSbhWl0dEFHw9Hxstp+ju8xJOGqtRuGHcykKeMtRrB8KxI9cClLMrwoskLAe0MITWvx XZR1lO4ZqLpytuu802pD6HycRzsKwVaADuzIMfIBl0Xr/zHnLmTaJzJtkxPJ8NHPO1pNs7Rhl gj2nxtlVAEmDVZsyXO6U8spmBwElsw+zRvlEVJQSTeWIf2SxYeUNNGmHqLOkcN3J9O057SeE8 A7htMdmEdmdlm6uBsjV1g8qiR2jISrVtRM8cvRliTdsP4jdRYOKcdOU62cl3KWG8twdOaQCMW AAySwlgYQUHUCIVDNg3llynJNyxYx2WgH9EcA0CH/N9aUAwN1V0tWC4RnJPWjfZQtFO49e+UO Zw2VA0j
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/za80L6rgH3d91CNEo4FFM8P9CUo>
Subject: [dhcwg] Fwd: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 16:10:08 -0000

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


> Begin forwarded message:
> From: Jonas Gorski <jonas.gorski@gmail.com>
> 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: tomasz.mrugalski@gmail.com, dhcwg@ietf.org
> Cc: softwires@ietf.org, draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org
> Hi,
> On 22.02.2017 18:37, tomasz.mrugalski@gmail.com <mailto:tomasz.mrugalski@gmail.com> 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 
> 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
> I hope these comments help improving the proposed standard.
> Regards
> Jonas Gorski
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org <mailto:Softwires@ietf.org>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>