Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

Timothy Winters <twinters@iol.unh.edu> Wed, 18 January 2017 12:57 UTC

Return-Path: <twinters@iol.unh.edu>
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 736CA129692 for <ipv6@ietfa.amsl.com>; Wed, 18 Jan 2017 04:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
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 dZgev3yncJzB for <ipv6@ietfa.amsl.com>; Wed, 18 Jan 2017 04:57:42 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 195E112945B for <ipv6@ietf.org>; Wed, 18 Jan 2017 04:57:42 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id x49so10573809qtc.2 for <ipv6@ietf.org>; Wed, 18 Jan 2017 04:57:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eTS+vNvy1LotjH0y9ogiUFCrWBGynOgy4wFZSiCVI7E=; b=LNHdc9S9+7ETaHFiPc7pCu833ScuaRGAaxYcT8DY3BkfmjNgj9seChF/147U7xLrqC zt9/Nk9IP8sFcJ9wIHPKpZsfAexYaBUmsomxaHCV1K0Yf+cinZZcQmBD3c7VwP+1hkG8 y/xhsjjLeTh5CJlRQFpZf9LSQi8219PQxJij8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eTS+vNvy1LotjH0y9ogiUFCrWBGynOgy4wFZSiCVI7E=; b=dedhgo1EyMZbvjt03DUz/UBgNdjeQ1E4iXgHTmcvms8YgQ+/jovla6JyUwx3E7Kuqr sZaMiEloTuLyyTzA+S7LTmjp6uuUUzp2WPwdE/0oocQvvDwygavssT5wA3JkrM5GW6pG wydAsZz3sp72k062Ie6GqG7DgyCaxryOLXTDzuWrcxIaXeZGhUbTjrgmosShaixnFGnv U/ifqfjSBJwR7r9NQtJIpKnb0w3Gl6AJTMXGRV/i4Jjv1YMB95hmgFPDylg68krplvZj l8IC6D4ocl+Yxze1mRLPhBMKXsL1b3y0Zo1HL35NgASYDwIVgGQP9ZBm2Lo3MOuTuf1v Hk4A==
X-Gm-Message-State: AIkVDXI+H0JgakcTwT/zIkBTaQYYxjK8zVzA3mUHNI+V3tWLCoyLWXmsuD8ze4sqYOkhvFu2zrGFRZl8B6dtg5th
X-Received: by 10.200.39.212 with SMTP id x20mr2502517qtx.109.1484744261149; Wed, 18 Jan 2017 04:57:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.32.202 with HTTP; Wed, 18 Jan 2017 04:57:40 -0800 (PST)
In-Reply-To: <f89ec8e6-3ec3-5c96-1577-d7438cbd6f4b@si6networks.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <fcf580ec-3617-ca5f-5337-37acb6e928ba@gmail.com> <CAKD1Yr25zNeQGvNJa=WzCjKMd9LaYrSwG=o4tUWn1Zc2ASZjrA@mail.gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <CAKD1Yr3wyza0_enWErMhmKKkA1ZOXPv5GG8dMT8HUQZsB5--UQ@mail.gmail.com> <CAAedzxppi5g_S05-m+B2jKMYePapPM0_wMA4XioYgwipwbKVHQ@mail.gmail.com> <CAAedzxoY6MGyvzDvUcZ44ka=5RcGwQ16fzRp29445Pa7mQYNHA@mail.gmail.com> <CAN-Dau36r2UgXPfdcdEAJ914QqvVvjGJK+=mgE9Y2tpBiDSRig@mail.gmail.com> <CAKD1Yr3RpUaNKkyTPHPWWew80cyGkiT1p7vYwfejESP4tQw31A@mail.gmail.com> <CAN-Dau0OsD4RcVUN+me98g6SJ=oaAr4HoqGtP88PTbMU_-kuGQ@mail.gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <CAN-Dau0Fkb-M8VM9iL9xwy89bir5PhNHJ3D1VFrnNppVXNyeOg@mail.gmail.com> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <5c9ea94a40bf4d95b6656debfe24f69b@XCH15-06-11.nw.nos.boeing.com> <f89ec8e6-3ec3-5c96-1577-d7438cbd6f4b@si6networks.com>
From: Timothy Winters <twinters@iol.unh.edu>
Date: Wed, 18 Jan 2017 07:57:40 -0500
Message-ID: <CAOSSMjWkkORD_WVdPa6xcDPGNRCrpCMuWF_n64zAMJo4sLbbpA@mail.gmail.com>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=001a1135b54244ce3305465df6b0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2eC1cdr4vBzYznkJn-spqtxkC9Y>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 18 Jan 2017 12:57:44 -0000

Hi Fernando,

IPv6 Ready Logo have a test that advertises a prefix length of /96 for
SLAAC, with the a flag set and we check that it's used for on-link
determination as per 4862.

"In fact, the advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.

If you read 5.5.3 of 4862 it has some text about prefix length and
interface-id having to add up to 128.

"If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored."

We haven't tried /3 but I'd be happy to try it on implementations to see
what they do if it's interesting to the working group.   My guess is they
will ignore it for SLAAC but use it for on-link.

~Tim

On Tue, Jan 17, 2017 at 9:04 PM, Fernando Gont <fgont@si6networks.com>
wrote:

> On 01/17/2017 09:16 PM, Manfredi, Albert E wrote:
> >> -----Original Message----- From: ipv6
> >> [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> >
> >> I think that the discussion on the IETF list has already shown that
> >> there is no consensus for the current text. I don't agree with it
> >> any more, either. It hides the tension between CIDR and the
> >> consistent length needed for SLAAC.
> >>
> >> Hence I'm still proposing that we change it. I think the median
> >> view at the moment is for the version that runs
> >>
> >> ...  For all currently allocated unicast addresses, except those
> >> that start with the binary value 000, that length should be 64
> >> bits.
> >
> > I think that as things are today, for unicast addresses allocated
> > that may use SLAAC, the "should" might not be strong enough. We have
> > no other implementation of SLAAC, other than one that uses 64-bit
> > IIDs. But I agree with you, when you said that future implementations
> > may not require 64-bit IIDs for SLAAC.
> >
> > But I completely concur with your point about tension with CIDR. In
> > fact, one thing that has always bothered me about the wording "all
> > currently allocated unicast addresses, except those that start with
> > the binary value 000," is that it sounds like the 64-bit IID rule
> > holds for the majority of the unicast address space. But that's not
> > true. Only 1/8 of the total address space is "currently assigned to
> > unicast," and a subset of that 1/8th has the stipulation that the
> > IIDs can be of any length.
> >
> > But the majority of the unicast address space is unconstrained, as it
> > should be. Somehow, it always ends up sounding the 64-bit IID is a
> > fixture, in most IPv6 unicast.
>
> Has anyone tred what happens if a prefix from::/3 is advertised for slaac?
>
> I wouldn't be surprised if, if we happen to want to use non-64 IIDS for
> ::/3, we find that we cannot because this 64-bit value is hardcoded
> everywhere.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR