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

Brian E Carpenter <> Fri, 13 January 2017 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 781FF12957D; Thu, 12 Jan 2017 16:29:20 -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 BKOVtHmlE3mE; Thu, 12 Jan 2017 16:29:18 -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 CDF7F129580; Thu, 12 Jan 2017 16:29:18 -0800 (PST)
Received: by with SMTP id 127so5550250pfg.0; Thu, 12 Jan 2017 16:29:18 -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=nq2Yh0khVbpCnVF86f7EtEBwM8OsMRRZhQPC6rQAJ58=; b=fJwdA+GFBmpVQdICE14dIXwD83Nai+g5E/nJ+gki5JvAqkRUeIW22yFOL6Ksf19OBm xVWVvIJd7MuhGsxAUmO3T/8uMggk3FiYwsRr6kLA+TOEij9xdqlGMsXVJl3BFpVippI2 aNrydwKqGlml0QPQqy1zgAY4VdLgfBCdM4RFBMFum0Sc3eWGU7cY2u/CVE7e/cxJtvdz 9F3JlxUkFOUTOA6zi5zfJBfFWO+vvf+F0CuFL+yb5nkaIA+F5ED4mJ0mmkoAf0eTblln nQ5Z/K08d0Y/6Maqm5rxtqnrzBQ+2FKCP6Ij9h5VrSAbepuzL/rJgtL9aJU+iQRZRq8x DguA==
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=nq2Yh0khVbpCnVF86f7EtEBwM8OsMRRZhQPC6rQAJ58=; b=oVXEH9a3bXoN3HWLrXy+tdrJhx2pDgI9fHK8W5OD2HYsDqnw+e9ukt4nF9Rl8BljWd ZHYPAOFeIxXzaqB+dLbDXxAnkOXtQu9xUqvkmI5ECKzr6sPSIMLvH58d25jKrFDNx9ap C9Wb7ppVv/ZqJ83ebeleSxl/qEBOkHTe6eO0t+PUTVmjotx9QNA1ljbCMYifELLMvEJc kLBNtXGiU+GbBD8e2jkTonjuvULrxJUYqW5yiMnnS3ww+om6fafGDZ51yacdSuBMzbzC o3yDUiyXV1YJTjTwNnjFm3S5ah8hwK7kCGEDxAlp/H76dW8zBXSJKT/u3x8juL2Zow/x 2ROA==
X-Gm-Message-State: AIkVDXLj8SAQIMc4otEZEcJykV3Uhi01Aujm0o8z+dqpju445OGgIn6EU/sZ9vRGb0028Q==
X-Received: by with SMTP id 34mr25534409plp.37.1484267357375; Thu, 12 Jan 2017 16:29:17 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t87sm19496296pfe.59.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 16:29:16 -0800 (PST)
Subject: Re: Review of draft-ietf-6man-rfc4291bis-06
To: Randy Bush <>, Bob Hinden <>
References: <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 13 Jan 2017 13:29:21 +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:, IPv6 List <>,, IETF <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jan 2017 00:29:20 -0000

On 13/01/2017 12:26, Randy Bush wrote:
>>> but i am having a hard time reconciling 2.4.4's insistence on a
>>> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc
>>> 6141, widespread operational practice, ...  clue bat please.
>> This was discussed extensively in 6MAN and resulted in RFC7421
>> "Analysis of the 64-bit Boundary in IPv6 Addressing”.  The text in
>> rfc4291bis is:
>>    For all unicast addresses, except those that start with the binary
>>    value 000, Interface IDs are required to be 64 bits long.
>>    Background on the 64 bit boundary in IPv6 addresses can be found in
>>    [RFC7421].
> thanks for the review that the wg came to this decision in conflict with
> operational practice and its own statement in 2.4.0.  i did read the
> documents.
> since it is incorrect, ietf last call seems to be the time to fix it.
> to be clear, i have no problem with iids being 64-bit.  my issue is with
> unicast globals being classful in 2.4.4.

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.