Subject: [dhcwg] RFC 3315 isn't specific about unknown message types

From: Ted Lemon <[email-masked]>
Date: Sun, 10 Mar 2013 20:10:51 -0400

Bernie and I were tossing some ideas around at the reception today and came up with a couple of issues with RFC3315; I'm curious what other people think of these points.

Currently the DHCP relay agent is not explicitly required to relay messages it doesn't recognize.   It's not advised to drop them either.   I think it should be required to relay them.   Has anybody here implemented a v6 relay agent?   What did you do about this?

One issue that Bernie came up with was, how does the relay agent recognize that it should send a message toward the server or toward the client?   I think the answer to this is really easy: the only message that a relay sends toward the client is the message it unpacks from a relay-reply, because this message has a destination address in the relay message header.   All other messages implicitly must be destined for the server; nothing else makes sense, because the relay has no other place to send them.

As a corollary to this, which I think is obvious, the draft never explicitly instructs clients or servers to drop messages with unrecognized types.   I think that this is a MUST: servers and clients MUST drop messages if they do not recognize the message type.   I suspect that implementors are already doing this, and didn't have to think about it.

Comments?

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 11 Mar 2013 03:10:50 +0000

Fully agree that client and server, as the terminal of communication MUST drop recognized message, maybe with a response message to the send. And the relay agent should forward the unknown message.

It is very similar to unknown extension header in intermedia router. Brian and I are doing a 6man draft to try to define intermedia router, including firewalls, should not drop the message with unknown extension header. draft-carpenter-6man-ext-transmit

The same catch 22 story will happen: if the intermedia router (relay agent in DHCPv6) does not forward for new extension until they are widely deployed. New extension hearder / message cannot be widely deployed until they are be avaible by forwarding.

Forwarding unknown message can make us easier to adopt new stuff in the future.

Best regards,

Sheng
________________________________________
From: [email-masked] [[email-masked]] on behalf of Ted Lemon [[email-masked]]
Sent: 11 March 2013 8:10
To: [email-masked]
Subject: [dhcwg] RFC 3315 isn't specific about unknown message types

Comments?

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

---

From: Andre Kostur <[email-masked]>
Date: Sun, 10 Mar 2013 20:36:24 -0700

I agree that it is eminently reasonable.  Take the non-relay reply,
wrap it with a relay forward, send it towards the server.  Take a
relay reply, unwrap it and send it along towards the client.  Servers
and clients ignore messages that they don't understand.

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Mar 2013 03:46:16 +0000

> Forwarding unknown message can make us easier to adopt new stuff in the future.

Indeed, that's what Bernie and I were talking about doing... :)