Subject: [dhcwg] RE: DHCPv6 confirm message

From: Ralph Droms <[email-masked]>
Date: Sat, 29 Oct 2005 07:55:32 -0400

After re-reading RFC 3315, it seems there is no text requiring that the
server confirm that the addresses in the Confirm message from the client
actually belong to the client.  RFC 2131 explicitly requires two checks
on the address being confirmed (section 4.3.2):

      Determining whether a client in the INIT-REBOOT state is on the
      correct network is done by examining the contents of 'giaddr', the
      'requested IP address' option, and a database lookup. If the DHCP
      server detects that the client is on the wrong net (i.e., the
      result of applying the local subnet mask or remote subnet mask (if
      'giaddr' is not zero) to 'requested IP address' option value
      doesn't match reality), then the server SHOULD send a DHCPNAK
      message to the client.

      If the network is correct, then the DHCP server should check if
      the client's notion of its IP address is correct. If not, then the
      server SHOULD send a DHCPNAK message to the client. If the DHCP
      server has no record of this client, then it MUST remain silent,
      and MAY output a warning to the network administrator. This
      behavior is necessary for peaceful coexistence of non-
      communicating DHCP servers on the same wire.

However, section 18.2.2 of RFC 3315 includes only the first check:

   When the server receives a Confirm message, the server determines
   whether the addresses in the Confirm message are appropriate for the
   link to which the client is attached.  If all of the addresses in the
   Confirm message pass this test, the server returns a status of
   Success.  If any of the addresses do not pass this test, the server
   returns a status of NotOnLink.  If the server is unable to perform
   this test (for example, the server does not have information about
   prefixes on the link to which the client is connected), or there were
   no addresses in any of the IAs sent by the client, the server MUST
   NOT send a reply to the client.

If RFC 3315 does not, in fact, include the check about whether the
address(es) in the Confirm message belong to the client, we'll need to
issue an errata clarifying the issue.

- Ralph

On Wed, 2005-10-12 at 09:37 -0700, [email-masked] wrote:
>   >
> >Hm - you've made an interesting observation.  The assumption 
> >is that the server will record the DUID of the client to which 
> >an address is assigned, and then use the DUID from the CONFIRM 
> >message to check that the client sending the CONFIRM is the 
> >client to which the address was previously assigned.
> >
> I could not find this explicitly anywhere. Not at least in the server
> processing side.
> 
> >Let me knpow if you don't think that assumption is made clear 
> >in RFC 3315.
> >
> Could you point to the section where this assumption is stated ?
> I am trying to use the CONFIRM message in a different protocol.
> I just want to make sure that the server does the check or not.
> 
> thanks
> 
> -mohan
> 
> >- Ralph
> >
> >On Mon, 2005-10-10 at 15:50 -0700, [email-masked] wrote:
> >> Ralph,
> >> 
> >> I hope you don't mind sending this question directly to you.
> >> 
> >> When the client sends a CONFIRM request to confirm the address, why 
> >> doesn't the server check to see whether it is the same client that 
> >> sent the REQUEST earlier or not ? The server processing 
> >description in 
> >> RFC 3115 does not seem to show that. Is this the right 
> >understanding ?
> >> 
> >> -mohan
> >

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 29 Oct 2005 09:30:11 -0400

Ralph / Mohan:

The idea behind the CONFIRM message isn't to confirm specific addresses
(or prefixes). It was to provide the client guidance as to whether it
was still connected to the same network (ie, based on the globally
unique addresses).

During the DHCPv6 design meetings, we debated as to whether we should do
client specific checks. But the problem with this was that it
complicated the client's actions -- for example, if there are multiple
servers and the server that actually gave out those addresses (prefixes)
wasn't up, what happens? The other servers can either not respond (which
gives the client no information) or they can respond with a "can't
verify addresses, but they have the correct prefix". In that case, what
is the client to do?

That's why we decided it was better to just give an answer based on the
prefix match. Any DHCPv6 server can do those tests.

Again, CONFIRM only validates that the client is on a link where the
prefixes for the addresses (or delegated prefixes) are correct. It does
NOT indicate that the individual addresses (or delegated prefixes) are
correct (for that client).

So, this is NOT an errata issue. It was BY DESIGN!

If the client wants to confirm individual addresses, use RENEW (or
REBIND). But, there is little reason for a client to use those unless a
CONFIRM fails to give positive confirmation.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ralph Droms (rdroms)
> Sent: Saturday, October 29, 2005 7:56 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] RE: DHCPv6 confirm message
>