Subject: [netlmm] Consensus call: PMIP6 IPv4 support change

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 15 Jan 2010 15:41:32 +0200

Hello,

This is an "official" consensus call on the proposed changes documented at
http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18a-pa
si-jikv3.txt.

Please, indicate if if you are in favor, or against the proposed change, and
the reason for your position.

Consensus call: PMIP6 IPv4 support change
Start: Now
End: January 29th, 2009 EOB Pacific time.

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 15 Jan 2010 17:04:00 +0200

Hi,

And obviously, the date is January 29th, 2010... Talking about being stuck
in the past!

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 15 Jan 2010 09:15:23 -0800

I am against the proposed change 

IMHO this is not acceptable for an extension to a MIPv6 extension.With MIPv6, mobility signaling is always layered on top of IPv6. As a result the IPsec policy operates on IPv6. Proxy MIPv6 has built on that model. 

The change proposed at this stage layers mobility signaling on top of UDP, which is inconsistent with design choices that were made for MIPv6. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Soininen, Jonne (NSN - FI/Espoo)
> Sent: Friday, January 15, 2010 5:42 AM
> To: [email-masked]
> Cc: Pasi Eronen
> Subject: [netlmm] Consensus call: PMIP6 IPv4 support change
> 
> Hello,
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 12:03:45 +0100

Proxy MIPv6 is built on a model where IPsec policy operates on the
addresses of LMA/MAG that are actually used for routing packets
between them, which is *VERY* different from the model used by
MIPv6. So I don't agree that PMIPv6 built on the model used by MIPv6
on how IPsec policy operates; both indeed use IPv6 addresses, but in
very different ways.

It's also worth noting that the IPsec/MIPv6 interaction specified in
RFC 5555 assumes a very specific interpretation of how IKEv2 NAT
traversal works with transport mode SAs (a topic that was not well
specified in RFC 4306). IPSECME WG has since investigated the issue,
and it turned out that the behavior assumed by RFC 5555, although it
works for DSMIPv6, doesn't work in most cases. The updated IKEv2 spec
(draft-ietf-ipsecme-ikev2bis, hopefully going to IETF Last Call soon)
will clarify the behavior, and it looks like that behavior will be
incompatible with RFC 5555 and the current version of pmip6-ipv4
draft. 

Best regards,
Pasi
(not wearing any hats)

> From: ext Laganier, Julien [mailto:[email-masked]]
> Sent: 15 January, 2010 19:15
> To: Soininen, Jonne (NSN - FI/Espoo); [email-masked]
> Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: RE: [netlmm] Consensus call: PMIP6 IPv4 support change
> 
> IMHO this is not acceptable for an extension to a MIPv6 extension.With
> MIPv6, mobility signaling is always layered on top of IPv6. As a result
> the IPsec policy operates on IPv6. Proxy MIPv6 has built on that model.
> 
> The change proposed at this stage layers mobility signaling on top of
> UDP, which is inconsistent with design choices that were made for
> MIPv6.
> 
> > This is an "official" consensus call on the proposed changes
> documented
> > at
> > http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-
> support-
> > 18a-pa
> > si-jikv3.txt.
> >
> > Please, indicate if if you are in favor, or against the proposed
> change,
> > and

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 18 Jan 2010 10:40:47 -0800

Laganier, Julien wrote:
> UDP, which is inconsistent with design choices that were made for MIPv6.

If NAT traversal is not of interest, as per the proposed change, the way to go is to remove UDP encapsulation altogether, unlike the proposed change...

--julien

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Mon, 18 Jan 2010 12:36:15 -0600

Hi Jonne,

I would like to have a NAT detection feature back. I would like
draft-ietf-netlmm-pmip6-ipv4-support to say explicitly that UDP
encapsulation should be used only if NAT is detected. Of course, there are
flags that might override this behavior, but when the flags are not set and
a NAT is not detected, I would like to use IP-in-IP encapsulation.

Vijay

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Mon, 18 Jan 2010 12:39:04 -0600

Hi Julien, Pasi,

> on how IPsec policy operates; both indeed use IPv6 addresses, but in

Agree with Pasi on this. The IPsec interaction as specified in RFC 5213 is
very different from how MIPv6 uses IPsec.

Vijay

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 19:55:57 +0100

Vijay,

What is the problem with having UDP encapsulation used all the time? I
believe it simplifies the protocol. Rather than doing NAT detection and then
deciding whether to encapsulate in UDP, it is simpler to do UDP
encapsulation all the time. The overhead is not really an issue if that is
your concern.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Jan 2010 15:48:56 -0800

