[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] Feedback on Layer 2 Relay Agent functionality
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
> dhcwg at ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg