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

David Farmer <farmer@umn.edu> Wed, 01 March 2017 14:36 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 B083112954C for <ipv6@ietfa.amsl.com>; Wed, 1 Mar 2017 06:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Level:
X-Spam-Status: No, score=-3.8 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, URIBL_BLOCKED=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 8LM2VjaqLCei for <ipv6@ietfa.amsl.com>; Wed, 1 Mar 2017 06:36:37 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 E2F321294EC for <ipv6@ietf.org>; Wed, 1 Mar 2017 06:36:36 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 67C5E5BB for <ipv6@ietf.org>; Wed, 1 Mar 2017 14:36:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EdoXm991_GH for <ipv6@ietf.org>; Wed, 1 Mar 2017 08:36:36 -0600 (CST)
Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 1DCB7CCF for <ipv6@ietf.org>; Wed, 1 Mar 2017 08:36:36 -0600 (CST)
Received: by mail-vk0-f70.google.com with SMTP id 130so7347474vkn.2 for <ipv6@ietf.org>; Wed, 01 Mar 2017 06:36:36 -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=xx5NrV8mdxh6yGMe/XTGrHNegztQCox6n9IKW6GXcPQ=; b=n+uJXGUdf4+21l1ScVcxUsxkNg3xgjQaRiU+Y7EObkFbLmZn8rzdyhxEozWwlTFv2N kNBbICyKmkdL0Nr28MJawD0kdd+I/PsNX9ZETT/1lQRS/bBsFLUA8Yw16VLqU7A6xpXu V5qLC1j7VQ0Ges45tva0NjByOLeEEYu4B0cR20Vh7qxCCoS3REdmb286tysCsFxpopn3 Q/K6DEjIiHCSIfihzTdigtrvK9VzssH9M6BT4E4p8IJ0tY+ZsTeBqQeMa152HtlBv7Io T2/g94/VX7e5XPOiVXrAlbb8+Ihv0yV9iRFGK5s39zY+nSmqq1B+ZtD3j0Pn1xnT8JFN DhHg==
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=xx5NrV8mdxh6yGMe/XTGrHNegztQCox6n9IKW6GXcPQ=; b=tYC3EVcxaqNjrdonCs1ORH8eor5L0hr2A3M2ASNelo4rYhOdStWdezQbIx7P01K+mG uxBHZfxejtID+VeFKwaNHw72ojdJD+V+EV9GXSUnxaFQacceDsyEu2ibL7XRB/hFiN/i OunaJzgZMZueftAfKjXn47OSiqEr5f2+Ow4mdNwK7icj3YoN1t/9PaBjTEdhuzk/qJBj wMPh6MWoHe/knXUrBucVnHkiwXS4LpfpR7eGgz+OITc7zOmcVs6LCcPu8wlUC7tax0/7 UtwgYH2UtebeLSeVO/iSCDXmoPdCAQNml6wa6QOsiIfeaK2Du7ecHFn7ASZY0+/qVHk5 AM2Q==
X-Gm-Message-State: AMke39l6Qli9ehDHkH1nyWZ1LkatPtQhXkHcW+amtL7+uxEpntms065AFry+8tnuYbRl/cISVw9IvSkZ9QGvl6cXcf4KLQmN7lXwNlyjV5WzWN1reBTasF+uJBTdyEqfW00fopcXFtXu7XA5X0k=
X-Received: by 10.31.192.204 with SMTP id q195mr508170vkf.155.1488378995492; Wed, 01 Mar 2017 06:36:35 -0800 (PST)
X-Received: by 10.31.192.204 with SMTP id q195mr508152vkf.155.1488378995199; Wed, 01 Mar 2017 06:36:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.71 with HTTP; Wed, 1 Mar 2017 06:36:34 -0800 (PST)
In-Reply-To: <CAKD1Yr3tHm5x29w4L5KtKi7PqDHRxkPr6i9mJMtHLaPc2eM2GQ@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> <CAN-Dau2N-fv3o9o4807m_fbMktjC6hq28sMZhfECKg5cbb4g6Q@mail.gmail.com> <CAKD1Yr3tHm5x29w4L5KtKi7PqDHRxkPr6i9mJMtHLaPc2eM2GQ@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Wed, 1 Mar 2017 08:36:34 -0600
Message-ID: <CAN-Dau1C9zpHLmx_V5764D4vu4wZKzQ86Nd_UL7kZdzNWCTuPQ@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary=001a114388cc4d40490549ac3d70
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rSGH5pHO5amcF7s3ZNxlBl_MDsM>
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: Wed, 01 Mar 2017 14:36:39 -0000

On Wed, Mar 1, 2017 at 3:51 AM, Lorenzo Colitti <lorenzo@google.com>; wrote:

> On Wed, Mar 1, 2017 at 5:33 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.
>>
>
> FWIW I wouldn't oppose an exception for manually-configured addresses on
> routers.
>

I think manually configuration should be OPTION for all hosts , and I'd
RECOMMEND it for routers, but i wouldn't REQUIRE or even necessary
RECOMMEND it for general host. It would be my personal preference that all
host have a way to be manually configured, but OPTIONAL is good enough for
the standard I think.


> 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.
>>
>
> Let's see if there is common ground here. I agree that routers should
> forward on arbitrary prefix lengths. It's probably reasonable that hosts
> should not make assumptions about other host's IP addresses (except if they
> are on the same subnet). But I think a host should be allowed to assume
> that its own subnet and its own IID are 64 bits long.
>

A host has to actually look at the RA to determine it, and can't just
assume. I'd concede that an RA set to and other than /64 with the "a" flag
set SHOULD be considered a misconfiguration, but it is possible to set RAs
with other than /64, especially if you don't set the "A" flag.  And if you
manually set set the 128 address and it's within the range defined by the
RA then the host SHOULD use it as excepted.  Furthermore, I think a host
configured with an 128 address via DHCPv6 SHOULD work much the same way,
but I'm willing to be convinced otherwise on that.

Now to me that says RAs with /64 are REQUIRED iff (if and only if) the "A"
flag is set.  Otherwise RAs with /64 are RECOMMENDED, but other lengths are
allowed.  Also you MAY manually configure a host with a subnet length in
addition to manually configuring a 128 address, and only in the case were a
host is manually configured with a 128 bit address and there is not
associated manually configured subnet length or there is no associated RA
is it ever ok to assume /64.

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.
>>
>
> Do you agree that a fixed boundary is useful or not? For 20 years the
> standards have guaranteed that 64 bits of IIDs were available to hosts that
> wanted to use them. If we make that barrier mobile, there will be no
> guarantee in the standards any more. Who should be allowed to set the
> boundary? An IPv6-over-foo document? An address configuration technology
> such as SLAAC? An ISP that wants to charge you $1 for every /128 you use?
>

I'll agree there is a 64 bit boundary, I don't conceded it's fixed, it's
only been considered fixed but cause we errantly allow the word required in
RFC4291 and its predecessors, CIDR and the opaqueness of addresses across
the Internet are more fundamental principles than the 64 bit boundary.  The
64 bit boundary is a convenience, a very important convenience, a very
highly RECOMMENDED convenience, but only a convenience.  It doesn't
override CIDR and the opaqueness of addresses across the Internet.

Thanks.
-- 
===============================================
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
===============================================