Subject: Re: [netlmm] possible ipv4-support edit

From: <[email-masked]>
Date: Wed, 6 Jan 2010 18:48:52 +0100

Hi Jari,

The proposed change is a major shift in terms of the compatibility with MIP6
base protocol. 
PMIP6 is an IPv6 protocol at a fundamental level and this change essentially
results in the protocol being transformed into an IPv4 network mobility
protocol. 

I do not believe we should adopt this change.

-Basavaraj

On 11/27/09 8:24 AM, "ext Jari Arkko" <[email-masked]> wrote:

> Hi,
> 
> This document has been revised a couple of times to address IESG review
> comments. For the last few weeks its been sitting idle because we were
> trying to argue what to do with one review comment. Pasi's comment was
> that the way that it uses RFC 5555 and IPsec complicates the
> implementation considerably from what it was in RFC 5213. For instance,
> in base PMIP you were able to use a standalone IPsec implementation or
> even a separate security gateway to secure your PMIP traffic. This is
> not possible in draft -17 of the ipv4-support, because it requires an
> integrated implementation of the mobility and IPsec parts.
> 
> We have been unable to decide what the right thing is between the
> authors, chairs and ADs. We talked about this in Hiroshima in a small
> group, and decided that it is time to take this issue to the working
> group. I asked Pasi, Jonne, and Jouni to provide a suggestion on what
> the changed design is. That suggestion is available here:
> 
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18a-pasi
> -jikv3-from-7.diff.html
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18a-pasi
> -jikv3.txt
> 
> Without a concrete proposal it has been hard to determine whether a
> change is necessary and what the impacts may be. Now we have a concrete
> proposal. Is Pasi's issue serious enough that a change is warranted? Is
> the changed specification simpler and easier to implement? Are the
> changes sufficient, or would something else have to be changed as well?
> Does the change break something? Does the resulting protocol design have
> the right architecture?
> 
> I would like the WG to weigh in on whether we should (a) move forward
> with draft -17 as it is or (b) adopt this change. To be clear, Pasi has
> cleared his Discuss on the document, so we are free to choose whatever
> alternative appears best. Please respond by next week's Sunday (Dec 6th)
> by the latest. My plan is that the document is in the RFC Editor queue
> before the end of the year, no matter what the outcome of this
> discussion is. I do not plan to issue a new IETF last call due to the
> changes, but of course we are now reviewing the issue in the working group.
> 
> Jari
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Wed, 6 Jan 2010 13:19:27 -0600

Hi Jari, Pasi,

A follow up question. Why does the version edited by Pasi declare NATs out of scope? Even if you send the BU as described in section 4.2.2.1 

     IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
       ESP header (in transport mode)
         UDP header (sport=TBD1, dport=TBD1)
           Mobility Header (PBU)

you can still perform NAT detection by comparing the IP header source address with the IPv4 PCoA, right?

Also, how do you figure out when to use UDP with the data traffic?

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jari Arkko
> Sent: Friday, November 27, 2009 6:24 AM
> To: [email-masked]
> Cc: [email-masked]; Pasi Eronen
> Subject: [netlmm] possible ipv4-support edit
> 
> Hi,
> 
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-
> 18a-pasi-jikv3-from-7.diff.html
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-
> 18a-pasi-jikv3.txt
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 6 Jan 2010 11:36:54 -0800

Hi Vijay,

> you can still perform NAT detection by comparing the IP header source address with the IPv4 PCoA, right?

I don't know why they remove NAT support from the spec. I don't see technical reason for that.

> Also, how do you figure out when to use UDP with the data traffic?

The section 4.1.3.1 said: 

   o  Upon accepting the request, the local mobility anchor MUST set up
      an IPv4 bi-directional tunnel to the mobile access gateway.  The
      tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
      The encapsulation mode MUST be determined by applying the
      following considerations:

      *  If the (F) flag in the received Proxy Binding Update message is
         set to the value of (1), but if the configuration flag,
         AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of
         (0), then the local mobility anchor MUST reject the request
         with the Status field value set to 129 (Administratively
         prohibited).

      *  If the (T) flag is set to (1), or GRE Key option is included,
         see [I-D.ietf-netlmm-grekey-option].

      *  If the (F) flag in the received Proxy Binding Update message is
         set to the value of (1), then the encapsulation mode MUST be
         set to IPv4-UDP.  Otherwise the encapsulation mode MUST be set
         to IPv4.

The GRE support is suddenly appeared in this version. 
We haven't discussed to add the GRE support from this version.

regards,
ryuji

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Wed, 6 Jan 2010 13:42:43 -0600

Hi Ryuji,

