Subject: [dhcwg] dhc wg last call on "DHCP Relay Agent Assignment Notification Option"

From: Stig Venaas <[email-masked]>
Date: Mon, 08 May 2006 20:19:21 +0200

This message announces a wg last call on "DHCP Relay Agent Assignment 
Notification Option" <draft-ietf-dhc-dhcpv6-agentopt-delegate-00.txt>. 
The last call will conclude at 1700 ET on 2006-05-22.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

 From the abstract:
The DHCP Relay Agent Assignment Notification option is sent from a
DHCP server to a DHCP relay agent to inform the relay agent of IPv6
addresses that have been assigned or IPv6 prefixes that have been
delegated to DHCP clients.

This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-00.txt

Stig

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 08 May 2006 23:23:52 +0200

I support it.

[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 09 May 2006 13:26:30 -0400

I (may) have concerns about this document, and am not sure I can
support it.

My issue with it is that it may (though I'm not entirely sure) cross a
boundary beyond just being yet another DHC optoin. It seems to perhaps
extend the protocol in a way that I have concerns about. Specifically:

>    The DHCP server is responsible for synchronizing any state created by
>    a node through the use of the Assignment Notification option.  For
>    example, if a DHCP server receives a Release message for a delegated
>    prefix, it causes the node to delete any state associated with that
>    prefix by sending an Assignment Notification option containing an IA
>    Prefix option with the released prefix and a valid lifetime of zero.

If I undestand this right, if the DHCP server deletes a lease (e.g.,
the client releases the address), the server is obligated to notify
the agent. Is this so? If so, I worry that this is placing reliability
requirements on the server that it is poorly positioned to meet. (I.e,
is this intended to be used so that relay agents can _reliably_
maintain state about what prefixes are in use behind a particular
link?

What message does the server send back (per above) that contains an
Assignment Notification option? Is it piggy backed on an existing
message going back to the client (i.e., a response to the release)? Or
some other message? And does this message have to be transported
reliably (i.e., implying the server has to do retransmissions)?

Or am I reading too much into how this is intended to work? :-)

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 09 May 2006 15:30:13 -0400

Thomas - one way to think about this option is that it defines a capability
that replaces the "snooping" technique that some devices use to learn about
the state of DHCP clients.  So, this draft will allow *more* reliable
maintenance of state in a network element that needs that state than is
available through DHCPv4.

Perhaps this mechanism could be clarified by stating more explicitly that
the Assignment Notification option is usually piggybacked on a message to
the client.  In fact, in all the cases I can think of, the Assignment
Notification option would always be piggybacked on a message to the client.

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Tue, 09 May 2006 15:42:59 -0400

> the state of DHCP clients.

Kind of what I read between the lines. :-)

But then, if the purpose of this option is to replace the snooping
hack, this (or some document -- could be separate) should explore that
problem space a bit more thoroughly, to make sure we really are
solving that problem to a degree of reliability that does solve the
problem good enough. I.e., is this a 99% solution, or only a 60%
solution (compared with the 30% (???? - I'm obviously guessing)
solution we have in IPv4 today?)

> So, this draft will allow *more* reliable maintenance of state in a
> network element that needs that state than is available through
> DHCPv4.

OK. Then document needs to be very clear that the operative word is
"more reliable", and very specifically, "NOT totally reliable".

> Perhaps this mechanism could be clarified by stating more explicitly
> that the Assignment Notification option is usually piggybacked on a
> message to the client.  In fact, in all the cases I can think of,
> the Assignment Notification option would always be piggybacked on a
> message to the client.

I think the keyword here needs to be "always piggybacked". Even
leaving the door open to having the message go out in other cases
makes me nervous, because then I fear this is a then the "nose of the
camel" w.r.t. extending DHC into something it is not today. This also
gets back to my first point. If it turns out that this option doesn't
quite solve the actual problem on hand, there will likely be pressure
to extend DHC just a little bit more to close the gap.

I would be a lot happier if we understood the landscape here better
before moving forward with this option.

Thomas