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

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 24 Feb 2014 09:57:20 +0000

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.

Many thanks!

Best regards,
Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 25 Feb 2014 00:41:18 -0800 (PST)

Hi,

----- Original Message -----
> From: Liubing (Leo) <[email-masked]>
> To: IPv6 IPv6 List <[email-masked]>
> 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,
> 
> 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.
> 
> 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.

Regards,
Mark.

(+ but certainly not this sort of behaviour - http://lists.si6networks.com/pipermail/ipv6hackers/2014-February/001501.html)

> Subject: New Version Notification for 
> draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt
> 
> 
> 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:
> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Feb 2014 00:57:42 -0800

> 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 v…
That is the behavior we have today. Sounds like this needs to be made 
more explicit.
> 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 e…
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