Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 16 February 2017 17:07 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 0CA14129663 for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2017 09:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 gNlGQTk07wYJ for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2017 09:07:20 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B391D1299AD for <ipv6@ietf.org>; Thu, 16 Feb 2017 09:07:18 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1GH7GWZ016331 for <ipv6@ietf.org>; Thu, 16 Feb 2017 18:07:16 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B880C20DA81 for <ipv6@ietf.org>; Thu, 16 Feb 2017 18:07:16 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AEB7120D962 for <ipv6@ietf.org>; Thu, 16 Feb 2017 18:07:16 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1GH7GPD020649 for <ipv6@ietf.org>; Thu, 16 Feb 2017 18:07:16 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: ipv6@ietf.org
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <m2y3x6eutl.wl-randy@psg.com> <B76B6864-5827-4AC1-9BF7-8FFF069C10F1@employees.org> <m2lgt6ed7j.wl-randy@psg.com> <4514E052-25C1-4C85-AB1D-0B53FD9DA0E1@employees.org> <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <04df18e9-aec4-7e94-fd14-9a4a9762b490@gmail.com>
Date: Thu, 16 Feb 2017 18:07:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vB69ZZGQZopXssVOdpUWbBgOpnQ>
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: Thu, 16 Feb 2017 17:07:25 -0000


Le 16/02/2017 à 15:38, David Farmer a écrit :
>
>
> On Thu, Feb 16, 2017 at 3:09 AM, <otroan@employees.org
> <mailto:otroan@employees.org>> wrote:
>
> Dear Randy,
>
>>>>> If your statement is that we only have the 64 bit boundary
> because of
>>>>> SLAAC I believe you are wrong.
>>>>
>>>> cite, please.  what else actually needs it?
>>>
>>> https://tools.ietf.org/html/rfc7421
> <https://tools.ietf.org/html/rfc7421>
>>
>> that excuses it.  cite where it is actually needed to do something
>>  useful other than slaac.
>
> "something useful" makes it subjective.
>
> If you only care about technical issues, then: SLAAC, NPT66, ILNP
> are the biggest one that I can think of. Trivial to make SLAAC work
> with variable length prefixes of course. As well as we don't know
> the consequences for implementations. 7421 seems to indicate it
> mostly works.
>
> But then you have people who write code like this:
> https://git.fd.io/vpp/tree/src/vnet/map/map.h#n332
> <https://git.fd.io/vpp/tree/src/vnet/map/map.h#n332>
>
> Where it clearly will not work with a longer prefix than 64. Feel
> free to contribute a patch, but make sure to count the cycles spent
> through that code.
>
>
> So, is that code right or wrong?  To be honest, I feel the current
> text says its correct to embed 64 in your code.  If you truly think
> current text is correct, then have the courage of your convictions
> and embed 64 in your code too.
>
> However, I take your example as evidence that the current text
> doesn't have the balance right.  Is the proposed text too far the
> other way? Maybe.  Well... actually probably it is too far the other
> way, but I don't see you even acknowledging there is an issue with
> the current text.
>
> As far as I'm concerned, this is a policy statement masquerading as a
> technical requirement.  Policy is all about nuance and shades of
> gray, and technical requirements are about clarity and making things
> ether black or white.  The problem as I see it is, we are trying to
> use technical requirements language too describe something that is
> truly a policy issue.  So we are probably doomed to fail!
>
> How do we move forward? What I think we need is to make it clear that
> there are real exceptions to 64, and it is therefore not acceptable
> to embed 64 in code.  The historic exception of addresses that start
> with 000 has been too amorphous, no one thinks it real. I've provided
> two exception that are clearly based on current standards track work,
> but I fear that still isn't enough.  I fear some will still embed 64
> and just add code for the exceptions, if it's even really needed.
>
> Can you help me find something a little more?
>
> What about an additional exception for manual configuration?

The manual configuration of IPv6 addresses on interfaces is a common
practice in establishing 2-computer one-to-one subnets on an Ethernet
wired link.  This often uses IPv6 addresses with prefix lengths
different than 64; e.g. /56, /60 or /72; in these cases the length of
the Interface ID is 128 minus that figure, to make sure 128 is respected.

During manual configuration gestures System Administrators appreciate
the easy to memorize strings denoting Interface IDs (e.g. ::abba),
rather than hard to spell strings (e.g. 5103:7ad5:4111:c22b).

Many DNS servers reachable on IPv6 have very short Interface IDs; check 
yours but mine is ::6, and a certain preferred is ::8888.  These are not 
normally /64, because they are not SLAAC'ed/Ethernet.

Alex

>
> Thanks. -- =============================================== David
> Farmer               Email:farmer@umn.edu
> <mailto:Email%3Afarmer@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
> ===============================================
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>