Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
james woodyatt <jhw@google.com> Thu, 09 November 2017 23:01 UTC
Return-Path: <jhw@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D593D1279EB for <ipv6@ietfa.amsl.com>; Thu, 9 Nov 2017 15:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXFnIby7O4xj for <ipv6@ietfa.amsl.com>; Thu, 9 Nov 2017 15:01:21 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628A9126C2F for <6man@ietf.org>; Thu, 9 Nov 2017 15:01:18 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id y75so6745073ywg.0 for <6man@ietf.org>; Thu, 09 Nov 2017 15:01:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=haqRjcUVjfn5CO4mMFdvjE/eXCgMds67v07xi8sfDM4=; b=hs9wN0BOahqRV7qLxHzzJPYm+Tl4+XZebzJsvlHvd4PI7fOOf66MGCC7vrOaQZ+A3O xg1/sZbMdHzemnPWjwTGEj5MOuivrRDe268/yO6UWmhapQKb/shee9I+PbCZhG9mgOvq NGteuWJaO8u1imr2mnMaMWhvh/ycFWhVJJskhCfQQprIj3ljgTiKsUhr58QY+n/t5HS1 w6QeYqRCxFvXn2ZN8x+nil+JmfPxZpu6IJcDyFJUXxD6xkshLcd7CC0aEXvZz/IiZK5R IAwks+g0lpFP42I8cQr6i7DOotJCl5Y+6tiligprAh2k0kDWoLLdikFdV2PW+VlowgCP ZVUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=haqRjcUVjfn5CO4mMFdvjE/eXCgMds67v07xi8sfDM4=; b=MyLMqQVM/MuqfhbAxGziDQFQN6LSeZF7hEsKUmmpitrU245DY2nkbFmzxtG5SXsXHp RxjgK+aiG6mPKnjfJbmo7/oWJsTOdESc+/yUS0sbYmAdfU/+tVrgmEo6UxuvwgLewYt6 8pTs7tK5UtZ/ArDiCajztmSZ73tLm29zftJcJ8mU6/Qr03Wc7BSgfMC9+vI5hjv/OBMA IJzpBZTNcUK1trM9O4s0uulPGyYF7gGWXqMyajJm2srDQKzRxL8dRVd5ddwxngGUGfY5 oyfL6oiFj7jC+5cBI5lG/gYh6NEUQIzdFZ5D3P8eeoFuW7qbRXONNuRQthRNK6yGJgjY c4WA==
X-Gm-Message-State: AJaThX4iOjKB71ykhQ7F/sjYc0+cNcLBFV/BQhSSTTpy8J8c2BHbIJmF V70WHJpFkfgj3LHvsJIaQZYeMw==
X-Google-Smtp-Source: ABhQp+TU9NsS1dl6OIdqA87GqCHvano/Goc52/XvPvMOnd1wFGpG+qW6g1z4xCrc8ZGTYN636Pmipg==
X-Received: by 10.129.76.194 with SMTP id z185mr1470157ywa.258.1510268477307; Thu, 09 Nov 2017 15:01:17 -0800 (PST)
Received: from [172.29.163.110] ([172.29.163.110]) by smtp.gmail.com with ESMTPSA id i207sm796667ywe.38.2017.11.09.15.01.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 15:01:16 -0800 (PST)
From: james woodyatt <jhw@google.com>
Message-Id: <DBE27830-1270-4FFA-8D1E-E97B234BEC45@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8079F2A4-00E6-4980-A58B-42DFE08E4429"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Thu, 09 Nov 2017 15:01:25 -0800
In-Reply-To: <10f7ae3d-1de0-d7fb-b5fb-fe7a609cbf05@gmail.com>
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" <v6ops-ads@ietf.org>, "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" <draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fernando Gont <fgont@si6networks.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com> <10f7ae3d-1de0-d7fb-b5fb-fe7a609cbf05@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZbaOaRBpnhe3VpPWaSvRDD-6d1Y>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2017 23:01:23 -0000
On Nov 9, 2017, at 12:36, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > On 10/11/2017 07:19, Templin, Fred L wrote: >>>> I don't see how this is a protocol change. Sending RAs unicast is >>>> already allowed by RFC 4861, so this is just an operational practice. >>> >>> That's incorrect. We are talking about sending multicasted internetlayer >>> packets to a unicast link-layer address. There's nothing in RFC4861 that >>> suggests you should do that. RFC6085 says "you shouldn't drop packets if >>> they are internet-layer multicast but link-layer unicast". But >>> certainly, unless a protocol spec says otherwise, the normal mapping >>> applies. >> >> On this point, I agree with Fernando. RFC4861 says that RAs can be unicast but >> that means unicast at both L2 and L3 (i.e., and not multicasted at L3). > > Who says that? As Fernando reminded us, RFC6085 says otherwise. > >> RFC5214 >> is an example of where both L2/L3 unicast are used in RAs in the spirit of RFC4861 . >> >> Is there some reason why the requirements of this draft cannot be satisfied >> by L3 unicast? > > Hosts listen for L3 multicast RAs. My answer to Fernando’s concern about this late addition to section 4 possibly moving this draft into the ambit of 6MAN. I don’t think it does. Here’s why. I don’t see the intent of RFC 6085 as to change the operational semantics of IPv6 multicast in the way that this draft sees it. When an IPv6 forwarding node sends a multicast packet with an Ethernet unicast address because the router knows that its group membership on the link comprises exactly one node… however, the RECEIVING node cannot be expected to share that knowledge. Therefore, when a host receives a multicast RA message in a unicast Ethernet frame, it cannot be expected to recognize that as a signal to indicate there are no other hosts on the link. Fortunately, this draft doesn’t violate that assumption of the protocol. The last paragraph of section 4 goes to this point: After the subscriber received the RA, and the associated flags, it will assign itself a 128 bit IPv6 address using SLAAC. Since the address is composed by the subscriber device itself, it will need to verify that the address is unique on the shared network. The subscriber will for that purpose, perform Duplicate Address Detection algorithm. This will occur for each address the UE attempts to utilize on the shared provider managed network. If the unicast address on the multicast RA message were to signal that the subscriber really is the only member of the all-hosts group on the link, then it would not be necessary for the host to perform Duplicate Address Detection (DAD), now would it? Of course, it has to perform DAD— how could it not do that? Imagine all the things that could break if it didn’t. Not mentioned in this draft (more is the pity) is that the provider router may send ND Redirect messages with a Target Address not in use by the subscriber host but still having the per-host unique prefix. Of course, in this scenario, the subscriber host cannot know that the prefix advertised in the RA message is a per-host unique prefix, so of course it’s then expected to process any ND Redirect messages it receives, and to update its Destination Cache according to RFC 4861 How could it not do that? Imagine all the things that could break if it didn’t. (I can imagine quite a lot, actually— I’m thinking of applications for this even now.) I was critical of this draft in V6OPS because I thought it didn’t make all of this sufficiently clear to the reader, but it was all pointed out to me on the list in subsequent discussions, and I seemed to be out of the rough consensus that it was necessary to clarify any of this stuff in the text, i.e. the fact that I initially misunderstood how this BCP is not actually a protocol specification should be no reason to believe that any ordinary reader might make the same mistake. Accordingly, because all of the protocol requirements about DAD and ND Redirect still hold despite all the diversionary text in the introduction about link-layer isolation, I’ve dropped my procedural objections to this draft. --james woodyatt <jhw@google.com <mailto:jhw@google.com>>
- Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-pref… Fernando Gont
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… DY Kim
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Brian E Carpenter
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Lorenzo Colitti
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Erik Kline
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Erik Kline
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Warren Kumari
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Fernando Gont
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Fernando Gont
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Templin, Fred L
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Brian E Carpenter
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Mark Smith
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… james woodyatt
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Lorenzo Colitti
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Fred Baker
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Fred Baker
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Joe Touch
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… joel jaeggli
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… David Farmer
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… james woodyatt
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Brian E Carpenter
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Joe Touch
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Joe Touch
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Joe Touch
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Warren Kumari
- Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-… Alexandre Petrescu
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Bob Hinden
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Nick Hilliard
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Erik Nordmark
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Bob Hinden
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Erik Nordmark
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DaeYoung KIM
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Brian E Carpenter
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Erik Nordmark
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Mark Smith
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Enno Rey
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Bernie Volz (volz)
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Nick Hilliard
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Victor Kuarsingh
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Victor Kuarsingh
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Victor Kuarsingh
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Victor Kuarsingh
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Victor Kuarsingh
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Michael H Lambert
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Philip Homburg
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… David Farmer
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Nick Hilliard
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Nick Hilliard
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Templin, Fred L
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… james woodyatt
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Mark Smith
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fred Baker
- DHCPv6 PD route injection (was: Re: [v6ops] State… Ole Troan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Ted Lemon
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… james woodyatt
- RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Suresh Krishnan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Warren Kumari
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fred Baker
- Re: [v6ops] DHCPv6 PD route injection (was: Re: S… Brzozowski, John
- Upleveling discussion (was Re: [v6ops] Stateful S… Suresh Krishnan
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: Upleveling discussion (was Re: [v6ops] Statef… Erik Nordmark
- Re: [v6ops] Upleveling discussion (was Re: Statef… Brian E Carpenter
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… David Farmer
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… David Farmer
- Re: Upleveling discussion (was Re: [v6ops] Statef… james woodyatt
- Re: [v6ops] Upleveling discussion (was Re: Statef… Gert Doering
- Re: Upleveling discussion (was Re: [v6ops] Statef… Fernando Gont