Hi Vijay,

Earlier, when we discussed about the use of UDP encap  with IPv4 transport,
the agreement was:

- not to force UDP encapsulation for data path
- use UDP encapsulation for control messages.

The use of UDP encap when using IPv4 transport allows the MIPv6 HA
application to intercept the control messages in a easier manner. It also
serves the purpose of on-path NAT detection. With MIPv6, application can
register with the IPv6 stack for all messages with MH header. With IPv4, UDP
encapsulation helps.

If you go back to the earlier discussion between you, julien, Ryuji, myself
and possibly others, we discussed about some complexity for the applications
to insert hooks in the switching path for receiving IPv4 control messages
and that the use of UDP encap simplifies to some extent. We all agreed not
to mandate UDP encap for data path.

The below change, you are suggesting, we don't use UDP encap for control or
data path ?

Regards
Sri

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Mon, 18 Jan 2010 18:57:42 -0600

> The below change, you are suggesting, we don't use UDP encap for control or

For data path. The initial PBU is always sent with UDP encapsulation.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Jan 2010 17:36:11 -0800

Hi Vijay,

Skipping UDP should be fine for data path, while keeping it for control.
That's fine, will add clarifications as needed.

Regards
Sri

>>>> This is an "official" consensus call on the proposed changes documented at
http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18a-p>>>>
a

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Mon, 18 Jan 2010 19:38:55 -0600

Sri,

The proposed change removes the NAT detection capability. So without knowing
if there is a NAT on the path, you would end up using UDP encapsulation all
the time for the data path.

I don't understand what clarifications you will be adding.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Jan 2010 17:46:13 -0800

Hi Vijay,

If NAT is not detected and the flags are not set for UDP encap, UDP encap is
not used. Where is the issue ?

Sri

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Mon, 18 Jan 2010 20:27:59 -0600

Sri,
 
Section 4.1.3.3 in version 17 has been removed. Section 4.1.3.3 specified
how the LMA and MAG detect a NAT on the path.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Jan 2010 18:37:26 -0800

Hi Vijay,

Yes. The use of UDP encap for NAT detection is just one use-case, that's
what I'm saying. I'm not talking about the issue of need for NAT support,
keeping that aside, the UDP encap is needed for control. You raised the
issue of when we would need it for data path, for firewall traversal or
other reasons, if UDP encap is desired, it can be enabled, but it can be
turned off when not needed. Hope this clarifies.

Regards
Sri

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 11:22:14 +0100

The proposed changes don't work with NATs (see my email on 
January 7 for details), so there's no need for NAT detection.

For the data path, it is possible to use either IP-in-IP or UDP (to
work with e.g. some other middleboxes than NATs), but this requires
manually configuring which is used, just like in the current draft 
(since NAT detection won't detect those other middleboxes).
 
Best regards,
Pasi

> From: ext Devarapalli, Vijay [mailto:[email-masked]]
> Sent: 19 January, 2010 03:39
> To: Sri Gundavelli; Soininen, Jonne (NSN - FI/Espoo); [email-masked]
> Subject: Re: [netlmm] Consensus call: PMIP6 IPv4 support change
> 
> Sri,
> 
> documented at

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 16:45:05 +0100

Sri/Vijay,

What is the downside (other than the 8 byte overhead) of having UDP
encapsulation for signaling and traffic all the time?

It simplifies the protocol and avoids the need to verify the presence of
NATs and flags to switch on/off the encapsulation.

Why not just have UDP encap as the default.

-Raj

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 19 Jan 2010 10:24:51 -0600

Hi Pasi,

> January 7 for details), so there's no need for NAT detection.

I had responded to this. Lets say, IPsec is not used and both the control
plane and the data plane use the same UDP port. You don't have the issue of
control and data plane messages using different UDP ports. Then you can have
NAT detection.
 
> (since NAT detection won't detect those other middleboxes).

This would just default to using UDP encapsulation all the time.

Vijay

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 19 Jan 2010 10:28:33 -0600

Hi Raj,

We decided a while ago that Mobile IP (both MIPv4 and MIPv6) use IP-in-IP
encapsulation. When DS-MIPv6 was standardized, we went with the same
assumption. UDP encapsulation is only used when NAT is detected.

We are just changing that. :)

The 8-byte overhead is significant too. Apart from that, the data plane
processing has an overhead too (processing the UDP header versus just
decapsulating and forwarding the inner packet).

Vijay

