IETF Logo Mail Archive

Re: [v6ops] Please review the No IPv4 draft

Ted Lemon <ted.lemon@nominum.com> Tue, 15 April 2014 15:31 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 32F471A0677 for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 08:31:45 -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 LMdC6-JF9_ZD for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 08:31:44 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 4348F1A065E for <v6ops@ietf.org>; Tue, 15 Apr 2014 08:31:44 -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 9CC4D1B8055 for <v6ops@ietf.org>; Tue, 15 Apr 2014 08:31:41 -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 9612E19005C; Tue, 15 Apr 2014 08:31:41 -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:31:41 -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: <F2DF90B2-53D6-431A-A8CE-DC2CF9D411CD@delong.com>
Date: Tue, 15 Apr 2014 10:31:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <182F7B02-7D62-4477-8A74-F641A0C366C4@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> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> <F2DF90B2-53D6-431A-A8CE-DC2CF9D411CD@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/9h18lDE0H6T8-oSr1exvQta7MGg
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:31:45 -0000

On Apr 14, 2014, at 11:50 PM, Owen DeLong <owen@delong.com> wrote:
> So, you’re saying having some external process kill the DHCP4 client in response to a message received via DHCPv6 is less of a change to the protocol state machine than having DHCPv4 client die in response to a similar message… Right.

Yes.   Not running a protocol is not a change to the protocol's state machine.   We don't need to write an RFC explaining how to not enable DHCPv4.   Changes to the state machine for the benefit of this use case would have to be considered in the larger context of intended uses of DHCPv4; turning off DHCPv4 requires no such consideration.

v2.23.0 | Report a Bug | By Email