Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9

Mark Smith <> Wed, 08 March 2017 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CA00129468 for <>; Wed, 8 Mar 2017 02:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mE-bs4GKt5dJ for <>; Wed, 8 Mar 2017 02:08:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EA62127071 for <>; Wed, 8 Mar 2017 02:08:09 -0800 (PST)
Received: by with SMTP id t8so6705511vke.3 for <>; Wed, 08 Mar 2017 02:08:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xQY46JBfComnHIRklo+yhw1Yer8ZBiSSuqqGEkqbETo=; b=KGlMfbyAX+EDA5yWcOQy96QibXRZ0t4L+qggZ7H77ke0/6hIvRXsGah3mQrN7GW0v1 +oMYLo6vWGNaUoSWAEpn2gvWj2ysAoM/RUE0DYmoV8icOADLShm/GRlxOC5Ro3fhG7+d 2sE5Ful8C+9/ocyc/dw93EFP5Zck6fIef1YglC2c3Dzf+eKkqsu0lKXKkVwV/TDImoE0 N/gatJ0MLjyZOLYyQruKGOTpPIJsbnINqihMuDkja/Zt2H62YIwBGDFah3jqHbz8ra0P o9nyA8VrL2ElAdfC7qGf2URewsxEBDDBJezyo9s0zDEMdJqtnJ6uDKlcObisw/VVHqk2 KONg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xQY46JBfComnHIRklo+yhw1Yer8ZBiSSuqqGEkqbETo=; b=jUqQv3Ugcaic6K8WHg2+SodbPgvAYzTEe4OcjzsPUdndaYgRkNf3QDyMoyma+cuoog yS6RIigjwknj673uo9VrsuPq8n1jU2ialeT7qagiogtdF5F0P0kT+SDhBKxaVbF4o+DJ G9T2IUi4BiBwT9Ir4OLRi4ZZ4uxenlqtUN+GYd8yvkzKiyN2970jz9zHtSB/kJu2i+Jt tCMJD1wJPPXbzOeVCf0srDBWTx/UqfH4Hoa4lmd1UfGzVWN/1L3oAMkyNngTDjZRiM6E 7YOn0d2NY7STiEJiMgF6eZjQ7KkenAXMJFWxC5njH0Z4W1TqoVRM4pOiJ5yGz3En+pL0 Gr5A==
X-Gm-Message-State: AMke39lCyQtn3OPzXXZ9Qk2fdI8sSsWu3bDiVP5O0J+DiE3AT0w/wX4QlbTzWXrBA/3WZuz+5c+t9cVhhuXgsg==
X-Received: by with SMTP id l124mr3154939vke.123.1488967688641; Wed, 08 Mar 2017 02:08:08 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 8 Mar 2017 02:07:38 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Mark Smith <>
Date: Wed, 8 Mar 2017 21:07:38 +1100
Message-ID: <>
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9
To: Ole Troan <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: Alexandre Petrescu <>, 6man WG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Mar 2017 10:08:10 -0000

On 8 Mar. 2017 6:36 pm, <> wrote:


> > Thanks to this discussion, I would like to promote the following fact that I did not know:
> >
> > If you say "FE80::" without telling the prefix length, that actually means "FE80::/9" (and not FE80::/10, nor FE80::/64).  Because 0xFE80  is "1111 1110 1000 0000" in binary representation.
> No it doesn't.
> FE80:: means FE80:0000:0000:0000:0000:0000:0000:0000
> Or
> FE80:0000:0000:0000:0000:0000:0000:0000/128
> which is an address within the LL space.
> Possible a statement that a /128 is implied if no prefix length is stated, and is the definition of an "address", could be put in RFC4291bis during AUTH48? Is it a trivial enough change (I think it probably isn't, although it'd be a bit of a shame to have to wait until the next RFC revision of it.)

>I don't see why it would be necessary to imply anything.

I say implied, because when "FE80::" is written that way, it is saying
that for the purposes of IPv6 processing (what ever that processing
may be), all 128 bits are significant - the "/128" is implicit.
"FE80::/128" is also saying that, except that it is explicitly stating
that all 128 bits are significant.

>FE80:: is an address. Not a prefix.

If it isn't a prefix because it doesn't have "/128" on it, then that
is what makes it an "address". However, "FE80::/128" is an entirely
accurate and exact equivalent replacement for it, so functionally,
"FE80::" and "FE80::/128" are equal.

>E.g. you wouldn't say the packet was sent from the source FE80::/128.

You wouldn't say it, but you could say it, it would be correct.

Here's an example of their equivalence.

I assign an IPv6 address to an interface under Linux, and it shows it
as a /128 prefix.

[root@opy mark]# ip -6 addr add 2001:db8::1 dev dummy0
[root@opy mark]# ip -6 addr show dev dummy0
9: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 2001:db8::1/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::c087:1cff:fe7a:413c/64 scope link
       valid_lft forever preferred_lft forever
[root@opy mark]#

I suppose under Linux, packets are sourced from /128s ;-)