Subject: [dhcwg] FW: I-D ACTION:draft-kurapati-dhc-relay-chaining-dhcpv4-01.txt

From: bharat_joshi <[email-masked]>
Date: Tue, 19 Jun 2007 21:29:14 +0530

Hi All,

      We have published a revised version of our draft 'Relay Chaining in DHCPv4'.

      Please review this document and let us know your comments and suggestions.

Thanks,
Bharat
________________________________________
From: [email-masked] [[email-masked]]
Sent: Saturday, June 16, 2007 1:20 AM
To: [email-masked]
Subject: I-D ACTION:draft-kurapati-dhc-relay-chaining-dhcpv4-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Relay Chaining in DHCPv4
        Author(s)       : B. Joshi, P. Kurapati
        Filename        : draft-kurapati-dhc-relay-chaining-dhcpv4-01.txt
        Pages           : 16
        Date            : 2007-6-15

DHCP Relay Agents eliminate the necessity of having a DHCP server on
   each physical network.  In certain network configurations, a DHCP
   server may be multiple subnets away from the DHCP client and multiple
   Relay Agents may be configured to relay DHCP messages to and from
   DHCP client.  Such configuration can be supported only when each
   Relay Agent adds certain Information to DHCP messages before relaying
   them.  This additional information helps in relaying the DHCP reply
   back to the DHCP client through the same path.  This mechanism is
   referred as Relay Chaining.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kurapati-dhc-relay-chaining-dhcpv4-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-kurapati-dhc-relay-chaining-dhcpv4-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-kurapati-dhc-relay-chaining-dhcpv4-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy02LTE1MTQwNjQ4LkktREBpZXRmLm9yZz4NCg0KRU5D
T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWt1cmFwYXRpLWRoYy1yZWxh
eS1jaGFpbmluZy1kaGNwdjQtMDEudHh0DQo=
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Andre Kostur" <[email-masked]>
Date: Tue, 19 Jun 2007 09:18:57 -0700

> From: bharat_joshi [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 8:59 AM
> 
> Hi All,
> 

Have you considered the interaction of this feature with RFC 4030 (DHCP
Authentication for Relay Agents)?

Let's assume that you have:

  Device -> Relay1 -> Relay2 -> Relay3 -> Relay4 -> DHCPSvr

And that the DHCPSvr and all relays in between wish to exchange
authentication information.  The DHCPSvr will have to reconstruct the
incoming packet 4 times to get the packet as it was seen by each relay
in turn so that it can calculate the hash at each hop, as well as the
server will have to write the returned hash into the packet going back
in 4 places.

Also, I'm not sure what you are getting at in section 7 when you say:

      A Relay Agents relaying DHCP messages to another Relay Agent are
      essentially DHCP clients for the DHCP messages.  Thus, RFC3118 [4]
      is an appropriate mechanism for these DHCP messages.

RFC 3118 already has a clause that the hash is calculated as if option
82 wasn't in the packet.

---

From: bharat_joshi <[email-masked]>
Date: Wed, 20 Jun 2007 20:27:38 +0530

Hi Andre,

    Thanks a lot for your comments. Please see my response in line.

Thanks,
Bharat

> Authentication for Relay Agents)?

We did not consider this.

> authentication information.

Does each relay agent really need to exchange authentication information with DHCP server? I think not. It looks to me that Relay1 should exchange authentication information with Relay2 and Relay2 with Relay3 and so on.

I think by exchanging authentication information you mean that both relay and DHCP server knows how to process a message send by other.

>  The DHCPSvr will have to reconstruct the

I think it should work as follows:

Relay1 adds relay agent information option with authentication option and send it to relay2. relay2 knows how to process it. Now relay2 adds its own relay agent information option and authentication option and send it to relay3. relay3 knows how to process it. Relay3 would do the same and send it to relay4 and finally relay4 would do the same and send it to DHCP server.

As DHCP server exchange authentication information with relay4, it can process this information. Now to find out the Relay Agent information for the 'Device' [that can be used for applying policy], I think DHCP server must be configured with authentication information of relay1.

I understand that there is more processing involved in all the relay agents and DHCP server.

> RFC 3118 already has a clause that the hash is calculated as if option

I think this is incorrect. We shall correct it in our next version.