idnits 2.17.1 draft-jiang-v6ops-incremental-cgn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2009) is 5413 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft D. Guo 3 Intended status: Standard Track Huawei Technologies Co., Ltd 4 Expires: December 25, 2009 B. Carpenter 5 University of Auckland 6 June 29, 2009 8 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 9 draft-jiang-v6ops-incremental-cgn-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on December 25, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Global IPv6 deployment was slower than originally expected in the 47 last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 48 transition issues become more critical and complicated. Host-based 49 transition mechanisms are not able to meet the requirements while 50 most end users are not sufficiently expert to configure or maintain 51 these transition mechanisms. Carrier Grade NAT with integrated 52 transition mechanisms can simplify the operation of end users during 53 the IPv4/IPv6 migration or coexistence period. This document proposes 54 an incremental Carrier-Grade NAT (CGN) solution for IPv6 transition. 55 It can provide IPv6 access services for IPv6-enabled end hosts and 56 IPv4 access services for IPv4 end hosts while remaining most of 57 legacy IPv4 ISP networks unchanged. It is suitable for the initial 58 stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and 59 encourages transition towards dual-stack or IPv6-only ISP networks. 61 Table of Contents 63 1. Introduction................................................3 64 2. Terminology.................................................4 65 3. An Incremental CGN Solution..................................4 66 3.1. Incremental CGN Solution Overview.......................4 67 3.2. Choice of tunnelling technology.........................5 68 3.3. Behaviour of Dual-stack Home Gateway....................6 69 3.4. Behaviour of Dual-stack Carrier-Grade NAT...............6 70 3.5. Impact for end hosts and remaining networks.............7 71 3.6. Discussion.............................................7 72 4. Migration towards IPv6 Core Network..........................7 73 4.1. Legacy communication in Phase 2.........................8 74 5. Security Considerations......................................9 75 6. IANA Considerations.........................................9 76 7. Acknowledgements............................................9 77 8. Change Log..................................................9 78 9. References.................................................10 79 9.1. Normative References...................................10 80 9.2. Informative References.................................10 81 Author's Addresses............................................12 83 1. Introduction 85 Up to now, global IPv6 deployment does not happen as was expected 10 86 years ago. The progress was much slower than originally expected. 87 Network providers were hesitant to take the first move while IPv4 was 88 and is still working well. However, IPv4 address exhaustion is now 89 confirmed to happen soon. The dynamically-updated IPv4 Address Report 90 [IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA 91 unallocated address pool exhaustion and middle 2012 for RIR 92 unallocated address pool exhaustion. Based on this fact, the Internet 93 industry appears to have reached consensus that global IPv6 94 deployment is inevitable and has to be done quite quickly. 96 IPv4/IPv6 transition issues therefore become more critical and 97 complicated for the soon-coming global IPv6 deployment. Host-based 98 transition mechanisms alone are not able to meet the requirements. 99 They are too complicated for most end users who do not have enough 100 technical knowledge to configure or maintain these transition 101 mechanisms. New transition mechanisms with simple user-side operation 102 are needed. 104 Carried Grade NAT (CGN) alone creates operational problems, but does 105 nothing to help IPv4/IPv6 transition. In fact it allows ISPs to delay 106 the transition, and therefore causes double transition costs (once to 107 add CGN, and again to support IPv6). 109 Carrier-Grade NAT that integrates multiple transition mechanisms can 110 simplify the operation of end user services during the IPv4/IPv6 111 migration or coexistence period. CGNs are deployed on the network 112 side and managed/maintained by professionals. On the user side, new 113 CPE devices may be needed too. They may be provided by network 114 providers, depending on the specific business model. Dual-stack lite 115 [DSLite] is a CGN-based solution that supports transition, but it 116 requires the ISP to upgrade its network to IPv6 immediately. Many 117 ISPs hesitate to do this as the first step. 119 This document proposes an incremental CGN solution for IPv6 120 transition. The solution is similar to DSLite, but the other way 121 around. Technically, it mainly combines v4-v4 NAT with v6-over-v4 122 tunnelling functions along with some minor adjustment. It can provide 123 IPv6 access services for IPv6-enabled end hosts and IPv4 access 124 services for IPv4 end hosts, while leaving most of legacy IPv4 ISP 125 networks unchanged. The deployment of this solution does not affect 126 legacy IPv4 hosts with global IPv4 addresses at all. It is suitable 127 for the initial stage of IPv4/IPv6 migration. It also supports 128 transition towards dual-stack or IPv6-only ISP networks. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. An Incremental CGN Solution 138 Most ISP networks are still IPv4. Network providers are starting to 139 provide IPv6 access services for end users. However, at the initial 140 stage of IPv4/IPv6 migration, IPv4 connectivity and traffic would be 141 the majority for most ISP networks. ISPs would like to minimize the 142 changes on their IPv4 networks. Switching the whole ISP network into 143 IPv6-only would be considered as a radical strategy. Switching the 144 whole ISP network to dual stack is less radical, but introduces 145 operational costs and complications. Although some ISPs have 146 successfully deployed dual stack routers, others prefer not to do 147 this as their first step in IPv6. However, they currently face two 148 urgent pressures - to compensate for an immediate shortage of IPv4 149 addresses by deploying some method of address sharing, and to prepare 150 actively for the deployment of IPv6 address space and services. The 151 solution described in this draft addresses both of these pressures by 152 proceeding in two phases. 154 3.1. Incremental CGN Solution Overview 156 The incremental CGN solution we propose is illustrated as the 157 following figure. 159 +-------------+ 160 |IPv6 Internet| 161 +-------------+ 162 | 163 +-------------+----------+ 164 +-----+ +--+ | IPv4 ISP +--+--+ | +--------+ 165 |v4/v6|----|DS|=====+==========| CGN |-------+---| IPv4 | 166 |Host | |HG| | Network +-----+ | | |Internet| 167 +-----+ +--+ +--------------------+---+ +--------+ 168 _ _ _ _ _ _ _ _ _ _ _ | 169 ()_6_o_4_ _t_u_n_n_e_l_() +---------------------+ 170 | Existing IPv4 hosts | 171 +---------------------+ 173 Figure 1: Phase 1 of incremental CGN solution with IPv4 ISP network 175 DS HG = Dual-Stack Home Gateway (CPE). 177 The above figure shows only Phase 1, in which the ISP has not 178 significantly changed its IPv4 network. This solution enables IPv4 179 hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 180 Internet. A dual stack host can be treated as an IPv4 host when it 181 uses IPv4 access service and as an IPv6 host when it uses IPv6 access 182 service. In order to enable IPv4 hosts to access IPv6 Internet and 183 IPv6 hosts to access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its 184 replacement) can be integrated with CGN. The integration of NAT-PT is 185 out of scope for this document 187 Two new types of devices need to be deployed in this solution: a 188 dual-stack home gateway, which MAY follow the requirements of [6CPE], 189 and dual-stack Carrier-Grade NAT. The dual-stack home gateway 190 integrates IPv4 forwarding and v6-over-v4 tunnelling functions. It 191 MAY integrate v4-v4 NAT function, too. The dual-stack CGN integrates 192 v6-over-v4 tunnelling and carrier-grade v4-v4 NAT functions. 194 3.2. Choice of tunnelling technology 196 In principle, this model will work with any form of tunnel between 197 the DS HG and the dual-stack CGN. However, tunnels that require 198 individual configuration are clearly undesirable because of their 199 operational cost. Configured tunnels based directly on [RFC4213] are 200 therefore not suitable. A tunnel broker according to [RFC3053] would 201 also have high operational costs. 203 Modified 6RD [6RD] technology appears suitable to support v6-over-v4 204 tunnelling with low operational cost. 6RD was designed for an IPv4 205 ISP scenario and allows re-use of slightly modified existing support 206 for 6to4 [RFC3056]. 6RD using a 32-bit IPv6 prefix from the ISP's 207 address space will allow each CPE to receive a 64-bit prefix 208 corresponding to its IPv4 address. If it is desired to delegate 56- 209 bit prefixes to each customer, the 6RD prefix MUST be of 24 bits, as 210 illustrated below. In that case, the ISP MUST have a general IPv6 211 prefix shorter than /24. 213 +----------------------.------------------------------+ 214 | 6RD-relay IPv6 prefix| IPv4 address | 215 | of the ISP | of the customer site | 216 +----------------------'------------------------------+ 217 <----- 24 bits -----><--------- 32 bits ----------> 219 Figure 2: format of a 56-bit 6RD prefix 221 Modified GRE [RFC2784] with additional auto-configuration mechanism 222 is also suitable to support v6-over-v4 tunnelling. In order to auto- 223 configure GRE tunnel, an interactive mechanism between tunnel 224 initiator and tunnel concentrator is needed. The parameters that 225 tunnel configuration requires can be obtained through DHCPv6. 227 Other tunnelling mechanisms such as Intra-Site Automatic Tunnel 228 Addressing Protocol (ISATAP) [RFC5214] or Virtual Enterprise 229 Traversal (VET) [VET] could also be considered. ISATAP is an IPv6 230 transition mechanism meant to transmit IPv6 packets between dual- 231 stack nodes on top of an IPv4 network. VET represents a functional 232 superset of 6over4 [RFC2529] and ISATAP. It support tunnel 233 autoconfiguration. 235 If the ISP has an entirely MPLS infrastructure between the CPE and 236 the dual-stack CGN, it would also be possible to consider a 6PE 237 [RFC4798] tunnel directly over MPLS. This would, however, only be 238 suitable for an advanced CPE that is unlikely to be found as a home 239 gateway, and is not further discussed here. 241 3.3. Behaviour of Dual-stack Home Gateway 243 When a dual-stack home gateway receives a data packet from an end 244 host, it firstly checks whether the packet is IPv4 or IPv6. For IPv4 245 data, the HG can directly forward it if there is no v4-v4 NAT running 246 on the HG. Or the HG translates packet source address from a HG-scope 247 private IPv4 address into a CGN-scope private IPv4 address. The HG 248 SHOULD record the v4-v4 address mapping information for inbound 249 packets, just like normal NAT does. 251 For IPv6 data, the HG needs to encapsulate the data into an IPv4 252 tunnel, which has the dual-stack CGN as the other end. Then the HG 253 sends the new IPv4 packet towards CGN. 255 The HG SHOULD record the mapping information between the tunnel and 256 the source IPv6 address for inbound packets if HG uplinks to more 257 than one CGN. Detailed considerations for the use of multiple CGNs by 258 one HG are for further study. 260 3.4. Behaviour of Dual-stack Carrier-Grade NAT 262 When a dual-stack CGN receives a data packet from a dual-stack home 263 gateway, it firstly checks whether the packet is a normal IPv4 packet 264 or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN 265 translates packet source address from a CGN-scope private IPv4 266 address into a public IPv4 address, and then send it to IPv4 Internet. 267 The CGN SHOULD record the v4-v4 address mapping information for 268 inbound packets, just like normal NAT does. For a v6-over-v4 tunnel 269 packet, the CGN needs to decapsulate it into the original IPv6 packet 270 and then send it to IPv6 Internet. The CGN SHOULD record the mapping 271 information between the tunnel and the source IPv6 address for 272 inbound packets. 274 Depending on the deployed location of the CGN, it MAY use v6-over-v4 275 tunnels to connect to the IPv6 Internet. 277 3.5. Impact for end hosts and remaining networks 279 This solution does not affect the remaining networks at all. Legacy 280 IPv4 ISP networks and their IPv4 devices remain in use. The existing 281 IPv4 hosts, shown as the right box in Figure 1, either having global 282 IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it 283 is now. Of course, these hosts can access IPv6 Internet through IPv4 284 ISP network by using IPv4-over-IPv6 tunnel technologies. 286 3.6. Discussion 288 It SHOULD be noted that for IPv4 traffic, this solution inherits all 289 the problems of CGN (e.g., scaling, and the difficulty of supporting 290 well-known ports for inbound traffic). Application layer problems 291 created by double NAT are for further study. 293 If a different solution than v4-v4 NAT is chosen for IPv4 address 294 sharing, for example [APLUSP], the present solution could be suitably 295 modified, for example replacing the v4-v4 NAT function by the A+P 296 gateway function. 298 However, for IPv6 traffic, a user behind the DS HG will see normal 299 IPv6 service. It is strongly RECOMMENDED that all IPv6 tunnels 300 support an MTU of at least 1500 bytes, to ensure that the mechanism 301 usually does not cause fragmentation of IPv6 traffic. This, and the 302 absence of NAT problems for IPv6, will create an incentive for users 303 and application service providers to prefer IPv6. 305 ICMP filtering function MAY be included as part of CGN functions. Any 306 firewall included in the CGN SHOULD follow the recommendations in 307 [RFC4890]. 309 4. Migration towards IPv6 Core Network 311 When the core network starts transition to IPv6, this solution can 312 easily be transited into Phase 2, in which the ISP network is either 313 dual-stack or IPv6-only. 315 For dual-stack ISP networks, dual-stack home gateways can simply 316 switch off the v6-over-v4 function and forward both IPv6 and IPv4 317 traffic directly; the dual-stack CGN SHOULD only keep its v4-v4 NAT 318 function. However, this is considered an unlikely choice, since we 319 expect ISPs to choose the approach described here because they want 320 to avoid dual-stack deployment completely. 322 For IPv6-only ISP networks, the dual-stack lite solution [DSLite], 323 which also needs dual-stack home gateway and CGN devices, can be 324 adopted for Phase 2. The best business model for this solution is 325 that CPE has integrated the functions for both Phase 1 and 2, and can 326 automatically detect the change. For example, the DS HG can use the 327 appearance of IPv6 Route Advertisement messages or DHCPv6 messages as 328 a signal that Phase 2 has started. Then when ISPs decide to switch 329 from Phase 1 to Phase 2, it may be that only a configuration change 330 or a minor software update is needed on the CGNs. The DS HG will then 331 switch automatically to DSLite mode. The only impact on the home user 332 will be to receive a different IPv6 prefix. 334 Note that if the 6RD mechanism is used in Phase 1, the user may have 335 a /64 prefix during Phase 1, but could get a shorter prefix such as 336 /56 in Phase 2. This would be an improved service offering available 337 as a result of the Phase 1 to Phase 2 transition. 339 It will not be necessary for all customers of a given ISP to switch 340 from Phase 1 to Phase 2 simultaneously; in fact it will be 341 operationally better to switch small groups of customers (e.g. all 342 those connected to a single point of presence). This is a matter of 343 planning and scheduling. 345 4.1. Legacy communication in Phase 2 347 We do not expect to see IPv6-only public services as long as there is 348 an IPv4-only customer base in the world, for obvious commercial 349 reasons. However, especially in Phase 2, IPv4/IPv6 intercommunication 350 may become issues. [DSLInter] describes a proposal to enhance DS-lite 351 solution with an additional feature to ease interconnection between 352 IPv4 and IPv6 realms. Furthermore, home users may encounter the 353 problem of reaching legacy IPv4-only public services from IPv6-only 354 clients. This problem could already exist in Phase 1, but will become 355 more serious as time goes on. It is proposed that each ISP should 356 provide its IPv6-only customers with a network-layer translation 357 service to satisfy this need. Such a service is not fully defined at 358 this time, so we refer to it non-specifically as NAT64. 360 We propose that the NAT64 service should be provided as a common 361 service located at the border between the ISP and the IPv4 Internet, 362 beyond the dual stack CGN from the customer's viewpoint. It MAY be 363 integrated into CGN devices too. The question has been asked why it 364 is better to do this than to distribute the NAT64 function by 365 locating it in (or near) the home gateway, so that relevant 366 translation state resides only in the HG. While this might be 367 suitable in Phase 1, when the ISP still provides full IPv4 368 connectivity, it would force all translated traffic into DSLite 369 tunnels in Phase 2. This seems undesirable. 371 5. Security Considerations 373 Security issues associated with NAT have been documented in [RFC2663] 374 and [RFC2993]. 376 Further security analysis will be needed to understand double NAT 377 security issues and tunnel security issues. However, since the tunnel 378 proposed here exists entirely within a single ISP network, between 379 the CPE and the CGN, the threat model is relatively simple. [RFC4891] 380 describes how to protect tunnels using IPSec, but it is not clear 381 whether this would be an important requirement. An ISP could deem its 382 infrastructure to have sufficient security without additional 383 protection of the tunnels. 385 The dual-stack home gateway will need to provide basic security for 386 IPv6 [6CPESec]. Other aspects are described in [RFC4864]. 388 6. IANA Considerations 390 This draft does not request any IANA action. 392 7. Acknowledgements 394 Shin Miyakawa discussed a related proposal at IETF72. 396 Useful comments were made by Fred Templin, Seiichi Kawamura, Remi 397 Despres, Janos Mohacsi, Mohamed Boucadair and other members of the 398 IETF V6OPS working group. 400 8. Change Log [RFC Editor please remove] 402 draft-jiang-incremental-cgn-00, original version, 2009-02-27 404 draft-jiang-v6ops-incremental-cgn-00, revised after comments at 405 IETF74, 2009-04-23 407 draft-jiang-v6ops-incremental-cgn-01, revised after comments at v6ops 408 mailing list, 2009-06-30 410 9. References 412 9.1. Normative References 414 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 [RFC2529] B. Carpenter, and C. Jung, "Transmission of IPv6 over IPv4 418 Domains without Explicit Tunnels", RFC2529, March 1999. 420 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, 421 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 423 9.2. Informative References 425 [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address 426 Translator (NAT) Terminology and Considerations", RFC 2663, 427 August 1999. 429 [RFC2766] G. Tsirtsis and P. Srisuresh, "Network Address Translation 430 - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 432 [RFC2993] T. Hain, "Architectural Implications of NAT", RFC 2993, 433 November 2000. 435 [RFC3053] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 436 Tunnel Broker", RFC 3053, January 2001. 438 [RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains via 439 IPv4 Clouds", RFC 3056, February 2001. 441 [RFC4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms 442 for IPv6 Hosts and Routers", RFC 4213, October 2005. 444 [RFC4798] J. De Clercq, D. Ooms, S. Prevost and F. Le Faucheur, 445 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 446 Edge Routers (6PE)", RFC 4798, February 2007. 448 [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter and E. 449 Klein, "Local Network Protection for IPv6", RFC 4864, May 450 2007. 452 [RFC4890] E. Davies and J. Mohacsi, "Recommendations for Filtering 453 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 455 [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 456 RFC4891, May 2007. 458 [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address 459 Translator - Protocol Translator (NAT-PT) to Historic 460 Status", RFC 4966, July 2007. 462 [RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic 463 Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 465 [DSLite] A. Durand, R. Droms, B. Haberman and J. Woodyatt, "Dual- 466 stack lite broadband deployments post IPv4 exhaustion", 467 draft-durand-softwire-dual-stack-lite-01, work in progress. 469 [IPUSAGE] G. Huston, IPv4 Address Report, March 2009, 470 http://www.potaroo.net/tools/ipv4/index.html. 472 [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 473 (6rd)", draft-despres-6rd, work in progress. 475 [6CPE] H. Singh, "IPv6 CPE Router Recommendations", draft-wbeebee- 476 ipv6-cpe-router, work in progress. 478 [6CPESec] J. Woodyatt, "Recommended Simple Security Capabilities in 479 Customer Premises Equipment for Providing Residential IPv6 480 Internet Service", draft-ietf-v6ops-cpe-simple-security, 481 work in progress. 483 [APLUSP] R. Bush, O. Maennel, J. Zorz, S. Bellovin and L. Cittadini, 484 "The A+P Approach to the IPv4 Address Shortage", draft- 485 ymbk-aplusp, work in progress. 487 [VET] F. Templin, "Virtual Enterprise Traversal (VET)", draft- 488 templin-autoconf-dhcp, work in progress. 490 [DSLInter] M. Boucadair, et al, "Stateless IPv4-IPv6 Interconnection 491 in the Context of DS-lite Deployment", draft-boucadair- 492 dslite-interco-v4v6, work in progress. 494 Author's Addresses 496 Sheng Jiang 497 Huawei Technologies Co., Ltd 498 KuiKe Building, No.9 Xinxi Rd., 499 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 500 P.R. China 501 Phone: 86-10-82836774 502 Email: shengjiang@huawei.com 504 Dayong Guo 505 Huawei Technologies Co., Ltd 506 KuiKe Building, No.9 Xinxi Rd., 507 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 508 P.R. China 509 Phone: 86-10-82836284 510 Email: guoseu@huawei.com 512 Brian Carpenter 513 Department of Computer Science 514 University of Auckland 515 PB 92019 516 Auckland, 1142 517 New Zealand 518 Email: brian.e.carpenter@gmail.com