Subject: [dhcwg] [CORRECTION] draft-ietf-dhc-l2ra-extensions-00

From: John Jason Brzozowski <[email-masked]>
Date: Fri, 03 Oct 2008 17:25:28 -0400

Folks,

This is a correction to the original email below.

The following draft has been accepted as a WG work item.  If you have any
questions or concerns please send feedback to the mailing list.

Feedback from the WG or the team below, if not already forwarded, is
requested.

Thanks,

-Ralph Droms, John Brzozowski
   dhc WG chairs

On 9/18/08 12:22 PM, "John Jason Brzozowski"
<[email-masked]> wrote:

> Folks,
> 
> Before we continue discussions surrounding the above becoming a WG work item
> we determined in Dublin that additional mailing discussion is required.
> 
> Please review the draft and send your comments and question to the WG.
> 
> Additionally, the following folks have also agreed to review the draft:
> 
> * David Miles
> * Ted Lemon
> * Woj dec
> * Ralph Droms
> 
> Once the review is complete and sufficient discussion has occurred on the
> mailing we will revisit next steps for draft-ietf-dhc-l2ra-extensions-00.
> 
> 
> Thanks,
> 
> John

=========================================
John Jason Brzozowski
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
=========================================

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 6 Oct 2008 15:43:12 +0200

Hi Folks,

Here are my review comments for draft-ietf-dhc-l2ra-extensions-00. I
have mainly doubts about the scope of the problem that's being addressed
and concern on whether it is actually suitable as a DHC WG item.

Section 1
----------
It's stated that "This document proposes enhancements in Layer 2 Relay
Agent [7] which
   addresses issues like flooding between Layer 3 Relay Agent and Layer
   2 Relay Agent"

Could the authors describe what is/are the scenario(s) under which such
flooding occurs *between* the Layer 3 and Layer 2 agents? Some form of
problem statement/description would be welcome. Section 3 appears to
contain an brief overview, of these, but mixes them with enhancements.
This actually brings me to comment on Section 3...

Section 3
---------
"Broadcasting DHCP requests on all interfaces

   A normal Layer 2 Relay Agent[7] would broadcast a DHCP request
   message to all its interfaces except..."

This not quite normal behaviour. I don't quite see how this is a problem
*between* the L3 and L2 relay agents, if anything this is a problem for
any ethernet broadcast frame sent "upstream" from the client towards a
L2 access node. If so, then this problem has nothing to do with DHCP,
and is actually covered in say the private vlan concept in 802.1d (also
explained in
http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-10.txt).
As such I do not believe that this is actually a problem to be covered
in a DHC draft, besides the fact that there are other ways in which the
"broadcast issue" can be handled.
BTW I am implicitly assuming that we're talking about ethernet here (are
we? Surely any non broadcast ethernet L2 access node doesn't run into
this issue)

"Layer 3 Relay Agent broadcasting DHCP replies

   Layer 3 Relay Agents generally broadcast DHCP replies towards Layer 2
   Relay Agents. "

I don't quite see why it's stated that L3 relay agents generally
broadcast replies. If anything, my experience points to the contrary, ie
that in SP environments the L3 relay will either explicitly unicast at
L2 replies or have a configurable option to ignore requests with the
broadcast flag set. As such I don't quite see that this is a problem
which requires additional DHC work for a L2 relay. If anything the L3
relay functionality could be described somewhere (it already is
documented in vendor release notes). Also, if the motivation is that
there are hosts that can only interpret broadcast MAC frames before an
IP address is assigned, then something is wrong there.

The remaining problem/extension described in this section is:
"Recovering Lease Information from Server

   A Layer 2 Relay Agent[7] may snoop DHCP messages and maintain the
   lease information.  This information is lost if the Layer 2 Relay
   Agent reboots."

