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

Mukund Kamath <Mukund_Kamath@infosys.com> Fri, 13 January 2012 05:41 UTC

Return-Path: <Mukund_Kamath@infosys.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF6A11E808D for <dhcwg@ietfa.amsl.com>; Thu, 12 Jan 2012 21:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP1O8srZdhDr for <dhcwg@ietfa.amsl.com>; Thu, 12 Jan 2012 21:41:50 -0800 (PST)
Received: from KECGATE08.infosys.com (kecgate08.infosys.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFA611E8075 for <dhcwg@ietf.org>; Thu, 12 Jan 2012 21:41:48 -0800 (PST)
X-TM-IMSS-Message-ID: <0919ec730001bcae@infosys.com>
Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 0919ec730001bcae ; Fri, 13 Jan 2012 11:11:38 +0530
Received: from blrkechub12.ad.infosys.com (10.66.236.47) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 13 Jan 2012 11:11:46 +0530
Received: from BLRKECMBX03.ad.infosys.com ([10.66.236.23]) by blrkechub12.ad.infosys.com ([10.66.236.47]) with mapi; Fri, 13 Jan 2012 11:11:45 +0530
From: Mukund Kamath <Mukund_Kamath@infosys.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Date: Fri, 13 Jan 2012 11:09:23 +0530
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-10.txt
Thread-Index: AczPo/mZ5mTrSWksSNC9eVpxb1DZrgAhv23iAGKvKu4=
Message-ID: <AB760FBDB8F14D4294F596941D2CABA92B69EE23E5@BLRKECMBX03.ad.infosys.com>
References: <20120110141243.15660.34595.idtracker@ietfa.amsl.com>, <AB760FBDB8F14D4294F596941D2CABA92B69EE23DD@BLRKECMBX03.ad.infosys.com>
In-Reply-To: <AB760FBDB8F14D4294F596941D2CABA92B69EE23DD@BLRKECMBX03.ad.infosys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jan 2012 05:41:51 -0000

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: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org [internet-drafts@ietf.org]
Sent: Tuesday, January 10, 2012 7:42 PM
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-10.txt

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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
**************** 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***