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

Christopher Morrow <christopher.morrow@gmail.com> Tue, 21 February 2017 21:52 UTC

Return-Path: <christopher.morrow@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 1CA28129D1A; Tue, 21 Feb 2017 13:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rHPJLzKtnW_2; Tue, 21 Feb 2017 13:52:44 -0800 (PST)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 191D5129D16; Tue, 21 Feb 2017 13:52:44 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id s186so135636152qkb.1; Tue, 21 Feb 2017 13:52:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qQjaaQvrQNo65QPc+j8RymYtN3nl5Z5EQjeZiPSXONc=; b=f12Rkl/Z9iRBSGcN77ZY8J3UbBcC+Ivd3RJllYOxahW8sLtr+s4c5TrAV/o+znu18+ T7FMtxFoMLUbHu7TowjwApPqcpHfw1YiJgLAdfoKPIqQ5UL1id9En7hIgn4pxQkOxv1s 6HCY3IALDisYR4wmPxHTf+xeNr7N/EvuKjJ12YgiP6Ee2CF2mzC4lOMYIf+98MSVelUT /V1/7+PCA0Dn0ztsXO4acpWQNAOAY+ZoXi5OSMjjkwPLUHZkPEaBJg0XxjIWxBQPrMUn fPIIlMyCCx6WdEBMJ9kOaAOWBZ7xy2giC+iYgdtRAJ6GUhFhONFJJKcnTifcgsqKiPEg 37rA==
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=qQjaaQvrQNo65QPc+j8RymYtN3nl5Z5EQjeZiPSXONc=; b=bZKEEp5FcksnWqqOJc9rnUgMo35FdnjY6LrXAaH9nErB34stOUWO/OOZXj5RRyOaV6 nsNbJ4y3fj+gZIRBisEEw6ERrc+QL9w1JNPEc2X4jWBTu+ROLkogj37A00yj4hpvBjlM pPJpwOH83f3bs4Cr2t8T3L9luUSgTkXjg9zCHb/MmuUdcwjBJfAMBrkuPbk7Z3AHwf8/ +6bkhWcX74Zk+MB/ThlVWsfLUf1EXOVGvxTLFmzAJfCpkQX9ggZRCLbSUGe5XVfrMDuc p0eS+K24XcLVPQgw2i0katEkunG6IS/fJvTxdXX2e9hoB7pg4AUH0TnksML+IHH/z8B+ fDcg==
X-Gm-Message-State: AMke39kMV2+MO+gzJRR2TyphvQN09ffoWseMos0lD2522eCOZ561SOBR0ueej5irFLKm+KhOquQFfAQyrhQPKA==
X-Received: by 10.55.200.217 with SMTP id t86mr28482950qkl.5.1487713963154; Tue, 21 Feb 2017 13:52:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.91.71 with HTTP; Tue, 21 Feb 2017 13:52:42 -0800 (PST)
In-Reply-To: <CAO42Z2z6K9tzYCekbyROXR7J1nB9FW53ncTRrW3p3N2P_6WyRQ@mail.gmail.com>
References: <m2y3x6eutl.wl-randy@psg.com> <CAKD1Yr3p=8b9Dmmb9GvGMq1u00xnE2ScmaF_a3FJXiteL=ZhBQ@mail.gmail.com> <20170221172739.GT84656@Vurt.local> <2683353.FOTFeJBnXE@linne> <CAO42Z2z6K9tzYCekbyROXR7J1nB9FW53ncTRrW3p3N2P_6WyRQ@mail.gmail.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Tue, 21 Feb 2017 16:52:42 -0500
Message-ID: <CAL9jLaZMbQaViLm6jms5chDMMYRZym7hN5w_6amACoLx5FqQ4w@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Mark Smith <markzzzsmith@gmail.com>
Content-Type: multipart/alternative; boundary=001a113aa8e84d32d40549116616
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kLdwlY7iu19Nls6ck8_ET_j5ntQ>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
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: Tue, 21 Feb 2017 21:52:46 -0000

