GPRS - IP Address & Naming Options

Adrian F Pauling

Contents:

• Executive Summary
  
• Overview of GPRS Service Provision
  
• Technical Options and Opportunities
  
• Impact on Regional Internet Registry
  
• Recommendations for Discussion
  
• Glossary, References & Acknowledgements
  
• Appendix 1 - Potential IP Addressing Schemes in GPRS
  
• Appendix 2: Overview of Internet Naming and Numbering
  

This is a discussion paper outlining the requirements for the use of IPv4 address space within the GPRS (General Packet Radio Service) Mobile Phone environment.

Various mobile network operators across the world have been developing a new GPRS network that will employ packet switching, instead of the traditional circuit switching techniques, to convey data across the mobile network. GPRS is an enhancement of the existing digital GSM voice-based network. Higher data rates than those currently provided by existing GSM data services will be possible, to enable high-speed mobile data applications to be supported. GPRS will also be used as a stepping stone to the introduction of the third-generation (3G) mobile networks: initial trials/implementation are expected from 2002 onwards.

GPRS has two separate addressing requirements: addressing nodes in the GPRS infrastructure, and addressing mobile handsets. This document discusses the IPv4 addressing requirements of the operational command and control aspects of the GPRS infrastructure only: the IP address requirement for mobile handsets as part of GPRS Service Provision is outside the scope of this document.

This paper is a result of the GPRS presentation (on behalf of the GSM Association ) to the European Operators Forum at the last RIPE meeting (RIPE35). The proposal was to use a dedicated Class A or "/8" assignment for GPRS command and control networks, but there was some debate regarding the suitability of the use of IPv4 registered addresses, and the amount of addresses required. There was considerable interest in this presentation and an alternative, the use of RFC1918 addresses, was proposed and debated. Several factors became apparent, most notably the fact that most attendees could not appreciate all of the issues involved because they were not familiar with the details of GPRS. Furthermore, there was significant concern regarding how, if registered addresses were used, these addresses would be managed and allocated.

It was hoped to gain approval for the proposal of using a Class A for this purpose, but it soon became clear that this was not immediately acceptable. Given the timescales required by the GPRS operators for their policy to be formulated and agreed, it was the agreed to form a small Task Force of both mobile operators and Internet engineering experts to produce a solution for the way forward. This Task Force has now been formed.

This paper acts as input to the debate. It assumes that the reader is familiar with IP networking technical terms in general, and is aware of the issues surrounding the conservation of IPv4 address space. Familiarity with RFC's 1918 and 2050 and RIPE document 185 is assumed, plus an understanding of Network Address Translation and Proxy Server technology.

There are a number of IP networked elements involved in the command and control of GPRS Service Provision, and it is important to note that IPv6 is not an option: GPRS equipment vendors will not support IPv6 for 2 more years. Hence, all operational GPRS network deployment is based on IPv4. A GPRS operational network consists of a combination of the five following separate hardware/software combinations, each with its own functionality:

(i) Public Land Mobile Network, PLMN: This consists of several basic IP network building blocks, including: routers, Local Area Network, LAN segments for GGSN, SGSN, HG and any appropriate Firewall System(s), Wide Area Network, and WAN links over various assorted media dependent on the choice of the GPRS Service Provider. WAN links can be point-to-point SDLC/HDLC-based serial links from 64K serial to Dense Wave Division Multiplexing, DWDM, or X25, Frame Relay or ATM Permanent Virtual Circuits, PVCs, i.e. any WAN media.

(ii) Serving GPRS Support Node, SGSN: equipment which terminates the layer 2 mobile call and changes the layer 2 functionality from mobile/radio connectivity to the PLMN-based traffic for the IP session of the user. The SGSN maintains the session with the cell-to-cell transitions without loss of the session.

(iii) Gateway GPRS Support Node, GGSN: gateway providing the IP point of interconnect outside of a particular GPRS Service Provider's network. The GGSN is a combination of IP routing and GPRS- specific functionality to support "roaming" users.

