Subject: [dhcwg] Solution for broadcast issue in Leasequery ext

From: "pavan_kurapati" <[email-masked]>
Date: Mon, 17 Jul 2006 21:08:07 +0530

Hi All,

  Tthanks a lot for all the people who provided feedbacks
on our draft.

   Based on the discussion during WG meeting in Montreal and subsequent
discussion on mailing list, it looks like we have some consensus about
the solution for the open issue we had raised.

   The issue which we raised is that a Layer 3 Relay Agent would
broadcast the DHCP reply message to the layer 2 Relay Agent in a typical
Layer 2 Access Network. Pl. refer to our proposed draft for more
details:
http://ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-00.txt

    Pl refer to our slides at
http://www3.ietf.org/proceedings/06jul/slides/dhc-0.pdf

    As discussed, we need both the solution we proposed during the
meeting:

* A new option which will be used in a DHCPLEASEQUERY message
* A new sub-option in option 82 which will be used for all other DHCP
messages.

    The value of the option would contain following information:

htype: 1 byte of Hardware type [Similar to how we set it in DHCP header]
hlen: 1 byte which tells the length of hwaddr field which is of interest
hwaddr: 16 bytes [only some bytes might be interesting, for ex 6 bytes
for Ethernet]

+-------+-------+----------------+
| htype | hlen  |    hwaddr      |
+-------+-------+----------------+

    The same format will be used in the new option and in the new
sub-option of option-82 to keep it consistent as the usage is same.

    In our draft, We have proposed that this option [or sub-option in
option-82] would need to be added by the Layer 2 Relay Agent and server
should echo it back in a reply. Layer 3 relay agent SHOULD look for this
option and if found, it MUST unicast the message to the hardware address
found in the option.

    Ted has suggested that Layer 3 Relay Agent should add this option
instead of Layer 2 but this may create issues in following case:

* If a few L2 Access nodes cannot process unicast directly, there is no way an L3 agent would know.  In our proposed case, if a layer 2 Relay Agent does not add the new option, Layer 3 Relay Agent would need to broadcast the message.

* In case of messages other than DHCPLEASEQUERY, Layer 3 Relay Agent
would end up modifying the option-82 string added by Layer 2 Relay Agent
which is not correct.

    Please let us know your concerns about this solution.

Thanks,
Pavan
Pavan Kumar Kurapati
Infosys Technologies Ltd,
Electronics city,
Hosur road, Bangalore

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