Re: OnDemand draft: 3 address types discussion

Hi Danny,

Thank you for continuing the discussion on the 3 address types.


Le 03/05/2016 à 14:27, Moses, Danny a écrit :
>
> This is in reply to comments we received from Behcet and Suresh
> regarding the three types of addresses define in the draft. Suresh
> commented that the ‘Fixed IP address’ is not necessary and
> application only require to select Sustained or Nomadic IP addresses
>  and Behcet commented that the ‘Sustained IP address’ is not needed
> and not well define due to the fact that the draft does not define
> how to identify the end of an IP session (will be discussed in a
> separate email).

To me, the problem in the definitions shown in the Buenos Aires slide 4
https://www.ietf.org/proceedings/95/slides/slides-95-dmm-2.pdf
is that they dont relate to each other.  This makes that a FIXED address
could be a SUSTAINED could be a NOMADIC.

For example, a FIXED 'exists no matter where the host moves to', and a
SUSTAINED 'is valid as long as the IP session is alive'.  One does not
exclude the other.  You could have an address be NOMADIC and SUSTAINED
at the same time ('exists no matter where the host moves to' and 'valid
as long as the IP session is alive').

A definition which relates them would keep the FIXED to be 'exists no
matter where the host moves to' and NOMADIC to be 'changes in certain
places where the host moves to'.

Thus, this improved definition would not allow a FIXED _and_ NOMADIC at 
the same time.

> We have gave more thought to these types and concluded that the
> definitions in the spec were confusing. We are providing new text in
> the new version, hoping they are more clear.

Let me see whether I can understand.

> We re-evaluated whether to stay with the definition of three IP
> address types or move to a two IP address type scheme and eventually
>  concluded that it is better to stay with the three type
> alternative.

A-ha.

> We hope that the better text in the new draft version will clarify
> and here are some additional inputs:


> Nomadic IP address (or in its new name: Non-persistent IP address):
> Clearly this type is useful for all applications that do not require
> any IP session continuity guarantee from the network and wish to
> avoid the overhead introduced by the network as part of that
> guarantee (inefficient routes, tunneling etc…).


> Sustained IP address (or in its new name: Session-lasting IP
> address): This is our accurate definition for the IP session
> continuity service that some application require and is similar to
> what is provided today by default, by mobile operators via GTP or
> PMIP.

These two definitions relate more to each other than the earlier
definitions, by the application requirements.

Yet, some questions arise:

The apps which don't require a session-lasting IP address can obviously 
work with a session-lasting IP address too.  So some of the 
session-lasting IP addresses can be non-persistent IP addresses?

The apps which require a session-lasting IP address wish to introduce
overhead in the network?

Mobile operators using GTP or PMIP do not provide non-persistent IP
addresses?

> Basically, current implementations provide  a guarantee for the
> source IP address to be valid throughout the time the mobile host is
> connected to the mobile network. We concluded that mobile hosts do
> not really require such a guarantee. It is sufficient to require a
> guarantee of the IP address availability while there is/are an IP
> session(s) using this IP address and hence the more accurate
> definition.

I dont understand.

Until here the app requirements where important.  Now we change to make
the mobile host to be important(?)

> Furthermore, some WG members have shown cases in DMM where it is
> more efficient for applications to request a new Session-lasting IP
> address when launched rather than using an existing one that was
> allocated to the mobile host in the past.

Well, I wonder about this.

In the environments I work I never saw an application (e.g. a browser)
to request an IP address.  It is the connection manager which deals with
address configuration.  This connection manager is not in contact with
other applications like web browsers.

> This is due to possible movement of the mobile host to a LAN which is
> being served by a mobility anchor that is different from the one that
> was used when the older Session-lasting IP address was assigned to
> the mobile host. Fixed IP address (no renaming …): We believe that
> this is where our original text was the most unclear leading to the
> confusion on the mailing list and the comments from the flour.

> A Fixed IP address is guaranteed by the network to Always be valid,
> even if the mobile host is not utilizing any IP sessions, or has been
> disconnected from the network for some time. This is a special
> service that mobile network operators provide for a premium charge,
> for servers, VPNs , secured content and other applications. With this
> IP address type the network operator provide IP address reachability
> in addition to IP session continuity, and mobile hosts may register
> these addresses in DNS infrastructure for name resolution.

I can understand the intention of the fixed IP address definition.

But I wonder whether there can be an improved definition of a fixed IP
address.  Because of the following:

A 'fixed' IP address, as much as it can be guaranteed by an operator at
a premium cost, will not be possible if moving to a more remote area:
for example, when moving from US to Europe can not maintain that fixed 
IP address even if it is paid a very high price.

> Clearly, most mobile hosts do not require Fixed IP

Again: _mobile hosts_  require?  Or apps require?

A more coherent definition can take advantage of using only app
requirements, or only mobile host reqs, or both but everywhere (i.e.
each of the 3 types of addresses relates to both MH reqs and to app reqs).

> addresses and their owners will not pay the premium cost for this
> service, but still, it is a service that mobile operators provide
> and this is enough proof for us to acknowledge its need.


> Please see some examples

Thank you very much for these pointers.  This makes it easier to 
understand the intention.

> from AT&T -
> _https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp_,

Is this IPv4 only?

 > Verizon -
> _http://www.verizonwireless.com/businessportals/support/features/data_services/static_ip.html_

Is this IPv4 only?

 > Sprint -
> _https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink_and_static_ip/index.html#.VxC7xSN9480_

Is this IPv4 only?

I am asking the IP version question because address configuration is 
very different in IPv6 than IPv4.

For example, in IPv6 the network does not assign an address to a host 
(as in IPv4 is done with context setup), but advertises a prefix to a 
link and the host forms an address.  In such a context the potential 
mechanism to achieve static IP addresses is very different - not only 
the network is in charge but the terminal too.

Moreover, whereas in IPv4 cellular networks the mechanism to achieve 
static IP address is standardised (NAI, PDP context setup, ppp), in IPv6 
there is no such mechanism standardised nor deployed.

Is there an example of deployed static IPv6 addresses in cellular 
networks? (as the IPv4 example of AT&T, Verizon, Sprint).  That would be 
very relevant too.

Alex