Subject: Re: [dhcwg] DNA and DHCPv6

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Nov 2009 09:23:10 -0500

Bernard - thanks for the clarifications; I've included some comments  
inline.

Also adding dhc WG for comments.

On Nov 20, 2009, at 8:37 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.

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.

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.

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.

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?

> 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.

OK.

>
> 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.

OK.

> 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.

As I mentioned above, I don't think the behavior you describe here is  
currently described in the document.

> 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.

OK.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Nov 2009 12:13:59 -0500

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  
SDAT
* 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  
NA

- Ralph

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

>> wording in the document.
> "It makes sense to me that DHCPv6 would not be changed by this
> 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
> 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
> 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
> 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
> 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.
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 08:39:47 -0800

[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.  

[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. 

[BA] Right.  My take is that this (and other DHCPv6 changes you mention) 
are unnecessary and should be removed.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 10:15:07 -0800

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

* If an NA is received, used cached info for corresponding link from  
SDAT
* 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 NA"

[BA] I believe so, yes.  Aside from the DHCPv6 issues, there were a few
deviations with respect to RS/RA that were raised in the IESG review. 
I think we need to look at those carefully as well.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 10:35:57 -0800

One potential wrinkle occurs in the case where the NS/NA, RS/RA and DHCPv6
exchanges have unequal levels of security.  For example, Section 4.7.1
states that if the NS/NA is secured with SEND and the DHCPv6 exchange is
not, then DNA takes priority.  However, where there are equal levels of
security (or insecurity), then I believe DNA should work as per below. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, November 20, 2009 10:15 AM
To: 'Ralph Droms'
Cc: 'DNA'; [email-masked]; 'Suresh Krishnan (QB/EMC)';
[email-masked]; 'Jari Arkko'; 'IESG IESG'; 'dhc WG'
Subject: [DNA] RE: DNA and DHCPv6