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 =-
- RFC4861 question - short prefixes in PIOs Templin (US), Fred L
- Re: [v6ops] RFC4861 question - short prefixes in … 神明達哉
- RE: [v6ops] RFC4861 question - short prefixes in … Templin (US), Fred L
- RE: [v6ops] RFC4861 question - short prefixes in … Dave Thaler
- Re: [v6ops] RFC4861 question - short prefixes in … David Farmer
- RE: [v6ops] RFC4861 question - short prefixes in … Templin (US), Fred L
- RE: [v6ops] RFC4861 question - short prefixes in … Templin (US), Fred L
- RE: [v6ops] RFC4861 question - short prefixes in … Dave Thaler
- Re: [v6ops] RFC4861 question - short prefixes in … David Farmer
- Re: [v6ops] RFC4861 question - short prefixes in … Brian E Carpenter
- Re: [v6ops] RFC4861 question - short prefixes in … Mark Smith
- Re: [v6ops] RFC4861 question - short prefixes in … Alexandre Petrescu
- Re: [v6ops] RFC4861 question - short prefixes in … Mark Smith
- Re: RFC4861 question - short prefixes in PIOs Michael Richardson
- Re: RFC4861 question - short prefixes in PIOs Mark Smith
- Re: [v6ops] RFC4861 question - short prefixes in … Alexandre Petrescu
- Re: [v6ops] RFC4861 question - short prefixes in … Philip Homburg
- Re: [v6ops] RFC4861 question - short prefixes in … Mark Smith
- Re: [v6ops] RFC4861 question - short prefixes in … Pascal Thubert (pthubert)