Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 09 November 2017 19:42 UTC
Return-Path: <brian.e.carpenter@gmail.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 E8486129B09 for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2017 11:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 N5Dnj25nrYel for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2017 11:42:00 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 6594B129AEA for <v6ops@ietf.org>; Thu, 9 Nov 2017 11:41:57 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id s11so62290pgc.5 for <v6ops@ietf.org>; Thu, 09 Nov 2017 11:41:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=okylOGxxhzbYAobZh2G/cNdBYbOGiK8HJlvpSuSGUZY=; b=TSQnAviay5RlOF1L6XBc5HZ589+p0G0r/lT3YWf1N6cm1KfUFqqUnka6gHMdgeHvsn iKBbjD0RCf2rNE2+zkVrQlBwY3q4C74i255kpLLzQyIv3hqANf9eVkPg0nmepNslFTxC +vxmES2JhyzGv37Jtnm323reAXAllZCD98rZ+CbEe54ZTT6aFdiwcL1t4wv1ykyUxOcF vHaJ1tjgablo/KSmW12YKnKOJQvgCBLcc9QK8/zDXgtsdmR3MZfnuLFjgj2kybAxU2Ls CkCBPmHgS+i8+S5BRvX2Anemw8xiqOVNkVdkfGEe2dt6lDuP1FZNgu1X1BBOWV2abwON BGeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=okylOGxxhzbYAobZh2G/cNdBYbOGiK8HJlvpSuSGUZY=; b=TZNR4LqPAqOI2VLJG7R2FNpT3NyWwBAIMZvuHF4C/7HItpeZKqNb9VqEb6Suf1Fs8E GEYjdIJybzu0716dOUM17vAWhxin/An1NF6BTLkhOORiF1fDdek7bULjMBAA/h6Qh50o Oqzcjez0QxxcMvZbwtSbbfHK37EYSvFHi3Il8TIL/yXnAYSfrybUIAb7PoHVK68eq/eT 6iybAa7HvTRjAlOZ3a0IlJKwHAeRC+hJH1jrY2A385k1WSBTeSxSdGALPPLkPWY63Yqh e7Yi+fuSDsXDvJD3tSuCQuWddTp3aP/vHwCa4kY06/IZ/fujfUdmf832QaMA5H0imziR nO9g==
X-Gm-Message-State: AJaThX5DrBFBkUhwNuN6LGv+s5QlXfuMr9nV0iejuJFGxINK3YA6oRxu h5weE21GGnSaGoonThb1kfjCCA==
X-Google-Smtp-Source: ABhQp+SWpdJcTLfy/7DpcOAX23vYEfGGw/ZRBefc2tiKs1J0QhBVK3sDofiasIbxB9Gd6SW4ZXVcXg==
X-Received: by 10.101.64.4 with SMTP id f4mr1436052pgp.301.1510256516406; Thu, 09 Nov 2017 11:41:56 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 132sm9003204pga.80.2017.11.09.11.41.54 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 11:41:55 -0800 (PST)
To: v6ops@ietf.org
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>
Date: Fri, 10 Nov 2017 08:42:00 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/BnvlGW8weEp9qAXZacua1FqS-cI>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 09 Nov 2017 19:42:03 -0000
On 10/11/2017 06:48, Fernando Gont wrote: > On 11/08/2017 11:58 PM, Lorenzo Colitti wrote: >> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont <fgont@si6networks.com >> <mailto:fgont@si6networks.com>> wrote: >> >> While reviewing this document a few days ago, I found that Section 4 >> (page 5) contains what is a protocol spec, rather than an operational >> BCP. It contains rules regarding how to set the link-layer address (to a >> unicast address) for IPv6 multicasted RAs, and how a SLAAC router should >> now remember which prefix has been "leased" to which node -- something >> that seems to be way outside of the v6ops charter, and that should have >> been done in 6man, instead. >> >> >> 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. No. It's more subtle than that. We are talking about sending packets with a LL multicast destination address to a unicast LL address. The packets are not in fact multicasted, although the recipient will in fact receive them on a multicast socket. Again I ask, so what? It may be different from what we thought of in 1998, but I simply don't see why it's problematic. > 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. Actually RFC6085 also says: " This document extends this mapping to explicitly allow for a mapping of an IPv6 packet with a multicast destination address into an Ethernet link- layer unicast address, when it is clear that only one address is relevant." That seems to apply perfectly here. > There's nothing in RFC4862 that may suggest "leasing one prefix per > node". No. That is the operational innovation in the present draft. > In fact, all nodes share all the prefixes being announced. All nodes that receive the announcement share it. In this operational mode, only one node receives it. Again, what's the problem? > And > when you don't want multiple nodes to share them, you just segment the > network one way or another. From the point of view of SLAAC, there's no > "one prefix per node". If it happens, it's because you segmented the > network, not because SLAAC is meant for that. Yes, effectively this draft does segment the LAN from a logical viewpoint. Why is that a problem? > > > >> Looking at diffs, it seems this additional text was incorporated very >> recently, in version -09 of the I-D, published in mid September >> (<https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt >> <https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt>>). >> It seems to be that this change is way beyond what the authors >> originally proposed >> >> The additional text did not actually change this practice at all.> It >> simply clarified what has always been a fundamental premise of this >> operational practice: if you want to give each host its own prefix, you >> need to ensure that the RA with that prefix is only received by that host. > > If you want to give each host it's own prefix, you do prefix delegation. > So far, SLAAC doesn't do prefix delegation. If you want to do prefix > delegation in slaac, write a std track document in 6man, not a BCP in > v6ops. That would be a more complicated way of getting the same result. >> 1) The protocol spec specified in this document requires the SLAAC >> router to keep state of the "leased" prefixes -- what seems a major >> change to SLAAC, which now would be kind of as stateful as DHCPv6. >> >> This is a bizarre claim. The first-hop router must always have fully >> up-to-date state on all the prefixes it is sending RAs for, otherwise it >> cannot fulfill its fundamental purpose of forwarding traffic to those >> prefixes. The word "stateless" in SLAAC applies to addresses configured >> to the host, not how routers route traffic. > > A SLAAC router need not maintain any sort of dynamic mapping. It's > static configuration information of the sort "I'm announcing this prefix > on this interface".. If you think otherwise, please point me the section > in RFC4862 where this conceptual data structure is mentioned. (Note: > Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861). Sure. The implementation will need a data structure per host, not per interface. Any way of handing out prefixes needs that. Why should I care? > > > >> 2) There are scenarios in which multiple nodes might receive the same >> packet -- say a NIC let's the packet through because it is in >> promiscuous mode -- wich could possibly lead to two nodes configuring >> the same prefix. >> >> Why do you say promiscuous mode is a problem? Even in promiscuous mode, >> network stacks already understand which packets are being send to the >> host network stack and which are not. For example, in the linux >> networking stack, well before the packet ever gets to the ICMPv6 >> protocol handlers that would process incoming RAs, ipv6_rcv does: >> >> if (skb->pkt_type == PACKET_OTHERHOST) { >> kfree_skb(skb); >> return NET_RX_DROP; >> } > > Great that Linux double-checks this. But it need not. Linux is just one > implementation. A very popular one. But one implementation. > > > > >> 3) What happens if the SLAAC router crashes and reboots, loosing state >> of the "leased" prefixes? >> >> You seem to be assuming that the router does not store the prefixes in >> stable storage. > > Routers store configuration info, not dynamic mappings. I think that depends on the router. Configs are not static in the general case anyway. > > Simple scenario: > > With slaac, the network is 100% resilient if a rotuer crashes and > reboots (because, as the name implies, it is stateless). With this > protocol you are specifying in this document, if the router crashes and > reboots, the network may just break -- same prefix may be reassigned to > different nodes, etc. > > > >> It's certainly the case that if you want this scheme to >> work across router crashes, then you need to ensure that the prefixes >> are stored somewhere. That sort of seems self-evident, but we could add >> it to the text. > > SLAAC stores *configuration information*. This protocol that you are > specifying requires SLAAC to store the *dynamic mappings* of which > prefix was "leased" to which host. And the fact that you need this for > this mechanism to work is an indication that you are specifying a > protocol. (Call it Stateful SLAAC, or AAC ;-) ) > > An operational practice is when you fiddle with the knobs that a > protocol gives you. Here you are introducing a state machine into SLAAC. > That's certainly not an operational practice, but rather a fundamental > change to SLAAC that makes it a stateful protocol It's not in SLAAC. It's almost certainly a layer above SLAAC. Brian > > > >> 4) How are prefixes selected? And, what's the minimum size of the pool >> of prefixes for the selection algorithm not to break due two "prefix >> collisions"? Does the selection algorithm have any specific properties? >> >> I see no reason why this should be in scope for this document. > > Actually, what's not in the scope of this document, and not within v6ops > charter, is the protocol you are specifying to handle prefixes with SLAAC. > > Thanks, >
- [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-i… Fernando Gont
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Erik Kline
- 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… Templin, Fred L
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Brian E Carpenter
- 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: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Brian E Carpenter
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Dae Young Kim
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fred Baker
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Fred Baker
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Joe Touch
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… 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: [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… 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… 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… 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
- [v6ops] DHCPv6 PD route injection (was: Re: 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] DHCPv6 PD route injection Alexandre Petrescu
- 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 Mikael Abrahamsson
- Re: [v6ops] DHCPv6 PD route injection (was: Re: S… Brzozowski, John
- Re: [v6ops] DHCPv6 PD route injection Alexandre Petrescu
- [v6ops] Upleveling discussion (was Re: Stateful S… Suresh Krishnan
- Re: [v6ops] DHCPv6 PD route injection Mikael Abrahamsson
- Re: [v6ops] DHCPv6 PD route injection Alexandre Petrescu
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… Lorenzo Colitti
- Re: [v6ops] DHCPv6 PD route injection Mikael Abrahamsson
- Re: [v6ops] DHCPv6 PD route injection Alexandre Petrescu
- Re: [v6ops] DHCPv6 PD route injection Mikael Abrahamsson
- Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-uniq… DY Kim
- Re: [v6ops] Upleveling discussion (was Re: 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: [v6ops] Upleveling discussion (was Re: Statef… james woodyatt
- Re: [v6ops] Upleveling discussion (was Re: Statef… Gert Doering
- Re: [v6ops] Upleveling discussion (was Re: Statef… Fernando Gont