Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

David Farmer <farmer@umn.edu> Tue, 28 February 2017 20:34 UTC

Return-Path: <farmer@umn.edu>
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 2EA611296DD for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 12:34:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Level:
X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 baigBxjupprH for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 12:34:03 -0800 (PST)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 F271C1296DB for <ipv6@ietf.org>; Tue, 28 Feb 2017 12:34:00 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 778FF997 for <ipv6@ietf.org>; Tue, 28 Feb 2017 20:34:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvAm7dEGLP-F for <ipv6@ietf.org>; Tue, 28 Feb 2017 14:34:00 -0600 (CST)
Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 315D9285 for <ipv6@ietf.org>; Tue, 28 Feb 2017 14:34:00 -0600 (CST)
Received: by mail-ua0-f197.google.com with SMTP id d8so11839443uaa.3 for <ipv6@ietf.org>; Tue, 28 Feb 2017 12:34:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dPzvFQv4SlypK3crZE+hLbH+YDYSVnFNrn/zllXJ3N4=; b=dXdWWwCUt2mqisRO/BLQGAshBw64hn3CkbcYFxAnd1DRirRhZkXr/gH7BTeoCroh6/ M1vrRI3gA/Miej9Sf52vegv9OUmNX7YO6fALgsz/uhlehkEUh/HU/Ig+W6u/r5J2q780 ifeHHte/WCv4tNPcSXcO43gCMfEgQJTAT3bHnyHm5pMIX+N1H7vqS0Cx5bJxJUTGz50M VUHGjpjde8I+ydCJsyJsJH1gBTRyTC9CtxxYoJTrGmY5Uj0sTeaz4XgcyysCBH9F9ldi okY2K3GIWz88+9kcs1WNQEtzg5NVWIwemqVCVnuiRrkJ7mTLPnGqdM1EA05qYTLhNlRR DYXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dPzvFQv4SlypK3crZE+hLbH+YDYSVnFNrn/zllXJ3N4=; b=JKBpxCw3ayyG596jY3FwsCZq5TT7+wMOPkQwcC+uJb3jxZSwysrCKk4Eo664gP4xU0 vm9p2fluUFSFVDwO9rsY5oOLFNTOTh6gOontvjGAciQXQWLlP+NREra0ZVmWpiIxPsjS Fp3RfKAt1J5jWEVxLLJetDo5DFk5ORwGIorO1BAJ6Hqkgd9tOOIB/Qj9XNMOSPscc33l VvOnX9IxvM6J50OBJAy4SIxxb46A5n7/nuFr6F/WCb8iuu+A7rViB/3M/PflyTniY7Vx 7cBBLu9TQj5l6FdECWtXgDj4pVKV/BODKYQpeN6MTjPsmBHKG0M+f0jkPEqUiVRsiFcS Ou7g==
X-Gm-Message-State: AMke39k4/PDh6k+rNGYDWrbvsiRaNuI36YN2HM76KUxUPpSPks7V6/7t8lMf77I1NSnc+MsRjolOyFcP/rLU6xlCeAnzjMAX6H4XfphAXg2djyfDHE4FFBo+Hg+RGHFOQIllwyILAthJOiyrUBE=
X-Received: by 10.176.5.136 with SMTP id e8mr2110529uae.108.1488314039407; Tue, 28 Feb 2017 12:33:59 -0800 (PST)
X-Received: by 10.176.5.136 with SMTP id e8mr2110517uae.108.1488314039166; Tue, 28 Feb 2017 12:33:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.71 with HTTP; Tue, 28 Feb 2017 12:33:58 -0800 (PST)
In-Reply-To: <CAKD1Yr0wK8EiAbz39EZz-xZLtsSV2JROSzNECKtGo36Zc=RZ0Q@mail.gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <CAKD1Yr0qk_njAGnex_FZsYisCVw=eM8hXTr1v+wqvcfX_09wiQ@mail.gmail.com> <CAN-Dau0ohz3Wp55bs+eoFvSyoUjuKfjzKGSAsJS3wUt3z7TGtA@mail.gmail.com> <CAKD1Yr0wK8EiAbz39EZz-xZLtsSV2JROSzNECKtGo36Zc=RZ0Q@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Tue, 28 Feb 2017 14:33:58 -0600
Message-ID: <CAN-Dau2N-fv3o9o4807m_fbMktjC6hq28sMZhfECKg5cbb4g6Q@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary=94eb2c1248749e818e05499d1d28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/E-4hJeztGGvB_fhzHXhAkmr3wD4>
Cc: james woodyatt <jhw@google.com>, 6man WG <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, 28 Feb 2017 20:34:06 -0000

On Tue, Feb 28, 2017 at 10:29 AM, Lorenzo Colitti <lorenzo@google.com>;
wrote:

> On Wed, Mar 1, 2017 at 12:46 AM, David Farmer <farmer@umn.edu>; wrote:
>
>> However many OSes also allow configurations other than just /64, is this
>> OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it
>> that way,
>>
>
> IMO the important question is not "should an OS refuse to configure a /65
> when manually configuring an address". I think the much more important
> questions are, "can the OS assume that it can use the full 64 bits to form
> an IID", and "will this link ever run out of IPv6 addresses". The answers
> to those should be yes and no.
>

I don't disagree with your answers, and you may not think the manual config
question is important, but others seem too.


> I think we should be saying OS MAY allow configurations other than /64, at
>> least with manual configuration, and maybe DHCPv6 too.
>>
>
> I really don't want to use a network that provides a /120 and requires
> DHCPv6 to connect. Not only does it offer subpar functionality, it does so
> for no good reason. At least in IPv4 there was a reason: there weren't
> enough addresses. Would you want to use such a network?
>

And you don't have too.  But, your saying no one else can ever have a
reason to do that, and I'm not so sure about that.  And something on the
other side of the Internet can't make any assumption about what I'm doing
anyway.  You are saying it can't be done because the 64 bit boundary is
even more important than CIDR and addresses on the other side of the
Internet are supposed to be opaque.  Where as I disagree, CIDR and the
opaqueness of addresses across the Internet are more fundamental properties
than 64 bit boundary.  Which is why I say the 64 bit boundary is really a
RECOMMENDATION.  And CIDR and the opaqueness of addresses across the
Internet are REQUIREMENTS.


> Another thing I think we should avoid is to remove the fixed 64 barrier
> and open the door to having this debate again and again, once for every new
> IPv6-over-foo document and once for every new address configuration
> protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the
> future).
>

Which is why it time to get this right and saying it is now and forever 64
isn't right.


> We have defined this as a parameter not as a constant.
>>
>
con·stant

adjective: constant
1. occurring continuously over a period of time.
- remaining the same over a period of time.

noun: constant; plural noun: constants
1. a situation or state of affairs that does not change.

MATHEMATICS
a quantity or parameter that does not change its value whatever the value
of the variables, under a given set of conditions.

PHYSICS
a number expressing a relation or property that remains the same in all
circumstances, or for the same substance under the same conditions.

Or;

A mathematical constant is a special number, usually a real number, that is
"significantly interesting in some way". Constants arise in many areas of
mathematics, with constants such as e and π occurring in such diverse
contexts as geometry, number theory, and calculus.

https://en.wikipedia.org/wiki/Mathematical_constant

I really don't understand this statement. How can you say that it's a
> parameter, given that every RFC that has been published on this topic
> starting from 1998 states that (most) IIDs are 64 bits long?
>
> Most of the code in most implementations treated this a parameter, but
> there is code that just takes the 64-bit length at face value, and is well
> within its rights to do so, because it's specified by the standard.
>


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================