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 19:18 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 57FA4129603 for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2017 11:18:33 -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 yKVUfo2OUVBc for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2017 11:18:31 -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 E43A71297DE for <ipv6@ietf.org>; Tue, 14 Feb 2017 11:18:27 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id B009C5C4 for <ipv6@ietf.org>; Tue, 14 Feb 2017 19:18:26 +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 TWYymhFSowke for <ipv6@ietf.org>; Tue, 14 Feb 2017 13:18:26 -0600 (CST)
Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (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 4647325D for <ipv6@ietf.org>; Tue, 14 Feb 2017 13:18:26 -0600 (CST)
Received: by mail-vk0-f72.google.com with SMTP id 78so95697007vkj.2 for <ipv6@ietf.org>; Tue, 14 Feb 2017 11:18:26 -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=BWJI2BCQPDmyv/Jyy0TxV3rQ/+V+7x7JtmxMmeapMGo=; b=F0VQbVZoZFmvsPTyrG5raf94LNSICmLzZ1yG72ztyXVLtGcRYRSNabptSdM0Uy2M+G MyxYls6f1XxwCM4XeWUE+uRg2G4pxO/gNpVIkqVNySR6kIsN4aM05B2EOsLuaAdSHBS4 9U3CJJ2q9KPfidzXrGRIj6ichpL/4Z8ZmyiTQ41fJCO6tnNFQ3SjklDyKN+3Dagt/AQk 5m6bSVLrrCYd0CVRP0qrkV15R/S8SJ8YdH03OPSg4VneCzxCg5tR97vBZ5qzpffydYvw daJizzInYBUs/cP+HmrOj8MMNWTgGHP3BBCEvmFxr/RF8vi8jfKcmOzhlS6xG0fmvH5u VwXA==
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=BWJI2BCQPDmyv/Jyy0TxV3rQ/+V+7x7JtmxMmeapMGo=; b=YmnMlAA7vyWoBJfrDwBuo8eWATNr8jx7NC0shoTRuGLgluw8RxnQ5dQTeLMbDucIy+ fRpRRsHfqkML8y85BfN6oG7pGLg38AlhQXJJwdITJ+XoRHH/Imq191L6u/hcQaQMUWuO pd41ngpn6/X4pK2rLf+QYnxAU2gR8TvbKyGDBV1dwhEea3rY+1/zjhATpCcizX6hij10 fw5iPPdkDkCxWpJ9NA6FJkibLLBEZmj+C8fMlsAlHFQC7GycNRxaxHve14Q1EY81JZte figqUZI1v3mwug2pcvzIt6fsVSxTYOIGUFkLqV6ZgkBcrIyXnUk/o0LwKQgD/XZ6iuHl O+CQ==
X-Gm-Message-State: AMke39mV6GEq3ecgAm4OPV/kyZM9SyUeRIjylWNwAYhV1lyhXRxOZ6bfFHSrZo82uvTcJvkHZOGb5oR3hHmWhzWNKcZ2o83fQWWa/3VZJu49O1U8nHBBmlUC69K2JrPHaps6OrDlBChzyDZvyjg=
X-Received: by 10.31.204.197 with SMTP id c188mr15385585vkg.31.1487099905515; Tue, 14 Feb 2017 11:18:25 -0800 (PST)
X-Received: by 10.31.204.197 with SMTP id c188mr15385574vkg.31.1487099905240; Tue, 14 Feb 2017 11:18:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.84.15 with HTTP; Tue, 14 Feb 2017 11:18:24 -0800 (PST)
In-Reply-To: <2A163C6E-FFBE-4502-BC2F-0DE8DF88C081@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> <CAN-Dau24tGpEvFEjk7xdu9tyN30bYwB6GmVMQjtKHs8LYFAJMQ@mail.gmail.com> <2A163C6E-FFBE-4502-BC2F-0DE8DF88C081@consulintel.es>
From: David Farmer <farmer@umn.edu>
Date: Tue, 14 Feb 2017 13:18:24 -0600
Message-ID: <CAN-Dau2Qv1dww_yxgw_SCx+zmVjXrctkPRoTK9i1x2--zHrxRg@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=001a114dd5d0990a190548826dc5
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mOzHyoKwIrGHisUmbk9653cxnNQ>
Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man WG <ipv6@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 19:18:33 -0000

So I hear you saying something like the following would be appropriate in
your opinion;

However, the Interface ID of all unicast addresses is required to be 64 bit
with the exception of the following; addresses for point-to-point links
[RFC6164], Network-Specific Prefixes used for IPv4/IPv6 Translators
[RFC6052], and addresses that start with the binary value 000.

While this is the less preferred approach as far as I'm concerned, I
believe it resolves the issue I raised.

Thanks.

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

> I understand that, but those are two clear exceptions, no others should be
> “allowed” by default.
>
> Keeping the door open is not good in my opinion. Specific exceptions must
> be taken in consideration one by one.
>
> 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, 17:03
> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>;
> CC: 6man WG <ipv6@ietf.org>;, <draft-ietf-6man-rfc4291bis@ietf.org>;,
> IETF-Discussion Discussion <ietf@ietf.org>;, <6man-chairs@ietf.org>;
> Asunto: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6
> Addressing Architecture) to Internet Standard
>
>     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/l
> istinfo/ipv6
>         >> ------------------------------------------------------------
> --------
>         >>
>         >
>         >
>         >
>         >
>         >
>         > ------------------------------------------------------------
> --------
>         > IETF IPv6 working group mailing list
>         > ipv6@ietf.org
>         > Administrative Requests: https://www.ietf.org/mailman/l
> istinfo/ipv6
>         > ------------------------------------------------------------
> --------
>         >
>
>
>
>
>
>
>         --
>         ===============================================
>         David Farmer               Email:farmer@umn.edu <mailto:
> Email%3Afarmer@umn.edu>; <mailto:Email%3Afarmer@umn.edu <mailto:
> Email%253Afarmer@umn.edu>>;
>         Networking & Telecommunication Services
>         Office of Information Technology
>         University of Minnesota
>         2218 University Ave SE        Phone: 612-626-0815 <tel:
> 612-626-0815>
>         Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel: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 <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 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================