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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 14 February 2017 16:09 UTC

Return-Path: <prvs=1218062e19=jordi.palet@consulintel.es>
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 C3299129668 for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2017 08:09:24 -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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 Xx-L00Dd38NJ for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2017 08:09:23 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3335B129657 for <ipv6@ietf.org>; Tue, 14 Feb 2017 08:09:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487088436; x=1487693236; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=4wRiAOzFSgI8vPyjP+nKDsvYE KvLdUI2KuGh2/+cTYA=; b=jfmg0wLThLwD//4kLmhhzTL1TrWCkkfYs7TygtVuo l4o/zQDuQzgQEd3xHI5sq1P9Oe3IMUIHTeoJDELOmlyWPk1IVveGTX7wx0n5pN4U 1LKlKsQHN6ZN9lH7qYHpbz+FVDAn3N8W5Ucy7Nao8IInCPRMm0bmDVsjCHc2d+G8 AI=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=U2j0POE3G8Lba75LS4XJZ8tJhPPzumZuQYqWdLdTQxgH1Nz2lJjJtm/mLMyJ qhJPG5r0fIW5SdCIXQfaWPjisL8AXz8jVCbS3pBHCceTcfw+OXVzHvNip 4Ywbj2plVJz0Gw+l9o9v5lTZMMqn9LdQK+NGb7j7atkAWkAvcJZ5oU=;
X-MDAV-Processed: mail.consulintel.es, Tue, 14 Feb 2017 17:07:16 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 14 Feb 2017 17:07:15 +0100
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005367324.msg for <ipv6@ietf.org>; Tue, 14 Feb 2017 17:07:14 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170214:md50005367324::0SLeWDNgWPL0SDNT:00001kie
X-Return-Path: prvs=1218062e19=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.1e.0.170107
Date: Tue, 14 Feb 2017 17:07:09 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
Message-ID: <2A163C6E-FFBE-4502-BC2F-0DE8DF88C081@consulintel.es>
Thread-Topic: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
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>
In-Reply-To: <CAN-Dau24tGpEvFEjk7xdu9tyN30bYwB6GmVMQjtKHs8LYFAJMQ@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Zd5V9_BAa9uCG5Hd4NZpRYS3PGg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
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:09:25 -0000

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/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> <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.