Re: [dna] DNA and DHCPv6

["Bernard Aboba" <[e-mail]>]

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