Re: [dhcwg] dhcpv6-24: Rapid Commit

The rationale for rapid commit is that there are devices that need to 
operate over a limited-bandwidth link, where the cost of the additional 
message exchange is significant.   For example, a cell phone.   Also, rapid 
commit introduces less latency to the address configuration process, which 
can be very significant in some cases.

With respect to the dual server model, the idea is that both servers do 
rapid commit, but the client only binds one of the server's addresses, and 
it simply drops the other server's addresses.   When it goes to renew, it 
only talks to the server it bound to, so the other leases expire, and the 
addresses burned by rapid commit are reclaimed.   This is considered okay 
because we have addresses to burn, and we consider the rapid commit to be 
more important than the burned addresses, which are reclaimed fairly 
quickly anyway.

I think that you are right to object to the specific implementation we've 
described.   It would be better to insist that the client be prepared to do 
the four-way handshake if it doesn't get a Reply with the rapid commit 
option - that is, a server can ignore the rapid commit option and send a 
Reply without it, and the client can wait if it wants to see if some other 
server replies with Rapid commit, or it can immediately proceed with the 
four-way handshake.   I don't see any reason to require that the client 
restart the whole process without rapid commit if it doesn't receive a 
reply - I would expect it to be the server provider's responsibility to 
make sure that all DHCP servers that serve a link where rapid commit is 
desired are configured to actually support rapid commit.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg