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

["Liubing (Leo)" <[e-mail]>]

Hi, Barbara

Thanks for your comments. Please see replies inline.

> -----Original Message-----
> From: STARK, BARBARA H [mailto:[e-mail]]
> Sent: Wednesday, February 27, 2013 2:02 AM
> To: Liubing (Leo); [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: 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?

[Bing] Yes, we just leave the Preferred Lifetime as default, it should be > 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. 

[Bing] As I learned from RFC4862, it 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.

[Bing] We haven't run that, but could do it later. Thanks for the remind.
For separating A flag and Preferred Lifetime, it is just the concept of separating "_address configuration_ methods" and "address aging" raised by Mark Smith in another mail on this thread. I think it is a good point of view, and if we can initiate subsequence revision of host behavior, we should consider it.

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

[Bing] We haven't tried this, could do later. But we used to talk about it in 6renum WG. DHCPv6-Reconfiguration is considered not suitable for bulk usage, since it is stateful and unicast, might cause heavy load for the DHCPv6 server, this has been documented in [draft-ietf-6renum-gap-analysis]. Moreover, it is more difficult for administration to simultaneously operate DHCPv6 and ND together.  

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.

[Bing] That is just the ambiguous of the RA flags behavior. IMHO, we need to specify it clear in the standard. Whether the RA flags should govern DHCPv6 behavior or not, we can discuss it in the next step if the groups agree we should deal with the ambiguous problem firstly.

B.R.
Bing


> Barbara
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Liubing (Leo)
> > Sent: Tuesday, February 26, 2013 2:14 AM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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: [e-mail] [mailto:[e-mail]]
> > > Sent: Monday, February 25, 2013 5:52 PM
> > > To: Liubing (Leo)
> > > Cc: [e-mail]
> > > 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------