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

"STARK, BARBARA H" <bs7652@att.com> Tue, 26 February 2013 18:06 UTC

Return-Path: <bs7652@att.com>
X-Original-To: renum@ietfa.amsl.com
Delivered-To: renum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A947B21F8A54; Tue, 26 Feb 2013 10:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.099
X-Spam-Level:
X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxrMPFkOp46H; Tue, 26 Feb 2013 10:06:42 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1747821F886B; Tue, 26 Feb 2013 10:06:42 -0800 (PST)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 2b9fc215.53c06940.4288268.00-533.11847790.nbfkord-smmo07.seg.att.com (envelope-from <bs7652@att.com>); Tue, 26 Feb 2013 18:06:42 +0000 (UTC)
X-MXL-Hash: 512cf9b24a1a8ee4-7de3abe4ef9469d00e2360082cd6e3c605c42217
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ea9fc215.0.4288249.00-496.11847726.nbfkord-smmo07.seg.att.com (envelope-from <bs7652@att.com>); Tue, 26 Feb 2013 18:06:40 +0000 (UTC)
X-MXL-Hash: 512cf9b022ec96b0-34130cba56638fea4099aab599ab43fa530cfdd5
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1QI6c7i028467; Tue, 26 Feb 2013 13:06:38 -0500
Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1QI6Tnk028206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 13:06:33 -0500
Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Tue, 26 Feb 2013 13:02:16 -0500
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 13:02:05 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: "Liubing (Leo)" <leo.liubing@huawei.com>, "ipv6@ietf.org" <ipv6@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiMZZ8g
Date: Tue, 26 Feb 2013 18:02:04 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130255AE0@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.174.97]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <bs7652@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=Ob0v+GvY c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=SawaiHsxiTQA:10 a=mjfWdd7OfzUA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=qIRfQioSgDsA:10 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8]
X-AnalysisOut: [ a=IrhkzyA9JQ-jOgXrGygA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA]
X-AnalysisOut: [:10 a=peF9eE_zjQwA:10 a=_nbaV8ywFon7Z7Y3:21 a=l_Yy1O5uc6Fl]
X-AnalysisOut: [zOYM:21]
X-Mailman-Approved-At: Tue, 26 Feb 2013 10:31:11 -0800
Cc: "renum@ietf.org" <renum@ietf.org>
Subject: Re: [renum] SLAAC/DHCPv6 addr-conf operational gaps
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2013 18:06:43 -0000

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