Re: IPv6 Link Local Addresses [was Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?]

Ole Troan <otroan@employees.org> Tue, 11 June 2019 08:43 UTC

Return-Path: <otroan@employees.org>
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 0D7C11200B1 for <ipv6@ietfa.amsl.com>; Tue, 11 Jun 2019 01:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 uqUon4du-R0R for <ipv6@ietfa.amsl.com>; Tue, 11 Jun 2019 01:43:49 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83227120047 for <ipv6@ietf.org>; Tue, 11 Jun 2019 01:43:49 -0700 (PDT)
Received: from astfgl.hanazo.no (77.18.55.224.tmi.telenormobil.no [77.18.55.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id E3606FECBED5; Tue, 11 Jun 2019 08:43:48 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 69E3217147CD; Tue, 11 Jun 2019 10:43:44 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: IPv6 Link Local Addresses [was Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?]
From: Ole Troan <otroan@employees.org>
In-Reply-To: <B3D43A45-5E90-4D04-BA64-17150EE6D2AA@gmail.com>
Date: Tue, 11 Jun 2019 10:43:44 +0200
Cc: Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0138C92A-A95A-488D-8851-9F3227D2B8B8@employees.org>
References: <DM6PR15MB2506E62560613C85F74A1FF8BB100@DM6PR15MB2506.namprd15.prod.outlook.com> <CALx6S36vVpD9bAPSBQmhV+daR0Yr4heQ-LaiB4hABAs8ofVfNQ@mail.gmail.com> <DM6PR15MB25063BAF058C1825E2B63E30BB130@DM6PR15MB2506.namprd15.prod.outlook.com> <CAKQ4NaW-QRZDO52zDZTSqz_MsfrS1uQHdz6zFjo+gXvtYVnFxA@mail.gmail.com> <DM6PR15MB2506E06165EA22E66BBB9524BB130@DM6PR15MB2506.namprd15.prod.outlook.com> <7E03089C-8429-4B56-96D6-441490C850B2@gmail.com> <B3D43A45-5E90-4D04-BA64-17150EE6D2AA@gmail.com>
To: Dennis Ferguson <dennis.c.ferguson@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OambbYh_zocX_Gn1nRUaEpyworc>
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: Tue, 11 Jun 2019 08:43:51 -0000

>> This means that link local addresses have a 10 bit prefix (1111111010) followed by 54 bits of zeros.  That is it, nothing more.   Address with different prefixes or with a 1111111010 prefix followed by non-zero 54 bits are not link local addresses.
>> 
>> This is not ambiguous.  
> 
> So if an application asks my implementation to send a packet addressed to fe80:1::1 out a particular link what should the implementation do with it? It seems like there are only 3 choices:
> 
>   1. Run ND on that link to see if it can find a neighbor there with that address to send the packet to.
> 
>   2. Send the packet to the current default router.
> 
>   3. Something else (what?).
> 
> I had though 1. was the answer since that is what is done with packets addressed to link-local unicast destinations (which is what that address is according to RFC4191 section 2.4), but that now seems to be ambiguous.

Let me illustrate with a typical per-interface FIB:

 fe80::/10 -> drop
 fe80::/64 -> glean
 fe80::abcd -> neighbor abcd

Cheers,
Ole