IETF Logo Mail Archive

Re: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?]

"Liubing (Leo)" <leo.liubing@huawei.com> Sat, 30 March 2013 09:44 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63FF21F86F5 for <v6ops@ietfa.amsl.com>; Sat, 30 Mar 2013 02:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.074
X-Spam-Level:
X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEh1L4KhP6-k for <v6ops@ietfa.amsl.com>; Sat, 30 Mar 2013 02:44:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9B3521F86F0 for <v6ops@ietf.org>; Sat, 30 Mar 2013 02:44:07 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARG31987; Sat, 30 Mar 2013 09:44:05 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 09:44:04 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 09:44:04 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Sat, 30 Mar 2013 17:44:02 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Iljitsch van Beijnum <iljitsch@muada.com>
Thread-Topic: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?]
Thread-Index: AQHOLSQnH1oAQEnPN0iF2Ic0n8/Uzpi99h/A
Date: Sat, 30 Mar 2013 09:44:02 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6ED152@nkgeml506-mbx.china.huawei.com>
References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <20130330.083107.74693658.sthaug@nethelp.no> <A96B26C0-0354-44A3-9BD6-DEC4B5A882AC@muada.com> <5156A83A.2090604@gmail.com>
In-Reply-To: <5156A83A.2090604@gmail.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2013 09:44:08 -0000

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Brian E Carpenter
> Sent: Saturday, March 30, 2013 4:54 PM
> To: Iljitsch van Beijnum
> Cc: v6ops@ietf.org WG
> Subject: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6
> Route/DefRouter/Src-basedRoute configuration to Client?]
> 
> On 30/03/2013 07:42, Iljitsch van Beijnum wrote:
> > On 30 mrt 2013, at 8:31, sthaug@nethelp.no wrote:
> >
> >>>> you want to run your DHCPv6 client always, even if there is no M=1.
> This means that networks will see tons of multicasts looking for a DHCPv6
> server, retransmitted at infinitum if there is no DHCPv6 server, wasting
> precious airtime on wireless networks where multicasts are sent at a very
> low rate
> >
> >> How is this worse than current DHCPv4 client behavior?
> >
> > In the IPv4 world, DHCP is the only game in town. So it's reasonable to
> assume the presence of a DHCP server. In the IPv4 world, there can be
> stateless autoconfig or DHCPv6 for address assignment. If hosts are going to
> solicit an address through DHCPv6 that means everyone has to run a DHCPv6
> server to soak up those requests, even the people who just want to use
> stateless autoconfiguration.
> 
> I think people should look at draft-liu-bonica-dhcpv6-slaac-problem,
> because it really is time to resolve this issue. And it's
> orthogonal to the default/source route issue.

[Bing] Hi, Brian, thank you mentioned this. Hope more people could notice the problem. 
Let me to summarize several important points of the draft here: 
- at initial state, Win7 would start DHCPv6 solicit if no RA received, while Linux/MAC won't start DHCPv6 unless received M=1
- the hosts configured by SLAAC first, and then M changed from 0 to 1, Win7 would initiate DHCPv6 along with SLAAC; Linux/MAC did nothing
- the hosts configured by DHCPv6 first, and then M changed from 1 to 0, Win7 would release DHCPv6 address while Linux/MAC did nothing
These different behaviors would be problematic especially when renumbering. 

> 
>    Brian
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email