Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

David Farmer <farmer@umn.edu> Tue, 14 February 2017 16:03 UTC

Return-Path: <farmer@umn.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 EA1981295E0 for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2017 08:03:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Level:
X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.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 yxcNpGcnOplt for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2017 08:03:39 -0800 (PST)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39801295A1 for <ipv6@ietf.org>; Tue, 14 Feb 2017 08:03:39 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 2C9CF5D for <ipv6@ietf.org>; Tue, 14 Feb 2017 16:03:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSnRPOfUXQ63 for <ipv6@ietf.org>; Tue, 14 Feb 2017 10:03:38 -0600 (CST)
Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id CB773914 for <ipv6@ietf.org>; Tue, 14 Feb 2017 10:03:38 -0600 (CST)
Received: by mail-vk0-f70.google.com with SMTP id 123so91981965vkm.4 for <ipv6@ietf.org>; Tue, 14 Feb 2017 08:03:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BeUZq8i08TQdL9fMrfZ5+vcksCA6gghqFs/CxfPIN7k=; b=NqWGPAmyWigEOzMFuPPLzXB4cJN3Nxx21RkQ4SbZoVTBLOLlgT+AC/QdwDlyboAsLI 87TrLK9FOrUSFbK2Aw7d6EKbJTgnKWeUMjhbn2N81Rn9ImjbbE/X8UrJWJlfAluoY68E 0MFH+38hwMvKeULuzUiuT9d2HX9mbz8tr2fIob0lNocITRwbQm0qRxZhEMjvtIjfvHX6 3rypnAxiV0wK7HLzYwgZH8si86xcaGDeC7x4gySMetAEfiRXXY70yBNL7Fvnhs9hxNkU XJWYEELiKpOhvZj8cyS9Yiv2rVZQR6AxPazLPLIsPFsF05QxbHGxKlpU356oHWZsKvBF gwZg==
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=BeUZq8i08TQdL9fMrfZ5+vcksCA6gghqFs/CxfPIN7k=; b=ebOkEu/hMwmb2i2quY+1WWLbgjx/cgO51guY5LG54mALFua76p4SoLZd+v0KkfUFTo SOvKn40O6R3MkZrlnOIgL0tsP7t4KQsjSfO9PoTQmYbVFldAys2FfaHuYliPaQu+cLya Px1RE73/S4I598pMt5Ww9AJIIKflLjCxh8iyFyBdSZsQUtmou4+vJB2v1t3yJV86ecgS NbuGQZqmxeis7MISKYfc5MYEOzkzcfN3JHYMNjhTrqFfH2YaNOCGzaTcreJ57AkMHMHs zRAIiV46nYggv/0UIoefcS8VGN15bzaQcGHQUuHOra1Hna4o0CVX5Aih3HgMe5pkMJR/ 86eQ==
X-Gm-Message-State: AMke39k/xLsN0uJL2zyRnOLv5+I1dWSbcRpDyWz9PQ78A0+CdUi18Yr9/XiSrWsuUQjBZ4PCtYGHDhZA1/kiTA9GnP4t0BtBMOvNAsYO+hurUNflJ3C9YgcWLxRXCo+qCEQcOx0BAIHuFj69s1Y=
X-Received: by 10.176.6.3 with SMTP id f3mr13010903uaf.37.1487088218231; Tue, 14 Feb 2017 08:03:38 -0800 (PST)
X-Received: by 10.176.6.3 with SMTP id f3mr13010876uaf.37.1487088217941; Tue, 14 Feb 2017 08:03:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.84.15 with HTTP; Tue, 14 Feb 2017 08:03:37 -0800 (PST)
In-Reply-To: <E780DEC3-F0E9-4A35-B3EA-8D6961775276@consulintel.es>
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <CAN-Dau30OuJ7_57302shrSOs8+sc6iaoDgV27umxb59uwb_pZQ@mail.gmail.com> <E780DEC3-F0E9-4A35-B3EA-8D6961775276@consulintel.es>
From: David Farmer <farmer@umn.edu>
Date: Tue, 14 Feb 2017 10:03:37 -0600
Message-ID: <CAN-Dau24tGpEvFEjk7xdu9tyN30bYwB6GmVMQjtKHs8LYFAJMQ@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Jordi Palet Martinez <jordi.palet@consulintel.es>
Content-Type: multipart/alternative; boundary=94eb2c048440fb71f405487fb403
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mffZ8tEET43-EFX0THaOu9mXVEk>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@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: Tue, 14 Feb 2017 16:03:43 -0000

The problem we want it to be 64 bits except when it's not suppose to be,
such as RFC6164 for point-to-point and RFC6052 for IPv4/IPv6 translators
with /96 Network-Specific Prefix.

On Tue, Feb 14, 2017 at 9:53 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es>; wrote:

