Subject: Re: [netlmm] Comments on draft-ietf-netlmm-pmip6-ipv4-support-04.txt

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Aug 2008 15:41:14 -0700 (PDT)

Hi Rajeev,

On Thu, 14 Aug 2008, Koodli, Rajeev wrote:

>
> Sri,
>
> I tend to agree with Vijay: I don't see any issue in having a
> configuration variable that toggles UDP encapsulation ON/OFF based on
> the particular deployment.

We can enable this mode for control messages, if there is a need for
this. It comes at an additional configuration of enabling native
IPv6 over IPv4 transitional support on the LMA. I do not believe this
will be used, but we can add that support.

Sri

>
> Regards,
>
> -Rajeev
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
>> Of Vijay Devarapalli
>> Sent: Thursday, August 14, 2008 1:38 PM
>> To: Sri Gundavelli
>> Cc: [email-masked]
>> Subject: Re: [netlmm] Comments on
> draft-ietf-netlmm-pmip6-ipv4-support-
>> 04.txt
>>
>> Sri,
>>
>> Ok, lets agree to disagree on the "PBU message consistency".
>>
>> However, I would still like to see the MAG configuration option to not
>> use UDP tunneling for the PBU messages specified, if it is known that
>> there is no NAT on the path. With this configuration option, you would
>> either use IPv6-over-IPv4 or with IPv6-in-UDP-over-IPv4 consistently.
>>
>>> While we clearly support encap of traffic in IPv4 packet (no
>>> UDP),
>>
>> We were not discussing that at all. You are making it appear as if you
>> are conceding something. :)
>>
>>> I dont
>>> see value in enabling that for control messages, that is the
>>> approach of
>>> DSMIP as well.
>>
>> This I completely disagree with. If there is not going to be NAT
> between
>> the MAG and the LMA in many of the PMIPv6 deployments, we should not
> be
>> mandating UDP encapsulation for the PBU/PBAck messages. It should be
>> possible to have the MAG and the LMA use plain IPv6-over-IPv4
>> encapsulation for all the PMIPv6 control messages.
>>
>> Vijay
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
>
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
>
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Julien Laganier <[email-masked]>
Date: Wed, 20 Aug 2008 16:46:18 +0200

Hi Sri,

On Friday 15 August 2008, Sri Gundavelli wrote:
> > configuration variable that toggles UDP encapsulation ON/OFF based
> > on the particular deployment.
>

Seems our beliefs differ.

In 3GPP Rel-8 there won't be NAT within operator's core network thus it 
makes no sense to use UDP encap for control or traffic. Please consider 
making the entire UDP encapsulation (control or traffic) optional. 

Regarding the comparison to DSMIPv6, IMHO it's apples-to-orange. While 
it's perfectly understandable that a user's MN might be in a NATed 
access network (with v4, being with a non-NATed one could even be seen  
as a corner case ;) ) and thus DSMIP has UDP encap and stuff, the 
situation for NETLMM is entirely different: Here we're talking about 
infrastructure nodes (MAG and LMA) belonging to a network operator. 

[ and as to my beliefs ;) I don't believe many operators will want to 
deploy NATs between their MAGs and LMAs. In case they don't have enough 
public address space to number their MAGs and LMAs, I bet they'd rather 
place their MAGs and LMAs in the same private addressing domain, e.g. 
10.x.x.x. ]

Cheers,

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 20 Aug 2008 09:51:21 -0500

Hi Julien,

> In 3GPP Rel-8 there won't be NAT within operator's core 
> network thus it makes no sense to use UDP encap for control 
> or traffic. Please consider making the entire UDP 
> encapsulation (control or traffic) optional. 
> 
> Regarding the comparison to DSMIPv6, IMHO it's 
> apples-to-orange. While it's perfectly understandable that a 
> user's MN might be in a NATed access network (with v4, being 
> with a non-NATed one could even be seen as a corner case ;) ) 
> and thus DSMIP has UDP encap and stuff, the situation for 
> NETLMM is entirely different: Here we're talking about 
> [ and as to my beliefs ;) I don't believe many operators will 
> want to deploy NATs between their MAGs and LMAs. In case they 
> don't have enough public address space to number their MAGs 
> and LMAs, I bet they'd rather place their MAGs and LMAs in 
> the same private addressing domain, e.g. 
> 10.x.x.x. ]

[Ahmad]
+1

I would also add that all NAT related text should be captured in a
specific section or moved to an Appendix.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Aug 2008 09:54:33 -0700 (PDT)

Hi Julien,

