Re: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-10.txt

[Bharat Joshi <[e-mail]>]

Hi Mukund,

     Thanks for your comments. Please see my responses in-line.

Regards,
Bharat

> 
> * What are we trying to identify using this option? The device as a whole ? or the line card in the device or a particular port? That is kinda open and is left to the implementor. In the case of a reboot, the device would like to get all the information back from the DHCP server i.e. lease information, any anti-spoofing rules etc. It would end up doing it in multiple sets if we dont have a common identifier for the whole device. So the ideal format should be a function of :
> 
> Device::Shelf::Slot::port
> 
>    This way, retrieving the data can be easier and can be done at several levels. I hope I am being clearing conveying my message. This can be suggested strongly in draft. It would also help in standardizing DHCP server implementations that would be vendor-independent.
>

Relay-id identifies the entire device. Not specific slot/port.

The following is the existing text from the draft's abstract:

"The suboption carries a value that uniquely identifies the relay agent device within the administrative domain."

It is explicit saying that relay-id uniquely identifies the relay agent device.
 
> * Is this suboption added to all the DHCP messages that are forward thro' the Relay agent? or only the messages generated by the RA ( like lease query etc). What about the messages that are directly unicast between the client and the server?
> 

This part is clarified in the following sections as follows:

Section 5:

" Implementors should note that the identifier needs to be present in
   all DHCP message types where its value is being used by the DHCP
   server.  The relay agent may not be able to add the Relay Agent
   Information option to all messages - such as RENEW messages sent as
   IP unicasts.  In some deployments that might mean that the server has
   to be willing to continue to associate the relay identifier it has
   last seen with a lease that is being RENEWed.  Other deployments may
   prefer to use the Server Identifier Override suboption [RFC5107] to
   permit the relay device to insert the Relay Agent Information option
   into all relayed messages."


> * I feel we should clearly outline the scenario where we have the following topology :
> 
>     DHCP client ---L2RA ---L3RA --- DHCP server.
> 
>    In this scenario, the typically the L3RA will not be adding a Option 82. Would the L3RA have an option to append its relay-id suboption for the server to know the exact path used by the DHCP client to reach the server? This could be a security feature as well.
>

This draft is defining only relay-id suboption. Its usage in specific scenarios
need to be documented separately.
 
> * There was some talk about the relay chaining feature ( using recursive look for option 82, when multiple option 82 headers are present in the packet). In this scenario, we may have to define how this option will have to be used?
> 

Yes. There is a draft 'draft-ietf-dhc-dhcpv4-relay-encapsulation-01' which defines DHCP processing in such a network configuration. I think it should be discussed there.

> * Will the same suboption hold good for DHCPv4 and DHCPv6? Is there already a mechanism for DHCPv6? Just a question from myside. I will look for information on this.


This option is specific to DHCPv4. The title clarifies that:

"The DHCPv4 Relay Agent Identifier Suboption".

This is not meant for DHCPv6.
**************** 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***