[Netext] PMIPv6 localized routing - IPv4 aspects

sunseawq at huawei.com (Qin Wu) Thu, 11 June 2009 03:13 UTC

From: "sunseawq at huawei.com"
Date: Thu, 11 Jun 2009 11:13:33 +0800
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
References: <4A2FE194.8040804@nw.neclab.eu>
Message-ID: <01fe01c9ea42$9ab787b0$260ca40a@china.huawei.com>

> from previous mails and drafts, we can identify a couple of issues which we
> must take into account when designing a localized routing protocol for 
> PMIPv6.
> For the PS, I don't think we need to analyze problems which have been 
> addressed
> for standard RFC5213 operations already, such as a NAT between MAG and LMA.

[Qin]: Probably you are right. I think there are some misunderstandings.
Let me clarify why NAT between MAG and LMA is shown in the figure 1 of draft-wu-netext-pmipv6-ipv4-ro-ps.
I think NAT between MAG and LMA can be further divided into two case:
case 1: The MAG is behind the NAT
case 2: The LMA is behind the NAT
As regarding the Case 1, suppose there is one scenario where the MN attaches to MAG1 and CN attaches to MAG2, MAG1 and MAG2 register
to the different LMA, In this scenario, if there is NAT between MAG1 and LMA1 and the MAG1 is behind the NAT, I think also there is a NAT between 
MAG1 and MAG2, the MAG1 is behind the same NAT as the NAT located between MAG1 and LMA1.
As regarding Case 2,  as described in draft-ietf-netlmm-pmip6-ipv4-support-12, it is impossible for the LMA to locate behind a NAT unless the MAG and 
the LMA both locate behind NAT. Take the same scenario mentioned in the case 1 as example, if there is NAT between MAG1 and LMA1 and the LMA1
and MAG1 are both behind the NAT, I  think also there is a NAT between LMA1 and LMA2.

> We could start with the following list to discuss and identify a 
> possible problem space
> for PMIPv6 localized routing and to find out which of these or new 
> issues are relevant
> for the PS and the NetExt protocol solution. I tried to collect 
> individual items from
> mail exchange with Sangjin, from draft-jeong-netlmm-pmipv6-roreq-01 and
> draft-wu-netext-pmipv6-ipv4-ro-ps-00.

[Qin]: As regarding IPv4 aspects, I am glad the draft-wu-netext-pmipv6-ipv4-ro-ps is credited. 

> Any thought, comment and discussion is welcome.
> 
> marco
> 
> ----
> 
> [1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)
> 
> [2] MN's and CN's MAG support different IP versions to signal to the LMA(s)
> 
> [3] NAT between MN's and CN's MAG
> 
> [4] NAT between MN's and CN's LMA
> 
> [5] Different IP version for signaling between MN's and CN's MAG
> 
> [6] Different IP version for forwarding of localized traffic between 
> MN's and CN's MAG
> 
> [7] IP address conflict when MN and CN use the same IPv4 HoA
> Isn't that an issue with base PMIPv6 already?
> 
> [8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
> localized forwarding between MAGs
> Should work if both MAGs are dual stack and can negotiate the IP version 
> (?).
> 
> [9] Compatibility of route optimization states with IPv4

[Qin]: Thank for your summarizing and re-catogorizing the scenarios described in the draft-wu-netext-pmipv6-ipv4-ro-ps.
I think most of these scenarios you enumerated are reflected in the draft-wu-netext-pmipv6-ipv4-ro-ps except the case where the NAT is located between
MN's and CN's LMA. If my understanding is  correct, this case should require both MAG and LMA behind the same NAT. Because as described in the draft-ietf-netlmm-pmip6-ipv4-support-12:
"
4.  IPv4 Transport Support
the local mobility anchor must not be behind a NAT and must be using a globally routable IPv4 address. 
"
I wonder whether we need to address this case in the PMIPv6 localized routing PS draft.

> In my opinion related to the issues above. If we set up IPv4 transport 
> or user
> plane support on relevant PMIPv6 nodes, route entries and binding 
> management need to
> have entries for IPv4 addresses.

[Qin] I fully agree with you. This point is also reflected in draft-wu-netext-pmipv6-ipv4-ro-ps,i.e, in the section 3 "Scenarios and Problem statement",
it point out routing optimization states for IPv4 support need to be maintained and updated.

> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext