Re: Forwarding Packets With Link Local Destination Addresses

Fred Baker <> Thu, 07 January 2021 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAFF63A0A3B for <>; Thu, 7 Jan 2021 10:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nMLCGm2C5DCw for <>; Thu, 7 Jan 2021 10:45:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF4B53A0A1E for <>; Thu, 7 Jan 2021 10:45:45 -0800 (PST)
Received: by with SMTP id x12so3998122plr.10 for <>; Thu, 07 Jan 2021 10:45:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1IxXAo9YRB2jAcH+WtRodxrnDnEe/7G04CuDLnU6MSc=; b=iIs6IwZR/G3eC2wZ0gDs3jB6T5rd5rUN2Q+LRL84yr6VG+k1MOzJLPE+6ccVFxvq5k 7zWDGv4JBcMx2hzm/591gdlfGSgFXYl79T1O14w60Ioj44p8DqDIrVdjRyCaBx8cEJF2 poDnXNABaWXBoUYq9rScSPTQxXmPlQPA1LPMUrtrH2Jv+Qp2PesIh9Wj2BGk/rLNTc+x skgVTA+UOXKgeDy7W4mKUwuKECHgCk3tJxYO+++MB2BUeI0b3dC8IuWN5S+9icI9sGOQ KCIfonkIkMbtsrbRNGM/dCNbgdsQn6N8k/3BtzgZqILBxewG6W1vtVPGaazDCM+9+Us4 qcvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1IxXAo9YRB2jAcH+WtRodxrnDnEe/7G04CuDLnU6MSc=; b=Rq6rvaDQPK5H+BzmdwU2G+RWv0UHLYx/d3Y3jcu6hnVHa07RBzXEauykm/KECcC6AM abjBnLrzlSEQxWgddZPtoJauWiZ+ox6mqNu5mSZwz48j48V3LZ3KtjjN+5ZLzxfQ5Kzn 6IXhsklb6Wh/i6GdKRxTDhFPfhvkacjOnCLszu59VAoXHy97BVBboQR2Sv9mbx+OEu8n Z9HlpKaHnYPgj4pCzPjGJc3I6HRtSigT0bBFgCexpBXCtUD4zuCHNFGOy36ebgFT8LqJ +NlXw2W6CsUcu27A0qKRizIn97ldXA2Pf7RnHUSo8JaKe9IOjuQeaMK3qj0b6fLcjRHQ 5pyw==
X-Gm-Message-State: AOAM533uEFqUXwhCMiZGGf+6KP46nMg3rlcTYX7gL3Xa7e7rGRA5R0jN TuWEwYfdendRfnwLHSkrgPg=
X-Google-Smtp-Source: ABdhPJw2CBUGkGG9Xia5Y3Tcg254/gHzdgW3Ij4tC4D896Swdy7bUAoLGShegqSCqrDT8kGmGPj55w==
X-Received: by 2002:a17:902:6807:b029:db:f60f:52f7 with SMTP id h7-20020a1709026807b02900dbf60f52f7mr234193plk.54.1610045145303; Thu, 07 Jan 2021 10:45:45 -0800 (PST)
Received: from ?IPv6:2600:8802:5800:567::1022? ([2600:8802:5800:567::1022]) by with ESMTPSA id g202sm6364535pfb.196.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 10:45:44 -0800 (PST)
From: Fred Baker <>
X-Google-Original-From: Fred Baker <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Forwarding Packets With Link Local Destination Addresses
Date: Thu, 7 Jan 2021 10:45:43 -0800
Message-Id: <>
References: <>
In-Reply-To: <>
To: Ron Bonica <>
X-Mailer: iPad Mail (18D5030e)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2021 18:45:47 -0000

On Jan 7, 2021, at 9:54 AM, Ron Bonica <> wrote:
> According to RFC 4291, “routers must not forward any packets with Link-Local source or destination addresses to other links”.

This, of course, imposes a requirement that no routers I’m aware of carry out absent explicit configuration, which is to make a forwarding decision (in this case a filter) based on the source address. Reverse forwarding lookups *might* accomplish this by associating link local addresses with the interface the packet it was received on, but that would only happen if reverse address lookups (normally associated with BCP 38) were enabled. 

So one could argue that RFC 4291 goes beyond its remit in this regard.