IETF Logo Mail Archive

[renum] SLAAC/DHCPv6 addr-conf operational gaps

"Liubing (Leo)" <leo.liubing@huawei.com> Tue, 26 February 2013 07:14 UTC

Return-Path: <leo.liubing@huawei.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 0C46621F9668; Mon, 25 Feb 2013 23:14:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level:
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
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 8JcVsdbBpbf1; Mon, 25 Feb 2013 23:14:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1169E21F960B; Mon, 25 Feb 2013 23:14:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQB42294; Tue, 26 Feb 2013 07:14:31 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 07:13:38 +0000
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 07:14:30 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 15:14:27 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cA==
Date: Tue, 26 Feb 2013 07:14:27 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com>
In-Reply-To: <20130225095210.8863.75094.idtracker@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@ietf.org" <renum@ietf.org>
Subject: [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 07:14:44 -0000

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

v2.23.0 | Report a Bug | By Email