Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

[Toerless Eckert <[e-mail]>]

Some more opinions:

I do like the goal of this draft, but not for the long list of mostly wifi
reasons given, but because the link-local IPv4 autoconfiguration
is an operational and diagnostics painpoint when its not necessary.

For example, most users wouldn't even be able to recognize when link-local
IPv4 addresses are being used. Much easier network diagnostics/behavior
to completely disable it automatically when not needed. Whatever the subnet type.

But: Why not simply write a draft stating that RFC3927 should not be performed
or even shut-down when the host has a routed IPv6 address on certain
type of subnets. Such as infrastructure mode WiFi. But maybe not on 
ad-hoc wifi ? In any case, the draft should discuss the benefit of this
RA bit over such non-RA but just host-local heuristics.

I think the assesment of "overload switches in multi-segment wireless network"
is not applicable for normal L2 switches as also said by others on the thread.
However i wouldn't dare to talk to all those convoluted wifi networks with protocols
like CAPWAP (RFC5415). 

The RFC3927 wifi multicast/broadcast send and receive cost should
be quantified. Maybe one can start with the RFC7772 assumption of
7 broadcast/hour = 0.1mA = reasonable limit for background multicast
and see how many order of magnitude one above that line the RFC3927
traffic might be.

Godot will arrive earlier than any randomn set of IP host stacks
would implement a new RA option even if its required to help the
host stacks battery to survive. I am not saying this to discourage the
draft, but rather to say that if the wifi problems can be quantified as
real problematic, then its more important to look for more short term
effective solution options first. Such as operational practices, if not
feature requirements for L2 broadcast filter recommendations on WiFi APs.
That at least seems like the most important short term fix for the
broadcast reception battery cost issue.

Overall, discussion about the wifi problems might better be suited for
analysis in drafts like draft-ietf-mboned-ieee802-mcast-problems first
before drawing conclusions at only the fud/may level. But as said
above, i'd be happy to see steps taken to minimize use of unnecessary
rfc3927 in the absence of wifi or batteries.

Wrt to security: I could not find a description of the case where
an attacker sends the new RA option to kill IPv4 in the presence of
a legitimate IPv4 only & DHCP capable router. How would client
recognize this condition and prohibit the attack ?

"a host SHOULD also choose to not attempt IPv4 operations until an
application asks it to, specifically delay performing DHCPV4 until
it gets a request from an application to use IPv4"

I think this is wishfull thinking wrt. to how applications interact
with available addressing. I am not aware of any API where apps 
can ask the host to get a local IPv4 address if non-yet exist,
and trying to enable IPv4 for example because of the first time when
an app asks the DNS resolver for a name with only A but no AAAA RRs
sounds like a cool project. But in the abence of any such known code
or spec how to do it, the draft should not allude to such wishfull
mechanisms. That should really be an ask from a draft specifically
for that goal: "IPv4 on demand to reach non-IPv6 peers".

Cheers
   Toerless