RE: Proposed solutions to broadcast issue in Leasequery ext
pavan_kurapati <pavan_kurapati <at> infosys.com>
2006-08-07 15:12:39 GMT
Hi Stig,
Please find replies inline
Thanks,
Pavan
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.
Yes, for non-leasequery we can just add another sub-option in Option 82 with a known MAC address to the
network. We were asked to bring this as a new draft. Myself and Stefaan are in the process of creating one.
Will send it out in couple of days
>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.
The problem is that in case of 'non-leasequery' the MAC address that we put in the sub-option is dependent on
whether Access Concentrator does MAC translation or not. If AC does MAC translation then the sub-option
will have MAC address of Access Concentrator. If it is acting as a pure bridge, it will have MAC address of
the client. So, an L3 RA cannot pickup this MAC in LEASEQUERY response and assume that it is AC's MAC
address. Moreover, how about LEASEUNKNOWN or LEASEUNASSIGNED. They both will not have any option 82 in
them. They will be flooded again in the network.
I think we need to add a point in the draft saying that if the new option 'access-concentrator-hw-address'
as well as the new sub-option is present (In case of LEASEACTIVE message) the new option should take
precendence over sub-option in L3 RA.
>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?
Exactly. I think adding two Option 82s, might not be proper solution.
>Stig
**************** 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***
RSS Feed