Re: [netlmm] possible ipv4-support edit

Hi Vijay,

On 2010/01/06, at 11:19, Devarapalli, Vijay wrote:

> 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?

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

> 
> Vijay
> 
>> -----Original Message-----
>> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On
>> Behalf Of Jari Arkko
>> Sent: Friday, November 27, 2009 6:24 AM
>> To: netlmm@ietf.org
>> Cc: jouni.korhonen@nsn.com; Pasi Eronen
>> Subject: [netlmm] possible ipv4-support edit
>> 
>> 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
>> netlmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/netlmm
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm