Re: Review of draft-ietf-6man-rfc4291bis-06

Mark Smith <markzzzsmith@gmail.com> Fri, 13 January 2017 20:55 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D149129E41; Fri, 13 Jan 2017 12:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8W6XW6rtw6yv; Fri, 13 Jan 2017 12:55:20 -0800 (PST)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 99098129DD5; Fri, 13 Jan 2017 12:55:20 -0800 (PST)
Received: by mail-vk0-x22c.google.com with SMTP id r136so41190997vke.1; Fri, 13 Jan 2017 12:55:20 -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=CaJ/v6v05QmyHsPWn0pFNO/XG1bOX6+iuIjT4hl9oa0=; b=Z9bgxrbNR1Vx1mqOHbJwO6M7vZD0e22dGf0hQCLaTdMoNbGlCPGsmCt7MFibXbJ0rN D7VMwr9f/kqVgYlb1x3QChikICOf5UEs9QBqWt/jaJMiU1JUQ01JzkyV+/PixiOub2WU 0ouP9SRHY2Nw07IA0l6G+6vTb5RBe4jjvDyOwS8mWh8LVPS7ZXLEAQj68G9VyeRH1eTD sk7E5X/WHgH5g7U36OqTJHRKI42FTJ4BQ1V/cXXrh/FRJDT2WptSxIWg9HTq7KaG0Jfj +1JHgLeKFD5K/2V7Q8ZsLVFuqhKFNol7wmCZVEBUc2YVZwgkY2xz1J0uPTvMa/0/YQ5t 3qtg==
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=CaJ/v6v05QmyHsPWn0pFNO/XG1bOX6+iuIjT4hl9oa0=; b=LuHS+ao7wh9K+F/287lAKvp8sycaICTcH/BMcvIh7FNqqynowJ15R4KAm41MQXeKOC LRwCxsjAWgPdjN8hDA/aFBFtMAGXaKoj6bGkHzIwtUCBHpt+MlIVoWVaiMkp+VraVCfW Tefaf46qLwhOsliYrk6oddINBiT3+JrBQ5T/2zLzxcSE4pZbR9/QOAX0dCInWdWxdHU1 BlKsQ1Lq/Q4L1ULX48PNubHzzi0aeYVTIW9zLI8Jh7miFAvL2Bj6oqxWUaVtn3u4h7PK JKszEnOBZ8K9Byr80MYyGB2oIgx+HY6SV1ZjfzC6toF9126f7pUa//Do+k+36yQR+fAi agAQ==
X-Gm-Message-State: AIkVDXI70WSlFwc1JqGZZYdwoneqv4URa2CQ2vpj9c8I/bg8X6UO4f4FE3fnENxdAjuOg4YgKRGZ5Himz1v6Sg==
X-Received: by 10.31.203.132 with SMTP id b126mr8754667vkg.75.1484340919640; Fri, 13 Jan 2017 12:55:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.2.235 with HTTP; Fri, 13 Jan 2017 12:54:48 -0800 (PST)
In-Reply-To: <m2eg07hji4.wl-randy@psg.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <m2fukqbbwv.wl-randy@psg.com> <F6953234-3F85-4E28-9861-433ADD01A490@gmail.com> <m2wpdzhncn.wl-randy@psg.com> <CAN-Dau0Z6aYhitOw8oJ_JQo9N_hzK6yzMe3VosZ7Ch6iV_uaxw@mail.gmail.com> <m2eg07hji4.wl-randy@psg.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 14 Jan 2017 07:54:48 +1100
Message-ID: <CAO42Z2xYD4crEYnCLJiZjS-zeOK2571n5iYoGD9=MCLA-xMbew@mail.gmail.com>
Subject: Re: Review of draft-ietf-6man-rfc4291bis-06
To: Randy Bush <randy@psg.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lWx9mgHbRp0opSKHFVjuyR3sMHo>
Cc: IPv6 List <ipv6@ietf.org>, IETF <ietf@ietf.org>, int-dir@ietf.org, Bob Hinden <bob.hinden@gmail.com>, draft-ietf-6man-rfc4291bis.all@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jan 2017 20:55:22 -0000

On 13 January 2017 at 11:49, Randy Bush <randy@psg.com> wrote:
>>> to be clear, i have no problem with iids being 64-bit.  my issue is with
>>> unicast globals being classful in 2.4.4.
>> Randy I take your point, but this supposed conflict isn't new, it's not
>> introduced in 4291bis, it goes back to RFC3513.
>
> i know; and i have pushed back every cm of the way.  it took years to
> get the other classful insanity, tls/nla, removed.  the old cidr war
> continues.  this last bit of classfulness (excuse the word) too will
> pass.
>
>> Do you have a suggestion how to change this within the context of
>> advancing this to Internet Standard?
>
> yes.  simply remove the mandatory requirement for classful global
> unicast addresses.
>

I think people are combining together in this thread two separate things:

- the addressing structure

- how addresses are processed by routers when the router is forwarding a packet.

In IPv6 they're separate things, in classful IPv4 they weren't (if I
recall correctly).

I think unicast IPv6 could only be described as classful if the
structure of the address dictated how processing of addresses for
forwarding occurred. (You could describe the difference between IPv6
unicast and multicast forwarding to be classful as forwarding is
different for those two types of addresses.)

BCP198/RFC7608, "IPv6 Prefix Length Recommendation for Forwarding"
makes it very clear that forwarding is to occur based on the longest
match rule of an IPv6 address, with no consideration of what the
structure of the address happens to be for the purposes of device
configuration or anything else.

"Abstract

   IPv6 prefix length, as in IPv4, is a parameter conveyed and used in
   IPv6 routing and forwarding processes in accordance with the
   Classless Inter-domain Routing (CIDR) architecture.  The length of an
   IPv6 prefix may be any number from zero to 128, although subnets
   using stateless address autoconfiguration (SLAAC) for address
   allocation conventionally use a /64 prefix.  Hardware and software
   implementations of routing and forwarding should therefore impose no
   rules on prefix length, but implement longest-match-first on prefixes
   of any valid length."


Regards,
Mark.