Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

From: "Sangjin Jeong" <[email-masked]>
Date: Wed, 9 May 2007 18:20:29 +0900

Hi Ryuji,

Thanks for developing IPv4 support document.

There is a concern when MAG performs DHCP server functionality.
Actually, it was raised during initial version discussion, 
so I bring it back.

According to the v4 support document, the following procedures 
will be performed when LMA assigns IPv4 HoA.
 
 MN      MAG      LMA
  |------>|        |    1. DHCP discovery
  |       |------->|    2. Proxy Binding Update
  |       |<-------|    3. Proxy Binding Ack (IPv4HoA)
  |       |========|    4. Tunnel/Route Setup*
  |<------|        |    5. DHCP offer (IPv4 HoA)
  |------>|        |    6. DHCP request (IPv4 HoA)
  |<------|        |    7. DHCP acknowledgement
  |       |        |
* Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)
  are processed in parallel.

In Step 5, DHCP offer will include server-id in the message and 
DHCP clients will use the IP address provided in the server-id 
for any unicast requests to the DHCP server.

Since LMA assigns MN's home network address and there is no DHCP 
server, MAG should use its IP address as the server-id so that 
MAG can respond MN's DHCP messages. 

MAG may use LMA address as the server-id. However, if MAG 
informs MN of LMA address as a server address, MN will send DHCP 
messages to LMA address and MAG will have to intercept them. 
IMHO, it is not a natural way for MAG to intercept/respond DHCP 
unicast messages whose destination address is not itself.
Additionally, since MAG performs DHCP server-side function, 
specifying MAG's address in DHCP message seems to be more 
reasonable.

IMHO, it is necessary to add following requirement in Step 5. 
"MAG uses its IP address as the server identifier in DHCP offer"

Also, if MAG's address is used as the server-id, there is another 
issue related to MN's handover. 

Refer to the following figure, please. 
Let's assume a MN moved from old MAG (oMAG) to new MAG (nMAG)

MN     oMAG    nMAG      LMA
 |-------|------>|        |    1. MN attachment
 |       |       |------->|    2. Proxy Binding Update
 |       |       |<-------|    3. Proxy Binding Ack (IPv4HoA)
 |       |       |========|    4. Tunnel Setup
 .       .       .        .
 |------>|       |        |    5. DHCP request (renew)
 |       |       |        |

Since the MN does not know the link change, the DHCP client in 
the MN will unicast DHCP request (renew) to the server IP address 
which was acquired by oMAG (server-id). This might be undesirable 
behavior because oMAG maintains state for the MN that is not in the 
access link anymore. Thus, DHCP client in the MN needs to 
reconfigure its local configuration parameters. One simple solution 
would be to force the DHCP client to renew its state by sending 
DHCP FORCERENEW message as follows. 

MN     oMAG    nMAG      LMA
 |-------|------>|        |    1. MN attachment
 |       |       |------->|    2. Proxy Binding Update
 |       |       |<-------|    3. Proxy Binding Ack (IPv4HoA)
 |       |       |========|    4. Tunnel Setup
 |<------|-------|        |    5. DHCP FORCERENEW*
 |       |       |        |

* nMAG sends DHCP FORCERENEW to MN.

Regards,
Sangjin

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 27, 2007 4:50 AM
Subject: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt 

>A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF.
> 
> Title : IPv4 Support for Proxy Mobile IPv6
> Author(s) : R. Wakikawa, S. Gundavelli
> Filename : draft-ietf-netlmm-pmip6-ipv4-support-00.txt
> Pages : 25
> Date : 2007-4-26
> 
>   This document specifies extensions to the Proxy Mobile IPv6 protocol
>   [ID-PMIP6] for supporting IPv4.  The scope of the IPv4 support in
>   Proxy Mobile IPv6 includes the support for the mobile node's IPv4
>   home address mobility and for supporting the scenario where the local
>   mobility anchor and the mobile access gateway are separated by an
>   IPv4 transport network.  The solution primarily leverages the
>   extensions defined in Dual Stack Mobile IPv6 specification [ID-
>   DSMIP6] for achieving this.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-ietf-netlmm-pmip6-ipv4-support-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-00.txt".
> 
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

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

> _______________________________________________
> 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: "Premec, Domagoj" <[email-masked]>
Date: Thu, 10 May 2007 10:33:34 +0200

Hi Sangjin,

> Since LMA assigns MN's home network address and there is no 
> DHCP server, MAG should use its IP address as the server-id 
> so that MAG can respond MN's DHCP messages. 
> 
> informs MN of LMA address as a server address, MN will send 
> DHCP messages to LMA address and MAG will have to intercept them. 
> IMHO, it is not a natural way for MAG to intercept/respond 
> DHCP unicast messages whose destination address is not itself.
> specifying MAG's address in DHCP message seems to be more reasonable.

We could also let the MAG act as a DHCP relay and the LMA as DHCP server. Then it would be the LMA's address in the server-id option. In other words, DHCP messaging from the first figure in your mail would be extended all the way to the LMA. This approach has no issues with handover.

> Also, if MAG's address is used as the server-id, there is 
> another issue related to MN's handover. 

Another solution could be to let the client go into rebinding state. Then the client would broadcast the DHCP-REQ which would contain the client's current IP address and would not contain the server-id option. The new MAG would respond with DHCP-ACK extending the lease time of the currently assigned IP address. And the response would contain the address of the new MAG in the server-id option.

regards
domagoj

> -----Original Message-----
> From: Sangjin Jeong [mailto:[email-masked]] 
> Sent: 09. svibanj 2007 11:20
> To: Ryuji Wakikawa
> Cc: [email-masked]
> Subject: Re: [netlmm] I-D 
> ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt 
> 
> Hi Ryuji,
> 
> Actually, it was raised during initial version discussion, so 
> I bring it back.
> 
> According to the v4 support document, the following 
> procedures will be performed when LMA assigns IPv4 HoA.
>  
>  MN      MAG      LMA
> In Step 5, DHCP offer will include server-id in the message 
> and DHCP clients will use the IP address provided in the 
> server-id for any unicast requests to the DHCP server.
> 
> Since LMA assigns MN's home network address and there is no 
> DHCP server, MAG should use its IP address as the server-id 
> so that MAG can respond MN's DHCP messages. 
> 
> informs MN of LMA address as a server address, MN will send 
> DHCP messages to LMA address and MAG will have to intercept them. 
> IMHO, it is not a natural way for MAG to intercept/respond 
> DHCP unicast messages whose destination address is not itself.
> specifying MAG's address in DHCP message seems to be more reasonable.
> 
> Also, if MAG's address is used as the server-id, there is 
> another issue related to MN's handover. 
> 
> Since the MN does not know the link change, the DHCP client 
> in the MN will unicast DHCP request (renew) to the server IP 
> address which was acquired by oMAG (server-id). This might be 
> undesirable behavior because oMAG maintains state for the MN 
> that is not in the access link anymore. Thus, DHCP client in 
> the MN needs to reconfigure its local configuration 
> parameters. One simple solution would be to force the DHCP 
> client to renew its state by sending DHCP FORCERENEW message 
> as follows. 
> 
> MN     oMAG    nMAG      LMA
> Subject: [netlmm] I-D 
> ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt 
> 
> 
> > This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> > 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Sangjin Jeong" <[email-masked]>
Date: Thu, 10 May 2007 20:32:38 +0900

Hi Domagoj,

See inline please.

> We could also let the MAG act as a DHCP relay and the LMA as DHCP server. Then it would be the LMA's address in the server-id option. In other words, DHCP messaging from the first figure in your ma…

The v4 support draft describes three address assignment schemes, static,
dynamic with LMA, and dynamic with DHCP server. When DHCP server is used
for assigning IPv4 home address, there will be DHCP relay agent on the link and
it will relay the DHCP messages to DHCP server. As you said, there is no issue
in this case.

