Subject: Re: [netlmm] Global IPv4 address on LMA

From: "Alper Yegin" <[email-masked]>
Date: Mon, 5 Jan 2009 15:15:01 +0200

Sri,

I think if we change

	The mobile access gateway can be potentially in a private IPv4
      network behind a NAT [RFC-3022] device, with a private IPv4
      address configured on its egress interface.  However, the local
      mobility anchor must not be behind a NAT and must be using a
      globally routable IPv4 address.

To

	The mobile access gateway can be potentially in a private IPv4
      network behind a NAT [RFC-3022] device, with a private IPv4
      address configured on its egress interface.  However, the local
      mobility anchor must not be behind a NAT from mobile access
	gateway's point of view.

Actually, if you consider registration revocation, then even the MAG must
not be behind a NAT from LMA's point of view. If you agree, than I'd further
revise the text to:

	The mobile access gateway and local mobility anchor can be 
	potentially in a private IPv4 network behind a NAT [RFC-3022]
device.  
	NAT may have to be traversed when the IP packets need to reach
	other domains or the Internet. However, there must not be a 
	NAT between the mobile access gateway and the local mobility anchor.

	In other words, PBU and PBA packets must not traverse a NAT.

Does this make sense?

Alper

.

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Thursday, December 18, 2008 7:48 PM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: RE: [netlmm] Global IPv4 address on LMA
> 
> Hi Alper,
> 
> 
> 
> On Thu, 18 Dec 2008, Alper Yegin wrote:
> 
> > Hi Sri,
> >
> >>> Current draft-ietf-netlmm-pmip6-ipv4-support-07.txt spec says:
> >>>
> >>> 	However, the local
> >>>      mobility anchor must not be behind a NAT and must be using a
> >>>      globally routable IPv4 address.
> >>>
> >>>
> >>> We shouldn't be preventing use of PMIP6 in private networks. For
> >> that, the
> >>> above text gets in the way and mandate on the global IPv4 address
> >> should be
> >>> removed.
> >>
> >>
> >> We allow the MAG to be behing a private network. However, we dont
> >> allow LMA to be behind in a private network, as such usage is
> >> remote and that makes the solution complex. As we discussed in the
> >> past, we just restricted this to the common case.
> >
> > MAG and LMA being in two different private domains is "remote and
> complex to
> > handle", I agree.
> > MAG and LMA being in the same private domain is trivial -- it just
> works.
> > I presume it is the former you wanted to restrict, not the latter.
> > If you agree, we can work out a text towards that objective.
> >
> 
> Yes. MAG and LMA in the same private domain, or same routing domain
> with no translation requirement, should work fine. Yes, we can add
> clarifying text to this affect.
> 
> Regards
> Sri

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Jan 2009 12:13:04 -0800 (PST)

Hi Alper,

> mobility anchor must not be behind a NAT from mobile access

This is fine, this will clarify the case where both the entities
are in the same (private) routing domain.

Regards
Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 5 Jan 2009 16:37:01 -0500

> 	In other words, PBU and PBA packets must not traverse a NAT.

Hmm... DS-MIPv6 allows the MN to be behind a NAT, while requiring the
home agent to be reachable via a public IPv4 HA address. The PMIPv6 IPv4
support document is just following the same. I don't think there was an
intention to prohibit NATs between the MAG and the LMA. The text you
proposed above prohibits NATs between the MAG and the LMA. 

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Jan 2009 13:39:47 -0800 (PST)

> proposed above prohibits NATs between the MAG and the LMA.

Alper was making sure, we dont exclude the case where both LMA
and MAG are using private IPv4 addresses, but are in a single
routing domain. In other words no NAT's between them, but in a
single IPv4 private routing domain. So, the clarification was
not to disallow this case, in addition to the other modes.

Sri