Re: RFC4861 question - short prefixes in PIOs

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 27 June 2019 21:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 E903312023E; Thu, 27 Jun 2019 14:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LvhEefiAEDVi; Thu, 27 Jun 2019 14:40:36 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041511201C9; Thu, 27 Jun 2019 14:40:35 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 47C7638183; Thu, 27 Jun 2019 17:38:49 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 899BF61; Thu, 27 Jun 2019 17:40:34 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
cc: v6ops list <v6ops@ietf.org>, 6man <6man@ietf.org>
Subject: Re: RFC4861 question - short prefixes in PIOs
In-Reply-To: <729f46ec4a8b419797e15bbdcac3e549@boeing.com>
References: <729f46ec4a8b419797e15bbdcac3e549@boeing.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 27 Jun 2019 17:40:34 -0400
Message-ID: <4615.1561671634@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GLRmSx1BXdQraRBGeoCli37j_VI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 27 Jun 2019 21:40:38 -0000

Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
    > 3) If the PIO instead has L=0, does it mean that 2001:db8::/32 is
    > “associated” with the link but not necessarily “on-link”?

As others have said, and I find the RFC rather obtuse in this way, I think
that only thing one can say is that if L=1, then devices in that indicated
PIO can be found using ND (appropriately multicast).

I think that when it is associated with the link, one can use SLAAC to assign
interfaces, but can't use ND to find neighbours.

Hairpin'ing all traffic through the advertising router when L=0 seems like
the only general solution.  But, I can imagine many situations where if a
Neighbour Cache entry somehow existed, then it could be used.

I think that hairpin'ing all traffic has many interesting uses when it comes
to providing firewalling (such as RFC8520) between devices.

    > 4) If yes to 3), does it mean that 2001:db8::/32 should be added to the
    > IPv6 forwarding table
    > as a “route-to-interface” with the receiving interface as the next hop?

I don't think so.
That would imply it was on-link, and L=0 means it isn't.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-