Subject: [netlmm] NAT traversal support [was:] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-03.txt

From: Julien Laganier <[email-masked]>
Date: Mon, 2 Jun 2008 14:42:54 +0200

Folks,

The IPv4 Support for Proxy Mobile IPv6 has support for NAT detection. 

There's however a certain number of usecases for this specification 
where no NATs will ever be present between an LMA and a MAG since they 
are in controlled environments.

I'd thus like to make it possible to turn the NAT traversal mechanism 
on/off with a configuration parameter on MAGs. That is, the 
specification would have a sentence like "Implementation MUST provide a 
configuration parameter that allows an administrator to disable the NAT 
traversal mechanism."

What do people think?

--julien 

On Wednesday 28 May 2008, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network-based Localized Mobility
> Management Working Group of the IETF.
>
> 	Title		: IPv4 Support for Proxy Mobile IPv6
> 	Author(s)	: R. Wakikawa, S. Gundavelli
> 	Filename	: draft-ietf-netlmm-pmip6-ipv4-support-03.txt
> 	Pages		: 35
> 	Date		: 2008-5-22
>
> This document specifies extensions to Proxy Mobile IPv6 protocol for
> supporting IPv4 protocol.  The scope of this IPv4 support includes
> the support for the mobile node's IPv4 home address mobility and for
> allowing the mobility entities in the Proxy Mobile IPv6 domain to
> exchange signaling messages over an IPv4 transport.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-supp
>ort-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 2 Jun 2008 07:23:06 -0700 (PDT)

Hi Julien,

Given that the mode (UDP encapsulation) mode is dynamically
negotiated based on the NAT on-path determination, wondering
why we need to turn this off explicitly. Its a simple check.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Mon, 2 Jun 2008 16:35:03 +0200

Hi Sri,

In an environment where I know there will never be any NAT, and thus 
I'll never need UDP encapsulation, I think we can simply turn it off. 

Another proposal would be to make the NAT traversal feature an optional 
part of the specification (i.e. MAY) since it's useless in such 
environments. That would simplify implementation targetting such types 
of environment. The NAT Traversal / IPsec interaction isn't easy to 
implement IMHO.

--julien

On Monday 02 June 2008, Sri Gundavelli wrote:
> > where no NATs will ever be present between an LMA and a MAG since
> > they are in controlled environments.
> >
> > I'd thus like to make it possible to turn the NAT traversal
> > mechanism on/off with a configuration parameter on MAGs. That is,
> > the specification would have a sentence like "Implementation MUST
> > provide a configuration parameter that allows an administrator to
> > disable the NAT traversal mechanism."
> >
> > What do people think?
> >
> > --julien
> >
> >> This document specifies extensions to Proxy Mobile IPv6 protocol
> >> for supporting IPv4 protocol.  The scope of this IPv4 support
> >> includes the support for the mobile node's IPv4 home address
> >> mobility and for allowing the mobility entities in the Proxy
> >> Mobile IPv6 domain to exchange signaling messages over an IPv4
> >> transport.
> >>
> >> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-s
> >>upp ort-03.txt
> >>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 2 Jun 2008 07:37:19 -0700 (PDT)

Hi Julien,

If NAT is not detected, the mode will not be turned on.
So, your requirement of no UDP encap mode is there.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Mon, 2 Jun 2008 17:04:50 +0200

Sri,

For DSMIPv6 NAT detection makes a lot of sense since both the MN and HA 
have no idea what kind of transit networks are between them.

For PMIPv6 things are different. It is network based, and the operator 
of the LMA and MAG networks can certainly figure out if they have/want 
a NAT in between them. The operating environment is under control.

Since the mechanism of NAT traversal is pretty hard to implement, and 
since it's not going to be needed in some deployments (e.g. 3GPP), it 
makes sense to me to make it optional to implement.

--julien

On Monday 02 June 2008, Sri Gundavelli wrote:
> > In an environment where I know there will never be any NAT, and
> > thus I'll never need UDP encapsulation, I think we can simply turn
> > it off.
> >
> > Another proposal would be to make the NAT traversal feature an
> > optional part of the specification (i.e. MAY) since it's useless in
> > such environments. That would simplify implementation targetting
> > such types of environment. The NAT Traversal / IPsec interaction
> > isn't easy to implement IMHO.
> >
> > --julien
> >
> >>> There's however a certain number of usecases for this
> >>> specification where no NATs will ever be present between an LMA
> >>> and a MAG since they are in controlled environments.
> >>>
> >>>> A New Internet-Draft is available from the on-line
> >>>> Internet-Drafts directories.
> >>>> This draft is a work item of the Network-based Localized
> >>>> Mobility Management Working Group of the IETF.
> >>>>
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4
> >>>>-s upp ort-03.txt
> >>>>
> >>>> implementation to automatically retrieve the ASCII version of
> >>>> the Internet-Draft.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 2 Jun 2008 08:54:12 -0700 (PDT)

Hi Julien,

Ok. It should not be an issue to define a config parameter to turn
it off, if needed.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 2 Jun 2008 10:51:42 -0700 (PDT)

Just a config knob to turn it off the NAT detect checks. But,
we need to see this in comparison to an inexpensive safe check
of NAT detect, if it really saves much.

Sri

On Mon, 2 Jun 2008, Vijay Devarapalli wrote:

> Wait, I think Julien in his last email was proposing "optional to
> implement the NAT traversal mechanism". Are we agreeing to that or to
> just provide a configuration knob to enable/disable the NAT detection
> mechanism?
>
> I am also worried about the 'F' flag in the NAT Detection Option. I was
> opposed to adding this flag in the DS-MIPv6 specification. This is used
> to force UDP encapsulation by the home agent even when no NAT is
> detected. I would like to add some text to
> draft-ietf-netlmm-pmip6-ipv4-support saying that this 'F' flag MUST NOT
> be set by the LMA if a NAT is not detected.
>
> Vijay
>
>>
>> Sri
>>
>>
>>>>>>>> 	Filename	:
>> draft-ietf-netlmm-pmip6-ipv4-support-03.txt
>>>>>>>> 	Pages		: 35
>>>>>>>> 	Date		: 2008-5-22
>>>>>>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 2 Jun 2008 10:53:56 -0700 (PDT)

F flag is not set by the HA. MN can force it UDP encap, not
HA. This is required for firewall reasons and the same is
is in 3519.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 2 Jun 2008 11:21:25 -0700 (PDT)

On Mon, 2 Jun 2008, Vijay Devarapalli wrote:

> See draft-ietf-mext-nemo-v4traversal-03.txt
>
>   Alternatively, the home agent can force UDP encapsulation by setting
>   the F flag in the NAT detection option included in the binding
>   acknowledgement.
>
> In any case, in the context of PMIPv6, I think UDP encapsulation should
> not be forced if a NAT is not detected.
>

There are two things here:

1.) The config option to enable/disable NAT detection behavior
     as Julien suggested. This should not be an issue, if a
     deployment is certain about the topology and does not want
     these checks. However, this is an expensive check and if
     there is a good reason to define this option, we can do that.

2.) The "F" bit is in the BU/BA. Due to firewall or administrative
     reasons, either ends should be able to force this. Personally
     from 3519 implementation and deployment experience, I've seen
     this usage a lot. For IPv4 environments, this is required. A
     simple example is a firewall policy blocking IP-in-IP packets
     and this can be only be enforced in the control path. Unless,
     there is an issue, we should not explicitly disable this.
     There is no specification cost either.

We can take some inputs on this.

Thanks
Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 2 Jun 2008 13:34:49 -0400

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 2 Jun 2008 14:05:12 -0400

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 3 Jun 2008 14:15:11 +0900

Hi

>     there is a good reason to define this option, we can do that.

Is this local config option on LMA and MAG?
Or do you consider some config parameter exchanged with some handshake  
between LMA and MAG?

BTW, if NAT is disabled, we need a new BA error code
like [NAT NOT SUPPORTED] for interoperability.

>     There is no specification cost either.

It makes sense in Mobile IP case. However,
in PMIP, we should allow F bit only if there is NAT on the path.
LMA and MAG are in the same administrative domain. The firewall  
setting should be negotiable.
Do you see any use case where operator only allow UDP tunneled  
packets  between LMA and MAG?

ryuji

---

From: Julien Laganier <[email-masked]>
Date: Tue, 3 Jun 2008 11:47:24 +0200

> just provide a configuration knob to enable/disable the NAT detection

Right, lately I've been proposing making the NAT traversal mechanism 
optional since it will not be used in some system architectures and 
will save a significant amount of complexity, both for specification 
and implementation itself.

--julien