Subject: [dhcwg] Layer 2 Relay Agent Information draft

From: Bharat Joshi <[email-masked]>
Date: Wed, 22 Apr 2009 06:43:56 +0530

Hi All,

       We have published version 04 of Layer 2 Relay Agent Information draft. This version addresses several editorial comments provided by Alfred.

       Draft is available at http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.txt

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

---

From: Ramesh <[email-masked]>
Date: Sun, 26 Apr 2009 15:43:26 +0530

Bharat,

Few comments/suggestions. Search for [Ramesh].

Section 4.1.1
-------------
3 ... The DHCP server responds with a DHCPOFFER message after applying
its local policies.
[Ramesh] Will it be good to mention ".. after applying its local policies for
address allocation". This is just to make clear of what policy, DHCP
is all concerned
about and readers do not relate this to any system policies.

Section 4.1.1
-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP
messages from server
_if_ it has inserted option-82. This is because for a client,
option-82 do not make any sense.

section 4.1.1
-------------
6. ...

DHCPNACK  - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok?

section 4.2.2
-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of
two conflicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn
from the REQUEST+ACK message exchange which involves only one server. So there
is no question of keeping a client state more than its life time. Am I missing
something here?

In any case, Maintaining a state ( and hence filter) even after a
client is dead,
mean anomalies.

section 4.3.2
-------------
3 ...Because of this, it could be difficult for the DHCP server to differentiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and
REBIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out
an IP and
hence it would know the state of the client based on T1 & T2.

-- 
cheers
ramesh

On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <[email-masked]>wrote:

> Hi All,
>
>       We have published version 04 of Layer 2 Relay Agent Information
> draft. This version addresses several editorial comments provided by Alfred.
>
>       Draft is available at
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.txt
>
> Thanks,
> Bharat
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: pavan_kurapati <[email-masked]>
Date: Sun, 26 Apr 2009 19:04:23 +0530

Hi Ramesh,
Thanks for the review. Please find replies inline

Thannks,
Pavan
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ramesh [[email-masked]]
Sent: Sunday, April 26, 2009 3:43 PM
To: Bharat Joshi
Cc: [email-masked]
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft

Bharat,

Section 4.1.1

-------------
3 ... The DHCP server responds with a DHCPOFFER message after applying its local policies.
[Ramesh] Will it be good to mention ".. after applying its local policies for
address allocation". This is just to make clear of what policy, DHCP is all concerned
about and readers do not relate this to any system policies.

[Pavan] I feel the text is generic and conveys the message.

Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server
_if_ it has inserted option-82. This is because for a client, option-82 do not make any sense.

[Pavan] Mandating all L2RAs to intercept unicast messages may be too strict behavior  given that there are implementations which doesnt do it. I feel 'may' is good here.

section 4.1.1
-------------
6. ...

[Pavan] Yes, thanks. Will change it.

section 4.2.2

-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of two conflicting

In any case, Maintaining a state ( and hence filter) even after a client is dead,
mean anomalies.

[Pavan] This condition can occur when multiple DHCP servers are configured for failover. In such a configuration, there are servers which ignore server-id and in certain exceptional conditions may respond to the same IP address request with multiple ACKs. In this scenario, L2RA must take the one which has more lease time.

section 4.3.2

-------------
3 ...Because of this, it could be difficult for the DHCP server to differentiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out an IP and
hence it would know the state of the client based on T1 & T2.

[Pavan] Actually this state is in terms of client's context. A client would broadcast the dhcp message with client address filled in this state. In case of failover configurations, a REBIND may imply that one of the primary server is not responding [since it is broadcast]. However, in L2RA, since unicast messages are also intercepted and option 82 added, a RENEW may be misunderstood as REBIND by server. Let us know if it is not clear.

--
cheers
ramesh

On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Thanks,
Bharat
[email-masked]<mailto:[email-masked]>

---

From: Ramesh <[email-masked]>
Date: Sun, 26 Apr 2009 21:50:13 +0530