>          set to IPv4-UDP.  Otherwise the encapsulation mode MUST be set

The above text depends on the flags to determine if UDP header needs to be used. In the earlier versions, the LMA could first perform NAT detection and then decide to use UDP encapsulation. That's missing.

Vijay

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 07 Jan 2010 11:25:26 +0200

Hi Raj,

Maybe you should read the discussion that has come after this mail.
Hopefully that answers your concerns and explains what's going on.

Cheers,

Jonne.

>> the changed design is. That suggestion is available here:
http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18a-pas>>
i
>> -jikv3-from-7.diff.html
http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-18a-pas>>
i

-- 
Jonne Soininen
Nokia Siemens Networks

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

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 14:24:39 +0100

Hi Vijay,

If there's a NAT between the MAG and the LMA, IPsec will detect it,
and will send the BU with UDP-encapsulated ESP (port 4500).  The NAT
will change the source address from MAG-IPv4:4500 to NAT-IPv4:X.

However, if you use IPsec only for BU/BAck, but not for user traffic,
then the user traffic will be UDP over some different port. And the LMA
needs to know the NAT mapping for this port -- but this information
isn't in the BU message.

(This is basically the same issue that caused the complexity in
DSMIPv6 -- if some traffic is over port 4500, and some over some
other port, the LMA/HA needs to know the NAT-mapped versions of
both. You can also solve this by sending a second message over
the other port, of course...) 

Best regards,
Pasi

> From: ext Devarapalli, Vijay [mailto:[email-masked]]
> Sent: 06 January, 2010 21:19
> To: Jari Arkko; [email-masked]
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: RE: [netlmm] possible ipv4-support edit
> 
> Hi Jari, Pasi,
> 
> A follow up question. Why does the version edited by Pasi declare NATs
> out of scope? Even if you send the BU as described in section 4.2.2.1
>

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 14:28:42 +0100

> We haven't discussed to add the GRE support from this version.

AFAIK the support for GRE appeared in version -10 (in March 2009). 

Best regards,
Pasi

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 07 Jan 2010 07:37:19 -0800

Yes. We did list GRE as one of the encap types when using IPv4 transport and
have the reference to the draft-ietf-netlmm-grekey draft. This was added
very early versions of the draft. Ryuji must have overlooked it ...

Sri

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Thu, 7 Jan 2010 13:08:06 -0600

Hi Pasi,

There is a simpler case. PBU and PBAck are exchanged between the MAG and the LMA with no IPsec. The initial PBU goes over the UDP. The LMA figures out if there is a NAT on the path and it tells the MAG to use UDP encapsulation for the data traffic. The same UDP port is used for both PBU/PBAcK and data traffic. 

This scenario is no longer supported.

Vijay

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 07, 2010 5:25 AM
> To: Devarapalli, Vijay; [email-masked]; [email-masked]
> Cc: [email-masked]
> > > proposal. Is Pasi's issue serious enough that a change is
> warranted?
> > Is
> > > changes, but of course we are now reviewing the issue in the
> working
> > > group.
> > >
> > > Jari
> > >

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Jan 2010 23:36:11 -0800

Folks,

We need to move forward on this. There are three other drafts that have
normative dependency on this draft and sitting in the RFC queue. And, I
really don't want this draft to beat the records established by McoA or
DSMIP6, for the time it took for standardization.

As I read it, this change suggested by Pasi, is satisfactory to many folks
and however, some folks had some concerns. But, I assume the responses from
Pasi/Jari cleared those concerns.

I want to move forward with this change and publish the updated rev in next
few days. If folks are still not satisfied with this, let us know, else we
will move forward with this change, or go for a consensus vote.

Sri

---

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

Hi,

Good point, Sri! As people are not discussing this that strongly, I think
the only possibility we have is to go for the consensus call. Then let's see
which direction it goes.

I will send a mail in a bit to start a two week consensus call.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

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

Hi Sri, Jari,

On 1/14/10 11:36 PM, "Sri Gundavelli" <[email-masked]> wrote:

> normative dependency on this draft and sitting in the RFC queue.

We have to make changes to those documents. They assume PMIPv6 control plane
messages are sent as IPv6 messages and tunneled over IPv4. For example, see
section 4 of 
http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-heartbeat-07.txt

> And, I

I haven't seen many folks supporting the change.

> Pasi/Jari cleared those concerns.

No.

Vijay

---

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

Hi Vijay,

> http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-heartbeat-07.txt

Hmm, I don't see a reason to make any changes to these documents. The mobility header is carried as an UDP payload in the proposed edit. You would construct a control plane message e.g. for heartbeat purposes using its mobility header in a same way you do PBU/PBA.

[snip]

Cheers,
	Jouni