Re: [Technical Errata Reported] RFC5453 (5589)

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 03 January 2019 01:52 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7AE128CF3 for <ipv6@ietfa.amsl.com>; Wed, 2 Jan 2019 17:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8-zEtvAovxw for <ipv6@ietfa.amsl.com>; Wed, 2 Jan 2019 17:52:12 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86E7124BE5 for <ipv6@ietf.org>; Wed, 2 Jan 2019 17:52:12 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id z10so15316088pgp.7 for <ipv6@ietf.org>; Wed, 02 Jan 2019 17:52:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VxmCxo9VWZ9PNZw5ar2LqSUjZS9dYtIkV7TrnQ8xToQ=; b=rpDefXnh+njlWSqeMnNMjOBBoEUBH4iMDKVCMzh54SvMr7cOq5TNBsrEQfkXVUWmKy Sw0FGg2TcvoQCpNZXcmVKVA9XVKTTfS9iY8U6XuuG4NuljQ4AHz+7JI+r6WtWdEsBKYO d27rZL8wuFEOakM0fMpHcf1BzCZ8Nb2fbuwe1HqfFfW1wHzHOlCbk0Gnv9hanf9cqALE H0hR0a6OD8nXjbIf73VoG9D4ddjZAAGLD8bBy9Ap4oYCNVDvgCUPFJQr7+TPCPIHRqLi 7J3c92flq0C03xi4UxYsWqhje0KSMOZ2b7Zxt0o0BguEZNwhjFVVTl8pIa13Q3GNPdMy ZfLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VxmCxo9VWZ9PNZw5ar2LqSUjZS9dYtIkV7TrnQ8xToQ=; b=dVj0QaTgxfJ3LhztAE1OkbKfJ63oOmLahDljtFcdf5cususb5RSvAZGMVecQz0i5b+ wCSQlgn8qUPBmlyW+LJkReo1dV18014+kaEYsk7Tt/CYme8TKnSEg/TYMpufizRklI6b xiA+GWid9jkPdtg+57OU2Z0WYtTGImr0Ml9/z73UqaAa2hod9wzCSN0BkpeefSHSDqrC /DOhIaHWbJ80GmstpWJ5uabw0Q2BKtMlm238fIwyIDp/2+uxk8ngp47N/MK4KAwSFt+R 2TmqNMdJFiix84NluGPifkKoYpJ6iLem0oFmyA9v4oMOlN+5XdKdc+8TMm7TAB5S4qQL /qcg==
X-Gm-Message-State: AJcUukcMuxujRKVtqPaDA4VvdnYaMWRVf+k37JcoJVBMlFa788u7F2o9 Qv3S218M3V4cLgRJIRVCYZ0oVdZMECY=
X-Google-Smtp-Source: ALg8bN77v9OdkdIBDayAskucs+NZjbDibcpOyUgE3CUJlF1RPsJH1iFfuw2gq2b8jvB9Sw/fKtXG8g==
X-Received: by 2002:a63:7c41:: with SMTP id l1mr42995591pgn.45.1546480331606; Wed, 02 Jan 2019 17:52:11 -0800 (PST)
Received: from [130.216.38.134] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.134]) by smtp.gmail.com with ESMTPSA id m67sm105718020pfb.25.2019.01.02.17.52.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Jan 2019 17:52:10 -0800 (PST)
Subject: Re: [Technical Errata Reported] RFC5453 (5589)
To: Fernando Gont <fgont@si6networks.com>, RFC Errata System <rfc-editor@rfc-editor.org>, suresh.krishnan@ericsson.com, suresh@kaloom.com, terry.manderson@icann.org, bob.hinden@gmail.com, otroan@employees.org
Cc: ipv6@ietf.org
References: <20190102215136.9450CB80833@rfc-editor.org> <12e62f40-8ec1-3c37-b85f-3ce3b69d20fb@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c320d8a1-df11-3bda-b070-d2a1de9cfb6a@gmail.com>
Date: Thu, 03 Jan 2019 14:52:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <12e62f40-8ec1-3c37-b85f-3ce3b69d20fb@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Xv8yXNM4GnQl5MNcCBkVhSmycVI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jan 2019 01:52:15 -0000

On 2019-01-03 13:54, Fernando Gont wrote:
> On 2/1/19 18:51, RFC Errata System wrote:
> 
> [....]
>> Corrected Text
>> --------------
>>    +-----------------------------------------+-------------------------+
>>    |        Interface Identifier Range       |       Description       |
>>    +-----------------------------------------+-------------------------+
>>    |           0000:0000:0000:0000           |  Subnet-Router Anycast  |
>>    |                                         |        [RFC4291]        |
>>    |                                         |                         |
>>    | FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast |
>>    | FFFF:FFFF:FFFF:FF80-FFFF:FFFF:FFFF:FFFF |    Addresses[RFC2526]   |
>>    +-----------------------------------------+-------------------------+
>>
>>                        Table 1: Current Assignments
> 
> How should we make this into the actual IANA registry?

Well, first some higher authority would have to approve the erratum.
Then I'm pretty sure the AD could simply ask IANA to make the update.

Another interesting question is who will instruct implementers
of RFC7217 to add a check for this case.

>> Notes
>> -----
>> Both these ranges are in fact reserved by Section 2 of RFC2526. Under current recommendations [RFC7217] the FDFF range is no longer recommended for routine use, and the FFFF range is equally likely to occur in a pseudo-random 64-bit IID. Credit to Kerry Lynn for pointing this out.
> 
> The FDFF range still seems to be recommended for routine use of its
> intended usage (i.e., anycast) -- that's why we are avoiding it in e.g.
> RFC721> 
> OTOH, the FFFF range wasn't present in the IANA registry, and might be
> being employed for pseudo-random-IIDs.

Yes, but it's a pretty unlikely problem. I think if we fix the text
and IANA registry now, it's really not going to affect the real world
much.

Rgds
   Brian

> 
> Thoughts?
> 
> Thanks,
>