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

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Wed, 07 June 2017 15:26 UTC

Return-Path: <pch-b7900FA3D@u-1.phicoh.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 00AE412951E for <ipv6@ietfa.amsl.com>; Wed, 7 Jun 2017 08:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mwtop9ZLjGMv for <ipv6@ietfa.amsl.com>; Wed, 7 Jun 2017 08:26:46 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24D129458 for <ipv6@ietf.org>; Wed, 7 Jun 2017 08:26:44 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dIcr4-0000FyC; Wed, 7 Jun 2017 17:26:42 +0200
Message-Id: <m1dIcr4-0000FyC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
From: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Sender: pch-b7900FA3D@u-1.phicoh.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>
In-reply-to: Your message of "Wed, 7 Jun 2017 10:13:51 -0500 ." <CAN-Dau08sssc6WnfYL0+7pvC_R5gAdQZu2bKxTyFWcSm0xFh=A@mail.gmail.com>
Date: Wed, 07 Jun 2017 17:26:39 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ll6T_3ohQANA5wgecnnV14FALys>
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: Wed, 07 Jun 2017 15:26:49 -0000

>So I'd prefer; "Interface Identifiers should be 64 bits long except..."
However, I could live with; "Operationally, Interface Identifiers must be
>64 bits long except..."

I don't know if we have to rewrite too many RFC to do the following...

The concept of an IID is only relevant to SLAAC. That's the only place where
a locally generated or configured IID is combined with either a well known
prefix (link local) or a prefix received in an RA.

In the case of SLAAC, IPv6-over-foo documents specify the number of bits of
the IID for that particular link type.

For anything else, manual configuration, DHCPv6 IA_NA we need to get rid of
any implied prefix length when dealing with addresses. An address is just that,
a single address, a /128 if you have to use prefix notation.

Everything is else is in the domain of routing and is irrelevant to assigning
addresses to interfaces.

Ideally, we should try to get software vendors to stop combining addresses
with on-link prefixes in user interfaces, but that may be an uphill battle.