However, when LMA assigns home address, there is no DHCP server or relay
agent. What I am considering is this case.

> Another solution could be to let the client go into rebinding state. Then the client would broadcast the DHCP-REQ which would contain the client's current IP address and would not contain the serve…

Yes right. I proposed that scheme to Ryuji during initial discussion.
However, I prefer to force the client to renew its state quickly. :)

Regards,
Sangjin

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 10 May 2007 17:24:37 +0200

Hi Sangjin,

> > We could also let the MAG act as a DHCP relay and the LMA 
> as DHCP server. Then it would be the LMA's address in the 
> server-id option. In other words, DHCP messaging from the 
> first figure in your mail would be extended all the way to 
> the LMA. This approach has no issues with handover.
> >
> 
> The v4 support draft describes three address assignment 
> schemes, static, dynamic with LMA, and dynamic with DHCP 
> server. When DHCP server is used for assigning IPv4 home 
> address, there will be DHCP relay agent on the link and it 
> will relay the DHCP messages to DHCP server. As you said, 
> there is no issue in this case.
> 
> However, when LMA assigns home address, there is no DHCP 
> server or relay agent. What I am considering is this case.

Yes, I see. I guess I was assuming that DHCP server and the LMA are collocated in the same box.

If they are not, and if the lease time expires, how does the LMA learn about expired address? DHCP server may even assign the expired address to another host. IMO, the LMA (and MAG) should stop providing service to the host if its address expired.

I see several options:
- DHCP server and LMA communicate by means which are out of scope of this spec (not really helpfull)
- we let the MAG monitor the lease time and deregister with LMA if it expires
- or maybe we can somehow couple the lease time and the MIP binding lifetime

> > Another solution could be to let the client go into 
> rebinding state. Then the client would broadcast the DHCP-REQ 
> which would contain the client's current IP address and would 
> not contain the server-id option. The new MAG would respond 
> with DHCP-ACK extending the lease time of the currently 
> assigned IP address. And the response would contain the 
> address of the new MAG in the server-id option.
> >
> 

Maybe we could keep both options. I think not many clients today implement DHCP-FORCERENEW. If the client doesn't support FORCERENEW, it will end up in rebinding state, so the MAG should be able to handle this situation.

regards
domagoj

