Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 13 March 2014 09:51 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0F51A09A0 for <ipv6@ietfa.amsl.com>; Thu, 13 Mar 2014 02:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.3
X-Spam-Level: ***
X-Spam-Status: No, score=3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 NgfBGe0k5KcC for <ipv6@ietfa.amsl.com>; Thu, 13 Mar 2014 02:51:03 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1140B1A099B for <ipv6@ietf.org>; Thu, 13 Mar 2014 02:51:02 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id cc10so3601583wib.14 for <ipv6@ietf.org>; Thu, 13 Mar 2014 02:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=D+ag29yTedCri17ijroNArxabWC1w+FZ/jQd9kJBp/4=; b=AVKXRouNYas59qhu6dHnQEhanpHqTwJf/KgVNNJXbmr5QC/kJZ2AwhG3A+UlJvuGTu uszEzJg7rmxGgEplxCUUz0me+hfeKGyGoR6Ei7XhpgXFK+eb3lL67HEhVEylfILN4Z6Y Ukmsc8hz5v//39djGAATMA4hAZAMdRST8JbQX3JeXStcQUCc7N4J7U4npxKdXeMC+GQ5 LcKKbRbMOzPBQbwYMuzZ7qH2RCtEfttT+k977FjZGlvI8ZKuiPCh8NG2TWGHURPQYPqZ orUgHJG2aoFVjj6sSFhH5vcprLAOCG103VtDnSRBU1xcE05fLRpTvxWbl87t+RfnfpQm OILw==
X-Received: by 10.180.7.130 with SMTP id j2mr763087wia.25.1394704256092; Thu, 13 Mar 2014 02:50:56 -0700 (PDT)
Received: from [192.168.0.3] (cpc8-mort6-2-0-cust102.croy.cable.virginm.net. [82.43.108.103]) by mx.google.com with ESMTPSA id u6sm23949660wif.6.2014.03.13.02.50.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 02:50:55 -0700 (PDT)
Message-ID: <53217F83.4060203@gmail.com>
Date: Thu, 13 Mar 2014 22:50:59 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 神明達哉 <jinmei@wide.ad.jp>
Subject: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64
References: <EDA8567C-CB31-40BD-BED5-E9F67AC6B3F3@employees.org> <53191E4B.10108@umn.edu> <1394158327.17795.YahooMailNeo@web162205.mail.bf1.yahoo.com> <53198A7B.4000109@gmail.com> <531F6666.2000107@umn.edu> <532012AB.9060102@gmail.com> <CAJE_bqfujObXMe+TKPevdzKa+b3pf1=Srzy4Q2oEMc4j7zzXmA@mail.gmail.com>
In-Reply-To: <CAJE_bqfujObXMe+TKPevdzKa+b3pf1=Srzy4Q2oEMc4j7zzXmA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/PJg4BEHoo1KSBg-xoxbnmrFLwwI
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 13 Mar 2014 09:51:04 -0000

On 13/03/2014 04:13, 神明達哉 wrote:
> At Wed, 12 Mar 2014 20:54:19 +1300,
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
>>> Therefore, unless the conclusion proposed is that there should never be
>>> IIDs other than 64 bits, which I believe would also be beyond the scope
>>> of an informational RFC as well, I would like to suggest we consider the
>>> conclusion of the draft as a problem statement in that most
>>> implementations seem to ignore any IIDs other than 64 and this will be a
>>> serious forward compatibility issue if other IID lengths are ever
>>> specified in the future.
>> Actually I'm not sure we know that, without code inspections. Certainly
>> a conforming implementation of an IPv6-over-foo that specifies a 64 bit
>> IID for foo links will only support 64. But in a well designed stack,
>> the IP layer itself will treat that 64 as a parameter, so it's only
>> the IPv6-over-foo code that needs to be updated.
> 
> Right, and that's why I tried to say in my previous message.  BSD
> variants implement it this way:
> 
>         /*
>          * Prefix Length check:
>          * If the sum of the prefix length and interface identifier
>          * length does not equal 128 bits, the Prefix Information
>          * option MUST be ignored.  The length of the interface
>          * identifier is defined in a separate link-type specific
>          * document.
>          */
>         ifidlen = in6_if2idlen(ifp);
> [...]
>         if (ifidlen + pr->ndpr_plen != 128) {
>             nd6log((LOG_INFO,
>                 "prelist_update: invalid prefixlen "
>                 "%d for %s, ignored\n",
>                 pr->ndpr_plen, if_name(ifp)));
>             goto end;
>         }
> (see lines 1228-1241 of
> https://github.com/freebsd/freebsd/blob/master/sys/netinet6/nd6_rtr.c)
> 
> And, under the currently published IPv6-over-foo RFCs, in6_if2idlen()
> always returns 64 for all known types of interfaces (IPv6-over-foo
> docs are super clear on this point; how could it be implemented
> differently?), which is why the BSD implementations behave as
> described Section 5.1 of 6man-why64-01.
> 
> But the description of 6man-why64-01 could read as if it's implemented
> as follows:
> 
>         if (pr->ndpr_plen != 64) {
>             nd6log((LOG_INFO,
>                 "prelist_update: invalid prefixlen "
>                 "%d for %s, ignored\n",
>                 pr->ndpr_plen, if_name(ifp)));
>             goto end;
>         }
> 
> and is misleading.  I also see the same confusion in this particular
> email thread.  I understand these two cannot be distinguishable from
> an external observer, but IMO the draft text should be revised to
> avoid this type of misunderstanding.

I completely agree.

  Brian