Re: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt

Erik Nordmark <nordmark@acm.org> Tue, 25 February 2014 08:57 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC80C1A0464 for <ipv6@ietfa.amsl.com>; Tue, 25 Feb 2014 00:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaBgjeO5nFVV for <ipv6@ietfa.amsl.com>; Tue, 25 Feb 2014 00:57:50 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7167F1A0388 for <ipv6@ietf.org>; Tue, 25 Feb 2014 00:57:50 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1P8vfjE015944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 00:57:42 -0800
Message-ID: <530C5B06.5090609@acm.org>
Date: Tue, 25 Feb 2014 00:57:42 -0800
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>, "Liubing (Leo)" <leo.liubing@huawei.com>, IPv6 IPv6 List <ipv6@ietf.org>
Subject: Re: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8535C2@nkgeml506-mbx.china.huawei.com> <1393317678.39795.YahooMailNeo@web162204.mail.bf1.yahoo.com>
In-Reply-To: <1393317678.39795.YahooMailNeo@web162204.mail.bf1.yahoo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;ZLgZ4vqd4xG+NugyCY+HFQ== M;SD264vqd4xG+NugyCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/BACfWrn-KAbiPXQhVe8LVsjDiG0
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 08:57:52 -0000

On 2/25/14 12:41 AM, Mark ZZZ Smith wrote:
>
> I think it is right to point out that address lifetime expiry is the only mechanism to be used to expire addresses, rather than whether or not the address configuration method also continues to be active. Specific to DHCPv6, it may be worth referencing this text in RFC3315, to further describe that address expiry is based only on lifetime:
>
> "If the client receives no responses before the message transmission
>     process terminates, as described in section 14, the client SHOULD
>     continue to use any IP addresses, using the last known lifetimes for
>     those addresses, and SHOULD continue to use any other previously
>     obtained configuration parameters."
>
>
> It might be worth pointing out that if addresses are to be actively expired via an address configuration method, then the technique to use would be to "reconfigure" the addresses with low or zero valid lifetime, letting the address expiry method using the lifetime value then expire them.
That is the behavior we have today. Sounds like this needs to be made 
more explicit.
>
> "However, for the implementation, making DHCPv6 initialing totally
>     depend on RA messages is more or less fragile since DHCPv6-only-
>     without-RA might become a valid case in the future or some special
>     scenarios. So it is recommended for implementers to take into account
>     the cases that RAs are absent. The DHCPv6 protocol state machine
>     should support DHCPv6 be initiated after a timeslot of RAs absent."
>
> I think it would be better to wait until "DHCPv6-only-without-RA" is specified before making this recommendation. I don't think there is anything which provides advice on how to implement it. For example, I'd think it would be better to initiate RA RS and DHCPv6 Solicit at the same time, rather than waiting for RA RSes to timeout, as it would provide the better end-user experience.
This use case (DHCP but no routers) was discussed in the DHC WG a long 
time ago. (If I don't misremember it even had a name - "the dentist 
office".) The idea was that some networks wouldn't even be connected to 
the network, and be quite small.

The answer from back then was that if there wasn't a router, who would 
configure a DHCP server.
Today everything seems to be connected - even if in some cases it is a 
private network and not the public Internet.

Hence I question the utility of changing the protocols and 
implementations to handle a case when there is no router.

     Erik

>
> However, initiating RA RS and DHCPv6 Solicit at the same time would then imply that the the RA M & O bits have no value. DHCPv6 clients would then have to always assume they need to perform a stateful DHCPv6 transaction, even though the chosen methods for the link might be SLAAC + stateless DHCPv6 for non-address information. RFC3315 is a bit ambiguous as to what to do if the DHCPv6 server does not have any addresses to give to the client:
>
>
> "If the client receives no addresses in
>     any of the IAs, it may either try another server (perhaps restarting
>     the DHCP server discovery process) or use the Information-request
>     message to obtain other configuration information only."
>
> In the context of performing RA RS and DHCPv6 Solicit in parallel, it is hard to know which is the better choice (+). On the one hand, the DHCPv6 server not having addresses available could indicate it is a stateless only server, so the Information-request procedure should be performed. OTOH, perhaps the stateful DHCPv6 server selected by the client ran out of addresses, and another stateful DHCPv6 server might be available with addresses. If only there were some bits somewhere that would indicate what the DHCPv6 client should do ...
>
> These ambiguities are just from me thinking about it for half an hour or so. I suspect there would be a lot more. The "Less is More" and other principles from RFC5505 come to mind.
>
>
> Regards,
> Mark.
>
> (+ but certainly not this sort of behaviour - http://lists.si6networks.com/pipermail/ipv6hackers/2014-February/001501.html)
>
>> Many thanks!
>>
>> Best regards,
>> Bing
>>
>>
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Friday, February 14, 2014 6:09 PM
>> To: Liubing (Leo); Ron Bonica; Liubing (Leo); Ron Bonica
>> Subject: New Version Notification for
>> draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt
>>
>>
>> A new version of I-D, draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt
>> has been successfully submitted by Bing Liu and posted to the IETF repository.
>>
>> Name:        draft-liu-6man-dhcpv6-slaac-implementation-guide
>> Revision:    00
>> Title:        DHCPv6/SLAAC Interaction Implementation Guidance
>> Document date:    2014-02-14
>> Group:        Individual Submission
>> Pages:        6
>> URL:
>> http://www.ietf.org/internet-drafts/draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-liu-6man-dhcpv6-slaac-implementation-guide/
>> Htmlized:
>> http://tools.ietf.org/html/draft-liu-6man-dhcpv6-slaac-implementation-guide-00
>>
>>
>> Abstract:
>>     ND and DHCPv6 protocols could have some interaction on address
>>     provisioning with the A, M, and O flags defined in ND protocol. But
>>     the relevant standard definitions of the flags contain ambiguity, so
>>     that current implementations in operating systems have varied on
>>     interpreting the flags. The variation might impact real network
>>     operations, so this document aims to provide some guidance on what
>>     should be the proper implementation on the interaction behavior.
>>
>>
>>
>>                                                                                  
>>    
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>