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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84E1912963E for <>; Fri, 3 Mar 2017 14:02:14 -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 J_vk-ZiwcdMg for <>; Fri, 3 Mar 2017 14:02:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 817A21295CE for <>; Fri, 3 Mar 2017 14:02:12 -0800 (PST)
Received: by with SMTP id g129so15282976qkd.1 for <>; Fri, 03 Mar 2017 14:02:12 -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=uT9gEqrIg7dN6w+C4TnM9CKOM/2n5nTo587ukB0KyPg=; b=nNrvFXFNo2c2nfTxwbsmP/9t5609+smc7wOLu6DAqq2tl79Jzvj5zeA8z0qWzOGzdZ R/cqWIo3JaBs1SF1w4KTIJW+C5pfRumSVqYo2+Dfb1qJ6c2SVSiIBuSPDiICyUzcmpWv Pizdw/BbBDd3thI1yar+AF4XpN4iny5P6N2Rn/WaBLxiwTKs2P5Y7/83pHG0MMP9x2eh LCgoEllipvQTnTaByyEHQBeUsIQ9/5GvksABfnoDKU6kuoMVI16bxO5jOPue5guVRyfO UmXdKj9AfSB+2EsbWhVwT4FgAZpCaLeF0oU0oD3ffw/3KjY0gGvco+SwNaToyUnGya/t Mxpw==
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=uT9gEqrIg7dN6w+C4TnM9CKOM/2n5nTo587ukB0KyPg=; b=teZC2ja3ufIM9uuRYkkxBl4ElndnYkkzAoFiGOJFqg89wZrj5xzCmowWhmOpqvkBuq XW5yTep42akKO2cZGSD//BKxNN/ErvS3/45tAdF4lIed7spX8XEl8RlW2J18iMiSP7U+ L6xKHr0Q31o8D1YvfQXo8E1CH8XhFQKsVlADKtr5WOMos1kmdHaucbvEN08HQAbzKgsW YRXsv3vWmh2SendZ5Z4FbnZdV8TcihM+MuqoJ+Z/Rr4solkdPSIzX9XHq9nvfcKmmoK1 IPIzXXxgTrq535YduCyN9Bb7WMzrhF2fZTWgKcZnKin1RSFnLSLiotE0hgBmbiXs4pli gmJg==
X-Gm-Message-State: AMke39lZf8vPqu9IlbniaW3VUrBfYmLKZ6qQkFz9Id+Vo17St/9yV3O5UNU2Ai4OzK39o9xQwQ1QhJbpO1AgQQ==
X-Received: by with SMTP id v124mr4492634qkc.19.1488578531348; Fri, 03 Mar 2017 14:02:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Mar 2017 14:02:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 3 Mar 2017 14:02:10 -0800
X-Google-Sender-Auth: iyHNJMqg2OzZYK4PJa8EEUSvzg4
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 22:02:14 -0000

At Fri, 3 Mar 2017 22:09:47 +0100,
Alexandre Petrescu <> wrote:

> > Both, and I believe at least most implementers have had no
> > difficulty in interpreting the spec that way.
> If it is both, then it requires that the prefix used for address
> autoconfiguration of LL addresses to be 64bit length.
> But the LL prefix is fe80::/10.
> "fe80::/10" means it is a prefix.  It does not mean it is "a mask for
> implementation in BSD and other OSs C macros to recognise the LL address".
> So, what goes between /10 and /64?  Why?

For (auto)configuring a link-local address?  If so, it's all-0 bits,
as defined in Section 2.5.6 of RFC4291:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   |1111111010|           0             |       interface ID         |

> > - uses the 64-bit IID (as specified in RFC2464) - uses the fe80::/64
> >  prefix (as defined in RFC4291 Section 2.5.6)
> And ignores the same document's fe80::/10.  And some implementer does
> not appreciate that.

I'm not sure what you mean by this here, but out of curiosity, who is
that implementer and what does it actually do by not appreciating
that?  Auto-configuring a link-local address that does not match fe80::/64?

> > - combine these to configure a link-local address fe80::<64-bit IID>
> > as specified in Section 5.3 of RFC4862
> And who tells the implementer what to put between /10 and /64?

> Should that be 0s?  1s?  An arbitrary random mix of 0s and 1s?

0s, as described in RFC4291 Section 2.5.6.