On 1/19/10 7:45 AM, "[email-masked]" <[email-masked]>
wrote:

>>>>>>>> The below change, you are suggesting, we don't use UDP encap for
>>>>>>>> control
>>>>>>>> or
>>>>>>>> data path ?
>>>>>>> 
>>>>>>>>> flags that might override this behavior, but when the flags are not
>>>>>>>>> set
>>>>>>>>> and

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 09:15:27 -0800

If we relinquish the ability to detect NAT, UDP encapsulation should go away with it.

--julien

Pasi Eronen wrote:
> > if there is a NAT on the path, you would end up using UDP
> encapsulation
> > all
> > control or
> > 18a-p>>>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 19 Jan 2010 13:41:07 -0500

Hi Vijay,

> control and data plane messages using different UDP ports. Then you can have

Isn't IPsec mandatory for PBU and PBA?What do you mean "IPsec isn't used"?

ryuji

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 19 Jan 2010 12:53:30 -0600

> If we relinquish the ability to detect NAT, UDP encapsulation should go away

Why? 

Both with DS-MIPv6 and PMIPv6 IPv4 support, we made decisions that said you
can use UDP encapsulation even without detecting a NAT. This could be for a
number of reasons - MAG knowing something about the access network that the
LMA did not, firewalls and middle box traversal, etc.. So I don't agree with
your statement above.

Vijay

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 19 Jan 2010 12:55:09 -0600

Hi Ryuji,

> Isn't IPsec mandatory for PBU and PBA?What do you mean "IPsec isn't used"?

Support for IPsec is a MUST. The usage is not. :)

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 19 Jan 2010 14:03:05 -0500

> Support for IPsec is a MUST. The usage is not. :)

You implement IPsec, but you don't run IPsec?!
We don't have have local configuration to turn on/off IPsec, I am afraid of loosing interoperability.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 19 Jan 2010 14:03:55 -0500

Julien

As Sri mentioned, there is other reasons to use UDP (firewall, etc).

ryuji

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 19 Jan 2010 11:40:07 -0800

> > If we relinquish the ability to detect NAT, UDP encapsulation should

Sorry - I should have said, if we relinquish the ability to traverse NATs, UDP encapsulation should go away with it.

> Both with DS-MIPv6 and PMIPv6 IPv4 support, we made decisions that said
> you can use UDP encapsulation even without detecting a NAT. This could be
> for a number of reasons - MAG knowing something about the access network that
> the LMA did not, firewalls and middle box traversal, etc.. So I don't agree
> with your statement above.

The firewall can be configured to let IPv6-in-IPv4 and IPv4-in-IPv4 pass thru.

--julien

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 21:24:15 +0100

Hi Vijay,

> assumption. UDP encapsulation is only used when NAT is detected.

I know. IMO this only adds to complex protocol specification. UDP
encapsulation at all times would be preferable even in the case of DSMIP6.

> The 8-byte overhead is significant too.

In what way? On the MAG-LMA links the additional 8-byte overhead is a small
price to pay for the benefits (FW/NAT traversal) that you get.

> Apart from that, the data plane

I don't believe this would impact your performance with current generation
HW.

-Raj

>>>>>>>>>> encapsulation should be used only if NAT is detected. Of course,
>>>>>>>>>> there
>>>>>>>>>> are

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 21:29:22 +0100

Vijay Devarapalli wrote:

> I had responded to this. Lets say, IPsec is not used and both the
> control plane and the data plane use the same UDP port. You don't
> have the issue of control and data plane messages using different
> UDP ports. Then you can have NAT detection.

