[Netext] PMIPv6 localized routing - IPv4 aspects

marco.liebsch at nw.neclab.eu (Marco Liebsch) Fri, 12 June 2009 15:19 UTC

From: "marco.liebsch at nw.neclab.eu"
Date: Fri, 12 Jun 2009 17:19:28 +0200
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
In-Reply-To: <01fe01c9ea42$9ab787b0$260ca40a@china.huawei.com>
References: <4A2FE194.8040804@nw.neclab.eu> <01fe01c9ea42$9ab787b0$260ca40a@china.huawei.com>
Message-ID: <4A327200.3090502@nw.neclab.eu>

Hi Qin,

please see inline for my thoughts.

Qin Wu schrieb:
>> 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.
>   
Yes, but that can be mapped to the case where there is a NAT between 
MAGs, right? So it does not
represent an extra case which introduces additional problems, or?

> 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.
>   
If the IPv4 draft indicates that the LMA must not be behind a NAT, the 
same holds for the
RO protocol extension. Or is there anything extra to be analyzed for RO?


>   
>> 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.
>   
Probably not. In particular since NetExt scope is limited to RO within a 
single PMIPv6 domain, where in
a multi-LMA scenario these LMAs should be behind the same NAT. But as 
you said, LMAs behind a
NAT are ruled out, if my understanding is correct. But maybe there are 
other opinions

marco


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