Subject: [dhcwg] RE:

From: Bharat Joshi <[email-masked]>
Date: Sat, 7 Jul 2007 11:50:42 +0530

Hi Michael,

    Thanks for your interest and review of our document. I have copied this reply to DHC WG mailing list for the benefit of others. Please see my response in line.

Thanks & Regards,
Bharat

> Recently, several customers asked for a L2RA
> feature, but could not define it, which
> brought me to you document.

Apart from the comments below, is there any specific feature your customers have asked which is not addressed in our document?

> Please indulge me in a few comments/questions
>
> 1. It seems to me (and my customers concur) that it is important for an
> L2RA to use Unicast
>     traffic when sending towards the DHCP-server, at least as an option.
> The current text does not
>     make it clear if the L2RA forwards DHCP traffic from clients as is or
> changes them into Unicasts
>
>     It just says "... forwards it towards the DHCP server .."

L2 RA is typically a bridge and most of the times; its management interface can not be used to communicate with DHCP server. It is also not configured with DHCP servers or Layer 3 Relay Agent's IP address so it can not unicast the DHCP request to DHCP server or layer 3 RA.

There may be multiple ways to find out the port on which DHCP server is available. L2 RA are typically configured with the upstream port which is used to reach the upstream routers [something similar to Uplink port]. So DHCP messages are forwarded towards DHCP server. This is a broadcast of the message.

>           It may be useful to refer to an expanded NW scenario than is
> shown in figure 1, where there may
>           be two (or more) layers of L2 switches between the hosts and the
> L3RA. Then the importance
>           of not sending Broadcasts from the L2RA upstream becomes
> obvious.
>

I got your concern. But as mentioned above, L2 RAs are not configured with either L3 RA's address or DHCP server's address and so can not unicast. Do you think there is any other way this can be achieved?

> 2. In Section 4.2 the 1st paragraph states categorically that an L2RA does
> not intercept Unicast DHCP messages,
>     and the next paragraph shows that sometimes they do. I suggest to
> unify the two paragraphs, and say
>     that an L2RA MAY intercept and process unicast DHCP messages as it
> does the Broadcast ones
>

Yes. There are several L2 RAs which does snoop unicast messages because they maintain certain states for each address assigned through them. This is done for various reasons. Let me see how I can combine these two paragraphs.

> 3. The document assumes that an L2RA sends to an L3RA, which will relay to
> a Server; It is conceivable
>     that no L3RA exist, and the L2RA sends directly to a server; In such
> cases, it may be good to be able
>     to fill in giaddr of the outgoing message, so that the Server sees
> itin the same way as if it came from an L3RA

Yes. This configuration is possible. A L2 RA may not have an IP address that is reachable by DHCP server so it can not add a routable 'giaddr'. As of now, I think a DHCP server would discard a DHCP message if it contains 'option 82' but not 'giaddr'. We may want to allow this for broadcast messages.

> 4.  I think the discussion in section 8 of the handling of the Broadcast
> flag is relevant not just to L3RA,
>     but to L2RA also; If the host needs a Broadcast reply (i.e. the
> Broadcast flag is set) it is preferable that
>     the last switch downstream will be the one to generate the Broadcast,
> as opposed to the L3RA, which
>
>     Can be quite up the tree, and thus affect a large(r) domain;
>

This is the reason this issue has been addressed with the new sub-option.

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