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

Brian E Carpenter <> Fri, 24 February 2017 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CA9E1294E8 for <>; Fri, 24 Feb 2017 11:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 R3w9wTKNV3ic for <>; Fri, 24 Feb 2017 11:48:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13BB41294DB for <>; Fri, 24 Feb 2017 11:48:16 -0800 (PST)
Received: by with SMTP id b129so15117091pgc.2 for <>; Fri, 24 Feb 2017 11:48:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pATBYjPMEs9TiUI1BLno2ejumxRrH3RUcgma1hzcEYk=; b=U+t7+Ir8e7BtByuDVeHueH/JPuUBEmm88srwnzXvOXxJ5XcnhpyqXxQCByXDlSAgOp mREALIkX8VWIFdPRSFnp6svktEcggZGkNL2kw8+53s/1FJVYolkEsnIYUPIqlH652QOa 2KdM9UFClHzjCsD9TeXtLyZHeMxt6eYp4w+3r3m162iou6G6BJJAs8FwJib8lCVLwCxD 2C45CU1l6+3O1motTHNYG0UFFL4lXtMsAX1laKaR554UlE/cqkyQ+lwxeIpG8PeNhpOy 1Gv5m5pf9f+4PbF6z6Sv8VDzMu5ompfLNNbDCcCjbvR454j4WKDuNOBzje+dk2h6vkXQ YxYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=pATBYjPMEs9TiUI1BLno2ejumxRrH3RUcgma1hzcEYk=; b=U8kffVCscetfpN7smPQAGb115lx1kmQg48uwYDt9n0ALSDyzdqa7tQbVTVrgEF8LAf ElDbye4L3QgrYs67wAfV5o1Zw0VutVF9nQSagQemiu++x16DChihrLoBQsmg+CcA5BrC 3LThndQZrEWVqQ9jXL2oOkytcGZVZ+wcZjIlUEVVy9G/ifIITRgTRJ21TYlMmLMpA43g 12/A200J8MAwK9wvxFwCubD5085jCTC+KB5BQ7P9EKcMsTdWFyKzUlPrYHpm1Hk/Q3Sv qR24hoeNB3dN1QPotDdLJsrPV5qQGfLggxvEk3X59myw/e+wzDVlRxW95zG5TbAer5hw 4DCA==
X-Gm-Message-State: AMke39mAbajbNGVEUPkvs/by1kbUFLnIJDqh9Hoee3WjfDFkoyJBpK+8S5a8HvmcUbdtIA==
X-Received: by with SMTP id a23mr5698002pfh.18.1487965695656; Fri, 24 Feb 2017 11:48:15 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id h3sm16519445pfc.82.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 11:48:15 -0800 (PST)
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: "Manfredi, Albert E" <>, james woodyatt <>
References: <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Sat, 25 Feb 2017 08:48:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 19:48:17 -0000

On 25/02/2017 08:10, Manfredi, Albert E wrote:
> From: ipv6 [] On Behalf Of james woodyatt
>> 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.
> But this is exactly why RFC 4291-bis has to get this right. The unicast address space 2000::/3 is the only one that should be so constrained. We need to nip this problem in the bud.

I don't think that specific IANA-delegated prefixes belong in this document.
And a few weeks ago I suggested limiting the /64 rule to currently delegated
address space, and was loudly told "No!". What we need to get across
is the notion that this is a parameter, not a constant, and today's
setting of the parameter is 64. I strongly suspect that the document editor
has got that message and will come up with some new text.