Pavan,
Please see comments inline

Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP
messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP
messages from server
_if_ it has inserted option-82. This is because for a client, option-82 do
not make any sense.
[Pavan] Mandating all L2RAs to intercept unicast messages may be too strict
behavior  given that there are implementations which doesnt do it. I feel
'may' is good here.
[Ramesh] My concern here is, L2RA should intercept all packets from server,
as server could do unicast reply for a broadcast request.
As per RFC 3046 information option have to be stripped off by the relay
agent which added it,
"

   The Relay Agent Information option echoed by a server MUST be removed
   by either the relay agent or the trusted downstream network element
   which added it when forwarding a server-to-client response back to
   the client.

"
Also, I think it will be harsh on the client by asking it to accept a DHCP
option which a client software does not care at all.
Today, there _can_ be DHCP clients which misbehave(?) when it see an
option-82, as RFC 3046 clearly removes client's relationship with option-82.

section 4.2.2

-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of two
conflicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn
from the REQUEST+ACK message exchange which involves only one server. So
there
is no question of keeping a client state more than its life time. Am I
missing
something here?

In any case, Maintaining a state ( and hence filter) even after a client is
dead,
mean anomalies.
[Pavan] This condition can occur when multiple DHCP servers are configured
for failover. In such a configuration, there are servers which ignore
server-id and in certain exceptional conditions may respond to the same IP
address request with multiple ACKs. In this scenario, L2RA must take the one
which has more lease time.
[Ramesh] I feel we are leaving a security hole here.
Say you have a client which should be leased IP for 10 minutes. One server
lease with 10 minutes and another server with 20 minutes of lease interval.
L2RA will assume the client is valid for 20 minutes and tune the filter.
Whereas the management box ( eg. BRAS) would think it is valid for 10
minutes.
So it is like allowing an unauthorized client to be active from 10 to 20th
time instance. ?
By the way, how is the client expected to behave when it gets two lease. Is
it expected to use the address leased by the server corresponding to the
server-id?

section 4.3.2

-------------
3 ...Because of this, it could be difficult for the DHCP server to
differentiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND
messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out an IP
and
hence it would know the state of the client based on T1 & T2.

[Pavan] Actually this state is in terms of client's context. A client would
broadcast the dhcp message with client address filled in this state. In case
of failover configurations, a REBIND may imply that one of the primary
server is not responding [since it is broadcast]. However, in L2RA, since
unicast messages are also intercepted and option 82 added, a RENEW may be
misunderstood as REBIND by server. Let us know if it is not clear.
[Ramesh] My understanding is, if unicast messages are intercepted,
               - RENEW will get option 82 added and giaddr not set.
               - REBIND will get option 82 added and giaddr set.
This difference is sufficient for the DHCP Server to distinguish the client
packet.
Did I get something wrong?

-- 
cheers
ramesh

On Sun, Apr 26, 2009 at 7:04 PM, pavan_kurapati
<[email-masked]>wrote:

> [Pavan] Mandating all L2RAs to intercept unicast messages may be too strict
> behavior  given that there are implementations which doesnt do it. I feel
> 'may' is good here.
>
> section 4.1.1
> -------------
> 6. ...
>
> [Pavan] This condition can occur when multiple DHCP servers are configured
> for failover. In such a configuration, there are servers which ignore
> server-id and in certain exceptional conditions may respond to the same IP
> address request with multiple ACKs. In this scenario, L2RA must take the one
> which has more lease time.
>
>
> section 4.3.2
>
> -------------
> [Pavan] Actually this state is in terms of client's context. A client would
> broadcast the dhcp message with client address filled in this state. In case
> of failover configurations, a REBIND may imply that one of the primary
> server is not responding [since it is broadcast]. However, in L2RA, since
> unicast messages are also intercepted and option 82 added, a RENEW may be
> misunderstood as REBIND by server. Let us know if it is not clear.
>
> --
> cheers
> ramesh
>
>
>
>
> On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <[email-masked]
> <mailto:[email-masked]>> wrote:
> Hi All,
>
>      We have published version 04 of Layer 2 Relay Agent Information draft.
> This version addresses several editorial comments provided by Alfred.
>
>      Draft is available at

---

