Proposed solutions to broadcast issue in Leasequery ext

 

________________________________

From: Ted Lemon [mailto:Ted.Lemonnominum.com]
Sent: Wed 7/12/2006 4:37 AM
To: pavan_kurapati
Cc: dhcwgietf.org
Subject: Re: [dhcwg] Proposed solutions to broadcast issue
in Leasequery ext



pavan_kurapati wrote:
>> 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?

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


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.


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


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.


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


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.

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

Thanks!



**************** 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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

pavan_kurapati wrote:
>>> 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
>>>       
>
> 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.
>
>   

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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

pavan_kurapati wrote:
> 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.
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 thought to put it in Leasequery
to address some security concerns.

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?



_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

Andre Kostur wrote:
> pavan_kurapati wrote:
> 
>>>> 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
>>>>       
>>
>>
>> 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.
>>
>>   
> 
> 
> 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.

I've finally studied this in detail, I know it's a bit
late to enter the 
discussion...

I think it could be made to work with just option 82. For
relayed 
messages (non-leasequery) the L2 relay agent could add
option 82 with 
the L2 address etc. as you say.

For leasequery you won't have to add any options at all if
my 
understanding is correct. The responses to the leasequery
should contain 
the value of option 82 that was in the original request. The
L3 relay 
can then make use of this. Maybe a bit ugly, but introducing
a new 
option requires new server behaviour which is kind of bad as
well.

One thing I started to wonder about. The leasequery message
should have 
no option 82 when originated by the L2 relay agent. Is it
possible that 
the L3 relay might add option 82, causing problems when the
server is 
supposed to both echo that back and add the value of option
82 from the 
original request?

Stig

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg