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

From: Stig Venaas <[email-masked]>
Date: Mon, 07 Aug 2006 16:38:16 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "pavan_kurapati" <[email-masked]>
Date: Mon, 7 Aug 2006 20:42:39 +0530

Hi Stig,

Please find replies inline

Thanks,
Pavan

>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

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

>supposed to both echo that back and add the value of option 82 from the

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Aug 2006 10:58:54 +0200

pavan_kurapati wrote:
[...]
> 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 th…

What I was thinking was to put the MAC address the AC wants the 
leasequery response sent to as an 82 suboption. Basically the same 
content as your proposed new option.

You're right that it doesn't work with unknown or unassigned though, so 
maybe not so good after all... The advantage though is that it requires 
no server changes. Oh well, I agree that a new generic option that can 
be used also for other messages than leasequery might be useful, but it 
will be harder to deploy since server behaviour needs be changed.

> Exactly. I think adding two Option 82s, might not be proper solution.

Right. I'm still worried that things might break, how can you ensure in 
general that the L3 relay agent doesn't add option 82 to leasequery 
messages?

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Aug 2006 11:34:53 +0200

Bharat Joshi wrote:
[...]
> Yes. This was one of the options proposed in our slides and people
> during meeting suggested not to use it for DHCPLEASEQUERY replies.

The L2 relay originating the leasequery message can't add option 82 
(hence no suboption), I think that was the issue. My point is that you 
may not need to do add any options to leasequeries, if the L3 relay can 
make use of option 82 in the leasequery responses (they are in the 
responses since L2 relay added this subtoption when relaying messages). 
But it doesn't work when there is a negative leasequery response.
> This was the primary reason for proposing new sub-option in option-82
> but as this can not be done, people suggested that we should go for a
> new option which will make things more simple and clean.

Again, what couldn't be done, is to have option-82 sent by L2 relay in 
the leasequery; I think. Or have I missed something?

A new option is probably cleaner though, but that requires changes to 
all the dhc components.

> A very good question indeed. As of now, there is no way it can be done
> and I feel our draft does not have any suggestions on this yet.
> 
> Though I am still thinking, I feel we may need to suggest that L3 Relay
> Agent SHOULD not add option 82 to a DHCPLEASEQUERY messages which it is
> relaying to server.

Yes. Even MUST NOT. Note that this is a generic problem with leasequery 
when having multiple levels of relay agents, not just for your case.

Stig

> ~Bharat

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 08 Aug 2006 14:46:18 +0530

Stig,

Thanks,
~Bharat