Subject: Re: [netlmm] DHCP relay in draft-ietf-netlmm-pmip6-ipv4-support-02.txt

From: "Sammy Touati" <[email-masked]>
Date: Mon, 19 Nov 2007 20:44:55 -0500

Hi Zu,

Because the MAG is the default gateway for the mobile node, then all
traffic will pass through it. The relay functionality on the MAG will
be able to snoop the DHCP renew message, and trigger a PBU.
The "snooping" can also be avoided by having the DHCP relay in the MAG
put its own IP address in the 'siaddr' field, instead of having the IP
address of the DHCP server, this will let the unicast renew messages
terminate in the relay function of the MAG, who will then forward them
to the IP server.

For this draft the DHCP relay functionality described is different
from the bootp relay functionality described in RFC2131; a
clarification might be needed in the draft to avoid confusion.

Sammy.

Hello,
            I have a question on the DHCP relay function defined at
draft-ietf-netlmm-pmip6-ipv4-support-02.txt
In the draft, it says:
"   o  After the initial procedure described in above, DHCP runs
      independently to the proxy binding registration for renewing the
      assigned IPv4 home address.  It is not necessary to run DHCP
      whenever a mobile node changes its attached mobile access gateway.
      A DHCP client renew the address according to the address lifetime,
      etc.  However, whenever a mobile node renews the IPv4 home address
      by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access
      gateway SHOULD send a proxy binding update to the local mobility
      anchor regardless of the mobile node's assigned address changes."

Based on RFC 2131, no relays are involved in the renew state:
"   o DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission."

So my question is how the MAG updates the bind at the renew state?
        Have a nice day,
__________________________________^_^___
Zu Qiang
Ericsson Canada
 *  Tel.: 1-514-3457900 X-47370
 *  Fax: 1-514-3457982, * ECN: 8104 7370
 *  Mobile: 1-514-5941136
 *  Email: [email-masked]
_________________________________________

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

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

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 20 Nov 2007 11:31:42 +0900

Hi Sammy and Zu,

Agree with Sammy.

We have exchanged email privately with Zu. I attach the mails for your  
information.
thanks
ryuji

Begin forwarded message:

> From: "Zu Qiang" <[email-masked]>
> Date: 2007年11月20日 5:05:45:JST
> To: "Ryuji Wakikawa" <[email-masked]>, "Sri Gundavelli" <[email-masked] 
> >
> Subject: RE: DHCP relay in draft-ietf-netlmm-pmip6-ipv4-support-02.txt
>
> Thanks Sri and Ryuji.
>
> I agree it may not be an issue for some implementation, but not all.  
> This snooping or interception function has to filters all DHCP  
> message at that interface. This does need some processing time. And  
> the only purpose of this function is to sync the MAG with the DHCP  
> server function. Compare with the DHCP server/client solution, it  
> does not save anything.
>
> Anyway, as Ryuji said that this has to be clarified in the  
> specification that the binding update is triggered by the snooping  
> or interception function, not the relay agent. And the new DHCP  
> snooping or interception function should be clear defined in the  
> draft when you update it.
>
>         Have a nice day,
> -----Original Message-----
> From: Ryuji Wakikawa [mailto:[email-masked]]
> Sent: Monday, 19 November, 2007 2:58 PM
> To: Sri Gundavelli
> Cc: Zu Qiang
> Subject: Re: DHCP relay in draft-ietf-netlmm-pmip6-ipv4-support-02.txt
>
> Hi Zu and Sri,
>
> On 2007/11/20, at 4:53, Sri Gundavelli wrote:
>
>> Hi Zu,
>>
>> The MN-AR link is a P2P link and every packet on the
>> link must be processed by the MAG. So, interception
>> is not an issue.
>
> agree here.
>
> we support the scenario of  MAG being DHCP server.
> For the DHCP relay case, we should clarify that MAG intercepts all
> unicated DHCP message...
>
> regards
> ryuji
>
>
>> Sri
>>
>> On Mon, 19 Nov 2007, Zu Qiang wrote:
>>
>>> Thanks again.
>>> The interception function is more like a DHCP snooping function
>>> which may has an impact on the network performance.
>>> Sorry for my typo, I mean MAG instead of S-GW. Do you think the
>>> solution works?
>>>
>>>        Have a nice day,

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 20 Nov 2007 11:38:10 +0900

