Subject: [v6ops] Cellular Host - a misnomer? draft-binet-v6ops-cellular-host-requirements-02.txt and draft-ietf-v6ops-rfc3316bis-00

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 03 Feb 2013 19:04:33 +0100

Please let me allow a generic comment about

draft-binet-v6ops-cellular-host-requirements-02.txt
   "IPv6 Requirements for Cellular Hosts" and about
draft-ietf-v6ops-rfc3316bis-00
   "IPv6 for 3GPP Cellular Hosts"

In short,  I think the term Cellular Host is a reductionist,
conflict-generating misnomer, of what is described in the documents.

To avoid this, and to clarify, I tend to suggest to avoid 'cellular
host' to profit a Host-IMP-Router kind of definition.  And put the
relevant requirements specific on these parts - either on the Host or on
the IMP or on the Router.

In detail, my reading is that although one of the documents tries to
clarify this (draft-ietf calls a cellular host a host with a cellular
interface) the spirit of what seems to be described in both documents is
a smartphone, or a 'mobile device' (draft-ietf puts reqs only on
cellular hosts, not on interfaces).

And this smartphone view has some problems.

1. One problem I struggle with, and exposed in some public discussions,
    is that the 64share technique is able to work only when certain
    requirements of the 3GPP Gateway and the USB cellular interface
    satisfy.  E.g. that neither the 3GPP Gateway, nor the USB cellular
    interface, MUST not send NS for any address in the announced /64
    range.  IF any of these two happens, the 64share method won't work.
    In practice we identified that this happens with a particular
    combination of network operator and bran dof USB LTE key.

    We need to avoid that situation in order for 64share to work.  We
    need to put requirements on the 3GPP Gateway (do not send NS) and on
    the USB cellular interface (do not send NS, nor pretend or fake NSs).

    If not a requirement, then maybe a statement that declares that if
    either the Gateway or the USB interface sends an NS then the 64share
    won't work.

    But where could we express that requirement/statement?  It is not a
    requirement for the Cellular Host per se.

2. Typically a Host has a single interface.  When that interface is
    Cellular and runs IP, the Host actually has more than just a cellular
    interface.  E.g. a typical smartphone.  That "cellular host" is also
    a "WiFi STA" at the same time, or a "bluetooth node".  And at times
    it becomes a Router with e.g. 64share.

    It is very hard to put IP Requirements entirely on the Cellular Host
    when what we want is only requirements on the Cellular interface
    part.

    A Host with multiple interface is dealt with in MIF WG.  There
    they're also seen as mostly the 'mobile device'  or the
    'smartphone'.  It has some RFC and active WG I-Ds which pertain to
    this discussion (DNS server selection, DHCP route option, to name a
    few).  These techniques should be integrated here, I think.

3. Maybe the only Cellular Hosts (i.e. a Host running IP and having a
    single interface which is cellular) is represented by some of
    smallest autonomous M2M Modules.  E.g. sierra wireless M2M modules.

    And surprisingly these 'pure' Cellular Hosts are put out of scope by
    draft-binet-v6ops-cellular-host-requirements-02.  But these may be
    the only devices which may be qualified as 'pure' cellular hosts.

4. The USB keys which are cellular interfaces and made to be plugged on
    laptops obviously would not qualify as Cellular Hosts.  Although
    their CPU/MEM is relatively powerful enough to run IP, they're not
    autonomous - they're the 'IMP' of a Host.

Other examples of this problem follow.

Example: REQ#10 of draft-binet says "The cellular host SHOULD embed a
DHCPv6 client".

But should this be implemented in the USB key?  Or in the Host whose
cellular interface is it?

Example: REQ#12 of draft-binet says "REQ#12:  The cellular host SHOULD
implement the Customer Side Translator function".

But if I use a big Mobile Router whose one single interface cellular
(the others are wifi, bluetooth, .15.4, .11p, RS232 SLIP, USBnet -
nothing to do about Customer Side) - should it still implement Customer
Side Translator function?

Other examples:
> The DNS server configuration is learned from 3GPP link layer
> signaling.  However, the cellular host should also implement the IPv6
> Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6
> is still optional for cellular hosts, and learning the DNS server
> addresses from the link layer signaling can be cumbersome when the MT
> and the TE are separated using other techniques than PPP interface.

But we know that if that cellular Host is a router with a cellular
interface then it should use _only_ DHCP to obtain the DNS address.  It
can't use RA for that because it's a Router.

> For the purposes of this document, IP mobility is not relevant.

The IP mobility (aka Mobile IP protocol) is irrelevant only for the
'pure' cellular hosts, i.e. these M2M cellular-only devices.  All the
other cellular-enabled devices may need Mobile IP.

> The movement of cellular hosts within 3GPP networks is handled by
> link layer mechanisms in majority of cases.

YEs, I agree mobility in 3GPP is handled by link layer mechanisms.
Often the term GTP comes up and could be mentioned.

But it is not the reason why cellular-enabled Hosts don't run Mobile IP.
  It is because a majority of their sessions are such that they can be
handed over from iface to another without needing continuous sessions
(e.g. bursty http transactions are probably the most used app on
smartphones).

These hosts are multiply-ifaced Hosts which is ok and deserves mentioning.

> 3GPP Release-8 introduced the dual-stack Mobile IPv6 (DSMIPv6) for a
>  client based mobility [RFC5555].  Client based IP mobility is
> optional in 3GPP architecture.

I think 3GPP should be notified about a number of shortcomings of
RFC5555 (compared to the simultaneous use of MIP4 and MIP6).

I think it is not right to invoke 3GPP documents here when many
oppinions expressed at IETF are that RFC5555 has probably several
competitors.

For example, 3GPP documents could mention Mobile IPv4 simultaneous with
Mobile IPv6 to achieve mobility, optionally.

> o  The host can be a "closed" device with optimized applications,
> with no possibility to add or download applications that can have IP
>  communications.  An example of such a host is a very simple form of
> a mobile phone.

Sorry - which is that device?  Qualifying them as 'open' or 'close'
without saying with respect to whom is not clear.

A very simple form of a mobile phone?  The smallest Mobile Phone
(e.g. simvalley) is not running IP.  And, the simplest form of an M2M
autonomous cellular device is not a phone either.

> o  The host can be an open device, e.g., a "smart phone" where it is
> possible to download applications to expand the functionality of the
> device.

A smartphone is more than just being open.  It is a complete platform
which most if not all times has more than a cellular interface (it has
cellular and wifi/bluetooth).  Is this a cellular Host?  I doubt.  It is
a MIF host.

> o  The cellular radio modem part can be separated from the host IP
> stack with an interface.  On example of such host is a laptop
> computer that uses a USB cellular modem for the cellular access.

I agree.  But there seem to be cases where that separation is not so
clearcut.  Some USB cellular modem interfaces appear to be generating IP
messages.  The requirements in this document apply to the radio modem?
Or to the USB HOST (Host has double meaning when we talk USB and IP at
the same time).

> If a cellular host has additional interfaces on which IP is used,
> (such as Ethernet, WLAN, Bluetooth, etc.) then there may be
> additional requirements for the device, beyond what is discussed in
> this document.

Should these requirements converge?

Regards,

Alex