On Tue, Feb 21, 2017 at 2:56 PM, Mark Smith <markzzzsmith@gmail.com>; wrote:

> On 22 February 2017 at 06:21, Karsten Thomann <karsten_thomann@linfre.de>;
> wrote:
> > Am Dienstag, 21. Februar 2017, 18:27:39 schrieb Job Snijders:
> >> On Tue, Feb 21, 2017 at 09:49:32AM +0900, Lorenzo Colitti wrote:
> >> > On Tue, Feb 21, 2017 at 8:57 AM, Job Snijders <job@ntt.net>; wrote:
> <snip>
> >>
> >> -------
> >>
> >> OLD:
> >>    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]
> >>
> >> NEW:
> >>    IPv6 unicast routing is based on prefixes of any valid length up to
> >>    128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
> >>    of unicast addresses is required to be 64 bits long. In other use
> >>    cases different prefix sizes may be required. For example [RFC6164]
> >>    standardises 127 bit prefixes on inter-router point-to-point links.
> >>    For most use cases, prefix lengths of 64 bits is RECOMMENDED, unless
> >>    there are operational reasons not to do so.
> >
> > Satisfies my desired outcome of the text, but I would like to modify it:
> >     IPv6 unicast routing is based on prefixes of any valid length up to
> >     128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
> >     of unicast addresses is required to be 64 bits long. An exception is
> for
> >     example [RFC6164] which standardises 127 bit prefixes on
> point-to-point
> >     links. The RECOMMENDED prefix length is 64 bit,
>
>
Firstly, the last update to the suggested text seems great to me. As I see
it, operating a reasonably large mixed-mode network... and some smaller
networks around the place... There are operational reasons why /64 makes
sense, for instance: "I just want all these things to get a v6 address, I
don't really care which one" and SLAAC fits that bill.

For my network interfaces I may (for my own reasons) decide that /127 is
perfect for me, and roll out all NNI type interfaces as /127's (hey, I even
helped with the rfc about this) ... for 'operational reasons' I don't care
about SLAAC, so I don't care about /64... and having to 'break the
standard' seems silly. Yes, this case is already taken care of by
RFC6164... but i have servers on which I don't need SLAAC to manage
addressing and simply assign addresses according to some other
systems-management automation... I even limit the number of devices per
subnet for internal reasons, so I don't need a /64 there, I just need a
/124.

I think the idea that some 'applications' need /64 is fine... but making
'all the things must be /64' just silly, in light of the actual deployment
and use-cases today. Therefore, the text as proposed above seems on target.

There have certainly been plenty of baked-in (to asics and/or software)
assumptions about /64 over the years, we shouldn't want that to happen
longer term and wording like:

  "However, the Interface ID of
   all unicast addresses, except those that start with the binary value
   000, is required to be 64 bits long"

ends up letting people make assumptions again, which get baked into
code/asics :(

It has to be stronger than a RECOMMENDED, because that implies it is
> an arbitrary choice that won't have any protocol operational and
> privacy or security impacts. That is not the case.
>

Someone else pointed out that the 2119 language isn't used/referenced in
4291, looking quickly:
  $ grep MUST rfc4291.txt

  $

seems to agree with that assertion... so I don't think "RECOMMENDED" is
right here, I think: "recommended" is correct.. and that since 2119 isn't
used you can't expect anything in the document to actually be binding :(
whoops! Also, /64 really was an 'arbitrary choice' ... more or less anyway.
Trusting in people to follow without MUST/SHOULD/RECOMMENDED seems a bit
crazy, but :)

thanks job@ for making a suggested fix here, I too am troubled by the
'classful' ideas in the ipv6 space, those didn't seem useful long-term in
ipv4 so I can't see how they would be useful in the short-term here in
v6-land.

I'm really not a fan of the: "But this makes subnetting easy!" arguments...
i don't think those hold water since we have tooling to do subnetting, it's
just not a problem looking for a solution anymore.

-chris