TS 102 483
ETSI TS 102 483 V8.1.0 (2009-04)
Technical Specification
Smart cards;
UICC-Terminal interface;
Internet Protocol connectivity between UICC and terminal
(Release 8)
Release 8
2
ETSI TS 102 483 V8.1.0 (2009-04)
Reference
RTS/SCP-T0311v810
Keywords
internet, protocol, smart card
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2009.
All rights reserved.
TM
TM
TM
TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
Release 8
3
ETSI TS 102 483 V8.1.0 (2009-04)
Content
Intellectual Property Rights ................................................................................................................................4
Foreword.............................................................................................................................................................4
Introduction ........................................................................................................................................................4
1
Scope ........................................................................................................................................................5
2
References ................................................................................................................................................5
2.1
2.2
3
Normative references .........................................................................................................................................5
Informative references........................................................................................................................................7
Definitions and abbreviations...................................................................................................................7
3.1
3.2
4
Definitions..........................................................................................................................................................7
Abbreviations .....................................................................................................................................................8
Terminal-UICC IP configuration .............................................................................................................8
4.1
4.2
4.3
4.4
Local client on UICC .........................................................................................................................................9
Local server on UICC.........................................................................................................................................9
Remote client UICC .........................................................................................................................................10
Remote server on UICC ...................................................................................................................................10
5
Protocol Stack ........................................................................................................................................11
6
UICC and Terminal components requirements......................................................................................12
6.1
6.1.1
6.1.2
6.1.2.1
6.1.2.2
6.1.2.2.1
6.1.2.2.2
6.2
6.2.1
6.2.2
6.3
6.3.1
6.3.1.1
6.3.1.2
6.3.2
6.3.2.1
6.3.2.2
6.4
6.4.1
6.4.2
UICC IP layer...................................................................................................................................................12
IPv4 / IPv6 interworking.............................................................................................................................12
Address allocation ......................................................................................................................................12
Local Connection ..................................................................................................................................13
Remote Connection...............................................................................................................................13
IPv4 address allocation....................................................................................................................13
IPv6 address allocation....................................................................................................................14
Local naming....................................................................................................................................................14
Predefined names........................................................................................................................................14
Names provided by the UICC.....................................................................................................................14
Summary of terminal and UICC configuration ................................................................................................15
UICC Configuration ...................................................................................................................................15
IP v4 ......................................................................................................................................................15
IP v6 ......................................................................................................................................................15
Terminal Configuration ..............................................................................................................................15
IP v4 ......................................................................................................................................................15
IP v6 ......................................................................................................................................................15
Terminal IP Components..................................................................................................................................16
Connection setting ......................................................................................................................................16
Routing, Network Address Translation and port forwarding......................................................................16
Annex A (informative):
Connection of a local equipment to the terminal and UICC......................17
Annex B (informative):
Example of activation parameters................................................................18
Annex C (informative):
Bibliography...................................................................................................19
Annex D (informative):
Change history ...............................................................................................20
History ..............................................................................................................................................................21
ETSI
Release 8
4
ETSI TS 102 483 V8.1.0 (2009-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP).
The contents of the present document are subject to continuing work within TC SCP and may change following formal
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with
an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x
the first digit:
0
early working draft;
1
presented to TC SCP for information;
2
presented to TC SCP for approval;
3
or greater indicates TC SCP approved document under change control.
y
the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z
the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
The present document defines how an Internet Protocol connection may be established between a UICC and a terminal
connected through a UICC-Terminal Interface able to carry Internet Protocol packets, and how the UICC resources
defined in ETSI TS 102 221 [11] may be accessed over this connection. Most telecommunication infrastructures rely on
the Internet Protocol and therefore telecommunication terminals commonly implement the IP layers as standardized by
the IETF RFC 791 [1] and by the new version in IETF RFC 2460 [7]. Connecting the UICC and the terminal at this
level is expected to bring the following advantages:
•
Leverage on existing standardization efforts: Applicative protocols relying on IP, e.g. running over TCP or
UDP, have already been standardized for a wide variety of applications and may be used by UICC
applications.
•
Minimize UICC-specific developments on the terminals; reuse what is already available on terminals rather
than forcing specific developments.
•
Facilitate connectivity of the UICC with standard network elements such as remote servers etc.
The present document focuses on the establishment and configuration of a generic IP connection between the UICC and
terminal, without addressing specific applications that may use this connection capability.
ETSI
Release 8
1
5
ETSI TS 102 483 V8.1.0 (2009-04)
Scope
The present document specifies the establishment and configuration of an Internet Protocol connection between a UICC
and a terminal interfaced through a protocol that supports the transport of Internet Protocol packets.
The way the Internet Protocol packets (or similar packets such as ARP) are transported over the UICC-Terminal
interface is part of the UICC-Terminal interface specification and not within the scope of the present document. The
present document focuses on the configuration and establishment of the Internet Protocol connection between the UICC
and the terminal.
The Internet Protocol connectivity defined in the present document may be used by applications such as the Smartcard
Web Server [i.7].
2
References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
•
For a specific reference, subsequent revisions do not apply.
•
In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version
of that document in the same Release as the present document.
•
Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
-
if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
-
for informative references, the latest version applies. In the case of a reference to an TC SCP document, a
non specific reference implicitly refers to the latest version of that document in the same Release as the
present document.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE:
2.1
While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1]
NOTE:
[2]
NOTE:
[3]
NOTE:
[4]
NOTE:
IETF RFC 791: "Internet Protocol".
Available from http://www.ietf.org/rfc/rfc791.txt.
IETF RFC 826: "An Ethernet Address Resolution Protocol".
Available from http://www.ietf.org/rfc/rfc826.txt.
IETF RFC 792: "Internet Control Message Protocol".
Available from http://www.ietf.org/rfc/rfc792.txt.
IETF RFC 793: "Transmission Control Protocol".
Available from http://www.ietf.org/rfc/rfc793.txt.
ETSI
Release 8
[5]
NOTE:
[6]
NOTE:
[7]
NOTE:
[8]
NOTE:
[9]
NOTE:
[10]
NOTE:
6
ETSI TS 102 483 V8.1.0 (2009-04)
IETF RFC 2449: "POP3 Extension Mechanism".
Available from http://www.ietf.org/rfc/rfc2449.txt.
IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers".
Available from http://www.ietf.org/rfc/rfc1122.txt.
IETF RFC 2460: "Internet Protocol, Version 6 (IPv6)Specification".
Available from http://www.ietf.org/rfc/rfc2460.txt.
IETF RFC 2463: "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6
(IPv6) Specification".
Available from http://www.ietf.org/rfc/rfc2463.txt.
IETF RFC 3022: "Traditional IP Network Address Translator (Traditional NAT)".
Available from http://www.ietf.org/rfc/rfc3022.txt.
IETF RFC 3314: "Recommendations for IPv6 in Third Generation Partnership Project (3GPP)
Standards".
Available from http://www.ietf.org/rfc/rfc3314.txt.
[11]
ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics
(Release 7)".
[12]
IETF RFC 4861: "Neighbor Discovery for IP Version 6 (IPv6)".
NOTE:
[13]
NOTE:
[14]
NOTE:
[15]
NOTE:
[16]
NOTE:
[17]
NOTE:
[18]
NOTE:
[19]
NOTE:
[20]
Available from http://www.ietf.org/rfc/rfc4861.txt.
IETF RFC 4862:"IPv6 Stateless Address Autoconfiguration".
Available from http://www.ietf.org/rfc/rfc4862.txt.
IETF RFC 4294: "IPv6 Node Requirements".
Available from http://www.ietf.org/rfc/rfc4294.txt.
IETF RFC 4291: "IP Version 6 Addressing Architecture".
Available from http://www.ietf.org/rfc/rfc4291.txt.
IETF RFC 2136: "Dynamic Updates in the Domain Name System (DNS UPDATE)".
Available from http://www.ietf.org/rfc/rfc2136.txt
IETF RFC 1035: "Domain names - Implementation and Specification".
Available from http://www.ietf.org/rfc/rfc1035.txt
IETF RFC 3490: "Internationalizing Domain Names in Applications (IDNA)".
Available from http://www.ietf.org/rfc/rfc3490.txt
IETF RFC 2131: "Dynamic Host Configuration Protocol".
Available from http://www.ietf.org/rfc/rfc2131.txt.
ETSI TS 102 600: "Smart Cards; UICC-Terminal Interface; Characteristics of the USB interface".
ETSI
Release 8
2.2
7
ETSI TS 102 483 V8.1.0 (2009-04)
Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1]
NOTE:
[i.2]
NOTE:
[i.3]
NOTE:
[i.4]
NOTE:
[i.5]
NOTE:
[i.6]
NOTE:
[i.7]
NOTE:
[i.8]
NOTE:
IETF RFC 2060: "Internet Message Access Protocol", version 4rev1.
Available from http://www.ietf.org/rfc/rfc2060.txt.
IETF RFC 2246: "The TLS Protocol", version 1.0.
Available from http://www.ietf.org/rfc/rfc2246.txt.
IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1".
Available from http://www.ietf.org/rfc/rfc2616.txt.
IETF RFC 959: "File Transfer Protocol (FTP)".
Available from http://www.ietf.org/rfc/rfc959.txt.
IETF RFC 821: "Simple Mail Transfer Protocol".
Available from http://www.ietf.org/rfc/rfc821.txt.
IETF RFC 1034: "Domain Names - concepts and facilities".
Available from http://www.ietf.org/rfc/rfc1034.txt.
OMA-TS-Smartcard-Web-Server-V1-0.
Available from http://www.openmobilealliance.org.
IETF RFC 768: "User Datagram Protocol".
Available from http://www.ietf.org/rfc/rfc768.txt.
[i.9]
ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT)".
[i.10]
IETF RFC 4632: "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and
Aggregation Plan".
3
Definitions and abbreviations
3.1
Definitions
For the purposes of the present document, the following terms and definitions apply:
application: computer program that defines and implements a useful functionality on a smart card or in a terminal
NOTE:
The term may apply to the functionality itself, to the representation of the functionality in a programming
language, or to the realization of the functionality as executable code.
file: directory or an organized set of bytes or records in the UICC
3.2
Abbreviations
For the purposes of the present document, the following abbreviations apply:
ARP
ASCII
Address Resolution Protocol
American Standard Code for Information Interchange
ETSI
Release 8
DHCP
FTP
HTTP
ICMP
IMAP
IP
NAT
POP
HTTPS
SMTP
TCP
TLS
UDP
URI
USIM
4
8
ETSI TS 102 483 V8.1.0 (2009-04)
Dynamic Host Configuration Protocol
File Transfer Protocol
HyperText Transport Protocol
Internet Control Message Protocol
Internet Message Access Protocol
Internet Protocol
Network Address Translation
Post Office Protocol
Secure HyperText Transport Protocol
Simple Mail Transfer Protocol
Transmission Control Protocol
Transport Layer Security
User Datagram Protocol
Universal Resource Identifier
Universal Subscriber Identity Module
Terminal-UICC IP configuration
This clause is an introduction to the various configurations and uses of the IP UICC. A UICC supporting IP will be
deployed with at least a local address. This address relates to a private network established between the UICC and the
terminal, independently from other networks to which the terminal may be connected.
The UICC shall be able to act as a combination of the following basic configurations:
•
A TCP/IP or UDP/IP client of a server located on the terminal.
•
A TCP/IP or UDP/IP server for a client located on the terminal.
•
A TCP/IP or UDP/IP client of a server located in a network reachable through the terminal.
•
A TCP/IP or UDP/IP server for a client located in a network reachable through the terminal.
Depending on the final applications, the actual configuration may be a combination of these basic configurations.
In the present document, the wording TCP/IP or UDP/IP protocol includes any application protocol such as HTTP,
FTP, POP, SMTP that may be enabled by TCP or UDP, i.e. the configuration targeted is not restricted to having a web
server and web client on the card.
ETSI
Release 8
4.1
9
ETSI TS 102 483 V8.1.0 (2009-04)
Local client on UICC
In this configuration the UICC is a client for TCP/IP servers located on the terminal. This configuration is the simplest
and does not require any routing or address translation. It requires however naming resolution inside the UICC, so that
the UICC applications can resolve the server IP address from the terminal name (localterminal).
Terminal
UICC
TCP/IP server
TCP/IP client
Name
Resolution
Figure 1
4.2
Local server on UICC
In this configuration the UICC is a local server for a TCP/IP protocol, e.g. HTTP. The server is accessed only from the
terminal. This configuration requires proper configuration of the terminal naming services, so that the terminal can
resolve the UICC name (localuicc) to the UICC IP address.
Terminal
UICC
TCP/IP Client
TCP/IP server
Name
Resolution
Figure 2
ETSI
Release 8
4.3
10
ETSI TS 102 483 V8.1.0 (2009-04)
Remote client UICC
This configuration allows the UICC to act as a client for TCP/IP servers located on the internet. The network
configuration requires the following:
•
naming services, so that the UICC can resolve the internet server name to the internet server IP address.
•
routing services on the terminal, so that the card can send/receive IP packets to/from the internet server
through the terminal
•
address translation when configured with an IPv4 address, so that on the internet, packets to and from the
UICC have the IP address of the UICC replaced by the IP address of the terminal
Operator’s network/
Internet
TCP/IP server
Terminal
UICC
routing
(address translation
in IP v4)
TCP/IP client
Name Server or
Name
Resolution
Figure 3
4.4
Remote server on UICC
This configuration allows the UICC to act as a server for TCP/IP client located on a remote network (subject to
limitations that may be set by the operator). The network configuration requires the following:
•
Naming services, so that the internet client can resolve the UICC server name to the UICC server IP address.
The way address resolution is performed in the network is out of the scope of this specification.
•
Routing services on the terminal, so that the UICC can send/receive IP packets to/from the internet client
through the terminal.
•
Address translation when configured with an IPv4 address, so that on the internet, packets to and from the
UICC have the IP address of the UICC replaced by the IP address of the terminal.
•
Port forwarding when configured with an IPv4 address, so that the incoming connection request on some given
port numbers will be rerouted to the UICC. For IPv4, two port numbers are defined by the IETF to be used by
smart cards. The terminal shall route all the incoming traffic to these port numbers to the UICC.
ETSI
Release 8
11
Operator’s network/
Internet
ETSI TS 102 483 V8.1.0 (2009-04)
Terminal
UICC
routing
(address translation
in IP v4)
Port forwarding
TCP/IP client
TCP/IP server
Name Server or
Name
Resolution
Figure 4
5
Protocol Stack
The protocol layers that are considered in this specification are represented in figure 5.
Application 1
Application 2
Application 3
Application 4
SMTP
HTTPS
Applications layer
described in
relevant
specifications
HTTP
TLS
Described in the
current document
Transmission Control (TCP)/ User Datagram (UDP) Protocols
Internet Protocol (IPv4/IPv6), ARP, ICMP
IP packets transport (e.g. Ethernet Emulation)
UICC - Terminal
Interface
UICC Terminal Interface
PHYSICAL LAYER
Figure 5: TCP/IP over UICC-Terminal Interface protocol stack
In figure 5, the IP, ARP, ICMP, TCP, UDP, TLS, HTTP and HTTPS layers are as standardized by the Internet
Engineering Task Force (IETF) in references indicated below.
A UICC and a terminal supporting the present specification shall support the following protocols:
•
IP V6 (Internet Protocol Version 6) [7], Neighbour discovery [12] and ICMPv6 (Internet Control Message
Protocol) [8].
•
IP V4 (Internet Protocol Version 4) [1] and ICMPv4 (Internet Control Message Protocol) [3].
ETSI
Release 8
12
ETSI TS 102 483 V8.1.0 (2009-04)
•
TCP (Transport Control Protocol) [4].
•
UDP (User Datagram Protocol) [i.8].
•
ARP (Address Resolution Protocol) [2] which is used to retrieve the MAC address when the UICC-Terminal
interface only carries Ethernet frames.
•
DHCP (Dynamic Host Configuration Protocol) [5] in client mode for the UICC.
Optionally, the following additional protocols may be supported:
•
DHCP (Dynamic Host Configuration Protocol) [5] in server mode for the terminal
•
TLS (Transport Layer security,[i.2]) or other Security protocols as profiled in relevant ETSI specifications.
•
DNS (Domain Name System) [i.6].
As an example applicative protocols could include HTTP (Hypertext Transport Protocol) [i.3] and
HTTP Over TLS [i.2]. Other applicative protocols such as FTP (File Transfer Protocol) [i.4], SMTP (Simple Mail
Transfer Protocol) [i.5], POP [5] and IMAP [i.1] may additionally be supported.
Applications needing to access information stored in the UICC file structure defined in TS 102 221 [11] may define
how this is performed using the applicative layer they rely on. For example, some applications may use HTTP URI
requests while others may rely on FTP.
6
UICC and Terminal components requirements
In the IETF terminology, an Internet communication system consists of interconnected packet networks supporting
communication among host computers using the Internet protocols. The networks are interconnected using IP routers or
gateways. A host computer is the ultimate consumer of communication services.
We follow here the Requirements for Internet Hosts as defined in RFC 1122 [6] for IPv4 and RFC 4294 [14] for IPv6.
6.1
UICC IP layer
Both IPv6 and IPv4 shall be supported, but support of IP fragmentation is not mandatory in IPv4.
6.1.1
IPv4 / IPv6 interworking
To ensure a smooth transition and deployments, it is important to provide the capability to support IPv4 in addition to
IPv6 for the foreseeable future.
Depending on the destination address, the UICC will use the IP layer that matches this IP address. However, local
communication between the terminal and the UICC shall use the IPv6 protocol, while the IPv4 layer is present to
provide support for remote connection in the case of a legacy IPv4-only infrastructure.
6.1.2
Address allocation
The main difference between IPv6 and IPv4 is the address allocation mechanism. Due to the large amount of addresses
available, there is no NAT mechanism for IPv6, every node connected on the network shall have its own address.
There are two possibilities to allocate the address of an IPv6 node - stateless and stateful auto configuration. The
stateful address allocation mechanism needs a DHCPv6 server to allocate the address. Following the IETF
recommendations for IPv6 [10], the UICC will implement stateless address configuration. In this case, the network
gateway assigns a prefix which is unique in the scope of a network activation (e.g. PDP context), the different nodes are
in charge of self assigning a unique interface identifier.
ETSI
Release 8
13
6.1.2.1
ETSI TS 102 483 V8.1.0 (2009-04)
Local Connection
The allocation of the local IPv6 address of the UICC shall follow these steps:
•
The UICC calculates its own local IPv6 address [13] from a unique value in the UICC (e.g. MD5 or SHA of
the ICCID) with the universal bit of the interface identifier set to 1 as defined in IETF RFC 4291 [15]. This
calculation can be done both in the network gateway and the UICC, avoiding creating a field in the subscriber
database.
•
The UICC sends a multicast Neighbor Solicitation message to the terminal. This message will be used by the
terminal to discover the UICC's address suffix.
•
The Terminal sends a Neighbor Advertisement message to the UICC using the previously discovered UICC
address. This message will be used by the UICC to get the terminal's address suffix. This specification makes
no assumption on the way to allocate the terminal address suffix. Support of duplicate address detection is not
required.
At this stage, the terminal and the UICC have established a local connection and resolved their respective addresses. It
should be noted that the stateless configuration is used for the local network configuration. The same procedure can be
used for a locally connected equipment.
6.1.2.2
Remote Connection
The establishment of a remote connection to the network gateway for the UICC is triggered by any packet sent by the
UICC with an address out of the scope of the local network. In IPv6, the first message sent by the UICC shall be a
router solicitation message.
6.1.2.2.1
IPv4 address allocation
The present version relies on either a fixed address allocation, statically allocated by the terminal and the UICC or
address allocation by a DHCP server in the terminal as follows:
•
UICC IP address: 192.168.0.1.
•
Terminal IP address: 192.168.0.2.
In case a DHCP server is present in the terminal, the UICC shall use this DHCP. The DHCP client and server shall
behave as follows:
DHCP Discover:
To minimize traffic between the DHCP client and server, the DHCP client shall not include any option in the request.
DHCP Offer:
To avoid a situation where the UICC is replaced and the IP address never comes back to the DHCP server, the DHCP
client shall always start in INIT state (see RFC 2131 [19]) whenever the layer transporting the IP packets enters
operational mode. The DHCP server shall reassign the UICC IP address when receiving a DHCP discover and shall
probe the UICC IP address before reassigning it.
It is recommended to reduce the network load from the renewal request traffic. Therefore the DHCP server shall use
infinite lease. In addition, and to reduce the amount of data transmitted between the DHCP client and server, the DHCP
server shall only use the "Server Identifier" and the "IP address lease time" options.
NOTE:
When the layer transporting the IP packets leaves operational mode, the DHCP server may release all IP
addresses allocated on the UICC interface.
For an underlying layer according to TS 102 600 [20], entering operational mode happens when the UICC is configured
and leaving operational mode happens when the UICC leaves Configured state - except for Suspended state.
ETSI
Release 8
6.1.2.2.2
14
ETSI TS 102 483 V8.1.0 (2009-04)
IPv6 address allocation
The UICC sends a router solicitation message to the terminal
If the terminal needs some network activation parameters, they should be retrieved as described in clause 6.4. The
terminal does the network activation if no appropriate connection is available.
The terminal sends back a router advertisement message to the UICC. This message may be generated by the terminal
itself or be a forwarded from the network.
Based on the previously received message, the UICC set its address prefix according to the prefix received in the router
advertisement. The UICC is now ready to send messages over the network.
6.2
Local naming
To resolve the local name of the UICC / the terminal, the following mechanisms shall be implemented in the
terminal / the UICC.
6.2.1
Predefined names
In order to facilitate application development and interoperability, the ME shall be referenced by localterminal and the
UICC by localuicc.
6.2.2
Names provided by the UICC
If applications on the UICC require the use of customised names for their access from the terminal side, the following
mechanism shall be used by the UICC to provide names to the terminal. Requests by applications on the terminal using
these names shall be resolved to the UICC.
A subset of the DNS UPDATE message encapsulation according to RFC 2136 [16] shall be implemented on the
terminal.
After resolution of its IP address, a UICC requiring customised name(s) shall send a DNS update message to the
terminal. The message shall have the following settings:
•
transport protocol: UDP;
•
server port on the terminal: 53;
•
ZOCOUNT, PRCOUNT and ADCOUNT are all zero (no zone, prerequisite and additional data);
•
the update section contains one or more RRs (resource records).
The RRs shall have the following settings:
•
NAME: domain name to be associated to the IP address
•
TYPE: A for IPv4, AAAA for IPv6;
•
CLASS: IN (internet)
•
TTL: 'FF FF FF FF' (unlimited time to live)
•
RDATA: IP address
Thus each message will consist of the header section and one resource record per name as specified in RFC 2136 [16]
and RFC 1035 [17].
The domain names shall be coded as defined in RFC 1035 [17], i.e. using ASCII characters, or as defined in
RFC 3490 [18] for internationalized domain names.
The terminal shall respond with a message as defined in RFC 2136 [16] section 3.8 with ZOCOUNT, UPCOUNT,
PRCOUNT and ADCOUNT set to zero.
ETSI
Release 8
15
ETSI TS 102 483 V8.1.0 (2009-04)
A new message shall completely replace previous information. If the update section is empty, no customised names
shall be associated to the UICC.
NOTE:
Terminal behaviour in case of collisions between names in the internet and names requested by the
UICC is undefined. So name collisions should be avoided.
6.3
Summary of terminal and UICC configuration
6.3.1
UICC Configuration
6.3.1.1
IP v4
If there is no DHCP server in the terminal, the IP address is: 192.168.0.1.
If there is a DHCP server in the terminal, the IP address is allocated by this DHCP server.
Network mask: 255.255.255.0.
Operator's name server.
In case there is no DHCP server in the terminal, the UICC network routing table shall be the following:
Network Destination Gateway
Netmask
Interface
192.168.0.0
*
255.255.255.0 UICC-Terminal interface
127.0.0.1
*
255.0.0.0
Loopback interface
6.3.1.2
IP v6
In IP v6, the UICC address shall be dynamically configured according to stateless configuration mode [13].
6.3.2
6.3.2.1
Terminal Configuration
IP v4
If there is no DHCP server in the terminal, the terminal shall use: IP address 192.168.0.2, network mask: 255.255.255.0.
If there is a DHCP server in the terminal, the IP address is allocated by this DHCP server.
In case there is no DHCP server in the terminal, the terminal network routing table shall be the following:
Network Destination
192.168.0.0
127.0.0.1
Gateway
*
*
Netmask
255.255.255.0
255.0.0.0
Interface
UICC-Terminal interface
Loopback interface
The network routing table shall be completed according to the activation parameters provided by the currently active
Network Access Application.
6.3.2.2
IP v6
In IP v6, the terminal address shall be dynamically configured according to stateless configuration mode [13]. The
network routing table shall be completed according to the activation parameters provided by the currently active
Network Access Application.
ETSI
Release 8
16
6.4
Terminal IP Components
6.4.1
Connection setting
ETSI TS 102 483 V8.1.0 (2009-04)
The network activation by the terminal for the UICC is triggered by an IPv6 router solicitation message sent by the
UICC, or by any message sent by the UICC to a non local address when using IPv4. The terminal may use an already
existing network activation context provided that its parameters are compatible with those requested by the UICC.
Otherwise a new network activation shall be done.
The way to retrieve the network activation parameters to be used by the terminal for the UICC shall be specified by the
Network Access Application. Network activation parameters shall be retrieved each time the Network Access
Application providing network connectivity is initialized or if the NAA indicates to the terminal that an update has
occurred (e.g. by means of a REFRESH proactive command, see TS 102 223 [i.9]).
6.4.2
Routing, Network Address Translation and port forwarding
The terminal shall forward incoming IP packets from the UICC to the Internet interface using the UICC APN, and
responses from the network to the UICC.
When IPv4 addresses are used, the terminal shall perform Network Address Translation (NAT) as per RFC 3022 [9], so
that the UICC can perform IP sessions with external servers.
The incoming remote IPv4 connections to the following TCP / UDP ports shall also be forwarded to the UICC:
smartcard-port
smartcard-port
smartcard-tls
smartcard-tls
3516/tcp
3516/udp
4116/tcp
4116/udp
Smartcard Port
Smartcard Port
smartcard-TLS
smartcard-TLS
In IPv6 since the UICC has its own public address no port forwarding or NAT mechanism is necessary.
ETSI
Release 8
17
ETSI TS 102 483 V8.1.0 (2009-04)
Annex A (informative):
Connection of a local equipment to the terminal and UICC
It is assumed that configurations similar to those described in the present document may also be available for an
equipment locally connected to the terminal. Such connections are device dependent and should therefore be specified
on an application basis. Depending on the terminal configuration, NAT and port forwarding may not be necessary in the
terminal.
Locally connected
device (e.g. PC)
Terminal
UICC
routing
TCP/IP client/
Server
Name Server or
Name
Resolution
Figure A.1
ETSI
TCP/IP server/
Client
Release 8
18
ETSI TS 102 483 V8.1.0 (2009-04)
Annex B (informative):
Example of activation parameters
The activation parameters that are necessary to initiate a connection depend on the network technologies. This annex
provides an example of activation parameters that are provided by a NAA.
The NAA provides a list with a sequence of entries. Each entry contains the following data items:
•
Address type (IPv4 or IPv6).
•
Address range, defined as address prefix.
•
Network Access Name (gateway to external packet network).
•
Bearer Description.
Network Access Name and Bearer Description are described in TS 102 223 [i.9] under the description of the OPEN
CHANNEL proactive command related to Packet Data service bearer. If these are missing, the terminal uses settings
from the terminal configuration or the default subscription values.
The list is ordered according to the priority of the entries, i.e. entries with higher priority come first. When IP packets
originating from the UICC are to be sent to an external destination, the terminal checks the list starting from the
beginning. The parameters of first entry where address type matches and the destination address of the IP packet is
within the given address range are taken to forward the IP packet.
It is recommended to end the list with "all addresses" entries (having a prefix length of zero) which are used if no other
entry matches.
Example for a list of activation parameters:
Entry #
Address type
Address prefix
Network Access Name
Bearer Description
1
IPv4
88.224.64.00/20
service.mno.net
packet data service
2
IPv6
2001:DB8:0:CD30::/60
special.net
packet data service
3
IPv4
0.0.0.0/0
web.mno.net
packet data service
4
IPv6
2001::/16
portal.mno.net
packet data service
5
IPv6
::/0
v6web.mno.net
packet data service
NOTE:
For the notation of IPv4 address prefixes see RFC 4632 [i.10]; For the notation of IPv6 address prefixes
see RFC 4291 [15]. The number after the slash defines the number of valid bits of the prefix. It is
recommended to define a data format where trailing zeros can be omitted.
Explanation of the example:
IPv4 packets to addresses from 88.224.64.0 to 88.224.79.255 are routed via gateway "service.mno.net" (entry 1), all
others are routed via gateway "web.mno.net" (entry 3).
IPv6 packets to addresses from 2001:DB8:0:CD30:: to 2001:DB8:0:CD3F:FFFF:FFFF:FFFF:FFFF are routed via
gateway "special.net" (entry 2), other IPv6 packets from 2001:: to 2001:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF are
routed via gateway "portal.mno.net" (entry 4), and all others are routed via gateway "v6web.mno.net" (entry 5).
ETSI
Release 8
19
Annex C (informative):
Bibliography
•
IETF RFC 4311: "IPv6 Host-to-Router Load Sharing".
NOTE:
Available from http://www.ietf.org/rfc/rfc4311.txt.
ETSI
ETSI TS 102 483 V8.1.0 (2009-04)
Release 8
20
ETSI TS 102 483 V8.1.0 (2009-04)
Annex D (informative):
Change history
The table below indicates all changes that have been incorporated into the present document since it was placed under
change control.
Date
2007
Meeting
SCP-33
SCP-33
Plenary Doc CR Rev
SCP-040416 001
SCP-040417 002
2008
SCP-35
SCP-080020 003
2008
2008
2008
2009
SCP-37
SCP-39
SCP-39
SCP-40
SCP-080211
SCP-080429
SCP-080429
SCP-090027
004
006
005
007
-
Change history
Cat
Subject/Comment
Old New
D Editorial corrections and clarifications
7.0.0 7.1.0
C Clarification of the use of terminal DHCP server 7.0.0 7.1.0
according to action point 31/01 from SCP#31
B Addition of a naming mechanism based on DNS 7.1.0 7.2.0
UPDATE
F Clarifications for UICC provided names
7.1.0 7.2.0
F Clarifications on DHCP support
7.2.0 7.3.0
C Alignment with 3GPP on External link control
7.3.0 8.0.0
D Update of Annex B
8.0.0 8.1.0
ETSI
Release 8
21
History
Document history
V8.0.0
January 2009
Publication
V8.1.0
April 2009
Publication
ETSI
ETSI TS 102 483 V8.1.0 (2009-04)
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising