IETF Logo Mail Archive

Re: [v6ops] Please review the No IPv4 draft

Ted Lemon <ted.lemon@nominum.com> Tue, 15 April 2014 15:57 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 EC6991A03A6 for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 08:57:46 -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 BZ5aBy0AFTcW for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 08:57:42 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id C33011A02C7 for <v6ops@ietf.org>; Tue, 15 Apr 2014 08:57:42 -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 409451B8055 for <v6ops@ietf.org>; Tue, 15 Apr 2014 08:57:40 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (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 2D70519005C; Tue, 15 Apr 2014 08:57:40 -0700 (PDT)
Received: from [172.16.0.175] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 08:57:39 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <534D1966.5090301@foobar.org>
Date: Tue, 15 Apr 2014 10:57:38 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6D57B3D8-DAF4-4792-BDF5-B0489A283F6B@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> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <B3942C2F-C08E-42F2-9038-92C3C63E0023@nominum.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FtcIcUC0Q8XckByshn2zySGbqSE
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: Tue, 15 Apr 2014 15:57:47 -0000

On Apr 15, 2014, at 6:35 AM, Nick Hilliard <nick@foobar.org> wrote:
> This is not an especially relevant argument because if there were a dhcpv4
> option to handle this, all you would need to provide the service would be a
> local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service
> option. There would be no requirement to back-haul the initial DHCPREQUEST
> to a centralised provisioning system.

So now every v6-only CPE router has to have a DHCPv4 implementation and an IPv4 stack.

> As a separate issue, if the operator really wants to disable all ipv4, why
> not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer?

The draft speaks to this point.

BTW, the draft also speaks to the point of why you don't want to use DHCPv4 for this: once you've turned off IPv4, DHCPv4 can't be used to turn it back on again.

And the message from Simon that I was referring to was the one that discussed the draft that was proposed in sunset4 for solving this problem using DHCPv4, which was _not adopted by the working group_.   Draft adoption is part of the working group process; the fact that the working group decided to merge the DHCPv4 draft into this one, and not the other way around, is precisely what it means for a working group to have consensus to push this solution and not the other one.

v2.23.0 | Report a Bug | By Email