The APNIC 34 Conference and Workshop convened in Phnom Penh, Cambodia during August, bringing together players from across the Internet spectrum. 237 delegates from 36 economies and 52 organisations assembled for 10 days of workshops, plenaries, presentations and open forums. Representatives from the various standards organisations and Internet Registries together with regional service providers, gained valuable insights into efficient Internet resource management, and garnered best practices in IPv6 address assignment and routing configuration. Functions of APNIC
The Asia Pacific Network Information Centre, one of the world’s five Internet address registries, is a non-profit organisation responsible for servicing the Asia Pacific Internet community. As a membership-based organisation, APNIC provides Internet resource distribution and registry services for the region and actively supports the Internet community.
Two concurrent workshops were held over the first five days. The subjects covered included:
IPv4 / IPv6 BGP Routing Workshop
- OSPF/ISIS design and best practices for Service Provider networks
- BGP introduction, attributes and policy
- BGP scalability (including Route Reflectors and Communities)
- Aggregation
- BGP Multihoming Techniques (redundancy and load balancing)
- ISP Best Practices
- Peering best practices
- IPv6 Background and Standards
- IPv6 Extensions for Routing Protocols
- IPv6 Addressing and Address planning
- IPv6 Deployment Case Study
Network Security Workshop
Network Security Fundamentals
- Cryptography
- Infrastructure security
- Monitoring and managing access
- Point protection
- ACLs
- Edge protection
Network Analysis and Forensics
- Understanding TCP/IP
- Forensics fundamentals
Anatomy of a network attack
- Miscreants, motivations and misconceptions
- Modern attacks
- Botnets
- DDoS & botnet financials
- Trends
DNS Security
- DNS vulnerabilities
- DNS security mechanisms (TSIG, DNSSEC)
Transition Technologies update
Over the following five days, a range of conference sessions and plenaries were conducted. A number of these sessions focussed on IPv6 implementation, and particularly around the transition from IPv4 to IPv6, of which many strategies have been formulated and are being deployed by various service providers.
Access Transition technologies are mechanisms that allow operators to deploy and migrate their subscriber-base to IPv6. Transition technologies have been developed by the IPv6 community and vendors to help accelerate IPv6 deployment, and reduce barriers to IPv6 uptake. All should be evaluated carefully to identify which technology or technologies are the best fit for any given operator to deploy.
Some transition technologies have a ‘long term life’. Others are seen as interim solutions to deploy IPv6 quickly while investment or technology catches up. CPE is one of the most important domains for IPv6 deployment – to support any transition technology, long term strategy, and managing cost.
Here is a brief descriptions of some transition technologies:
Native Dual Stack
by Alastair Johnson – Alcatel Lucent
Deploying IPv6 services as native dual-stack is the best case approach for most operators and subscribers. However, it is often the most difficult.
Dual-stack is the ‘best-case’ transition design for IPv6 deployment which allows full coexistence of IPv6 and IPv4 services on an incremental deployment basis (e.g. subscribers can take up IPv6 services as their CPE is replaced, after network-wide deployment).
- Subscriber experience is identical regardless of IPv6 or IPv4 service, which are terminated on the same equipment (CPE, BNG) and share queues, SLA, and authorization and accounting policies.
- Impact to the customer side of the network is high due to the CPE swap requirement – however significant number of CPE today are now IPv6 capable (including many transition technologies – refer to CPE link in references).
- Broadband Forum TR-177 and TR-187 along with TR-124i2 give excellent references for operators looking to deploy dual-stack services into existing TR-101 and PPP based environments, and provide requirements for RG behavior.
- Depending on topology (IPoE v. PPPoE) the impact in the access/aggregation is variable: PPPoE is very straightforward to deploy IPv6 on and allows easy customer uptake.
- IPoE does require some changes in the access network, particularly if Lightweight DHCPv6 Relay Agent (LDRA) support is required and what the access architecture looks like.
- Debate over SLAAC vs. DHCPv6 in the access attachment continues, however general recommendation and approach is DHCPv6 based to align with DHCPv4 model in existing networks.
- Impact in the subscriber edge (BNG) is variable: impact to some legacy BNGs may be substantial when dual stack service is enabled impacting scalability, or lack of features for full equivalent IPv4 deployment. Operators need to investigate this carefully, however modern BNGs should have no issues when deploying dual-stack services at high subscriber scale.
- Dual-stack does have drawbacks in that it does require potential capital investment if equipment forklift upgrades are required, as well as the impact of monitoring two address families in the network (twice the link monitoring, etc).
- Dual-stack does provide an interesting and easy approach to an IPv6-only network by simply turning IPv4 off in the future (and potentially using NAT64, etc).
- Allows status-quo to remain for non-Internet services (e.g. VoIP ATA, CPE/RG management, IPTV services etc) as existing IPv4 path is retained.
Dual Stack Lite
by Alastair Johnson – Alcatel Lucent
DS-Lite specifically targets the case where operators wish to immediately remove IPv4 from the access – aggregation and subscriber management edge and run single-stack IPv6 while continuing to support IPv4 connectivity through a classic NAT44 capability rather than address family translation. This view was developed around 2007 and has started to gain deployment traction in 2012.
- Significant impact in the CPE domain as the CPE must be upgraded to support IPv6 WAN and all associated connectivity (management, VoIP, IPTV etc), however NAT function is removed from CPE which potentially reduces cost (CPU/memory) in maintaining NAT state in the CPE. CPE are commercially available today that support DS-Lite and vendor support is continuing to increase.
- Access network and subscriber management edge must support IPv6 in the same manner that dual-stack deployment. DS-Lite typically assumes an IPoE deployment but could be used in the PPP case as well.
- Debate over SLAAC vs. DHCPv6 in the access attachment continues, however general recommendation and approach is DHCPv6 based to align with DHCPv4 model in existing networks.
- As the operator must now deploy an AFTR, this node needs to be located near subscriber traffic (e.g. in or adjacent to the BNG) to avoid hauling traffic to centralized locations in the network which may impact TE or interface scaling in the network core. A potential drawback to non-BNG located AFTR is that any DPI or other IPv4 classification may be forced to occur at AFTR or elsewhere in the network, potentially stranding existing investment.
- As DS-Lite moves the NAT44 function out of the RG and into the service provider environment, the service provider must support transaction logging for the LS-NAT as the subscribers share a common LAN IPv4 prefix (192.0.0.0/29) for the inside prefix.
- DS-Lite does force re-architecture of existing service offerings such as VoIP and IPTV which may need to be moved to native IPv6 services to avoid transiting AFTR nodes in the network which may present a significant bandwidth bottleneck (in particular with multicast traffic!).
- Deployment of DS-Lite generally implies a significant migration stage where entire Access Nodes (or regions) are migrated at once, rather than an incremental migration on a per-subscriber basis – however this is up to individual service provider deployment approach.
- DS-Lite provides an interesting and easy approach to an IPv6-only network by simply turning IPv4 off in the future when it is no longer required.
NAT64
by Alastair Johnson – Alcatel Lucent
NAT64 specifically targets the case where operators wish to immediately remove IPv4 from the access–aggregation and subscriber management edge and run single-stack IPv6 while continuing to support IPv4 connectivity. NAT64 most closely aligns with wireless deployment models rather than wireline, given the drawbacks in NAT64 for application translation and the wider number of applications found in wireline environments vs. wireless.
- Significant impact in the CPE domain as the CPE must be upgraded to support IPv6 WAN and all associated connectivity (management, VoIP, IPTV etc), however NAT function is removed from CPE which potentially reduces cost (CPU/memory) in maintaining NAT state in the CPE.
- Access network and subscriber management edge must support IPv6 in the same manner that dual-stack deployment. NAT64 typically assumes an IPoE deployment but could be used in the PPP case as well.
- Debate over SLAAC vs. DHCPv6 in the access attachment continues, however general recommendation and approach is DHCPv6 based to align with DHCPv4 model in existing networks.
- As the operator must now deploy a NAT64, this node needs to be located near subscriber traffic (e.g. in or adjacent to the BNG) to avoid hauling traffic to centralized locations in the network which may impact TE or interface scaling in the network core. All DPI and classification on the IPv4 side of the NAT64 should be translated into the IPv6 side as well to preserve end-to-end behavior in the service provider network.
- The operator must also deploy a DNS64 node that can provide the DNS synthesis by translating DNS responses with only A-records into AAAA-records with the well-known Pref64 prefix. Major DNS vendors support DNS64 translation today.
- NAT64 will break a number of applications that rely on IPv4-literals (e.g. attempt to establish a socket directly to 192.0.2.1) and applications that will not traverse NAT environments happily. Some experiments have been conducted with IPv6-only networks and NAT64 environments and document the broken applications – refer to reference slide.
- NAT64 does force re-architecture of existing service offerings such as VoIP and IPTV which may need to be moved to native IPv6 services to avoid transiting NAT64 nodes in the network which may present a significant bandwidth bottleneck (in particular with multicast traffic!).
- Deployment of NAT64 generally implies a significant migration stage where entire Access Nodes (or regions) are migrated at once, rather than an incremental migration on a per-subscriber basis – however this is up to individual service provider deployment approach.
IPv6 Rapid Deployment - 6rd
by Alastair Johnson – Alcatel Lucent
6rd specifically targets the case where operators wish to immediately deploy IPv6 to their subscriber base, but cannot enable it in the native access. As 6rd encapsulates IPv6 in IPv4, it can be deployed across any existing IPv4 network.
Some constraints faced by operators that drive 6rd as the technology include legacy Access Nodes (e.g. DSLAMs) that cannot support forwarding IPv6 packets, or older access technologies (e.g. DOCSIS 1.1) that cannot support IPv6 L3 wholesale access environments that cannot support IPv6 are another common barrier to deployment.
- Significant impact in the CPE domain as the CPE must be upgraded to support 6rd. CPE are commercially available today that support 6rd and vendor support is continuing to increase.
- Access network and subscriber management edge face no changes.
- As the operator must now deploy a 6rd BR, this node needs to be located near subscriber traffic (e.g. in or adjacent to the BNG) to avoid hauling traffic to centralized locations in the network which may impact TE or interface scaling in the network core. A potential drawback to non-BNG located 6rd BR is that any DPI or other IPv4 classification may be forced to occur at 6rd BR or elsewhere in the network, potentially stranding existing investment or impacting service provider operations.
- As 6rd may automatically derive the subscriber prefix with variable length subnetting (e.g. 48-56-64) based on the IPv4 address, the operator must consider exactly how many IPv4 bits they wish to stuff into the IPv6 prefix, and how this impacts any RIR allocated IPv6 prefixes. There are multiple approaches for managing the IPv6 addressing in 6rd environments.
- 6rd does not force re-architecture of existing service offerings such as VoIP and IPTV which may remain on the existing IPv4 service.
- 6rd can be deployed incrementally with no impact to the subscriber base as and when CPE are upgraded to support 6rd.
- 6rd does not solve the long term problem of removing IPv4 from the access network or moving to native IPv6 services, however discussion for this is being undertaken in the IETF currently (refer reference slide).
- Potential MTU issues may occur with the tunnel, but may be mitigated by increasing WAN MTU or implementing fragmentation in the 6rd BR and CPE.
464XLAT
by Masanobu Kawashima - NEC Access Technica, Ltd.
464XLAT provides limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (described in RFC 6146) in the core, and stateless protocol translation (described in RFC 6145) at the edge.
What it is
- Easy to deploy and available today, commercial and open source shipping product.
- Effective at providing basic IPv4 service to consumers over IPv6-only access networks.
- Efficient use of very scarce IPv4 resources.
What it is NOT
- A perfect replacement for IPv4 or Dual-stack service.
As the name implies, 464XLAT centres on “translation”, employing terms such as:
PLAT: Provider side translator - A stateful translator that performs 1:N translation. It translates a global IPv6 address to global IPv4 address, and vice versa.
CLAT: Customer side translator - A stateless translator that performs 1:1 translation. It algorithmically translates private IPv4 address to global IPv6 address, and vice versa. Other features are IPv6 router, DHCPv6 Server/Client, Access Control, DNS Proxy, etc. The presence of DNS64 (described in RFC6147) and any port mapping algorithm are not required.
Upcoming APNIC Conferences
APNIC 35
– Singapore, March 2013
– with APRICOT 2013
Also, for the avid readers, interesting BLABs on the Internet can be found here:
http://labs.apnic.net/blabs/?cat=7
About Cambodia
Phnom Penh is often referred to as the “Pearl of Asia”; it was considered one of the prettiest French-built cities in Indochina in the 1920s. Founded in 1434, the city is noted for its beautiful and historical architecture and attractions. You will still find surviving French colonial buildings along the grand boulevards. There are scant reminders of the tragedies that have beset Cambodia right up to recent decades, but it is possible for the inquisitive to be reminded of some of the worst atrocities a nation could assail on its people.
Attempting to cross Phnom Penh’s streets, you encounter a never ending stream of tuk-tuks plying for trade and motorcycles laden with the entire family. The key lies in the confidence to step off the footpath and walk steadily to the other side – let them avoid you. The automobile is an altogether different proposition. Do not take on a car – the car will not miss you, and Cambodian drivers do not attend the scene of an accident. There is no personal liability insurance or CTP in this country.
Nor, are there many beggars. Phnom Penh has made a concerted effort to encourage its people to produce goods and to offer them for sale, and when one considers that over 90 percent of the population survive on less than two dollars a day, you have to admire their drive for independence and their tenacity.
Laurie Benjamin IIT Training