> Sent: 10. svibanj 2007 13:33
> To: Premec, Domagoj
> Cc: Ryuji Wakikawa; [email-masked]
> > > server, MAG should use its IP address as the server-id so 
> that MAG 
> > > can respond MN's DHCP messages.
> > >
> informs MN 
> > > of LMA address as a server address, MN will send DHCP messages to 
> > > LMA address and MAG will have to intercept them.
> > We could also let the MAG act as a DHCP relay and the LMA 
> as DHCP server. Then it would be the LMA's address in the 
> server-id option. In other words, DHCP messaging from the 
> first figure in your mail would be extended all the way to 
> the LMA. This approach has no issues with handover.
> >
> 
> The v4 support draft describes three address assignment 
> schemes, static, dynamic with LMA, and dynamic with DHCP 
> server. When DHCP server is used for assigning IPv4 home 
> address, there will be DHCP relay agent on the link and it 
> will relay the DHCP messages to DHCP server. As you said, 
> there is no issue in this case.
> 
> However, when LMA assigns home address, there is no DHCP 
> server or relay agent. What I am considering is this case.
> 
> > Another solution could be to let the client go into 
> rebinding state. Then the client would broadcast the DHCP-REQ 
> which would contain the client's current IP address and would 
> not contain the server-id option. The new MAG would respond 
> with DHCP-ACK extending the lease time of the currently 
> assigned IP address. And the response would contain the 
> address of the new MAG in the server-id option.
> >
> 
> > > Actually, it was raised during initial version discussion, so I 
> > > bring it back.
> > >
> > > In Step 5, DHCP offer will include server-id in the 
> message and DHCP 
> > > clients will use the IP address provided in the server-id for any 
> > > unicast requests to the DHCP server.
> > >
> > > server, MAG should use its IP address as the server-id so 
> that MAG 
> > > can respond MN's DHCP messages.
> > >
> informs MN 
> > > of LMA address as a server address, MN will send DHCP messages to 
> > > LMA address and MAG will have to intercept them.
> > > Since the MN does not know the link change, the DHCP 
> client in the 
> > > MN will unicast DHCP request (renew) to the server IP 
> address which 
> > > was acquired by oMAG (server-id). This might be 
> undesirable behavior 
> > > because oMAG maintains state for the MN that is not in the access 
> > > link anymore. Thus, DHCP client in the MN needs to 
> reconfigure its 
> > > local configuration parameters. One simple solution would be to 
> > > force the DHCP client to renew its state by sending DHCP 
> FORCERENEW 
> > > message as follows.
> > >
> > > MN     oMAG    nMAG      LMA
> > > > Author(s) : R. Wakikawa, S. Gundavelli Filename : 
> > > > draft-ietf-netlmm-pmip6-ipv4-support-00.txt
> > > > Pages : 25
> > > > Date : 2007-4-26
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. Login with 
> > > > the username "anonymous" and a password of your e-mail address. 
> > > > After logging in, type "cd internet-drafts" and then "get 
> > > > draft-ietf-netlmm-pmip6-ipv4-support-00.txt".
> > > >
> > > > http://www.ietf.org/shadow.html or 
> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > > "FILE 
> /internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-00.txt".
> > > >
> > > > command.  To decode the response(s), you will need 
> "munpack" or a 
> > > > MIME-compliant mail reader.  Different MIME-compliant 
> mail readers 
> > > > "multipart" MIME messages (i.e. documents which have 
> been split up 
> > > > into multiple messages), so check your local 
> documentation on how 
> > > > to manipulate these messages.
> > > >

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 11 May 2007 14:11:06 +0900

Hello Premec,

On 2007/05/11, at 0:24, Premec, Domagoj wrote:

> If they are not, and if the lease time expires, how does the LMA  
> learn about expired address? DHCP server may even assign the  
> expired address to another host. IMO, the LMA (and MAG) should stop  
> providing service to the host if its address expired.
>

Wether DHCP server is co-located with LMA doesn't matter in this  
case. MAG is the DHCP relay and can monitor the lease time.
If the lease time is expired, MAG receives DHCPNACK and then sends PBU 
(deregistration) to LMA.
We should clearly mention this in the spec.

regards,
ryuji