Hi Sammy and Zu,

Agree with Sammy.

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 20 Nov 2007 15:14:33 +0100

Hi Ryuji, Sammy, Zu,

FWIW, just wanted to add that rfc 3046 explicitely allows DHCP relays to intercept messages sent in unicast to DHCP server. This requires packet inspection at MAG and I also think that this may have significant disadvantages on MAG's performance. On the other hand, it seems that the packet inspection is also required for the case when the DHCP server is colocated with the MAG. After the handover, the new MAG must discard all DHCP messages besides those sent to broadcast address or its own address. So it also needs to look into every packet.

From the draft:
> So, DHCP client in the mobile node
> needs to reconfigure its local configuration parameters.
> Therefore, mobile access gateway SHOULD discard any DHCP request
> message that does not belong to the mobile access gateway itself,
> so that the mobile node should go into the DHCP REBINDING state
> and broadcast DHCP request without server identifier.

Letting the MN go into rebinding state may result in many re-trasnmissions of DHCP_REQUEST. This would wake up the MN frequently from the idle mode. Maybe this interaction with idle mode could be mentioned in the draft so that deployments are aware of different trade-offs when choosing a DHCP mode for their network?.

regards
domagoj

> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: 20. studeni 2007 03:38
> To: Sammy Touati
> Cc: [email-masked]
> Subject: Re: [netlmm] DHCP relay in 
> We have exchanged email privately with Zu. I attach the mails 
> for your information.
> thanks
> ryuji
> 
> Begin forwarded message:
> 
> > Subject: RE: DHCP relay in 
> > This snooping or interception function has to filters all 
> DHCP message 
> > at that interface. This does need some processing time. And 
> the only 
> > purpose of this function is to sync the MAG with the DHCP server 
> > function. Compare with the DHCP server/client solution, it does not 
> > save anything.
> >
> > specification that the binding update is triggered by the 
> snooping or 
> > interception function, not the relay agent. And the new 
> DHCP snooping 
> > or interception function should be clear defined in the 
> draft when you 
> > update it.
> >
> >        Have a nice day,
> > Subject: Re: DHCP relay in 
> >> The MN-AR link is a P2P link and every packet on the link must be 
> >> processed by the MAG. So, interception is not an issue.
> >
> > agree here.
> >

---

From: "Zu Qiang" <[email-masked]>
Date: Tue, 20 Nov 2007 09:39:03 -0500

Thanks Domagoj for your information

In RFC3046, it says: 
"  Relay agents are NOT required to monitor or modify client-originated
   DHCP packets addressed to a server unicast address.  This  includes
   the DHCP-REQUEST sent when entering the RENEWING state."
"  Note that DHCP relay agents are not required to monitor unicast DHCP
   messages sent directly between the client and server (i.e., those
   that aren't sent via a relay agent).  However, some relay agents MAY
   chose to do such monitoring and add relay agent options.
   Consequently, servers SHOULD be prepared to handle relay agent
   options in unicast messages, but MUST NOT expect them to always be
   there."
My understanding is the specification does not request the interception function in relay. However, it does not prevent an implementation to add the DHCP snooping function. But this additional snooping function has to be clarified in the specification as we discussed before. And I agree with as you that this additional function may have a significant disadvantage on MAG's performance.

The rebinding after handover case is another problem that the MN may not have an assigned IP address for a long time. The DHCP snooping function is also needed in this case. This also needs to be clarified in the specification.

        Have a nice day, 

-----Original Message-----
From: Premec, Domagoj [mailto:[email-masked]] 
Sent: Tuesday, 20 November, 2007 9:15 AM
To: RYUJI WAKIKAWA; Sammy Touati; Zu Qiang
Cc: [email-masked]
Subject: RE: [netlmm] DHCP relay in draft-ietf-netlmm-pmip6-ipv4-support-02.txt

Hi Ryuji, Sammy, Zu,

regards
domagoj

---

From: "Sammy Touati" <[email-masked]>
Date: Tue, 20 Nov 2007 10:48:38 -0500

Hi,

The performance issues may be removed by terminating the DHCP message in the
MAG itself instead of just snooping on the message:  if the DHCP relay
function in the MAG position itself as a DHCP server by putting
its own address in the siaddr field, then after an IP address has been
assigned to the mobile, all subsequent unicast DHCP communication will be
terminated in the relay function.
This change of functionality in the relay function can then be specified in
the draft.

Sammy.

On 11/20/07, Premec, Domagoj <[email-masked]> wrote:
>
> Hi Ryuji, Sammy, Zu,
>
> FWIW, just wanted to add that rfc 3046 explicitely allows DHCP relays to
> intercept messages sent in unicast to DHCP server. This requires packet
> inspection at MAG and I also think that this may have significant
> disadvantages on MAG's performance. On the other hand, it seems that the
> packet inspection is also required for the case when the DHCP server is
> colocated with the MAG. After the handover, the new MAG must discard all
> DHCP messages besides those sent to broadcast address or its own address. So
> it also needs to look into every packet.
>
> From the draft:
> Letting the MN go into rebinding state may result in many re-trasnmissions
> of DHCP_REQUEST. This would wake up the MN frequently from the idle mode.
> Maybe this interaction with idle mode could be mentioned in the draft so
> that deployments are aware of different trade-offs when choosing a DHCP mode
> for their network?.
>
> regards
> domagoj
>
>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 20 Nov 2007 16:48:54 +0100

Hi Zu,

> The rebinding after handover case is another problem that the 
> MN may not have an assigned IP address for a long time. The 

hmm... the MN is able to use the assigned address even if it is in rebinding state. Could you be more specific why an MN would not have an IP address?

regards
domagoj

> From: Zu Qiang [mailto:[email-masked]] 
> Sent: 20. studeni 2007 15:39
> To: Premec, Domagoj; RYUJI WAKIKAWA; Sammy Touati
> Cc: [email-masked]
> Subject: RE: [netlmm] DHCP relay in 
> My understanding is the specification does not request the 
> interception function in relay. However, it does not prevent 
> an implementation to add the DHCP snooping function. But this 
> additional snooping function has to be clarified in the 
> specification as we discussed before. And I agree with as you 
> that this additional function may have a significant 
> disadvantage on MAG's performance.
> 
> The rebinding after handover case is another problem that the 
> MN may not have an assigned IP address for a long time. The 
> DHCP snooping function is also needed in this case. This also 
> needs to be clarified in the specification.
> 
>         Have a nice day,
> Zu Qiang _________________________________________ 
> 
> 
> Subject: RE: [netlmm] DHCP relay in 
> FWIW, just wanted to add that rfc 3046 explicitely allows 
> DHCP relays to intercept messages sent in unicast to DHCP 
> server. This requires packet inspection at MAG and I also 
> think that this may have significant disadvantages on MAG's 
> performance. On the other hand, it seems that the packet 
> inspection is also required for the case when the DHCP server 
> is colocated with the MAG. After the handover, the new MAG 
> must discard all DHCP messages besides those sent to 
> broadcast address or its own address. So it also needs to 
> look into every packet.
> 
> From the draft:
> > message that does not belong to the mobile access gateway 
> itself, so 
> > that the mobile node should go into the DHCP REBINDING state and 
> > broadcast DHCP request without server identifier.
> 
> Letting the MN go into rebinding state may result in many 
> re-trasnmissions of DHCP_REQUEST. This would wake up the MN 
> frequently from the idle mode. Maybe this interaction with 
> idle mode could be mentioned in the draft so that deployments 
> are aware of different trade-offs when choosing a DHCP mode 
> for their network?.
> 
> regards
> domagoj
> 
> 
> link must be

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 20 Nov 2007 16:55:08 +0100

Sammy,
 
DHCP server in the MAG has a problem after handover. Draft states that a new MAG must discard all DHCP messages sent by the MN to the old MAG (DHCP server). In order to discard those messages, new MAG must do packet inspection. So packet inspection is needed both for "MAG as DHCP relay" and "MAG as DHCP server" cases.
 
domagoj

________________________________

	From: Sammy Touati [mailto:[email-masked]] 
	Sent: 20. studeni 2007 16:49
	To: Premec, Domagoj
	Cc: RYUJI WAKIKAWA; [email-masked]; [email-masked]
	Subject: Re: [netlmm] DHCP relay in draft-ietf-netlmm-pmip6-ipv4-support-02.txt

	Hi,
	 
	The performance issues may be removed by terminating the DHCP message in the MAG itself instead of just snooping on the message:  if the DHCP relay function in the MAG position itself as a DHCP server by putting
	its own address in the siaddr field, then after an IP address has been assigned to the mobile, all subsequent unicast DHCP communication will be terminated in the relay function.
	This change of functionality in the relay function can then be specified in the draft.
	 
	Sammy.

		Hi Ryuji, Sammy, Zu,

		
		
		regards
		domagoj

		> > From: "Zu Qiang" < [email-masked]>
		> > To: "Ryuji Wakikawa" <[email-masked] >, "Sri Gundavelli"
		> > <[email-masked]
		> > >
		> > From: Ryuji Wakikawa [mailto: [email-masked] <mailto:[email-masked]> ]

---

From: "Zu Qiang" <[email-masked]>
Date: Tue, 20 Nov 2007 11:03:22 -0500

Hi, Domagoj 
I could be wrong. My understanding is at rebinding state, the MN is not supposed to use the IP address for sending any packets. Is there any text in the RFC saying that the MN can use the IP address at rebinding?

        Have a nice day, 

-----Original Message-----
From: Premec, Domagoj [mailto:[email-masked]] 
Sent: Tuesday, 20 November, 2007 10:49 AM
To: Zu Qiang
Cc: [email-masked]; RYUJI WAKIKAWA; Sammy Touati
Subject: RE: [netlmm] DHCP relay in draft-ietf-netlmm-pmip6-ipv4-support-02.txt

Hi Zu,

regards
domagoj

---

From: "Sammy Touati" <[email-masked]>
Date: Tue, 20 Nov 2007 11:04:53 -0500

This is true, I overlooked this part.

On 11/20/07, Premec, Domagoj <[email-masked]> wrote:
>
>  Sammy,
>
> DHCP server in the MAG has a problem after handover. Draft states that a
> new MAG must discard all DHCP messages sent by the MN to the old MAG (DHCP
> server). In order to discard those messages, new MAG must do packet
> inspection. So packet inspection is needed both for "MAG as DHCP relay" and
> "MAG as DHCP server" cases.
>
> domagoj
>
>
>  ------------------------------
> *From:* Sammy Touati [mailto:[email-masked]]
> *Sent:* 20. studeni 2007 16:49
> *To:* Premec, Domagoj
> *Cc:* RYUJI WAKIKAWA; [email-masked]; [email-masked]
> *Subject:* Re: [netlmm] DHCP relay in
> The performance issues may be removed by terminating the DHCP message in
> the MAG itself instead of just snooping on the message:  if the DHCP relay
> > re-trasnmissions of DHCP_REQUEST. This would wake up the MN frequently from
> > the idle mode. Maybe this interaction with idle mode could be mentioned in
> > the draft so that deployments are aware of different trade-offs when
> > choosing a DHCP mode for their network?.
> >
> > regards
> > domagoj
> >
> >
> > > > From: Ryuji Wakikawa [mailto: [email-masked]]

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 20 Nov 2007 17:33:29 +0100

Zu,

MN may use an address assigned via DHCP until its lease time expires, entering the rebinding state does not invalidate the IP address. Rebinding is just a mechanism to find a different DHCP server if the original one does not respond.

domagoj

> Sent: 20. studeni 2007 17:03
> To: Premec, Domagoj
> I could be wrong. My understanding is at rebinding state, the 
> MN is not supposed to use the IP address for sending any 
> packets. Is there any text in the RFC saying that the MN can 
> use the IP address at rebinding?
> 
>         Have a nice day,
> > The rebinding after handover case is another problem that 
> the MN may 
> > not have an assigned IP address for a long time. The
> 
> hmm... the MN is able to use the assigned address even if it 
> is in rebinding state. Could you be more specific why an MN 
> would not have an IP address?
> 
> regards
> domagoj
> 
> 
> > interception function in relay. However, it does not prevent an 
> > implementation to add the DHCP snooping function. But this 
> additional 
> > snooping function has to be clarified in the specification as we 
> > discussed before. And I agree with as you that this additional 
> > function may have a significant disadvantage on MAG's performance.
> > 
> > The rebinding after handover case is another problem that 
> the MN may 
> > not have an assigned IP address for a long time. The DHCP snooping 
> > function is also needed in this case. This also needs to be 
> clarified 
> > in the specification.
> > 
> >         Have a nice day,
> DHCP relays 
> > to intercept messages sent in unicast to DHCP server. This requires 
> > packet inspection at MAG and I also think that this may have 
> > significant disadvantages on MAG's performance. On the 
> other hand, it 
> > seems that the packet inspection is also required for the case when 
> > the DHCP server is colocated with the MAG. After the 
> handover, the new 
> > MAG must discard all DHCP messages besides those sent to broadcast 
> > address or its own address. So it also needs to look into every 
> > packet.
> > 
> > From the draft:
> frequently 
> > from the idle mode. Maybe this interaction with idle mode could be 
> > mentioned in the draft so that deployments are aware of different 
> > trade-offs when choosing a DHCP mode for their network?.
> > 
> > regards
> > domagoj
> > 
> >

---

From: "Zu Qiang" <[email-masked]>
Date: Tue, 20 Nov 2007 16:18:59 -0500

Thanks Domagoj. I think you are right.

After reading the RFC again, I found that the rebinding after handover is not the only case to require the interception function. The RFC says:
" The client unicasts DHCPRELEASE messages to the server. "
"   When the DHCP client knows the address of a DHCP server, in either
   INIT or REBOOTING state, the client may use that address in the
   DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
   The client may also use unicast to send DHCPINFORM messages to a
   known DHCP server.  If the client receives no response to DHCP
   messages sent to the IP address of a known DHCP server, the DHCP
   client reverts to using the IP broadcast address."

The MN may send unicast message at INIT or REBOOT and RELEASE state. All of this unicast messages must be discarded by the MAG, if the server ID is not the MAG itself. Or the unicast messages have to be intercepted by the MAG if it acts as relay.
My conclusion is the DHCP interception function is mandatory at MAG.

        Have a nice day, 

-----Original Message-----
From: Premec, Domagoj [mailto:[email-masked]] 
Sent: Tuesday, 20 November, 2007 11:33 AM
To: Zu Qiang
Cc: [email-masked]; RYUJI WAKIKAWA; Sammy Touati
Subject: RE: [netlmm] DHCP relay in draft-ietf-netlmm-pmip6-ipv4-support-02.txt

Zu,

domagoj

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sun, 25 Nov 2007 03:11:44 +0900

Hi Zu,

thanks for summarizing this.
We will update which DHCP messages MAG (DHCP-S) will discard at the  
handover case.

I don't have good answer to the performance issue.
For any DHCP scenarios, MAG has to check the packets.

regards,
ryuji

On 2007/11/21, at 6:18, Zu Qiang wrote:

> After reading the RFC again, I found that the rebinding after  
> handover is not the only case to require the interception function.  
> The RFC says:
> The MN may send unicast message at INIT or REBOOT and RELEASE state.  
> All of this unicast messages must be discarded by the MAG, if the  
> server ID is not the MAG itself. Or the unicast messages have to be  
> intercepted by the MAG if it acts as relay.
> MN may use an address assigned via DHCP until its lease time  
> expires, entering the rebinding state does not invalidate the IP  
> address. Rebinding is just a mechanism to find a different DHCP  
> server if the original one does not respond.
>
> domagoj
>
>