IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Tue, 10 December 2019 00:17 UTC

Return-Path: <mellon@fugue.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 1BE17120810 for <v6ops@ietfa.amsl.com>; Mon, 9 Dec 2019 16:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 EN-XeIRkOYNU for <v6ops@ietfa.amsl.com>; Mon, 9 Dec 2019 16:17:38 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 50DE112021C for <v6ops@ietf.org>; Mon, 9 Dec 2019 16:17:38 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id k20so6500099pls.3 for <v6ops@ietf.org>; Mon, 09 Dec 2019 16:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rkB8WEdbNDLZ1YUkeHtzEK4VxhcBloZevEQ1jCmKJOo=; b=P8gw4BBBhCxdXySDRwIS3HPRdm5yYCfHl0M53V7c2xxCN0yNG66oF1LJizwvO0JT+c SbTkRNGvNThE1qrc2ZpO9PvGpredFaphe0cpYFGJeyHDWka4t2Vko0/USDRMId1WjUho JVu1jhE48NxRpaa3Im3QpM/TvXsTtBuqn//T9IQXhc/9KgK00whsinZ0VhO2yY2xwZGW 8YZOQYU2S8prJpPDGUOCwKm6szk/5DDvW3vXKl3Qd7OMCjAjHdKH39RjcKTc+xVybGvE ykynQrnSsITYM6Sr3H66dRoHqfVPJEyK+migLP/hq9ruBqMHOWWO0zNGoH1w4b5TeClO Nj8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rkB8WEdbNDLZ1YUkeHtzEK4VxhcBloZevEQ1jCmKJOo=; b=Y6aZY8YCKVkDw/FsVqmdDjmWXYtQtaqLscSOke/flPmWgjORd/Ofsz+qbiq9JzSnZa I0NnU0Zw7pMoc+IuQbsRwG+HM6eFw9FzgoXysgvXx1TWLgMchvu6Q4VmlnqzY4xFx89/ xWKUfvj/E1S/ms9lV/ml6rSwM41Brea20CZdZWw7nacXfK6yLFeNfdUrWTRWMeAyxLlm KlCdpAWUp5gI79OGZU5lmidnk0IxLPMzVy3mc2oDX2PQqSurjtflj9UfNsBW6LMofkqz V0O/Xk4NcWesb65Qks1eg6vBwUxyzt+BzDTk0uUVP8wF55RWRcIbQDfX6mPFl/8XomNF s/7Q==
X-Gm-Message-State: APjAAAXXNQ/wYDKx91yBvuI9YQdrH6E6j4uZJoLuVntp3dZMDNjQwfv8 oaGU/6ZXMoUbWuX5zEILE8PMYw==
X-Google-Smtp-Source: APXvYqyycvwnJA+Go4Eg+0jlW8ajbHJZCyuQXl2J7WZN6ZgTVHj81Dhhhv3MKvTq3XpIV1i6x4jMIg==
X-Received: by 2002:a17:902:8ec8:: with SMTP id x8mr30800011plo.119.1575937057664; Mon, 09 Dec 2019 16:17:37 -0800 (PST)
Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id e4sm606096pfj.125.2019.12.09.16.17.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 16:17:36 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <0EC7EB9D-1349-4F9C-BD13-A5A85719F5E2@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AE9B261A-C677-47E6-AC81-0E895A7D0257"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\))
Date: Mon, 09 Dec 2019 16:17:35 -0800
In-Reply-To: <d0eabdd2-903f-f9f8-71c6-e3e9470c5613@gmail.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, Jen Linkova <furry13@gmail.com>, V6 Ops List <v6ops@ietf.org>, draft-link-dhc-v6only@ietf.org, dhcwg@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
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> <d0eabdd2-903f-f9f8-71c6-e3e9470c5613@gmail.com>
X-Mailer: Apple Mail (2.3600)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/WIgpUD2rS04J83GyLQR8cDhdqPc>
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: Tue, 10 Dec 2019 00:17:40 -0000

On Dec 9, 2019, at 4:05 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
> The alternative (bogus address or small pool of just one address) is much more tricky to set up and there may be messy corner cases. Every DHCP server I know does various checks if the address belongs to a pool (so setting something completely out of the range could break down various mechanisms), it could mess up statistics and thresholds. The fundamental role every DHCP server is supposed to play is to ensure that the addresses are not duplicated and there are many mechanisms to help ensure that. If we decided to go with bogus address shared by all ipv6-only preferred clients, most (all?) of such mechanisms would have to be conditionally disabled. Let's not do that.

It’s hard to imagine how this could be possible.   You allocate the address, then verify that it’s okay to send?   That’s backwards.  I would expect you to allocate an address that is available and valid to send.  Otherwise you’d have to re-run the allocation algorithm multiple times until you come up with an address that works.  So in fact I think that the allocation algorithm in this case would just be a no-op, and that would not require a lot of extra fuss.

v2.23.0 | Report a Bug | By Email