INTERNET-DRAFT Jari Arkko
Internet Engineering Task Force Peter Hedman
Issued: September 21, 2001 Gerben Kuijpers
Expires: March 21, 2002 Ericsson
John Loughney
Pertti Suomela
Juha Wiljakka
Nokia
Minimum IPv6 Functionality for a Cellular Host
<draft-manyfolks-ipv6-cellular-host-01.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
As an increasing number of cellular hosts are being connected to the
Internet, IPv6 becomes necessary. Examples of such hosts are GPRS,
UMTS, and CDMA2000 terminals. Standardization organizations are also
making IPv6 mandatory in their newest specifications, such as the IP
multimedia terminals specified for UMTS. However, the concept of
IPv6 covers many aspects, numerous RFCs, a number of different
situations, and is also partly still evolving. A rapid adoption of
IPv6 is desired for cellular hosts. Yet these terminals vary greatly
in terms of their processing capabilities and task orientation.
Cellular host software often cannot be upgraded, yet it must meet
tough demands for interoperability with other hosts, the cellular
network, and the Internet. For these reasons it is necessary to
understand how the IPv6 deployment starts and which parts of IPv6
are necessary under which situations. This document suggests basic
IPv6 functionality for cellular hosts, and discusses when parts of
the functionality is needed, and under which conditions.
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
Abstract ............................................................1
1 Introduction ......................................................4
1.1 Abbreviations ..................................................6
1.2 Requirement Language ...........................................6
1.3 Cellular Host IPv6 Features ....................................6
2 Core IP ...........................................................6
2.1 RFC1981 - Path MTU Discovery for IP Version 6 ..................7
2.2 RFC2373 - IP Version 6 Addressing Architecture .................7
2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format ......7
2.4 RFC2460 - Internet Protocol Version 6 ..........................7
2.5 RFC2461 - Neighbor Discovery for IPv6 ..........................8
2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration .............8
2.7 RFC2463 - Internet Control Message Protocol for the IPv6 .......9
2.8 RFC2472 - IP version 6 over PPP ................................9
2.9 RFC2473 - Generic Packet Tunneling in IPv6 Specification .......9
2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 .........9
2.11 RFC2711 - IPv6 Router Alert Option ............................9
2.12 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers ....9
2.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6 ........10
2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds .........10
2.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ........10
2.16 Default Address Selection for IPv6 ...........................10
2.17 DNS ..........................................................11
2.18 Security Issues ..............................................11
3 IP Security ......................................................11
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication ......13
3.2 RFC2401 - Security Architecture for the Internet Protocol .....13
3.3 RFC2402 - IP Authentication Header ............................13
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH ............13
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH ............13
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV ...14
3.7 RFC2406 - IP Encapsulating Security Payload (ESP) .............14
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP .............14
3.9 RFC2408 - ISA and Key Management Protocol .....................14
3.10 RFC2409 - The Internet Key Exchange (IKE) ....................14
3.11 RFC2410 - The NULL Encryption Algorithm and its Use With IPsec14
3.12 RFC2411 - IP Security Document Roadmap .......................14
3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms .................15
3.14 IP Security Remote Access ....................................15
3.15 The AES Cipher Algorithm and Its Use With IPsec ..............15
3.16 ICMPv6 and Its Effect to IKE and IPsec Policies ..............15
4 IP Mobility ......................................................15
4.1 Mobility Support in IPv6 ......................................15
4.2 Fast Handovers for Mobile IPv6 ................................16
4.3 Hierarchical MIPv6 Mobility Management ........................17
4.4 Mobile IP Security ............................................17
5 Security Considerations ..........................................17
6 References .......................................................19
7 Acknowledgements .................................................22
8 Authors' Addresses ...............................................22
Manyfolks [Page 2]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
Appendix A Cellular Host IPv6 Addressing in the 3GPP Model .........23
Appendix B Transition Issues .......................................25
Manyfolks [Page 3]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
1 Introduction
Technologies such as GPRS (General Packet Radio Service), UMTS
(Universal Mobile Telecommunications System), and CDMA2000 are
making it possible for cellular hosts to have an always-on
connection to the Internet. IPv6 becomes necessary, as it is
expected that the number of such cellular hosts will increase
rapidly. Standardization organizations working with cellular
technologies have recognized this, and are making IPv6 mandatory in
their newest specifications. One example of this is that 3GPP
specifies IPv6 support as mandatory for future UMTS IP multimedia
terminals.
The purpose of this draft is to propose a compact set of IPv6
specifications and functionality that cellular hosts must support.
Such a specification is necessary in order to determine the optimal
way to use IPv6 in a cellular environment. Important considerations
are how to minimize footprint and implementation effort for a large
number of consumer terminals, eliminate unnecessary user confusion
with regards to configuration options, ensure interoperability and
to provide an easy reference for those implementing IPv6 in a
cellular host. The overarching desire is to ensure that cellular
hosts are good citizens on the Internet.
The main audiences of this document are the implementors who need
guidance on what to implement, the IETF that wants to ensure a well-
working global IPv6 network, and other standardization organizations
that need a reference to how IPv6 can be mandated on their
standards.
For the purposes of this document, a cellular host is considered to
be a terminal which uses a cellular air interface (i.e. GPRS, UMTS,
CDMA2000) to connect to a cellular access network in order to
provide IPv6 connectivity to an IP network. The functionality to
provide this connectivity is outlined in this draft. The description
is made from a general cellular host point of view, and this
document is intended to be applicable for many types of cellular
network standards (or even multi-standard devices). In some cases
known exceptions and special cases are however documented for
specific cellular networks such as the UMTS, as examples and
additional information for the reader.
Parts of this document may also be applicable in other, non-cellular
contexts, such as small IPv6 appliances with similar size and cost
restrictions. The scope of thisdocument, however, is the cellular
hosts and it may not cover all issues relevant in those other
contexts.
The use of IPv6 within cellular networks implies an implementation
of the IPv6 stack within a wide range of terminals. Such terminals
may vary significantly in terms of capacity, task orientation and
Manyfolks [Page 4]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
processing power. For instance, the smallest handheld terminals can
have a very limited amount of memory, computational power, and
battery capacity. Cellular hosts operate over low bandwidth wireless
links with limited throughput. As such, there are certain
optimizations that would be required for these hosts in order to fit
the largest possible amount of terminals within an area of spectrum.
Tough demands are set for interoperability of cellular hosts towards
other hosts, the cellular network, and the Internet. It is often
hard or impossible to upgrade a large number of cellular hosts to a
new software version. The long lifetime of the terminals sets a
requirement for old equipment to still work in newer versions of the
network and other hosts.
The concept of IPv6 covers many aspects, numerous RFCs, a number of
different situations, and is also partly still in evolution. For
these reasons it is necessary to understand how the IPv6 deployment
starts and which parts of IPv6 are necessary under which situations.
This document reviews the IPv6 functionality, grouped under three
categories: core IP, security, and mobility. For each category and
each RFC in them, we discuss the following:
- Is this part of functionality needed by cellular hosts and under
which conditions?
- In some cases individual parts of the RFCs are discussed in more
detail and recommendations are given regarding their support.
- In some other cases conflicts between some parts of
functionality and the current cellular network protocols are
identified.
The aim of this work is to introduce a minimal set of IPv6
functionality _ subject to the particular type of terminal and
application _ that would be required for cellular IPv6 hosts. As a
general guideline, a cellular host should not appear any different
from other IPv6 hosts. The set of requirements proposed should be
suited to terminals with minimal capabilities, low cost and
processing power. Interoperability can be achieved by listing needed
IPv6 related IETF specifications according to chapter 1.2.
The scope of the discussion in this document is the IPv6
functionality. The reader should be advised that other work exists
for various other layers, which is not IPv6 specific such as the
header compression work done in the IETF ROHC group, or the TCP work
in [TCPWIRELESS].
The authors of this document seek feedback to ensure that the
proposed functionality set is consistent, interoperable with the
rest of the IPv6 Internet, complete, and does not open new security
risks.
Manyfolks [Page 5]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
1.1 Abbreviations
3GPP Third Generation Partnership Project
AH Authentication Header
CDMA2000 Code Division Multiple Access 2000, the name identifying
the third generation technology of IS-95 CDMA standard
and ANSI-41 network.
ESP Encapsulating Security Payload
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
IKE Internet Key Exchange
ISAKMP Internet Security Association and Key Management
Protocol
MTU Maximum Transmission Unit
SGSN Serving GPRS Support Node
UMTS Universal Mobile Telecommunications System
WLAN Wireless LAN
1.2 Requirement Language
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [KEYWORDS].
1.3 Cellular Host IPv6 Features
This specification defines IPv6 features for cellular hosts in three
groups.
Core IP
In this group we describe the core parts of IPv6. Only RFCs
needed in all situations and under all conditions are in this
group.
IP Security
In this group we discuss the IP layer security functionality
suitable for cellular hosts. Chapter 3 defines the contents
of this group, and discusses its usage in different contexts.
IP Mobility
In this group we discuss IP layer mobility functionality for
cellular hosts. Basic functionality needed just to correspond
with mobile nodes is a part of the Core IP group. Chapter 4
defines the contents of the IP Mobility group, and discusses
its usage in different contexts.
2 Core IP
Manyfolks [Page 6]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
This section describes the minimum needed IPv6 functionality of a
cellular host in order to be able to communicate with other IPv6
hosts.
2.1 RFC1981 - Path MTU Discovery for IP Version 6
Path MTU Discovery [PMTU] MAY be supported.
The IPv6 specification [IPv6] states in chapter 5 that "a minimal
IPv6 implementation (e.g., in a boot ROM) may simply restrict itself
to sending packets no larger than 1280 octets, and omit
implementation of Path MTU Discovery."
If Path MTU Discovery is not implemented then the uplink packet size
MUST be limited to 1280 octets (standard limit in [IPv6]). However,
the cellular host MUST be able to receive packets with size up to
the link MTU before reassembly.
2.2 RFC2373 - IP Version 6 Addressing Architecture
The IPv6 Addressing Architecture [ADDRARCH] MUST be supported. IPX &
NSAP addresses SHOULD NOT be used.
2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format
The IPv6 Aggregatable Global Unicast Address Format is described in
[RFC-2374]. This RFC MUST be supported.
2.4 RFC2460 - Internet Protocol Version 6
The Internet Protocol Version 6 is specified in [IPv6]. This RFC
MUST be supported.
The cellular host is assumed to act as a host, not a router.
Implementation requirements for a cellular router are not defined in
this document.
The cellular host MUST implement all non-router packet receive
processing as described in RFC 2460. This includes the generation
of ICMPv6 error reports, and at least minimal processing of each
extension header:
- Hop-by-Hop Options header: at least the Pad1 and PadN options
- Destination Options header: at least the Pad1, PadN and Home
Address options
- Routing (Type 0) header: final destination (host) processing
only
- Fragment header
- AH and ESP headers: In the case of the Core IP functionality
only, AH and ESP headers are treated as if the Security
Association had not existed, i.e. - packets with these headers
Manyfolks [Page 7]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
are dropped. When the IP Security functionality is in use, they
are processed as specified in RFCs 2401, 2402, and 2406.
- The No Next Header value
Unrecognized options in Hop-by-Hop Options or Destination Options
extensions must be processed as described in RFC 2460.
The cellular host must follow the packet transmission rules in RFC
2460. A cellular host implementing the Core IP functionality will
typically send packets containing either no extension headers or the
Fragment header. However, a cellular host MAY generate any of the
extension headers.
Cellular Hosts will act as the destination when processing the
Routing Header. This will also ensure that the cellular hosts will
not be inappropriately used as relays or components in Denial-of-
Service attacks. Acting as the destination involves the following.
The cellular hosts MUST check the Segments Left field in the header,
and proceed if it is zero or one and the next address is one of the
terminal's addresses. If not, however, the terminal MUST implement
error checks as specified in section 4.4 of RFC 2460. Under the
simplifying assumptions, there is no need for the terminal to send
Routing Headers.
2.5 RFC2461 - Neighbor Discovery for IPv6
Neighbor Discovery is described in [RFC-2461] and, in general, MUST
be supported.
In cellular networks, some Neighbor Discovery messages can cause
unnecessary traffic and consume valuable (limited) bandwidth. If a
cellular link resembles a point-to-point link, a mobile terminal may
only have its default routers as neighbors. Therefore, in this
situation, Neighbor Solicitation and Advertisement messages MAY be
implemented. If a cellular host does not have a MAC address on its
cellular interface, the link layer suboption SHOULD NOT be
implemented for this interface. It is for further study to study in
which direction this is applicable.
2.5.1 Neighbor Discovery in 3GPP
3GPP terminals only need to support Router Solicitations and Router
Advertisements for 3GPP IPv6 Stateless Address Autoconfiguration.
See appendix A for more details. Neighbor Sollicitations and
Advertisements may be supported for Neighbor Unreachability
Detection. They are not needed for 3GPP IPv6 Stateless Address
Autoconfiguration, since Duplicate Address Detection is not needed
in this address assignment mechanism.
2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration
Manyfolks [Page 8]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
IPv6 Stateless Address Autoconfiguration [ADDRCONF] MAY be
supported. It is recommended not to perform the Duplicate Address
Detection if the IPv6 address (suffix) uniqueness is taken care of
by a network element (on the same link). It will avoid unnecessary
(valuable) bandwidth consumption in the cellular environment.
2.6.1 Stateless Address Autoconfiguration in 3GPP
A 3GPP Cellular host MUST be able to process a Router Advertisement
as stated in chapter 5.5.3 of [ADDRCONF]. However, a cellular host
in a 3GPP Architecture does not generate its own IPv6 address
(suffix), therefore Duplicate Address Detection is not needed.
See appendix A for more details on 3GPP IPv6 Stateless Address
Autoconfiguration.
2.7 RFC2463 - Internet Control Message Protocol for the IPv6
The Internet Control Message Protocol for the IPv6 [ICMPv6] MUST be
supported.
As per RFC 2463 section 2, ICMPv6 requirements MUST be fully
implemented by every IPv6 node. However, references to the use of IP
Security (sections 5.1 and 5.2) are not relevant for Core IP
features.
2.8 RFC2472 - IP version 6 over PPP
IPv6 over PPP [IPv6PPP] MUST be supported for cellular hosts that
implement PPP.
2.9 RFC2473 - Generic Packet Tunneling in IPv6 Specification
Generic Packet Tunneling [RFC-2473] MAY be supported if needed for
transition mechanisms and MUST be supported if the Mobile Node
functionality of Mobile IP is implemented, as specified in chapter
4.
2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
Multicast Listener Discovery [MLD] SHOULD be supported if the
cellular host supports multicast functionality.
2.11 RFC2711 - IPv6 Router Alert Option
The Router Alert Option [RFC-2711] MAY be supported. Since the
cellular host will not function as a router, the receiver side of
the Router Alert Option can be omitted even in case the Router Alert
Option is supported.
2.12 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers
Manyfolks [Page 9]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
Transition mechanisms [TRANSMECH] MAY be supported. See Appendix B
for more details.
2.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6
Privacy Extensions for Stateless Address Autoconfiguration [RFC-
3041] MAY be supported.
2.13.1 Privacy Extensions for Stateless AA in 3GPP
The Privacy Extensions for Stateless Autoconfiguration RFC [RFC-
3041] is incompatible with the 3GPP model and MUST NOT be supported
if the 3GPP IPv6 Stateless Address Autoconfiguration is used. 3GPP
IPv6 Stateless Address Autoconfiguration uses Neigbor Discovery
messages, but the host is not allowed to propose its own interface
identifier. The network provides the complete IPv6 address to the
3GPP host. A host implementing Privacy Extensions for Stateless
Autoconfiguration will periodically change its interface identifier.
Depending on the specific implementation of the 3GPP network, the
packets originated from and destined for the new address will most
likely be dropped. See Appendix A for more details on 3GPP IPv6
address assignment and Chapter 5 for the security implications of
this.
2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds
Connection of IPv6 domains via IPv4 clouds [RFC-3056] MAY be
supported.
For a cellular host, this specification would mean capability to
create 6to4 tunnels starting from the cellular host itself. In a
cellular environment, tunneling over the air interface should be
minimized. Hence, 6to4 tunneling SHOULD be carried out by
intermediate 6to4 routers rather than the cellular host.
2.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Dynamic Host Configuration Protocol for IPv6 [DHCPv6] MAY be
supported.
It is possible for the DHCP client to be implemented on the cellular
host.
2.16 Default Address Selection for IPv6
Default Address Selection for IPv6 [DEFADDR] SHOULD be supported
since cellular hosts can have more than one IPv6 address.However,
note that the rules in [DEFADDR] can be greatly simplified when
cellular hosts do not implement the optional policy table, and/or
have just one global IPv6 address.
Manyfolks [Page 10]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
2.17 DNS
Some networks may provide DNS-proxy service for simple cellular
hosts. Therefore, generally, DNS MAY be supported.
2.17.1 RFC1034 - Domain Names _ Concepts and Facilities
The concepts and facilities of domain names are specified in [RFC-
1034]. This RFC MUST be supported for cellular hosts which support
DNS.
2.17.2 RFC1035 - Domain Names _ Implementation and Specification
The implementation and specification are described in [RFC-1035].
This RFC MUST be supported for cellular hosts which support DNS.
2.17.3 RFC1886 - DNS Extension to support IP version 6
DNS Extension for IPv6 [RFC-1886] MUST be supported for cellular
hosts which support DNS.
2.17.4 RFC2874 - DNS Extensions to Support IPv6 Address Aggregation and
Renumbering
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
[RFC-2874] MAY be supported. A6 can cause problems for cellular
hosts operating over wireless links since several round trips may be
needed to collect a complete DNS record, when a DNS resolver is
implemented on a cellular host.
2.18 Security Issues
Chapter 3 describes where IP Security [RFC-2401] should or should
not be used. Nevertheless, even if a particular terminal does not
support IP Security, it MUST be able to refuse IKE [RFC-2409]
connection attempts. The purpose of this is to provide a clean
indication to the other host that this particular host is not
willing to provide security associations.
It is for further study whether IKE response messages are needed for
the clean indication or if ICMP port unreachable reports are
sufficient.
3 IP Security
The use of IP Security [RFC-2401] or other security services in
cellular hosts depends on their intended use. The following services
are discussed here:
- VPN service to a corporate intranet
- Web browsing service
Manyfolks [Page 11]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
- IP Multimedia Service as defined by 3GPP
- Mobility service as defined by Mobile IP
- Protection of IPv6 infrastructure communications in the local
network
Recommendations are given on what security solution to employ in
these situations, though in some cases work by other bodies or
working groups hasn't progressed far enough to state the solution
yet. It is however strongly suggested that some of the existing set
of security mechanisms be used rather than new ones developed,
adding to the amount of memory and implementation effort needed for
a host supporting multiple services.
Cellular hosts that provide a VPN service to a corporate intranet,
for example, or to a transition tunneling gateway MUST support IPsec
and IKE. This security set is defined in this chapter. For this
purpose an IPsec Remote Access solution SHOULD also be supported.
Cellular hosts that provide only a simple web browsing service
SHOULD provide SSL or TLS [RFC-2246]. The use of security in a web
browser is seen in most cases as necessary, as otherwise the user
would be blocked from some of the sites - such as e-commerce sites -
that do require security. The fact that just SSL/TLS should be the
protocol to provide web security relates to current deployment and
the suitability of the single-side certificate trust model for this
application.
It is likely that no end-to-end security will be mandated for the
multimedia streams themselves in the first releases of the 3GPP IMS
service specifications. However, it is necessary to provide security
for the signaling parts. The 3GPP SA3 group is currently evaluating
the use of IPsec, S/MIME/CMS-based approaches, and other techniques.
When this work completes, more can be said about the mandated
security services for the IMS.
Hosts supporting mobility services [MIPv6], will need a security
solution which is also currently under development in the IETF.
The use of IPsec, IKE, or other security services directly in the
underlying IPv6 infrastructure communications (e.g. ICMPv6 or
Neighbor Discovery) can also be discussed. The use of IPsec towards
a specific home server in the context of a VPN service is easy.
However, the use of any security service within the context of local
next hop routers (GGSNs) or other 3GPP nodes seems hard due to the
difficulties in establishing a suitable trust infrastructure for
creating the necessary Security Associations (SAs). In order for a
terminal to create an SA with the next hop router for the purposes
of securing the router and neighbor discovery tasks would mean the
following. First, both the routers and all cellular hosts would have
to be registered to a PKI system. Second, a common root CA would
have to be found that encompasses both the visiting cellular host of
Manyfolks [Page 12]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
an operator as well as the infrastructure of another operator. It is
not clear if this is possible with today's technology.
Furthermore, as [ICMPIKEv6] points out, dynamic SA negotiation can't
be used for the protection of the first few connectivity
establishment messages in ICMPv6. It may be possible to overcome
these problems, however, the added security benefits of the
protection in these cases would be minimal: encrypted radio
communications exist at a lower layer, and the next hop router can
always engage in any denial-of-service attacks (such as dropping all
packets) regardless of the existence of any SAs. For these reasons,
the 3GPP terminals will not be mandated to support any security for
the pure IPv6 router and infrastructure protection purposes.
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication
This RFC [RFC-2104] MUST be supported, as it is referenced from RFC
2403 which is mandatory in this set.
3.2 RFC2401 - Security Architecture for the Internet Protocol
This RFC [RFC-2401] MUST be supported.
3.3 RFC2402 - IP Authentication Header
This RFC [RFC-2402] SHOULD be supported. The AH protocol is one of
the alternative protocols in the IPsec protocol family, the other
alternative being ESP.
In the interest of minimizing implementation complexity and in
particular configuration options, both protocols may not be needed
in a cellular host. It is suggested that the ESP protocol be
preferred for its confidentiality protection function. We also note
that the IPsec WG has discussed the removal of AH, it is no longer
certain that AH be used for securing Mobile IP Binding Updates, and
tunnel mode ESP with integrity protection can perhaps be used to
provide some of the functions of AH.
For these reasons AH is made a SHOULD and ESP a MUST. However,
feedback is sought on the matter since this is against the
traditional standard rules, and the protection offered by AH is
different from ESP.
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH
This RFC [RFC-2403] MUST be supported.
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH
This RFC [RFC-2404] MUST be supported.
Manyfolks [Page 13]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
This RFC [RFC-2405] MAY be supported. It is, however, recommended
that stronger algorithms than DES be supported.
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)
This RFC [RFC-2406] MUST be supported.
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP
This RFC [RFC-2407] SHOULD be supported. Automatic key management,
[RFC-2408] and [RFC-2409], are not a mandatory part of the IP
Security Architecture. Note, however, that in the cellular
environment the IP addresses of a host may change dynamically. For
this reason the use of manually configured Security Associations is
not practical, as the newest host address would have to be updated
to the SA data base of the peer as well. Regardless of this,
automatic key management is not made a mandatory requirement here.
This is because there may be other special-purpose keying schemes
for particular applications.
In the cellular environment, the detailed MUSTs within the IP
Security DoI, ISAKMP, and IKE is for further study. It is likely
that several simplifying assumptions can be made. For instance, the
use of pre-shared secrets as an authentication method in IKE is not
feasible in practice in the context of a large number of hosts.
3.9 RFC2408 - ISA and Key Management Protocol
This RFC [RFC-2408] MUST be supported where IKE is necessary for the
particular service provided, as described in the start of chapter 3,
and MAY be supported otherwise.
3.10 RFC2409 - The Internet Key Exchange (IKE)
This RFC [RFC-2409] SHOULD be supported where IKE is necessary for
the particular service provided, as described in the start of
chapter 3, and MAY be supported otherwise.
3.11 RFC2410 - The NULL Encryption Algorithm and its Use With IPsec
This RFC [RFC-2410] MUST be supported where IKE is necessary for the
particular service provided, as described in the start of chapter 3,
and MAY be supported otherwise.
3.12 RFC2411 - IP Security Document Roadmap
This RFC [RFC-2411] is of informational nature only.
Manyfolks [Page 14]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms
This RFC [RFC-2451] MUST be supported if encryption algorithms other
than DES are implemented, e.g.: CAST-128, RC5, IDEA, Blowfish, 3DES.
3.14 IP Security Remote Access
The IETF IPSRA WG is working on solutions to provide remote access
mechanisms on top of IPsec in situations where legacy RADIUS or
other authentication is desired instead of PKI-based authentication.
These solutions are currently under development, but SHOULD be
supported by cellular hosts offering VPN services to corporate
intranets.
3.15 The AES Cipher Algorithm and Its Use With IPsec
This specification [AESIPSEC] MUST be supported. We suggest here
that in a new environment such as the cellular IPv6 older and
insecure algorithms such as DES should not be used, and that the
most secure and lightweight new ones should be used instead. Due to
better efficiency we suggest the use of AES instead of 3DES.
3.16 ICMPv6 and Its Effect to IKE and IPsec Policies
This specification [ICMPIKEv6] MUST be supported by hosts, if they
also support IKE. Without this specification, there may be certain
undesirable interactions between ICMPv6 and IKE.
4 IP Mobility
Mobile IPv6 manages IP mobility resulting from the change in CoA
when a host moves within the Internet topology. This section will
detail the level of support of MIPv6 required by cellular hosts and
highlight the scenarios in which such support is needed.
4.1 Mobility Support in IPv6
Mobile IPv6 is specified in [MIPv6].
Mobile IP is required for hosts moving within the Internet topology.
At the highest level, the Mobile IPv6 functionality within Mobile
Nodes can be divided to the following parts:
- Mobile Node (MN) functionality, defined by Mobile IPv6
specification [MIPv6]. This includes the ability to configure
Home and Care-of-Addresses (CoA) send Binding Updates (BUs)and
receive Binding Acknowledgements and Requests. In addition, this
function also includes the ability to maintain a Binding Update
List.
- Correspondent Node (CN) functionality [MIPv6], i.e. the basic
functionality needed to correspond with mobile nodes.
Manyfolks [Page 15]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
- Route optimization. The functionality needed to correspond with
mobile nodes in an optimal manner.
We will discuss the use of each part in turn. The mobile node
functionality is needed when the host itself will move within the
Internet topology i.e. changes it's care-of address. This function
is needed in cellular systems where MIPv6 is used for intra-domain
mobility. In other cellular systems where intra-domain mobility is
handled by other means (e.g. GTP in a 3GPP system), only hosts with
additional, non-cellular interfaces MUST have this functionality if
they need to retain session or IP layer reachability while moving
between different access technologies, i.e. - to use MIPv6 for
inter-system IP handovers.
For instance, when a hosts has both a Wireless LAN (WLAN) and an
UMTS interface, MIPv6 MN functionality is needed to retain sessions
when moving from UMTS area to a WLAN area. The UMTS network provides
a basic mobility service (layer 2 mobility) to all hosts without
requiring the implementation of IP layer mobility. Hosts that have
interfaces only to networks providing such other mobility services,
or hosts that do not require session mobility through interface
handovers MAY have this functionality.
The basic functionality of a Correspondent Node, i.e. process the
Home Address Option, MUST be supported by all hosts.
The Route Optimized functionality for a CN, i.e. processing of
Binding Updates, SHOULD be supported by all hosts when the
communication benefits from this optimization.
4.2 Fast Handovers for Mobile IPv6
Fast handovers for Mobile IPv6 is specified in [MIPv6-FH].
This draft SHOULD be supported if Mobile IPv6 [MIPv6] is supported
and when communication benefits from this optimization.
4.2.1 3GPP and Fast Handoffs
Within the current 3GPP architecture, a cellular host will always
keep the connection to the same GGSN (default router) for a context.
Movement between default routers is not permitted. The only scenario
where a MN would change default routers is in the case of a handover
between two different access technologies. In this case the MN will
be simultaneously connected to both routers which would eliminate
the need for anticipation through the current router. Hence the Fast
Handoffs draft will not be required within the current 3GPP
architecture.
Manyfolks [Page 16]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
4.3 Hierarchical MIPv6 Mobility Management
Hierarchical MIPv6 is specified in [HMIPv6].
Hierarchy SHOULD be supported to run MIPv6 efficiently over the air.
This aims to reduce the number of MIPv6 BUs sent over the air while
moving within the topology.
4.3.1 HMIPv6 in 3GPP
As mentioned above, Inter-GGSN handovers are not allowed within the
current 3GPP architecture. Hence, the benefit of implementing HMIPv6
in 3GPP will only appear during the inter-access technology handover
which may not be as common as intra-access technology ones. However
the architecture can benefit from the per-flow movement explained in
the draft which allows a MN to receive different traffic flows on
different interfaces.
4.4 Mobile IP Security
The security design for Mobile IP is currently being performed in
the IETF. Before this work completes it will not be possible to
state in detail the security requirements for cellular hosts using
Mobile IP. However, we expect that security solutions will be
provided both for the protection of binding updates to correspondent
nodes, as well as secure tunneling support between the mobile node
and its home.
5 Security Considerations
This document does not specify any new protocols or functionality,
and as such it does not introduce any new security vulnerabilities.
However, specific profiles of IPv6 functionality are proposed for
different situations, and vulnerabilities may open or close
depending on which functionality is included and what is not. In the
following, we discuss such situations:
- The suggested limitations (Section 2.4) in the processing of
routing headers limits also exposure to Denial-of-Service
attacks through cellular hosts.
- The incompatibility of the addressing privacy [RFC3041] and 3GPP
address autoconfiguration model prevents the use of exactly the
same kind of privacy functionality as provided in IPv6. However,
it should be noted that in the 3GPP model the network will
assign new addresses to hosts in roaming situations and
typically also when the cellular terminals are turned on. This
means that a limited form of addressing privacy will already be
provided by 3GPP networks, and no global tracking of a single
terminal is possible through its address.
Manyfolks [Page 17]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
- The use of various security services such as IPsec or SSL in the
connection of typical applications in cellular hosts is
discussed in Chapter 3 and recommendations are given there.
- Chapter 3 also discusses under what conditions it is possible to
provide IPsec protection of e.g. ICMPv6 communications.
Recommendations are given to support VPN-type tunneling to home
networks, but to avoid the use of any security services in
towards visited network nodes due to problems setting up
sufficient PKI infrastructure for such usage.
- Chapter 3 further discusses a specific profile of IPsec suitable
for cellular implementations. Deviations from the standard RFCs
are suggested mainly due to a desire to adopt the latest
advances, such as the AES algorithm. On the other hand it is
suggested to employ only the ESP protocol for reasons of
reducing complexity. ESP provides a different protection than
AH, which may have security implications.
- As Chapter 4 mandates only the support of the Mobile IP Home
Address option and not the full, optimized correspondent node
behavior, the security problems related to Binding Updates are
not relevant for nodes supporting only the Core IP features.
- The air-time used by cellular hosts is expensive. In some cases
users are billed according to the amount of data they transfer
to and from their host. It is crucial for both the network and
the users that the air-time is used correctly and no extra
charges are applied to users due to misbehaving third parties.
The wireless links also have a limited capacity, which means
that they may not necessarily be able to accommodate more
traffic than what the user selected, such as a multimedia call.
Additional traffic might interfere with the service level
experienced by the user. While QoS mechanisms mitigate these
problems to an extent, it is still apparent that Denial-of-
Service aspects may be highlighted in the cellular environment.
It is possible for existing DoS attacks that use for instance
packet amplification to be substantially more damaging in this
environment. How these attacks can be protected against is still
an area of further study. It is also often easy to fill the
wireless link and queues on both sides with additional or large
packets.
- In certain areas of the world it is possible to buy a prepaid
cellular subscription without presenting personal
identification. This could be leveraged by attackers that wish
to remain unidentified. We note that while the user hasn't been
identified, the equipment still is; the operators can follow the
identity of the device and block it from further use. The
operators MUST have procedures in place to take notice of third
party complaints regarding the use of their customers' devices.
Manyfolks [Page 18]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
It MAY also be necessary for the operators to have attack
detection tools that enable them to efficiently detect attacks
launched from the cellular hosts.
- Cellular devices that have local network interfaces (such as
IrDA or Bluetooth) may be used to launch attacks through them,
unless the local interfaces are secured in an appropriate
manner. Therefore, we recommend that any local network interface
SHOULD have access controls to prevent bypassers from using the
cellular host as an intermediary.
6 References
[3GPPADDR] 3GPP 23.060, version 4.00, chapter 9.2.1.1
[3GPP-IMS] 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; IP
Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228
version 5.0.0)
[ADDRARCH] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ADDRCONF] Thomson, S. and Narten, T., "IPv6 Stateless Address
Autoconfiguration". RFC 2462.
[AESIPSEC] Frankel, S., Kelly, S. and Glenn, R., "The Candidate
AES Cipher Algorithms and Their Use With IPsec",
draft-ietf-ipsec-ciph-aes-cbc-01.txt, November 2000,
Work in progress
[DEFADDR] Draves, R., "Default Address Selection for IPv6",
draft-ietf-ipngwg-default-addr-select-05.txt, June
2001, Work in progress.
[DHCPv6] Bound, J. et al., "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-
19.txt, June 2001 Work in progress.
[HMIPv6] Soliman, H., Castelluccia, C., El-Malki, K. and
Bellier, L., "Hierarchical MIPv6 mobility
management", draft-ietf-mobileip-hmipv6-04.txt, July
2001, Work in progress
[ICMPIKEv6] Arkko, J., "Effects of ICMPv6 on IKE and IPsec
Policies", draft-arkko-icmpv6-ike-effects-00.txt,
February 2001, Work in progress
[ICMPv6] Conta, A. and Deering, S., "ICMP for the Internet
Protocol Version 6 (IPv6)", RFC 2463, December 1998.
Manyfolks [Page 19]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
[IPv6] Deering, S. and Hinden, R., "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December
1998.
[IPv6PPP] Haskin, D. and Allen, E., "IP Version 6 over PPP",
RFC 2472, December 1998
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIPv6] Johnson D. and Perkins, C., "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-14.txt, July 2001,
Work in progress.
[MIPv6-FH] Tsirtsis, G. et al., "Fast Handovers for Mobile
IPv6", draft-ietf-mobileip-fast-mipv6-02.txt, July
2001, Work in progress.
[MLD] Deering, S., Fenner, W. and Haberman, B., "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999
[PMTU] McCann, J., Mogul, J. and Deering, S., "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC-1034] Mockapetris, P., "Domain names _ concepts and
facilities", RFC 1034, November 1987
[RFC-1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC-1886] Thomson, S. and Huitema, C., "DNS Extensions to
support IP version 6, RFC 1886, December 1995.
[RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC-2246] Dierks, T. and Allen, C., "The TLS Protocol Version
1.0", RFC 2246, January 1999
[RFC-2374] Hinden, R., O'Dell, M. and Deering, S., "An IPv6
Aggregatable Global Unicast Address Format", RFC
2374, July 1998.
[RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC-2402] Kent, S. and Atkinson, R., "IP Authentication
Header", RFC 2402, November 1998.
Manyfolks [Page 20]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
[RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5
within ESP and AH", RFC 2403, November 1998.
[RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
within ESP and AH", RFC 2404, November 1998.
[RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[RFC-2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2408] Maughan, D., Schertler, M., Schneider, M., and
Turner, J., "Internet Security Association and Key
Management Protocol (ISAKMP)", RFC 2408, November
1998.
[RFC-2409] Harkins, D., and Carrel, D., "The Internet Key
Exchange (IKE)", RFC 2409, November 1998.
[RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption
Algorithm and Its Use With IPsec", RFC 2410, November
1998
[RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998
[RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling
in IPv6 Specification", RFC 2473, December 1998.
[RFC-2529] Carpenter, B. and Jung, C., "Transmission of IPv6
over IPv4 Domains without Explicit Tunnels_, RFC
2529, March 1999.
[RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert
Option", RFC 2711, October 1999.
[RFC-2874] Crawford, M. and Huitema, C., "DNS Extensions to
Support IPv6 Address Aggregation and Renumbering",
RFC 2874, July 2000.
Manyfolks [Page 21]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
[RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms
for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC
3041, January 2001.
[RFC-3056] Carpenter, B. and Moore, K., "Connection of Ipv6
domains via IPv4 clouds", RFC 3056, February 2001.
[TCPWIRELESS] Inamura, H. et al. _TCP over 2.5G and 3G Networks_.
IETF, draft-ietf-pilc-2.5g3g-02.txt, Work in
progress.
[TRANSMECH] Gilligan, R. and Nordmark, E., "Transition Mechanisms
for IPv6 Hosts and Routers", RFC 2893, August 2000.
7 Acknowledgements
The authors would like to thank David DeCamp, Markus Isomaki, Petter
Johnsen, Janne Rinne, Jonne Soininen, Hesham Soliman and Shabnam
Sultana for there comments and input.
8 Authors' Addresses
Jari Arkko
Ericsson
02420 Jorvas
Finland
Phone: +358 40 5079256
Fax: +358 40 2993401
E-Mail: Jari.Arkko@ericsson.com
Peter Hedman
Ericsson
SE-221 83 LUND
SWEDEN
Phone: +46 46 231760
Fax: +46 46 231650
E-mail: peter.n.hedman@ecs.ericsson.se
Gerben Kuijpers
Ericsson
Skanderborgvej 232
DK-8260 Viby J
DENMARK
Phone: +45 89385100
Manyfolks [Page 22]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
Fax: +45 89385101
E-mail: gerben.a.kuijpers@ted.ericsson.dk
John Loughney
Nokia Research Center
Itamerenkatu 11 _ 13
FIN-00180 HELSINKI
FINLAND
Phone: +358 7180 36242
Fax: +358 7180 36851
E-mail: john.loughney@nokia.com
Pertti Suomela
Nokia Mobile Phones
Sinitaival 5
FIN-33720 TAMPERE
Finland
Phone: +358 7180 40546
Fax: +358 7180 48215
E-mail: pertti.suomela@nokia.com
Juha Wiljakka
Nokia Mobile Phones
Sinitaival 5
FIN-33720 TAMPERE
Finland
Phone: +358 7180 47562
Fax: +358 7180 48215
E-mail: juha.wiljakka@nokia.com
Appendix A Cellular Host IPv6 Addressing in the 3GPP Model
The appendix aims to describe 3GPP (Third Generation Partnership
Project) IPv6 addressing model for 2G (GPRS) and 3G (UMTS) cellular
networks [3GPPADDR].
There are two possibilities to allocate an address for an IPv6 node
_ stateless and stateful autoconfiguration. The stateful address
allocation mechanism needs a DHCP server to allocate the address for
the IPv6 node. In the stateless autoconfiguration, the IPv6 node is
more involved in the allocation and the stateless autoconfiguration
procedure does not need any external entity involved in the address
autoconfiguration.
The two important network elements in the 3GPP packet based
architecture are SGSN (Serving GPRS Support node) and GGSN (Gateway
GPRS Support Node). GGSN is the nearest router for the mobile
terminal / cellular host and it is responsible for giving an IP
Manyfolks [Page 23]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
address to the mobile terminal. The logical link established
between the GGSN Access Point and the mobile terminal is called PDP
(Packet Data Protocol) context.
To support dynamic IPv6 address allocation by the PLMN (Public Land
Mobile Network) operator, the GGSN provides a unique interface
identifier (see RFC 2462) to the mobile terminal. This enables the
cellular host to perform the IPv6 stateless autoconfiguration
procedures to generate its full IPv6 address.
In the first phase the mobile terminal sends an Activate PDP Context
Request message to the SGSN. The mobile terminal shall leave PDP
Address empty and set PDP Type to IPv6. The GGSN shall create the
unique link-local address for the mobile terminal and send it in the
PDP Address information element in the Create PDP Context Response
message. The link local address consists of a fixed 10-bit prefix
(IPv6 link-local prefix), zero or more 0 bits, and the interface
identifier.
After that the mobile terminal may send a Router Solicitation
message to the GGSN to activate the sending of the Router
Advertisement message.
The GGSN should automatically send the Router Advertisement message
after the PDP context is activated. In 3GPP Release 99 the GGSN
shall be configured to advertise only one network prefix per APN
(Access Point Name).
After the mobile terminal has received the Router Advertisement
message, it constructs its full IPv6 address by concatenating the
interface identifier contained in the link-local address provided in
the Create PDP Context Response Message and the network prefix of
the selected APN received in the Router Advertisement. Subsequently,
the mobile terminal is ready to start communicating to the Internet.
Because the GGSN provides a unique interface identifier during the
PDP context activation procedure, there is no need for the mobile
terminal to perform Duplicate Address Detection for this IPv6
address. Therefore, the GGSN shall intercept and discard Neighbor
Solicitation messages that the mobile terminal may send to perform
Duplicate Address Detection. It is possible for the mobile terminal
to perform Neighbor Unreachability Detection, as defined in RFC
2461; therefore if the GGSN receives a Neighbor Solicitation as part
of this procedure, the GGSN shall provide a Neighbor Advertisement
as described in RFC 2461.
Finally, the GGSN updates the PDP context in the SGSN and mobile
terminal with the full IPv6 address (so-called GGSN-Initiated PDP
Context Modification Procedure).
Manyfolks [Page 24]
Internet Draft Min. IPv6 Func. for a Cellular Host July 2, 2001
Appendix B Transition Issues
IETF has specified a number of IPv4 / IPv6 transition mechanisms
[RFC-2893] to ensure smooth transition from IPv4 to IPv6 and
interoperability between IPv4 and IPv6 during the transition period.
The three main transition methods from a cellular network point of
view are dual IPv4 / IPv6 stacks, tunneling and protocol
translators, such as NAT-PT or SIIT.
It is recommended that cellular hosts have dual IPv4 / IPv6 stacks
to be able to interoperate with both IPv4 and IPv6 domains and use
both IPv6 and IPv4 applications / services. It is recommended that
the majority of the transition mechanisms are provided by the
network in order to save the limited resources of the cellular host.
Tunneling (for example RFC 3056 - Connection of IPv6 Domains via
IPv4 Clouds) should be carried out in the network. Also any
protocol translation function, such as NAT-PT, should be implemented
in the network, not in the cellular host. The tunneling mechanism
specified by [RFC-2529] is not relevant for a cellular host. [RFC-
2529] allows isolated IPv6-only hosts to connect to an IPv6 router
via an IPv4 domain. The scenario of an IPv6-only host in an IPv4-
only cellular network is considered unlikely.
Manyfolks [Page 25]