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

Mark ZZZ Smith <> Tue, 25 February 2014 08:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37ED81A01D9 for <>; Tue, 25 Feb 2014 00:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.313
X-Spam-Level: **
X-Spam-Status: No, score=2.313 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-l3l3MXccAA for <>; Tue, 25 Feb 2014 00:41:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1616D1A0194 for <>; Tue, 25 Feb 2014 00:41:19 -0800 (PST)
Received: from [] by with NNFMP; 25 Feb 2014 08:41:19 -0000
Received: from [] by with NNFMP; 25 Feb 2014 08:41:18 -0000
Received: from [] by with NNFMP; 25 Feb 2014 08:41:18 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 66663 invoked by uid 60001); 25 Feb 2014 08:41:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1393317678; bh=R87kgMk1cGAFuthpBDpvDiUC2GNHOFpSJLH4WCIfd0Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NhV28Q34+f5djqJwjxG6vrjjJOSi0Klo1Q8PXc57dKHkRjM4OyjWuSudaUKw3cMm2W5mFDQ8SZ5XLBalfZTYtYf4ii3iqraf6L3hOK7oLuB2VRYS9zg47/yiCGuj+25pU5HozFFvEVJ2B9KpIsASB2REYUaEnr+kVNHaK1Vg+Jg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f1JRwjOKe5EY/yY/b4LPAsQp4pfM4VzL35eQ1wpqWwcg59jdV+HEhxaeOQmkFi+jvDwtArSDEcKeTvqbt0689itLej+fLbKxJ9eC1bR7ORu48iJavxx3jTrdMlqL+UxBVzNCGLKT8JhrjCzivW5WXJdwxXKPx58AKCAp+poGc1I=;
X-YMail-OSG: 3yA4mGAVM1lRYij3Y3mcF1edf0Ws4TCY1573e1Jt5EI1ftY MtwsYt729wyNj3RA7P7dZFOd_1G0GyyHwAowzhSQPH1X_96nfxOoyTy01Tun 2AZUjNF37VBtjenMJsK9kb6a_fEp.z_62ckzZIaKpkVGqPkQwKD2nNN5PUVn iDC8GoQlFbDS8UhMszLxkfwtVbHEHYmDL5q.kU3Keg56NPf78mJ9O1IICZG0 IIBTRcTeKCRMCTwqGG2WB76qud6J5UwSC829U_XK2sNT6NOPZ1n.6DQzEKGw 5MxXaJ.pWPYt1cq1tGhUGIkndxcFoqS4tYERMwVsrOsiru4opxahBiG69umF FsxFHzeZpfkXx0O6jbZLqUdJxk6JBt4YkHWW8b316o8cDXlEp.yLS.UzqU5F U6U0fqmhCECaSC6BRjrYOuP4rPjyw2Buw8gxZHBDNcLxxSXVJOUkRNtOdrvX hPUGRxrgaUImCZs2DItfsOfNVAOA86NjYsd70nsXCtwRPglnRC.NdwDAdanF _Oxp0xbL9r.krq1TjlAG0sR2v5cz4EROTXBi4vxBPL9do8Gzcr8FaRDZS2TM GEnNducnri4r9C0hILzxD337PIlzHmsjKAHVzlYkZ2ZdxFMSaDT0cA0PXnc1 wy548vCvogJARtKI01EoFl1YntNn0xQxrWjRjw3A6jNBdfvxVpdj2LFt3xiX pCSjSm1rthhDZTHhTRq_Z70yJrCoRx264R85V4wPZnw--
Received: from [] by via HTTP; Tue, 25 Feb 2014 00:41:18 PST
X-Rocket-MIMEInfo: 002.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20.Cj4gVG86IElQdjYgSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPgo.IENjOiAKPiBTZW50OiBNb25kYXksIDI0IEZlYnJ1YXJ5IDIwMTQgODo1NyBQTQo.IFN1YmplY3Q6IENsZWFyaW5nIHRoZSBhbWJpZ3VpdHkgaW4gREhDUHY2L1NMQUFDIGludGVyYWN0aW9uLS8vRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LTZtYW4tZGhjcHY2LXNsYWEBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <>
Message-ID: <>
Date: Tue, 25 Feb 2014 00:41:18 -0800
From: Mark ZZZ Smith <>
Subject: Re: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt
To: "Liubing (Leo)" <>, IPv6 IPv6 List <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Feb 2014 08:41:22 -0000


----- Original Message -----
> From: Liubing (Leo) <>
> To: IPv6 IPv6 List <>
> Cc: 
> Sent: Monday, 24 February 2014 8:57 PM
> Subject: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt
> Hi Dear all,
> We've discussed the DHCPv6/SLAAC address-config problems in 6man a couple of 
> times before. 
> In summary, the problem is regarding with the ambiguity on interpreting the M 
> flag and O flag in ND messages. Different operating systems' behavior has 
> varied on interpreting the flags, especially when flags are in transition.
> In last ietf, the draft discussing the issues was adopted by v6ops to be a 
> problem statement document (draft-ietf-v6ops-dhcpv6-slaac-problem).
> People from OPS area agreed that the problems need to be solved, and suggested 
> us to initial another work in 6man to discuss how to deal with the issues. 
> So below is just the draft, it is to specify the proper behavior when the hosts 
> interpreting the relevant flags (A flag, M flag and O flag) in different states.
> Please have a review, and comment whether you agree the approaches.
> And we're open to discussing other proposals to clear the ambiguity (e.g. 
> revising the relevant specification in RFC4861/4862), so please feel free to 
> comment.

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.

"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.

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.


(+ but certainly not this sort of behaviour -

> Many thanks!
> Best regards,
> Bing
> -----Original Message-----
> From: [] 
> 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:            
> Status:        
> Htmlized:      
> 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
> The IETF Secretariat
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------