Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

[Philip Homburg <[e-mail]>]

>The very first sentence of RFC 4213 Section 2 says, "The most
>straightforward way for IPv6 nodes to remain compatible with IPv4-only
>nodes is by providing a complete IPv4 implementation." You are basically
>suggesting that RFC3927 isn't needed. Which seems to be part of a complete
>IPv4 implementation, at least as far as I can tell.

I assume you notice the informal language that is used there. 

I'm saying that in the context of IPv6 connectivity, RFC 3927 is not needed
unless explicitly enabled by the user.

So the only change is that in the context of IPv6 it would be off by default.

>Yes, we can update it, but we need consensus to do so and doing it the way
>you suggest will break or at least make things that work less reliably than
>they do today, so I'm not sure we'll get consensus for what you suggest.

Indeed that's a good question. It is not clear if anything new is actually
needed. For networks, filtering type 0x800 is good enough. Mobile devices
with limited battery power can probably come up with something on their own.

>The point is RFC3927 is automatic, most of the time you don't even know you
>are using it.  But the easy example of what you break would be printing to
>a local IPv4-Only printer. If the dual-stack host doesn't receive a global
>unicast IPv4 address and it doesn't configure an IPv4 Link-Local address it
>won't be able to print to the local IPv4-Only printer. This kind of thing
>would be rather common in the home network environment, and RFC3927 is
>important when there are issues with the Internet gateway.

This kind of thing could become common in the future, or not.

Today, a mobile host without IPv4 connectivity is dead in the water. IPv4aaS
on LANs is very rare. 

Today, just about every network has a DHCPv4 server.

Like I said before, if there is evidence, that there are lots of production
networks today that combine IPv6 with RFC 3927 (and mobile devices), then yes
my heuristic will not work.

If this is about future networks, then requiring a network to explictly 
support legacy devices by running a DHCPv4 server is a small price to pay.

It would be weird to ask all operators of networks without IPv4 to set a
special flag, for all host to check that flag only to support the
few networks that want to put legacy printers in an IPv6-only network and
don't want to run a DHCPv4 server.

>Then you are saying that it is ok for local access at unmanaged sites to an
>IPv4-Only device can be broken when there is an issue with the local
>gateway.

Yes, that is perfectly fine. In unmanaged sites, when stuff breaks it is
broken. If today, in an unmanaged site, the DHCPv4 server breaks, then you
may have access to the printer but you lost access to the internet. Guess
what most people care about.

There is no expectation that stuff keeps working when routers or servers 
are down. We know about link local, but we are the only ones. For 
everybody else, IPv4 link local is the weird stuff that happens when
DHCP is down.

>Those edge cases you think are so obscure, happen every day in the home
>environments when the provider gateway goes away, and there are IPv4-Only
>devices.

Today, when the CPE is up, you get a DHCPv4 lease. Whether there is an
internet connection or not. If the CPE is off, most likely your wifi
network is down. So we are talking edge cases. The CPE needs to be off and
there needs to be a separate network that is up and connects both the
mobile devices and the printer.

It is not reasonable to require all routers on LANs and all hosts to support
a special flag, just to deal with these kinds of edge cases in a legacy
protocol.