Subject: RE: [dhcwg] dhc wg last call on "DHCP Relay AgentAssignmentNotification Option"

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 14 Jun 2006 16:24:10 -0400

Ted:

> This is starting to seem more than a little bit too complicated.
> Do we really want to add this to the protocol? I'm skeptical.

It is perhaps a stretch as to how likely this is, after all Relay's have
been gleaming this data from DHCPv4 traffic for a long time and
generally have no issues? But, the DHCPv4 situation is different as the
model assumes one address per client. In DHCPv6, this model is no longer
true. Perhaps that is not sufficient reason to do this?

One solution for the sequence number only requires that it commit it (a
portion of it) to storage at server start (read, increment, write, or
initialize from current time). This means that the server need not
commit it after sending each reply (which we would definitely not
want!).

I admit that this is certainly not as lightweight as we would like it to
be and I guess we can:
- Remove it if no one cares enough (or make it optional).
- Do something else (for example, sending back a client-last-transaction
time would at least allow the relay to look at something to decide which
is later, but it fails if there are multiple transactions per second.)
- Leave it in the draft.

- Bernie
 
> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Wednesday, June 14, 2006 4:07 PM
> To: Bernie Volz (volz)
> Cc: Thomas Narten; [email-masked]; Stig Venaas; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] dhc wg last call on "DHCP Relay 
> AgentAssignmentNotification Option"
> 
> Bernie Volz (volz) wrote:
> > Thomas, and DHC WG:
> >
> > Thomas' comments got me thinking some more about this "reliablity"
> > issue. And, though I don't know if Thomas intended it this 
> way, there is
> > an issue. Ralph will be submitted an updated draft to "correct" this
> > issue.
> >
> > Suppose we have the following timeline of events:
> >
> > T+00 - Client sends REQUEST for a binding.
> >      - Relay forwards to server.
> >      - Server sends REPLY, which is "delayed" by the network.
> >        (Relay and client don't yet see this packet; assume
> >        there is a cloud between relay and server and some
> >        route is flopping and/or congested.)
> > T+02 - Client retransmits REQUEST for a binding. 
> >      - Relay forwards to server.
> >      - Server sends REPLY.
> >      - Relay forwards REPLY to client and processes data from
> >        notification option and records binding.
> >      - Client records binding but discovers that it can't use
> >        the address.
> > [Both client and relay are in agreement.]
> > T+03 - Client sends a DECLINE.
> >      - Relay forwards to server.
> >      - Server sends REPLY.
> >      - Relay forwards reply to client and processes data from
> >        notification option and removes binding.
> >      - Client completes DECLINE.
> > [Both client and relay are in agreement.]
> > T+04 - Delayed REPLY from REQUEST (T+00) arrives at Relay.
> >      - Relay forwards REPLY to client and processes data from
> >        notification option and records binding.
> >      - Client ignores REPLY as the transaction-id is invalid
> >        for an outstanding transaction.
> >
> > Now, the Relay believes the client has a binding which it 
> doesn't have!
> >
> > If a RELEASE/DECLINE REPLY were delayed, a Relay may REMOVE 
> an active
> > binding.
> >
> > So, the updated draft will correct this by adding a new 
> option which is
> > added by the server and includes a 64-bit monotonically increasing
> > sequence number (there are suggestions for how a server 
> might do this).
> > This sequence number is for the REPLYs that a server sends (at least
> > those that contain the Notification option).
> >
> > When a Relay receives the notification option and this new sequence
> > number option (a server-id option is also required to be sent by the
> > server), the relay can examine its database and ignore 
> things from the
> > same server with a lower sequence number.
> >
> > One other change is that a Relay must not remove information for at
> > least the maximum datagram lifetime (similar to what TCP 
> requires). That
> > way, it can correctly handle all of the issues.
> >
> > And, the server is required to send ALL current bindings 
> (for the client
> > on the link) in the Notification option, not just the deltas.
> >
> > Again, a revised draft will be published shortly (though 
> perhaps it will
> > take a bit to pop out of the queue?).
> >   
> 
> This is starting to seem more than a little bit too 
> complicated.   Do we 
> really want to add this to the protocol?   I'm skeptical.
> 

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 14 Jun 2006 22:22:23 -0400

> > Do we really want to add this to the protocol? I'm skeptical.

I need to think about this, as it does sound like more complexity.
However...

> generally have no issues?

Actually, if this were a problem in practice today, would we _really_
know about it, or would it just be chalked up as one of those weird
things that happens sometimes where something doesn't work for a user,
the helpdesk is clueless, and it fixes itself when the home client is
rebooted (hey, must just have been an windows problem)?

I do think we need to make our protocols fairly rock solid. Given how
this is core infrastructure, it just has to work. All the time.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Jun 2006 19:30:25 -0700

> this is core infrastructure, it just has to work. All the time.
To be clear, I was questioning the need for the protocol for which 
Bernie's fix applies, not the need for the fix.   If we adopt the 
protocol, we have to have Bernie's fix.   But I'm not convinced we 
should adopt the protocol.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 29 Jun 2006 10:01:52 -0400

The protocol is defining a real solution for which DHCPv4 "snooping" or
"gleaning" was developed as a workaround.

There are many use cases for getting state into the network element on which
a relay agent runs based on DHCP activity.  This state could be transmitted
through some other protocol; e.g., TELNET/CLI to the network element, SNMP.
It seems the most direct method to deliver the state information to the
network element is to piggy-back that information on the DHCP message
exchange.

We missed the opportunity to formalize this information delivery in DHCPv4.
This protocol for DHCPv6 will formalize the specification, add reliability
and more closely follow the DHCPv6 model of client-server message
encapsulation (in constrast with the DHCPv4 model of message
forwarding/relaying).

- Ralph