> infrastructure nodes (MAG and LMA) belonging to a network operator.

As discussed earlier, we will allow the sending of control
messages in plain IPv4 packets. So, this mode will be supported.
We will add the config flag to enable/disable this support as
you suggested earlier.

Secondly, its not a presence of NAT that that requires UDP
mode for control packets. We require the support of native IPv6
over IPv4 translation support on the receiver to handle encap
packets natively.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 20 Aug 2008 12:32:09 -0500

Hi Sri,

> mode for control packets. We require the support of native 
> IPv6 over IPv4 translation support on the receiver to handle 
> encap packets natively.

[Ahmad]
May be you need to explain this a little more. My understanding that UDP
encapsulation is used for control messages when there is a NAT. What you
are saying here is contradictory to my understanding. Could you please
explain?

Thanks!

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Aug 2008 10:51:47 -0700 (PDT)

Hi Ahmad,

> are saying here is contradictory to my understanding. Could you please

Sorry, typo. I should have said, its not always for NAT that we require
UDP encap. Couple of points:

We were supporting IPv4 encap for the data packets.

We did not specify the vanilla IPv4 encap for control packets.
    - Most MIP control plane is implemented in user space. Use
      of L4 transport is the way to deliver the control packets
      to the application which is not in the kernel.
    - Requires a pre-configured IPv6 over IPv6 transitional support
      for the receiver to perform decap and reroute the IPv6 packet
      so the MIP6 module that registered for the MH, will receive it.
    - In IPv4 world, there are firewalls and NAT's, which may not
      be the case for 3GPP. But, this is an IETF document and we have
      to be generic.
    For these reasons, we did not see a value of supporting this mode
    for control packtets. Apparently, there is interest for this mode
    from few folks, we will add the support. We will enable this mode,
    but I will be surprised if any implementations will go for this. But,
    my word against some one else's.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 20 Aug 2008 19:55:34 +0200

Hello Sri,

>      to the application which is not in the kernel.

The not-in-kernel "application" can use raw sockets.

>      so the MIP6 module that registered for the MH, will receive it.

Not sure I understand what the problem there.

>      be the case for 3GPP. But, this is an IETF document and we have

Firewalls can be configured to let control packet pass, UDP encap or not.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Aug 2008 11:07:19 -0700 (PDT)

Hi Julien,

> The not-in-kernel "application" can use raw sockets.

Agree, thats one way.

> Not sure I understand what the problem there.

How will the IPv6 packet encapped in IPv4 gets handled on the
receiver. On all platforms, including Linux, Windows and BSD,
the support for transitional support needs to be enabled.

> Firewalls can be configured to let control packet pass, UDP encap or not.

Requires extra provisioning for deep inspection.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Aug 2008 11:13:14 -0700 (PDT)

Hi Julien,

One more comment.

>>  The not-in-kernel "application" can use raw sockets.

What will the appliction register for ? RAW IP packets of any type ?
I see its use for ICMP packets. In this case, will it register for
all IPv6 packet types ?

Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 20 Aug 2008 20:20:56 +0200

Hello Sri,

> the support for transitional support needs to be enabled.

I have no idea what that means...

> Requires extra provisioning for deep inspection.

I don't buy the firewall argument.

And aren't we supposed to use IPsec between a MAG and a LMA anyway? ;)

Then you can let IPsec thru the firewall and no deep inspection.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Aug 2008 11:25:57 -0700 (PDT)

Hi Julien,

> I don't buy the firewall argument.

Ok, if you dont have a need for this mode, fine. The config flag
will take care of it. I assume you are certain, if you happen
to implement LMA function, you will use the raw mode and will
enable IPv6/Ipv4 transitional support.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 20 Aug 2008 14:54:16 -0500

Hi Sri,

> mode for 
> >> control packets. We require the support of native
> >> IPv6 over IPv4 translation support on the receiver to handle encap 
> >> packets natively.
> >
> > [Ahmad]
> > May be you need to explain this a little more. My 
> understanding that 
> > UDP encapsulation is used for control messages when there is a NAT. 
> > What you are saying here is contradictory to my 
> understanding. Could 
> > you please explain?
> >
> 
> Sorry, typo. I should have said, its not always for NAT that 
> we require UDP encap. Couple of points:

[Ahmad]
According to DSMIP6, in an IPv4 ONLY access network, the Mobile Node is
dynamically allocated an IPv4 care of address. The Mobile Node does not
know if the allocated IPv4 care-of address is a public address, a
private address, or if there is a NAT between the mobile node and its
HA. For that reason, the mobile node MUST use UDP encapsulation when
sending the initial BU/BA. Only After the MN receives the initial BA
from its HA, it would know if there is a NAT between it and its HA or
NOT.

