idnits 2.17.1 draft-iab-mpls-tp-uncoord-harmful-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 16) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2009) is 5398 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-08 -- Obsolete informational reference (is this intentional?): RFC 1393 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant, Ed. 3 Internet-Draft M. Morrow, Ed. 4 Intended status: Informational On behalf of the IAB 5 Expires: December 10, 2009 June 8, 2009 7 "Uncoordinated Protocol Development Considered Harmful" 8 draft-iab-mpls-tp-uncoord-harmful-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 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 10, 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 This document identifies various types of damage that may occur 47 without formal coordination and joint development on protocols of 48 mutual interest between standards development organizations. The IAB 49 has selected T-MPLS as recent case study to describe hazard to both 50 the MPLS and Internet architecture as a result of uncoordinated 51 adaptation of a protocol. 53 This experience has resulted in a considerable improvement in the 54 relationship between the two organisations. In particular, this was 55 achieved via the establishment of the "Joint working team on MPLS-TP" 56 which was the first ever joint ITU/IETF group. In addition, the 57 leadership of the two organisations have agreed to improve inter- 58 organizational working practices so as to avoid conflict in future 59 between ITU-T Recommendations and IETF RFCs. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Protocol Safety . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Importance of Invariants . . . . . . . . . . . . . . . . . 5 66 2.2. Importance of Correct Identification . . . . . . . . . . . 5 67 2.3. The Role of the Design Authority . . . . . . . . . . . . . 6 68 2.4. Ships in the Night . . . . . . . . . . . . . . . . . . . . 6 69 3. T-MPLS As a Case Study . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Multiple Definitions of Label 14 . . . . . . . . . . . . . 7 71 3.2. Redefinition of TTL Semantics . . . . . . . . . . . . . . 8 72 3.3. Reservation of Additional Labels . . . . . . . . . . . . . 8 73 3.4. Redefinition of MPLS EXP Bits . . . . . . . . . . . . . . 9 74 3.5. The Consequences for the Network Operators . . . . . . . . 9 75 3.6. The Consequences for the SDOs . . . . . . . . . . . . . . 9 76 4. MPLS-TP As Best Practice . . . . . . . . . . . . . . . . . . . 10 77 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. Generalization from this Case Study . . . . . . . . . . . . . 14 81 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 84 10.2. Informative references . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 The uncoordinated adaptation of a protocol, parameter, or code-point 90 by a standards development organization (SDO), either through the 91 allocation of a code-point without following the formal registration 92 procedures, or by unilaterally modifying the semantics of the 93 protocol or intended use of the code-point itself, poses a risk of 94 harm to the Internet [RFC4775]. 96 The purpose of this document is to describe the various types of 97 damages that may occur without formal coordination and joint 98 development on protocols of mutual interest between SDOs. In 99 particular, the IAB considers an essential principle of the protocol 100 development process that only one SDO maintains design authority for 101 a given protocol, with that SDO having ultimate authority over the 102 allocation of protocol parameter code-points; defining the intended 103 semantics, interpretation, and actions associated with those code- 104 points. 106 There is currently a joint IETF - ITU-T development effort underway, 107 known as MPLS Transport Profile (MPLS-TP), which is progressing 108 rapidly to extend MPLS in a way that is consistent with the MPLS 109 architecture, and fully satisfies the requirements of the transport 110 network provider [LS26]. By way of a case study we will refer to the 111 design and standardization process of the ITU-T protocol known as 112 Transport MPLS (T-MPLS). Development of T-MPLS was abandoned 113 [RFC5317] by ITU-T Study Group 15 due to inherent conflicts with the 114 IETF MPLS design and in particular with the Internet architecture. 115 These conflicts arose due to the lack of coordination with the IETF 116 as the design authority for MPLS. 118 The goal of this document is to demonstrate the importance of a 119 coordinated approach to successful collaboration between SDOs, and to 120 explain a model for inter-SDO collaborative protocol development that 121 is being used successfully by the ITU-T and IETF. 123 2. Protocol Safety 125 To understand the reasons why the IAB and the IETF regards 126 uncoordinated use of code-points and/or protocol modification as 127 posing a risk of harm to the Internet, it is necessary to recap some 128 important principles of protocol design in large scale networks such 129 as the Internet. Large scale networks represent significant economic 130 value. Any outage in a large scale network due to a protocol failure 131 will therefore result in significant commercial and political damage. 132 When two incompatible protocols, or forms of the same protocol, are 133 deployed without coordination, there is a serious risk that this may 134 be catastrophic to the stability or security of the network. 135 Furthermore, the scale and distributed nature of the Internet is such 136 that it is impossible to coordinate a network wide restart to rid the 137 network of the long- term consequences of the protocol 138 incompatibility. Therefore, the following issues are of critical 139 importance. 141 2.1. Importance of Invariants 143 Invariants are core properties that are consistent across the network 144 and do not change over extremely long time-scales. Protocol 145 designers use such invariants as axioms in designing protocols. A 146 protocol often places an absolute reliance on an invariant to resolve 147 a design corner case. One example of an invariance in IP that was 148 inherited in the design of MPLS is the invariant that a time to live 149 (TTL) value is monotonically decreased and that a packet with TTL<=1 150 will not be forwarded. This is a safety mechanism to mitigate the 151 damaging effects of packet forwarding loops. Another example is the 152 way that MPLS applies special semantics to the reserved label set 153 [RFC3032] (0..15), and the notion that a Label Switched Router (LSR) 154 is free to allocate labels with a value of 16 or greater for its own 155 use. 157 2.2. Importance of Correct Identification 159 A special type of invariant is the allocation of a code-point. A 160 code-point may be used to identify a packet type or a component 161 within a packet. Without these identifiers, a packet is an opaque 162 sequence of bits. A packet parser operates by first identifying the 163 code-point and then using the semantics associated with that code- 164 point to interpret other components within the packet. Once a code- 165 point is defined the interpretation of associated data and the 166 consequential actions becomes a protocol invariant. Subsequent 167 protocol development must adhere to those invariants. The semantics 168 for an allocated code point must never change. If a future 169 enhancement requires different semantics, interpretation, or action, 170 then a new code point must be obtained. 172 2.3. The Role of the Design Authority 174 A code-point such as an IEEE Ethertype is allocated to a design 175 authority such as the IETF. It is this design authority that 176 establishes how information identified by the code-point is to be 177 interpreted to associate appropriate invariants. Modification and 178 extension of a protocol requires great care. In particular it is 179 necessary to understand the exact nature of the invariants and the 180 consequences of modification. This may not always be the case when 181 protocols are modified by organizations without the experience of the 182 original designers, or the design authority expert pool. 183 Furthermore, since there can only safely be a single interpretation 184 of the information identified by a code-point, there must be a unique 185 authority responsible for authorizing and documenting the semantics 186 of the information and consequential protocol actions. 188 In the case of IP and MPLS technologies, the design authority is the 189 IETF. The IETF has an internal process for evolving and maintaining 190 the protocols for which it is the design authority. The IETF also 191 has change processes in place [RFC4929] to work with other SDOs that 192 require enhancements to its protocols and architectures. Similarly, 193 the ITU has design authority for Recommendation E.164 [E.164] and 194 allocates the relevant code points, even though the IETF has design 195 authority for the protocols ("ENUM") used to access E.164 numbers 196 through the Internet DNS [RFC3245]. 198 2.4. Ships in the Night 200 It may be tempting for a designer to assert that the protocol 201 extensions it proposes are safe even though it breaks the invariants 202 of the original protocol because these protocol variants will operate 203 as ships in the night. That is, these protocol variants will never 204 simultaneously exist in the same network domain and will never need 205 to inter-work. This is a fundamentally unsound assumption for a 206 number of reasons. First, it is infeasible to ensure that the two 207 instances will never be interconnected under any circumstances. 208 Second, even if the operators that deploy the protocols apply 209 appropriate due diligence to ensure that the two instances do not 210 conflict, it is infeasible to ensure that such conflicting protocols 211 will not be interconnected under fault conditions. 213 This assumption of ships in the night is particularly hazardous when 214 the instances of the protocol share the same identifying code-point. 215 This is because a system is unable to determine which variant of the 216 protocol it has received, and hence how to correctly interpret the 217 associated information or to determine what protocol actions may be 218 safely executed. 220 3. T-MPLS As a Case Study 222 In order to illustrate the issues that arise from uncoordinated 223 protocol development called out above we will use the ITU-T T-MPLS 224 protocol as a recent example. 226 3.1. Multiple Definitions of Label 14 228 To appreciate why the use of MPLS Reserved Label 14 by the T-MPLS 229 protocol represented a safety concern to the Internet, it is 230 important to understand the current standards that use MPLS Reserved 231 Label 14. 233 The governing standard on the use of MPLS Reserved Label 14 is 234 [RFC3429], "Assignment of the 'OAM Alert Label' for Multi-protocol 235 Label Switching Architecture (MPLS) Operation and Maintenance (OAM) 236 Functions". 238 Label 14 is assigned to a specific protocol, namely, ITU-T 239 Recommendation [Y.1711-2002]. 241 ITU-T Recommendation [Y.1711-2002] has been superseded by newer 242 versions, specifically: - [Y.1711-2004], [Y.1711cor1] and 243 [Y.1711am1]. 245 All three documents are currently in-force as ITU-T Recommendations. 247 The problem is that the changes made to Y.1711 were never reflected 248 in an update to RFC 3429 which only defines the protocol as specified 249 by the now superseded 2002 Recommendation. So for example, MPLS 250 equipment responding to an MPLS packet containing Label 14 would 251 expect to see the 2002 version of Y.1711 [Y.1711-2002] protocol and 252 would not recognize any of the new function codes specified in Y.1711 253 Amendment 1. This problem arises because Y.1711 does not have a 254 version field, and RFC 3429 offers no other method to disambiguate 255 non-interoperable versions of Y.1711. Having a version number in the 256 protocol permits an implementer to codify non-interoperability. 257 Furthermore, the IETF as the authority over Label 14 semantics has 258 the final say over maintaining the interoperability of the protocol 259 employing that code-point, unless the IETF explicitly delegates such 260 authority. 262 With regard to T-MPLS there was a lack of coordination between the 263 ITU-T and the IETF over the redefinition of the semantics of MPLS 264 label 14, which resulted in protocol definitions that conflicted with 265 the IETF MPLS Architecture. 267 The MPLS architecture [RFC3031], defines a swap operation as an 268 atomic function that replaces the top label in an MPLS label stack 269 with another label which provides context for the next hop LSR. 270 However the ITU-T Recommendations that specified the new OAM 271 functions defined by Label 14 redefined the label swap operation as a 272 POP, followed by a PUSH, thereby causing all LSRs to inspect the 273 label stack for the presence of Label 14 at each hop. This proposed 274 new behaviour conflicts with the IETF definition of a swap operation. 275 The behaviour proposed in these specifications would have had major 276 consequences for deployed hardware designs. The outcome would have 277 been that the equipments built according to the two different 278 specifications would have been incompatible. It is important that 279 the atomic procedure defined in [RFC3031] is kept unchanged. 281 3.2. Redefinition of TTL Semantics 283 The standard method of delivering an OAM message to an entity on a 284 label switched path (LSP) such that the OAM message fate shares with 285 the data traffic is to use TTL expiry. The IETF's Internet Protocol 286 (IP) utilizes this mechanism for traceroute [RFC1393], as does MPLS 287 ping [RFC4379]. 289 At one stage, the T-MPLS designers considered a multi-level OAM 290 design in which the OAM packet was steered to its target by a process 291 in which some nodes increased the TTL as they forwarded the OAM 292 packet to its next hop. TTL is a safety device in the IETF IP and 293 MPLS architecture that prevents a packet from continuously looping 294 under fault conditions. Thus the proposed extension to support an 295 enhanced OAM mechanism violated an MPLS design invariant specifically 296 introduced to ensure safe operation of the Internet by preventing 297 persistent forwarding loops. 299 3.3. Reservation of Additional Labels 301 The IETF MPLS protocol uses a small number of reserved labels 302 [RFC3032] as a mechanism to provide additional context and to trigger 303 some special processing operations in the forwarder. All other 304 labels used for forwarding use semantics defined by the forwarding 305 equivalence class (FEC). In an early implementation of T-MPLS the 306 designers determined that they needed some additional labels to alert 307 the forwarder that the packet needed special processing. Thus a 308 conflict was thereby introduced between the behaviour of an IETF MPLS 309 LSR, and LSRs that operate according to the specification in the 310 ITU-T Recommendation. Thus some LSRs would attribute special 311 semantics to labels 16..31, whist other LSRs would perform normal 312 forwarding on them. 314 3.4. Redefinition of MPLS EXP Bits 316 The early MPLS documents defined the form of the MPLS label stack 317 entry [RFC3032]. This includes a three-bit field called the "EXP 318 field". The exact use of this field was not defined by these 319 documents, except to state that it was to be "reserved for 320 experimental use". 322 Although the intended use of the EXP field was as a "Class of 323 Service" (CoS) field, it was not named a CoS field by these early 324 documents because the use of such a CoS field was not considered to 325 be sufficiently defined. Today a number of standards documents 326 define its usage as a CoS field [RFC3270], [RFC5129], and hardware is 327 deployed that assumes this exclusive usage. 329 The T-MPLS designers, unaware of the historic reason for the 330 "provisional" naming of this field assumed that they were available 331 for any experimental use and re-purposed them to indicate the 332 maintenance entity level (a hierarchical maintenance mechanism). 334 The intended use of the EXP field was subsequently carried in 335 [RFC5462], which reinforces this by formally changing the name to 336 Traffic Class (TC). 338 3.5. The Consequences for the Network Operators 340 Two consequences arose for the users of the T-MPLS protocol. 341 Firstly, those who deployed development versions of the protocol were 342 exposing their network to hazards explicitly guaranteed by the IETF 343 MPLS protocol suite to not occur. Indeed those operating T-MPLS in 344 production networks in anticipation of later adoption of the MPLS 345 Transport Profile (MPLS-TP) may still experience those hazards; and 346 vendors continuing to distribute T-MPLS equipment expose their 347 customers to the same hazards. 349 The second consequence was to delay the necessary enhancements to 350 MPLS to meet their needs [I-D.ietf-mpls-tp-requirements] as the IETF 351 and ITU-T executed a redevelopment of MPLS-based transport network 352 protocols. 354 3.6. The Consequences for the SDOs 356 The process of resolution required considerable resources and 357 introduced a great deal of conflict between the IETF and the ITU-T, 358 much of which was exposed to public scrutiny, to the detriment of 359 both organizations. In particular this conflict resolution process 360 consumed the very resources required to develop an optimal 361 architecture for MPLS in transport networks. 363 4. MPLS-TP As Best Practice 365 In order to bridge the gap between the two organizations, the IETF 366 and the ITU-T established a joint working team (JWT) to assess 367 whether it was possible to enhance existing MPLS standards to provide 368 a best in class solution for transport networks. The outcome of this 369 investigation is reported in [RFC5317]. 371 The JWT proposed a design that was acceptable to both SDOs. This has 372 lead to the creation of the MPLS-TP project. This is a joint project 373 in which the ITU-T experts work with the IETF on protocol development 374 tasks; and IETF members work within the ITU-T to understand 375 requirements, and to assist in the creation of the ITU-T 376 recommendations that describe MPLS-TP in which the technical 377 definition is provided through normative references to IETF RFCs. 379 5. IANA considerations 381 There are no requests for IANA allocation of code-points in this 382 document, nor are any other IANA actions required. 384 6. Security considerations 386 The uncoordinated development of protocols is poses a risk of harm to 387 the Internet and must not be permitted. The enhancement or 388 modification of a protocol can increase attack surfaces considerably 389 and may therefore compromise the security or stability of the 390 Internet. The IETF has a review process that combines cross area 391 review with specialist security review by experts familiar with the 392 development and deployment context of the Internet protocol suite. 393 In particular, because of the Internet infrastructure's reliance on 394 the IP and MPLS protocol suites, this security review process must be 395 exercised with considerable diligence. Failure to apply this review 396 process exposes the Internet to increased risk along both security 397 and stability vectors. 399 7. Acknowledgments 401 The authors wish to acknowledge Loa Andersson and the members of the 402 2009/2010 Internet Architecture Board. Additionally we wish to 403 acknowledge Malcolm Johnson, Director, ITU Telecommunication 404 Standardization Bureau and Yoichi Maeda ITU-T Study Group 15 Chair, 405 for their review of this draft and their contribution of text. 407 8. Generalization from this Case Study 409 Although we have used T-MPLS as a case study, there is potential 410 conflict between other ongoing ITU-T projects and core IETF 411 specifications, for example [Y.2015] , [Q.Flowsig] . There are new 412 areas of potential conflict also emerging from the other work of 413 ITU-T SG13 Question 7, "IPv6" for example: [Y.ipv6split] and 414 [Y.ipv6migration]. 416 9. Conclusion 418 It is important that all SDOs developing standards that effect the 419 operation of the Internet learn the lessons that arise from the 420 T-MPLS experience. Uncoordinated parallel work between SDOs creates 421 significant problems with potentially damaging operation impact to 422 those that deploy and use the Internet. SDOs need to work jointly on 423 new projects in such a way that the safety of the Internet is assured 424 and the expertise of the organizations concerned is applied 425 optimally. 427 10. References 429 10.1. Normative References 431 10.2. Informative references 433 [E.164] ITU-T, "ITU Recommendation E.164: The international public 434 telecommunication numbering plan", February 2005. 436 [I-D.ietf-mpls-tp-requirements] 437 Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 438 and S. Ueno, "MPLS-TP Requirements", 439 draft-ietf-mpls-tp-requirements-08 (work in progress), 440 May 2009. 442 [LS26] ITU-T Study Group 15, "Cooperation Between IETF and ITU-T 443 on the Development of MPLS-TP, Geneva, 1-12 December 2008, 444 https://datatracker.ietf.org/documents/LIAISON/ 445 file596.pdf". 447 [Q.Flowsig] 448 ITU-T Study Group 11, "ITU-T Study Group 11, Question 5, 449 Signalling protocols and procedures relating to flow state 450 aware access QoS control in an NGN; draft 451 Recommendation.". 453 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 454 January 1993. 456 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 457 Label Switching Architecture", RFC 3031, January 2001. 459 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 460 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 461 Encoding", RFC 3032, January 2001. 463 [RFC3245] Klensin, J. and IAB, "The History and Context of Telephone 464 Number Mapping (ENUM) Operational Decisions: Informational 465 Documents Contributed to ITU-T Study Group 2 (SG2)", 466 RFC 3245, March 2002. 468 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 469 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 470 Protocol Label Switching (MPLS) Support of Differentiated 471 Services", RFC 3270, May 2002. 473 [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for 474 Multiprotocol Label Switching Architecture (MPLS) 475 Operation and Maintenance (OAM) Functions", RFC 3429, 476 November 2002. 478 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 479 Label Switched (MPLS) Data Plane Failures", RFC 4379, 480 February 2006. 482 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for 483 Protocol Extensions and Variations", BCP 125, RFC 4775, 484 December 2006. 486 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 487 Multiprotocol Label Switching (MPLS) and Generalized MPLS 488 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 489 June 2007. 491 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 492 Marking in MPLS", RFC 5129, January 2008. 494 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 495 Report on MPLS Architectural Considerations for a 496 Transport Profile", RFC 5317, February 2009. 498 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 499 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 500 Class" Field", RFC 5462, February 2009. 502 [Y.1711-2002] 503 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM 504 mechanism for MPLS networks", November 2002". 506 [Y.1711-2004] 507 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM 508 mechanism for MPLS networks", February 2004". 510 [Y.1711am1] 511 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 512 Amendment 1, New Function Type Codes, October 2005.". 514 [Y.1711cor1] 515 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 (2004) 516 corrigendum 1, February 2005.". 518 [Y.2015] ITU-T Study Group 13, "ITU-T Study Group 13, Question 5, 519 "General Requirements for ID/Locator Separation in NGN"". 521 [Y.ipv6migration] 522 ITU-T, "ITU draft Y.ipv6migration : Roadmap for IPv6 523 migration from NGN operators perspective", 2009. 525 [Y.ipv6split] 526 ITU-T, "ITU draft Y.ipv6split : Framework of ID/LOC 527 separation in IPv6-based NGN", 2009. 529 Authors' Addresses 531 Stewart Bryant (editor) 532 On behalf of the IAB 534 Phone: 535 Fax: 536 Email: stbryant@cisco.com 537 URI: 539 Monique Morrow (editor) 540 On behalf of the IAB 542 Phone: 543 Fax: 544 Email: mmorrow@cisco.com 545 URI: