Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

james woodyatt <> Fri, 24 February 2017 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A910E12946A for <>; Fri, 24 Feb 2017 10:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id asUV1evWzETA for <>; Fri, 24 Feb 2017 10:10:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61EF7129466 for <>; Fri, 24 Feb 2017 10:10:55 -0800 (PST)
Received: by with SMTP id s67so14181764pgb.3 for <>; Fri, 24 Feb 2017 10:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wJCmgLNumoIgCeWKf2iaMIpjJ6u3OsyPijLOKEjkEK8=; b=urkb7G4lDaFFA6xJMIXCpRpuGsYRsWEw5hdlMgiV6xzt/I9BFm3dRVi/guG8CJ9z6b k5B4SsWLdYDY1cuEekWVKOlH53h/Q7v86RUSeLXuUvmdSX65DQUSGDoK5O7J5s8FVCk9 ZYCChEIeEOF+T426O30nuGqDwBO8RUvL+nYKG3aNGSutOvW1lKCDtrY7TQnLOvt2QH8z eZgNUfJoZnV+yoyZPDNaMnKAW3mbeL3opoxWZKw+nNexRdq8ULp+CojoWjwjKV4s1e2W mjWy/aLB3NgJfQPRqijxbQs5vUTMt+dEp2DCvdP4L0bBs3yew0auYr3xAT1iqTjXiDFv glQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wJCmgLNumoIgCeWKf2iaMIpjJ6u3OsyPijLOKEjkEK8=; b=daZoGRUPIlLavHCCevhZ+7EEd7BkssF2S83Y4GEhIeDFT3fIkleoJuUBjqY4jnMRx5 /qKvpkGdaSnHpeiBtjrlthpqFNOPTV8jmfmwyzGlpAk3W1mOkwOwQycHoYUs7z0Hu0oj RDSm11cZswcYF5eoW22S4GpKpZLKcYlSGLewjO/RQm0N/x1GUPTmkYdmJXBpMUb5kqBG qqGXBO1YNRWIHV2XL68TeoKXzDbBDjfm5fOFWvEtbWWdI7Mw6hyxkEekB6x0+XCtMy0o Ek2mc0czYNRgk6GXpZxIZDyYoR0NXtIFY1MfKa7bBUGrvJIuF8vjB+FevNWDoD/q+vLH qrPw==
X-Gm-Message-State: AMke39mMS8VR3QZn8viOZbfvFOLFYSmz9P58Z9hmrv4qfrxe5BzUhAf7gIM37Jk2B5j5SNEw
X-Received: by with SMTP id b10mr5697484pll.32.1487959854929; Fri, 24 Feb 2017 10:10:54 -0800 (PST)
Received: from ([]) by with ESMTPSA id m6sm16364139pgn.58.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 10:10:54 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4FF54A0E-92EB-479C-B48E-364049869FF3"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Date: Fri, 24 Feb 2017 10:11:03 -0800
In-Reply-To: <>
To: Nick Hilliard <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Feb 2017 18:10:57 -0000

On Feb 24, 2017, at 03:11, Nick Hilliard <> wrote:
> Let me be more specific then: are you proposing that vendors write code
> to allow or disallow interface subnets which aren't /64 (or /127)? This
> is a binary choice; a vendor needs to choose one way or another.

I don’t know how I can be more clear about this: I insist that general purpose host operating system developers should be expressly permitted to write code that declines to accept subnet prefixes of any length other than /64 on the grounds that these are not used in general IPv6 networking and the successor to RFC 4291 continues to say so.

I know there are operating systems with billions of units in the field today that do exactly this because RFC 4291 and its predecessors have for years given them clear license to do so, and I don’t want to see the publication of I-D.ietf-6man-rfc4291bis as RFC come to remove this license as a side effect of promoting IPv6 to full Standard category.

You want to remove that license? I suppose we can continue discussing that, but I think you should try to do it in a separate draft once IPv6 is officially promoted.

--james woodyatt < <>>