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

[Gyan Mishra <[e-mail]>]

RFC 3927 IPv4 link local use case instance only occurs in a DHCPv4 failed
state where the host failed to get its network configuration.

The goal of the IPv6 only flag is for the host OS to receive this secondary
signal that if the host OS supports the flag it would disable IPv4
operation and when that happens that does break the dual stack model but
that is the goal of the ipv6 only flag is my interpretation as for the use
case for IPv6 only networks.  So as was mentioned the draft implies in my
opinion that rfc 3927 is unnecessary but the goal is to have the host OS
make the decision on whether the flag should be processed and if the OS
processes the flag then it can chose to disable IPv4 if it is not needed
which is the intent of the draft.

The dual stack model works well and I think it is very hard for most
operators including myself to get out of the dual stack mind set that rfc
3927 and 4213 have to be supported and have to work and if that model
breaks then this ipv6 flag option should not be supported which I disagree
that to be a reason to not support the draft.

This flag is for IPv6 only networks so is really mutually exclusive of the
dual stack hosts on the same subnet as all routers on the same subnet would
be sending the flag set to 1 as secondary signal if no offer is received
and the host does not have IPv4 network access then at that point IPv4 can
be disabled if the OS supports and there is no harm in doing so.

Once the IPv4 DHCPv4 fails and the host are in IPv4 link local mode with no
network access so at that point in time they are ready to receive this
secondary signal and process the ipv6 only flag set to 1 so that IPv4 can
be disabled.

The flag to me would be useful in migration of enterprises quickly to IPv6
and not have to support two protocols and the administrative  overhead of
supporting both and IPv4 & IPv6 addressing plan.  So to me this flag seems
like a great way to get all access network within the enterprise quickly
migrated to IPv6 only subnet.  I think would help break up the dual stack
dependency as well and allow for flatter larger L2 networks.  I think their
are a lot of advantages and use cases for this flag to be incorporated into
migration from dual stack to IPv6 only networks.

Gyan



On Mon, May 13, 2019 at 1:44 PM David Farmer <[e-mail]> wrote:

>
>
> On Mon, May 13, 2019 at 10:08 AM Philip Homburg <
> [e-mail]> wrote:
>
>> >I don't propose this, I simply contend that it is what RFC3927 and
>> >dual-stack model intends. Per Section 2 of RFC 4213, the dual-stack model
>> >expects dual-stack hosts to be fully compatible with IPv4-Only hosts.
>>
>> RFC 4213, Section 2.1 starts with:
>> "Because the nodes support both protocols, IPv6/IPv4 nodes may be
>> configured with both IPv4 and IPv6 addresses."
>>
>> Nowhere does RFC 4213 Section 2 say that IPv4 address configuration has to
>> be the same between IPv4-only and dual stack.
>>
>
> 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.
>
>
>> Beyond that, IPv4 is a legacy protocol. There is no reason we can't
>> publish
>> a RFC that updates a RFC from 2005.
>>
>
> 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.
>
> Some people didn't link the breakage possible with this flag, at least
> before I suggested that it should be a secondary signal and the lack of
> IPv4 DHCPOFFERS should be the primary signal to not configure a global
> scope unicast IPv4 address.
>
>
>> >Further, there are good reasons to require this for compatibility between
>> >dual-stack hosts and IPv4-Only hosts. If dual-stack hosts were to do as
>> you
>> >say and not configure a Link-Local IPv4 address if they have a working
>> IPv6
>> >address they would not be able to communicate with IPv4 Link-Local or
>> >global scope unicast IPv4 addresses on the local link unless they
>> receive a
>> >global scope unicast IPv4 address via DHCPv4. Your proposed change breaks
>> >the dual-stack model.
>>
>> Please provide examples where people are actively using IPv4 link local
>> together with IPv6-only in the case the DHCPv4 server fails.
>>
>
> 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.
>
>
>> I clearly wrote that the user should be able override this behavior. So if
>> a site wants to use IPv4 link local to access legacy devices, then the
>> user
>> would have to change a setting. That's to be expected if you want to use
>> legacy devices in a modern network.
>>
>> IPv4 is a legacy protocol. We should not add protocol complexity just to
>> keep
>> obscure IPv4 features alive.
>>
>
> 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.
>
>
>> >By the way, do you mean any working IPv6 address? Because all IPv6 host
>> >will have an IPv6 Link-Local address. So, do you mean a global scope
>> >unicast IPv6 address?
>>
>> Just an IPv6 link-local is not evidence of IPv6 connectivity. My guess is
>> that checking for any global address is enough. But if a stack wants to
>> go beyond that and make sure that there is global connectivity and access
>> to a DNS resolver then that is fine with me.
>>
>
> I figured that is what you meant, but we need to be specific.
>
>
>> >Without some kind of explicit signal that a network is intended to be
>> >IPv6-Only, per Section 2 of RFC4213 a dual-stack host needs to be fully
>> >compatible with IPv4-Only hosts that could be on the dual-stack network..
>>
>> There is no need to maintain obscure details of a legacy protocol.
>>
>> If IPv4 link locals combined with IPv6 are in active use, then obviously
>> that
>> would make the situation. But, as far as I know, IPv4 link local is
>> useless, except for some rather obscure edge cases.
>>
>
> 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.
>
>
>> For most people, an IPv4 link local just means that DHCP failed. Not some
>> thing you use in a network design.
>>
>
> Yes, but if you want local access to work in the meantime then you need
> RFC3927..
>
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000