Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Mark Smith <[e-mail]>]

On Fri, 6 Dec 2019, 13:37 Ted Lemon, <[e-mail]> wrote:

> That wasn’t my question. I know how to write one. Can you give me an
> example of one in the wild?  It has to be something that gets serious use.
>

I'm not sure what the point of your question is.

I mentioned my thinking is probably more future and long term because
applications would need to be explicitly IPv6 only. I understand that's not
going to be many today.

The trouble with dual stack applications is that they aren't explicitly
saying whether they want or expect IPv4, IPv6 or both from the network.

Since what the applications want from the network is ambiguous, it's hard
to know if an application would be happy with an IPv6 only network
connection.

Taking IPv4 away from these ambiguous applications always creates a risk of
breaking them.

An application that explicitly said "I only want IPv6" doesn't have that
risk.



> > On Dec 5, 2019, at 17:58, Mark Smith <[e-mail]> wrote:
> >
> > On Fri, 6 Dec 2019 at 12:50, Ted Lemon <[e-mail]> wrote:
> >>
> >> What’s an ipv6-only application?  Normally I would expect an
> application to be stack-neutral.
> >>
> >
> > From RFC 3493:
> >
> > For example, to create an IPv6/TCP socket, applications make the
> >   call:
> >
> >      s = socket(AF_INET6, SOCK_STREAM, 0);
> >
> >   To create an IPv6/UDP socket, applications make the call:
> >
> >      s = socket(AF_INET6, SOCK_DGRAM, 0);
> >
> >
> > For example, this application only listens on IPv4 or IPv6, but never
> both:
> >
> > https://github.com/markzzzsmith/replicast
> >
> >
> > Regards,
> > Mark.
> >
> >
> >>>> On Dec 5, 2019, at 16:59, Mark Smith <[e-mail]> wrote:
> >>>
> >>> On Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti <[e-mail]>
> wrote:
> >>>>
> >>>>> On Thu, Dec 5, 2019 at 9:53 AM Mark Smith <[e-mail]>
> wrote:
> >>>>>
> >>>>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the
> first IPv4 application started running, then when a host is only running
> IPv6 only applications, it would never acquire an IPv4 address because it
> wouldn't need one, meaning never try to use DHCPv4 (so would avoid the
> link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer
> broadcast ARP Requests).
> >>>>
> >>>>
> >>>> Speaking as an OS implementer: how do I know whether an application
> is an IPv4 application?
> >>>>
> >>>
> >>> So these are reasonable questions, and they're uncovering some
> >>> assumptions and a view point I have:
> >>>
> >>> - the hosts in question are commonly single homed (and I should know
> >>> better *, however I would't be surprised if that is the unstated
> >>> assumption of most people when they imagine the scenario being
> >>> discussed)
> >>>
> >>> - the on-demand I'm imagining is inspired by the dial-on-demand that
> >>> used to be implemented with ISDN, triggered by IP traffic. ISDN
> >>> connection establishment happened quickly enough that it was tolerable
> >>> by end-users. If a DHCPv4 transaction occurred within 100 ms, users
> >>> will perceive it as instant - "Response Times: The 3 Important Limits"
> >>> - https://www.nngroup.com/articles/response-times-3-important-limits/
> >>>
> >>> - IPv6 only applications clearly indicate they're IPv6 only, by only
> >>> opening IPv6 sockets.
> >>>
> >>> This latter point is probably a significant difference between what is
> >>> being proposed here and what I'm thinking. My thinking is probably
> >>> about a passive and longer term mechanism that would result in IPv4
> >>> disappearing over time, rather than an active mechanism that purposely
> >>> switches IPv4 off on dual stack hosts.
> >>>
> >>>
> >>> Responding to these points for completeness:
> >>>
> >>>> When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do
> that.
> >>>
> >>> They wouldn't be IPv6 Only applications.
> >>>
> >>>
> >>>> When it creates an IPv4 socket? But what if it's creating an IPv4
> socket for the purpose of connecting to another network on the system
> (e.g., cellular data) that does have IPv4?
> >>>
> >>> Yes, this would be an issue with what I was describing.
> >>>
> >>> What I'm thinking about would probably more result in "IPv6 Only"
> >>> being a host level status on a host, covering all interfaces (1 or
> >>> many), rather than an interface status. In other words, if a host is
> >>> only currently running IPv6 Only applications, then there is no need
> >>> for any IPv4 addresses on any of its interfaces.
> >>>
> >>>
> >>>> When it does a connect() on an IPv4 socket? But what if that's just a
> happy eyeballs stack that is using IPv4 because it might be available?
> >>>
> >>> As above, not an IPv6 Only application if trying to use HE.
> >>>
> >>>
> >>>> What if the app knows it needs IPv4 and will refuse to do any
> networking if it doesn't find an IPv4 address on the system?
> >>>
> >>> Not an IPv6 Only application.
> >>>
> >>>
> >>> I see value in both applications being explicit about what Internet
> >>> Protocol they want to use (e.g. on demand addressing per above), and
> >>> also being agnostic about it.
> >>>
> >>>
> >>>
> >>> Regards,
> >>> Mark.
> >>>
> >>>
> >>>
> >>> (* "The Rapid Rise of the Mobile Multi-Homed Host" -
> >>>
> https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf
> )
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
>