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

["Sangjin Jeong" <[e-mail]>]

Hi Domagoj,

See inline please.

On 5/10/07, Premec, Domagoj <[e-mail]> 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:[e-mail]]
> > Sent: 09. svibanj 2007 11:20
> > To: Ryuji Wakikawa
> > Cc: [e-mail]
> > 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: <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>
> > 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
> > v4-support-00.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a
> > message to
> > > [e-mail] 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:
> > > [e-mail].
> > > 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
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/netlmm
> > >
> >
>

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