Re: [netlmm] IPv4 Support

Vijay Devarapalli wrote:
> Alexandru Petrescu wrote:
> 
>>>>>> draft-sgundave-mip6-proxymip6-02 also provides support for 
>>>>>> an IPv4-only mobile node. The mobile node need not have a 
>>>>>> dual stack. See section 5.6.
>>>>>> 
>>>>>> [behcet] You mean, HA is going to cheat MN and act as if MN
>>>>>>  is dual stack? while it is in reality not so? What?
>>>>> 
>>>>> I don't understand your question. The mobile node that 
>>>>> supports IPv4 only will continue to use IPv4. It is not aware
>>>>>  of the fact that there is PMIPv6 being used in the network
>>>>> or the fact that its IPv4 traffic might be tunneled over an
>>>>> IPv6 tunnel between the MAG and the LMA.
>>>> 
>>>> Double-encapsulation for IPv4 Host?
>>>> 
>>>> Would make sense to tunnel an IPv4 packet from MN into an IPv6 
>>>> tunnel (between MAG and LMA) and into another IPv4 packet (the 
>>>> IPv6-in-IPv4 of DS-MIPv6)?
>>>> 
>>>> If the Host is IPv4, and the network between MAG and LMA is 
>>>> IPv4, why encapsulating with IPv6?  Sorry, I may miss 
>>>> something.
>>> 
>>> There is no double encapsulation. It will either be IPv4-in-IPv4
>>>  or IPv4-in-IPv6.
>> 
>> For IPv4, this is not clear at all to me.  Which IPv4-in-IPv4 
>> encapsulation method?  GRE?  "IP-in-IP" RFC2003?  "Minimal" 
>> rfc2004?
>> 
>> Neither DS-MIPv6 nor PMIPv6 seem to say, IMHO.
>> 
>> Or maybe any that is available?
> 
> See the discussion on Issue 93 on the MIP6 mailing list. This will be
>  done as part of the DS-MIPv6 spec. It would be a good idea to just 
> re-use it for PMIPv6.

Yes, re-use would be fine.

The issue 93 raised by Sri (followed by MIP6 discussion):
>> For the IPv4 transport and with NAT in path, the opaque 
>> encapsulation mode of IPv4-UDP for both IPv4 and IPv6 payload
>> packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being recommended by
>> the draft. With out a payload qualifier in the UDP header, I wonder
>> how the tunnel peer handles the packet after decapsulation ? How
>> would it know, if it is an IPv4 payload packet or an IPv6 packet ?
>> Do you expect some packet inspection after decapsulation ?
>> 
>> One option is to have thin header such as the MIP Tunnel Data
>> Message from RFC-3519, as suggested by Kent Leung.

The issue talks mostly IPv4-in-UDPv4 (not IPv4-in-IPv4).  The suggested
resolution uses a new thin header, but still preceding UDPv4.

Or, UDP is mainly proposed in DS-MIPv6 for NAT Traversal reasons.  Ie,
DS-MIPv6 says (in some way) that if there's no NAT then no UDP; and
here's no NAT between MAG and LMA.

So I don't think this way of solving the issue in DS-MIP6 makes sense
for PMIPv6.  I don't think the rfc3519 header inserted between IPv4 and
UDP headers helps solve any issue here.  Because using UDP is simply not
needed because no NAT in between.

What do you think?  Which IPv4-in-IPv4 (no UDP) should PMIPv6 use?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm