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

David Farmer <farmer@umn.edu> Fri, 17 November 2017 13:50 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 98FBE126FB3 for <ipv6@ietfa.amsl.com>; Fri, 17 Nov 2017 05:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 SOevx3h3j_m7 for <ipv6@ietfa.amsl.com>; Fri, 17 Nov 2017 05:50:16 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 30042126C19 for <ipv6@ietf.org>; Fri, 17 Nov 2017 05:50:16 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id A52C5C0A for <ipv6@ietf.org>; Fri, 17 Nov 2017 13:50:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5xdBREeO6_Q for <ipv6@ietf.org>; Fri, 17 Nov 2017 07:50:15 -0600 (CST)
Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id EEDF5C37 for <ipv6@ietf.org>; Fri, 17 Nov 2017 07:50:14 -0600 (CST)
Received: by mail-lf0-f72.google.com with SMTP id g35so587242lfi.0 for <ipv6@ietf.org>; Fri, 17 Nov 2017 05:50:14 -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=5eYFL4JghNNvahIRYnhq7TNQfPLghJiF9neyQPwfW/M=; b=a4bYPGq10IKGSuwdd1FVWQHVarNkvxKp2Vkv3brnKZEnohztwCqveuzUFrnquOSIXL FYoDTCxluoqSfzG83nX1Tee6D9gnL6cEGEgXDlFX+FH/HsKPiPq3fzeK4dqa3lHcJkLR yfgR+NEhfLHwNmFpreUaPUIMlNN3WVDPizfpCAX5PRfhIYHcSWXIlCg6XUxxmsP/Zagb VJqrvfcVNymSSuZA2ewYjFOuQ3YCGd8JQQgEbkx6m3O1kALAu6S0H3RulhQxqHsVhjVM MVX6nCSxeHGW3smkJzAyh8JdgpFvu72IXHdjlXg0es14BetJH7tcRXscM5AdjrncHEwE OKUg==
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=5eYFL4JghNNvahIRYnhq7TNQfPLghJiF9neyQPwfW/M=; b=Kk6iKnBbKkZiHF85fNIj355NTHLeko0LKw1p1PzWsCDqiAEVUaZdgkx3kWFqrUrvfc RjE/gh6H4rE5Y/9l6hQezmSJ7oAFieX+sKWks0qd/fhH1mJJvmbb4IyYqlTE9dHnDKD+ yraA/nQHxxkpnnd8/MDE2vRdK9a9Fmy1UHeP9OgpXKOVRdR8wcci0wYNSz48NpFHEF75 hL7gdPcfncNOXiJzD3UE1IdV8G0qS1AGXt+KAnmZ2B/srtLJ8RENFTg4zhY4DPPFlCF8 7RKyiTKJJdgEZ5vHV+oKUhCGZ+c9ZI+k5699QzhL0YZ7P1VThYB1IbKVbh5wPgYnB4zV 1MCw==
X-Gm-Message-State: AJaThX6gKVfh7uYsafWINJPCG8VfAZYPQ7jElwRA3Oaeroe7rszOeQ6S 5iisa+HTUC1xJlDxnlGscoym2Tsaix3D6Mgq+WDhpHfHdianEOVI1cgKNDyVlZd3Klj5O6IVZnU QX32fsIiDuRwphFiD9jQ68ov4
X-Received: by 10.46.7.82 with SMTP id i18mr60957ljd.123.1510926613001; Fri, 17 Nov 2017 05:50:13 -0800 (PST)
X-Google-Smtp-Source: AGs4zMaRjs2Jpm+fy8jyOkFRAF+y9HctLTKl8RpsXKv1o5+Tyz7ZmZduSf1i+6Lj/pEDrIb4x/HoBVjFmOiPWidpKE4=
X-Received: by 10.46.7.82 with SMTP id i18mr60946ljd.123.1510926612687; Fri, 17 Nov 2017 05:50:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Fri, 17 Nov 2017 05:50:12 -0800 (PST)
In-Reply-To: <F6CEDD51-CA7E-45C6-BB79-6309F0B601F1@consulintel.es>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <F6CEDD51-CA7E-45C6-BB79-6309F0B601F1@consulintel.es>
From: David Farmer <farmer@umn.edu>
Date: Fri, 17 Nov 2017 07:50:12 -0600
Message-ID: <CAN-Dau0SY36Hu4V66rzHVsxF8k_7pWpLhVKEmjCxx1c-5uU7yA@mail.gmail.com>
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Jordi Palet Martinez <jordi.palet@consulintel.es>
Cc: IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f736c08071a055e2e0408"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/j1A90guj1FA6SRHvEpxqAo_daqU>
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 13:50:20 -0000

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