IETF Logo Mail Archive

Re: draft-bourbaki-6man-classless-ipv6-00

Lorenzo Colitti <lorenzo@google.com> Thu, 08 June 2017 12:42 UTC

Return-Path: <lorenzo@google.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 4E5AB129508 for <ipv6@ietfa.amsl.com>; Thu, 8 Jun 2017 05:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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=google.com
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 4yyxQmB82Uva for <ipv6@ietfa.amsl.com>; Thu, 8 Jun 2017 05:42:22 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1943126CF6 for <ipv6@ietf.org>; Thu, 8 Jun 2017 05:42:22 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id g66so16333900vki.1 for <ipv6@ietf.org>; Thu, 08 Jun 2017 05:42:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jv2IilCHDV+B4beyvIE6bTQEJaGgOvSJsR53rq4D4EM=; b=czxAw6FHUW1EPtarZdSsJbZhwexYKn2AUKte/0lkuinXwUBI5D5WPemYfhe7NBtuyg XYB7EeCrSZdgxbhd4irdefh0NvkaLWTtTg0NBYYiOsp51XeyWY1M8kn9M3eWR8RnHFbV 34HRe1vmm/tL3vSSViKiNMcG28CGG8ioBAXVyb0xZvuQwC5PChxhLtE9OHqM/LTMNHzh 85AatGzlLQF0DfsAVipSIUAK503Aquosd8N+jA71MLsNULbJRrmIVxkYFY7CiUvqMNkF /jPNdewDStHf+u+avER8S22Rn2ogRRMFX2oyCHhf1v8yx3L+FLjQD4I97GQ1PJYO/EHT Wd2w==
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=Jv2IilCHDV+B4beyvIE6bTQEJaGgOvSJsR53rq4D4EM=; b=nw/E5ZBbEcWF5Z+MWwjmRBOfSs9mGOxROYCnjbfzLvTu06yefQgqBiFcn0LQVz5I22 kywOOBp5GVPdaBn17fs2U2B2bhinxEKlkWR6sbXYyUAiRlTZWY9pLzlcS+RjNjXXjHsm jcVTTHN//wCnLUdFc2seVOonHkU5fD63IKDmjZgthHm9GiiHR+WL94cX+3LWfh8aqKXn 3jYUlXjCqRnxt6VUUXJlgGhdAEScLK9BK5AP8wl+4+NQFDC9i86HJ666S2m2fLKV5i19 /EXyNmD+kAoRoHZKMO4gJBRvjG5HBj6zqqKlpgH7+w62DrMEwWhxcoZMf4dEH8ceVwB5 48sQ==
X-Gm-Message-State: AODbwcAYIWc0yV1b44wmw9mydRw4hBxpWchh+Pn5XNK6R4eE/GGlJMjf RDemng7YpeBLoxQrKAN0Edtg3JFPvuQO
X-Received: by 10.31.69.138 with SMTP id s132mr16267140vka.13.1496925741593; Thu, 08 Jun 2017 05:42:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 05:42:00 -0700 (PDT)
In-Reply-To: <CAN-Dau08sssc6WnfYL0+7pvC_R5gAdQZu2bKxTyFWcSm0xFh=A@mail.gmail.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <CAKD1Yr0DtQYvCYLQexhXe_nhb5rjeyhnB4bCveqyO5Xbuwdg1A@mail.gmail.com> <CAKFn1SEdjhsQ3tKPZdbdfF4ArDzw-FZfjQT68gV55Fc-5vzBvw@mail.gmail.com> <CAKD1Yr3ppM0UF8HoN8PgS7F0iEmK26ebiuJK=tkAdZnuLWpkZg@mail.gmail.com> <CAKFn1SHASt34ihJmGN0iRFQQzLTMspZfxXHgBjBatXXcRYF4cw@mail.gmail.com> <20170604093119.nt733rb3ymmjssww@Vurt.local> <m1dHTLx-0000DcC@stereo.hq.phicoh.net> <CAKD1Yr0ZZwRar6D-2bkXBKPYehqqW99+BMtDOjyovR8WDXKzxw@mail.gmail.com> <CAD6AjGTjikAWutcenW8qn7OW8kPM9c_x_yDUy5vQxJmXKL85dg@mail.gmail.com> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <CAKD1Yr0_WR_TB+OC0U1Qt2h6WzUp9EGvrqC1ZKW2mwFeBd3bCQ@mail.gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <CAAedzxppjnBhVAHF4L4B7WTtwxPGhpOv8ruXOhm=zGwjQ5-OsA@mail.gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <dc950594-cb1a-3c36-4538-3b62f58806ed@gmail.com> <CACWOCC93jbqhw+Pigjx5CdHcAmubcx=nQLbOOtjOb81+u6MQow@mail.gmail.com> <CAJE_bqdcR+-6AxODiokcSRhRNb-5gcbRx0xwBqQ8AeOqYd2Daw@mail.gmail.com> <CAN-Dau08sssc6WnfYL0+7pvC_R5gAdQZu2bKxTyFWcSm0xFh=A@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 08 Jun 2017 21:42:00 +0900
Message-ID: <CAKD1Yr2pxzCb_99UA5aR202OE8hMxc_vSwy5TohzSB2etG-Ftg@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: David Farmer <farmer@umn.edu>
Cc: 神明達哉 <jinmei@wide.ad.jp>, Job Snijders <job@instituut.net>, Erik Kline <ek@google.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a114dd2d215acea0551722ff0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YA_SK6YT-UKp7LYkLqC-jGnqWQ4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Jun 2017 12:42:24 -0000

On Thu, Jun 8, 2017 at 12:13 AM, David Farmer <farmer@umn.edu> wrote:

> I think "should be 64" is the correct language, primarily because "must be
> 64" has been misinterpreted several times to justify hard coding 64 in IPv6
> implementations, but also it seems like a false imperative.
>

Currently the standard says "are 64 bits long". Do we need to change that?
Can we just say "are 64 bits long except when manually configured"?

I think either of these makes it clear 64 bit is the norm, but this should
> not enforced by an IPv6 implementations or hard coded in some way.
>

I have no issue with manual configuration.

However, I think IPv6 implementations that don't support manual
configuration must be able to reject non-64 bit IIDs, since that is the
standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or
/123", and those are against BCP 204 (RFC 7934).

It's not clear to me whether the signatories of this document care about
future IPv6-over-foo documents. They seem to be mostly focused on manual
configuration. However, if we want to say that future IPv6-over-foo
documents can specify non-64-bit IIDs, then that should require formally
updating this document and providing rationale of why the link layer does
not allow the network to follow the addressing best practices in BCP 204.

v2.23.0 | Report a Bug | By Email