Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Jen Linkova <[e-mail]>]

On Thu, Dec 5, 2019 at 6:53 AM Brian E Carpenter
<[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 hope not and let me explain why I have that hope ;)
AFAIR the main issue with using IPv6 to signal to the host 'pls turn
of IPv4' was that many IPv4-only networks might not have IPv6 security
in place. So an attacker can use IPv6 to a)turn off IPv4 and b) break
IPv6 by sending a rogue RA.

What this draft proposes is to use DHCPv4 to signal to the host 'pls
turn of IPv4' . The same protocol, not IPv6. So there is a shared fate
here - it the network allows rogue DHCP servers then IPv4 is doomed
anyway.  But it's all is working over IPv4, no IPv6 involved.


> On 05-Dec-19 07:22, Michael Richardson wrote:
> >
> > Tommy Pauly <[e-mail]> wrote:
> >     > Thanks for posting this draft! I find it to be both a well-written document, and a great solution.
> >
> > As an author, thank you.
> > I think that this document grew quickly from hallway discussion at IETF106.
> >
> >     > As a client OS vendor, I think this would be easy for the client hosts
> >     > to implement, and we'd likely see a scenario in which pretty quickly,
> >     > most modern mobile devices and laptops would support this, and we'd end
> >     > up with using v4 on networks only for more "legacy" devices.
> >
> > A question that we had was whether or not hosts in a IPv6-mostly network
> > should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts.
> >
> > The DHCPv4 option has a payload value that can be returned with information.
> > Right now, it's a boolean: if the option exists the network is ready.
> > We have considered two things:
> >
> > 1) We could put a time at which the host should recheck for v4.  This avoids
> >    making mis-configuration of IPv6-mostly networks permanent.  The question
> >    is not whether such a recheck timeout should exist (it must); but rather
> >    whether we should allow it to be configured in the option, or if we can
> >    just suggest some implementation local value.
> >
> > 2) Whether or not IPv4-LL (169.254.0.0) addresses should be configured or not.
> >    We could make this an option in the payload here as well.
> >
> > We wind up with four classes of v4-hosts:
> >
> > 1) IPv4-only legacy hosts which do not speak IPv6 at all.
> >    (The old printer in the corner, a whole plethora of stupid Web-Connected IoT devices)
> >    Some might not even have IPv4-LL addresses though!
> >
> > 2) Dual-Stack hosts do not understand this option.
> >    They have IPv4-LL and IPv6-LL addresses as well as IPv6 GUAs and ULAs, so
> >    they can talk to any host on the network.
> >
> > 3) Dual-Stack hosts which have an operational need for IPv4 that is not
> >    satisfied by NAT64, and which therefore either do not include this option,
> >    or for which the network is aware of their need, and does not answer with
> >    the option set.
> >
> > 4) Dual-Stack hosts which turn off their IPv4.
> >    Do they keep IPv4-LL so that they can talk to (1)?
> >
> > [5) IPv6-only capable hosts which never speak IPv4]
> >
> > --
> > ]               Never tell me the odds!                 | ipv6 mesh networks [
> > ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> > ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> >
> >
> >
> > --
> > Michael Richardson <[e-mail]>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> >
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops



-- 
SY, Jen Linkova aka Furry