Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux

神明達哉 <> Fri, 03 March 2017 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEAAE129990 for <>; Fri, 3 Mar 2017 11:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 PO2chyORAfNU for <>; Fri, 3 Mar 2017 11:03:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADC9512998E for <>; Fri, 3 Mar 2017 11:03:18 -0800 (PST)
Received: by with SMTP id g129so7761136qkd.1 for <>; Fri, 03 Mar 2017 11:03:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WZEPhyzLOrQkwf6N/LJIR+6+BC9+5XHVYlfQXqxP4Og=; b=UdCk8RmLfo1YdSSdAXMP/hr8kNEnNdptt97cL5SrIsPXR6GftSk3KMLA1EaMV2cgXH AN19deWCuM2g6jZRJSaJndvwNHqaUPCb6kyz1IekU3wtQ6YmEkU/gSFBFwlppMu9OYAu 9glQdvhdQXVpNnjjFTP6ePlZPHBTdymXnA/8IyrQ5xIOwIej4RNc6RtoKCVTyolXyZsO O1NV5HeFb+RRLApyWpW4vLXGZSsKaOv5Q9RWS48AmgB+GdEgkU4a+vGCwwMl3uCdrGtI O7QHzw+djQ5DnXqwFPsg5a1JOEiNomvAojUe2WcacKx330U1eHiCNojD7iBLTEwXuy99 3nrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WZEPhyzLOrQkwf6N/LJIR+6+BC9+5XHVYlfQXqxP4Og=; b=cGKCtjJKk6yPnEzFah+jCaS8kBlDIjZ/rdW4bJCQFYu0sraIXT0uCNRlsXeykd8Qsg ozRy/t7GFhE3OTgZKS+vmHLT4uWuFz7EvsN2b0IAoW/8W+Y/cDMnULtpelwC+mo3eexQ hv9uJj9UPnzcy3ySjHoEMJzViCihbNTS2cq9ocBounRYCKzFn9WO+ZYFNjURtNIawgOj C2dRaZGLdfdaXoQccgQGCTcAL30QrkRwoLjiw2pDbSmG1k1h/9s+XdK6EoX0jkdwprSj RG200nAdCUcBOaNODtBQkPoXa7izP82mhE1TyGjwPZmXY8mr1SSAzKkrFsqGtz6IZxDm s5qg==
X-Gm-Message-State: AMke39mwUOgSu+NT1BndgRoedwLMjSjlOWL2jGgFAkffpzdAilfMxzQM4GSfmhWtE+yChi7Sn88UqZCqv5DpjA==
X-Received: by with SMTP id v124mr3806659qkc.19.1488567797580; Fri, 03 Mar 2017 11:03:17 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Mar 2017 11:03:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 3 Mar 2017 11:03:17 -0800
X-Google-Sender-Auth: gWnONoGaa5qzWlZWNxRPo9vhqdk
Message-ID: <>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux
To: Alexandre Petrescu <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: IPv6 IPv6 List <>
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: Fri, 03 Mar 2017 19:03:20 -0000

At Thu, 2 Mar 2017 13:36:44 +0100,
Alexandre Petrescu <> wrote:

> Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used for
> stateless autoconfiguration [ACONF] of an Ethernet interface must have a
> length of 64 bits".
> It does not say which prefix of [ACONF/RFC2462] must be /64?  Is it a
> global prefix in RA?  Or is it the link-local prefix?  Both these
> prefixes are relevant for the above phrase, both are mentioned in ACONF,
> yet only one is present in RA (the one linux complains about when at
> 65).  Is the mandate cited above applying to the prefix in RA?  Or to
> the link-local prefix?  If the mandate applies to the prefix in RA then

Both, and I believe at least most implementers have had no difficulty
in interpreting the spec that way.

> linux is right to complain, on Ethernet.  If the mandate applies only to
> the LL prefix, then linux is wrong to complain about 65 in RA.  If the
> mandate applies to both then RFC4291 is wrong when it says fe80::/10.

Like in my previous message, I don't know what "it says fe80::/10" in
this context.  I also don't know implementation details of the Linux
kernel either, but the BSD implementation uses:

- uses the 64-bit IID (as specified in RFC2464)
- uses the fe80::/64 prefix (as defined in RFC4291 Section 2.5.6)
- combine these to configure a link-local address fe80::<64-bit IID>
  as specified in Section 5.3 of RFC4862

To me there's nothing confusing or unclear here, and I suspect the
Linux implementation essentially does the same thing.

> RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64".

That's fine.  The only thing this RFC is expected to say is the length
of IIDs.  RFC4862 defines how we use the IID to (auto)configure
addresses.  And RFC4862 applies it to both link-local and global.

> It does not forbid that that 64bit prefix be formed by self-appending a
> 0 to a /63 from the RA, or other mechanism.

It's not the job of RFC2464.  RFC4862 imposes the restriction through
its Section 5.5.3 bullet d):

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be

> Besides, RFC4862 (successor to 2462) says "If the sum of the prefix
> length and interface identifier length does not equal 128 bits, the
> Prefix Information option MUST be ignored." And linux does _not_ ignore
> a /63 in the RA: it adds a rt entry for that /63 prefix.  That's not
> normal either.

I suspect you're probably conflating SLAAC with on-link prefix
determination.  I guess that "rt entry for that /63 prefix" is to
treat the /63 prefix as on-link (assuming the corresponding PIO has L
bit on).  If so, that's the correct behavior per RFC4861 (not 4862).
It's also correct to ignore that prefix for SLAAC per RFC4862 (not
4861).  Nothing wrong here.

JINMEI, Tatuya