Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Mark Smith <[e-mail]>]

On Thu, 5 Dec 2019, 10:57 Lorenzo Colitti, <lorenzo=
[e-mail]> wrote:

> On Thu, Dec 5, 2019 at 5:43 AM Nick Hilliard <[e-mail]> wrote:
>
>> > As an ex-author of an ex-draft that suggested using IPv6 to tell
>> > hosts to avoid IPv4, I'm curious to know whether a draft that
>> > suggests using IPv4 to tell hosts to prefer IPv6 will also be accused
>> > of being an operational nightmare.
>>
>> I haven't read the draft yet - and won't get to it for a couple of days
>> - but am also curious about why this approach is better than the other
>> way around :-)
>>
>
> Here are a couple of reasons why we believe this proposal will fare better
> than the IPv6-only flag:
>
>    1. It has a clear goal and clear semantics.  There was little
>    consensus on the meaning of the IPv6-only flag. Did it mean that there was
>    no IPv4 on the link? That the network should not provide IPv4 addresses? Or
>    that hosts should never send packets with IPv4 ethertypes? If the latter,
>    why not drop the packets in the infrastructure? But then, what
>    about link-local? And so on. In contrast, this option's goal is very clear
>    (conserve IPv4 addresses) and its meaning is very clear: here's an IPv4
>    address if you want it, but please don't use it if you don't need it.
>
>
So I haven't read the draft either, although the following applied in the
context of the the IPv6-only flag draft and I think this one.

Why aren't IPv4 (and IPv6) addresses acquired on-demand when the first
application opens an IPv4 (or IPv6) socket, and then released when the last
application closes the last IPv4 socket?

It seems to me that it is really only tradition that devices acquire
network layer addresses when the host boots up or when an interface
attaches to a new link. Devices are acquiring addresses even though there
may never be applications running on the host that use the address.

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).

If all IPv4 on-demand hosts on a link are then only running IPv6 only
applications, IPv4 would not ever appear on the link. Hosts would
effectively switch off IPv4 on links themselves because they don't need it.

More generally, IPv4 would automatically drain away from networks more
hosts exclusively running IPv6 only applications appear. In this scenario,
there would be no need for any out-of-band signalling mechanism to say
switch off IPv4, such as what this draft proposes or what the IPv6-only RA
flag draft proposed.

Some might say they want hosts to acquire addresses for security purposes
of knowing what devices are on a link. However, I can attach to a link,
purposely not acquire an IPv4 (or an IPv6) address, yet spoof packets with
IPv4 or IPv6 addresses. In other words, if you truly want to have an audit
trail of devices that attach to your link/network for security purposes,
you need to do it at layer1 and/or layer 2 at the point of attachment of
the device, not layer 3.


>    1. It is using a protocol that already configures IPv4 to configure
>    IPv4. The IPv6-only flag was trying to affect IPv4 using an IPv6 protocol,
>    and that allows attackers to mount attacks on existing networks that have
>    not deployed IPv6 and thus have no IPv6 security measures in place.
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>