Subject: [netlmm] possible ipv4-support edit

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Nov 2009 16:24:25 +0200

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Nov 2009 16:27:57 +0200

For what it is worth, my personal opinion is that we should make the 
change. I do not believe NATs on the MAG-LMA path are a practical 
consideration, and the new design is considerable simpler. I believe 
using IPsec gateways is important for real world deployments.

I have done a quick review of the new document, and it seems OK at a 
high level. I cannot say if there are missing things or broken details; 
I hope others on the list make more careful reviews. A couple of 
observations here though:

I'm not clear on why the MH checksum needs to be set to zero and UDP 
checksum used instead.

In Section 4.1.3.2, some text around DHCP has disappeared. I'm not sure 
it should disappear just because of this change. Was this an error?

Section 4.2.2.1 appears to downgrade the use of IPsec to protect the 
signaling messages from a MUST. I'm not sure that is appropriate. No 
matter what form of IPsec encapsulation we choose, that needs to be at 
least mandatory to implement.

Jari