Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

Christopher Morrow <morrowc.lists@gmail.com> Fri, 24 February 2017 16:27 UTC

Return-Path: <christopher.morrow@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 34AD01299CB for <ietf@ietfa.amsl.com>; Fri, 24 Feb 2017 08:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 U-tRzVspxKwz for <ietf@ietfa.amsl.com>; Fri, 24 Feb 2017 08:27:38 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 2B3111299AD for <ietf@ietf.org>; Fri, 24 Feb 2017 08:27:38 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id n127so22829786qkf.0 for <ietf@ietf.org>; Fri, 24 Feb 2017 08:27:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6kv/dsJFWd+T48eZJj+6j07mbvd4g2kAWzVxKMjgYIg=; b=WKTEzqeEWat210Xjb+NW3yyiCOuWEXJvgva6hH4ZqGpRl4uxnOYswHTk9ps64N8SRU Pt5QwCRTKeSMI1l4DWXp4MfACTRXP3fLIkejTuMGmhvf6HOVKDd3yeAH86cIqamYjYLi 8BrFMC9b+ARXOn0rQX9SteP04u/7WHVq0+iRGT7fobTDa9Yc7i96K1D0NmB/cdknraw1 cIreemZQ7HxtL59Ie/ggt5zCAowysJj2xoIO2QboCW3ciuypMw+sImLuDx9PJL2OpB9j zE5s8+yjnl4bhT1dJCvAwCW1m8wpK3KkbVWw7Ui/eMdpKM6nDJsLs6eXkubgb/bxpcB4 z3Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6kv/dsJFWd+T48eZJj+6j07mbvd4g2kAWzVxKMjgYIg=; b=JPGLgrnqFpIPZPhWTp/8vmuqURfO5E0u0ECYh5dd98gNYu5G4FkTF2SlQKaFb/N5iS pO3KkHpvLK28T7Bhy2KpRhfq88WEbGVuViHVP973qxl2fDoTFhMnHGIKt6dBSAihCh7O iZr06Bzt7F9e2/43UQQIXQej6PePT4QBc5uZ+3tEb8dl+rBpOZNJ+nRemX4GmmdMg0x7 ejAeK8wd3AHcclM5FAo077e+mTps3IZKgn4l12PTGa1AeqxjHDCCnxnivEJCPHTYGzrf 0HYCJSKMQJBtNuKILISj7GuyjHPqdXguRhCCVEDdccgTIsJo7WSEIqwkTKIWiKUjmddI ghvg==
X-Gm-Message-State: AMke39kzh6RnAz27d+kQcyEhDtTIQGr79d/gniE2mQSHHjA6XOEroDocf4EG45vd/harhxzh0U5FfgKnL7fBIw==
X-Received: by 10.55.140.134 with SMTP id o128mr3336674qkd.58.1487953657218; Fri, 24 Feb 2017 08:27:37 -0800 (PST)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.91.71 with HTTP; Fri, 24 Feb 2017 08:27:36 -0800 (PST)
In-Reply-To: <bd05771e-1b03-1ee7-2a4c-0a1fe69b8a14@gmail.com>
References: <58AF313D.3020905@foobar.org> <CAO42Z2ymnLm9dUNL3doU9+vR0eMzGbr71HQybbibXq9rCObP3A@mail.gmail.com> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> <CAKD1Yr2Q-AUEWQSXFPzjn73Q7dJhMpB2_iHb3wJTCGx4-==Bpg@mail.gmail.com> <DADB35F5-3CB6-4396-A99F-ECE13C3EFE44@darou.fr> <e89b23b0-b037-995e-fd66-335505ecee61@gmail.com> <CAL9jLaY6RzX6pGFFMcReADudt+ewVtNw_XUYp07_BAVKAp8+hQ@mail.gmail.com> <bd05771e-1b03-1ee7-2a4c-0a1fe69b8a14@gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Fri, 24 Feb 2017 11:27:36 -0500
X-Google-Sender-Auth: LOI5jTc_EiInOcmUR2ZPS8Tqp9Q
Message-ID: <CAL9jLaZJR9YzkF-R9Gx6MWBoJG4cSvp0rovYQ_9BALLzbQGiPQ@mail.gmail.com>
Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0548d82e7cbe0549493566"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VkEBEU1EvN0-14W7g-FwuUIOpOU>
Cc: ietf <ietf@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, 24 Feb 2017 16:27:39 -0000

On Fri, Feb 24, 2017 at 10:48 AM, Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 24/02/2017 à 15:59, Christopher Morrow a écrit :
>
>>
>>
>> On Fri, Feb 24, 2017 at 9:09 AM, Alexandre Petrescu
>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
>>  wrote:
>>
>>
>> A question to Windows is the following: what prefixlen does it set
>> when the end user manually assigns an address on an interface without
>> specifiying a prefixlen?
>>
>>
>> I don't think this matters... 'end users' will in almost all cases
>> just attach and get connectivity.
>>
>
> Let me go next in cycle: what does linux do when one ifconfig add an
> IPv6 address without telling the plen?  Is it adding an entry in the rt
> table?  Which plen?  Is that plen normal?
>
>
still don't think this matters. If a user messes up what they type, they
messed up.
if the instructions aren't complete, they aren't complete and there will be
mistakes.
An interface configuration requires all proper parameters be set, or
problems will arise. Assumptions about current and future behavior are
proven wrong time and again.

non-deterministic behavior over time is the hallmark of this space...
please do not rely on defaults for hand-managed/bespoke configurations if
you expect things to work reliably and repeatably.

If they are in a place where someone says: "Hey, you should go
>> if/ipconfig ...." then .. they are 'consenting adults' and can do
>> whatever they please.
>>
>
> I assume you assume that ip/ifconfig by consenting adults means the
> adults type a plen in the CLI, right?
>
>
sure, or a script/program/etc does this, it's not important how the
'ifconfig' happens, it's important that when it happens the right
parameters are passed to the 'ifconfig' command.


> That makes it mandatory that the CLI _requires_ a plen, right?  That CLI
> should not allow silence for a plen parameter.
>
>
sure, or you are at the mercy of the implementor of that command:
  Today I like /64!
  It's tomorrow and now I like /62!!

don't rely on defaults.


> Because silent plen means 64.  And I dont think it's right to assume a
> by-default 64 plen.  Because many people think 64 is right and others
> think it's wrong, there does not seem to be a commonly agreed 'by
> default' value for plen.
>
>
correct, so.. be specific in your configuration effort please... which
again, means that the 'what is the default?" conversation is moot.


> Alex
>
>
>
>> again the proposed text (now 175+ messages back) really covers this
>> already..
>>
>