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

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