Re: [dna] DNA and DHCPv6

Ralph Droms <> Fri, 20 November 2009 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EC603A6946; Fri, 20 Nov 2009 09:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gv13Ago31PhD; Fri, 20 Nov 2009 09:14:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1CCFA3A6358; Fri, 20 Nov 2009 09:14:04 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAGJdBktAZnwN/2dsb2JhbAC9O5dihDwEgW8
X-IronPort-AV: E=Sophos;i="4.44,778,1249257600"; d="scan'208";a="69165349"
Received: from ([]) by with ESMTP; 20 Nov 2009 17:14:00 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id nAKHDx1I003968; Fri, 20 Nov 2009 17:13:59 GMT
Message-Id: <>
From: Ralph Droms <>
To: Bernard Aboba <>
In-Reply-To: <BLU137-DS1D82CF3CD90846438826393A10@phx.gbl>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 20 Nov 2009 12:13:59 -0500
References: <> <BLU137-DS32F4D6442FA52382BD73893A10@phx.gbl> <> <BLU137-DS1D82CF3CD90846438826393A10@phx.gbl>
X-Mailer: Apple Mail (2.936)
Cc: DNA <>,,, IESG IESG <>, dhc WG <>
Subject: Re: [dna] DNA and DHCPv6
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2009 17:14:06 -0000

So, would this be an accurate description of Simple DNA:

* Send NS for each candidate link to the default router for that link
* Initiate RS/RA exchange as specified in RFC 4861
* Initiate DHCPv6 exchange as specified in RFC 3315

* If an NA is received, used cached info for corresponding link from  
* Process any received RAs as specified in RFC 4861
* Use info from DHCPv6 exchange as specified in RFC 3315
* Info from RA and/or DHCPv6 overrides any reused cached info based on  

- Ralph

On Nov 20, 2009, at 11:39 AM 11/20/09, Bernard Aboba wrote:

>> 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.
> "It makes sense to me that DHCPv6 would not be changed by this
> document.  DHCPv6 already has a mechanism through which a host can
> determine, in one DHCPv6 message exchange, if it has reattached to its
> most recently attached link.  If the host has moved to a new link, an
> additional 4 message exchange (possibly optimized to 2 messages) is
> necessary to get configuration information for the new link."
> [BA] Right.  That mechanism should be used as is, with no changes.
> "In addition to the text that may imply skipping an initial delay when
> sending an initial DHCPv6 message, the third paragraph of section 4.6
> of this document changes the DHCPv6 protocol by specifying that a host
> always send a Solicit message first, possibly including addresses from
> previously visited links as hints.  I think the text about this step
> is a little fuzzy about which addresses should be sent and how they
> should be sent."
> [BA] The contents of DHCPv6 packets shouldn't be dependent on any  
> aspect of
> DNA.
> For example, DNA shouldn't influence whether a Solicit message is  
> sent first
> nor
> what addresses are used as hints.  Whatever any implementation already
> does should be left alone.  After all, DNA is just an optimization.
> "I could imagine an argument for a change to DHCPv6 that requires the
> host to send a Confirm message for each of its currently valid
> addresses and a Solicit message, all in a burst, to probe all possible
> links in parallel, rather than just checking for reattachment to the
> most recently attached link.  However, it would be a significant
> change to DHCPv6 that has the potential for significant load on the
> DHCPv6 service."
> [BA] I don't see a need to change DHCPv6, particularly if this would
> create potential problems.
> "Another link between Simple DNA and DHCPv6 comes to mind at this
> point.  Here is the second paragraph of section 4.7:
>    On reception of a Router Advertisement or advertising DHCPv6  
> message
>    (a REPLY or ADVERTISE) which contains prefixes that intersect with
>    those previously advertised by a known router, the host utilizes  
> the
>    configuration associated with the detected network.
> What, exactly, does "utilize the configuration" mean, in relation to
> DHCPv6?  Does the host use any DHCPv6-assigned addresses without
> sending a Confirm message to the DHCPv6 service?  If the host has not
> reattached to its most recently attached link, presumably the host
> will have received a NAK from the DHCPv6 service from its initial
> Confirm (which checked just the most recently attached link).
> Depending on the timing, the host may have already initiated a DHCPv6
> message exchange for the current link."
> [BA] I have no idea what this paragraph means (or even why it is  
> necessary).
> Shouldn't a host just do what it would normally do in response to  
> these
> messages?  After all, DNA is only really about use of neighbor  
> discovery,
> not RS/RA or DHCPv6.
> "Also, this paragraph specifies "prefixes that intersect with those
> previously advertised by a known router".  Suppose the set of prefixes
> intersects but is not identical to those previously advertised?  I
> assume the host uses the newly received configuration.  But, by now
> the host has all the current configuration information from its local
> router, so what's the point?"
> [BA] As far as I can see, the only case worth additional discussion is
> the one in which there are prefixes that don't intersect.
> "As I mentioned above, I don't think the behavior you describe here is
> currently described in the document."
> [BA] Right.  My take is that this (and other DHCPv6 changes you  
> mention)
> are unnecessary and should be removed.