Re: [dna] DNA and DHCPv6

[Ralph Droms <[e-mail]>]

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