Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"

Sander Steffann <sander@steffann.nl> Tue, 07 March 2017 12:15 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53B4129461 for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 04:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfNepnZ1PTdx for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 04:15:47 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7552B1293E9 for <ipv6@ietf.org>; Tue, 7 Mar 2017 04:15:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 93F4D4A; Tue, 7 Mar 2017 13:15:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1488888941; bh=KP871CTet/mVZAX7ohP3qJkk84wC PQmLO9S6dowLecw=; b=VGg4f6vsr8BEXSJcZOrOLBV0O3KijbdtOdsixG1sxlO0 B6CQwDNe7/HrLbyDE/PFfQTH6A6UO067ljX/eK5rrJPjImnMWt6DXp8bv2bNpUDl cDkx+mtVLGUScvSPB2+C/HJ2XCvOVJU2xxZfLyGAfLOlVCtkQ2urdZcAnw9/nBk=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id INzpbub-4FrY; Tue, 7 Mar 2017 13:15:41 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6] (unknown [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 3167F49; Tue, 7 Mar 2017 13:15:41 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_D655C36C-22F8-447F-BF6F-BED5C801DA5E"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
In-Reply-To: <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com>
Date: Tue, 7 Mar 2017 13:15:40 +0100
Message-Id: <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl>
References: <CAN-Dau17q_BrUuzfvB1mLDt6p5UxYikphWaHpa8VQ2L-3kx-DA@mail.gmail.com> <ee764408573b4db4b22e58c4ea5f289c@XCH15-06-11.nw.nos.boeing.com> <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <CAN-Dau0bSPiubeDOFeJAg6H0wP0ZNDS514eedmJtkOqHTXWOOw@mail.gmail.com> <D6D5B476-7F21-4F49-A81D-C2A11C30ADEC@google.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <ABE47051-FBFC-460F-89B0-FFD451410F7B@google.com> <m1cjviu-0000EYC@stereo.hq.phicoh.net> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <m1ck5mu-0000GaC@stereo.hq.phicoh.net> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <m1ckxfo-0000IMC@stereo.hq.phicoh.net> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <CAOSSMjUR203+hYFBrFBrj9Xkjux3o7fYNd4y9kNyxwpLxF11ew@mail.gmail.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <CAOSSMjUP6m-L1iNhE=BxHW+7hvt4YsZgxxtVn+qmgEVS9HeStA@mail.gmail.com> <CAJE_bqfpE-NWwG12S4CXM+ZnHdHHH31-y+_+pYhuCuq2FtqZ4w@mail.gmail.com> <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.c om>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xuDlWADSABcVI1ACYZNAiPbOcGc>
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 12:15:49 -0000

Hi Alex,

> Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu <alexandre.petrescu@gmail.com>; het volgende geschreven:
> 
> Le 07/03/2017 à 02:11, 神明達哉 a écrit :
> [...]
>> But this thread and another similar discussion seem to suggest that
>> it's still not clear enough for some people.  At least two different
>> readers interpret this text:
>> 
>>> If the sum of the prefix length and interface identifier length
>>> does not equal 128 bits, the Prefix Information option MUST be
>>> ignored.
> 
> Let me say that there are some interpretations of that sum from people
> struggling to make it work.  These interpretations may be surprising to
> the specifier.
> 
> The specifier is tempted to think that that "sum" equation is a good way
> to tell everything in just one phrase.
> 
> But some people face the problem of making that sum be 128 even though
> the plen is less than 64 and the IID is 64.
> 
> It is the case with the fe80:://10 needing to become a fe80::/64

Which is explicitly specified in RFC 4862 section 5.3. The /10 is used as the basis and adapted to the IID length on the link. It explicitly says that all bits between fe80::/10 and the IID are zero (point 2).

It also says "The length of the interface identifier is defined in a separate link-type-specific document". RFC 2464, which is that link-type-specific document for ethernet, specifies in section 5 that on ethernet the prefix for link-local addresses is a fe80::/64 with a 64-bit IID. Everything is specified: the /10 to use as the basis, the /64 being the length used on ethernet and the bits between the two having to be zero.

> , and it is also the case when PIO in RA has a P1::/63.
> 
> For this latter case, one wonders: am I allowed to form an address when
> all I have is a P1::/63, and an IIDlen 64?  Can I make a P2::/64 by padding with 0s?
> 
> The specs dont answer these questions.  The specs think that the "sum"
> equation is enough.

It is. A "sum" is a quite clearly defined mathematical concept. As you quoted above RFC 4862 section 5.5.3 says "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored." Let's test this. In your example case:
- P1::/63 has a prefix length of 63
- IIDlen (interface identifier length) is 64
- the sum of the prefix length and the interface identifier length is 63 + 64 = 127
- 127 does not equal 128
- therefore the Prefix Information option MUST be ignored

> Further, because of that, some people think P1::/63 is forbidden from
> being advertised on Ethernet.

According to RFC 4862 you can advertise it, but receivers must ignore it.

> Others think fe80:://10 is the same as fe80::/64.

As you can see above the fe80::/10 prefix is used as the basis for the link-local addresses, with the actual prefix length defined per link-type. For ethernet that has been specified as 64-bits, so that leads to fe80::/64 on ethernet.

Please read the RFCs. All the examples you provide are quite explicitly covered there...

Cheers,
Sander