Re: <draft-ietf-6man-rfc4291bis-09.txt>

james woodyatt <jhw@google.com> Mon, 24 July 2017 18:03 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 6361F129B55 for <ipv6@ietfa.amsl.com>; Mon, 24 Jul 2017 11:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 J4byrafANzuX for <ipv6@ietfa.amsl.com>; Mon, 24 Jul 2017 11:03:00 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 58FBB129B19 for <ipv6@ietf.org>; Mon, 24 Jul 2017 11:03:00 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id g14so11396337pgu.0 for <ipv6@ietf.org>; Mon, 24 Jul 2017 11:03:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=P8DML9lUfkMHDkEGQ6EeSkwYiSlR/hbfbWy5pSadbGc=; b=lC6IwvtFrbglpdT2uuw8Ss3md439TsC9H5VVgBFridMnyWBijqyU0yEDl9tUKGteg0 Gsw+vgdyrJGo8O+0ftsuXVos1Zexq+g3lf9JYui467hCpWKvEOgGJef+xqMfHWYiEp9o z0gO25pYeSA8ECYmtLg7crgwwq2N8aD2jgqIprLrE2xUQ3t55hUphHscVpxbHa/j+7ne iM5soUYueK8IgSlykCGq0YXzF7iN+NwmudNIsKvPdX7lpz1MfVFevLHLJM/wiTalvg4/ x/DNzZ9URoyKyvTwpUfbCnBD/L93ws+VGQdpSQsE4I3wcDCkdJ1suSvzRJaBoDPP4CJY eNqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=P8DML9lUfkMHDkEGQ6EeSkwYiSlR/hbfbWy5pSadbGc=; b=EmpMbnzT8JldYh5fdqMhA6+U6eD9OZbWPbVowJ96hPVrCVgmmx1PyEgqDNAOBzG396 wVavAFKbTwqwaynicBXbPL3ENWBNY4be8D1H3QJulCzlfDOPphixW5SYCakale6q9AfZ UL0foS7iJmXfgDj9T4h5GJsJ2g1STkvzB38KwovSLetiZRJSsbt0Gx1OpTYAQAAop+G4 eSgCW9AbJ2Kl6xu9/g6QZsEZtduuZulL/MfDiLqFOONM5e1VhKnqO6EpTsJeYgfjjbYX zqM69zdzzTBRZxDo2/u8qdg06ZGmOEUI8oINEPmWTWC1+c/do05LKg8VYKSi1CvaVeNC aafw==
X-Gm-Message-State: AIVw111ysShZ2XAbT7y/DzRPf1+brOXCXu8kBSr1FmTVFLFmQgyiGtTx H6Dihu+NmCDTDkafpOrmog==
X-Received: by 10.84.137.3 with SMTP id 3mr18544517plm.319.1500919379552; Mon, 24 Jul 2017 11:02:59 -0700 (PDT)
Received: from ?IPv6:2620::10e7:10:e1af:98b2:35d1:ff60? ([2620:0:10e7:10:e1af:98b2:35d1:ff60]) by smtp.gmail.com with ESMTPSA id y22sm22524322pfi.159.2017.07.24.11.02.58 for <ipv6@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 11:02:58 -0700 (PDT)
From: james woodyatt <jhw@google.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_1D762CE3-A581-4283-BDA4-C019187A05EB"
X-Priority: 3
Subject: Re: <draft-ietf-6man-rfc4291bis-09.txt>
Date: Mon, 24 Jul 2017 20:02:57 +0200
References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <CAKD1Yr0Bt4hhBvtSVWrLpns4odzek3U5WJkuQoS1NGsPozW0sg@mail.gmail.com> <CAN-Dau3vVREsYc4Y6AAdDpLKsMjwH_2saS7JTn8P6fRDXRKV7Q@mail.gmail.com> <CD9ED408-9574-4DBC-ADE7-C9D4FD5CB52E@google.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> <345495C4-030E-41FA-98CD-B403509B9402@google.com> <CAN-Dau2CEMEebYhMT6NKFfYOTeos48SoUG2EixApN6dw=NiTxg@mail.gmail.com> <010901d30459$794a76c0$4001a8c0@gateway.2wire.net>
To: IPv6 List <ipv6@ietf.org>
In-Reply-To: <010901d30459$794a76c0$4001a8c0@gateway.2wire.net>
Message-Id: <80A571CE-9E91-45E1-A453-1780B512BF00@google.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9ck8s1pI-h7OCIsrFM05AWX_m0g>
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: Mon, 24 Jul 2017 18:03:02 -0000

On Jul 24, 2017, at 10:47, t.petch <ietfc@btconnect.com> wrote:
> 
> I think I'd prefer to call the righthand side of both a subnet prefix and a on-link prefix an interface identifier, because in both case it is a node’s interface that is being identified.  Then generically they are interface identifiers, if you are referring to a specific aspect it is qualified with the aspect.

Here is the reason I can’t do that: the fact a destination address has an on-link prefix does not, in fact, identify a destination at a node on that link. For one, it may be an anycast address. However, even if it’s a unicast address, it may— in practice, if not in standard theory— identify a destination on a node that in reality is attached to a completely different link.

An important exception, with which I find myself increasingly concerned these days, is the case where a 6LBR is sharing the subnet prefix advertised in PIO by a CE router, preferably, with plen=64, L=1 and A=1, naturally, and proposals to make plen>64 + L=1 into BCP is worrisome accordingly— and providing reachability at global scope addresses to nodes on another link by proxying ND. In this case, the CE router sends inbound packets to the 6LBR which retransmits them to the destination on its 6LO interface only if it has a host route and a ND proxy binding.

In that scenario, to say that the part of the IPv6 address that follows the on-link prefix, which‚ let me repeat, is really a routing prefix and its address configuration operational semantics are completely orthogonal to this discussion, identifies the interface on the 6LBR node and not the real destination address at the downstream 6LO node's interface, is to make a technical distinction in the context of forwarding and routing without any good purpose.

For that reason, I’d prefer not to use “interface identifier” for the part of a unicast address that follows a routing prefix, particularly the part the follows the routing prefix advertised in RA message PIO elements with A=0 and L=1.


--james woodyatt <jhw@google.com <mailto:jhw@google.com>>