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

David Farmer <farmer@umn.edu> Wed, 01 March 2017 15:08 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 020F012953A for <ipv6@ietfa.amsl.com>; Wed, 1 Mar 2017 07:08:09 -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 HXlRCyfJP88b for <ipv6@ietfa.amsl.com>; Wed, 1 Mar 2017 07:08:06 -0800 (PST)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 AC0A912956F for <ipv6@ietf.org>; Wed, 1 Mar 2017 07:08:06 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 34CE7C76 for <ipv6@ietf.org>; Wed, 1 Mar 2017 15:08:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83eX0HkJi6Ka for <ipv6@ietf.org>; Wed, 1 Mar 2017 09:08:06 -0600 (CST)
Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id D6716C6E for <ipv6@ietf.org>; Wed, 1 Mar 2017 09:08:05 -0600 (CST)
Received: by mail-vk0-f71.google.com with SMTP id n125so7846011vke.0 for <ipv6@ietf.org>; Wed, 01 Mar 2017 07:08:05 -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=NiJwwyJwcVnLdJ599GC0H3HBVEhBdexyC/yNvJMPy3o=; b=XKSfyeZOgrQ8Ewl+dLweqXPrY134IUQknMWyQlSYPpdLa++5vVMMNu4NPqOXV1goFm xcPUOqQcPbTaXeMVNm3FuiQQVaoNjy6s9l3EXmZFQcgJvyC1R6xZLoEO8y+oAKRHgEeW bAizL0MQm7O3+KE+4/7uVwR3yA0HIFlyZ2QJ53iA5+vy6MrEnOHPKdJ0LUGCgItJhnBv UJ8SZAUxp5URaeGqOti6CwbEqSO2W+Id1LtbOO9Vv+GKBhTb7v844G+PA19eRdToUq50 9tQqxQGWBNF1TLejuAMUAw3woIuDP2lwiIOoojdR8RjHy553dhQ6zkFGqe13R1VCQPyW gPuA==
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=NiJwwyJwcVnLdJ599GC0H3HBVEhBdexyC/yNvJMPy3o=; b=ZUzk+1DfxFh/0AIXn+07rhunyejqSxmUsu5wQKDnu7cZMg/UNKiXvecQXsrMKPOqCA SyajAD8MtPfWOnJ3WbMsOe5MVNR3HFHo57j52mC8zxLwpXbXhVQAg/bF3CvcFp8UGcEr tqQcfJ8O1lEitWdNc4g2HfoIB6GsMq4Z8yC6F7LLWgMc7TKB35q/NFJmuS832oCm/PoL bghonw4wpNNGj7bw2eL3EDB/3vZczhoJ5LhMa6f/2CPuojJtHMqaJB98DlUCMbRjUe5+ Ep2mWUKx1EKKPCdtlEqzlqmGiSZqGtKv1wTq2x5uaqWG95jjJ3CeC9k9xNOm23cFcX6x fWzw==
X-Gm-Message-State: AMke39nTnS8yP3uN5LbT0Uqk5gJOYXfkL1BxjeGAl5nNGh1u5pbopieVV88WvxVDtPwVxhC7TCT/9WGnNl7WszcT4jk+wmhu4yvJjRQp7M45ddUqcA+k0Dg45R3K1Vg7XsL6ruSJQRYFs9ryK8w=
X-Received: by 10.176.5.136 with SMTP id e8mr4241434uae.108.1488380885140; Wed, 01 Mar 2017 07:08:05 -0800 (PST)
X-Received: by 10.176.5.136 with SMTP id e8mr4241421uae.108.1488380884909; Wed, 01 Mar 2017 07:08:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.71 with HTTP; Wed, 1 Mar 2017 07:08:03 -0800 (PST)
In-Reply-To: <CAN-Dau1C9zpHLmx_V5764D4vu4wZKzQ86Nd_UL7kZdzNWCTuPQ@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> <CAN-Dau1C9zpHLmx_V5764D4vu4wZKzQ86Nd_UL7kZdzNWCTuPQ@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Wed, 1 Mar 2017 09:08:03 -0600
Message-ID: <CAN-Dau0AqtP7YqMSHke5nCzEPmBj+WT10pKKWN6+sHb_hiwXGA@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary=94eb2c124874eff3540549acadd0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mVz_BPt4yIlbnQCRr2zM6S_cPBY>
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 15:08:09 -0000

On Wed, Mar 1, 2017 at 8:36 AM, David Farmer <farmer@umn.edu>; wrote:
>
>
> 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.
>

I'll add;  It is so highly RECOMMENDED and so convenient we deluded
ourselves into thinking it was actually a REQUIREMENT, that actually
overdid the more important concepts of CIDR and the opaqueness of addresses
across the Internet.  The idea that the 64 bit boundary is fixed is a
delusion, an appealing delusion, none the less a delusion.


> 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 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>



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