The case of PMIPv6 is totally different for the following reasons:
1. The MAG is not allocated a dynamic IPv4 address to be used as pCoA. 

2. The MAG should know if the IP address it has been configured with is
a private IP address or NOT.
 
3. The MAG should be aware if there is a NAT between it and the LMA or
NOT.

**** If any of the above three points is NOT true, then we need to
understand that usecase and its applicability to Netlmm.*****

4. If the MAG is supposed to support Proxy MIPv6, it also should be
assigned an IPv6 address.

Based on all of the above, I do not see any point for using UDP
encapsulation when exchanging PBU/PBA.
As I said before, the case of having a NAT between the MAG and the LMA
is a very specific special case that MUST be addressed entirely separate
from the rest of the document.

We can not afford having this issue as the default for this document. On
the contrary, that is a specific case that I personally believe would
not probably need to be addressed in this document to start with, but in
case we need to document how it can be addressed, it needs to be done
under a separate section or an Appendix.

Regards,
Ahmad

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Aug 2008 14:43:40 -0700 (PDT)

Hi Ahmad,

> from its HA, it would know if there is a NAT between it and its HA or

I though we converged on this thread, after the discussion on
the need to add raw IPv4 encap support for the signaling
messages and define a control flag. Looks like not.

Ok. So, why do we need GRE tunneling support in NETLMM ? From
the IETF perspective, we have seen just one usecase, the case
of overlapping IPv4 address space. If there are no NAT's why
is this relevant in NETLMM WG ? If 3GPP needs it, it can be
a 3GPP document. Can you explain why we should standardize
GRE support in IETF ?

I'd like to emphasise that the scope of 5213 is not to reflect
24.275 or 23.402. Its applicability is beyond 3GPP. Its certainly
valid for WiMAX, 3GPP2 and finally for enterprise mobility. We
do not have a applicability statement that the document should
not be used for enterprise mobility. Its perfectly allowed for
my enterprise to enable network-based mobility using the Proxy
Mobile IPv6 protocol. MAG need not be a SGW, but can be an IP
router, its also perfectly valid for the same functional element
to support 1918 and be using private IPv4 addresses. I understand
that this mode is not needed for some usecases and fine, we
enabled the raw IPv4 support and there is no issue for those
deployements. So, where is the issue ?

On your comment that the default mode should be no use of UDP
at all, that is just a default value for the config flag. Me
or Ryuji dont have a strong opinion, either way, its a flag and
the protocol behaviour can be controlled.

On the need for having a separate section for the modes, its
an editorial comment, we will ensure the formats are clearly
specified. In the next rev after we update, if this is not
clear, we can discuss.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 20 Aug 2008 18:05:33 -0500

Hi Sri,

Hopefully we can avoid a long discussion on this thread and conclude
quickly:)
In the mean time, I would like to mention the following:

Please remember that Netlmm wg agreed to address PMIPv6 support for IPv4
address and IPv4 transport in a separate document from base PMIPv6. I
guess there was a good reason for that. Similarly, dynamic GRE keys
exchange is addressed in a separate document, Binding Revocation, etc. 

In my mind if a deployment supports only IPv6 and IPv6 transport, that
deployment does not need to reference the IPv4 support draft. Right?

Similarly, if a deployment does not support MAG behind a NAT, they do
not need to reference the document which address that special case.

On the other hand, I am not saying that enterprise mobility using PMIPv6
is not needed or not important. However, I know one thing, all major
customers for PMIPv6 does not need the functionality of the MAG behind
NAT. Consequently, addressing that usecase in a different document than
IPv4 support document is ideal. I personally, sees that is exactly like
separating the IPv4 support from base PMIPv6 protocol.

Finally, If you agree, as seems to be the case from your response below,
to address MAG being behind a NAT in a separate section or an Appendix,
that should also be fine.

In other words, the document structure could be as follows:
1. The Major scope is focused on how to PMIPv6 support IPv4 addressing
and IPv4 transport without MAG being behind NAT.
2. A special section or an Appendix, address and captures all the text
related to the optional support of MAG being behind NAT.

If that is acceptable, then everyone is happy and those who does not
want to support MAG being behind a NAT can always clearly exclude that
draft's section.

Best Regards,
Ahmad

