RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 09 November 2017 18:19 UTC

Return-Path: <Fred.L.Templin@boeing.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 023F2129426; Thu, 9 Nov 2017 10:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8e_AC39ctLfK; Thu, 9 Nov 2017 10:19:44 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE19F129404; Thu, 9 Nov 2017 10:19:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vA9IJhlx010208; Thu, 9 Nov 2017 11:19:43 -0700
Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vA9IJYHv010120 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 9 Nov 2017 11:19:34 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 9 Nov 2017 10:19:33 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 9 Nov 2017 10:19:33 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Fernando Gont <fgont@si6networks.com>, Lorenzo Colitti <lorenzo@google.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>
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTWYLPF0lutU7PtESjw8Zn8vPUPqMMWk3Q
Date: Thu, 9 Nov 2017 18:19:33 +0000
Message-ID: <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.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>
In-Reply-To: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OG9erAC5ZPWdsz3KUTO4BVqbT5Y>
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 18:19:46 -0000

> > 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). 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?

Thanks - Fred