[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 >>
- [Netext] PMIPv6 localized routing - IPv4 aspects Qin Wu
- [Netext] PMIPv6 localized routing - IPv4 aspects Qin Wu
- [Netext] PMIPv6 localized routing - IPv4 aspects Marco Liebsch
- [Netext] PMIPv6 localized routing - IPv4 aspects Qin Wu
- [Netext] PMIPv6 localized routing - IPv4 aspects Marco Liebsch
- [Netext] PMIPv6 localized routing - IPv4 aspects jouni korhonen
- [Netext] PMIPv6 localized routing - IPv4 aspects Marco Liebsch
- [Netext] PMIPv6 localized routing - IPv4 aspects Marco Liebsch