Friday, March 19, 2010

IPv6 transition in cellular networks gaining momentum


IPv6 is good and we all know that. I has been talked for years but practically it hasnt found much success. Verizon made some noise last year but I am not sure of the conclusion.

Just to recap, IPv4 was introduced back in 1982 and IPv6 work started since 1995. IPV4 uses 32 bit (4 bytes) addresses while IPV6 uses 128 bit (16 bytes) addresses. Theoretically we would now have 2^96 times more addresses than in case of IPv4.

Most of network infrastructure manufacturers have their equipment ready for IPv6 as some of the handset manufacturers. The main driver being that someday soon IPv4 addresses would be exhausted (Internet Assigned Numbers Authority will run out of IPv4 addresses in September of 2011, based on current projections) and their equipment would be ready to provide IPv6 addresses without any problems.

Recently, IETF-3GPP Workshop on IPv6 in cellular networks was held in San Francisco, USA on 1 - 2 March, 2010. There are lots of interesting presentations available here for people who want to dig a bit deeper. The concluding report that summarises the presentations and discussions are available here. Here is a brief summary from one of the reports (with links at the end):

Summary
  • Scenarios for IPv6 migration were discussed based on 3GPP Technical Report 23.975
    • The discussion focused on validating the scenarios
  • General IPv6 transition and deployment guidelines were outlined based on input from IETF
  • Solutions for migration and v4-v6 co-existence were presented
    • Solutions included existing RFCs and working group items but also proposals in Internet Drafts
    • Gap analysis wrt transition scenarios was discussed

Conclusions on scenarios
  • Scenarios 1 and 3 based on dual-stack and IPv6-only deployments were generally recognized as valid
  • Scenario 2 was also recognized as valid, addressing two separate problems related to insufficient RFC1918 space and subscriber identification
  • Scenario 4 did not receive wide support from the workshop, largely because it was felt that it addressed a problem already solved by other scenarios
  • Variants of some of these scenarios were brought up during the discussions, conclusions were not reached on these
    • These may need further discussion

Conclusions on solutions
  • It was recognized that necessary support in the network and devices is already available to “switch on” IPv6 in 3GPP networks
    • Some networks reported running dual stack
    • Some networks reported running IPv6-only now
  • Solutions enhancing existing mechanisms for dual stack deployments and new solutions for IPv6-only deployments drew wide support
    • Gateway-initiated Dual Stack Lite
    • Stateful IPv4/IPv6 translation
Next steps: 3GPP
  • IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
    • Note that the workshop itself does not have the mandate to make formal decisions
  • 3GPP is expected to identify possible normative specification impacts, if any, of the preferred solutions
  • A need was identified to provide more operational guidelines about IPv6 deployment to 3GPP operators
    • The best location for these guidelines is FFS (e.g. 3GPP TR 23.975, GSMA, etc)
Next steps: IETF
  • IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
    • Note that the workshop itself does not have the mandate to make formal decisions
  • IETF is encouraged to continue working on stateless and stateful IPv4/IPv6 translation mechanisms
    • These mechanisms are being worked on in IETF BEHAVE group
  • IETF is also encouraged to consider new solutions that are not yet working group items
    • Gateway Initiated DS Lite
    • Per-interface NAT44 bindings addressing IPv4 address shortage
  • Note that the workshop has not set any timelines

Further reading:
Posted by Zahid Ghadialy at 7:29 AM
Labels: , , ,

1 comment:

Unknown said...

Hi, all

We have IPv6 running on a number of Mobile operators in the world today, both in operations and in test. All of the operational networks use Ericsson SGSN/GGSN and supports IPv4 PDP and IPv6 PDP. These PDP's can terminate in APN's that supports both IPv4 and IPv6. Later this year there will be support for a dual stack PDP, which also impliese that terminals supporting this will only use one RAB (Radio Access Bearer), therefore saving valueable radio resources.
If You live e.g. in Sweden, or Slovenia some operators have native support in the Mobile network.
The biggest issue with full native IPv6 support, is the application still only running on IPv4 servers. Therefore the operator need an translation Gateway (e.g. ALG64/NAT64/DNS64) to secure that all services (Either in IPv4 or IPv6 domain) are reachable.
Beside the pure Gi/SGi interface issues, the operator also need to support settings in HSS/HLR (2 bits for Pure IPv4, Pure IPv6 or dual stack) to control the end user capabilities. This also implies that You need to have support in the HLR/HSS front-end call CCS (Customer Care System).
Beside this normally all operators wants to be able to bill the traffic, which means that the Billing system must support both Dual stack and IPv6 CDR's. Some operators have a good Billing system, and some have home-made systems (Leading to redesign or rewrite the software - Reluctance to do it because of "small investment").
To this You also have operators running DPI solutions to control the traffic, and those have normally some issues with IPv6 due to the bit-width that's coming and also the extension headers that makes IPv6 a little more difficult to handle.

IPv6 are not hard to do, it takes a very short time to implement. But the prepartion needs to take time, so the operators doesn't end up in an architectural mess later (As in IPv4 case).

Best regards

May 21, 2010 at 2:08 PM

Post a Comment

Subscribe to: Post Comments (Atom)