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

Mark Smith <> Tue, 26 February 2013 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60EB121F8920 for <>; Tue, 26 Feb 2013 12:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.349
X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PpiM72CIkIqc for <>; Tue, 26 Feb 2013 12:34:34 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 4ADB921F889C for <>; Tue, 26 Feb 2013 12:34:34 -0800 (PST)
Received: from [] by with NNFMP; 26 Feb 2013 20:34:33 -0000
Received: from [] by with NNFMP; 26 Feb 2013 20:34:33 -0000
Received: from [] by with NNFMP; 26 Feb 2013 20:34:33 -0000
X-Yahoo-Newman-Property: ymail-5
Received: (qmail 79426 invoked by uid 60001); 26 Feb 2013 20:34:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1361910873; bh=y6gH6gNPjZdYi+d8xQFSX48JcT3R04YZd4dbpDBnytA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=19sfM13tdRNw/DhE3RJeK02PIKUvHNIHfTZF/yUCX3hpbNle19/n440hJk8C6u7oiJZgbLFAPZBZ/wrKSD1C0uoCFdudnPkuEtLilxgxz/wDTfLUoGB3ChJHWHcR1ObPZ7DrUsJMsuDoBViWmUaTQCN63P1N7s4tPMyr4I+zDDI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LDmFVUuiRsA0/a3S4HrrQryt/SPb9Ac/3cmtGq1WXO3kj+9o2lR9NeMsY9Bs90UY+IjcdcZNc5FXNqC/7ws6vCN0HX6yAM1TUpxaaliXHntTnJnVaRXOFrBWuaQHzXDyIlyNDVfJ4hol9EtCiz3p/KHwU9XW1qE7v1EQ+sGZZBw=;
X-YMail-OSG: BO43t_QVM1mM5KX2avIH5Y.WJ3tCS9ay0Zms5nY0c7aAncp xoe12iQHGKXLAJx4WEzAFX6N4P2pbAN7scj2lCGh1faPZN8Bn1PUSG8.AD78 CzZuKpkthHoXuPKyu3bL8J2kgQEoqkjgtVgCAwveeSi60u7sVk5IieO0nFce Nb2ND3oMDaweJnH.iPCbse8xRn_V.Yn9ZI9MJTSGBNXX3_PpJIAlvAQzssM5 q0vEHxwsMsh.lLoJypL4IL.4Wg9gBgckZXjKtadO9mr58pIiJMSKL89JNokT cySQmyjgDwFeHXSeFudiCm3YcB6Exl1TXbENfncoKBk52VpzPib1taSuAu7t DW3l91VDkX946fOl5fNzzPHzvHFXkM0AEurIAccKbyN.TU8..3wYuf9fOhMi oR6pRnZsfHgFqTyYWcfI4WPkdPbv4Vfm1T_X7lZFmhkJbgCTTGL14I0uBSLW Vb6np.IpknccnLfnv.ywM6C3W2JH0IvebrUn8VdU9oo8XKgeaCcxbmRbZoSo GQd6o7etlWfme8DmQkhp7A23HCooC
Received: from [] by via HTTP; Tue, 26 Feb 2013 12:34:33 PST
X-Rocket-MIMEInfo: 001.001, SGksCgpJJ3ZlIGhhZCBhIHF1aWNrIHJlYWQgdGhvdWdoLCBJJ2xsIHRyeSB0byBkbyBhIHRob3JvdWdoIG9uZSBpbiB0aGUgbmV4dCB3ZWVrIG9yIHNvLgoKVGhhbmtzIGZvciB3cml0aW5nIHRoaXMsIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCBkb2luZyBzb21ldGhpbmcgc2ltaWxhciBvdmVyIHRoZSBsYXN0IGZldyBtb250aHMgc2luY2UsIElJUkMsIEkgaGVhcmQgYWJvdXQgV2luZG93cyA3IGludmFsaWRhdGluZyBJUHY2IGFkZHJlc3NlcyBsZWFybmVkIHZpYSBESENQdjYgd2hlbiBTTEFBQyB3YXMgZW4BMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <>
Message-ID: <>
Date: Tue, 26 Feb 2013 12:34:33 -0800 (PST)
From: Mark Smith <>
To: "Liubing \(Leo\)" <>, "" <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 26 Feb 2013 12:35:38 -0800
Cc: "" <>
Subject: Re: [renum] SLAAC/DHCPv6 addr-conf operational gaps
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Mark Smith <>
List-Id: "Renumbering discussion mailing list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Feb 2013 20:34:37 -0000


I've had a quick read though, I'll try to do a thorough one in the next week or so.

Thanks for writing this, I've been thinking about doing something similar over the last few months since, IIRC, I heard about Windows 7 invalidating IPv6 addresses learned via DHCPv6 when SLAAC was enabled and DHCPv6 was disabled on a link.

A few thoughts I've had which may be useful -

Firstly, I came to realise that the mistake being made by Windows 7 was the assumption that the aging of the assigned IPv6 addresses was tightly coupled to the DHCPv6 session state, meaning that if DHCPv6 went away, so would the assigned addresses. This is generally the way DHCPv4 has worked. However, in IPv6/DHCPv6, it seems the address lifetime values in the IA_NA are not coupled to the T1 and T2 times, so if DHCPv6 goes away (perhaps because the M bit was switched off in a latter RA), the configured IPv6 addresses should be left to age out as per their preferred and valid lifetimes.

The other thing I noticed was that the M RA flag and the PIO A flags aren't mutually exclusive - I couldn't find any text in RFC4861 that says if the M bit is switched on, the PIO A flags must be switched off and vice-versa. So that suggests that the DHCPv6 and SLAAC can co-exist, and I think that is quite reasonable if you're transitioning a link from DHCPv6 to SLAAC address configuration or vice-versa.

Thinking about it more, I came realise that DHCPv6 and SLAAC are _address configuration_ methods, but are not address aging methods - IPv6 takes care of address aging via it's preferred and valid aging mechanisms, regardless of the address configuration method. Static assignment is also just an address configuration method, although typically the addresses don't age out, but only because they're normally set to infinity. Perhaps in the future there might be other address configuration methods.

I didn't seem to be able to find an RFC that made it clear that address configuration and address aging are quite separate, so perhaps this ID could be the one.

Regarding this text:

'For the host behavior, there is an explicit rule in the SLAAC specification [RFC4862]: "If the Autonomous flag is not set, silently ignore the Prefix Information option."'

I think RFC5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes." updates that advice, as the PIO option is used to indicates which prefix/range of addresses are on-link, via the PIO O bit, even if the PIO A bit is switched off.

Best regards,

> From: Liubing (Leo) <>
>To: "" <>rg>; "" <> 
>Cc: "" <> 
>Sent: Tuesday, 26 February 2013 6:14 PM
>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,
>> -----Original Message-----
>> From: []
>> Sent: Monday, February 25, 2013 5:52 PM
>> To: Liubing (Leo)
>> Cc:
>> 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:
>> 01.txt
>> Status:
>> Htmlized:
>> Diff:
>> 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
>Administrative Requests: