Re: New Version Notification for draft-hinden-ipv4flag-00.txt

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 17 November 2017 14:08 UTC

Return-Path: <prvs=1494ff0e50=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 A0B021270B4 for <ipv6@ietfa.amsl.com>; Fri, 17 Nov 2017 06:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham 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 ml2SGuv25tLJ for <ipv6@ietfa.amsl.com>; Fri, 17 Nov 2017 06:08:21 -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 CBFC6120727 for <ipv6@ietf.org>; Fri, 17 Nov 2017 06:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510927699; x=1511532499; 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=VrZjTpEjfBfqEZBWwq533iRNB sKmlGUX2FyT6TGEQQE=; b=dcAsxl0oayuLKdlHa1fKmhYbSjnmG1gLhhbyN1Hb5 2GZTWkb0D8e2hPfUqjbGvqO1wpkASlwkXSqo1TY/9JttNaIiloKKkZCl+KrboCtl jjpl/fRHEF0ZrNsAJim75S38IfIDMhqNvBQ4Z3ZFkvaYDINvB+qijO6YkBCVApkO Qc=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=c29lXP6lQ1oVxOQIgmzTeWpRKJFSZzJqv6EPRKMsXXGNfbJEU+x0uCtitYmS ggFe72rEDzFXFGtacLJl9KoBO2DkpPWvwrlH27q1ru99tLFKgSpDhM11m v4Dc39MxzlSeJZBjjeGqyyDyfWIDs2Ev2Zjhc1bmhxM4P2mXpirjEU=;
X-MDAV-Processed: mail.consulintel.es, Fri, 17 Nov 2017 15:08:18 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 17 Nov 2017 15:08:18 +0100
Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005627015.msg for <ipv6@ietf.org>; Fri, 17 Nov 2017 15:08:17 +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:171117:md50005627015::HUctSD4JhfE/XgBq:00002EBJ
X-Return-Path: prvs=1494ff0e50=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Fri, 17 Nov 2017 22:08:01 +0800
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 List <ipv6@ietf.org>
Message-ID: <F31BAADB-53E6-4014-81FF-90A7ED3AB5D8@consulintel.es>
Thread-Topic: New Version Notification for draft-hinden-ipv4flag-00.txt
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <F6CEDD51-CA7E-45C6-BB79-6309F0B601F1@consulintel.es> <CAN-Dau0SY36Hu4V66rzHVsxF8k_7pWpLhVKEmjCxx1c-5uU7yA@mail.gmail.com>
In-Reply-To: <CAN-Dau0SY36Hu4V66rzHVsxF8k_7pWpLhVKEmjCxx1c-5uU7yA@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lSjQv3tuTvKSPhwdKW3aFPn_mqM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 17 Nov 2017 14:08:23 -0000

I’ve the feeling reading your proposal that you’re assuming that the dual-stack hosts have the transition mechanism built-in. However, this is happening mainly in smartphones when attached to the 3G/LTE link.

If the case is for devices in a home or corporate network, and there is a need for IPv4, then it is the CE or router the one that manages the flag, and in that case, either the CE or router supports some transition mechanism (such as MAP or 464XLAT), or will set the flag to shop “no IPv4 available”.

So, unless I’m missing something, I don’t see the point for changing the flag from the actual text.

Regards,
Jordi
 

-----Mensaje original-----
De: David Farmer <farmer@umn.edu>;
Responder a: <farmer@umn.edu>;
Fecha: viernes, 17 de noviembre de 2017, 21:50
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>;
CC: IPv6 List <ipv6@ietf.org>;
Asunto: Re: New Version Notification for draft-hinden-ipv4flag-00.txt

    I think this is a good start. It covers the basic use case.  However as currently defined, it says IPv4 is definitively not available and means the network will not provide any backward compatibility for IPv4-only hosts. Or for that matter, any early dual-stack hosts that do not support or can not properly initialize a transition mechanism, such as NAT64. Further, if a network operator wants to provide such backward compatibility it must essentially provide a separate service to do so, such as a separate WiFi SSID, and users need to understand the capabilities of there host to select the proper service, which is not auto-configuration, or a very friendly user experience. 
    
    It seems to me if we made a subtle change to the meaning of the flag, a single service could support both IPv6-only and IPv4-only hosts. If the meaning of the flag were modified to indicate that there is either no IPv4 service on the advertising router, or that any IPv4 service provided is intended to be limited to only hosts needing it for backward compatibility.  Primarily intended to support IPv4-only hosts, but could also be used by dual-stack hosts that do not support or can not properly initialize the transition mechanism(s) they support.
    
    How is this different than providing dual-stack service as we know it today?  Full dual-stack service needs to support IPv4 at scale for all hosts on the network, what I'm proposing allows a limited scale legacy IPv4 service to be provided instead of a full scale IPv4 service.
    
    I also suggest a "Host behavior" section be added.  Move the last paragraph of section 2 into it, add that dual-stack hosts that support this flag and properly initialize a transition mechanism that allows communication with other the IPv4-only networks SHOULD NOT initialize their IPv4 stack. Dual-stack hosts that support this flag and that do not support or cannot initialize such a transition mechanism MAY attempt to initialize their IPv4 stack. It is expected that IPv4-only hosts and dual-stack hosts that do not support this flag will attempt to initialize their IPv4 stack.
    
     Thanks.
    
    On Fri, Nov 17, 2017 at 1:21 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>; wrote:
    
    At first sight, looks fine to me.
    
    Regards,
    Jordi
    
    
    -----Mensaje original-----
    De: ipv6 <ipv6-bounces@ietf.org>; en nombre de Bob Hinden <bob.hinden@gmail.com>;
    Responder a: <bob.hinden@gmail.com>;
    Fecha: viernes, 17 de noviembre de 2017, 14:42
    Para: IPv6 List <ipv6@ietf.org>;
    CC: Bob Hinden <bob.hinden@gmail.com>;
    Asunto: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
    
        Hi,
        Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND Router Advertisements.  From the Introduction:
    
           Hosts that support IPv4 and IPv6, usually called dual stack hosts,
           need to work on IPv6 only networks.  That is, a link where there are
           no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
           networks, for example at the IETF 100 meeting in Singapore, shows
           that current dual stack hosts will create local auto-configured IPv4
           addresses and attempt to reach IPv4 services.  A mechanism is needed
           to inform hosts that there is no IPv4 support and that they should
           turn off IPv4.
    
           Because there is no IPv4 support on these links, the only way to
           notify the dual stack hosts on the link is to use an IPv6 mechanism.
           An active notification will be much more robust than attempting to
           deduce this state by the lack of IPv4 responses or traffic.
    
           IPv4-only hosts, and dual-stack hosts that do not recognize the new
           flag, will continue to attempt IPv4 operations, in particular IPv4
           discovery protocols typically sent as link-layer broadcasts.  This
           legacy traffic cannot be prevented by any IPv6 mechanism.  The value
           of the new flag is limited to dual-stack hosts that recognize it.
    
        We were originally thinking it would be an April 1 submission, but after reading the discussion on the IPv6 list, we decided it makes sense as a real submission :-)
    
        Please review and comment.
    
        Thanks,
        Bob and Brian
    
    
    
        Begin forwarded message:
    
        From: internet-drafts@ietf.org
    
        Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
    
        Date: November 17, 2017 at 2:36:31 PM GMT+8
    
        To: "Robert M. Hinden" <bob.hinden@gmail.com>;, "Robert Hinden" <bob.hinden@gmail.com>;, "Brian Carpenter" <brian.e.carpenter@gmail.com>;
    
    
    
        A new version of I-D, draft-hinden-ipv4flag-00.txt
        has been successfully submitted by Robert M. Hinden and posted to the
        IETF repository.
    
        Name:               draft-hinden-ipv4flag
        Revision:   00
        Title:              IPv6 Router Advertisement IPv4 Availability Flag
        Document date:      2017-11-17
        Group:              Individual Submission
        Pages:              5
        URL:            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
        Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
    
    
        Abstract:
           This document specifies a Router Advertisement Flag to indicate that
           there is no IPv4 service on the advertising router.  This document
           updates RFC5175.
    
    
    
    
        Please note that it may take a couple of minutes from the time of submission
        until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>;.
    
        The IETF Secretariat
    
    
    
    
    
    
    
    
        --------------------------------------------------------------------
        IETF IPv6 working group mailing list
        ipv6@ietf.org
        Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
        --------------------------------------------------------------------
    
    
    
    
    **********************************************
    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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    
    
    
    --------------------------------------------------------------------
    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 <tel:(612)%20626-0815>
    Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.