Re: Question on anycast IID range(s)

Suresh Krishnan <suresh.krishnan@gmail.com> Thu, 03 January 2019 23:56 UTC

Return-Path: <suresh.krishnan@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 8DE82130DEE for <ipv6@ietfa.amsl.com>; Thu, 3 Jan 2019 15:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bwUPaI8hw8gn for <ipv6@ietfa.amsl.com>; Thu, 3 Jan 2019 15:56:42 -0800 (PST)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 A0F1F129A87 for <ipv6@ietf.org>; Thu, 3 Jan 2019 15:56:42 -0800 (PST)
Received: by mail-yb1-xb32.google.com with SMTP id q2so7127785ybd.12 for <ipv6@ietf.org>; Thu, 03 Jan 2019 15:56:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/nugXkLKU+qQgGTljcTsXJW2quCo8YX3by1jqExw0wM=; b=ezAsBnQhVS3CvNhL079XEGl5HqbskovMF0IVL+dmEhE2Y03QNYV7a7WY2Y9LwIilP3 OJK4/Lxpysi7lAg/ezibMBB2APAXQrztE28l/z1MCBdOkG35HTLQrWMudHR7Bth+mkAR L88w5JnH7j6WiALXeSr+Oe32ZUKQEcmFmempD2syJTAPrdhNeaPD7vz9fQlQbqhNiBaH kVSnHK84p9tDMM+Z6a60JO+cGQG/qL0XZ6Fms0baMV0IsljqY0y+IT2nLspcF+4ufuzJ 5cYcOkC/IrnThQFiga49hjHS64f3F2DN30KsHioUAInjQ7yFV9SvkSnm05MTA+EEBvBL IHOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/nugXkLKU+qQgGTljcTsXJW2quCo8YX3by1jqExw0wM=; b=Mq9p/+kG2WM3LnwKyG6JEvv1BOMe4roE7aHZN1oEDHHEb/h9ExzjzI9D5MfIe7FnHo 4qp1q8eA4q+Jie4FMNYF0KFCGFUsQ8No7PbUAdhwQ2j1E3si8v4o2nAnW8xtxQCUlBgN 3daM3Gw4eJah6J9Fc5GJqQWuof9RVbImxR/hGoiBSMc05aPcMfnQn2LfPkDbKsRWMgOR hVA7ZyC6Evnuw/Qw290+YqU3ofH77nhvbFxL7QJ6tn+SHPvoK3IE/4khxePIYZhdbK+I 8XZZMNG6yXtHnNAmuwe3LOIlSvKU9HWINPFMm9DiVT+uI4SeU2LR43DMgftMkS1SxdQ6 lKjw==
X-Gm-Message-State: AJcUukerGh10iNl8KjrRvnQJpjENGHWWZhX2aETVM7rBWaLMy1ar7h3S O4QkKdZFP9ktDSzX+wn9hZY=
X-Google-Smtp-Source: ALg8bN6hVRrvU8t36uSjb+rYYx0zncPYKuYh0UlOSx6mEPtKBL5sglcauU/LCKoIlpXYf05vUkW2dA==
X-Received: by 2002:a25:2d24:: with SMTP id t36mr24479368ybt.101.1546559801675; Thu, 03 Jan 2019 15:56:41 -0800 (PST)
Received: from [10.0.0.20] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id q187sm20168243ywb.40.2019.01.03.15.56.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jan 2019 15:56:40 -0800 (PST)
From: Suresh Krishnan <suresh.krishnan@gmail.com>
Message-Id: <4F727D6F-BED2-4A7E-96BB-A1F3ECE6C803@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_451D12AF-45F2-4BE6-BB73-BB7BFC14B891"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Re: Question on anycast IID range(s)
Date: Thu, 03 Jan 2019 18:56:39 -0500
In-Reply-To: <60b1edf1-0d5f-62fd-318f-1f30ba02ca2c@gmail.com>
Cc: Kerry Lynn <kerlyn@ieee.org>, ek@loon.co, 6man 6man <ipv6@ietf.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <CABOxzu1O6qd_23xLgpAsx6BiZ09SCNUAgFurOL2UX4HQTvYFCA@mail.gmail.com> <CAAedzxq=AHCD6MSksz4P4ZGVxamStF3x2+xTasJH+oOxFY5H9Q@mail.gmail.com> <CABOxzu3iV7ymCTGESQ20yDtqTBdggo_5yVZquY6vcG+XfEsDQA@mail.gmail.com> <827c7f24-0161-960b-18f6-c451ac471f79@gmail.com> <CABOxzu3fUGjoy29-7=zU2Lky+1oKHQFDSnDcu346xkE8joQ_DQ@mail.gmail.com> <92a6d888-ead1-9b40-1b1c-d9584957214c@gmail.com> <6C9EA505-BAD2-42BE-9E99-680E8CB9FAE9@gmail.com> <60b1edf1-0d5f-62fd-318f-1f30ba02ca2c@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rSAJ-2S_1Fn3ho1Js-T2TXeVLVo>
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 23:56:45 -0000

Hi Brian,

> On Jan 2, 2019, at 11:15 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 2019-01-03 17:01, Suresh Krishnan wrote:
>> <AD Hat off>
>> 
>> Hi Brian/Erik/Kerry,
>> 
>>> On Jan 2, 2019, at 4:52 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> On 2019-01-03 09:37, Kerry Lynn wrote:
>>>> On Wed, Jan 2, 2019 at 2:57 PM Brian E Carpenter <
>>>> brian.e.carpenter@gmail.com> wrote:
>>>> 
>>>>> On 2019-01-03 07:15, Kerry Lynn wrote:
>>>>>> Thanks Erik,
>>>>>> 
>>>>>> My question was ill-posed *and* contained a typo.  I'm really trying to
>>>>>> figure out
>>>>>> which range(s) of IIDs RFC 2526 is trying to reserve for anycast use.  I
>>>>>> now think
>>>>>> the answer is fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff based on RFC 5453
>>>>> and
>>>>>> 
>>>>> https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml
>>>>> 
>>>>> If I take RFC2526 literally, ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff
>>>>> is also reserved, for IIDs not in modified EUI-64 format.
>>>>> 
>>>> That's the problem with RFC2526; at the time it was written there was a
>>>> class of
>>>> IPv6 address that required IIDs to be 64-bits AND in EUI-64 format.  Given
>>>> that the
>>>> latter requirement no longer seems to hold, it would seem the basis for the
>>>> range
>>>> fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff no longer exists.  Yet, this range
>>>> is now enshrined in
>>>> RFC5453 and
>>>> https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml
>>>> 
>>>> But RFC7217 doesn't mention RFC2526, which might be a bug.
>>>>> 
>>>> RFC7217 (and any other proposal for IID generation) should take RFC5453 and
>>>> its associated registry into consideration.
>>> 
>>> It does. But the gap is that RFC5453 doesn't call out
>>> ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff
>> 
>> Looking back at my notes on what became RFC5453, this is not a gap but something I had intentionally left out of RFC5453 based on the addressing usage then. I will try to explain my reason why and we can see if this still makes sense or not. 
>> 
>> According to RFC2526, "for IPv6 address types required to have to have 64-bit interface identifiers in EUI-64 format” the reserved anycast range was only 
>> 
>> FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF
>> 
>> Since RFC4291 defined all the space other than ::/3 to be used only with 64-bit IIDs, and the goal of RFC5453 was to avoid address conflicts for SLAAC (which used 64 bit IIDs due to reasons explored in great detail in RFC7421), this is the range that was put into RFC5453.
>> 
>>> Yes. I've posted an erratum to 5453. At the time, ffff:etc might
>>> have seemed like a corner case, but 2526 did actually cover it.
>> 
>> 2526 covered this *only* for non 64-bit non EUI-64 IIDs. 
> 
> That's not how I read it. IMHO, it covered it for non-EUI-64 IIDs
> of length N, and there's nothing to say that N may not be 64.
> (In fact, our current addressing architecture states that N==64,
> as we all know only too well.)

:-). Yes, we do. The addressing architecture also states in Section 2.5.1. that 

"  For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format."

So if we want to add the omitted range, we need to restrict it to non ::/3 prefixes as well.

> 
>> If we do want to cover the non 64-bit cases then the range Brian suggested above is insufficient (because the IIDs will not fit in the 64-bit range suggested) and would require a more considered change.
> 
> For the specific case of N==64 I don't see that as necessary. 

Agree that the N==64 case works fine but I was talking about whether the WG wanted to cover the non-64-bit cases as well.

Thanks
Suresh