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

Job Snijders <job@ntt.net> Mon, 20 February 2017 23:58 UTC

Return-Path: <job@ntt.net>
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 E379F129435; Mon, 20 Feb 2017 15:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Level:
X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 nZCck42Ap_If; Mon, 20 Feb 2017 15:58:05 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 10FEB129413; Mon, 20 Feb 2017 15:58:05 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cfxpy-00032s-PR (job@us.ntt.net); Mon, 20 Feb 2017 23:58:04 +0000
Date: Tue, 21 Feb 2017 00:57:34 +0100
From: Job Snijders <job@ntt.net>
To: draft-ietf-6man-rfc4291bis@ietf.org, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <20170220235734.GA84656@Vurt.local>
References: <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> <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org> <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com> <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yJnMdNkUEsty6fT5WRW3KvY_OOc>
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: Mon, 20 Feb 2017 23:58:06 -0000

On Fri, Feb 17, 2017 at 08:44:20AM +0100, otroan@employees.org wrote:
> 4291:
>    For all unicast addresses, except those that start with the binary
>    value 000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format.
> 
> 4291bis:
>    IPv6 unicast routing is based on prefixes of any valid length up to
>    128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
>    on inter-router point-to-point links.  However, the Interface ID of
>    all unicast addresses, except those that start with the binary
>    value 000, is required to be 64 bits long.  The rationale for the
>    64 bit boundary in IPv6 addresses can be found in [RFC7421]
> 
> Proposal:
>    IPv6 unicast routing is based on prefixes of any valid length up to
>    128 bits [BCP198]. However, as explained in [RFC7421], the
>    Interface ID of unicast addresses is generally required to be 64
>    bits in length, with exceptions only provided in special cases
>    where expressly recognised in IETF standards track documents.

wow, the last sentence of that proposal is overreaching! The text in
4291bis -07 is not ideal either. At this point, I do not believe
rfc4291bis can advance with such text. The contention around unicast
addresses not starting with a binary value 000 must be resolved.

Let's look at the following:

    job@tardis:~$ sudo ip -6 addr show dev eth1
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 2001:728:1808:1::21/126 scope global
           valid_lft forever preferred_lft forever
        inet6 fe80::20d:b9ff:fe41:d4f5/64 scope link
           valid_lft forever preferred_lft forever
    job@tardis:~$ echo HERESY\! a /126\!

Is the IPv6 Addressing Architecture Police (IAAP) gonna come to crack
down on this? What's IETF going to do about this? Nothing! Is this bad?
No. Should there be any tolerance for "IPv6 capable" hw/sw which can't
cope with a /126, /120 or whatever? No.

The main issue for me on this point is that from a pragmatic point of
view, a architecture policy specification should strive to match the
expected deployment reality. I think we can argue that there now is
sufficient deployment experience to admit that all possible IPv6 prefix
lengths are configured.

Referencing RFC7421 is fine, but please realise that in doing so we're
(by proxy) referencing FDDI, ATM, Token Ring and other fascinating
standards from the good ole' days - imho a 7421 ref is just scrambling
for arguments.

Persisting with a 64-bit boundry fixation is actually making the IPv6
address architecture _less_ expressive. When expressiveness is limited
through an arbitrary rule... that's just shortsighted. 

Nobody can claim that we know all use cases (with their respective up
and downsides). However, the few use cases we _do_ know about arrived at
different prefix lengths. Why continue to document exceptions? That is
just busywork. There is no 'one true subnet size'.

Mandating something arbitrary like 'address ID must be 64 bits' when
there is no technical requirement for such rule would be nothing short
of arrogant.

The ND/SLAAC attack vector was real problem, can still be real, why
pretend that that issue doesn't exist by mandating 64-bit IIDs? Any sane
deployment will take steps to cover that risk surface. A valid
mitigation strategy remains to just configure something longer then a
/64 ... like /120

We must accept that we cannot see into the future. Let operators choose.

Kind regards,

Job

ps. The "Write a draft" argument is weak at best, since we are already
are discussing a draft (called 'draft-ietf-6man-rfc4291bis-07.txt'),
which is in IETF Last call, which means it is in a place to discuss the
contents of that draft. No reason to kick the can down the road.