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

From: "John.zhao" <[email-masked]>
Date: Fri, 11 May 2007 10:24:18 +0800

Hi, Domagoj and sangjin

         Based on the rebind method, I think some necessary parameter will
be share between new MAG and old MAG to confirm the right reassignment and
avoid some possible attack.

         As to the DHCP Server stay w/o LMA schema, I think that seems not
very feasible.

         That DHCP Force Renew signal is a good way, but if the new MAG send
it ,then why the client can believe that. I think RFC3203 didn't metion
about it.

Best Rgds,

Thanks,

John.zhao

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

Date: Thu, 10 May 2007 17:24:37 +0200

From: "Premec, Domagoj" <[email-masked]>

Subject: RE: [netlmm] I-D

         ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

To: "Sangjin Jeong" <[email-masked]>

Cc: Ryuji Wakikawa <[email-masked]>, [email-masked]

Message-ID:

<[email-masked]>

Content-Type: text/plain;   charset="iso-8859-1"

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.

> Yes right. I proposed that scheme to Ryuji during initial discussion.

> However, I prefer to force the client to renew its state quickly. :)

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

> -----Original Message-----

> From: Sangjin Jeong [ <mailto:[email-masked]> mailto:[email-masked]]

> Sent: 10. svibanj 2007 13:33

> To: Premec, Domagoj

> Cc: Ryuji Wakikawa; [email-masked]

> Subject: Re: [netlmm] I-D

> ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

> Hi Domagoj,

> See inline please.

> On 5/10/07, Premec, Domagoj <[email-masked]> wrote:

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

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

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

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

> 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

> > regards

> > domagoj

> > > -----Original Message-----

> > > From: Sangjin Jeong [ <mailto:[email-masked]>
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,

> > > 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-ip>
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ip

> > > v4-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>
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> http://www.ietf.org/shadow.html
or 

> > > >  <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
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: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 11 May 2007 12:53:48 +0900

Hi John and Sangjin,

On 2007/05/11, at 11:24, John.zhao wrote:

> Hi, Domagoj and sangjin
>
>
>
>          Based on the rebind method, I think some necessary  
> parameter will be share between new MAG and old MAG to confirm the  
> right reassignment and avoid some possible attack.
>
>          As to the DHCP Server stay w/o LMA schema, I think that  
> seems not very feasible.
>
>          That DHCP Force Renew signal is a good way, but if the new  
> MAG send it ,then why the client can believe that. I think RFC3203  
> didn’t metion about it.

Good point. The force-renew message can be possible security  
vulnerability.
It is better that the MN should go into the REBINDING state and  
broadcast DHCPREQ again.

regards,
ryuji

> 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
>
> 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
>
>
>
>
>
> > From: Sangjin Jeong [mailto:[email-masked]]
>
> > > > From: Sangjin Jeong [mailto:[email-masked]]
>
> > > > > http://www.ietf.org/shadow.html or
>

---

From: "Sangjin Jeong" <[email-masked]>
Date: Fri, 11 May 2007 14:36:44 +0900

Hi Ryuji,

On 5/11/07, RYUJI WAKIKAWA <[email-masked]> wrote:
> > didn't metion about it.

Let me summarize this issue.

- When MAG sends DHCP offer to MN, MAG's IP address will be
included in the server-id option.
- MAG discards MN's unicast DHCP request whose destination
is not the MAG itself so that the MN can go into DHCP REBINDING
state and broadcast DHCP request without server-id.

Any thoughts?

Regards,
Sangjin

---

From: "John.zhao" <[email-masked]>
Date: Fri, 11 May 2007 14:33:01 +0800

Hi,Sangjin

	I think this description can work. But for avoiding to cause some
confusion. The new MAG can check the server-id option in unicast DHCP
request any more. Typically, there are three scenarios existed in this
message:
	1)The server-id option contain a IP address that is equal to the new
MAG address. Then that means the new MAG should handle this DHCP message
directly.
	2)The server-id option contain a IP address that isn't equal to the
new MAG address but it equal to the previous MAG(if the new MAG can know the
old MAG ip address stored in MN). Then this message should be discarded to
force the MN enter into rebinding state.
	3)The server-id option contain a IP address that is equal to neither
the new MAG address , nor the old MAG address. How do dealt with them?
Simple discarded? Or reverse tunnel to home network? I think seems the later
is the right choice to keep some normal behavior can continue.
	My two cents.

Best Rgds,
Thanks,
John.zhao

-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月11日 13:37
收件人: RYUJI WAKIKAWA
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi Ryuji,

Any thoughts?

Regards,
Sangjin

---

From: "Sangjin Jeong" <[email-masked]>
Date: Fri, 11 May 2007 16:10:30 +0900

Hi John,

I briefly described just the basic idea. :)

On 5/11/07, John.zhao <[email-masked]> wrote:
> Simple discarded? Or reverse tunnel to home network?

Would you elaborate on this? What kind of home network do you mean?

Regards,
Sangjin

> I think seems the later

---

From: "John.zhao" <[email-masked]>
Date: Fri, 11 May 2007 15:51:08 +0800

Hi,Sangjin

	OK. I see you described the basic idea. So something can be appended
based on that.
	What I means about the home network is referred to the network that
LMA located. Because all of the traffics towards to or comes from MN will
via the tunnel between MAG and LMA. 
	So that problem I mean is that if the server-id isn't equal to any
one of old MAG and new MAG? Why? Error handler or is a normal case? If error
handler , then discard is no problem. But if is a normal case, it should be
transferred simply. And to a PMIP MN, it only has the reverse tunnel can be
chosen.
	My two cents.

	Best Rgds,
Thanks.

John.zhao

-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月11日 15:11
收件人: [email-masked]
抄送: RYUJI WAKIKAWA; [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

Regards,
Sangjin

---

From: "Sangjin Jeong" <[email-masked]>
Date: Fri, 11 May 2007 21:31:56 +0900

Hi John,

Thanks for your kind explanation.
See inline, please.

> via the tunnel between MAG and LMA.

OK. I see.

> handler , then discard is no problem.

In the scenario where LMA assigns IPv4 HoA, MN should get its HoA from MAG
through DHCP procedures. Further, MAG is seen as DHCP server from MN.
So, the server-id should indicate MAG's address. If the server-id in
MN is neither
old MAG nor new MAG's address during handover, it will imply that MN gets
its HoA from other means or has configuration error. In any case, it does
not seem to be normal behavior. Thus, discarding the DHCP message is more
reasonable, IMO.

Regards,
Sangjin

> But if is a normal case, it should be

---

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

Hi Sangjin, John,

please see below...

 > >        So that problem I mean is that if the server-id 
> isn't equal to 
> > any one of old MAG and new MAG? Why? Error handler or is a normal 
> > case? If error handler , then discard is no problem.
> 
> In the scenario where LMA assigns IPv4 HoA, MN should get its 
> HoA from MAG through DHCP procedures. Further, MAG is seen as 
> DHCP server from MN.
> So, the server-id should indicate MAG's address. If the 
> server-id in MN is neither old MAG nor new MAG's address 
> during handover, it will imply that MN gets its HoA from 
> other means or has configuration error. In any case, it does 
> not seem to be normal behavior. Thus, discarding the DHCP 
> message is more reasonable, IMO.

DHCPREQ sent from the renewing state will not contain server-id option, it is sent in unicast directly to the DHCP server's address.

I think it is possible that the address of the DHCP server to which the DHCPREQ message is sent does not correspond neither to that of current MAG nor the previous MAG. Consider a MN that attaches at MAG1 (so it saves MAG1's address as the address of the DHCP server), then moves to MAG2 and subsequently to MAG3 before T1 expired. If T1 then expires at MAG3, the client will send DHCPREQ to MAG1. This should be treated as normal behavior. But discarding this DHCPREQ at MAG3 seems to be the right action anyway if we want to let the MAG3 act as the DHCP server. Though this means filtering of MN's traffic at MAG.

domagoj

> Sent: 11. svibanj 2007 14:32
> To: [email-masked]
> Cc: RYUJI WAKIKAWA; Premec, Domagoj; [email-masked]
> >        OK. I see you described the basic idea. So something can be 
> > appended based on that.
> >        What I means about the home network is referred to 
> the network 
> > that LMA located. Because all of the traffics towards to or 
> comes from 
> > MN will via the tunnel between MAG and LMA.
> 
> OK. I see.
> 
> >        So that problem I mean is that if the server-id 
> isn't equal to 
> > any one of old MAG and new MAG? Why? Error handler or is a normal 
> > case? If error handler , then discard is no problem.
> 
> In the scenario where LMA assigns IPv4 HoA, MN should get its 
> HoA from MAG through DHCP procedures. Further, MAG is seen as 
> DHCP server from MN.
> So, the server-id should indicate MAG's address. If the 
> server-id in MN is neither old MAG nor new MAG's address 
> during handover, it will imply that MN gets its HoA from 
> other means or has configuration error. In any case, it does 
> not seem to be normal behavior. Thus, discarding the DHCP 
> message is more reasonable, IMO.
> 
> Regards,
> Sangjin
> 
> > transferred simply. And to a PMIP MN, it only has the 
> reverse tunnel 
> > can be chosen.
> >        My two cents.
> >
> >        Best Rgds,
> > Thanks.
> >
> > John.zhao
> >
> > -----邮件原件-----
> > 主题: Re: [netlmm] I-D 
> > >        I think this description can work. But for 
> avoiding to cause 
> > > some confusion. The new MAG can check the server-id option in 
> > > unicast DHCP request any more. Typically, there are three 
> scenarios 
> > > existed in this
> > > message:
> > >        1)The server-id option contain a IP address that 
> is equal to 
> > > the
> > new
> > > MAG address. Then that means the new MAG should handle this DHCP 
> > > message directly.
> > >        2)The server-id option contain a IP address that 
> isn't equal 
> > > to the new MAG address but it equal to the previous 
> MAG(if the new 
> > > MAG can know
> > the
> > > old MAG ip address stored in MN). Then this message should be 
> > > discarded to force the MN enter into rebinding state.
> > >        3)The server-id option contain a IP address that 
> is equal to
> > neither
> > > 主题: Re: [netlmm] I-D 
> > > > > parameter will be share between new MAG and old MAG 
> to confirm 
> > > > > the right reassignment and avoid some possible attack.
> > > > >
> > > > >          That DHCP Force Renew signal is a good way, 
> but if the 
> > > > > new MAG send it ,then why the client can believe 
> that. I think 
> > > > > RFC3203 didn't metion about it.
> > > >
> > > - When MAG sends DHCP offer to MN, MAG's IP address will 
> be included 
> > > in the server-id option.
> > > - MAG discards MN's unicast DHCP request whose destination is not 
> > > the MAG itself so that the MN can go into DHCP REBINDING 
> state and 
> > > broadcast DHCP request without server-id.
> > >
> > > Any thoughts?
> > >
> > > Regards,
> > > Sangjin
> > >
> > > >
> > > > regards,
> > > > ryuji
> > > >
> > > > >
> > > > >
> > > > > Best Rgds,
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John.zhao
> > > > >
> > > > > > 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.
> > > > >
> > > > > > >
> > > > >
> > > > > >
> > > > >
> > > > > > 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
> > > > >
> > > > > Yes, I see. I guess I was assuming that DHCP server 
> and the LMA 
> > > > > are collocated in the same box.
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > > > rebinding state. Then the client would broadcast 
> the DHCP-REQ 
> > > > > > which
> > > > >
> > > > > > extending the lease time of the currently assigned 
> IP address.
> > > > > And the
> > > > >
> > > > > FORCERENEW, it will end up in rebinding state, so the 
> MAG should 
> > > > > be able to handle this situation.
> > > > >
> > > > >
> > > > >
> > > > > regards
> > > > >
> > > > > domagoj
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > > > Since LMA assigns MN's home network address and 
> there is 
> > > > > > > > no DHCP
> > > > >
> > > > > > > > IMHO, it is not a natural way for MAG to 
> intercept/respond 
> > > > > > > > DHCP
> > > > >
> > > > > > 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.
> > > > >
> > > > > > >
> > > > >
> > > > > >
> > > > >
> > > > > > 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
> > > > >
> > > > > > > > Also, if MAG's address is used as the 
> server-id, there is
> > > > > another
> > > > >
> > > > > > rebinding state. Then the client would broadcast 
> the DHCP-REQ 
> > > > > > which
> > > > >
> > > > > > extending the lease time of the currently assigned 
> IP address.
> > > > > And the
> > > > >
> > > > > > > > Actually, it was raised during initial version 
> discussion, 
> > > > > > > > so I
> > > > >
> > > > > > > > bring it back.
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > clients will use the IP address provided in the 
> server-id 
> > > > > > > > for
> > > > > any
> > > > >
> > > > > > > > Since LMA assigns MN's home network address and 
> there is 
> > > > > > > > no DHCP
> > > > >
> > > > > > > > IMHO, it is not a natural way for MAG to 
> intercept/respond 
> > > > > > > > DHCP
> > > > >
> > > > > > > > Also, if MAG's address is used as the 
> server-id, there is
> > > > > another
> > > > >
> > > > > > > > because oMAG maintains state for the MN that is 
> not in the
> > > > > access
> > > > >
> > > > > > > > local configuration parameters. One simple 
> solution would 
> > > > > > > > be to
> > > > >
> > > > > > > > >   IPv4 transport network.  The solution primarily 
> > > > > > > > > leverages
> > > > > the
> > > > >
> > > > > > > > > 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
> > > > >
> > > > > > > > > Internet-Drafts are also available by anonymous FTP. 
> > > > > > > > > Login
> > > > > with
> > > > >
> > > > > > > > > MIME-encoded form by using the "mpack" 
> utility.  To use 
> > > > > > > > > this
> > > > >

