Subject: RE: [dhcwg] Feedback on Layer 2 Relay Agent functionality

From: Bharat Joshi <[email-masked]>
Date: Fri, 5 Oct 2007 23:02:33 +0530

Hi David,

     Sorry for a late response. Please see my response in line.

Thanks,
Bharat

> > With the big number of people that wanted the wg to work on this
> > problem at the meeting I would have hoped a few would respond to my
> > request. Does the silence mean a lack of interest or that the below
> > document actually does a very good job at describing what
> you think we
> > should work on?
>
> There are a few things I think are missing; I think we can
> use a general document that describes what an ("official") l2
> relay agent is and does, and things it can and cannot rely
> upon.  For example, I have had l2 relay agent manufacturers
> express grief when I had to explain that yes, one
> DHCPDISCOVER may net more than one DHCPOFFER, and they may
> not agree.  Further grievances were uttered upon the
> discussion that one DHCPREQUEST may net multiple DHCPACKs
> under imprecise circumstances, and they also may not agree
> upon some finer details (you may even see DHCPACKs and
> DHCPNAKs mixed, and will have to deal with this case as best
> as you can).
>
> The main problem with those grievances being those services that
> l2 relay agents are trying to deliver using something vaguely
> referred to as 'dhcp snooping' as a transport.  I don't think
> we need to get into 'dhcp snooping' in a standard way in this
> document (but I would welcome a second document that at least
> describes the practices!), but rather a more generic
> discussion of what can (and some explicit things that can't)
> be relied upon.
>
> So, essentially, a 'step by step' explanation of an L2 relay
> agent's operation, similarly to what we see in rfc2131,
> something similar (unless there's a better way) to the
> 'timeline' graphs in that document.
>

I agree that our draft does not touch upon these areas. This is because we describe Layer 2 Relay Agent functionality in a particular Network Configuration.

I think Michael was also looking for something similar. If I understand it correctly you are suggesting that we should come out with a document which describes the Layer 2 Relay Agent functionality without assuming a particular Network configuration.

We can keep our draft as it is which talks about enhanced Layer 2 Relay Agent.

> Second, I think this document could actually use some helpful
> hints for server implementors, based solely on my own
> experience.  From our DHCP software distribution's RELNOTES,
> as an easy summary;
>
> - In the case where an "L2" DHCP Relay Agent (one that does
> not set giaddr)
>   was directly attached to the same broadcast domain as the
> DHCP server,
>   the RFC3046 relay agent information option was not being
> returned to the
>   relay in the server's replies.  This was fixed; the dhcp
> server no longer
>   requires the giaddr to reply with relay agent information.
> Note that
>   this also improves compatibility with L2 devices that
> "intercept" DHCP
>   packets and expect relay agent information even in unicast (renewal)
>   replies.  Thanks to a patch from Pekka Silvonen.
>
> My finding that lead to inclusion of this patch upon reading
> the relay agent option RFC basically was that the relay agent
> options are included in any replies to packets that had the
> option in them...not restricted by a non-zero giaddr.
>
> I swear there was something else we changed or fixed for L2
> agent compatibility, but I can't seem to find it now.  I
> might be confused, it wouldn't be the first time.
>

Yes. I agree that implementation specific things may help in identifying such issues. We can add a section later.

>
> Ohyeah, one other thing I've had to explain that I think may
> not be obvious is why server operation changes when the
> 'giaddr' is nonzero.
>
> In particular, this goes back to 'getting multiple DHCPACKs
> in response to one DHCPREQUEST'.  Where giaddr is set, our
> servers believe the client to be "REBINDING", and since you
> only reach REBINDING if REQUESTING fails (e.g., the peer has
> failed to answer for a not-insubstantial period), our
> failover pair will elect not to load balance...both will
> answer.  This lead us into the discussion about multiple replies.
>
> I'm not sure failover needs to be referenced explicitly, I
> just include that for discussion, but I think it's important
> to note that a device acting in this way creates the illusion
> of a REBINDING when the client is in actuality REQUESTING.
> This is basically a loss of information in the absence of
> some other way to convey it (like the relay agent flags sub-option).
>

I did not get this one. In case of Layer 2 Relay A gent, DHCP client will still send DHCP requests as unicast to the DHCP server. Can you elaborate on how do we get the illusion of a rebinding in this case?

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

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

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 5 Oct 2007 11:47:27 -0700

> I did not get this one. In case of Layer 2 Relay A gent, DHCP client will still send DHCP requests as unicast to the DHCP server. Can you elaborate on how do we get the illusion of a rebinding in t…

Server logic uses several hints in the DHCP packets to sense the
client's state.  This may make small, but noticeable, changes in
server behaviour (such as in the example case, multiple packets
are transmitted).

One of those of course is the message in question.  A discover vs.
a request helps narrow down greatly wether we're talking about INIT
or the INIT_REBOOT/SELECTING/RENEWING/REBINDING kitchen sink.

Within the request message specifically however, it's necessary to
look at other hints to further narrow down the client state.

First, you look at the message type, let's just look at DHCPREQUEST.

If ciaddr is zero, you're looking at INIT_REBOOT or SELECTING.

	If the server-identifer is supplied, you're looking at
	SELECTING.

	ELSE you're looking at INIT_REBOOT.

ELSE (ciaddr is nonzero) you're looking at RENEWING or REBINDING.

	If the packet was unicast you're looking at RENEWING.

	ELSE (the packet was broadcast) you're looking at REBINDING.

So how do you sense broadcast vs unicast?

If 'giaddr' is set, you assume the packet to be broadcast.  If
giaddr is not set, then you examine the destination IP address of
the packet*.

So, if a client in RENEWING sends a packet as described in rfc, and an
intervening device sets giaddr nonzero, the server will (correctly)
interpret that to be REBINDING and may use different behaviour than
might be expected for RENEWING.  This is only a problem if you rely
on the RENEWING server-behaviour for a RENEWING client and are then
fazed by REBINDING server-behaviour for a RENEWING client.

I described some 'alternate' behaviour recently in regards to
failover, but conceivably there are other potential, subtle, changes
in behaviour or processing across different perceived client states.

Anyway.  L2 relay agents usually sniff DHCP packets out of an L2
filter, rather than listening at L3.  Depending on the filter, they
may catch unicasts as well as broadcasts, and relay both equally.

I know of precisely two L2 relay agent implementations.  I don't
think that's a big enough number. :(

They both intercept unicasts and append relay agent options.  One sets
giaddr, the other leaves it clear.  I can check my notes if vendor
names are needed.

For the first implementation, we had a compatibility issue because
our failover servers sent multiple responses.  I told him he was
going to have to sleep in the bed he made.  That's just what we do.

For the second implementation, we had a compatibility issue because
we refused to reply with the relay agent information option (so the
L2 relay lost the info it needed to forward the packet on).  We
changed our server behaviour because I think (even if I disagree
with the practice of including agent options in unicasts) that the
relay agent information option RFC does specify this behaviour as
correct.  The implicit assertion that all relays set giaddr is false.

* - At least one implementation, for RENEWING/REBINDING clients on
	the local wire, "punts on the issue" because it can not
	differentiate between unicasts and broadcasts.  Only where
	giaddr is set can it differentiate a REBINDING...otherwise it
	assumes RENEWING.  This has some amusing results in extremely
	contrived circumstances.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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: Bharat Joshi <[email-masked]>
Date: Sun, 7 Oct 2007 21:10:53 +0530

Hi David,

    Thanks for your details response. Please see my response in line.

Thanks,
Bharat

> > I did not get this one. In case of Layer 2 Relay A gent, DHCP client
> will still send DHCP requests as unicast to the DHCP server. Can you
> elaborate on how do we get the illusion of a rebinding in this case?
>

Ok. Now I understand what you meant there.

> in behaviour or processing across different perceived client states.

Ok.

> may catch unicasts as well as broadcasts, and relay both equally.

Actually AFAIK Layer 2 Relay Agent filter would also need to look at UDP port to intercept DHCP messages.

> giaddr, the other leaves it clear.  I can check my notes if vendor

Our implementation always used to add 'giaddr' in unicast messages as well.

>         assumes RENEWING.  This has some amusing results in extremely

Ok.

As mentioned in my last mail, I think we need to come out with a document that discusses this kind of stuff. I am waiting for more inputs and may be present this in the coming up meeting for getting feedback from working group's participants.