Subject: [dhcwg] IETF76 dhcwg agenda UPDATE

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 12 Nov 2009 08:50:37 +0900

The agenda for the dhcwg meeting has changed:

DHC WG Agenda - IETF 76
0900-1130 2009-11-12
(Last revised 2009-11-12 08:35 JST)
-------------------------------------
          
          Administrivia                              Chairs
5 minutes
                  Agenda bashing; blue sheets; scribe; Jabber scribe
                  Draft last call and adoption announcements
          
          Working Group Charter                      Chairs
10 minutes
                  Clear outdated items, discuss changes to accommodate new
work
          
          DHCPv6 option for network boot             Authors or Chairs
5 minutes
                  <draft-ietf-dhc-dhcpv6-opt-netboot-06>
                  Revised, ready for last call?
          
          DHCPv6 Redundancy Considerations           J. Brzozowski
15 minutes
                  <draft-brzozowski-dhcpv6-redundancy-considerations>
          
          EAP Authentication for DHCP for Broadband  Ric Pruss
10 minutes
                  <draft-pruss-dhcp-auth-dsl-06>
          
          DHCP Authentication Analysis               Chairs
10 minutes
                  <draft-brzozowski-dhcp-eap-analysis>
                  Status Update
          
          Secure DHCPv6 Using CGAs                   Sean Shen
15 minutes
                  <draft-jiang-dhc-secure-dhcpv6>
          
          DHCP Relay Agent Stacking                  Robin Zheng
10 minutes
                  <draft-zheng-dhc-relay-agent-stacking-00.txt>
                  proposes to have more than one Relay Agents adding DHCP
Option 82
          
          Multiple Relay Agent Information Option    Hui Deng
10 minutes
                  <draft-huang-dhc-multiple-relay-agents-option-00>
                  proposes using a different option for stacking relay agent
information
          
          DHCPv6 Route Option                        W. Dec
10 minutes
                  <draft-dec-dhcpv6-route-option-02>
                   
----------
                   
100 minutes
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
=========================================

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 12 Nov 2009 09:13:41 +0530

Hi All,

      Just noticed this. The following two drafts provide a solution for similar problem.

>           DHCP Relay Agent Stacking                  Robin Zheng           10 minutes
>                   proposes to have more than one Relay Agents adding DHCP Option 82
>           
>           Multiple Relay Agent Information Option    Hui Deng              10 minutes
>                   proposes using a different option for stacking relay agent information
>           

       Couple of years back, we have identified the similar issue because of the introduction of Layer 2 Relay Agent in the network and had come out with a draft based on the suggestions from working group. A new revision of that draft was published couple of months back. None of the author could attend this IETF meeting and so we could not present it.

       Our solution proposed to create a new sub-option for option 82. A relay agent receiving a packet with option 82, create its own option 82, populate it as it is configured and also create this new sub-option in its own option 82 and populate it with the received option 82. This way server will see only one option 82 and can dig into sub-option recursively to find the deepest option 82. On return path, every relay agent will remove its own option 82 and pass it to the previous relay agent.

       For more detailed text, please refer to http://tools.ietf.org/html/draft-kurapati-dhc-relay-chaining-dhcpv4-02

       Before we take a decision on a particular method to solve this problem, I would request everybody to review all the drafts and then take an informed decision.

Thanks,
Bharat

---

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 12 Nov 2009 14:11:21 +0900

Bharat,

Our AD actually mentioned this to us and during the meeting we felt that it
might not be exactly related to the work you did.

However, since you have email about the time I would like to suggest that
the authors of the new work include you in their activities to see if their
is a collaborative opportunity here.

Does this work for you?

Sean, Hui,

Any comments?

John

On 11/12/09 12:43 PM, "Bharat Joshi" <[email-masked]> wrote:

>        Couple of years back, we have identified the similar issue because of
> the introduction of Layer 2 Relay Agent in the network and had come out with a
> draft based on the suggestions from working group. A new revision of that
> draft was published couple of months back. None of the author could attend
> this IETF meeting and so we could not present it.
> 
>        Our solution proposed to create a new sub-option for option 82. A relay
> agent receiving a packet with option 82, create its own option 82, populate it
> as it is configured and also create this new sub-option in its own option 82
> and populate it with the received option 82. This way server will see only one
> option 82 and can dig into sub-option recursively to find the deepest option
> 82. On return path, every relay agent will remove its own option 82 and pass
> it to the previous relay agent.
> 
>        For more detailed text, please refer to
> http://tools.ietf.org/html/draft-kurapati-dhc-relay-chaining-dhcpv4-02
> 
>        Before we take a decision on a particular method to solve this problem,
> I would request everybody to review all the drafts and then take an informed
> decision.
> 
> Thanks,
> Bharat
> 
>

---

From: zhengruobin 35664 <[email-masked]>
Date: Fri, 13 Nov 2009 08:51:15 +0800

Welome aboard! 

Regarding to the potential solution, what I can think is as follow.

1. To allow the "second" relay agent to modified the Circuit ID suboption of option82 in transit. But this will invalidate the signature added by the "first" relay agent.

2. To create a new sub-option for option 82. But again this will invalidate the signature added by the "first" relay agent.

3. To introduce a new option with multiple suboptions so that each relay agent can add its own relay agent information as one suboption. However, it's required to update the software of all devices where relay agent resides.

4. To allow adding the "second" option 82. It is simplest way. It will not invalidate the signature. There is no need to update the software of the first-level relay agent. Thus, protect the legacy device furthest.
 
5. To introduce a new option with the same format of Option 82. The "first" relay agent adds the Option 82 as usual. The "second" relay agent adds its relay agent information as a new option. If there is a "third" relay agent, it adds its relay agent information as a new option again. In this way,  it not only will not invalidate the signature but also will not need to update the software of the first-level relay agent.

As a vendor of access products, I would like to recommend the fourth one or the fifth one .

----- 原邮件 -----
发件人: John Jason Brzozowski <[email-masked]>
日期: 星期四, 十一月 12日, 2009 下午1:11
主题: Re: IETF76 dhcwg agenda UPDATE
收件人: Bharat Joshi <[email-masked]>, Ruobin Zheng <[email-masked]>, Hui Deng <[email-masked]>
抄送: Ted Lemon <[email-masked]>, dhc WG <[email-masked]>

> >       Just noticed this. The following two drafts provide a 
> solution for
> > similar problem.
> > 
> >>           DHCP Relay Agent Stacking                  Robin 
> Zheng           10
> >> minutes
>           10
> >> minutes

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 13 Nov 2009 12:27:06 +0530

Hi,

> Welome aboard! 

Thanks!

Sometime back, we had some discussion on this with Hui and Lu Huang.

> 1. To allow the "second" relay agent to modified the Circuit ID suboption of option82 in transit. But this will invalidate the signature added by the "first" relay agent.

I agree and I think we should not go down this path.
 
> 2. To create a new sub-option for option 82. But again this will invalidate the signature added by the "first" relay agent.

How? What exactly you mean by 'invalidate the signature added by first relay agent'?

I am not sure if you read through our proposed solution. We proposed something on this line but our solution preserve the option 82 added by all relay agents and one relay agent does not change the option 82 added by any of the previous relay agent.

If you want I can describe the complete functionality here but I would suggest you to go through the draft which will provide more clarity.

There were multiple reasons to choose this:

* As you mentioned below, we do not need to change the software in the first RA.
* This also does not invalidate the option 82 added by the first RA as you want in the solution. 
* Because we are putting in the complete option 82 in a sub-option of option 82, we do not need to add any new option.
* DHCP server does not need to learn parsing a new option because the new sub-option contains the option 82 and it already knows how to parse it. [This is from implementation perspective]
 
> 3. To introduce a new option with multiple suboptions so that each relay agent can add its own relay agent information as one suboption. However, it's required to update the software of all devices…

We wanted to avoid getting a new DHCPv4 option for this. There were two reasons, one is as you pointed out that all the device's software need upgradation and another is that there are very small number of new DHCPv4 options available now so we wanted to avoid it if we can.

> 4. To allow adding the "second" option 82. It is simplest way. It will not invalidate the signature. There is no need to update the software of the first-level relay agent. Thus, protect the legacy…

Actually we had proposed this in one of the IETF meeting where we have proposed this work but there was some resistant on repeating this option in DHCP message. I do not remember the cause of this resistance though. May be someone still remembers that discussion and can add to it.

> 5. To introduce a new option with the same format of Option 82. The "first" relay agent adds the Option 82 as usual. The "second" relay agent adds its relay agent information as a new option. If th…

Ok. But this is not very different than what you mentioned in point 4. The only thing which we are taking care is that not repeating option 82 instead we will repeat option 'X'.

> As a vendor of access products, I would like to recommend the fourth one or the fifth one .

It would be great if you can send me your comments on the solution proposed by us in our draft.

Thanks,
Bharat

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 15 Nov 2009 17:33:41 -0600

>> 4. To allow adding the "second" option 82. It is simplest way.
>>It will not invalidate the signature. There is no need to update
>>the software of the first-level relay agent. Thus, protect the
>>legacy device furthest.
>>  
>
>Actually we had proposed this in one of the IETF meeting where we
>have proposed this work but there was some resistant on repeating
>this option in DHCP message. I do not remember the cause of this
>resistance though. May be someone still remembers that discussion
>and can add to it.

The problem is RFC 3396. A 2nd instance of an option just means to concatenate the two instances into one.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bharat Joshi
Sent: Friday, November 13, 2009 1:57 AM
To: zhengruobin 35664; John Jason Brzozowski
Cc: dhc WG; Ted Lemon
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

Hi,

Thanks!

 

 

Thanks,
Bharat

> > is a collaborative opportunity here.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Nov 2009 17:53:25 -0700

> The problem is RFC 3396. A 2nd instance of an option just means to concatenate the two instances into one.

While this is true in a sense, if the specification defines a layering process for multiple options of the same type, that could supersede RFC 3396 for this particular case.   And this is a reasonable exception - relay agent options *require* special handling anyway.

You can argue that it would be better not to do this because it makes the code on the DHCP server simpler, and that would probably be a valid argument, but I don't see any way to layer arbitrary relay agent option sets without an exception to RFC3396 or else some other similar exception.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 15 Nov 2009 19:58:33 -0600

Ted:

The problem is that the cat is already out of the bag ... servers are
already assuming option 82 could have been split into multiple pieces
and concatenating them (RFC 3396 didn't prohibit this).

So, how would these servers react? Perhaps they'll only find the first
instance of each suboption, but this could end being a mixed bag if the
relays included different suboptions (i.e., one included circuit id, the
other didn't, and vice versa for the remote-id).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Sunday, November 15, 2009 7:53 PM
To: Bernie Volz (volz)
Cc: Bharat Joshi; zhengruobin 35664; John Jason Brzozowski; dhc WG
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

> The problem is RFC 3396. A 2nd instance of an option just means to
concatenate the two instances into one.

While this is true in a sense, if the specification defines a layering
process for multiple options of the same type, that could supersede RFC
3396 for this particular case.   And this is a reasonable exception -
relay agent options *require* special handling anyway.

You can argue that it would be better not to do this because it makes
the code on the DHCP server simpler, and that would probably be a valid
argument, but I don't see any way to layer arbitrary relay agent option
sets without an exception to RFC3396 or else some other similar
exception.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Nov 2009 19:00:12 -0700

> and concatenating them (RFC 3396 didn't prohibit this).

We can't use option 82 anyway, because relays won't append a second option 82 if there's one there already.   So we need to define a new option.   Servers that support it will do the right thing; servers that don't will concatenate it, but since they don't support it, it doesn't matter.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 15 Nov 2009 20:02:15 -0600

>We can't use option 82 anyway.

Agreed. I was just trying to answer the original question as to why two
option 82's would not work.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Sunday, November 15, 2009 9:00 PM
To: Bernie Volz (volz)
Cc: Bharat Joshi; zhengruobin 35664; John Jason Brzozowski; dhc WG
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

> and concatenating them (RFC 3396 didn't prohibit this).

We can't use option 82 anyway, because relays won't append a second
option 82 if there's one there already.   So we need to define a new
option.   Servers that support it will do the right thing; servers that
don't will concatenate it, but since they don't support it, it doesn't
matter.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Nov 2009 19:09:30 -0700

> option 82's would not work.

Gotcha.

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 17 Nov 2009 09:23:08 +0530

Hi,

> It would be great if you can send me your comments on the solution proposed by us in our draft.

       So I would like to ask all participants to read our draft and send us your comments. Based on that we can work to find a solution for this problem.

Thanks,
Bharat

---

From: Hongyu Li <[email-masked]>
Date: Tue, 17 Nov 2009 14:50:20 +0800

Ted and Bernie,

Perhaps we can re-think about the cases that why we have all these
discussion. Currently two cases have been identified as requiring more than
relay agents to add its circuit ID into the DHCPv4 messages, one is PON
network, the other is Enterprise LAN network with cascaded switches. This
means that not all DHCP relay agents are required to add a second option 82.

There is no problem for the first relay to add its circuit ID to DHCP
message. The later relays that need adding circuit IDs should be well
controlled or managed. These devices are required or configured to do so. In
this sense, relay agent options (may be multiple option 82) are added under
control.

RFC 3396 actually provided a good way for concatenating multiple option 82
and may work well in cases we are discussing, where relays are cascaded.
Supposing each related relay adds its own part of circuit ID info, the
server or the device that deals with these options may simply concatenate
these circuit ID info and get what we need.

Cheers,
Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
Sent: Monday, November 16, 2009 10:00 AM
To: Bernie Volz (volz)
Cc: dhc WG
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

> and concatenating them (RFC 3396 didn't prohibit this).

We can't use option 82 anyway, because relays won't append a second option
82 if there's one there already.   So we need to define a new option.
Servers that support it will do the right thing; servers that don't will
concatenate it, but since they don't support it, it doesn't matter.

---

From: Hongyu Li <[email-masked]>
Date: Tue, 17 Nov 2009 15:04:12 +0800

Bharat,

It might be too early to say only 2 and 5 are among choices.

Adding a new sub-option for option 82 will change existing option 82 in DHCP
message. "invalidate the signature" means if the original DHCP message has a
signature made by the whole DHCP message (including Option 82), changing
option 82 by later relay agents will invalidate the signature. Therefore,
method 2 and 1 have same issue in this case. 

However, if there is no signature added by DHCP relay agents, method 1 and 2
may both work.

As for your draft, generally, I'd say it work. However, I would agree with
John's previous comments that it doesn't quite fit to the issue we are
having here.
I am not sure how DHCP server in the field would deal with it. As it is a
new sub-option, existing DHCP servers have no way to understand it and find
the multi-layer packed first option 82. Though DHCP server may recognize
option 82, but not the sub-option. If not the sub-option, it can't find
complete circuit ID info. That said, issue in the two cases triggering this
discussion is not solved.

Cheers,
Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bharat Joshi
Sent: Tuesday, November 17, 2009 11:53 AM
To: Bharat Joshi; zhengruobin 35664; John Jason Brzozowski
Cc: dhc WG; Ted Lemon
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

Hi,

        I hope you have seen the discussion on mailing list about why we can
not use two option-82 in the header. So now we are left with following two
options:

> > 2. To create a new sub-option for option 82. But again this will
invalidate the signature added by the "first" relay agent.
> I am not sure if you read through our proposed solution. We proposed
something on this line but our solution preserve the option 82 added by all
relay agents and one relay agent does not change the option 82 added by any
of the previous relay agent.
> 
> If you want I can describe the complete functionality here but I would
suggest you to go through the draft which will provide more clarity.
> * Because we are putting in the complete option 82 in a sub-option of
option 82, we do not need to add any new option.
> * DHCP server does not need to learn parsing a new option because the 
> new sub-option contains the option 82 and it already knows how to 
> parse it. [This is from implementation perspective]
> 

> > 5. To introduce a new option with the same format of Option 82. The
"first" relay agent adds the Option 82 as usual. The "second" relay agent
adds its relay agent information as a new option. If there is a "third"
relay agent, it adds its relay agent information as a new option again. In
this way,  it not only will not invalidate the signature but also will not
need to update the software of the first-level relay agent.
> >
> 
> Ok. But this is not very different than what you mentioned in point 4. The
only thing which we are taking care is that not repeating option 82 instead
we will repeat option 'X'.
> It would be great if you can send me your comments on the solution
proposed by us in our draft.

       So I would like to ask all participants to read our draft and send us
your comments. Based on that we can work to find a solution for this
problem.

Thanks,
Bharat

---

From: Bud Millwood <[email-masked]>
Date: Tue, 17 Nov 2009 11:43:29 +0100

> > option 82's would not work.

Am I right in understanding that this discussion is just for DHCPv4? For 
DHCPv6, each relay header holds information specific to that relay agent, so 
having multiple relay agent options with DHCPv6 is a no brainer... correct?

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 17 Nov 2009 08:32:29 -0600

Yes, we have no issues with DHCPv6 - multiple relays are no brainer
there (well, there is an issue for the server as to which relay's
information it should use - as there could be situations where the first
2 relays are in the customer's network and the 3rd (and others) are in
the service providers -- the service provider would likely not want to
use anything that was provided by the customer's relays). But, this is a
problem whenever you have multiple relays -- whether v4 or v6.

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2009 5:43 AM
To: [email-masked]
Cc: Ted Lemon; Bernie Volz (volz); John Jason Brzozowski
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

DHCPv6, each relay header holds information specific to that relay
agent, so 
having multiple relay agent options with DHCPv6 is a no brainer...
correct?

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 17 Nov 2009 08:47:26 -0600

No, I think multiple instances of option 82 are a problem because:
1. There is no way for the server to know where one relay's data ends
and another starts -- this assumes that the server does what RFC 3396
says and treats the two as one large option. Likely the server needs
special logic to keep the option 82 information separate. But this also
prevents a relay-option from ever being more than 255 bytes because
there cannot be two instances -- as they are assumed to be separate
options. So, neither are good choices.
2. There is no way for existing servers to know that anything special
has happened -- though one might argue that if you're going to deploy
multiple relays, you MUST use newer software on your relays and servers
that knows how to deal with it.
3. The server would need special logic to handle replying - it would
need to return multiple option 82 options to that each relay could
remove what it added.

Personally, I think this requires just too much special care and
handling to be worth it.

There are far better solutions using new options.

It could even be argued that there are even more drastic changes that
could be made here - since it really requires replacing relays and
servers (well at least the software in them) to support this. For
example, one could use a more DHCPv6 like technique and encapsulate the
client/relayed messages (the first relay would not need to do this, but
the 2nd and later could). This would also address some other issues with
overloading giaddr (though we already have existing techniques to handle
this).

Perhaps someone can think up a 'backwards' compatible way to handle this
so that only the 2nd and later relays need changing (no server changes),
but I suspect that would require adding a lot of logic into relays which
is probably not that desirable.

- Bernie

-----Original Message-----
From: Hongyu Li [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2009 1:50 AM
To: 'Ted Lemon'; Bernie Volz (volz)
Cc: 'dhc WG'
Subject: RE: [dhcwg] IETF76 dhcwg agenda UPDATE

Ted and Bernie,

Perhaps we can re-think about the cases that why we have all these
discussion. Currently two cases have been identified as requiring more
than
relay agents to add its circuit ID into the DHCPv4 messages, one is PON
network, the other is Enterprise LAN network with cascaded switches.
This
means that not all DHCP relay agents are required to add a second option
82.

There is no problem for the first relay to add its circuit ID to DHCP
message. The later relays that need adding circuit IDs should be well
controlled or managed. These devices are required or configured to do
so. In
this sense, relay agent options (may be multiple option 82) are added
under
control.

RFC 3396 actually provided a good way for concatenating multiple option
82
and may work well in cases we are discussing, where relays are cascaded.
Supposing each related relay adds its own part of circuit ID info, the
server or the device that deals with these options may simply
concatenate
these circuit ID info and get what we need.

Cheers,
Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of
Ted Lemon
Sent: Monday, November 16, 2009 10:00 AM
To: Bernie Volz (volz)
Cc: dhc WG
Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

option

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 17 Nov 2009 15:52:17 -0800

On Sun, Nov 15, 2009 at 07:00:12PM -0700, Ted Lemon wrote:
> option 82 if there's one there already.

We can't use the agent option?  But...as the slides said, this is what
we do today...since the most interesting information is usually from
the relay closest to the client, that is what is retained and used as
first-class agent options in the server.  It seems to be working well
for us today.

A new option cloning the relay agent information option would just
muddy the water.  As a relay agent implementer, which one do you
populate?  How can you possibly detect if you're first in a relay
agent chain (even with a maximum of 2 relays)?  Given that you know
you should be populating the new option (you are "most likely" to be
the outermost relay or something?), are you generally going to do
that, knowing that it would make server-configurations with your
device uncomfortable or complicated on current-era DHCPv4 servers
even when there wasn't a second relay agent in the mix?

I think you've mis-characterized the problem; we are not looking at
new first-tier relay agent devices that need a new way to express
their agent options to the DHCPv4 server.  They already have it and
it is working well.

The problem we are talking about is in-the-middle relay agents which
currently have no way to express their agent options to the DHCPv4
server when the outermost relay has already consumed it.  This is
where behaviour should change.

There are compelling reasons why that behaviour should be neither the
application of multiples of the current agent options, nor multiples
of the agent sub-options.

I've already posited some flaws in reasoning the addition of a new
parallel option.  This kind of "let's just do this twice" reasoning is
what's gotten us in trouble with the DHCPv4 client identifier.  In
trying to provide an extra, elective way to provide disambiguated
values, we succeed only in ambiguity.

Which leaves the addition of a new agent sub-option, one in which
the middle agent places its usual relay agent information option.

If servers don't support the new sub-option and thus the middle agent,
that's fine, they will still support the outermost relay agent's
information option contents without anyone having to sacrifice their
product's quality and polish for the WG to get an easy out.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 18 Nov 2009 15:09:02 +0530

Hi David, Ted, Hongyu, Lu Huang and all,

         I think I like what David has proposed in this mail.

> values, we succeed only in ambiguity.

I agree.
 
> product's quality and polish for the WG to get an easy out.

What I like about this idea is that it fulfils all the use cases and it may work with existing DHCP servers as well.

We had also proposed a new sub-option in our draft but the main difference is that 2nd and subsequent Relay Agent was creating this sub-option with option 82 of the received message.

Now my question is whether it is ok to let a Relay Agent insert a sub-option in an already existing option 82 which was added by a previous Relay Agent. If yes, I think we could use this.

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