> is this relevant in NETLMM WG ? If 3GPP needs it, it can be a 
> 3GPP document. Can you explain why we should standardize GRE 
> support in IETF ?
> 
> 24.275 or 23.402. Its applicability is beyond 3GPP. Its 
> certainly valid for WiMAX, 3GPP2 and finally for enterprise 
> mobility. We do not have a applicability statement that the 
> document should not be used for enterprise mobility. Its 
> perfectly allowed for my enterprise to enable network-based 
> mobility using the Proxy Mobile IPv6 protocol. MAG need not 
> be a SGW, but can be an IP router, its also perfectly valid 
> for the same functional element to support 1918 and be using 
> private IPv4 addresses. I understand that this mode is not 
> needed for some usecases and fine, we enabled the raw IPv4 
> support and there is no issue for those deployements. So, 
> where is the issue ?
> 
> or Ryuji dont have a strong opinion, either way, its a flag 
> and the protocol behaviour can be controlled.
>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 20 Aug 2008 16:29:21 -0700 (PDT)

Hi Ahmad,

Ok. We have converged now. There are un-answered questions,
never mind. Lets move forward :)

W.r.t to the comment that a deployment should never see
a feature that they dont need, its not always possible.
Generally, the doc structure should ensure readability, that
should be enough for deployments to look for what they need.
Else, we have to split the IPv4 doc into two parts, transport
and addressing, which we dont want now. Any case, the raw mode
and the UDP mode will be in proper sub sections.

Thanks
Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 21 Aug 2008 23:23:03 +0900

> I see its use for ICMP packets. In this case, will it register for

Right, you cannot specify good filters only for PBU/PBA.
An application daemon might receive not only PBU/PBA but also all the  
data traffic encapsulated in IPv4-IPv6 tunnel.
There are certain overheads for this.

regards,
ryuji

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Aug 2008 16:30:15 +0200

Sri,

> I see its use for ICMP packets. In this case, will it register for

These really are implementation details that do not need to be discussed 
here. Let's leave some work for the developers :)

On the higher level issue of using a transport layer to carry mobility 
signaling vs. an extension header, the choice has been made already for 
MIPv6 and I hope we're not revisiting this here.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Aug 2008 16:33:17 +0200

> There are certain overheads for this.

The destination address of data traffic packets isn't neither that of 
the LMA, neither that of the MAG, thus the PMIPv6 stack will not receive 
those.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Aug 2008 07:48:03 -0700

> There are certain overheads for this.

??? Doesn't make sense. You can make sure only mobility header messages
(protocol 135) go to the MIPv6/PMIPv6 user process. Not every IPv6-over-IPv4
tunneled packet. This is trivial.

In fact, you shouldn't have a filter only for PBU/PBA.

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 22 Aug 2008 00:40:30 +0900

Vijay

> tunneled packet. This is trivial.

For an IPv4 encapsulated PBU, the next header must be IPv6. How can  
you specify MH ?

ryuji

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 21 Aug 2008 11:48:43 -0400

> For an IPv4 encapsulated PBU, the next header must be IPv6. How can  

For any IPv6-over-IPv4 tunneled packet, you need to first check if the
destination address on the inner IPv6 header belongs to the LMA, then
look at the next header field in the IPv6 header. If it is protocol 135,
send it to the process (MIPv6/PMIPv6) registered for that. If it is some
other protocol, do something else.

This is of course more work that using an UDP port. Nobody is disputing
that. But remember that we made a choice long time ago to use a final
protocol header for MIPv6 (and therefore PMIPv6). Not use UDP ports. 

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 22 Aug 2008 00:39:05 +0900

On 2008/08/21, at 23:33, Julien Laganier wrote:

>> An application daemon might receive not only PBU/PBA but also all  
>> the data traffic encapsulated in IPv4-IPv6 tunnel.
> The destination address of data traffic packets isn't neither that  
> of the LMA, neither that of the MAG, thus the PMIPv6 stack will not  
> receive those.

Is that destination address the inner's IPv6 header, right?
AFAIK, you cannot filter out unnecessary packets at the socket level  
by using the inner header's destination address.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 22 Aug 2008 00:54:48 +0900

> other protocol, do something else.

Well, the original question from Sri is about raw socket.
You can of course write the above code by yourself.

> This is of course more work that using an UDP port. Nobody is  

This is what I tried to point it out.
I am not disputing that, neither.
I just try to explain that use of UDP port is a bit easier.

> protocol header for MIPv6 (and therefore PMIPv6). Not use UDP ports.

The MH type is nothing to do with this thread. Remember  MH type is  
defined only for IPv6!
Our choice is either UDP port or RAW IPv4 packet here.

ryuji