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

From: "pavan_kurapati" <[email-masked]>
Date: Wed, 12 Jul 2006 04:08:20 +0530

Hi All,

      We presented our draft "Extension of DHCPLEASEQUERY in Bridging/Switching Networks" today in DHC WG meeting.       We had a discussion regarding the two solutions we have proposed for an issue we had raised in the Appendix of our draft [http://www.ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-00.txt]

      The issue is that Layer 3 Relay Agent will broadcast DHCP reply for a LEASEQUERY  to Access Concentrator [Layer 2 Relay Agent]. One solution is proposed in the draft and another solution is discussed in the presentation. [http://www3.ietf.org/proceedings/06jul/slides/dhc-0.pdf]
     
The solutions that we proposed were
      1. Create a new option for Access-Concentrator-MAC
      2. Create a new sub-option in Option 82 for Access-Concentrator-MAC

      We saw some mixed response to these solutions. Some people found the first one simple and better while others felt that we can use solution #2 but use it only in LEASEQUERY messages. In this solution, L2 Relay Agent would send this sub-option in the LEASEQUERY with no other sub-options. The server while replying to  the LEASEQUERY must append this new sub-option in Option 82 of DHCP reply message.

      Does anyone has any concerns with this approach?

Thanks & Regards,
Pavan

Pavan Kumar Kurapati
Infosys Technologies Ltd,
Electronics city,
Hosur road, Bangalore
9448613789(M)
080-56646575(R)
080-51167492(O) or 28520261 Ext : 67492

**************** 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: Andre Kostur <[email-masked]>
Date: Tue, 11 Jul 2006 16:16:28 -0700

>       Does anyone has any concerns with this approach?

I heard the opposite.  Since one cannot use option 82 in a Leasequery 
(note, if your LQ included an option 82, there would be a conflict on 
the server side.  It's supposed to reflect back option 82 as supplied by 
the requestor, but it also needs to return option 82 as originally 
supplied by the DHCP requestor), the sub-option method isn't usable at 
the leasequery time.  Thus for LQ originating from the L2 bridge would 
have to use option #1.  Option #2 would be usable when passing normal 
DHCP requests from downstream clients.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2006 19:07:43 -0400

>       Does anyone has any concerns with this approach?

What Mark said, and with which I agree, is that it's not right to make
the server put different data in option 82 in a leasequery message.  The
contents of option 82 in the leasequery message should always reflect
what was sent to the server in option 82 in the most recent exchange
with the DHCP client, so altering what the server returns is a problem
both from the perspective of server implementation complexity and also
from the perspective of simple consistency.

So in fact you have to do both (1) and (2).   The new option for the
access concentrator mac address is used in the leasequery message only,
and indicates to which MAC address the L3 relay agent should send the
leasequery reply.   The new option 82 suboption is used in normal DHCP
messages to indicate the layer 2 address of the concentrator; the layer
3 relay agent uses this suboption, when it appears in a normal reply
from the server, to forward the reply to the correct concentrator.

I am taking somewhat on face value the configuration here; one question
that occurs to me is that if we completely leave aside the question of
DHCP Leasequery for a moment, are there in fact implementations of layer
two relay agents out there at the present moment?   It's my impression
that quite a few such devices exist, but I've never put my hands on one,
so I could be mistaken.

If such devices do already exist, then the problem for normal packets
exists regardless of whether or not leasequery is being done.   So how
does the Layer 3 relay agent know to which Layer 2 relay agent to send a
server response?   If there is already a good solution to *this*
problem, then the only additional work that needs to be done is to add
the access-concentrator-mac option for use with DHCP Leasequery.

Can you clarify whether the problem I've described exists for normal
DHCP packets, or whether a solution to that problem already exists?

Thanks!

---

From: [email-masked]
Date: Wed, 12 Jul 2006 15:09:08 +0200

Hi Ted,

see below...

Ted Lemon wrote:
> that quite a few such devices exist,

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.

regards,
Stefaan

  but I've never put my hands on one,

---

From: Andre Kostur <[email-masked]>
Date: Wed, 12 Jul 2006 06:24:17 -0700

[email-masked] wrote:

[snip]

> mainly because it is promoted by the DSL Forum that the DSLAM is such 
> a layer 2 relay agent.

Stefaan:

It seems you are aware of some of the DSL applications... do the DSLAMs 
necessarily have an Ethernet MAC address?  Or can that upstream 
connection be something like ATM or fibre?  Note that the draft 
specifically talks about a 6-byte MAC address.  Is this draft 
unnecessarily restricting itself to ethernet-only L2 relays?
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "pavan_kurapati" <[email-masked]>
Date: Wed, 12 Jul 2006 18:57:00 +0530

________________________________

From: Ted Lemon [mailto:[email-masked]]
Sent: Wed 7/12/2006 4:37 AM
To: pavan_kurapati
Cc: [email-masked]
Subject: Re: [dhcwg] Proposed solutions to broadcast issue in Leasequery ext

pavan_kurapati wrote:
>>       We saw some mixed response to these solutions. Some people found the first one simple and better while others felt >>that we can use solution #2 but use it only in LEASEQUERY messages. In this solution, L2 Relay Agent would send this >>sub-option in the LEASEQUERY with no other sub-options. The server while replying to  the LEASEQUERY must append >>this new sub-option in Option 82 of DHCP reply message.
>>

>from the server, to forward the reply to the correct concentrator.

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.

>that quite a few such devices exist, but I've never put my hands on one,

Yes, there are a lot of implementations which use L2 in Access nodes and which does DHCP snooping to append Option 82. DSLAMs for eg, does the same.

>the access-concentrator-mac option for use with DHCP Leasequery.

Currently there is no way a L3 relay agent would know the MAC of L2 relay agent. So  the dhcp replies are always broadcasted by L3 RA. Infact this problem is present even without LEASEQUERY, but we thought to put it in Leasequery to address some security concerns.

Thanks!

---

From: Andre Kostur <[email-masked]>
Date: Wed, 12 Jul 2006 06:40:03 -0700

> 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 b…

Relays aren't allowed to add extra options to a DHCP packet at will.  
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).  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.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Wed, 12 Jul 2006 16:23:52 +0200

Hi Andre,

see below...

> unnecessarily restricting itself to ethernet-only L2 relays?

I do not see any other application than for ethernet only. I am not 
aware of an ATM DSLAM that is also a L2 relay agent... so just ethernet 
is fine. If generalizing it to any L2 only has minor overhead, then it 
can be done although I think it will never be used except from ethernet. 
I do not have a strong opinion about this.

regards,
Stefaan

---

From: Andre Kostur <[email-masked]>
Date: Wed, 12 Jul 2006 07:54:43 -0700

[email-masked] wrote:
> aware of an ATM DSLAM that is also a L2 relay agent... so just 
> ethernet is fine. If generalizing it to any L2 only has minor 
> overhead, then it can be done although I think it will never be used 
> except from ethernet. I do not have a strong opinion about this.

I was simply thinking that instead of specifying that the sub-option 
length (or future option) is 6, that could simply be 'n', where n is the 
length of the MAC address.  This would allow it to be used with any 
physical transport.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Wed, 12 Jul 2006 17:14:57 +0200

> length of the MAC address.  This would allow it to be used with any 

and the type of the address since this cannot be inferred from just the 
length I would think.

regards,
Stefaan

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2006 12:22:34 -0400

> mainly because it is promoted by the DSL Forum that the DSLAM is such a

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?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2006 12:34:45 -0400

> 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 b…
Actually, (1) doesn't work for non-leasequery traffic, because it's not
permissible for the relay agent to add options to the packet, other than
option 82.

> Currently there is no way a L3 relay agent would know the MAC of L2 relay agent. So  the dhcp replies are always broadcasted by L3 RA. Infact this problem is present even without LEASEQUERY, but we…

I think we need to treat this as two separate problems:

(1) How do we avoid having the L3 relay broadcast to all L2 relays when
returning DHCP packets /to the client/ from the server?

(2) How do we avoid having the L3 relay broadcast to all L2 relays when
returning DHCP Leasequery packet /to the relay/ from the server?

I think if you try to solve both problems with the same mechanism, you
are going to get into trouble.   So this is going to require two drafts,
one that specifies the mechanism for (1) and one that specifies the
mechanism for (2).   I think you already know how to solve both of these
problems, so perhaps what comes next is simply two drafts describing the
two solutions.  I would encourage you to treat the two solutions as
entirely separate, with one exception: the specification for the return
address of the L2 device should be the same.

By the way, this does bring up a problem: you probably _don't_ want to
get into specifying something like ARP here - even if the DHC working
group allows it, I doubt the IESG will.   So the token you use to
describe how to return the packet to the L2 device has to be opaque.
It may be better for the L3 device to add this token, not the L2 device
- I think this makes the specification simpler.   Does that make sense?

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 12 Jul 2006 12:57:57 -0400

> 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.)

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.

-josh

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

---

From: "pavan_kurapati" <[email-masked]>
Date: Wed, 12 Jul 2006 23:43:39 +0530

Hi Ted,

Please find replies inline

Thanks,
Pavan

>address of the L2 device should be the same.

Right. We shall bring in two drafts to address the two issues seperately

>- I think this makes the specification simpler.   Does that make sense?

Can you elaborate more on what exactly would be the issue if the token is added by L2 RA.
Agreed that it can be done by L3 RA also but then L3 RA has to check for the Src MAC of the packet
and convert it into new option/sub option. Also, there would be a problem when L3 RA has to populate the  new sub-option in the
option 82 added by L2 RA. I think L3 RA is not supposed to modify Option 82 added by L2 RA and so it does not seem to be feasible.

Thanks,
Pavan

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2006 15:50:22 -0400

> option 82 added by L2 RA. I think L3 RA is not supposed to modify Option 82 added by L2 RA and so it does not seem to be feasible.

The L3 device is going to be using the token as a return address, so it
is most qualified to determine the value of the token.   If the L2
device provides the value for the token, then you have to clearly
specify what the value should be, or else you don't really have a
standard that can be followed by independent implementors to produce
mutually interoperable implementations.

So it's possible to do it either way, but I think it's much harder to
have the L2 device do it.

As for the option 82 question, there is a problem there, particularly if
you sign the contents of option 82.   I'm not sure what to propose for
this case.   It may be that, as you say, the only way to do it is to do
it from the L2 device, but if so then I think it's going to be very hard
to write the specification.

In DHCPv6 we explicitly allow multi-hop relays with encapsulations for
each hop; it may be that in order to do this correctly, we need to allow
multiple 82 encapsulations as well.

---

From: [email-masked]
Date: Wed, 12 Jul 2006 23:57:06 +0200

Hi Pavan, Ted,

see below...

> to write the specification.

What would the problem be if the spec clearly says that the content of 
the suboption/option is a MAC address and that it has to be used to 
unicast it to that address by the L3 RA. It is true that both L2 and L3 
RA must have the same understanding of what the meaning is of the 
content of this suboption/option, but if it is clearly specified would 
there still be a problem? The suboption for 82 was already suggested in 
the expired draft draft-decnodder-dhc-rai-unicast-00.txt, which also 
refers to TR-101 where the concept of L2/L3 RA is detailed but as Josh 
already suggested, an informational RFC to clarify the whole concept 
would be very useful because the split of L2 and L3 RA is getting very 
common.

regards,
Stefaan

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2006 22:11:24 -0400

[email-masked] wrote:
> there still be a problem?

What's a MAC address?

You can't put stuff like that in RFCs.   Clearly specifying it in such a
way that it's a protocol and not a hack (that is to say, it works if you
change layer two) is hard.   You're way better off writing it in such a
way that it's not necessary to specify in detail what the address looks
like and how it works.   I would be shocked if you were to write an
ethernet-specific draft and it were to get past the IESG.