Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Ole Troan <[e-mail]>]

[top-posting]

OK, if this flag is not about providing host configuration, then I suggest we look at this from a different perspective. 

This is about providing meta-information about the link. Does it connect to the Internet / walled garden, free/charge structure etc.

There is existing work on this. prefix-properties, coloured prefixes that led to provisioning domains. And perhaps most appropriate from a layer perspective 802.11u. 

Cheers 
Ole

> On 26 Oct 2018, at 02:52, Brian E Carpenter <[e-mail]> wrote:
> 
>> On 2018-10-25 18:53, Mark Andrews wrote:
>> 
>> 
>>> On 25 Oct 2018, at 4:29 pm, Manfredi (US), Albert E <[e-mail]> wrote:
>>> 
>>> -----Original Message-----
>>> From: Brian E Carpenter <[e-mail]> 
>>> 
>>>> Please read the draft again, since it intends to answer that exact question. (Nick and others have objected to some assertions in the text, but regardless of that... the draft intends to answer your question.)
>>> 
>>>  However, hosts transmitting IPv4 packets would still do so, consuming
>>>  their own battery power and some radio bandwidth.  The intent of this
>>>  specification is to provide a mechanism that prevents such traffic,
>>>  and also works on networks without the ability to filter L2 traffic,
>>>  or where there are portions of a network without the ability to
>>>  filter L2 traffic.  It may also be valuable on unmanaged networks
>>>  using routers pre-configured for IPv6-only operations and where Layer
>>>  2 filtering is unavailable.
>>>  ...
>>>  Because there is no IPv4 support on IPv6-only routers, the only way
>>>  to notify the dual stack hosts that this link is IPv6-Only is to use
>>>  an IPv6 mechanism.  An active notification will be much more precise
>>>  than attempting to deduce this fact by the lack of IPv4 responses or
>>>  traffic.
>>> 
>>> So, the network doesn't want to support IPv4. Is it not possible for the devices on the network to use their own updated heuristics?
> 
> There's certainly no universal heuristic. For example, as I've said before,
> there will be some devices that will never stop trying IPv4 whatever you tell
> them - it doesn't really matter whether those are legacy devices or devices
> whose implementer took a specific decision to ignore the flag. And there
> will probably be devices that don't bother to look at the flag because
> they don't even have an IPv4 stack in the first place.
> 
> I don't see why this matters. There's no interop problem here; the goal is to
> reduce pointless IPv4 traffic, especially multicast. If different hosts
> behave differently, so what?
> 
>> Please go write down the heuristics that you think hosts should use to say “now is the time to turn off
>> IPv4 on this interface” and get it right?  I can’t think of any set of rules that will achieve that.
> 
> No, because there's no universal right answer.
> 
>>> Their own timeout timers, without having to rely on the network admin? This much we already discussed briefly, earlier on. Is it not just as easy to tell device makers that some networks may be dropping IPv4 altogether, and let these device makers do what's right, instead of saying that the network will transit this flag, to achieve that same purpose? Either way, the hosts will need updating. (Some device makers will eventually give IPv6 priority.)
>>> 
>>> In networks where IPv4 can legitimately be dropped, in principle, the admin will have determined that all legitimate hosts can reach everything with IPv6. EtherType filtering primarily protects the network. If no EtherType filtering is possible in parts of the network, then what help is a flag? The hosts that will create nuisance broadcasts would be unable to read that flag anyway, because they are not updated, presumably. Still, the network can simply not route IPv4, not provide IPv4 addresses in the DNS, not respond to DHCPv4 requests. Without EtherType filtering, IPv4 broadcasts would remain a nuisance in those parts of the network, until those users give up. Yes, legacy IPv4 users will be irritated by long waits, and then failure. But no flag will help that. Those hosts are not updated to read the flag anyway. And updated hosts will have the new heuristics, to minimize or prevent these nuisances.
>>> 
>>> For networks that support both stacks, but the equipment vendor is serious about conserving battery power, that device may try IPv6 first, regardless of any flag, would adjust IPv4 timers regardless of any flag, and so on. Just to save power. Why rely on a network admin?
> 
>> Because that really is the ONLY way to determine if a network that could be dual stack should be IPv6-only.
> 
> Right. We're talking about the administrator's *intention* and computers aren't
> very good at guessing human intention.
> 
>> 
>>>  It is expected that on IPv6-Only networks it will be common for
>>>  access to IPv4 external services to be reached by techniques such as
>>>  NAT64 [RFC6146] and DNS64 [RFC6147] at the edge of the network.  This
>>>  is beyond the scope of this document.
>>> 
>>> In this case, flag or no flag, any device with the updated IPv4 timeout timers, and especially those which try first to use IPv6, will be happy. Devices which will instead waste time insisting on IPv4, are not updated, and therefore, they won’t understand any flag.
>>> 
>>>  The intent is that the administrator of the router configures the
>>>  router to set the IPv6-Only flag if she/he wants to tell the hosts on
>>>  the link that the link is IPv6-Only.  This is a configuration flag,
>>>  it is not something that the router decides on it's own.  Routers MAY
>>>  log a configuration error if the flag is set and IPv4 is still active
>>>  on the routers interface to the link.
>>> 
>>> I think I covered that above. It's a bit of a paradigm shift. Even without any new flag, the IETF can make device makers aware of this threat of no IPv4 service in some networks in the near future, and to take their own action. I don’t know how prevalent unmanaged switches are, in parts of the network that a network admin controls, but again, that is for network self-protection, mostly.
> 
> Sure.
> 
> Look, it's entirely possible that we could suggest a heuristic that would work
> for most hosts most of the time *without* this flag, based on tuning the
> timers for DHCPv4 and other IPv4 actions. I think the notion of a v6ops draft
> on this topic is a good one. The authors aren't going to insist on defining
> a flag if there's a convincing case for an operational solution that works
> without one. In the end we're after a statistical solution that stops most
> useless IPv4 traffic most of the time. Because of differing host behaviours,
> you can't stop all useless IPv4 traffic all of the time.
> 
>   Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------