Re: I-D Action: draft-smith-6man-link-locals-off-link-00.txt

Mark Smith <markzzzsmith@gmail.com> Sat, 22 August 2015 00:04 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C191B29BB for <ipv6@ietfa.amsl.com>; Fri, 21 Aug 2015 17:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=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 9_fnIUPrDa_l for <ipv6@ietfa.amsl.com>; Fri, 21 Aug 2015 17:04:13 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 05CD01B29B9 for <ipv6@ietf.org>; Fri, 21 Aug 2015 17:04:13 -0700 (PDT)
Received: by iods203 with SMTP id s203so98420862iod.0 for <ipv6@ietf.org>; Fri, 21 Aug 2015 17:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zOO9lqQn84UiDuz2Yc8j9c5c4JnHDjY+eC/sWtWgAFk=; b=TCLRyEk2WS369G4pwo/XxVWvO6IZWos82tHWrlJKG+PxnFtU2wDoM1Vjs659wdgPQA 4WJlZIMRDqnFaTvQgKNb6/PyVHNtr6K36b5G+/cJFLibD2RSYHk6J7m2pyVA7yqU1R0B blWGr5JPjklyl16CE2HqRbEqM2K8NfdEGnKqBS3VDa6wlzPfXjCDUCdwInOytXofJpA/ 94Z3zJPKsjD8QrYyPuQVSXb9V/YeqNxIxMhZ2obkRtxab80KyFG6D9ZDgY+2SIVNAnmI 4BQouVbwZbyo++0m7F4XxKyppwDfLkMi6Ir+Zlh/aE2UmnfjPpZUzL/JCEKLQxslshPG dGuA==
X-Received: by 10.107.170.139 with SMTP id g11mr8977955ioj.85.1440201852321; Fri, 21 Aug 2015 17:04:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.141.21 with HTTP; Fri, 21 Aug 2015 17:03:42 -0700 (PDT)
In-Reply-To: <91C53FF9-70C4-4673-9ECA-5DE7C292D3E1@gmail.com>
References: <20150816123509.23625.7953.idtracker@ietfa.amsl.com> <55D3E7E6.7000505@gmail.com> <CAO42Z2y4im1dMc7Zvos9oBLL0xh7E-dF58xfMQJY6XhvZtN=Ww@mail.gmail.com> <E3F33DB1-65F3-4DBC-A4BB-C96EA4587E34@gmail.com> <CAO42Z2zBA3yP8znTq1Z-xv-UAc2nE-MdJVaZ0-D8BCb4PxihpA@mail.gmail.com> <91C53FF9-70C4-4673-9ECA-5DE7C292D3E1@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 22 Aug 2015 10:03:42 +1000
Message-ID: <CAO42Z2xgWoe85gjY=tAaMLPTAxyN4QjV1wrOC3fBKF4X=9-icg@mail.gmail.com>
Subject: Re: I-D Action: draft-smith-6man-link-locals-off-link-00.txt
To: Dennis Ferguson <dennis.c.ferguson@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/8Ud70VRuRigjZoIypaMGKao8F9I>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 22 Aug 2015 00:04:14 -0000

Hi Dennis,

On 22 August 2015 at 01:09, Dennis Ferguson <dennis.c.ferguson@gmail.com> wrote:
> Mark,
>
> On 20 Aug, 2015, at 03:02 , Mark Smith <markzzzsmith@gmail.com> wrote:
>> What I'm really taking about is whether a host can reach a link local destination attached to the same link instance directly.
>
> Here's the definition of "link" from RFC2460:
>
>    link        - a communication facility or medium over which nodes can
>                  communicate at the link layer, i.e., the layer
>                  immediately below IPv6.  Examples are Ethernets (simple
>                  or bridged); PPP links; X.25, Frame Relay, or ATM
>                  networks; and internet (or higher) layer "tunnels",
>                  such as tunnels over IPv4 or IPv6 itself.
>
> Given this I think your statement of the problem is really difficult to parse.
> Hosts attached to the same link can communicate directly at the link layer.
> Hosts that can't communicate directly at the link layer are not attached to
> the same link.
>  Link local addresses may only be used to communicate with
> nodes attached to the same link which, by definition, can be reached directly
> at the link layer.
>

Here's a definition from RFC4861 that describes the characteristics of
a CBMA-type link from the perspective of IPv6 neighbor reachability.

   shared media   - a link that allows direct communication among a
                    number of nodes, but attached nodes are configured
                    in such a way that they do not have complete prefix
                    information for all on-link destinations.  That is,
                    at the IP level, nodes on the same link may not know
                    that they are neighbors; by default, they
                    communicate through a router.  Examples are large
                    (switched) public data networks such as Switched
                    Multimegabit Data Service (SMDS) and Broadband
                    Integrated Services Digital Network (B-ISDN).  Also
                    known as "large clouds".  See [SH-MEDIA].


Note, "That is, at the IP level, nodes on the same link may not know
that they are neighbors; by default, they communicate through a
router."

This is what allows GUAs and ULAs to work over a CBMA link if the
L-bit is switched off for their PIOs. The trouble is that currently it
isn't possible for Link-Local's to be used over 'shared media' links
with CMBA reachability limitations, because hosts always consider LL
destinations to be "on-link" (per RFC5942).

It seems really inconsistent to me that GUAs and ULAs will work over
these types of links by default (due to the default "off-link"
assumption for those prefixes), where as LLs won't, but more
importantly, LLs can't be made to work even if desired, despite LLs
being a more preferred address type to use vs. GUA/ULAs, as per the
IPv6 address selection rules.

I'm fine with security being a reason to limit this reachability.
However, I think the absoluteness of the LLs not and currently never
working over CBMA type links should be changed, allowing more granular
security to be applied to LL traffic over CBMA links if desired.

Regards,
Mark.

> If you restrict the link layer connectivity of a host you have unavoidably
> restricted the scope of the link to which it is attached to the neighbors it
> can still reach directly at the link layer.   If a host thinks it should be
> able to reach a link local destination that it cannot communicate with at
> the (restricted) link layer you have a problem, but it is not a problem you
> can fix with a router.  You instead need to fix whatever it is that lead the
> host to think that would work.
>
> This is why the question of how the host came to know the off-link link local
> address is exactly on target; the answer would reveal what needs to be
> fixed.  I don't think you have answered this question yet.  If there is no
> answer to this there may be no problem to fix.
>
> Dennis Ferguson
>