From: pavan_kurapati <[email-masked]>
Date: Tue, 28 Apr 2009 22:02:55 +0530

Hi Ramesh,
Sorry for the delay. Please see replies inline

Thanks,
Pavan
________________________________
From: Ramesh [[email-masked]]
Sent: Sunday, April 26, 2009 9:50 PM
To: pavan_kurapati
Cc: Bharat Joshi; [email-masked]
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft

Pavan,

Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server
_if_ it has inserted option-82. This is because for a client, option-82 do not make any sense.
[Pavan] Mandating all L2RAs to intercept unicast messages may be too strict behavior  given that there are implementations which doesnt do it. I feel 'may' is good here.
[Ramesh] My concern here is, L2RA should intercept all packets from server, as server could do unicast reply for a broadcast request.
As per RFC 3046 information option have to be stripped off by the relay agent which added it,
"

   the client.

"
Also, I think it will be harsh on the client by asking it to accept a DHCP option which a client software does not care at all.
Today, there _can_ be DHCP clients which misbehave(?) when it see an option-82, as RFC 3046 clearly removes client's relationship with option-82.
[Pavan] You are right that ideally L2RAs (or any relay agent) which adds Option 82 must be configured to snoop unicast replies to remove the option 82. That is how most of the L2RAs (DSLAMs for eg) work today. However, as I mentioned, there are some L2RAs which cannot snoop unicast messages. Also, please note that this is a informational draft and not a standards draft, so we cannot mandate anything in this draft.

section 4.2.2

-------------

In any case, Maintaining a state ( and hence filter) even after a client is dead,
mean anomalies.
[Pavan] This condition can occur when multiple DHCP servers are configured for failover. In such a configuration, there are servers which ignore server-id and in certain exceptional conditions may respond to the same IP address request with multiple ACKs. In this scenario, L2RA must take the one which has more lease time.
[Ramesh] I feel we are leaving a security hole here.
Say you have a client which should be leased IP for 10 minutes. One server lease with 10 minutes and another server with 20 minutes of lease interval.
L2RA will assume the client is valid for 20 minutes and tune the filter. Whereas the management box ( eg. BRAS) would think it is valid for 10 minutes.
So it is like allowing an unauthorized client to be active from 10 to 20th time instance. ?
By the way, how is the client expected to behave when it gets two lease. Is it expected to use the address leased by the server corresponding to the server-id?

[Pavan] We feel that all the elements (including BRAS) must take the highest lease time option in this case. Currently, I dont think client has any defined bahavior in this case. BTW, please read the below thread on the origin of this text.
http://www.ietf.org/mail-archive/web/dhcwg/current/msg08427.html

section 4.3.2

-------------

[Pavan] Actually this state is in terms of client's context. A client would broadcast the dhcp message with client address filled in this state. In case of failover configurations, a REBIND may imply that one of the primary server is not responding [since it is broadcast]. However, in L2RA, since unicast messages are also intercepted and option 82 added, a RENEW may be misunderstood as REBIND by server. Let us know if it is not clear.
[Ramesh] My understanding is, if unicast messages are intercepted,
               - RENEW will get option 82 added and giaddr not set.
               - REBIND will get option 82 added and giaddr set.
This difference is sufficient for the DHCP Server to distinguish the client packet.
Did I get something wrong?
[Pavan] There are DHCP servers today which assumes client is in REBIND state if option 82 and client ip address is present. It does not check the 'giaddr' and that was the reason for adding this statement. Let me know if this is still not clear.
--
cheers
ramesh

On Sun, Apr 26, 2009 at 7:04 PM, pavan_kurapati <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ramesh,
Thanks for the review. Please find replies inline

Thannks,
Pavan
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Ramesh [[email-masked]<mailto:[email-masked]>]
Sent: Sunday, April 26, 2009 3:43 PM
To: Bharat Joshi
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft

Bharat,

Section 4.1.1

-------------

Section 4.1.1

-------------

section 4.1.1
-------------
6. ...

section 4.2.2

-------------

section 4.3.2

-------------

--
cheers
ramesh

On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
Hi All,

Thanks,
Bharat
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>