Re: [dhcwg] dhcpv6-24: Rapid Commit

Ted Lemon <> Wed, 08 May 2002 16:10 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA14881 for <>; Wed, 8 May 2002 12:10:57 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id MAA11142 for; Wed, 8 May 2002 12:11:04 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id MAA10884; Wed, 8 May 2002 12:09:11 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id MAA10860 for <>; Wed, 8 May 2002 12:09:10 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA14672 for <>; Wed, 8 May 2002 12:09:02 -0400 (EDT)
Received: from ( []) by (8.11.3/8.6.11) with ESMTP id g48G88S09664; Wed, 8 May 2002 09:08:08 -0700 (PDT)
Received: from tongpanyi (localhost []) by (8.10.2/8.6.11) with ESMTP id g48G97600352; Wed, 8 May 2002 11:09:07 -0500 (CDT)
Date: Wed, 08 May 2002 11:09:06 -0500
Subject: Re: [dhcwg] dhcpv6-24: Rapid Commit
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v481)
To: Thomas Narten <>
From: Ted Lemon <>
In-Reply-To: <>
Message-Id: <>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit

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