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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 14 Jun 2006 15:43:49 -0400

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?).

So, thanks for catching this issue Thomas!

- Bernie

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Tuesday, May 09, 2006 10:33 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; Stig Venaas; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] dhc wg last call on "DHCP Relay 
> AgentAssignmentNotification Option" 
> 
> > It is 100% reliable in the sense that if the relay doesn't get the
> > message, how would the client? Thus, the relay has at least as good
> > information as the client (and in some cases, perhaps 
> better since the
> > message could always be lost between the relay and client).
> 
> Makes sense.
> 
> But, isn't one of the problems (if I recall from what is done in IPv4)
> that relay agents can reboot and lose all their state? What happens
> then? How does the relay recover? Is this extension going to be used
> to help in that case too?
> 
> Thomas
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Jun 2006 13:07:23 -0700

> 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.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Jun 2006 13:12:27 -0700

If a DHCPv6 client is pre-configured with a list of IP addresses
of DHCPv6 relay agents on the link, and if the client knows that
there are no DHCPv6 servers on the link, can the client send
SOLICIT/CONFIRM/REBIND messages to the unicast address of one
of the relay agents?

If not, is this something that can be specified "in a document
that describes how IPv6 is carried over a specific type of link"
as suggested by ([RFC3315], Section 13)?

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Jun 2006 15:58:37 -0700

Responding to my own post, I was able to gain some insights from
the RFC3315 text. Please review and comment on whether I may be
missing something, or if there is some fundamental flaw with

> SOLICIT/CONFIRM/REBIND messages to the unicast address of one

Combing through RFC3315, I see only the following passages
relating to the IP destination address in client messages:

in Section 1.1:
  "DHCP servers receive messages from clients using a reserved,
   link-scoped multicast address.  A DHCP client transmits most messages
   to this reserved multicast address, so that the client need not be
   configured with the address or addresses of DHCP servers."

in Section 1.2:
  "In this case, the client sends a
   Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting
   the assignment of addresses and other configuration information."

in Section 1.3:
  "The client sends a Solicit message to the
   All_DHCP_Relay_Agents_and_Servers address to find available DHCP
   servers."

in Section 3:
  "The availability of these features means that
   a client can use its link-local address and a well-known multicast
   address to discover and communicate with DHCP servers or relay agents
   on its link."

in Section 13:
  "Unless otherwise specified in this document, or in a document that
   describes how IPv6 is carried over a specific type of link (for link
   types that do not support multicast), a client sends DHCP messages to
   the All_DHCP_Relay_Agents_and_Servers.

   A client uses multicast to reach all servers or an individual server.
   An individual server is indicated by specifying that server's DUID in
   a Server Identifier option (see section 22.3) in the client's message
   (all servers will receive this message but only the indicated server
   will respond).  All servers are indicated by not supplying this
   option."

finally, in Section 15:
  "A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address."

In these passages, I see only one "MUST" which occurs in the
Section 15 text wrt a server's validation for messages received
with a unicast destination address. But, if the client sends
messages to the unicast address of a *relay*, the relay would
forward them to the server with 'All_DHCP_Servers' as the
destination address, so the server message validation would pass.

> as suggested by ([RFC3315], Section 13)?

None of the RFC3315 text speaks to whether clients could send
messages to the unicast address of a relay other than to say
in Section 1.1 that: "The operation of the relay agent is
transparent to the client". Furthermore, the spec is silent
on a relay's message validation which I take to mean that a
relay agent's behavior wrt receiving a unicast message from
a client is unspecified and presumed to behave the same as
for multicast messages.

Using this information, plus the first paragraph of the Section
13 text cited above, I assume that "a document that describes how
IPv6 is carried over a specific type of link (for link types that
do not support multicast)" could specify that a client's messages
are sent to the unicast address of a relay on the link (if the
client is configured with the IP address of the relay).

Comments?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Jun 2006 16:20:57 -0700

Responding to my own post yet again (hopefully for the

> client is configured with the IP address of the relay).

I suppose another option would be to still have the client
send its messages to 'All_DHCP_Relay_Agents_and_Servers',
but to map the IP address to the MAC address of an on-link
relay or server, i.e., as for NBMA links?

Fred

---

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

Fred,

What problem are you trying to solve? You seem to be asking a narrow
"legalistic" question about whether something is technically legal
according to the RFC. I would much prefer understanding what you are
trying to do (and why) before answering whether what you are asking is
legal. (I.e., maybe it is technically legal, but shouldn't be, or
maybe it's technically not legal, but given the problem at hand, could
be made legal.)

In particular:

> of DHCPv6 relay agents on the link,

This statement alone gives me heartburn because the whole point of DHC
is to not have to hardwire in something like the addresses of the
relay agents. I.e., the hardwired part is the multicast addresses
already used in the base DHC protocol.

> as suggested by ([RFC3315], Section 13)?

Perhaps. But could you please describe the problem and your proposed
solution, so we have context for answering your specific questions?

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Jun 2006 08:25:07 -0700

Thomas,

You probably saw my iterations on the question, but I am coming
to the conclusion that the problem I am trying to solve basically
boils down to multicast on NBMA links. You would probably rightly
say that the question is out of scope for dhc and should be
addressed in a specific "IP-over-foo" document, but it turns out
that I have one of those open for edit right now and got stuck
in the mindset that something special was needed for DHCP.

So, this forum has served a useful purpose if only to allow me
to hear myself think. Your follow-up was appreciated as well;
please let me know if there is anything else I may be missing.

Fred

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, June 14, 2006 7:15 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dhcwg] Sending SOLICIT/CONFIRM/REBIND messages to a
relay-agentunicast address 

Fred,

Thomas

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 15 Jun 2006 09:03:38 -0700

> relay or server, i.e., as for NBMA links?

I seem to recall this was solved in the past, either for broadcast
or multicast reasons on NBMA links...it involved allocating an extra
DLCI ("MAC"?) to each circuit.

So you have one DLCI for each peer on the network, and one which
you send a single copy of frames which you want to send to either
all or a subset of your peers.

This was efficient in the sense that the transmitter neither needed
to know, at that time, what the full range of DLCIs present on its
interface were, nor of those which actually wanted to receive that
kind of traffic.  So you could add nodes to an NBMA network like
this without having to reconfigure all of them.

To use it, you only had to configure (statically on the end system)
a 'broadcast DLCI'.  In some implementations this also enabled
Inverse ARP as I vaguely recall, completely automating the network
so no static address mapping was necessary.

Is that vague sort of idea compatible with the particular type of
NBMA network you're working on?

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Jun 2006 09:12:01 -0700

David,

Thanks for this. I think you are correct; the link type I
am working on basically boils down to NBMA although I didn't
realize it until puzzling it out here on the dhc list. So,
the solution space needs to look at all multicast; not just
'All_DHCP_*'.

Fred

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Thursday, June 15, 2006 9:04 AM
To: [email-masked]
Subject: Re: [dhcwg] Sending SOLICIT/CONFIRM/REBIND messages
toarelay-agentunicast address

-- 
David W. Hankins		"If you don't do it right the first
time,
Software Engineer			you'll just have to do it
again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins