Subject: Re: [netlmm] IPv4 Support

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Mar 2007 06:25:41 -0700 (PDT)

Vijay, see inline.

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: Alexandru Petrescu <[email-masked]>; Behcet Sarikaya <[email-masked]>
Cc: Jari Arkko <[email-masked]>; [email-masked]
Sent: Tuesday, March 13, 2007 1:59:43 PM
Subject: Re: [netlmm] IPv4 Support

Hello Alex and Behcet,

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?

The IPv4 home address given to the mobile node is from a shared
prefix from the LMA. There is no per-MN IPv4 prefix.

[behcet] draft-thaler-multilink-subnet-issues applies to IPv6 as well as IPv4. 
IPv4 HoA should also be per-MN prefix based according to this draft.
Besides, I don't think it is difficult to support per-MN prefixes in IPv4, just use 
10.0 addresses.

Shared prefix is out of scope currently only for IPv6 addresses
for the mobile node.

The MAG gets the IPv4 address for the mobile node from the LMA
using Proxy BU/Proxy BAck messages. After that the address is
assigned to the mobile node using DHCP.

Hope that clarifies.

Vijay

Alexandru Petrescu wrote:
> Jari Arkko wrote:
>> Behcet,
>>> Do you mean the netlmm protocol for IPv4, i.e. a mobile node with no 
>>> mobility client gets IPv4 level mobility services or do you mean
>>>  the netlmm protocol that supports IPv6 hosts but that also can carry 
>>> IPv4 traffic of a dual stack MN
>>
>> I was mostly thinking of supporting IPv4 hosts. But don't take this as 
>> an instruction on what to do. I sent the mail mainly to say what you 
>> can and cannot do; its up to the group to figure what you want to
>>  do.
> 
> Talking to the group:
> 
> I think DS-MIPv6 inserted in PMIPv6 has some issues supporting IPv4 hosts.
> 
> In some way, yes, both current draft-sgundave PMIPv6 and draft-singh
> support IPv4 hosts.  Both drafts say the IPv4 address for MN is assumed
> to be its Home Address, and a P-BU (proxy BU) is sent by MAG to LMA and
> contains the IPv4 Home Address.
> 
> In some other particular way, IPv4 host support is a bit more difficult
> to understand.
> 
> draft-sgundave seems to try to assume that only prefix-per-MN should be
> considered (not shared prefixes), by most recent trends.  Or, an IPv4 
> prefix-per-MN is little feasible in the public routable address space - 
> it must be NAT.  But, draft-sgundave doesn't say explicitely that _if_ 
> the IPv4 Host has an IPv4 Home Address then that address MUST be a 
> private IPv4 address.  But logically it can be deduced so.  So, can I 
> deduce that _only_ private IPv4 Hosts are needed by PMIPv6?
> 
> Also, with draft-sgundave, address autoconfiguraiton is assumed to be
> mainly SLAAC (stateless, RS/RA) and less DHCP.  Or, IPv4 towards an IPv4
> host can not be SLAAC.  So, logically it should be either PPP, IPv4
> Stateless, or DHCPv4.  Out of these, PMIPv6 talks mostly DHCP.
> 
> DS-MIPv6 (a feature of MIP6 re-used in PMIPv6) has an IPv4 host to 
> include 0.0.0.0 in BU to request an IPv4 address allocated from HA.  For 
> PMIPv6, this would mean the AR (not the Host) sends this 0.0.0.0 P-BU. 
> But how does the AR know that the attached IPv4 host _needs_ an IPv4 
> address?  Moreover, how does the AR know that the DHCP didn't allocate 
> already an IPv4 address to the IPv4 host?
> 
> The relevant paragraphs in draft-sgundave:
>> When a mobile node attached to a mobile access gateway sends a DHCP 
>> request, the network will ensure it gets an IP address from its home 
>> address prefix.
> 
> Ok up to here.  So the AR will relay the request to DHCP Server and the 
> DHCP Server makes sure it gets an IP address from its home address prefix.
> 
>> The mobile access on the access link where mobile node is attached, 
>> will register this address with the local mobility anchor using the 
>> IPv4 Home Address option, defined in Section 3.1.1, DSMIP6 draft 
>> [draft-ietf-mip6-nemo-v4traversal-03.txt].
> 
> Ok, but how does this  "mobile access" know the IPv4 Home Address, when
> that address is currently to be allocated by DHCP.  Who is "mobile 
> access"?  Or typo maybe, sorry?
> 
>> Upon receiving the Proxy Binding Update Message with this IPv4 Home
>> Address option, the local mobility anchor is required to apply the
>> processing rules as specified in DSMIP6 draft.  Further, if the
>> received option has a value set to 0.0.0.0, the local mobility anchor
>> needs to consider this as a request for an IPv4 Home Address
>> allocation and must return the allocated value in the IPv4 Home
>> Address option carried in the Proxy Binding Acknowledgement.
> 
> At this point, how does the "local mobility anchor" know that it has 
> allocated an address that is _exactly_ the same as the address allocated 
> previously by DHCP?
> 
> So, with this in mind, I'm not requesting updating any draft.
> 
> I am requesting comments on these problems, Vijay?
> 
> Alex
> 
> 
>>
>> Jari
>>
>>
>>
>> _______________________________________________ netlmm mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>>
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Mar 2007 12:27:20 -0700

Hello Behcet,

Behcet Sarikaya wrote:
> [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.

> IPv4 HoA should also be per-MN prefix based according to this draft.

The updated document is draft-iab-multilink-subnet-issues-03.txt
I don't think the issues apply here, since there is no notion of
a tunnel from the mobile node to the home agent. There is no
notion of a single IPv4 subnet being shared across multiple
virtual tunnels (or multiple links) between the mobile node and
LMA.

> Besides, I don't think it is difficult to support per-MN prefixes in 

I don't think we should use private addresses for the IPv4 home
addresses. It is not required.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 20:52:58 +0100

> its IPv4 traffic might be tunneled over an IPv6 tunnel between

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.

> virtual tunnels (or multiple links) between the mobile node and

I think this is too quick discarded...

We may have IPv4 multi-link subnet issues with the IPv6-in-IPv4 tunnels 
between MAG and LMA (not MN).

It is not clear at all how ARP runs over the IPv4 subnet shared across 
multiple virtual links and how multicast over it.

It may be we want to ignore these issues for fast progress though(?).

> addresses. It is not required.

I agree requiring private IPv4 addresses is not good to require.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Mar 2007 13:24:18 -0700

> encapsulating with IPv6?  Sorry, I may miss something.

There is no double encapsulation. It will either be IPv4-in-IPv4
or IPv4-in-IPv6.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 21:44:17 +0100

Vijay Devarapalli wrote:
>> (between MAG and LMA) and into another IPv4 packet (the IPv6-in-IPv4 
>> of DS-MIPv6)?
>>

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?

And I'd like this separated, but I said this many times, I think you know.

Alex

>> We may have IPv4 multi-link subnet issues with the IPv6-in-IPv4 
>> tunnels between MAG and LMA (not MN).
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Mar 2007 13:47:22 -0700

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

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 22:12:41 +0100

Vijay Devarapalli 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.
>>>> 
>>>> 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.
>>> 
> 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