Re: A proposal for draft-ietf-6man-rfc4291bis-07

james woodyatt <> Fri, 03 March 2017 23:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7055F128B38 for <>; Fri, 3 Mar 2017 15:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 NlR8kMvqmAbO for <>; Fri, 3 Mar 2017 15:44:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26173126D73 for <>; Fri, 3 Mar 2017 15:44:05 -0800 (PST)
Received: by with SMTP id j5so37810389pfb.2 for <>; Fri, 03 Mar 2017 15:44:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6XKal/eAqVGE8BrS1pWKI4N3pVrt1rBGUQKyNNmIM80=; b=DJX3j3EUisBGY9wiLVcemzT+7jGEaMei3gyr7xErTYLBUhG8LUcUT+r4Pz2qKuGLyH qUEEk+MkJv5TdKnH9PLPl8Vp9f0xMd2N1H01QTRAGWZMIJX6+0L1VZmFgR9wCh9phann 8xy/rP/knb1uySeZNcsFSa6Vz/M0YvLZQbYyYxu9/kk4r6TNiP0Myhn9pkIssIq2b5YW sR8grK+5M35mq0PgVmZsgNLIhBO/OD1zG8H7NIyugO41XCF2GyzTExJzaUArtiTA+tmw snIjilDFaIhueuQvptTMjnHJrFgPgGpaY8zifiZq/vq62JM7IUVKGLUr2z4jnjbu1zXe IJxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6XKal/eAqVGE8BrS1pWKI4N3pVrt1rBGUQKyNNmIM80=; b=VhmihIc5KDMcpSPxjB0+4EHRVYchiLVkUyK02IcCIoB3Zo+NxHgHlnr02DF4KECpna 4aIP07vsSJHKzgDtbisFZh+m3/HUfHIKuIADA7yyRIyrkbStfvVtyuhgDsjrro6BqNRY 3RZHeaOLkJrzlHZKOikQukoqxe36PfcZAqBf44rvSvUgkCOfJftfUaoXbGgnCKuAseQL W2rmou37B5rtjpD3NhJfg7EYkRStgWA/7q+PTQCRZ2psuLnpk4M5YJ66hB9x//vhIGAC 4/xi9ogQPmEXddZMCjyewpFnLe7pswaGBJVA2xBCFX07T9t01xwRSW5BIDb4ZY7Qha+U 6FTQ==
X-Gm-Message-State: AMke39k1+i1DAX+1vj3nyckP/cnF1gIWLqGnH+n36Uq+H8wnTrOITexBYuXkmHJD1AzwVWC0
X-Received: by with SMTP id r207mr1311576pgr.214.1488584644548; Fri, 03 Mar 2017 15:44:04 -0800 (PST)
Received: from ([]) by with ESMTPSA id s21sm25553567pgg.65.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 15:44:03 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_882D4D36-46BD-4E6B-860B-F18BAF1BC256"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
Date: Fri, 3 Mar 2017 15:44:02 -0800
In-Reply-To: <>
To: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
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 23:44:06 -0000

On Mar 3, 2017, at 14:30, Philip Homburg <> wrote:
>>   Shorter james: if IETF will insist that I modify my host IPv6
>>   stack so that, on Wi-Fi links, it will do on-link determination
>>   with prefix lengths other than 64 bits, then I want to see that
>>   in its own draft and not in the successor to RFC 4291.
> Did I miss a couple of rounds somewhere?

It looks like you’re assuming that I don’t have to comply with requirements in RFC 4862 when processing RA messages with Prefix Information Options (PIO). Like every good IPv6 host implementation, mine implements SLAAC. It therefore needs to comply with RFC 4862, especially if I ever hope for it to achieve IPv6 Ready certification for hosts. Lots of hosts are required to implement RFC 4862. You probably have one in your pocket.

> Onlink prefixes come from PIO options in RAs with the L bit set. Since
> forever, these options have a prefix length field.
> Section 4.6.2 of RFC 4861 has this to say about prefix length:
> "8-bit unsigned integer.  The number of leading bits
> "in the Prefix that are valid.  The value ranges
> "from 0 to 128.  The prefix length field provides
> "necessary information for on-link determination
> "(when combined with the L flag in the prefix
> "information option).  It also assists with address
> "autoconfiguration as specified in [ADDRCONF], for
> "which there may be more restrictions on the prefix
> "length.
> So there are extra restriction for SLAAC, but not for use as an onlink
> prefix.
> Are you saying that your stack completely ignores that prefix length and
> hardcodes it to 64?

I’m saying that my stack tries to comply with RFC 4862 which requires that it ignore PIO options where the Prefix Length is not 64 on link types that define the length of the IID as 64 bits in the relevant IPv6-over-link document. My stack does that in the hopes of eventually passing the IPv6 Ready certification test, which I’ve been through before, and, yes, it tests for that MUST In RFC 4862. It tests both the requirements for processing the A flag as well as the requirements for processing the L flag.

If you send me a Prefix Length other than 64 bits, then I’m gonna ignore it. Just as RFC 4862 commands.

It’s technically true that *if* my stack did not implement SLAAC, then it would have no need to comply with RFC 4862, and it could therefore accept Prefix Length other than 64 bits on Ethernet (and Wi-Fi) link types, by complying only with RFC 4861 and not RFC 4862.

But let’s be honest. Who would buy gear intended for home networks that cannot do SLAAC?

--james woodyatt < <>>