> > To me there's nothing confusing or unclear here, and I suspect the
> > Linux implementation essentially does the same thing.
> I think you dont want to see the potential confusion because you do not
> ask yourself what to put between /10 and /64.  I think you silently
> assume that should be 0s.

If "what to put between /10 and /64" is for (auto)configuring
link-local addresses, yes, I assume it's 0s.  But not "silently" -
it's based on Section 2.5.6 of RFC4291.

BTW, I do not necessarily disagree that there may be "some confusion"
if one sees this:

      Link-Local unicast   1111111010           FE80::/10       2.5.6
(Section 2.4 of RFC4291)

and this:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   |1111111010|           0             |       interface ID         |
(Section 2.5.6 of RFC4291)

like, wondering "what if the intermediate 54 bits are non-0?  should
it be called a link-local address?".

But, at least in terms of auto-generating link-local addresses, the
specs are clear enough to me that these bits should be set to 0.
That's why I always try to clarify the context is to auto-generate a
link-local address in this conversation.

If you want to further clear any possible confusion between the
intermediate 54 bits, I wouldn't discourage you to write a "mystery of
the intermediate 54 bits for fe80::/10" draft:-)

> >> 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):
> Well then, it should.
> BEcause currently RFC2464 says "An IPv6 address prefix used
> for stateless autoconfiguration [ACONF] of an Ethernet interface
> must have a length of 64 bits".
> If we go by your recommendation above, then it means RFC2464 must not
> say that.

I guess we're just not on the same page...trying to rephrase my point,
it doesn't matter that RFC2464 "does not forbid that that 64bit prefix
be formed by self-appending a 0 to a /63 from the RA", since RFC4862
forbids it anyway (by the "sum must be 128" requirement).

> > 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).
> YEs.
> > If so, that's the correct behavior per RFC4861 (not 4862).
> So RFC4862 should not require the Host to ignore a received non 128
> plen+IID, because RFC4861 accepts it.

Here I actually see conflating.  RFC4862 only says the host MUST
ignore such prefix *for SLAAC*.  It doesn't say, for example, it
should ignore the entire RA or even for that particular PIO for other
purposes than SLAAC.  But I admit this point may be subtle and can
easily be misunderstood.  RFC4862 tried to clarify that subtlety a bit
in the following paragraph of that section (that was actually written
by me):

      It is the responsibility of the system administrator to ensure
      that the lengths of prefixes contained in Router Advertisements
      are consistent with the length of interface identifiers for that
      link type.  It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  In fact, the
      advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.  Thus, it
      should be safe to validate the advertised prefix length here, in
      order to detect and avoid a configuration error specifying an
      invalid prefix length in the context of address autoconfiguration.

but this conversation seems to suggest it's still not clear enough.

> As such, either rfc4862 or rfc4861 should be modified to make it work
> together.

4861 and 4862 already work together.  But, we could make it even
clearer that prefix length validation for on-link determination
(actually there's no restriction for this) and prefix length
validation for SLAAC are independent, if and when we want to update
these RFCs.

> Maybe rfc4862 should not require the Host to refuse a
> received plen+IID not making for 128.

No, it should still require that, as there's currently no defect in
the spec even if it may still not be crystal clear for some.  However,
you have the right to propose loosening the requirement, so if you
think that change is necessary, please feel free to write a draft.

> > It's also correct to ignore that prefix for SLAAC per RFC4862 (not
> > 4861).
> If some RFC requires the Host to ignore the PIO and some other RFC
> requires the Host to interpret it, and both RFCs are mandatory to
> implement, under the same conditions, isn't there a conflict?

No, there's no conflict, once one understands the two types
validations are independent:

- RFC4861 does not impose any restriction on the prefix length in PIO
  for on-link determination purpose (and therefore the host is
  expected to accept any length of prefix for on-link determination)
- RFC4862 requires the host to ignore the PIO of some particular
  length for the purpose of SLAAC (and therefore the host is expected
  to not use a prefix of "invalid length" to configure an address)

Both can coexist.  BSDs literally implement it.  From your previous
message, I guess so does Linux.  I also suspect so do other major OS
implementations such as Windows or Solaris, as this separation has
been in fact one of common test cases in IPv6 protocol conformance
test suites.

JINMEI, Tatuya