> Agree, we shouldn’t change that. Must be 64 bits.
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: ietf <ietf-bounces@ietf.org>; en nombre de David Farmer <farmer@umn.edu
> >
> Responder a: <farmer@umn.edu>;
> Fecha: martes, 14 de febrero de 2017, 16:27
> Para: Brian E Carpenter <brian.e.carpenter@gmail.com>;
> CC: <draft-ietf-6man-rfc4291bis@ietf.org>;, <6man-chairs@ietf.org>;, 6man
> WG <ipv6@ietf.org>;, IETF-Discussion Discussion <ietf@ietf.org>;
> Asunto: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6
> Addressing Architecture) to Internet Standard
>
>     Actually, in addition to your text there still needs to be a
> recommendation for 64 bit IIDs in all other cases.  64 bit IIDs are(and
> should remain) the norm for IPv6, I do not want to change that.  But the
> current language say IIDs are always 64 bit except when an address begins
> with binary 000, leaving no room for any other exception.  And this is
> plainly incorrect, I provided two clear exceptions that are already
> standardized.  Furthermore, IIDs other than 64 bits are in operational use,
> with manual configuration and DHCPv6.
>     So I'd suggest;
>
>     However, the Interface ID of unicast addresses used for
>     Stateless Address Autoconfiguration [RFC4862] is required
>     to be 64 bits long, in all other cases it is recommended to
>     be 64 bits long.
>
>     The other option is to enumerate all the exceptions, requiring the
> document to be updated every time a new exception is standardized.
>
>     On Mon, Feb 13, 2017 at 4:53 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com>; wrote:
>
>     At an earlier stage I suggested restricting the applicability
>     of the "However..." sentence to SLAAC [RFC4862]. A short way
>     of doing this would be
>
>     However, the Interface ID of unicast addresses used for
>     Stateless Address Autoconfiguration [RFC4862] is required
>     to be 64 bits long.
>
>     Regards
>        Brian
>
>     On 14/02/2017 11:32, David Farmer wrote:
>     > I have concerns with the following text;
>     >
>     >    IPv6 unicast routing is based on prefixes of any valid length up
> to
>     >    128 [BCP198].  For example, [RFC6164] standardises 127 bit
> prefixes
>     >    on inter-router point-to-point links. However, the Interface ID of
>     >    all unicast addresses, except those that start with the binary
> value
>     >    000, is required to be 64 bits long.  The rationale for the 64 bit
>     >    boundary in IPv6 addresses can be found in [RFC7421]
>     >
>     > The third sentence seems to limit exceptions to 64 bit IIDs to
> exclusively
>     > addresses that start with binary vale of 000.  There are at least
> two other
>     > exceptions from standards track RFCs, that should be more clear
> accounted
>     > for in this text.  First is [RFC6164] point-to-point links, as
> mentioned in
>     > the previous sentence.  I think the clear intent of [RFC6164] is to
> allow
>     > one(1) Bit IIDs for point to point-to-point links using any Global
> Unicast
>     > Address, not just those that start with 000.  Second is, [RFC6052],
> which
>     > updates [RFC4921] and seems to allow 32 bit IIDs or /96 prefixes for
> any
>     > Global Unicast Address when used for IPv4/IPv6 translation, referred
> to as
>     > ""Network-Specific Prefix" unique to the organization deploying the
> address
>     > translators," in section 2.2 of [RFC6052].
>     >
>     > Thanks.
>     >
>     > On Wed, Feb 1, 2017 at 5:51 PM, The IESG <iesg-secretary@ietf.org>;
> wrote:
>     >
>     >>
>     >> The IESG has received a request from the IPv6 Maintenance WG (6man)
> to
>     >> consider the following document:
>     >> - 'IP Version 6 Addressing Architecture'
>     >>   <draft-ietf-6man-rfc4291bis-07.txt> as Internet Standard
>     >>
>     >> The IESG plans to make a decision in the next few weeks, and
> solicits
>     >> final comments on this action. Please send substantive comments to
> the
>     >> ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments
> may be
>     >> sent to iesg@ietf.org instead. In either case, please retain the
>     >> beginning of the Subject line to allow automated sorting.
>     >>
>     >> Abstract
>     >>
>     >>
>     >>    This specification defines the addressing architecture of the IP
>     >>    Version 6 (IPv6) protocol.  The document includes the IPv6
> addressing
>     >>    model, text representations of IPv6 addresses, definition of IPv6
>     >>    unicast addresses, anycast addresses, and multicast addresses,
> and an
>     >>    IPv6 node's required addresses.
>     >>
>     >>    This document obsoletes RFC 4291, "IP Version 6 Addressing
>     >>    Architecture".
>     >>
>     >>
>     >>
>     >>
>     >> The file can be obtained via
>     >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
>     >>
>     >> IESG discussion can be tracked via
>     >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ballot/
>     >>
>     >>
>     >> No IPR declarations have been submitted directly on this I-D.
>     >>
>     >>
>     >>
>     >>
>     >> ------------------------------------------------------------
> --------
>     >> IETF IPv6 working group mailing list
>     >> ipv6@ietf.org
>     >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     >> ------------------------------------------------------------
> --------
>     >>
>     >
>     >
>     >
>     >
>     >
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > ipv6@ietf.org
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>     >
>
>
>
>
>
>
>     --
>     ===============================================
>     David Farmer               Email:farmer@umn.edu <mailto:
> Email%3Afarmer@umn.edu>;
>     Networking & Telecommunication Services
>     Office of Information Technology
>     University of Minnesota
>     2218 University Ave SE        Phone: 612-626-0815
>     Minneapolis, MN 55414-3029   Cell: 612-812-9952
>     ===============================================
>
>
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
>


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================