Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 18 Jul 2001 10:01:29 -0500

Ralph, et al:

Here's proposed text for dealing with the DHCPNACK issue. Ted and I
exchanged messages on this text and I've used most of Ted's feedback
here - though Ted has not seen this latest round.

1) Add to section 7.4.2:

   |NoPrefixMatch_|26______|_An addr in IA not valid for prefix_|_

2) Add to 14.4.1, 14.4.2, 14.4.4:

   If the server finds that the prefix on one or more IP addresses in
   any IA in the {Request,Confirm,Rebind} message is not a valid
   prefix for the link to which the client is connected, the server
   MUST send an NoPrefixMatch status in the IA status field for that
   IA in the DHCP Reply message.

   [Should we include Renew in the message list and add to 14.4.3?]

3) Add to Section 14.3.5. (Receipt of Reply message in response
   to a Request, Confirm, Renew or Rebind message):

   When the client receives a NoPrefixMatch error status in the IA status
   field of a Reply to a Confirm message, the client MUST make a
   determination as to whether it has moved to a different link.  If the
   client is unable to make such a determination it MUST assume that it
   has moved to a new link.  In this case the client MAY discard the IA
   that received the NoPrefixMatch status, or may retain it as long as
   the addresses in the IA continue to be valid.

4) Add somewhere (perhaps in 18.3, Identity Associatin Option):

   The client MUST NOT send any address in an IA once that address'
   valid lifetime has expired.

- Bernie (and Ted)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 13:51:33 -0700

>    [Should we include Renew in the message list and add to 14.4.3?]

The renew message can be unicast (IIRC) so the server can't make a
determination as to the validity of the prefix.

			       _MelloN_

---

From: "Vijay Bhaskar A K" <[email-masked]>
Date: Thu, 19 Jul 2001 04:23:39 +0530

Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Bernie Volz (EUD)
  Sent: Wednesday, July 18, 2001 8:31 PM
  To: DHCPv6 discussion list
  Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]

  Ralph, et al:

  1) Add to section 7.4.2:

     |NoPrefixMatch_|26______|_An addr in IA not valid for prefix_|_
  [Vijay Bhaskar A K] *********

  The format of "Error Code" option is not specified in the draft. It is
needed to be included.

     [Should we include Renew in the message list and add to 14.4.3?]
  [Vijay Bhaskar A K] ****************

  It will be better, if this functionality can be incorporated in the
agent,since, it is the only thing which knows well about the prefix in which
the client message is received. And the advantage is, if this checking is
done, this packet can be prevented from forwarding it to the multiple
servers and save multiple processing time. The agent itself can send the
NoPrefixMatch status directly to the client.

  [Vijay Bhaskar A K] *********

  If the client is receiving the error status as NoPrefixMatch error, what
may be the reason other than client's plugging in to different subnet. I
agree that, some roghe server can send this status, but, it can be prevented
by authentication.

     The client MUST NOT send any address in an IA once that address'
     valid lifetime has expired.
  [Vijay Bhaskar A K] **********

  Is there any reason in doing this specifically? Any how, the server is
going to delete the expired leases, then what way it is going to make
difference?

  - Bernie (and Ted)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 16:08:35 -0700

>   The format of "Error Code" option is not specified in the draft. It is

I think it goes into the IA option, but you're right - it needs to be
clarified.

> NoPrefixMatch status directly to the client.

Ooh, good point!   I think it would be good if the agent could do
this, although I have to admit that I am concerned that some people
who implement relay agents may not want to have to delve into the IA
to validate a packet.   I'm in favor of doing as you suggest, but I
suggest that we defer to the working group to see if any router
vendors have a problem with this.

Also, the timing is a bit tight on making this change, and I wouldn't
blame the authors if they said "no, sorry, do this in a new draft."  I
think it's okay to make this optional, so doing it in a seperate draft
should be fine.

> agree that, some roghe server can send this status, but, it can be prevented

The client may be mobile, and may be able to reach more than one
mobile access point.  The two access points may want to think of
themselves as seperate links, even though their physical link-layers
overlap.  I don't know how likely this is with existing technology,
but it's certainly been discussed with respect to 3G phones.  I think
it's important to leave the language open for this case.

			       _MelloN_

---

From: "Vijay Bhaskar A K" <[email-masked]>
Date: Thu, 19 Jul 2001 05:14:49 +0530

> Behalf Of Ted Lemon
> Sent: Thursday, July 19, 2001 4:39 AM
> Cc: DHCPv6 discussion list

No. What i meant was a seperate option called "Error Code" option.  These
error codes
are specifically releated to IAs. So, these can occur in the IA as IA
status.
But there are some error status which are very generic.
(e.g):- authfail,service not implemented, etc. These things should occur
only
in the generic error option. I think Ebi (hp) has given the specs to Ralph.
I beleive, this option is necessary.

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 00:33:28 -0400 (EDT)

if the server checks the prefix of the renew it can know?

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 00:48:07 -0400 (EDT)

I think this is an option we can do later.  But I think we are asking to
much of the relay.  The entire design goal has always been to keep the
relay as stateless as possible.  If the relay knows which prefixes are
good for a client and has to parse the addresses in a client packet I
think I am against that as one who has worked on building a router this is
a bit intense.  In fact now that I think about it I think this is simply
not a good idea.

/jim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 22:30:12 -0700

> if the server checks the prefix of the renew it can know?

You mean the IP source address?   True enough.

			       _MelloN_

---

From: "Vijay Bhaskar A K" <[email-masked]>
Date: Thu, 19 Jul 2001 15:23:58 +0530

No, the relay need not to be stateful. It can just compare the
prefix of Source IP address of the client packet and has to compare
with the prefix of its interface in which it is received. It don't need 
to parse the packet. It has to just see the sender's address, that's all.
But, this prevent the more and more processing that going to be 
happened on the servers. I think, including this functionality in the relay
won't be a big problem.
~Vijay

> Behalf Of Jim Bound
> Sent: Thursday, July 19, 2001 10:18 AM

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 12:34:52 -0400 (EDT)

yep...

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 12:39:57 -0400 (EDT)

true.  but the relay cannot see the addresses inside the IA option.
thats the addresses that will have to be nak'd not the source address.

/jim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2001 11:46:35 -0700

> happened on the servers. I think, including this functionality in the relay

This is true; the only concern is that the relay may not have complete
knowledge of the network configuration, and in that case it could
cause some serious breakage.   I like the idea of saving work by
having the relay generate the Invalid Prefix result, but I think it
should be approached with great caution.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2001 12:06:24 -0700

> thats the addresses that will have to be nak'd not the source address.

Hm, why not?   You mean because of authentication?

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Jul 2001 15:59:11 -0400

I agree with Ted - my intuition is that allowing the relay to do IA prefix 
checking is potentially dangerous.  To me, it introduces the requirement 
that we push detailed knowledge of network configuration out across lots of 
devices, where misconfiguration can cause significant problems for DHCP 
clients.  Even if we suppose that the relay can dive into other local 
information on the router, that information may not be complete enough to 
correctly make decisions about prefix validity.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 21:26:06 -0400 (EDT)

I think the entire notion of having a relay do server functions is a
separate piece of work.

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 21:27:29 -0400 (EDT)

the relay can't without looking at the UDP packet.  sorry I don't believe
routers perform well when looking past the header or as well.  this is
raging debate in the ietf.

/jim