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

james woodyatt <> Tue, 07 March 2017 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 450A31295EF for <>; Tue, 7 Mar 2017 10:59:23 -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 7kUMfFNFx3zf for <>; Tue, 7 Mar 2017 10:59:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 981871295F3 for <>; Tue, 7 Mar 2017 10:59:21 -0800 (PST)
Received: by with SMTP id v190so4005075pfb.1 for <>; Tue, 07 Mar 2017 10:59:21 -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=alhOCWmDiQU4KH7ZZJV6cF17QXjBarE1ND6aKfLB9Wc=; b=idVlTNP2XSTWSsYMKpJsYACdQZUEwXjrrp1Imc1bSjT1cRcMxqn13nfnh8eE9fowbL mUTSnyk8Mq9jCTitXoCQQ4qOM8r7qkO+LCINWIWDkYSm0hIbARcV2AqLV0VgVI7GabXg dGpPxuBbgKuQAlfT1byqHJ3mblyDSj7Sk2zGdfs09vtBQF9AO9zW/lwVLrNfR5zvl0cl Cphj1DjkUKjtR77a6IRjYgIxIbr7iwQYNBSkvKpxTRO132hlNbn/NuGAwSi3pd4tpN4v qXYWI61I62sqRtgB/x9Jmq77oZO6BZ/7cOVHKpJk/NA4GHCULoQj5vvhdqPVJ1OU4Zke QgQw==
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=alhOCWmDiQU4KH7ZZJV6cF17QXjBarE1ND6aKfLB9Wc=; b=Su2UPVp07kOzv1YnE4gs9eNHe1p/uHtIQQrQKtV7sQ2IxL/eM33uCicA/9s/QUdtMY BzG9mi3esbRYhgSPk8Uec9wLuksT5Xwy3jfYa4cm1tth+XurPKU29dZkTR814LssEP2A GH9GsJOR2hylHqcRCxgbamn3MpDbAGTVNIo4SSgOinPH14G4xLkp+m4LHqv1rzp+qrYV ivjnfwT0w05+GokWFsgxmBMA0TtzMFaF9kjVa8x/2MzDjZDWG7ppWDlQysDHG+5Un4mh 2pzOmYcBwvjWAstoATwIyqLEyOeP5lMHyM+8mfPM5g+DO1HqVMDp8rH9AYqXXNEgNPg8 b/TQ==
X-Gm-Message-State: AMke39midZqAQ5N2NW4uQ54f3PrEAy+xeAWrxK4E6Hv8S2NsbmvX8lKDpmE9sHvNI3e4qXsH
X-Received: by with SMTP id h27mr2022280pfd.182.1488913161074; Tue, 07 Mar 2017 10:59:21 -0800 (PST)
Received: from ([]) by with ESMTPSA id f3sm1286893pga.34.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 10:59:20 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_151E138E-AA36-44A5-A1DF-B3E3E56929CB"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07
Date: Tue, 7 Mar 2017 10:59:19 -0800
In-Reply-To: <>
To: Timothy Winters <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 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: Tue, 07 Mar 2017 18:59:23 -0000

On Mar 7, 2017, at 10:50, Timothy Winters <> wrote:
> It's valid to ignore it for SLAAC, but not ND.   RFC 4861 is clear about processing the PIO for on-link determination, LwIP isn't following ND spec.
I’m happy to defer to your considerable expertise in these matters.

Question: could you point me at the requirements language in RFC 4861 that LwIP is specifically violating? I’m confused because when I search on the phrase "Prefix Length” in the text, the relevant excerpt that seems to apply is this one:

>>       Note: Implementations can choose to process the on-link aspects of
>>       the prefixes separately from the stateless address
>>       autoconfiguration aspects of the prefixes by, e.g., passing a copy
>>       of each valid Router Advertisement message to both an "on-link"
>>       and an "addrconf" function.  Each function can then operate
>>       independently on the prefixes that have the appropriate flag set.

The way I read this is that implementations MAY choose to process the Prefix Length validation differently in on-link determination and SLAAC functions, but that it doesn’t seem to be expressly REQUIRED. Sadly, there don’t seem to be any other relevant texts about the Prefix Length.

I can believe that LwIP is violating RFC 4861, but before I file an error report for this, I’d like to be able to cite the actual requirements keywords, and I’m concerned about the possibility this Note above may be used by the LwIP maintainers as a justification to reject the problem report.

--james woodyatt < <>>