Re: A proposal for draft-ietf-6man-rfc4291bis-07

Iván Arce <> Fri, 03 March 2017 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FDF11295E8 for <>; Fri, 3 Mar 2017 11:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R1gC35AktHlJ for <>; Fri, 3 Mar 2017 11:43:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35CF4129593 for <>; Fri, 3 Mar 2017 11:43:05 -0800 (PST)
Received: by with SMTP id 1so74048025qkl.3 for <>; Fri, 03 Mar 2017 11:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=subject:references:from:to:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ugXKDjyeG9jiOZLtCI77qKOHF0mA2/HQO9mlZst4IQ4=; b=CxjIlJJznV2s4PDfSs8eb2KC/jDtTPKvfERc5wyQzXClyTD4tVFu4qYDudMt8IrLWA zbO7m0wgClf1ZZRaL2PrryC5h25icJMVaMYshP5EhuHN+N8e9RRtYl2hzcA3c/wLE/LF Y7qi0KfszQmiUsnTh1yxoWBtauTM01dmuOvo4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:references:from:to:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ugXKDjyeG9jiOZLtCI77qKOHF0mA2/HQO9mlZst4IQ4=; b=FfbdIfFrY5VMIsHY1zDl5JmPWREPRSuoJb2V+su4diA+OG51Nifpbn/4c2cR80IPT6 zxhoT7chR+IEzSxV5syoBQsA2DcXqwbA0CLy18bPDdZuQST5qe9Zw1k4G9tHvopWiCyY G/bIP0UppuBXanTvgPhDXvY2C7jg6fFcOeizwDhdp3w/yfllDPhIdPQCJ/nHg2eHKc4A PzlETz77z9hL2YBWDzltnDUk9jh/t9BIMEQwTuTuaR6+V4XvK7qE+V1tGjIhv+XK/kXH P2Vx927Kned2cD63Wr/PwSnTO4wdYw4ZvveGPobov6heuh0z2v91GqmP1c9gyC6WIn2S d1tw==
X-Gm-Message-State: AMke39mYBYHhnf0O1MbxO/FOVeM9PbgEJgtX3Rb89Ig9gVM/SjLECL/YZrCWgaPzaUN/yQ==
X-Received: by with SMTP id p36mr4151790qtf.187.1488570183983; Fri, 03 Mar 2017 11:43:03 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 29sm8228147qtn.51.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 11:43:02 -0800 (PST)
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
References: <> <> <>
From: =?UTF-8?Q?Iv=c3=a1n_Arce?= <>
To: 6man WG <>
Organization: =?UTF-8?Q?Fundaci=c3=b3n_Dr._Manuel_Sadosky?=
Message-ID: <>
Date: Fri, 3 Mar 2017 16:43:00 -0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Lightning/4.7.7
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <>
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, 03 Mar 2017 19:43:07 -0000


El 2/3/17 a las 22:49, David Farmer escribió:
> However, if a provider only delegates a /64, this new text ensures that
> prefix could be further subnetted down below /64 using manual config or
> possibly DHCPv6.  This is NOT RECOMMENDED, /64 subnets are RECOMMENDED
> and RFC6177 clearly RECOMMENDS sites be allow more than one /64 subnet.
>     > 3. IIDs are REQUIRED to be 64 bits
>     I thought this interminable last call was specifically because many
>     of us object to this idea. With those exceptions such as SLAAC on
>     Ethernet. Or maybe IIDs should not be longer than 64 bits?
> Variable length IIDs are a BIG CHANGE and it will break current code,
> I'm not sure that is a really good idea.

Is there data about that? Any specifics? Which/whose code?

What is the scope of the alleged problem?

A host OS implementor (OpenBSD) had said on this list that they will NOT
accept /64 as fixed prefix len mandated in a Internet Standard.

Some people on the list say allowing variable length prefix len will
"break existing running code" while others say the exact opposite. There
can't be a rational discussion about this without actual data.

An alternative is to drop the entire discussion on the basis of a
provable argument such as "it will break existing code" and move to a
discussion where arguments for and against are just analyzed in abstract
or where personal preferences, opinions and interests are stated as such.


Iván Arce
Director del Programa STIC
Fundación Dr. Manuel Sadosky
TE: (+54-11) 4328-5164
GPG fingerprint: 4D97 3003 76C9 9DA4 7209  7982 0A1D 10BE CEA9 1B6E