Re: [v6ops] Please review the No IPv4 draft

Nick Hilliard <nick@foobar.org> Tue, 15 April 2014 11:55 UTC

Return-Path: <nick@foobar.org>
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 640891A07AF for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 04:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable
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 35YJuCuYnjmn for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 04:54:53 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id F28FF1A07B6 for <v6ops@ietf.org>; Tue, 15 Apr 2014 04:54:32 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3FBsSav088350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2014 12:54:29 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie
Message-ID: <534D1E10.40809@foobar.org>
Date: Tue, 15 Apr 2014 12:54:56 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@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>
In-Reply-To: <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/w6KTgdZyhJHjaQzW7HTwITi9GCI
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 11:55:04 -0000

On 15/04/2014 04:12, Ted Lemon wrote:
> Because you are changing the protocol state machine.

it's a single new state with a single transition point, and it would need
to added to the state machine regardless of whether the signal comes
directly through dhcpv4 or indirectly through dhcpv6 or ra.  The difference
between the two is that dhcpv6/ra would need an asynchronous transition
which significantly complicates the dhcpv4 FSM because you would now have
the possibility of a transition from any dhcpv4 state to the No IPv4 state.
 IOW, you're creating a longjmp style exception mechanism in the FSM.  This
is not a sensible thing to aim for.

Nick