> Maybe we could keep both options. I think not many clients today  
> implement DHCP-FORCERENEW. If the client doesn't support  
> FORCERENEW, it will end up in rebinding state, so the MAG should be  
> able to handle this situation.
>
> regards
> domagoj
>
>
>
>> procedures will
>>>> be performed when LMA assigns IPv4 HoA.
>>>>
>>>>  MN      MAG      LMA
>>>>> A New Internet-Draft is available from the on-line
>>>>>
>> Internet-Drafts
>>
>>>>> directories.
>>>>>   This document specifies extensions to the Proxy Mobile
>>>>>
>>>> IPv6 protocol
>>>>
>>>>>   [ID-PMIP6] for supporting IPv4.  The scope of the
>>>>>
>> IPv4 support in
>>
>>>>>   Proxy Mobile IPv6 includes the support for the mobile
>>>>>
>> node's IPv4
>>
>>>>>   home address mobility and for supporting the scenario
>>>>>
>>>> where the local
>>>>
>>>>>   mobility anchor and the mobile access gateway are
>>>>>
>> separated by an
>>
>>>>>   extensions defined in Dual Stack Mobile IPv6
>>>>>
>> specification [ID-
>>
>>>>> To remove yourself from the I-D Announcement list, send a
>>>>>
>>>> message to
>>>>
>>>>> [email-masked] with the word unsubscribe in
>>>>>
>>>> the body of
>>>>
>>>>> the message.
>>>>> You can also visit
>>>>>
>>>>> Below is the data which will enable a MIME compliant
>>>>>
>> mail reader
>>
>>>>> implementation to automatically retrieve the ASCII
>>>>>
>> version of the
>>
>>>>> Internet-Draft.
>>>>>
>>>>>
>>>>
>>>>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 11 May 2007 12:51:19 +0200

Hi Ryuji,

please see inline...

> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: 11. svibanj 2007 07:11
> To: Premec, Domagoj
> Cc: Sangjin Jeong; [email-masked]
> server-id 
> >> option. In other words, DHCP messaging from the first 
> figure in your 
> >> mail would be extended all the way to the LMA. This 
> approach has no 
> >> issues with handover.
> >>
> >>>
> >>>
> >>
> >> The v4 support draft describes three address assignment schemes, 
> >> static, dynamic with LMA, and dynamic with DHCP server. When DHCP 
> >> server is used for assigning IPv4 home address, there will be DHCP 
> >> relay agent on the link and it will relay the DHCP 
> messages to DHCP 
> >> server. As you said, there is no issue in this case.
> >>
> >> However, when LMA assigns home address, there is no DHCP server or 
> >> relay agent. What I am considering is this case.
> >>
> >
> > If they are not, and if the lease time expires, how does 
> the LMA learn 
> > about expired address? DHCP server may even assign the 
> expired address 
> > to another host. IMO, the LMA (and MAG) should stop 
> providing service 
> Wether DHCP server is co-located with LMA doesn't matter in 
> this case. MAG is the DHCP relay and can monitor the lease time.

What I mean by "monitoring the lease time" is that DHCP relay starts a timer in the same way as DHPC server. Do you have the same understanding? Yes, this needs to be explicitely described in the spec - monitoring the lease time is not something that regular DHCP relays do.

Could you please elaborate a bit more on how DHCPNACK would be used, some concernes below:

If MAG receives DHCPNACK, why would it need to monitor the lease time? It could rely on the DHCPNACK, right?

Are you refering to the case when the client's request to extend the lease time is refused? In this case DHCPNACK is sent in unicast to the client, so MAG would have to inspect all downlink traffic for DHCPNACK messages, right?

What about the case when the address expired because the client didn't send a request to extend the lease time? Would the DHCP server still send DHCPNACK? Directly to MAG, i.e. with MAG's IP address as the destination?

regards
domagoj

> 
> regards,
> ryuji
> 
> 
> > I see several options:
> > - DHCP server and LMA communicate by means which are out of 
> scope of 
> > this spec (not really helpfull)
> > - we let the MAG monitor the lease time and deregister with 
> LMA if it 
> > expires
> >> rebinding state. Then the client would broadcast the 
> DHCP-REQ which 
> >> would contain the client's current IP address and would 
> not contain 
> >> the server-id option. The new MAG would respond with DHCP-ACK 
> >> extending the lease time of the currently assigned IP address. And 
> >> the response would contain the address of the new MAG in the 
> >> server-id option.
> >>
> >>>
> >>>
> >>
> FORCERENEW, 
> > it will end up in rebinding state, so the MAG should be 
> able to handle 
> > this situation.
> >
> > regards
> > domagoj
> >
> >
> >
> server-id 
> >> option. In other words, DHCP messaging from the first 
> figure in your 
> >> mail would be extended all the way to the LMA. This 
> approach has no 
> >> issues with handover.
> >>
> >>>
> >>>
> >>
> >> The v4 support draft describes three address assignment schemes, 
> >> static, dynamic with LMA, and dynamic with DHCP server. When DHCP 
> >> server is used for assigning IPv4 home address, there will be DHCP 
> >> relay agent on the link and it will relay the DHCP 
> messages to DHCP 
> >> server. As you said, there is no issue in this case.
> >>
> >> However, when LMA assigns home address, there is no DHCP server or 
> >> relay agent. What I am considering is this case.
> >>
> >>
> >> rebinding state. Then the client would broadcast the 
> DHCP-REQ which 
> >> would contain the client's current IP address and would 
> not contain 
> >> the server-id option. The new MAG would respond with DHCP-ACK 
> >> extending the lease time of the currently assigned IP address. And 
> >> the response would contain the address of the new MAG in the 
> >> server-id option.
> >>
> >>>
> >>>
> >>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 11 May 2007 14:53:51 +0200

Hi Ryuji,

One additonal question for the case when DHCP server and LMA are different boxes: is the DHCP traffic tunneled through the MAG-LMA tunnel? The draft implies that the DHCP traffic is not going over the tunnel. At least during the initial attachment DHCP messages are exchanged before the MAG-LMA tunnel is set up, correct? Since renewal messages are sent by client in unicast to DHCP server, I would expect them to be tunneled through MAG-LMA tunnel, with the rest of the MN's traffic. What is your opinion?

regards
domagoj

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 14 May 2007 18:54:05 +0900

Hi Premec,

On 2007/05/11, at 19:51, Premec, Domagoj wrote:

> What I mean by "monitoring the lease time" is that DHCP relay  
> starts a timer in the same way as DHPC server. Do you have the same  
> understanding? Yes, this needs to be explicitely described in the  
> spec - monitoring the lease time is not something that regular DHCP  
> relays do.
> If MAG receives DHCPNACK, why would it need to monitor the lease  
> time? It could rely on the DHCPNACK, right?

Sorry, my reply wasn't so clear. I mean DHCP relay can know the  
expired lease time by receiving DHCPNACK. Thus,
DHCP relay doesn't need to monitor the release time explicitly.

In your case, address assignment is managed by DHCP and not PMIP.  
Thus, the lease time should be managed by DHCP as specified in DHCP's  
RFC.

ryuji

> Are you refering to the case when the client's request to extend  
> the lease time is refused? In this case DHCPNACK is sent in unicast  
> to the client, so MAG would have to inspect all downlink traffic  
> for DHCPNACK messages, right?
>
> What about the case when the address expired because the client  
> didn't send a request to extend the lease time? Would the DHCP  
> server still send DHCPNACK? Directly to MAG, i.e. with MAG's IP  
> address as the destination?
>
> regards
> domagoj
>
>
>
>>
>> regards,
>> ryuji
>>
>>
>>> I see several options:

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 14 May 2007 18:57:29 +0900

Each DHCP relay (i.e. on each MAG) knows DHCP server address. It just  
forwards the DHCP messages to the DHCP server.
Thus, the DHCP messages are not sent to the PMIP tunnel. Note that  
renewal messages are sent to the DHCP relay agent (i.e. MAG), not to  
the DHCP server...

regards,
ryuji

On 2007/05/11, at 21:53, Premec, Domagoj wrote:

> Hi Ryuji,
>
> One additonal question for the case when DHCP server and LMA are  
> different boxes: is the DHCP traffic tunneled through the MAG-LMA  
> tunnel? The draft implies that the DHCP traffic is not going over  
> the tunnel. At least during the initial attachment DHCP messages  
> are exchanged before the MAG-LMA tunnel is set up, correct? Since  
> renewal messages are sent by client in unicast to DHCP server, I  
> would expect them to be tunneled through MAG-LMA tunnel, with the  
> rest of the MN's traffic. What is your opinion?
>
> regards
> domagoj
>
>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 14 May 2007 12:01:57 +0200

Hi Ryuji,

> > If MAG receives DHCPNACK, why would it need to monitor the 
> lease time? 
> > It could rely on the DHCPNACK, right?
> 
> Sorry, my reply wasn't so clear. I mean DHCP relay can know 
> the expired lease time by receiving DHCPNACK. Thus, DHCP 
> relay doesn't need to monitor the release time explicitly.
> 
> Thus, the lease time should be managed by DHCP as specified 
> in DHCP's RFC.

There are several issues with this approach:
- DHCP server (a regular one) is not allowed to send unsolicited DHCPNACK
- the intened receiver of DHCPNACK will not be expecting the DHCPNACK message and will simply ignore it
- DHCPNACK is always sent directly to the client, never to the DHCP relay

If we go with this approach, the draft needs to clearly describe requirements/behaviour which are different or not specified in the relevant DHCP RFCs.

domagoj

> Sent: 14. svibanj 2007 11:54
> To: Premec, Domagoj
> server or 
> >>> Yes, I see. I guess I was assuming that DHCP server and 
> the LMA are 
> >>> collocated in the same box.
> > What I mean by "monitoring the lease time" is that DHCP 
> relay starts a 
> > timer in the same way as DHPC server. Do you have the same 
> > understanding? Yes, this needs to be explicitely described 
> in the spec 
> > - monitoring the lease time is not something that regular 
> DHCP relays 
> > do.
> > Could you please elaborate a bit more on how DHCPNACK would 
> be used, 
> > some concernes below:
> >
> > If MAG receives DHCPNACK, why would it need to monitor the 
> lease time? 
> > It could rely on the DHCPNACK, right?
> 
> Sorry, my reply wasn't so clear. I mean DHCP relay can know 
> the expired lease time by receiving DHCPNACK. Thus, DHCP 
> relay doesn't need to monitor the release time explicitly.
> 
> Thus, the lease time should be managed by DHCP as specified 
> in DHCP's RFC.
> 
> ryuji
> 
> > Are you refering to the case when the client's request to 
> extend the 
> > lease time is refused? In this case DHCPNACK is sent in 
> unicast to the 
> > client, so MAG would have to inspect all downlink traffic 
> for DHCPNACK 
> > messages, right?
> >
> > What about the case when the address expired because the 
> client didn't 
> > send a request to extend the lease time? Would the DHCP 
> server still 
> > send DHCPNACK? Directly to MAG, i.e. with MAG's IP address as the 
> > destination?
> >
> > regards
> > domagoj
> >
> >
> >
> >>
> >> regards,
> >> ryuji
> >>
> >>
> >>> I see several options:
> >>> - or maybe we can somehow couple the lease time and the 
> MIP binding 
> >>> lifetime
> >>>
> >>>
> server or

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 14 May 2007 13:23:28 +0200

Ryuji,

> Thus, the DHCP messages are not sent to the PMIP tunnel. Note 
> that renewal messages are sent to the DHCP relay agent (i.e. 
> MAG), not to the DHCP server...

No, the DHCP client sends renewal messages in unicast directly to the DHCP server, bypassing the DHCP relay. RFC 3046 allows DHCP relays to monitor (intercept) such messages, but this is MAY. If the MAG is supposed to intercept unicast DHCP messages and forward them outside of the MAG-LMA tunnel to the DHCP server, IMO this must be clearly described in the draft. (If you like, I could provide a couple of sentences.)

domagoj

> Sent: 14. svibanj 2007 11:57
> To: Premec, Domagoj
> Each DHCP relay (i.e. on each MAG) knows DHCP server address. 
> It just forwards the DHCP messages to the DHCP server.
> Thus, the DHCP messages are not sent to the PMIP tunnel. Note 
> that renewal messages are sent to the DHCP relay agent (i.e. 
> MAG), not to the DHCP server...
> 
> regards,
> ryuji
> 
> > tunnel? The draft implies that the DHCP traffic is not 
> going over the 
> > tunnel. At least during the initial attachment DHCP messages are 
> > exchanged before the MAG-LMA tunnel is set up, correct? 
> Since renewal 
> > messages are sent by client in unicast to DHCP server, I 
> would expect 
> > them to be tunneled through MAG-LMA tunnel, with the rest 
> of the MN's 
> > traffic. What is your opinion?
> >
> > regards
> > domagoj
> >
> >