Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

Lorenzo Colitti <lorenzo@google.com> Mon, 09 December 2019 06:03 UTC

Return-Path: <lorenzo@google.com>
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 7A9B0120103 for <v6ops@ietfa.amsl.com>; Sun, 8 Dec 2019 22:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 ugCSVa_AapWQ for <v6ops@ietfa.amsl.com>; Sun, 8 Dec 2019 22:03:41 -0800 (PST)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3681200E9 for <v6ops@ietf.org>; Sun, 8 Dec 2019 22:03:41 -0800 (PST)
Received: by mail-io1-xd2f.google.com with SMTP id z26so13462330iot.8 for <v6ops@ietf.org>; Sun, 08 Dec 2019 22:03:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I/ZdrxjcUVUCR02ICzBA2LaIheWWjBZ/5Eacp+v+uv4=; b=p+xsiD+CClbGuTuYHPQpvCQ7PNHj5qK/ok9hR+1ZSztIcFttRd4MdlDiuJYl2rj9nB ch5Ki4fT5TwYR1Ga8ik0XfdRZGEzl6JAbxW3kiqbxCC1zjGZsPpPG7ALpjNgAbH1vi1u IUAkzw+YlO2m96jlyA0b/qeICalGnHs+/ONXWNNw0qPBuH4lHpFLJeRRXGkqjIpdiHqF RXHPMl7glZose50Bpa5u3q9QBqNeLtfB7mc/2MMXSo23Ah3PXFG0WCSRRKNpYUhy10Md xK7jpIzBv7jDAQ8UbydnJJqz0F9/hDcd26KQcDJYWcGldAQ7rcG2b332UTklzdquJ8Jj LRsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I/ZdrxjcUVUCR02ICzBA2LaIheWWjBZ/5Eacp+v+uv4=; b=K+xSnLtfP1PmTdLqbMxENJN8U0h8BNTd5I16GGg5KN+1kgNJZhB9ihD9uyS5us+BQV 36TAiv9T66j/QP3jn1nSMuR2zUPeuKVvZbT1/dNl5oP4xByHlc8TDICZYJ3EYuhp6Vp+ xHVaX3dDC09pl6/ZzJ0cXZtHXTGkAJO7EHv1w+UawufH/264LtxuA4xe3GONNgUT+5r+ MDVdB+W2yWiudBWq0Ioh9zgRmC8SfD39hkRB7qe6a5z7KzpVYRmSj0Y7q7CR5iEZUKLW L0synFK4ZbsCM34K+ocY7tHQx8CA7Dwnvc1ULsu3jz2ZmODUMgIpSvMGWtEHFZaAULDU z9Mg==
X-Gm-Message-State: APjAAAVTPi3NXI/cGfPmdhZyXqlDH8J5/D6L0W0SPTzKa7oWV6k/1BNA JrauZteftn1BcqBkgJP6omiI2N8vo1doJbt55Wd9iA==
X-Google-Smtp-Source: APXvYqzRx4MG8ef7wHdV0Mo7IFfS/d0mHF+nDFwb+4gquwlk3juHsnpxJkuwkDGdNd9b7eJpl480UvezQeyjWbBjUPY=
X-Received: by 2002:a02:2909:: with SMTP id p9mr25844448jap.59.1575871420030; Sun, 08 Dec 2019 22:03:40 -0800 (PST)
MIME-Version: 1.0
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> <E03BBE6C-3BED-4D49-8F79-0A1B313EFD9D@apple.com> <28594.1575483729@localhost> <CAFU7BAQp2-4EwntFj6Nx+be54-fi+gnQmRgT6yS22p=vYugpzA@mail.gmail.com> <CAN-Dau1L_hdRMiGApa7VKuZ0_f5q1NJ-5sHMeg-dtTWa=Tq6bQ@mail.gmail.com> <CAFU7BAS9iMBWkdQF_hwK7squvG9A5f38miS=sWLNns=ZxK4GCg@mail.gmail.com> <CAN-Dau3WswixgY=B9dPwL-hTtxsjm-X-sJ6iXMtpifUAHF12DQ@mail.gmail.com> <CAFU7BASYFEcUgJZUvxi+m4s_GELUQV-2C=UaJ35pBz+zpG1XzA@mail.gmail.com> <CAKD1Yr3OjCsMNM+P2tt9EPrkXDhP+yMptKg-AG3OA1KNbsrqhQ@mail.gmail.com> <DM6PR11MB4137A537075D4D90732F7EB4CF5F0@DM6PR11MB4137.namprd11.prod.outlook.com> <CAFU7BAQXZ40t6w+6WLfqww8wG2Wkke2JGM4P=YnX1HiHAjWksQ@mail.gmail.com>
In-Reply-To: <CAFU7BAQXZ40t6w+6WLfqww8wG2Wkke2JGM4P=YnX1HiHAjWksQ@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 09 Dec 2019 15:03:27 +0900
Message-ID: <CAKD1Yr0R70H=_x3UqtmNWDqWFZLrOEmzFZaJPH7QLLE30XxF4Q@mail.gmail.com>
To: Jen Linkova <furry13@gmail.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, V6 Ops List <v6ops@ietf.org>, "draft-link-dhc-v6only@ietf.org" <draft-link-dhc-v6only@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="00000000000034602205993f28d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Xd-Xy2CE-BQKfVGd7421j3Vv2hg>
Subject: Re: [v6ops] [dhcwg] 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: Mon, 09 Dec 2019 06:03:44 -0000

On Mon, Dec 9, 2019 at 9:54 AM Jen Linkova <furry13@gmail.com> wrote:

> I'm fine with it. I'll remove the reference to a dedicated address to
> return.
> So just to summarise the discussion: we have a number of options on the
> table:
> a) let server just return *an* address from the pool, assuming that as
> the host would not accept the offer anyway, the address will be made
> available again soon;
>    pros:
>       --- no changes on the server side;
>       --- it would look normal to smart middle boxes
>    cons:
>       --- might lead to higher pool utilisation
> b) return some bogus address (0.0.0.0 or smth else)
>     pros:
>        --- client would not be able to assign it (hmm..theoretically)
>       --- optimized pool usage
>    cons:
>       --- requires changes on the server
>       --- might trigger unexpected behaviour on smart middle boxes
> (==> slowing down the adoption)
>
> c) do not offer anything, do smth esle instead (what exactly?)
>
> After writing it down like that I do agree that we shall probably choose
> a) ;)
>

I would change b) "return 0.0.0.0" and add:

d) configure a specific address from the pool for all IPv6-only-capable
clients
    pros:
       --- most efficiently preserves IPv4 addresses. Always works even if
all clients ask for an address at the same time.
   cons:
      --- requires changes on the server
      --- client cannot actually get the address, so if it sends a request,
things won't go well.

In that sense I think b) is a non-starter, and I don't think c) is feasible
either: we do need to return something to the client, otherwise it can't
know that IPv6-only will work, and I don't think there's anything other
than OFFER that the server respond with (I don't think NAK is typically
sent in response to DISCOVER).

So I think we're down to a) offer a regular address from the pool, and d)
offer a bogus address. The draft attempts to do both right now. I wonder if
we could leave d) in the text, but make it clear that it's just a possible
optimization?