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

"Sangjin Jeong" <sjjeong@gmail.com> Thu, 10 May 2007 06:46 UTC

Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2Py-0002UC-7q; Thu, 10 May 2007 02:46:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2Pv-0002RN-RU for netlmm@ietf.org; Thu, 10 May 2007 02:46:23 -0400
Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2Ps-0005R1-Cq for netlmm@ietf.org; Thu, 10 May 2007 02:46:23 -0400
Received: by nz-out-0506.google.com with SMTP id z6so515377nzd for <netlmm@ietf.org>; Wed, 09 May 2007 23:46:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:from:to:cc:references:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=SCiCKzQ99/pzT3idSheeHWq4AzgNUFMRzvpUHw28xMw3mSPyH3Ae8VSsL4c9uq0dQb8waVuqwXbvNpeGsVyXhYiAf+Ummi1deYQAmH7BYxK7l/FYKKOVdzC1x0L2OrqpokIDZBvqkvMN5T4GfYRXy44w1KZylASNNumT5qBWC9E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:from:to:cc:references:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=AqN/fnTDzuQg0OHTPb6B+MbswRGCkfzm34hjfNEN18FrrSUR3jK/nnKVUVg1/bCFT7HoBxdRBfFo0I7FRuQXG6LwgwQqk4Swgb4/tovd6aLA14LfHcw97lJvWwSZHe5SBLeKD6ad2ZoJjdaBVn8mKRCinveUESPIYb8rd1Tma7Q=
Received: by 10.114.120.1 with SMTP id s1mr386750wac.1178779578588; Wed, 09 May 2007 23:46:18 -0700 (PDT)
Received: from sjjeong ( [129.254.112.53]) by mx.google.com with ESMTP id m26sm205827pof.2007.05.09.23.46.12; Wed, 09 May 2007 23:46:15 -0700 (PDT)
Message-ID: <013401c792ce$e7a50b60$3570fe81@sjjeong>
From: Sangjin Jeong <sjjeong@gmail.com>
To: john.zhao@huawei.com, ryuji@sfc.wide.ad.jp
References: <006c01c792a4$32bbaa80$ad20790a@china.huawei.com>
Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
Date: Thu, 10 May 2007 15:46:10 +0900
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 33fc46667f70a87403df4cb21ee8343c
Cc: netlmm@ietf.org
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0527264317=="
Errors-To: netlmm-bounces@ietf.org

Hi John,

That will be the new MAG.

Regards,
Sangjin
  ----- Original Message ----- 
  From: John.zhao 
  To: sjjeong@gmail.com ; ryuji@sfc.wide.ad.jp 
  Cc: netlmm@ietf.org 
  Sent: Thursday, May 10, 2007 10:40 AM
  Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt


  Hi sangjin Jeong

   

           May I ask you a question, which should DHCP server send the DHCP ForceRenew message to MN? The old one or new one or anyone?

           

           Best Rgds,

  Thanks

   

  John.zhao

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

  Date: Wed, 9 May 2007 18:20:29 +0900

  From: "Sangjin Jeong" <sjjeong@gmail.com>

  Subject: Re: [netlmm] I-D

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

  To: "Ryuji Wakikawa" <ryuji@sfc.wide.ad.jp>

  Cc: netlmm@ietf.org

  Message-ID: <028301c7921b$4b39a5f0$3570fe81@sjjeong>

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

   

  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

   
_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm