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

From: Stig Venaas <[email-masked]>
Date: Fri, 02 Nov 2007 09:56:37 +0100

Bharat Joshi wrote:
> Hi David,
> 
>     Thanks for your details response. Please see my response in line.

Thanks David for providing some input on this. It's been very quiet from
others. I'm wondering how we should proceed with the layer 2 relay agent
stuff.

I'm thinking perhaps a first step could be an informational document
discussing what we mean by a layer-2 relay agent and different ways
they may be implemented and relevant issues like what is in the
current draft and also what David point out here.

Perhaps also some scenarios where layer-2 agents are useful.

Thoughts? What do you think Bharat?

Stig

> 
> 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?
>>
>> 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*.
>>
> 
> Ok. Now I understand what you meant there.
> 
>> 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.
>>
> 
> Ok.
> 
>> 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.
>>
> 
> Actually AFAIK Layer 2 Relay Agent filter would also need to look at UDP port to intercept DHCP messages.
> 
>> 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.
>>
> 
> Our implementation always used to add 'giaddr' in unicast messages as well.
> 
>> 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.
>>
> 
> 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.
> 
> **************** 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

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

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 2 Nov 2007 15:04:34 +0530

Hi Stig,

> others. I'm wondering how we should proceed with the layer 2 relay agent

Yes. I would also like to thank David for sharing this information. It
will really help understanding what people are looking for.

> current draft and also what David point out here.

Yes. It looks like whatever assumption we made in the starting about the
general understanding of this domain is not correct. So we will have to
go one step back and talk about this in a generic terms.

> Thoughts? What do you think Bharat?

We have already started working on an information document which
captures following things:

* What a Layer 2 Relay Agent is? Where it fits in and how it works?
* Various scenarios where a Layer 2 Relay Agent is used and how DHCP
server and Layer 3 Relay Agent behaves in its presence?

We are still working on it and I think it should be completed in couple
of days.

If anyone has any inputs in next couple of days, Please let us know.

Thanks & Regards,
Bharat

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 2 Nov 2007 08:57:21 -0700

> others. I'm wondering how we should proceed with the layer 2 relay agent

I'm somewhat concerned about this as well, I'd like to see some
comment from other server implementors.  If they've seen more issues
than I have, the same issues, or no issues at all, that's all useful
information.

> current draft and also what David point out here.

I think that's an excellent idea, 'documenting existing operational
practices,' which really helps frame new work in this area.  I just
want to add that this is more work for *someone*, by which I mean not
me...I just have too much on my plate right now to do more than read
and review.  So I'm happy to accept whatever work in this area as can
find willing authors. :)

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