(iv) Home Gateway, HG: As part of the GPRS Service Provision, home gateways into Corporate / Enterprise network environments are envisaged. In such circumstances, the IP addresses supplied to the handsets will be assigned via PPP, DHCP or similar technology, from ranges of the Corporate Network Customers' IP addressing plan - typically involving the use of RFC1918 assigned addresses, over layer two tunnels from these HGs across the GPRS infrastructure.

(v) Inter-PLMN: the interconnect with other GPRS Service Providers .In order to provide a Roaming service, where GPRS Users can transparently use any GPRS Service Provider, there must be an interconnect backbone between all GPRS Service Providers. This is covered more fully in the Roaming section below, but is similar in nature to the Intra-PLMN in terms of hardware and communications links.

Currently GPRS networks are private, stand alone, networks. However, the aim is for GPRS operators to interconnect to form a large public roaming network. Such a facility allows users to use another GPRS Service Provider transparently, whilst in reality the traffic is tunnelled via another GPRS Service Provider back to the Home GPRS Service Provider network for the individual user. A key protocol in the GPRS Service Provision is the GPRS Tunnelling Protocol, GTP.

The Inter-PLMN backbone itself may in some cases be part of the Internet i.e. the Internet could be used in some instances to connect GPRS operators together. Multiple GPRS Service Providers will provide this backbone, and the central management of these multiple networks supporting public services is the role of the GSM Association.

As part of the GPRS Service Provision, home gateways into Corporate/Enterprise environments are envisaged, with the provision of Home Gateways for Corporate customers. Up to 2300 Home Gateway systems is one estimate of the scale of the deployment across all GPRS Service Providers.

One set of estimates for a 5 year time frame for deployment of the GPRS Technology as a whole to support Roaming is 672 SGSNs, 136 GGSNs, and 26 support servers. One supplier's system requires 3 IP addresses per SGSN. Hence, the overall IP addressing requirement for an individual GPRS Service Provider may not actually be that high.

To summarise, there are 350 GSM operators around the world that need to connect their GPRS infrastructure together. The network formed does necessarily need to connect to the Internet directly, but it is a public service network. Each network needs to address some 5000 devices and so needs at least 3.5 Million IP addresses, and probably nearer to 35 Million in the longer term. Hence, a single "/8" should cover the GPRS requirements generically.

A policy is requested from the RIR authorities to clarify whether public registered addressing can be allocated for use in the GPRS IP data network backbones.

The GPRS Inter-PLMN network backbone for roaming cannot be realised until the addressing policy has been defined and agreed. All the GPRS network operators must subscribe to the same addressing policy in order for roaming to operate. Operators deploying different addressing schemes will not be able to interconnect to one another, hence limiting the GPRS data services available to users when they are roaming in these operators?countries.

The GPRS roaming backbone could be viewed as existing in a private network domain if it cannot be accessed via the Internet, e.g. using leased lines from International Data Service (IDS) carriers only. However, the IDS carriers are expected to provide the majority of the network required for the roaming backbone, leased lines being relatively expensive. During initial start-up of the service, initial roaming trials interconnecting networks in different countries may be conducted using the Internet as part of the roaming backbone. Registered addressing will be required for this type of implementation.

Inter-PLMN connectivity via the Internet may be the ideal solution for some of the smaller GPRS Operators. The Internet may evolve to support similar capability as currently offered by the IDS carriers in terms of quality of service, performance, bandwidth and security. The Internet could thus be considered as a more cost-effective medium for the GPRS roaming backbone to carry some or all of the GPRS international traffic. Registered addressing deployed now will significantly ease any future migration to use the Internet as the GPRS roaming backbone.

The addressing policy agreed to by either the RIR Authority or potentially ICANN-ASO will be used by IREG to define the guidelines for a common IP addressing scheme for adoption by all the GSM PLMN operators. Hence, a single point of contact for all IP addressing requirements for the GPRS Service Providers command & control networks is a clear requirement.

As previously stated, the requested IPv4 addressing policy is only for application to the GPRS network backbone infrastructure and not for mobile handsets. Currently some GSM operators have obtained permission from their LIR's to use registered IP addresses only for their infrastructure command & control networks for GPRS Service Provision, to enable them to be a GPRS Service Provider.

There is a requirement for firewalls between the GPRS Service Providers?command & Control networks, and between each other and the Internet. These firewalls prevent unwanted and inappropriate traffic gaining access to a GPRS Service Provider's command & control network.

In the initial release of GTP, the protocol can not work across Network Address Translation, NAT, due to embedded IP addresses within the application. IP addresses are embedded for security. It is understood that GTP is being enhanced to support NAT functionality, but this feature will not be available until late this calendar year for pilot and trial purposes, and hence not available for deployment into production networks until the next calendar year.

NAT provides an address translation function, e.g. converts an external network protocol address into an internal network address. It can be implemented �transparently?at the network's stub domain border router that separates an organisation's private intranet from the public Internet domain.

NAT was originally developed as an interim solution to the IPv4 address exhaustion problem until the availability of IPv6. It provides mechanisms to enable re-use of addresses to help conserve the available IPv4 address space. However, there are a number of drawbacks with its use.

Generally, address re-writing leads to the complexity of diagnosing operational problems, as it becomes more difficult to reliably establish the true source and/or destination of a packet. Because of source address re-writing, the traditional end-to-end significance of an IP address is lost. Hence, although TCP connections are still end-to-end (NAT box being �transparent?, the NAT can impact TCP's performance. If a GPRS Service Provider network has multiple entry/exit points, the border router NATs must ensure their address mapping tables are identical. This adds to the NATs complexity and manageability. There may be scaling issues when NAT is used in large networks, making networks complex and difficult to manage and, in some cases, leading to performance problems.

IPSec is not fully supported by NAT as it uses embedded IP addresses. IPSec provides a security mechanism to access corporate networks via the public Internet. However, in theory, the NAT limitation could be resolved by ignoring the embedded IP address, whilst maintaining security identification via key exchange. Further investigation is required to verify if this resolution is actually feasible.

If NAT is used with a 10.0.0.0/8 GPRS Command & Control backbone, then guidelines to ensure this addressing scheme is not used in any other PLMN operator's intra-PLMN backbone network must be provided. This is to avoid duplication of IP addresses within the same autonomous environment of GPRS command & control.

However, irrespective of the addressing scheme selected for the inter-PLMN backbone, some PLMN operators may still want to use NAT to allow a separate private addressing scheme to be used in their intra-PLMN backbone.

IP bearer network elements within a PLMN are only of significance to that individual GPRS Service Provider. However, there may be a requirement to share the operational status of a router network and associated LAN/WAN connectivity between GPRS Service Providers for operational reasons. Such information sharing would only occur on a read-only basis. Hence operational network status could be provided by proxy server technology or SNMP alarm gathering system or similar.

SGSN, GGSN and Home Gateways must be uniquely identifiable within the GPRS technology deployment on a global basis. This is to ensure scalability and interoperability between GPRS Service Providers and to support the roaming facility. Such uniqueness can only be provided via either a co-ordinated RFC 1918 addresses amongst all GPRS Service Providers (negating the potential to use RFC1918 addresses within each of their own Intra-PLMN networks), or via globally unique registered addresses. This requires all GPRS Service Providers to agree with the appropriate scheme. The alternative to the support of global uniqueness is that of using globally unique IPv4 addresses from an appropriate LIR.

Initial roaming trials with foreign operators can be conducted with whatever scheme is currently deployed in each respective network, provided that there is no duplication of network addresses across any of the networks. However, reconfiguration work of each GPRS Service Providers operational network may be required subsequently, depending on the address scheme deployed during trials.

The backbone will require uniqueness between all operators in a co-ordinated manner. This could be via RFC 1918 addresses as this is only a transit network for the GTP tunnels between source GPRS Service provider and the terminating home GPRS Service Provider. Initial roaming trials with foreign operators can be conducted with whatever scheme is currently deployed in each respective network, provided that there is no duplication of network addresses across any of the networks.

This backbone could use either a Public or Private addressing scheme. The use of a public addressing scheme has the following advantages:

• IP administration and control processes are already in place to provide a global service by the Regional Internet Registries (RIR) authorities.
• using a public addressing scheme now will greatly simplify the possible future transition to use the public Internet for part of or all of the GPRS backbone. However, this will depend upon the Internet being capable of:
• supporting Quality of Service (QoS) capabilities, i.e. capable of providing greater control over the network's data transmission characteristics, e.g. latency, throughput, reliability and priority.
• providing a secure network.

A Class A (or /8) address range could be requested for this purpose from the RIR authorities.

The RIR authorities are unlikely to approve the use of public addressing if the GPRS backbone exists in the private domain only.

Alternatively, a private addressing scheme could be used, using 10.0.0.0/8 for this purpose.

Once an addressing scheme has been identified, it is proposed that specific network ranges should be allocated for the use of each GPRS Service Provider. This will simplify the address management and administration process, and the numbering proposals will be presented to the GSM Association/IREG for agreement and acceptance for use within the GSM community.

If a single "/8" was assigned for GPRS command and control purposes, the network would operate and perform optimally. IP address summarisation plans could easily be achieved by the governing assigning authority. GPRS addressing would be easily identifiable

There is in principle no requirement for extra AS numbers. This assumes no requirement for dynamic interconnection between the Internet and the Command & Control for GPRS Service Provision for IP routing purposes. Command and Control networks are typically Firewalled from other networks, and Firewall systems do not allow dynamic routing of any nature, with all IP routing static.

RFC 1930 outlines the private AS numbering schema, the equivalent to RFC 1918 for AS numbers. Use of RFC 1930 AS numbers in the Inter-PLMN environment is an option, but would require a single authority for the allocation and co-ordination for the AS numbers.

From the two distinct uses of IP by GPRS, each GPRS Service Provider will require IP addresses for two separate uses. Firstly, an LIR for the "ISP" type registry for the allocation of IP addresses to the customers of the GPRS Service Provider. Secondly, IP addresses for the GPRS Service Provider's own GPRS command & control network. For this section reference will be made to RIPE processes and documents, which are not be applicable in other global geographic regions, but do have equivalents.

For the provision of IP services to the GPRS Customer base of a Mobile Phone operator, the operator will be required to obtain globally unique IP address space for the customer base. Where the IP addresses are assigned from depends on their proposed connectivity to the Internet. The 3 potential LIR sources for the provision of IP address space for the GPRS Service Provider are as follows:

GPRS Service Provider Command & Control

For the User traffic bearer and command & control infratsructure aspects of the GPRS Service Providers?own internal backbone, certain devices require globally unique IP addresses. In this scenario, the GPRS Service Providers' infrastructure will be multi-homed into the appropriate Inter-PLMN between the GPRS Service Providers, in a static manner. RIPE Document 185 has many detailed policies within that require consideration.

Use of PI Addresses may cause potential connectivity problems, and the peering arrangements of ISPs would need to be examined by the GPRS Service Provider. A check on the minimum route advertisement size carried by the ISPs would be required. End-to-end path scenarios where the Internet is used to provide Inter-PLMN connectivity would require regular checks to ensure reachability across the Internet accordingly, including route advertisements in BGP. Some ISPs may decline to route PI space, even where they are the sole ISP, unless they are the assigning LIR.

It is unclear whether Enterprise LIRs should be created by GPRS Service Providers to allow them to use globally unique IP address space. Where an organisation already has an Enterprise LIR, such as BT, guidance regarding the suitability of assigning for GPRS usage is required.

Also, although 158.230.0.0/16 is assigned to Cellnet, this was before their acquisition by BT. It is unclear whether this assignment should now come under the BT Enterprise registry, which also has ARIN address space as well as RIPE addresses. This is a policy question regarding re-use of existing assigned address space, as the address space could be re-used for GPRS command & control purposes.

Smaller or start-up operators that do not currently connect to the Internet may have difficulty in justifying the requirement for registered addressing. They are unlikely to meet the minimum requirements to become an Enterprise LIR, with command & control aspects of their GPRS network for roaming backbone alone.

A clear policy from the RIR authorities to use registered addressing could be presented to the organisation assigning the GPRS Command & Control address space as part of the address plan, hence clarifying any potential confusion that may arise.

The GSM Association aims to provide a common set of guide lines to their members on how to go about starting GPRS Service Providers. The geographically based model of the RIRs makes the deployment of the GPRS technology in a central globally co-ordinated manner difficult. The processes outlined within this paper are generally specific to RIPE, and hence generically the same as APNIC. However, in the US region the processes for becoming an LIR, requesting IP address space and AS numbers, and IP routing information are different: both ARIN and MERIT provide similar functionality to RIPE & APNIC, but with different procedures. Not having identical procedures across all RIRs potentially slows down deployment of GPRS for Global GPRS operators (admittedly a small proportion of the overall total), as central advice on IP addressing issues from the GSM Association is more difficult to derive.

An option is for the GPRS to utilise a currently unassigned "/8". If such an approach was taken, it is not clear whether such an approach should go via an RIR, or direct to ICANN-ASO for direct consideration and appropriate assignment.

• a "/8" should be assigned for the GPRS command & control, to be owned centrally by the GSM Association on behalf of all GPRS operators.
• Consideration of the GSM Association becoming a RIPE LIR, though their user base is global.
• Should an existing registry, such as RIPE, or setting up a dedicated registry, be used for supply of IP addresses to GPRS Service Providers? Such a registry would base its operating model on that of RIPE, but for use exclusively by GPRS Service Providers for their Command & Control networks.
• a policy derivation process should be initiated to establish the potential re-use of IP addresses of older ARIN assigned address space. Such policy must cover Enterprise LIRs, the potential recovery of the address space, its re-use and which RIR should be used to store information on in the case where an organisation has assignments from multiple RIRs.
• a policy for the derivation of Internet connectivity options for GPRS Service Providers should be initiated.

• Proposal for a policy to use Public Registered Addressing to support GPRS Roaming Services (008_C_0030_Proposal_for_RIPE_Iss_1.doc)
• 008_A_0023 Minutes - Genie_Roaming IP addr reqts.doc
• GSM Association
• Various e-mails from Kim Fullbrook, Paul Mylotte, Peter Willis, Malra Jarnail, Scott Bailey.
• RFCs 1918, 1930, 2050 ; RIPE-160, 185
• http://www.ripe.net/ripe/archive/ripe-35/presentations/ripe35-gprs-KF/index.html

Acknowledgements

The assistance of Paul Mylotte in the creation and refinement of this report is gratefully acknowledged by the author.

The author of this document may be contacted at:

Adrian F Pauling
Internet Protocol Manager
PPHW D117
PO Box 200
London
N18 1ZF

Tel: +44 19 2685 1992
Fax: +44 19 2685 1992
Mobile: +44 78 0290 4877
E-mail: adrian.pauling@bt.com

Where GCC is GPRS Country Code, GNC is GPRS Network Code, GHC is GPRS Host Code

Large Networks: Range 10.0.0.0/8 to 10.255.255.255

Class A - 00001010 C₇C₆C₅C₄C₃C₂C₁C₀ N₄N₃N₂N₁N₀ H₁₀H₉H₈ H₇H₆H₅H₄H₃H₂H₁H₀

Medium Networks - Expansion: Range 172.16.0.0/12 to 172.31.255.255

Class B - 10101100 XXXY₄Y₃Y₂Y₁Y₀ C₄C₃C₂C₁N₄N₃N₂N₁ N₀H₇H₆H₅H₄H₃H₂H₁H₀

Small Networks - Reserved Expansion: Range 192.168.0.0/24 to 192.168.255.255

Class C - 11000000 10101000 C₆C₅C₄C₃C₂C₁C₀N₂ N₁N₀H₅H₄H₃H₂H₁H₀

Option 2 - GOC and GHC:

Where GOC is GPRS Operator Code, GHC is GPRS Host Code

Large Networks: Range 10.0.0.0/8 to 10.255.255.255

Class A - 00001010 O₇O₆O₅O₄O₃O₂O₁O₀ O₁₀O₉O₈H₁₂H₁₁H₁₀H₉H₈ H₇H₆H₅H₄H₃H₂H₁H₀

Medium Networks - Expansion: Range 172.16.0.0/12 to 172.31.255.255

Class B - 10101100 XXXY₄Y₃Y₂Y₁Y₀ O₄O₃O₂O₁O₀H₁₀H₉H₈ H₇H₆H₅H₄H₃H₂H₁H₀

Small Networks - Reserved Expansion: Range 192.168.0.0/24 to 192.168.255.255

Class C - 11000000 10101000 C₆C₅C₄C₃C₂C₁C₀H₈H₇H₆H₅H₄H₃H₂H₁H₀

Naming and Numbering on the Internet started off being managed on a central basis within the US. Essentially, up until the early-mid 90s' all requests went to the Internet Network Information Centre, InterNIC. The model was that of central US Government funding, and hence IP addresses were 'free' for everyone, and names were charged on a cost recovery basis. More specialised numbers within the IP protocol suite were monitored by the Internet Assigned Numbers Authority, IANA. An Internet Architecture Board was set up to monitor and ensure management of IANA and InterNIC. However, phenomenal growth meant the model had to change.

RIPE (R?eaux Internet Protocol Europ?ns) was formed in the early-mid 90s' to handle aspects of IP address assignment for European Internet Service Providers, ISP. RIPE is a not - for - profit organisation, formed by an open membership of ISPs. RIPE derived a set of processes, procedures and policies for the assignment of IP addresses to ISPs (RIPE-185 refers). These are reflected typically in the RIPE documents, and in some instances Request for Comments paper, RFCs. RIPE developed a model where the Regional Internet Registry, RIR, operating a central registry service for IP assignments to Local Internet Registry's, LIR's. Everyone who has IP addresses assigned from RIPE must operate an LIR, and though the vast majorities are ISPs, there are a few 'Enterprise' LIRs for corporate to assign IP addresses global uniqueness, where appropriate.

Now, the Internet Corporation for Assigned Names & Numbers, ICANN, is the organisation with ownership of the numbering and naming processes within the Internet community. ICANN has 3 prime supporting organisations, for addressing (ASO), (domain) naming and protocols. Global addressing policy is set out in RFC2050, and the geographically based RIRs, report to the ICANN-ASO. The InterNIC separated into two organisations in 1998, Network Solutions (now owned by Verisign) for Domain Names, and the American Registry for Internet Numbers, ARIN, for IP addresses. The Asia-Pacific Network Information Centre, APNIC, formed a couple of year after RIPE, and hence the prime RIRs are APNIC, ARIN and RIPE. Though RIPE and APNIC have very similar processes and procedures, ARIN's are slightly different. Each registry also has its?own set of policies, though they are in broad alignment.

Another important RFC regarding IP addressing is RFC1918, which outlines a schema for private IP addressing schemes within large Corporate and Enterprises. This sets aside certain address blocks that are not to be routed on the Internet itself by convention, but are for use within a single, managed, autonomous, IP networked environment.

Back to Documents Index

Back to SIG Index