Subject: Re: [netlmm] IPv4 Support

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 13 Mar 2007 08:51:05 -0700 (PDT)

Dear Jari,
  I could not get a clear picture from your mail on what you mean by IPv4 support. 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 (such as in draft-sgundave)?
Regards,

Behcet

----- Original Message ----
From: Jari Arkko <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 13, 2007 8:03:03 AM
Subject: Re: [netlmm] IPv4 Support

Hi all,

I wanted to explain my point of view on this matter.

First, I would personally like to see a protocol that is capable of
dealing with both IPv6 and IPv4. I think that will have a significant
impact on how widely the protocol can be deployed. And reduce problems
going forward with the support of multiple solutions for different IP
versions.

The group is not currently chartered to deal with the IPv4 part (but see
below). And I'm not necessarily ready to expand it just yet. However, I
have said in the past that once you are a bit further ahead, adding the
IPv4 to the charter is not a problem at all. I also brought this up in
the IESG back when DSMI BOF proposal was under consideration.

Nevertheless, what I told Vidya is that even with the current charter I
do not have a problem if the document supports IPv4 as well, assuming
some conditions are fulfilled.

The charter text is not arbitrary, it was written with specific
management goals in mind. In particular, the ability to complete work in
a timely manner. But it should not prevent making the right engineering
decisions, or documenting how the protocol works together with other
Mobile IPv6 extensions. For instance, I think it is fine for the
specification to say that via RFC XXXX the Netlmm protocol can run over
IPv4. So my condition for you to include IPv4 support in the base
document is that you can do it without the development of a lot of new
mechanisms or the addition of complex logic. If you can satisfy this
condition its not a problem. If you cannot, I would suggest a separate
spec and a charter extension at the same time as the base spec comes to
the IESG.

I would also like to underline what Vidya said about the nature of this
question in the WG -- this is not an opportunity to revisit previous
design decisions. And that you shouldn't tie all specific technical
questions to the selection of a particular draft. You should choose the
best draft to work on, obviously, but at the same time you will have N
technical questions that you need to decide. Such as the question about
IPv4. The results of those decisions will have to be edited into the
next revision of draft that you decide to work on.

Jari

_______________________________________________
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: Jari Arkko <[email-masked]>
Date: Tue, 13 Mar 2007 19:25:53 +0200

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.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2007 19:11:58 +0100

cet<br><br><div style=3D"font-family: times new roman,new york,times,serif;=
 font-size: 12pt;">----- Original Message ----<br>From: Jari Arkko &lt;jari=
[email-masked]&gt;<br>To: Behcet Sarikaya &lt;[email-masked]&gt;<br>Cc=
: [email-masked]<br>Sent: Tuesday, March 13, 2007 12:25:53 PM<br>Subject: =
Re: [netlmm] IPv4 Support<br><br><div>Behcet,<br>&gt;&nbsp;&nbsp;Do you mea=
n the netlmm protocol for IPv4, i.e. a mobile node with no<br>&gt; mobility=
 client gets IPv4 level mobility services or<br>&gt; do you mean the netlmm=
 protocol that
 supports IPv6 hosts but that also<br>&gt; can carry IPv4 traffic of a dual=
 stack MN<br><br>I was mostly thinking of supporting IPv4 hosts. But don't =
take this as<br>an instruction on what to do. I sent the mail mainly to say=
 what you can<br>and cannot do; its up to the group to figure what you want=
 to do.<br><br>Jari<br><br><br></div></div><br></div></div></body></html>
--0-1990592082-1173809543=:27166--

--===============2128334687==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============2128334687==--

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2007 19:11:58 +0100

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 
______________________________________________________________________

[email-masked]

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 13 Mar 2007 11:59:43 -0700

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.

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2007 20:06:56 +0100

> Shared prefix is out of scope currently only for IPv6 addresses

So can one say PMIPv6 does shared-prefix for IPv4 but prefix-per-MN for 
IPv6?

> assigned to the mobile node using DHCP.

How does  DHCP implementation on MAG know to _not_ do DHCP?

This is what you imply: LMA gets DHCP request and then obtains the IPv4 
address with PBU/PBAck.

Alex

>> 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?
>>
>> 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?
>>
>> 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.
>>
>> allocated an address that is _exactly_ the same as the address 
>> allocated previously by DHCP?
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 13 Mar 2007 12:14:15 -0700

> So can one say PMIPv6 does shared-prefix for IPv4 but prefix-per-MN for 

Yes. That is what is assumed in draft-sgundave-mip6-proxymip6-02 currently.

> How does  DHCP implementation on MAG know to _not_ do DHCP?

I don't understand this question.

> This is what you imply: LMA gets DHCP request and then obtains the IPv4 

The DHCP request does not go to the LMA. Only upto the MAG. Proxy 
BU/Proxy BAck is used between the MAG and the LMA.

Vijay

>>> the DHCP Server makes sure it gets an IP address from its home 
>>> address prefix.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2007 20:27:52 +0100

Vijay Devarapalli wrote:
>> So can one say PMIPv6 does shared-prefix for IPv4 but prefix-per-MN 
>> for IPv6?
> 

Well who does DHCP DISCOVER?  MN.  Who does DHCP ACK?  MAG.

How does MAG know to _not_ relay the DISCOVER to DHCP Server and do 
P-BU/BAck instead?  Is that a DHCP modification?  Shouldn't that be made 
clear that PMIPv6 requires DHCP modifications?

>> This is what you imply: LMA gets DHCP request and then obtains the 
>> IPv4 address with PBU/PBAck.
> 

How does MAG _know_ to _not_ send the DHCP Request received from MN?  A 
DHCP implementation _does_ forward the DHCP Request.  Provided it's a 
DHCP Relay, of course.  I hope both you and me assume the MAG is a DHCP 
Relay.

Besides, it's not the DHCP Request that MAG receives first, it's the 
DHCP DISCOVER.  It's upon DHCP DISCOVER that MAG should act, not upon 
DHCP Request.

Alex

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 13 Mar 2007 12:41:10 -0700

Hi Alex,

Instead of trying to answer your email point-by-point we 
will try to put out a call flow for this.

Vijay

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 12:28 PM
> To: Vijay Devarapalli
> Cc: Alexandru Petrescu; Behcet Sarikaya; Jari Arkko; [email-masked]
> > Yes. That is what is assumed in 
> draft-sgundave-mip6-proxymip6-02 currently.
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2007 20:55:15 +0100

Vijay Devarapalli wrote:
> Hi Alex,
> 
> Instead of trying to answer your email point-by-point we will try to 
> put out a call flow for this.

If you continue doing this (update draft-sgundave based on my remarks) I
will remark the following:

We have an MN-AR document talking DHCP.  A WG document.  Shouldn't that
work in tandem with your understanding of how DHCP is supposed to work?

If you feel such an urge to update your draft, you can add a reference
entry to MN-AR document, only that, no text.  It's natural, it's a WG item.

Please stop updating your draft before any consensus asked you to do so.

Alex

---

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

Alex,

I was going to send the call flow to the mailing list.

There are no updates going into draft-sgundave-mip6-proxymip6
this week.

Vijay