Re: [v6ops] Please review the No IPv4 draft

Ted Lemon <ted.lemon@nominum.com> Wed, 16 April 2014 13:52 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DCC1A01A7 for <v6ops@ietfa.amsl.com>; Wed, 16 Apr 2014 06:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
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 rF_dZxW3z9X8 for <v6ops@ietfa.amsl.com>; Wed, 16 Apr 2014 06:52:49 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id EF2111A01AA for <v6ops@ietf.org>; Wed, 16 Apr 2014 06:52:47 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F0AB11B8055 for <v6ops@ietf.org>; Wed, 16 Apr 2014 06:52:44 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D2BF619005C; Wed, 16 Apr 2014 06:52:44 -0700 (PDT)
Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Apr 2014 06:52:44 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <60828264-A034-46D2-AFE6-05C984C172E7@delong.com>
Date: Wed, 16 Apr 2014 08:52:42 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <E9D77934-0BCA-42F9-9254-758513EAE822@nominum.com>
References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <F08AF14D-22C6-4F4C-9388-670EB4CD8453@nominum.com> <F2A0EC2F-6B41-4560-88BA-CEBF3E921B61@delong.com> <CAEmG1=oK8iHAms2_uVBsCtpCG7xBdhRfh9QQrd+JXUXgjBPqPA@mail.gmail.com> <534C1A41.1050505@foobar.org> <CAEmG1=qjev-Fkt4tpMSwy4xz-4L5CKow6xBCyiRY7sr7BBoQeA@mail.gmail.com> <BEE692B7-4A6E-44CC-9B2F-C6649C7BE622@delong.com> <534E6FAF.5080503@innovationslab.net> <60828264-A034-46D2-AFE6-05C984C172E7@delong.com>
To: Owen DeLong <owen@delong.com>
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YPUeAh3pFWal5xy6lqvvHWp-SsA
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Please review the No IPv4 draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 16 Apr 2014 13:52:53 -0000

On Apr 16, 2014, at 7:55 AM, Owen DeLong <owen@delong.com> wrote:
> I can see IPv6 transport for DHCPv4 relay information, but using DHCPv6 as a transport to talk to the DHCPv4 client directly seems patently absurd to me.

It gets you the IPv6 relay path information, which you would not get if you sent the request directly.   Doing a v4 shim relay doesn't really get you what you want since you don't want to configure the interface that's connected to the link the relay is connected to.   There's a draft, http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-05, that talks about the why of this, but it needs a bit of work, so the dhcpv4-over-dhcpv6 draft made it into the last call queue first.