Subject: DHCP Packets with Option 82 from Trusted Circuit

From: "Mark Llacuna" <[email-masked]>
Date: Fri, 18 May 2001 07:48:05 -0700

Hello Everyone,

Section 2.1 of RFC 3046 says:

  A trusted circuit may contain a trusted downstream (closer to client)
  network element (bridge) between the relay agent and the client that
  MAY add a relay agent option but not set the giaddr field.  In this
  case, the relay agent does NOT add a "second" relay agent option, but
  forwards the DHCP packet per normal DHCP relay agent operations,
  setting the giaddr field as it deems appropriate.

>From an email exchange with the author of the RFC, it was clarified that
the keywords "does NOT" in the last statement, above, should be
interpreted as "MUST NOT". What was not clarified, however, was whether
or not the statement also prohibits any relay agent action that alters or
replaces the option 82.

Because we are not sure what the correct meaning of the statement is, we
are also not sure if our solution to the following problem is correct and
compliant to the RFC.  In our setup, there's a bridging DSLAM, our relay
agent, and a DHCP server as shown --

              +--------+       +-------+       +--------+
              | Bridge | _____ | Relay | _____ |  DHCP  |
              | DSLAM  |       | Agent |       | Server |
              +--------+       +-------+       +--------+

Every DHCP request that goes through the DSLAM is encoded with an option
82 and giaddr=0 by the DSLAM before it is passed onto our Relay Agent.
The problem is before forwarding the request to the DHCP Server, our Relay
Agent also needs to encode an option 82 in the request (in addition to
setting the giaddr to some appropriate value) for it to be able to forward
the corresponding response back to the DSLAM.

I understand that in the case where the DHCP server lease assignment policy
involves the use of the DSLAM's option 82, the relay agent must forward the
DHCP packet without touching the option 82.

But what about in the case where the DHCP server does not use the option 82:
will encapsulating the DSLAM's option 82 within the Relay Agent's option 82
be an acceptable solution?

Mark

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 May 2001 08:57:47 -0700

> be an acceptable solution?

Are the two devices adding competing information?   That is, are both,
for example, adding a remote-id suboption?   If not, you might
consider having the cable modem simply add its own suboptions to the
existing option 82.

I don't think the existing draft talks about encapsulating option 82
within option 82, so I don't think there's a standard way of doing
this.

Where you're really going to run into trouble is if somebody buys your
DSLAM and someone else's relay agent, or vice versa.   If that's not a
possibility, then you can just make sure that whatever leaves the
relay agent is conformant.

			       _MelloN_