This appears to be a valid problem, but actually has little to do with
broadcasts between the L3 and L2 agents. That said, the method proposed
may have some issues... (more on that in the next section review

Section 5.2.3
-------------
"While generating a DHCP reply for a DHCPLEASEQUERY message, if the
   message type is DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN, it MUST echo
   back the Relay Agent Information received in the DHCPLEASEQUERY
   message.  If the message type is DHCPLEASEACTIVE, DHCP server
   prepares the message as described in RFC 4388 and ignores the Relay
   Agent Information option received in the DHCPLEASEQUERY message."

If I interpret this correctly the server will:
- send a response message to the L3 relay with the L2 relay agent option
(opt82) with For LeaseQueries that have no valid/active lease
- send a response message to the L3 relay without the L2 relay agent
option (opt82) with For LeaseQueries that have a valid lease
This leads me to conclude that in the latter case an L2 relay
(eventually receiving the reply) will be unable not correlate it to a
given port. If the assumption is that the server needs to insert in the
reply *another* (a cached) relay agent info option, then it raises very
much the possibility that the L2 relay receiving it was not actually the
one that generated it (and should probably ignore the response). In
either case I do not see how the L2 relay can then use the message for
anything useful. In fact this appears could well lead to an undesirable
aspect: If a client with a valid lease moves in the same domain to
another L2 agent in the same domain he/she will be Denied the service
until the lease expires (as per section 5.2.1) - assuming that the
"query" feature use is coupled with security. 
Now, in the former case, i.e. when the L2 relay receives a reply
(DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN), then even though it can
correlate it to a given port, I see no benefit in it doing so; it had no
state to begin with, and now it has no valid state to go on either.
What's the point in all this? 

Section 5.2.5.1 
---------------
"When a DHCPLEASEUNASSIGNED message is received by a Layer 2 Relay
   Agent, it means that there is no active lease for the IP address
   present in the DHCP server, but that a server does in fact manage
   that IP address.  Layer 2 Relay Agent SHOULD cache this information
   for later use."

What later use? Why is caching this info useful? (Note: A similar
question may be brought forward to rfc4388, but that's bygone now...
Let's talk about why is it useful to have this caching on a L2 relay)

Section 6.
----------
"Even though the DHCP clients are not setting the broadcast flag, it
   is still possible that the DHCPOFFER and DHCPACK messages from the
   DHCP server are sent to all access concentrators.  This is when the
   access concentrator implements a MAC concentration or MAC translation
   function. "

This sanctions the use of L2 MAC NAT which I do not think that the IETF
should get involved in... It also appears that this may be the source of
the real problem which could cause a L3 agent reply sent to a perfectly
valid client unicast mac address to be flooded in an L2 domain. If in
the upstream direction, MACs are NATed but the L3 relay replies to the
client MAC address then that frame will get flooded. It's a problem with
MAC NATing, not DHCP IMO. Actually, it's testament to why the MAC NATIng
is flawed; the L2 MAC NAT device needs a DHCP NAT function too,
translating the client mac address field (and likely breaking rfc3118).

I'd welcome a discussing/resolution of the above before continuing with
the review of some of the other details.

Regards,
Woj.

> -----Original Message-----
> From: John Jason Brzozowski 
> [mailto:[email-masked]] 
> Sent: 03 October 2008 23:25
> To: dhc WG
> Cc: Ted Lemon; David Miles; Ralph Droms (rdroms); Wojciech 
> Dec (wdec); dhc Chairs
> Subject: [CORRECTION] draft-ietf-dhc-l2ra-extensions-00
> 
> Folks,
> 
> The following draft has been accepted as a WG work item.  If 
> you have any questions or concerns please send feedback to 
> the mailing list.
> 
> Feedback from the WG or the team below, if not already 
> forwarded, is requested.
> 
> Thanks,
> 
> > Before we continue discussions surrounding the above becoming a WG 
> > work item we determined in Dublin that additional mailing 
> discussion is required.
> > 
> > Once the review is complete and sufficient discussion has 
> occurred on 
> > the mailing we will revisit next steps for 
> draft-ietf-dhc-l2ra-extensions-00.
> > 
> > 
> > Thanks,
> > 
> > John
>

---

From: pavan_kurapati <[email-masked]>
Date: Tue, 14 Oct 2008 19:37:17 +0530

Hi Woj,

Thanks for the detailed review. Please find my comments inline with <Pavan> tag. Please note that this draft  not only solves broadcast issues. It is intended for all extensions possible for L2RA (including leasequery extensions)

Thanks,
Pavan Kurapati

From: [email-masked] [[email-masked]] On Behalf Of Wojciech Dec (wdec) [[email-masked]]
Sent: Monday, October 06, 2008 7:13 PM
To: [email-masked]
Cc: dhc Chairs; Ted Lemon; Ralph Droms (rdroms)
Subject: [dhcwg] Comments -  draft-ietf-dhc-l2ra-extensions-00
 Hi Folks,
Here are my review comments for draft-ietf-dhc-l2ra-extensions-00. I
have mainly doubts about the scope of the problem that's being addressed
and concern on whether it is actually suitable as a DHC WG item.
Section 1
----------
It's stated that "This document proposes enhancements in Layer 2 Relay
Agent [7] which
   addresses issues like flooding between Layer 3 Relay Agent and Layer
   2 Relay Agent"
Could the authors describe what is/are the scenario(s) under which such
flooding occurs *between* the Layer 3 and Layer 2 agents? Some form of
problem statement/description would be welcome. Section 3 appears to
contain an brief overview, of these, but mixes them with enhancements.

<Pavan> DHCP messages can be flooded between L3 and L2 RAs if "broadcast" flag is set or when MAC translation is used. DHCPLEASEQUERY initiated by L2RA and the reply will be broadcast between L3RA and L2RA. We will add problem statement/description in the beginning of the draft if it helps in avoiding any confusion
</Pavan>

<Pavan> Yes. We are talking about Ethernet L2 access node. For a normal Layer 2 device, DHCP message will be treated similar to any other broadcast message and that is why it may be broadcasting it on all interface as it would have done for other broadcast messages without any extension [Uplink port/Lan router port]. For control messages like DHCP/PPPoX, it is important that these are sent only on uplink port and not flooded on all access ports which is not a common behavior of a normal Etherent switch. That is what is the intention here. Do you think this intention is not clearly visible here?
</Pavan>

<Pavan> I dont think it is correct to assume that all L3 relays unicast the replies towards L2. There are potentially 2 issues here. One is for L3RA to identify the right outgoing interface (since option 82 is added by L2RA) and then identifying the correct L2RA. If there is any mechanism by which L3RA correctly idenfifies the MAC of L2 relay by looking at the reply from the DHCP server, it is not standardised or documented and may be propreitory (i.e say, if it uses 'chaddr' to get the MAC address of the client). On the other hand, identifying the correct interface on L3RA itself is a problem currently, which we tried to address in another draft (relay chaining) which is out of scope here. The mechanism we are suggesting needs some changes in both L2 and L3 RAs.
</Pavan>

<Pavan>
We are not covering only broadcast issues in this draft. This draft handles extensions to L2RA wherever required. Currently leasequery mechanism is not supported for L2RA and we are proposing the same here.
</Pavan>

Section 5.2.3
-------------

<Pavan> Sorry for the confusion but this was a stale paragraph that remained from previous versions. We were supposed to delete this whole thing as there is no change in DHCP server behavior. To clarify a bit more, in our earlier versions we proposed that L3RA should add option 82 to leasequery message so that it can find out the outgoing interface in case of non LEASEACTIVE reply. In case of LEASEACTIVE, it will anyway have the IP address status to rely on finding the outgoing interface. So, to summarise, DHCP server was supposed to use option 82 present in leasequery for replies of inactive/unknown lease and should use option 82 stored in the database for lease active message. We dropped this idea in the latest draft after our internal discussions, as we thought we should not be handling issues of L3RA in this draft.
</Pavan>

<Pavan> Please see the above reply. </Pavan>

Section 5.2.5.1
---------------

<Pavan> Yes, caching is not good but we tried to keep the same behavior as 4388. If required, we can change this statement
</Pavan>

Section 6.
----------

<Pavan> Yes, it is with the case of L2 MAC NAT. We tried to address this case also with DHCP as these implementations do exist hence we were addressing the same in our draft. If everyone feels that we should not be handling L2MAC NAT then we will remove it.
</Pavan>

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

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 15 Oct 2008 19:00:00 +0200

Hi Pavan,

Continued inline... Woj> 

> From: pavan_kurapati [mailto:[email-masked]] 
> Sent: 14 October 2008 16:07
> To: Wojciech Dec (wdec); [email-masked]
> Subject: RE: Comments - draft-ietf-dhc-l2ra-extensions-00
> 
> Hi Woj,
> 
> Thanks for the detailed review. Please find my comments 
> inline with <Pavan> tag. Please note that this draft  not 
> only solves broadcast issues. It is intended for all 
> extensions possible for L2RA (including leasequery extensions)
> 
> Thanks,
> Pavan Kurapati
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Wojciech Dec (wdec) [[email-masked]]
> Subject: [dhcwg] Comments -  
> draft-ietf-dhc-l2ra-extensions-00  Hi Folks, Here are my 
> review comments for draft-ietf-dhc-l2ra-extensions-00. I have 
> mainly doubts about the scope of the problem that's being 
> addressed and concern on whether it is actually suitable as a 
> DHC WG item.
> Section 1
> ----------
> It's stated that "This document proposes enhancements in 
> Layer 2 Relay Agent [7] which
> Could the authors describe what is/are the scenario(s) under 
> which such flooding occurs *between* the Layer 3 and Layer 2 
> agents? Some form of problem statement/description would be 
> welcome. Section 3 appears to contain an brief overview, of 
> these, but mixes them with enhancements.
> 
> <Pavan> DHCP messages can be flooded between L3 and L2 RAs if 
> "broadcast" flag is set or when MAC translation is used. 
> DHCPLEASEQUERY initiated by L2RA and the reply will be 
> broadcast between L3RA and L2RA. We will add problem 
> statement/description in the beginning of the draft if it 
> helps in avoiding any confusion </Pavan>

Woj> MAC translation is equal to MAC NATing, and firstly I would like to
understand why the community think that this is a reasonable thing to
do. As with IP NAT, MAC NAT is a slippery slope, and one that breaks
other aspects of ethernet (eg 802.1xrev). Secondly if agreed to as
reasnable I would like to understand why does the access-node that
engages in MAC NATing not implement a DHCP ALG to do the MAC NAT in the
payload, instead of going after protocol extensions to handle the
resulting problems? 

> *between* the L3 and L2 relay agents, if anything this is a 
> problem for any ethernet broadcast frame sent "upstream" from 
> the client towards a
> L2 access node. If so, then this problem has nothing to do 
> with DHCP, and is actually covered in say the private vlan 
> concept in 802.1d (also explained in 
> As such I do not believe that this is actually a problem to 
> be covered in a DHC draft, besides the fact that there are 
> other ways in which the "broadcast issue" can be handled.
> BTW I am implicitly assuming that we're talking about 
> ethernet here (are we? Surely any non broadcast ethernet L2 
> access node doesn't run into this issue)
> 
> <Pavan> Yes. We are talking about Ethernet L2 access node. 
> For a normal Layer 2 device, DHCP message will be treated 
> similar to any other broadcast message and that is why it may 
> be broadcasting it on all interface as it would have done for 
> other broadcast messages without any extension [Uplink 
> port/Lan router port]. For control messages like DHCP/PPPoX, 
> it is important that these are sent only on uplink port and 
> not flooded on all access ports which is not a common 
> behavior of a normal Etherent switch. That is what is the 
> intention here. Do you think this intention is not clearly 
> visible here?
> </Pavan>

Woj> Perhaps I didn't explain myself clearly: When a client broadcasts
an ethernet frame (any ethernet frame) and for whatever reason one
doesn't want that frame to be received by other clients then there are
standard means of isolating users at layer 2, without requiring dhcp
extensions/features. The draft above talks about that.

> I don't quite see why it's stated that L3 relay agents 
> generally broadcast replies. If anything, my experience 
> points to the contrary, ie that in SP environments the L3 
> relay will either explicitly unicast at
> L2 replies or have a configurable option to ignore requests 
> with the broadcast flag set. As such I don't quite see that 
> this is a problem which requires additional DHC work for a L2 
> relay. If anything the L3 relay functionality could be 
> described somewhere (it already is documented in vendor 
> release notes). Also, if the motivation is that there are 
> hosts that can only interpret broadcast MAC frames before an 
> <Pavan> I dont think it is correct to assume that all L3 
> relays unicast the replies towards L2. There are potentially 
> 2 issues here. One is for L3RA to identify the right outgoing 
> interface (since option 82 is added by L2RA) and then 
> identifying the correct L2RA. If there is any mechanism by 
> which L3RA correctly idenfifies the MAC of L2 relay by 
> looking at the reply from the DHCP server, it is not 
> standardised or documented and may be propreitory (i.e say, 
> if it uses 'chaddr' to get the MAC address of the client). On 
> the other hand, identifying the correct interface on L3RA 
> itself is a problem currently, which we tried to address in 
> another draft (relay chaining) which is out of scope here. 
> The mechanism we are suggesting needs some changes in both L2 
> and L3 RAs.
> </Pavan>

Woj> You may want to take note of the fact that such unicast replies are
the norm in already deployed broadband networks, and explicit features
exist to disable broadcasting back. Unless we conclude that there are
cases when broadcast replies from a server/relay are an absolute must,
then I'd say that there is no problem to solve here.
> This appears to be a valid problem, but actually has little 
> to do with broadcasts between the L3 and L2 agents. That 
> said, the method proposed may have some issues... (more on 
> that in the next section review
> 
> <Pavan>
> We are not covering only broadcast issues in this draft. This 
> draft handles extensions to L2RA wherever required. Currently 
> leasequery mechanism is not supported for L2RA and we are 
> proposing the same here.
> </Pavan>

Woj> IMO the L2RA leasequery is the only possibly interesting thing
here, if/when we're able to actually determine that such a leasequery is
beneficial (doubts below)

> - send a response message to the L3 relay without the L2 
> relay agent option (opt82) with For LeaseQueries that have a 
> valid lease
> 
> <Pavan> Sorry for the confusion but this was a stale 
> paragraph that remained from previous versions. We were 
> supposed to delete this whole thing as there is no change in 
> DHCP server behavior. To clarify a bit more, in our earlier 
> versions we proposed that L3RA should add option 82 to 
> leasequery message so that it can find out the outgoing 
> interface in case of non LEASEACTIVE reply. In case of 
> LEASEACTIVE, it will anyway have the IP address status to 
> rely on finding the outgoing interface. So, to summarise, 
> DHCP server was supposed to use option 82 present in 
> leasequery for replies of inactive/unknown lease and should 
> use option 82 stored in the database for lease active 
> message. We dropped this idea in the latest draft after our 
> internal discussions, as we thought we should not be handling 
> issues of L3RA in this draft.
> </Pavan>

Woj> Ok, now I'm even more confused. What will the server include in
it's leasequery reply to get the message back to the L2RA that generated
the query? I thought that the Opt82 inserted by the L2RA (not the L3RA)
was the way of accomplishing that.

> (eventually receiving the reply) will be unable not correlate 
> it to a given port. If the assumption is that the server 
> needs to insert in the reply *another* (a cached) relay agent 
> info option, then it raises very much the possibility that 
> the L2 relay receiving it was not actually the one that 
> generated it (and should probably ignore the response). In 
> either case I do not see how the L2 relay can then use the 
> message for anything useful. In fact this appears could well 
> lead to an undesirable
> aspect: If a client with a valid lease moves in the same 
> domain to another L2 agent in the same domain he/she will be 
> Denied the service until the lease expires (as per section 
> 5.2.1) - assuming that the "query" feature use is coupled 
> with security.
> Now, in the former case, i.e. when the L2 relay receives a 
> reply (DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN), then even 
> though it can correlate it to a given port, I see no benefit 
> in it doing so; it had no state to begin with, and now it has 
> no valid state to go on either.

Woj> Let's keep the comment in the queue pending clarification on how
the server sends back query replies to the L2RA

> What later use? Why is caching this info useful? (Note: A 
> similar question may be brought forward to rfc4388, but 
> that's bygone now...
> <Pavan> Yes, caching is not good but we tried to keep the 
> same behavior as 4388. If required, we can change this 
> statement </Pavan>

Woj> Unless we have a good reason for it to cache, I'd say it should go.

> This sanctions the use of L2 MAC NAT which I do not think 
> that the IETF should get involved in... It also appears that 
> this may be the source of the real problem which could cause 
> a L3 agent reply sent to a perfectly valid client unicast mac 
> address to be flooded in an L2 domain. If in the upstream 
> direction, MACs are NATed but the L3 relay replies to the 
> client MAC address then that frame will get flooded. It's a 
> problem with MAC NATing, not DHCP IMO. Actually, it's 
> testament to why the MAC NATIng is flawed; the L2 MAC NAT 
> device needs a DHCP NAT function too, translating the client 
> mac address field (and likely breaking rfc3118).
> 
> <Pavan> Yes, it is with the case of L2 MAC NAT. We tried to 
> address this case also with DHCP as these implementations do 
> exist hence we were addressing the same in our draft. If 
> everyone feels that we should not be handling L2MAC NAT then 
> we will remove it.
> </Pavan>

Woj> I subscribe to the "no MAC NAT" list :-)

Cheers,
Woj.
> 
> I'd welcome a discussing/resolution of the above before 
> continuing with the review of some of the other details.
> Regards,
> Woj.
> 
> 
> Dec (wdec); 
> > dhc Chairs
> > The following draft has been accepted as a WG work item.  
> If you have 
> > any questions or concerns please send feedback to the mailing list.
> >
> forwarded, is 
> **************** 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.

---

From: pavan_kurapati <[email-masked]>
Date: Fri, 17 Oct 2008 21:42:31 +0530

Hi Woj,

Replies inline. We agree to remove L2MAC NAT portion if it complicates things. So, I am removing the comments related to that to save some text

Thanks,
Pavan

________________________________________
From: Wojciech Dec (wdec) [[email-masked]]
Sent: Wednesday, October 15, 2008 10:30 PM
To: pavan_kurapati; [email-masked]
Cc: dhc Chairs; Ted Lemon; Ralph Droms (rdroms)
Subject: RE: Comments -  draft-ietf-dhc-l2ra-extensions-00

Hi Pavan,

Continued inline... Woj>

Pavan> OK. Just to make it clear, we are not proposing any extensions in DHCP to prevent upstream flooding. We are handling prevention of flooding through DHCP only in downstream direction. For upstream flooding prevention, we've just suggested usage of uplonk port in Access concentrator as a recommendation which does not change anything to DHCP protocol. Do you want us to remove this reference as well?

Pavan> This problem can be solved in 2 ways. 1) Obsolte the broadcast flag 2) Use unicast option
To do option 1 we have to formally obsolte the same. Option 2 is a cleaner solution for RA to pick up the address given in the option and unicast it back. Either way, it has to come through a draft and get WG approval. Ignoring broadcast flag otherwise is not DHCP standard compliant.

Pavan> L2RA would generate leasequery with relay-agent-hw-address option added. L3RA would populate 'giaddr' to leasequery message similar to other DHCP messages. (Please note that L2RA would not populate 'giaddr' in leasequery even though RFC 4388 mandates populating the same for leasequery generator. This is clearly mentioned in section 5.2.1). Server would unicast the reply to L3RA just like a regular DHCP reply message and adds back 'relay-agent-hw-address' option that came in leasequery. L3RA would use relay-agent-hw-address option to unicast it to L2RA's MAC address.

There is no option 82 added to leasequery message either by L2RA or L3RA. Only LEASEASSIGNED will have option 82 which the server had stored for that lease. This is inline with RFC 4388.

Pavan> OK

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 17 Oct 2008 12:14:26 -0700

> Pavan> This problem can be solved in 2 ways. 1) Obsolte the broadcast flag 2) Use unicast option

Maybe I am confused; the unicast option is a DHCPv6 feature, the
broadcast flag is a DHCPv4 (bootp header) feature?

> To do option 1 we have to formally obsolte the same. Option 2 is a cleaner solution for RA to pick up the address given in the option and unicast it back. Either way, it has to come through a draft…

Presuming DHCPv4 contextually; DHCPv4 agents may, at their ability,
unicast or broadcast.  The only thing that is certain is that if the
broadcast flag is set, they MUST broadcast.  With the broadcast flag
cleared (indicating desire to unicast), they may still broadcast if
they cannot unicast-without-arp (for example).

Modern day networks realistically have software support for unicast.
It is very rare to find instances where broadcast replies are
actually used, excepting of course now that Vista sets the broadcast
flag.  Even where DHCP server software is running on 'odd' server
hardware (lacking sufficient raw packet support), a modern relay agent
can be used to bridge the gap.

So this is a condition that I think "IETF DHCP Extensions" must
formally support, even if it hopefully has very little, if any,
actual use.  Replies may be broadcast to the L2RA no matter what
we do.

An area where L2RA can and should extend this featureset is in a
missing indication between the DHCP Agent and the L2RA.

The broadcast flag properly indicates the client's needs, meaning
between the L2RA and the client.  The DHCPv4 protocol is missing a
field that hints at the path between the server-side DHCP agent and
L2RA.

This could be solved with a relay agent information option scoped
broadcast-request flag (perhaps extending the 'flags' option).

The DHCP agent would use the relay agent information flags option
contents to deliver the packet to the L2RA, which would use the
bootp header flag to deliver to the client (limiting the broadcast
to their specific port).

> Woj> Unless we have a good reason for it to cache, I'd say it should go.

Now that I consider it, I think there is a lease-time associated with
active assignments, and no expiration time associated with inactive
assignments.  To these ends, caching negative replies is probably
actively harmful; it could be assigned at any moment, including the
next nanosecond.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 21 Oct 2008 14:43:09 +0530

David,

   Please see my response in line.

Regards,
Bharat

> broadcast flag is a DHCPv4 (bootp header) feature?

Pavan meant the unicast hardware sub-option we have proposed in layer 2 Relay Agent extension draft.

> > To do option 1 we have to formally obsolte the same. Option 2 is a
> cleaner solution for RA to pick up the address given in the option and
> unicast it back. Either way, it has to come through a draft and get WG
> approval. Ignoring broadcast flag otherwise is not DHCP standard
> compliant.
>
>

Ok.

> bootp header flag to deliver to the client (limiting the broadcast

This is a very good idea. Let me rephrase it and let me know if my understanding of what you are proposing is correct.

L2 RA sets a flag [other than the broadcast flag] if it wants the reply to be unicast to him. DHCP server [if there is no layer 3 relay agent] or Layer 3 Relay Agent always looks at this flag and if the flag is clear, it unicast the message to the L2 RA. L2 RA looks at the broadcast flag and broadcast/unicast DHCP reply accordingly. This looks good.

One question remains. Is it enough if L3 RA [or DHCP server if L3 RA is not there] unicast the DHCP reply to hardware address available from the DHCP message's chadd field? Or we need some mechanism where L2 RA tells L3 RA [or DHCP server] as to what hardware address to use to unicast a DHCP reply message to him?

> actively harmful; it could be assigned at any moment, including the

Yes. We completely agree. This was one of the reasons why we removed it from 'query-by-remote-id' draft. We will remove it from this draft as well.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 21 Oct 2008 08:42:35 -0700

> Pavan meant the unicast hardware sub-option we have proposed in layer 2 Relay Agent extension draft.

Ah, I am confused, it has been awhile since I have reviewed the draft.
High time probably.

You have my permission to apply the appropriate filter to my comments.

> L2 RA sets a flag [other than the broadcast flag] if it wants the reply to be unicast to him. DHCP server [if there is no layer 3 relay agent] or Layer 3 Relay Agent always looks at this flag and i…

We may fidget on whether the flag would be set for unicast or set for
broadcast (the question is if any l2ra's exist today which will not
know or set the flag, and what default they can reasonably expect to
work), but yes that's the general idea.

> One question remains. Is it enough if L3 RA [or DHCP server if L3 RA is not there] unicast the DHCP reply to hardware address available from the DHCP message's chadd field? Or we need some mechanis…

I am probably agnostic on this point as I am not an L2 relay
implementer.

If the L3 agent transmits to the client's L2 address by unicast, it
presumes the client's L2 address is in the forwarding database and
that the database points to the relevant L2 relay agent (which will
recognize the relay agent information option contents as their own).
This is most likely a safe presumption since "standard" L2 networks
generally are not multi path; spanning tree or similar techniques
remove loops and hold them inactive until the primary path fails.  So
the only path to the client includes the relay agent by definition,
even if the packet is flooded (when the client's chaddr is not in the
forwarding table).

Because there are some modern standard movements that are attempting
to create L2 multipath forwarding (TRILL WG) with more similarity to
routed networks (OSPF-like qualities), and many nonstandard methods to
implement the same exist and are used today, it may be useful to
direct the unicast to the L2 device itself, to ensure the packet finds
the original relay agent and does not find an alternate path that
avoids the relay agent entirely.

I would expect L2 implementers have a stronger and more reliable
opinion than my own, and would defer to their judgement.

As a L3 relay agent implementer (albeit a not widely used/deployed
one), I'd be willing to observe a "directed unicast over-ride" relay
agent information option.  It would not be difficult to implement,
but it would take some time to deploy.

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 23 Oct 2008 09:40:08 +0530

David,

     Thanks a lot for your feedback. Please see my replies in line.

Thanks,
Bharat

> You have my permission to apply the appropriate filter to my comments.

Not a problem.

> > This is a very good idea. Let me rephrase it and let me know if my
> understanding of what you are proposing is correct.
> >
> > L2 RA sets a flag [other than the broadcast flag] if it wants the
> reply to be unicast to him. DHCP server [if there is no layer 3 relay
> agent] or Layer 3 Relay Agent always looks at this flag and if the flag
> is clear, it unicast the message to the L2 RA. L2 RA looks at the
> broadcast flag and broadcast/unicast DHCP reply accordingly. This looks
> good.
>

We have been internally discussing and have been thimking that have a sun-option may be more generic and helpful. It may take care of cases where Client's MAC address is not known.

> > One question remains. Is it enough if L3 RA [or DHCP server if L3 RA
> is not there] unicast the DHCP reply to hardware address available from
> the DHCP message's chadd field? Or we need some mechanism where L2 RA
> tells L3 RA [or DHCP server] as to what hardware address to use to
> unicast a DHCP reply message to him?
>

Yes. You are right. That is exactly what we have thought.

> avoids the relay agent entirely.

Apart from this, as mentioned above, that the client's MAC address may be all zeros. [We found a case where a client may set the chaddr to all 0s]

Does DHCP server allocates an IP address to such a request?

> but it would take some time to deploy.

Ok. So this is what has been proposed in Layer 2 Relay Agent extension draft that L3 RA parse the sub-option and unicast the reply back to the hardware address.

---

From: pavan_kurapati <[email-masked]>
Date: Thu, 23 Oct 2008 14:08:18 +0530

Hi David,
Just to elaborate on Bharat's point, having a sub-option instead of a flag will address some scenarios where MAC address to be unicasted is not known from the DHCP header. Consider an example where CPE is operating in IPoA (IP over AAL5) encapsulation and not doing bridging.
                      IPoA
PC----CPE----------L2RA-----L3RA------Server

In this mode, there wont be any ethernet header between CPE and L2RA hence CPE does not populate 'chaddr'. L2RA will populate the ethernet header and hence the Layer 2 network between the relay agents will only learn the MAC address of L2RA. Hence having a sub-option here will solve all the cases where there is a chance of flooding between L3 and L2 Relay agents

Thanks,
Pavan

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bharat Joshi [[email-masked]]
Sent: Thursday, October 23, 2008 9:40 AM
To: David W. Hankins; DHC WG
Subject: Re: [dhcwg] Comments -  draft-ietf-dhc-l2ra-extensions-00

David,

Thanks,
Bharat

Not a problem.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Oct 2008 09:00:18 -0700

> Apart from this, as mentioned above, that the client's MAC address may be all zeros. [We found a case where a client may set the chaddr to all 0s]

Not a DHCPINFORM by chance, was it?

> Does DHCP server allocates an IP address to such a request?

Well, in theory it's not supposed to happen, and there seem to be
some RFC's floating around for doing DHCP over specific kinds of
physical networks which have no MAC address (or an address that is
too long to fit in the chaddr field).

I think a server could properly allocate an address to a chaddrless
client if a client-identifier had been sent.

But depending on the kind of network they're attached to, this
breaks things like relay forwarding by unicast, so it would be a
pretty weird, crafted situation.

> Ok. So this is what has been proposed in Layer 2 Relay Agent extension draft that L3 RA parse the sub-option and unicast the reply back to the hardware address.

That's a fine plan, with the only proviso being you can't count on
support for the new option; so you still have to be prepared to
receive packets "the old way" until compatible relays deploy.