[dna] DNA and DHCPv6

"Bernard Aboba" <bernard_aboba@hotmail.com> Fri, 20 November 2009 13:37 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A32F43A6937; Fri, 20 Nov 2009 05:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.562
X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_05=-1.11]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id QKE08ebKqwWO; Fri, 20 Nov 2009 05:37:10 -0800 (PST)
Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com []) by core3.amsl.com (Postfix) with ESMTP id C6E873A6A98; Fri, 20 Nov 2009 05:37:10 -0800 (PST)
Received: from BLU137-DS3 ([]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 05:37:08 -0800
X-Originating-IP: []
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS32F4D6442FA52382BD73893A10@phx.gbl>
From: "Bernard Aboba" <bernard_aboba@hotmail.com>
To: "'Jari Arkko'" <jari.arkko@piuha.net>, "'Suresh Krishnan \(QB/EMC\)'" <suresh.krishnan@ericsson.com>, <draft-ietf-dna-simple@tools.ietf.org>, "'Ralph Droms'" <rdroms@cisco.com>, "'Lars Eggert'" <lars.eggert@nokia.com>
References: <4B0655CB.2040309@piuha.net>
In-Reply-To: <4B0655CB.2040309@piuha.net>
Date: Fri, 20 Nov 2009 05:37:20 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcppvQLJ7ItJirIBTUaGOr1PTwr3RgAKJhDQ
Content-Language: en-us
X-OriginalArrivalTime: 20 Nov 2009 13:37:08.0320 (UTC) FILETIME=[8E3C6E00:01CA69E6]
Cc: 'DNA' <dna@eng.monash.edu.au>, dna@ietf.org, 'IESG' <iesg@ietf.org>
Subject: [dna] DNA and DHCPv6
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2009 13:37:11 -0000

I believe that many of Ralph's issues below are the result of poor wording
in the document. 

The draft specifically says that it does not change the DHCPv6
protocol, state machine or timers, so that any situation in which
there is an implied DHCPv6 change represents an error. 

So if a host delays transmission of an initial DHCPv6 message that 
should still be the case with DNA.   Also, the draft should not 
change the retransmission rules for DHCPv6.  The paragraph in question,
(which is not well worded) was intended to refer only to NS retransmission.

With respect to the M/O bits, the draft should not change the behavior
of an implementation.  So if an implementation ignores the M/O bits
(as some do), then that behavior should continue.  If it
doesn't ignore them, then it will continue to take them into account as
it did before.  

Also, DNA does not change the assumptions which DHCPv6 uses to obtain
an address. If DHCPv6 would normally attempt to confirm a previously 
held address, it should continue to do so;  if it would normally 
attempt to obtain a new address, it will do that instead.  

Given the above, DHCPv6 and DNA largely operate as "ships in the 
night";  the only interaction comes when the two procedures come
to different conclusions, in which case the text in Section 4.7.1
comes into play.