problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 18 November 2017 19:59 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 57B97126D85 for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 11:59:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qCVtYAuYAnQk for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 11:59:28 -0800 (PST)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8661F1200FC for <ipv6@ietf.org>; Sat, 18 Nov 2017 11:59:28 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id b6so4361930pff.10 for <ipv6@ietf.org>; Sat, 18 Nov 2017 11:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qLHRsn9tbwEz3fb0R+2odZyJSVbkYAHbS2oRta1IaHc=; b=NF2Hdrn9lMFe+K3/Ux4Vj44Nd9Fd9yt2Og+xzP9NA6Y8goxNpdM0K8J4uR9zVMcAEg Kp0y0ubfNSOWEDl+ONkRLO2euhaHM3Ybo8/EnPIdwZVLaxMFIsw8Mr82j3LS9F5k+O8j XVnJ5eNznia4FMHOIGslBV/U5LUlDIO5xE6wjZBuc1uxdzmQfoSLLPg/tMesG6dLHvhx uev0jJZQyGcLK4QaTr6MTWivX3/s1xW+jKNiImdku8zGyHjIv8Gz5ubc9zbolzsXxsMN tIXD54ndZ5dgycsYxdIjB6OMdtm+W0WaJKsuA1ETG25EtA+U4nkblOcPexQzS8WJZ/ao sFJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qLHRsn9tbwEz3fb0R+2odZyJSVbkYAHbS2oRta1IaHc=; b=P6xGBO1x1EgF9cMH2Fwilu0td3z9HRMzWYX6GZdQzuSyxTu6QBL7SXQ5OsDrPKMUcW rhTUUYcXjOVcPdw/30G0Hf6s/pFDFRKM5xLEto7FAw+Gq6aM9xbYeUMw0ZmamhbTUQid XUN0nPK1oQZPOsEHgSplX9UGyACUgN7+/pGHyWjBxcbMLZPEXAd2olMsajjNQ+WLNUJv chtuBL0Y2osiLiasdXTWQUkWACjJMDQLp5E2uh0nuvE2zsGG5io4W/HK0bgi49JCUgEF YFDwovPbY1BDqWvCbzZ0aIeYOT5rv5GZA7G39GQlP1tNXe3M2i4MSkvIUm/jQKRrpDGT LlmA==
X-Gm-Message-State: AJaThX7tW10xNtke66hFO/qNl7Wq7yJLB7CnHh55TUWapFI1VdzN42aH LgiLi4W/xNN8H+qMCtzzKyCvPg==
X-Google-Smtp-Source: AGs4zMY+Qnxl+pCrqsPGahnSLkNHcNQEAFpADc0SIH4XOGX9yjk0EuPImPFyMnEmAz+xisUXBVKsbg==
X-Received: by 10.98.234.9 with SMTP id t9mr6164607pfh.92.1511035167681; Sat, 18 Nov 2017 11:59:27 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v28sm12326683pfl.118.2017.11.18.11.59.25 for <ipv6@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 11:59:26 -0800 (PST)
Subject: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <CAFU7BAQKoWPcEFQZgU3k_d0gUL4en6d2pyNq1V4RMNZ6HrSG8w@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
Date: Sun, 19 Nov 2017 08:59:22 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAFU7BAQKoWPcEFQZgU3k_d0gUL4en6d2pyNq1V4RMNZ6HrSG8w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/iQrddIS6I5rdrd5BGIg9pv7IgJ4>
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: Sat, 18 Nov 2017 19:59:30 -0000


Regards
   Brian Carpenter



On 19/11/2017 03:39, Jen Linkova wrote:
> Hi Bob,
> 
> To be honest I'm not convinced that there is a real problem to be solved..
> The draft says
> 
> 'A mechanism is needed  to inform hosts that there is no IPv4 support
> and that they should turn off IPv4.'
> and it would be great to have more detailed problem statement IMHO...

Indeed. If there is no serious problem, don't fix. What I seemed to hear
in Singapore was that people weren't happy with just ignoring the small
amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement
by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
traffic, which is more of a burden for the infrastructure. We need to decide
whether we care.

(As to whether this belongs in 6man or sunset4, that's a secondary question.
As for the other comments on this thread, I am too jet lagged to respond
right now... later.)

     Brian

> 
> It looks to me that when you are saying 'there is no IPv4 support on a
> link' you mean 'a router does not provide IPv4 connectivity'.  However
> it still might be
> IPv4 connectivity within the given broadcast domain and the router has
> nothing to do with it.
> 
> If the problem is 'IPv4 broadcast noise on the link' then it should be
> solved on L2 level and the network should not switch ethertype 0x0800.
> If the problem is 'all those noisy DHCPv4 requests the first-hop
> router has to drop because DHCP relay is not configured' then the
> router interface should not accept IPv4 packets at all, problem
> solved.
> 
> Also it's not clear what a host is supposed to do if it'd been
> receiving RAs with that flag set 0 and at some point subsequent RAs
> started to arrive with that bit set to 1...
> Shall the host stop all IPv4 operations attempts? Basically how that
> information could be updated?
> 
> 
> On Fri, Nov 17, 2017 at 5:42 PM, Bob Hinden <bob.hinden@gmail.com>; wrote:
>> 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.
>>
>> The IETF Secretariat
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 
>