Re: Forwarding Packets With Link Local Destination Addresses

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 07 January 2021 19:05 UTC

Return-Path: <alexandre.petrescu@gmail.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 017813A0ADF for <ipv6@ietfa.amsl.com>; Thu, 7 Jan 2021 11:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 R4at20vVi-Rz for <ipv6@ietfa.amsl.com>; Thu, 7 Jan 2021 11:05:49 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 5AEE13A0AA7 for <ipv6@ietf.org>; Thu, 7 Jan 2021 11:05:49 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 107J5l5s000995 for <ipv6@ietf.org>; Thu, 7 Jan 2021 20:05:47 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A353A20CF32 for <ipv6@ietf.org>; Thu, 7 Jan 2021 20:05:47 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 98CB620CE7C for <ipv6@ietf.org>; Thu, 7 Jan 2021 20:05:47 +0100 (CET)
Received: from [10.14.1.83] ([10.14.1.83]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 107J5lAg027324 for <ipv6@ietf.org>; Thu, 7 Jan 2021 20:05:47 +0100
Subject: Re: Forwarding Packets With Link Local Destination Addresses
To: ipv6@ietf.org
References: <DM6PR05MB6348A18046C5DDC7CF2AED76AEAF0@DM6PR05MB6348.namprd05.prod.outlook.com> <CAJE_bqdYv1uO7fZjG8hvD7Zf=f_TL6zH0bcgxxzxHG1ZkA8XGw@mail.gmail.com> <DM6PR05MB634852C42F4CCDBFA137EAE2AEAF0@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <5cf537dc-b7e8-7de9-f461-26a25b5d31fe@gmail.com>
Date: Thu, 07 Jan 2021 20:05:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <DM6PR05MB634852C42F4CCDBFA137EAE2AEAF0@DM6PR05MB6348.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gnvDaOQ93P2OZ77fwBS_JIEJ_WA>
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, 07 Jan 2021 19:05:51 -0000


Le 07/01/2021 à 19:24, Ron Bonica a écrit :
> Jinmei,
> 
> Thanks! I think that the following text from RFC 4007 covers the
> issue:
> 
> "   A node that receives a packet addressed to itself and containing
> a Routing Header with more than zero Segments Left (Section 4.4 of
> [3]) first checks the scope of the next address in the Routing
> Header.  If the scope of the next address is smaller than the scope
> of the original destination address, the node MUST discard the
> packet. "

Are scopes bigger one than another?

In multicast that may be true, but in unicast it's hard to say a scope
might be smaller or bigger than another scope.

In unicast, there might be only two scopes: LL and global.  It might be
that there is no inclusion from one into another, or it might be that a
size comparison might not be possible.

Intuitively, one might consider that LL scope to be smaller than Global
scope, because of the reach.  But knowing that each iface must have an
LL address whereas not all ifaces have a Global address it might be that
the number of assigned LL addresses is larger than the number of
assigned Global addresses at one point in time.  In that sense, it might
be that the set of LL addresses is much larger (bigger) than the set of
Global addresses.

That is one reason that is hard to implement the paragraph cited in the
beginning of this message.

There is no number in an address that says 'scope', and that could be
used to compare two addresses, and to decide that one address is of a
larger scope than another.

Alex

> 
> Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message----- From: 神明達哉 <jinmei@wide.ad.jp> Sent:
> Thursday, January 7, 2021 1:09 PM To: Ron Bonica
> <rbonica@juniper.net> Cc: 6man@ietf.org Subject: Re: Forwarding
> Packets With Link Local Destination Addresses
> 
> [External Email. Be cautious of content]
> 
> 
> At Thu, 7 Jan 2021 17:53:51 +0000, Ron Bonica
> <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> 
>> According to RFC 4291, "routers must not forward any packets with
>> Link-Local source or destination addresses to other links".
>> 
>> I interpret this statement to include packets that contain routing
>> headers. For example, it forbids an SRv6 packet whose final segment
>> has a locator that begins with FE80.
>> 
>> Does everyone share this interpretation? If so, do RFC 4291 or RFC
>> 8200 make this sufficiently clear?
> 
> I believe Section 9 of RFC4007 answers the question.  In short,
> you're *basically* correct.
> 
> I said *basically* because there can be an exception that makes it
> legitimate, but I suspect that usually doesn't apply in practice.
> 
> -- jinmei 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>