Subject: RE: [dhcwg] Proposed solutions to broadcast issue in Leasequery ext

From: "bharat_joshi" <[email-masked]>
Date: Wed, 12 Jul 2006 19:18:04 +0530

> > Agreed that (2) is complex and owing to the issues caused by the
change
> in MAC address(as described in the presentation) and other issues that
you
> pointed out I think using a new Option  (1) is a better choice.  I
feel
> that going for both might not be required. If we can get a new
'option'
> the same can be used for both normal DHCP messages as well as
Leasequery.
> L2 relay agent would need to send both Option 82 and the new option in
> normal messages and only the new option in leasequery. Server must
> echo/append both Option 82 as well as this new option in its replies.
> >
> >
>

Hi Andre,

> Relays aren't allowed to add extra options to a DHCP packet at will.

     TRUE. But we thought instead of creating one option and one
sub-option [containing same information], we can use a new option.
That's why we proposed this.

> Option 82 was specially crafted to be allowed to be added by relays
> (which is also why 82 must be the last option in the packet, exception
> option 255).

Agree.

  Also, it would be superfluous information in the packet to
> do (1) & (2) at the same time.  The L2 relay agent would only need to
> send the sub-opt in normal DHCP relayed packets (allows the DHCP
server
> to be aware of what L2 relay the client passed through, in case it
> cares), and the L2 relay would only need to add the option into
> Leasequeries that it originates.

So as you, Ted and Mark suggested it seems we would need to go for both
a new option and a new sub-option in options 82.

Regards,
Bharat

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

---

From: "bharat_joshi" <[email-masked]>
Date: Wed, 12 Jul 2006 23:48:14 +0530

Hi Ted,

>
> Ted Lemon wrote:
> > [email-masked] wrote:
> >> There are implementations and deployements of such devices. This is
> >> mainly because it is promoted by the DSL Forum that the DSLAM is
such a
> >> layer 2 relay agent.
> >
> > Can you explain briefly how this works?   Do we need to write a
standard
> > describing how they should work, so that interoperable
implementations
> > are possible, or is there already such a standard?
>
> I don't know if we need a standard (maybe), but I do think an
> informational RFC would be useful.  This is actually something I've
been
> intending to start for some time.  To help the DSLForum clarify their
> use of L2 Relay Agents, I help provide requirements to TR-101
> (http://www.dslforum.org/techwork/tr/TR-101.pdf), and supplied text
that
> appears in an appendix to TR-101.  (In addition to DSLForum review,
this
> benefited from review by both Ralph and some Cisco folks who have also
> implemented this technology in ethernet switches.)
>

As josh mentioned there is no standard yet and I also think we need at
least something which talks about Layer 2 Relay Agent, their functioning
and how they fit in a layer 2 Access Network [One section in our draft
has briefly described this ]

> DHCPv4 Relay agents don't have a lot of detailed description in RFC's,
> as they mostly inherit from the BOOTP function, which is pretty basic.
> RFC 3046 mentions a relay receiving packets with option-82 from a
> trusted downstream interface, but there is no guidance about how one
> would implement this, or what they rules are.  The appendix to TR-101,
> and the invention of the Layer 2 DHCP Relay Agent term (thanks Ralph)
> are the beginnings of work that I think should be carried forward
within
> the IETF to clarify the different roles of DHCP relays and proxies
(DHCP
> proxies are another thing which exists in the wild, but are not
clearly
> specified).  These "stupid DHCP tricks" can be very useful in specific
> environments, but without implementation guidelines, interoperability
> may be hard to ensure, and appropriate participation in things like
> leasequery might not be obvious.
>

Agree.

If other people also agree then we can come out with a small
informational document on Layer 2 Relay Agent and their usage in Layer 2
Access Network.

~Bharat

> -josh
> --
> =====================================================================
> Josh Littlefield                                  Cisco Systems, Inc.
> [email-masked]                             1414 Massachusetts Avenue
> tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205
>