I doubt the IESG would approve a spec that is intended to work with
NATs, but is totally insecure when doing so (security can be 
turned on only if there's no NAT).

Best regards,
Pasi

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 19 Jan 2010 14:34:16 -0600

Hi Pasi,

> turned on only if there's no NAT).

I didn't say that. The document should say that if IPsec is used to secure
the PBU/PBACK exchange, then the NAT detection feature does not work. You
have to depend on manual configuration on the MAG and the LMA to figure out
when to use UDP encapsulation. If IPsec is not used, NAT detection can be
supported and used. Based on that the MAG and the LMA can use IP-in-IP or
IP-in-UDP-in-IP for the data path.

Vijay

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 21:42:40 +0100

Vijay Devarapalli wrote:

> I didn't say that. The document should say that if IPsec is used to
> secure the PBU/PBACK exchange, then the NAT detection feature does
> not work.  You have to depend on manual configuration on the MAG and
> the LMA to figure out when to use UDP encapsulation. 

No, the NAT detection feature could actually work, but the rest of the
protocol doesn't. So even if you configured both ends manually
("yes, there's a NAT"), it still would not work.

Best regards,
Pasi

---

From: jouni korhonen <[email-masked]>
Date: Tue, 19 Jan 2010 23:33:26 +0200

Hi Ryuji,

> You implement IPsec, but you don't run IPsec?!

For example, because your customer or the deployment environment where the PMIP6 is used does not require use of IPsec.

> We don't have have local configuration to turn on/off IPsec, I am afraid of loosing interoperability.

We don't? The RFC5213 says "..SHOULD be used..", which basically means for a vendor that the usecase is optional. It is then switchable using a configuration knob or an additional plug-able feature. And for the latter case you definitely want a solution that is really simple to add/remove to the rest of the system.

For any bigger deployments, operators agree on common profiles and do IOTs.. 

Cheers,
	Jouni

>>>>>> there are

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Jan 2010 17:13:55 -0800

Hi Raj,

I'll be fine with mandating UDP encap. But, there was some interest for this
8-byte optimization. We also have the text, flags, other drafts in RFC
editor queue and backed by some prior discussions, so, keeping the same
semantics at this stage will be better, IMO.

Regards
Sri

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 20 Jan 2010 08:32:33 -0800

Ryuji:

The firewall can be configured to let pass thru v6-in-v4 and v4-in-v4 packets between MAGs and LMAs.

--julien

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 21 Jan 2010 18:19:35 -0500

Hello Folks,

I believe I have been consistent of NOT supporting a MAG behind a NAT and the proposed changes are inline of what I have been saying all along:-)

On the other hand, I very well understand NAT detection functionality in the case of DSMIP6 since we are talking about a Mobile node that is most probably not aware of the network configuration. However, in the case of PMIP6, I hardly can imagine that a deployment wont know if a MAG is behind a NAT or NOT! while the MAG itself needs to be aware of many other things before being able to send a PBU to a specific LMA. For example, the MAG and the LMA needs to be in the same PMIP6 domain, there should be a trust relationship between the MAG and the LMA, there needs to be a SA between the two, and most difinetely a SLA of some kind, etc...... 

Because of that, I strongly believe that the current flags and design will allow the MAG within the definition of PMIP6 domain to know if IPv4-UDP is needed because of a NAT presence or NOT. IMO, this means NAT detection is not necessary for PMIP6 while it is essential in DSMIP6.

On the other hand, I would like to add another minor comment that requires a correction to the list of comments I posted on Dec. 3rd, 2009:

Sections 4.3.1 and 4.3.2 use the term Proxy-CoA_1 and LMAA_1. My understanding these terms refer to the respected IPv6 addresses. They need to be replaced by: IPv4-Proxy-CoA_1 and IPv4-LMAA_1, respectively.

Having said the above, I would like to support the proposed changes.

Best Regards,
Ahmad
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Soininen, Jonne (NSN - FI/Espoo) [[email-masked]]
Sent: Friday, January 15, 2010 7:41 AM
To: [email-masked]
Cc: Pasi Eronen
Subject: [netlmm] Consensus call: PMIP6 IPv4 support change

Hello,

Cheers,

Jonne.
--
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 22 Jan 2010 10:02:28 -0800

Hello Ahmad,

Good to see I'm not the only one that consistently opposed introduction of NAT detection and traversal to this spec.

I however do not support the proposed change. I believe we shouldn't encapsulate anything if we do not need to traverse NATs.

--julien

> Behalf Of Ahmad Muhanna
> Sent: Thursday, January 21, 2010 3:20 PM
> I believe I have been consistent of NOT supporting a MAG behind a NAT
> and the proposed changes are inline of what I have been saying all
> along:-)
> 
> On the other hand, I very well understand NAT detection functionality
> in the case of DSMIP6 since we are talking about a Mobile node that is
> most probably not aware of the network configuration. However, in the
> case of PMIP6, I hardly can imagine that a deployment wont know if a
> MAG is behind a NAT or NOT! while the MAG itself needs to be aware of
> many other things before being able to send a PBU to a specific LMA.
> For example, the MAG and the LMA needs to be in the same PMIP6 domain,
> there should be a trust relationship between the MAG and the LMA, there
> needs to be a SA between the two, and most difinetely a SLA of some
> kind, etc......
> 
> Because of that, I strongly believe that the current flags and design
> will allow the MAG within the definition of PMIP6 domain to know if
> IPv4-UDP is needed because of a NAT presence or NOT. IMO, this means
> NAT detection is not necessary for PMIP6 while it is essential in
> DSMIP6.
> 
> On the other hand, I would like to add another minor comment that
> requires a correction to the list of comments I posted on Dec. 3rd,
> 2009:
> 
> Sections 4.3.1 and 4.3.2 use the term Proxy-CoA_1 and LMAA_1. My
> understanding these terms refer to the respected IPv6 addresses. They
> need to be replaced by: IPv4-Proxy-CoA_1 and IPv4-LMAA_1, respectively.
> 
> 
> From: [email-masked] [[email-masked]] On Behalf Of
> Soininen, Jonne (NSN - FI/Espoo) [[email-masked]]

---

From: Ahmad Muhanna <[email-masked]>
Date: Sat, 23 Jan 2010 02:49:23 -0500

Hello Julien,
I am glad that we are on the same boat, even if only partially:-)

As far as data path when IPsec is not used and no NAT, IPv6-in-IPv4 works just fine and I guess that inline of what you prefer. On the other hand, as you know, MIP6 was designed with IPv6 transport in mind. I understand that DSMIP6 described how to use MIP6 signaling over IPv4 transport but with a lot of pain. I still remember the discussion:-)

I look at the proposed changes as a nice enhancement to enable PMIP6 signaling over IPv4 transport smoothly while enabling the option of having IPsec terminates at another box. Nice and clean.

Additionally, we just agreed that there are few differences between DSMIP6 and PMIP6. I do not see a problem in PMIP6 differs in this piece too.

Best Regards,
Ahmad
________________________________________
From: Laganier, Julien [[email-masked]]
Sent: Friday, January 22, 2010 12:02 PM
To: Ahmad Muhanna; Soininen, Jonne (NSN - FI/Espoo); [email-masked]
Cc: Pasi Eronen
Subject: RE: [netlmm] Consensus call: PMIP6 IPv4 support change

Hello Ahmad,

--julien

---

From: jouni <[email-masked]>
Date: Sun, 24 Jan 2010 13:03:21 +0200

Hi,

On Jan 23, 2010, at 9:49 AM, Ahmad Muhanna wrote:

[snip]

> I look at the proposed changes as a nice enhancement to enable PMIP6 signaling over IPv4 transport smoothly while enabling the option of having IPsec terminates at another box. Nice and clean.

I can second this. You could achieve this way of functioning with based PMIPv6, so having it on IPv4 transport is imho beneficial.

Cheers,
	Jouni

> _______________________

[snap]

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 25 Jan 2010 11:30:45 -0800

Hello Ahmad,

If there's no NAT and no UDP encapsulation, you can terminate IPsec earlier than the MAG and LMA by using regular IPsec tunnel mode between two security gateways. The artificial UDP-encapsulation is something different.

If IPsec tunnel mode is what we're after, let's do it. 

--julien
 
> Sent: Friday, January 22, 2010 11:49 PM
> To: Laganier, Julien; Soininen, Jonne (NSN - FI/Espoo); [email-masked]
> Cc: Pasi Eronen
> As far as data path when IPsec is not used and no NAT, IPv6-in-IPv4
> works just fine and I guess that inline of what you prefer. On the
> other hand, as you know, MIP6 was designed with IPv6 transport in mind.
> I understand that DSMIP6 described how to use MIP6 signaling over IPv4
> transport but with a lot of pain. I still remember the discussion:-)
> 
> I look at the proposed changes as a nice enhancement to enable PMIP6
> signaling over IPv4 transport smoothly while enabling the option of
> having IPsec terminates at another box. Nice and clean.
> 
> Additionally, we just agreed that there are few differences between
> DSMIP6 and PMIP6. I do not see a problem in PMIP6 differs in this piece
> too.
> 
> Best Regards,
> Ahmad
> Good to see I'm not the only one that consistently opposed introduction
> of NAT detection and traversal to this spec.
> 
> I however do not support the proposed change. I believe we shouldn't
> encapsulate anything if we do not need to traverse NATs.
> 
> --julien
>

---

From: Ahmad Muhanna <[email-masked]>
Date: Tue, 26 Jan 2010 22:04:20 -0500

Hello Julien,

My understanding; we agreed to have UDP encapsulation for signaling any way; that what I meant when said "smoothly". :-)

Regards,
Ahmad
Sent: Tuesday, January 26, 2010 2:30 AM

Hello Ahmad,

--julien

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 27 Jan 2010 18:25:49 +0800

Hi Jonne,

The proposed changes in

http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18
a-pasi-jikv3.txt looks ok.

The proposed changes on using UDP for PBU for IPv4 transport without
IPv6 header looks fine.  Although NAT detection is not in this version,
using UDP without IPv6 header for PBU makes it simple for Ipsec
processing of the control message.

By applying the ESP natively (removing the IPv6 header), the normal
Ipsec is getting applied normally as it will get applied to any IP
packet.

Thanks.

BR,
Mohana

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Soininen, Jonne (NSN - FI/Espoo)
> Sent: Friday, January 15, 2010 9:42 PM
> To: [email-masked]
> Cc: Pasi Eronen
documented at
http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18
a-
> pa
change,

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 27 Jan 2010 08:42:57 -0800

Hello Ahmad,

My understanding: 

We've been working under the assumption that we need to detect and traverse NAT.

Under that assumption, we agreed to have UDP encapsulation. 

Now this assumption is being challenged. If it no longer holds, we have no agreement to use UDP encapsulation.

If we do not need to traverse NATs, we do not need UDP encapsulation, unless there's a clear case describing its purpose (other than being "smooth".) I have not seen that happen so far. 

--julien

> Sent: Tuesday, January 26, 2010 7:04 PM
> My understanding; we agreed to have UDP encapsulation for signaling any
> way; that what I meant when said "smoothly". :-)
> 
> Regards,
> Ahmad
> If there's no NAT and no UDP encapsulation, you can terminate IPsec
> earlier than the MAG and LMA by using regular IPsec tunnel mode between
> two security gateways. The artificial UDP-encapsulation is something
> different.
>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 27 Jan 2010 18:53:33 -0800

Hey Julien,

But, we did discuss the need for UDP encap for control plane even when NAT
devices are not present in path. Please see the thread.

http://www.ietf.org/mail-archive/web/netlmm/current/msg05166.html

To repeat, Using  L4 delivery semantics, will provide a proper delivery path
for control messages to the MIP modules. Carrying both control and data
packets natively will require in-kernel interceptions and some
implementation complexity, vs. receiving a packet on transport socket. Other
reasons, on path firewall devices, non MH semantics in IPv4 headers and the
use of transport ports...

I see you are not comfortable with this, I understand. But, we discussed
this issue. We really need to close this work.

Hope you agree.

Regards
Sri

On 1/27/10 8:42 AM, "Laganier, Julien" <[email-masked]> wrote:

> If we do not need to traverse NATs, we do not need UDP encapsulation, unless
> there's a clear case describing its purpose (other than being "smooth".) I
> have not seen that happen so far.
> 
> --julien
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 27 Jan 2010 19:35:16 -0800

Hello Sri,

Sri Gundavelli wrote:
> 
> Hey Julien,
> 
> But, we did discuss the need for UDP encap for control plane even when
> NAT devices are not present in path. Please see the thread.
> 

Please see more below - 

> To repeat, Using  L4 delivery semantics, will provide a proper delivery
> path for control messages to the MIP modules. Carrying both control and
> data packets natively will require in-kernel interceptions and some
> implementation complexity, vs. receiving a packet on transport socket.
> Other reasons, on path firewall devices, non MH semantics in IPv4 headers and
> and the use of transport ports...

Just above you talked about the MIP modules. One of the primary customer for this work is 3GPP. The 3GPP EPS system architecture supports both DSMIPv6 and PMIPv6, and the HA and LMA are located in the same box (PDN-GW). In the IETF, the decision to base Network-Based Mobility on Mobile IPv6 signaling was motivated by the simplicity of implementing both in the same box, as in the 3GPP use case. By making the PMIPv6 and DSMIPv6 encapsulation different you complexify the implementation. 

As to receive the packets in kernel, that is required already when PMIPV6 is transported over native IPv6, so I guess that's doable for native IPv4 as well. 

> I see you are not comfortable with this, I understand. But, we
> discussed this issue. We really need to close this work.

Sri, we did discuss a similar, but different issue, on which we did conclude, but the assumptions were different. The issue was, if NAT traversal is required, let's not re-invent the wheel and reuse DSMIPv6. 

Now for the sake of simplicity we say don't need NAT traversal, there's no practical usecase, so I'm just asking for consistency.

So far I have not seen a convincing explanation of why UDP encapsulation should be used, I am still left with 1) handling firewalls that apparently can't be configured to let IPv6 in IPv4 traffic pass thru, and 2) making life easier for developers who can intercept IPv6 packets in kernel but not IPv4 ones.

Best,

--julien