Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps

This is interesting. Thanks for doing these tests and submitting the results.

When testing the switching behavior, I'm curious for the " SLAAC-only host receiving A=0&M=1 " case as to what you set the Preferred Lifetime to, when you set A=0. I'm guessing Preferred Lifetime > 0?
Since RFC 4862 states "A preferred address becomes deprecated when its preferred lifetime expires", I would only have expected a host to deprecate a SLAAC-obtained address if the RA message set Preferred Lifetime to zero. It sounds like the case where the RA is changed from A=1 and Preferred Lifetime > 0 to A=0 and Preferred Lifetime > 0 is ambiguous. I'm not quite sure what the use case is for separating the A flag and Preferred Lifetime settings. Did you also run the test by changing to A=0 and Preferred Lifetime = 0? I would hope that there would be consistent behavior in that case.

For the "DHCPv6-only host receiving A=1&M=0" case, I'm curious as to whether you also tried sending a DHCPv6 Reconfigure message and forcing the host to release the DHCPv6-assigned address; and send A=1&M=0 in an RA directly after sending the Reconfigure. I'm not sure what the use case is for trying to force the release or deprecation of a DHCPv6 address via flags in an RA message. Once a host has a DHCPv6 address, I would have expected its subsequent behavior relating to that address and that DHCPv6 server to be governed by RFC 3315. The Linux/MAC behavior appears consistent with what I would have expected. The Windows 7 does not. I'm unaware of even a "hint" that suggests RA flags have a role in governing DHCPv6 behavior once RFC 3315 is in play.
Barbara

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Liubing (Leo)
> Sent: Tuesday, February 26, 2013 2:14 AM
> To: ipv6@ietf.org; v6ops@ietf.org
> Cc: renum@ietf.org
> Subject: SLAAC/DHCPv6 addr-conf operational gaps
> 
> Hi, 6man & v6ops
> 
> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
> 
> As we know there are several flags in RA messages regarding with the host
> configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
> and O (Otherconfig) flag.
> For some reason, the host behavior of interpreting the flags is ambiguous in
> the standard (mainly RFC4862). I presented a draft discussing M flag behavior
> in 6man @ietf84, and there were some feedbacks arguing the same issue.
> This draft analyzed all the three flags, and provided test result of current
> implementations, it showed the behavior of different mainstream desktop
> OSes have varied. The ambiguous and variation might cause operational
> problems, such as renumbering (used to discuss in 6renum WG and been
> documented in the WG drafts), cold start problem, and management gaps
> .etc.
> 
> Your review and comments would be appreciated very much.
> 
> All the best,
> Bing
> 
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Monday, February 25, 2013 5:52 PM
> > To: Liubing (Leo)
> > Cc: rbonica@juniper.net
> > Subject: New Version Notification for
> > draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >
> >
> > A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> > has been successfully submitted by Bing Liu and posted to the IETF
> > repository.
> >
> > Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
> > Revision:	 01
> > Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
> > Statement
> > Creation date:	 2013-02-25
> > Group:		 Individual Submission
> > Number of pages: 12
> > URL:
> > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-prob
> > lem-
> > 01.txt
> > Status:
> > http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
> > Htmlized:
> > http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
> > Diff:
> > http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem
> > -01
> >
> > Abstract:
> >    This document analyzes the host behavior of DHCPv6/SLAAC interaction
> >    issue. It reviews the standard definition of the host behaviors and
> >    provides the test results of current mainstream implementations. Some
> >    potential operational gaps of the interaction are also described.
> >
> >
> >
> >
> > The IETF Secretariat
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------