Re: [netlmm] IPv4 Support

Hi Vijay,
  First of all, I like IPv4 related text in draft-sgundave but I also think that IPv4 is an extension issue, it is not base PMIPv6 functionality.

For the rest, please see inline.

Regards,

Behcet
----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@AzaireNet.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: netlmm@ietf.org
Sent: Wednesday, March 14, 2007 2:27:20 PM
Subject: Re: [netlmm] IPv4 Support

Hello Behcet,

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

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.
[*behcet*] Are you saying that IPv4 support in PMIPv6 protocol is going to solve the problem and if someone, e.g. SDO x asks for PMIPv4 then we can say use this one?

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

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.
[*behcet]* I am not sure on this, I see no difference. We might need expert opinion to be sure. What is wrong with using 10.0 addresses?

> Besides, I don't think it is difficult to support per-MN prefixes in 
> IPv4, just use
> 10.0 addresses.

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

Vijay

> 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
>  >> netlmm@ietf.org 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
>  > netlmm@ietf.org
>  > https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 