---

From: "Sangjin Jeong" <[email-masked]>
Date: Mon, 14 May 2007 10:31:46 +0900

Hi Domagoj,

On 5/11/07, Premec, Domagoj <[email-masked]> wrote:
> DHCPREQ sent from the renewing state will not contain server-id option, it is
> sent in unicast directly to the DHCP server's address.

Since the destination of unicast DHCP request during renewal is derived from
server-id, I used the term server-id for convenience. Sorry for confusion.

>
> I think it is possible that the address of the DHCP server to which the DHCPREQ
> message is sent does not correspond neither to that of current MAG nor the
> previous MAG. Consider a MN that attaches at MAG1 (so it saves MAG1's
> address as the address of the DHCP server), then moves to MAG2 and
> subsequently to MAG3 before T1 expired. If T1 then expires at MAG3, the client
> will send DHCPREQ to MAG1. This should be treated as normal behavior.

I missed this case. Thanks for elaboration, good point.

> But discarding this DHCPREQ at MAG3 seems to be the right action anyway
> if we want to let the MAG3 act as the DHCP server.

I agree. This seems to be right way to do.

Regards,
Sangjin

> Though this means filtering of MN's traffic at MAG.
>
> domagoj
>
>

---

From: "John.zhao" <[email-masked]>
Date: Mon, 14 May 2007 10:03:28 +0800

Hi Sangjin and Domagoj,

	If the destination IP address of DHCP request isn't match to the new
MAG, then we can discard it in most situation. But how about the rebinding
progress? I think only those MNs that have entered in this netlmm domain
successafully and assigned by a MAG should be handled. That can be processed
by checking the server-id option in rebind message. To others, the rebind is
also no need to handle them. Because the rebinding should be a quick
reassign progress, it maybe didn't equal to a re-enter progress. So
typically, it didn't need to interact with some center control function such
as AAA. So if the MN can't provide the same server-id as it is assigned the
current IP address, then the rebind should also be discard and force the MN
go into discover again. After all, we only have this progress to trigger a
whole network entry progress.
	My two cents.

	Best Rgds,
Thanks,

John.zhao

-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月14日 9:32
收件人: Premec, Domagoj
抄送: [email-masked]; RYUJI WAKIKAWA; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi Domagoj,

Regards,
Sangjin

---

From: "Sangjin Jeong" <[email-masked]>
Date: Mon, 14 May 2007 13:21:01 +0900

Hi John,

See inline, please.

On 5/14/07, John.zhao <[email-masked]> wrote:
> by checking the server-id option in rebind message.

DHCPREQ message sent from rebinding state does not include server-id.
I think MAG can filter out the MN that is not eligible to use the PMIP
service based on MN profile.

> To others, the rebind is also no need to handle them.
> Because the rebinding should be a quick
> as AAA.

If MAG detects MN's attachment on link, MAG will get MN's profile information
and will check MN's authorization. Therefore, DHCP procedure will be preformed
after MN attachment procedure.

> So if the MN can't provide the same server-id as it is assigned the
> go into discover again.

Do you mean how to prevent unauthorized MN from using home network address?
If so, when the MN is not allowed to use PMIP service (according to
policy profile),
MAG will discards traffic from MN. So, DHCP messages from rebind state
will be discarded, IMO.

Regards,
Sangjin

> After all, we only have this progress to trigger a

---

From: "John.zhao" <[email-masked]>
Date: Mon, 14 May 2007 12:56:53 +0800

Hi ,Sangjin

	Yes,the server-id isn't included in DHCP Rebind message. 

	Best Rgds,
Thanks,

John.zhao
-----邮件原件-----
发件人: Sangjin Jeong [mailto:[email-masked]] 
发送时间: 2007年5月14日 12:21
收件人: [email-masked]
抄送: Premec, Domagoj; RYUJI WAKIKAWA; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

See inline, please.

> typically, it didn't need to interact with some center control function
such

If MAG detects MN's attachment on link, MAG will get MN's profile
information
and will check MN's authorization. Therefore, DHCP procedure will be
preformed
after MN attachment procedure.

Regards,
Sangjin

> > DHCPREQ sent from the renewing state will not contain server-id option,
it
> is

---

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

Hi John,

As far as I know, there is no way that a new MAG know the old MAG  
information in PMIP spec.
There must be two cases, the server-iD is equal to the new MAG or not.

ryuji

On 2007/05/11, at 15:33, John.zhao wrote:

> message
>>> <[email-masked] 
>>> >
>>>

---

From: "John.zhao" <[email-masked]>
Date: Mon, 14 May 2007 17:52:23 +0800

Hi ryuji,

	Right. To acquire that information will depend on the context
transfer mechanism. 
	In another side, the old MAG in here is means the MAG assigned the
DHCP information to MN. But not just the previous MAG before handover.

	Best Rgds,
Thanks,

John.zhao

-----邮件原件-----
发件人: RYUJI WAKIKAWA [mailto:[email-masked]] 
发送时间: 2007年5月14日 17:48
收件人: [email-masked]
抄送: 'Sangjin Jeong'; [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 15 May 2007 01:04:47 +0900

Hi John,

I see.
MN may cache DHCP states at the regular IPv6 network which is not  
operated by MAG and comes to the PMIP network with such DHCP state  
caches.
Is this the problem you have?

ryuji

---

From: "John.zhao" <[email-masked]>
Date: Tue, 15 May 2007 09:37:52 +0800

Hi , Ryuji	

	Yes. I think you just pointed exactly the problem.
	So I think from a managed network perspective, some information is
necessary to make it more mature. Otherwise, we can discard any DHCP request
message that didn’t belong to it, it is still ok. But can't provide more
flexible difference mechanism.
	Best Rgds,
Thanks,

John.zhao

-----邮件原件-----
发件人: RYUJI WAKIKAWA [mailto:[email-masked]] 
发送时间: 2007年5月15日 0:05
收件人: [email-masked]
抄送: 'Sangjin Jeong'; [email-masked]; [email-masked]
主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

Hi John,

I see.

ryuji