IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 06 December 2019 15:25 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 797AF120836; Fri, 6 Dec 2019 07:25:43 -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 7_CmWNv0KLDG; Fri, 6 Dec 2019 07:25:42 -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 E3C6412082D; Fri, 6 Dec 2019 07:25:41 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 14C623818F; Fri, 6 Dec 2019 10:22:00 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3E659366; Fri, 6 Dec 2019 10:25:40 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jen Linkova <furry13@gmail.com>
cc: David Farmer <farmer@umn.edu>, dhcwg@ietf.org, V6 Ops List <v6ops@ietf.org>, draft-link-dhc-v6only@ietf.org
In-Reply-To: <CAFU7BASYFEcUgJZUvxi+m4s_GELUQV-2C=UaJ35pBz+zpG1XzA@mail.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>
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: Fri, 06 Dec 2019 10:25:40 -0500
Message-ID: <5391.1575645940@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lXSIpSrw0Wd3pG_cAofAVZ2Nj80>
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: Fri, 06 Dec 2019 15:25:43 -0000

Jen Linkova <furry13@gmail.com> wrote:
    > The draft currently suggests that the server is configured with a
    > dedicated IPv4 address per pool for this purpose:

    > "If the pool is explicitly configured with a dedicated IPv4
    > address to be returned to IPv6-only capable clients the server MUST
    > specify that address as the client's network address and MUST NOT
    > verify its uniqueness.  Otherwise the server SHOULD follow the
    > recommendations in [RFC2131].  The client is not expected to use that
    > IPv4 address so if the client responds with the DHCPREQUEST message
    > for that address the server SHOULD respond with DHCPNAK.
    > "

This is why this document belongs in DHC, because this is new server logic :-)
I think that maybe we are trying to be too cute here.

The goal is not to assign an address, but ciaddr is a fixed field, so we have
to put something in, and I think that we are worried that 0.0.0.0 is going to
confuse DHCP relay nodes that snoop.

At this point, Jen is trying to give the DHCP administrator some rope with
which to work around confusing the snoop node by creating a pool of one
address.

Maybe we can return 225.0.0.1.

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

v2.23.0 | Report a Bug | By Email