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

From: [email-masked]
Date: Tue, 10 Jan 2012 06:12:43 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : The DHCPv4 Relay Agent Identifier Suboption
	Author(s)       : Bharat Joshi
                          D.T.V Ramakrishna Rao
                          Mark Stapp
	Filename        : draft-ietf-dhc-relay-id-suboption-10.txt
	Pages           : 7
	Date            : 2012-01-10

   This draft defines a new Relay Agent Identifier suboption for the
   Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information
   option.  The suboption carries a value that uniquely identifies the
   relay agent device within the administrative domain.  The value is
   normally administratively-configured in the relay agent.  The
   suboption allows a DHCP relay agent to include the identifier in the
   DHCP messages it sends.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-10.txt

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 10 Jan 2012 19:48:11 +0530

Hi All,

      This ID had expired couple of weeks back. I have submitted this new revision with only one change. It now refers to the most recent version of bulk-lease-query draft.

      Ted had called a working-group last-call on this document. So if you think this should move forward, please send a mail indicating the same.

Regards,
Bharat
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, January 10, 2012 7:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-dhc-relay-id-suboption-10.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: Mukund Kamath <[email-masked]>
Date: Fri, 13 Jan 2012 11:09:23 +0530

Hi DTV,Bharat,

   I have read thro' the draft and I had a few questions :

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

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

* 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 serve security feature as well.

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

* Will the same suboption hold good for DHCPv4 and DHCPv6? Is there already a similar mechanism for DHCPv6?  Just thinking aloud at this point. I will look for information on this.

Regards,
Mukund Kamath
Infosys Ltd
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, January 10, 2012 7:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-10.txt

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