IETF Logo Mail Archive

Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 04 December 2019 18:22 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC31208C3; Wed, 4 Dec 2019 10:22:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lEKbyHvvOyZ; Wed, 4 Dec 2019 10:22:11 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D625012085B; Wed, 4 Dec 2019 10:22:10 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 03D463818F; Wed, 4 Dec 2019 13:18:32 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5B0CEAAB; Wed, 4 Dec 2019 13:22:09 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List <v6ops@ietf.org>
In-Reply-To: <E03BBE6C-3BED-4D49-8F79-0A1B313EFD9D@apple.com>
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> <E03BBE6C-3BED-4D49-8F79-0A1B313EFD9D@apple.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 04 Dec 2019 13:22:09 -0500
Message-ID: <28594.1575483729@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LGBBq4MoutlHXw_2hjfRp1q7kS8>
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2019 18:22:13 -0000

Tommy Pauly <tpauly@apple.com> 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   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email