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

Brian E Carpenter <> Fri, 13 January 2017 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 226C112940F; Fri, 13 Jan 2017 11:34:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 AfUM_Gnr_TVZ; Fri, 13 Jan 2017 11:34:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 933B81293FC; Fri, 13 Jan 2017 11:34:01 -0800 (PST)
Received: by with SMTP id 127so9551772pfg.0; Fri, 13 Jan 2017 11:34:01 -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=McE9c4oc1E5g2S4SStJ9J3GKVvJGTupaBba1ji543qI=; b=boiLHfJmhNLeXv3Mrei5XLfHldfZClxRrzOUfeMGXAUAO8sHxElTGSf/TJjTXAbXbh rO7D6F7820o8qNfpyrbW0UXet4GBkRhEqgh949XmzfbkkNok8BW+6HFrrYy0pPWnR0VO vPO46+xejiZmJ7RzabsTsme56IAhadaZjzui8OdPxuJjBdrlGIIJOYqYe+jlaBMcfdP6 zgrMJNG0cMIf28sy2bfT2yyor5GUPKnsdTrEUOLwTHOXSHKQtpaP50hCR7BPBkfQ7oy9 LnF8vNAL7/7NkShnciMr4RLXlrIzt8NtPiCf/PmL0haAm22EoDR7KA6EPr/wgfBZl9E9 liMw==
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=McE9c4oc1E5g2S4SStJ9J3GKVvJGTupaBba1ji543qI=; b=or9FVZikkdpkg9YmWQ4n86sZVoIVwKApO8dKongi0cLPac6+oOmVsj30SrScXAJlOR VrdL6b3s3VyFb2KKns6Is2yJygy3wlSZ2RO5fKAX2Jau7gMt5EUsZ0gFpGj0+GOxNDmQ P4bY1657n1T0ju4P0KNK3uTP9UTfKectixnOb8BWPXbrjHTqbkN+JWDwulKTKj5TQUoN 3SA9onAyGF+sMzUVbCLJ8e2yzFBOIKTuS3hmvmOpTsAFNVrTIyXywBBfKiUIAbW/T1DF ZZC7hin5OW9kHg+8GcpvEi7WWrz9rz5tG5ot/5Z+41VrIDSU/vWugpJwOMKXQjBawATe MJsw==
X-Gm-Message-State: AIkVDXICifsqx3o18i9AHxxSLA007Rv77NfTyi7GeHdPTiMa+NNtjoyW9QHIyTm3EEYhnQ==
X-Received: by with SMTP id j62mr12339228pgd.87.1484336041039; Fri, 13 Jan 2017 11:34:01 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id u14sm31047520pfg.18.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:34:00 -0800 (PST)
Subject: Re: AW: Review of draft-ietf-6man-rfc4291bis-06
To: Karsten Thomann <>
References: <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Sat, 14 Jan 2017 08:34:07 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: IETF <>, IPv6 List <>,,
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, 13 Jan 2017 19:34:04 -0000

On 13/01/2017 18:09, Karsten Thomann wrote:
>   Originalnachricht  
> Von: Randy Bush
> Gesendet: Freitag, 13. Januar 2017 01:51
> An: Brian E Carpenter
> Cc: IPv6 List;; Bob Hinden;; IETF
> Betreff: Re: Review of draft-ietf-6man-rfc4291bis-06
>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception.
>> To be precise it says:
>> The de facto length of almost all IPv6 interface identifiers is
>> therefore 64 bits. The only documented exception is in [RFC6164],
>> which standardizes 127-bit prefixes for point-to-point links between
>> routers, among other things, to avoid a loop condition known as the
>> ping-pong problem.
>> I would suggest adding a similar exception statement in 4291bis.
>  just get rid of classful addressing. we went through this
> in the '90s.
> ‎I can only support this, while /127 is a good exception for ptp links, it's still useless for small nets with 4-5 IPs like a network between routers and a Firewall cluster.

Please read RFC 7421. For example

   From an early stage, implementations and deployments of IPv6 assumed
   the /64 subnet length, even though routing was based on prefixes of
   any length.
   The main practical consequence of the existing specifications is that
   deployments in which longer subnet prefixes are used cannot make use
   of SLAAC-configured addresses and require either manually configured
   addresses or DHCPv6.

Nobody is trying to un-CIDRise IPv6. But the price of not applying the
/64 subnet size is that you lose automatic addressing. The 4291bis text
doesn't yet explain this clearly enough.