idnits 2.17.1 draft-chakravorty-6lsa-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1164. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2008) is 5769 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) -- Missing reference section? '1' on line 1072 looks like a reference -- Missing reference section? '2' on line 1075 looks like a reference -- Missing reference section? '3' on line 1078 looks like a reference -- Missing reference section? '4' on line 1081 looks like a reference -- Missing reference section? '5' on line 1084 looks like a reference -- Missing reference section? '6' on line 1089 looks like a reference -- Missing reference section? '7' on line 1093 looks like a reference -- Missing reference section? '8' on line 1097 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Chakravorty 3 Internet-Draft J. Bush 4 Expires: January 10, 2009 The MITRE Corporation 5 J. Bound 6 NAv6TF 7 July 9, 2008 9 IPv6 Label Switching Architecture 10 draft-chakravorty-6lsa-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2009. 37 Abstract 39 This specification provides an architectural framework, called IPv6 40 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric 41 packet transmission technique that uses the IPv6 packet header Flow 42 Label to establish IPv6-based label switched paths. The label 43 switched paths, called 6LSPs, provide application and user specified 44 routes for efficient transport of packets and as means for quality of 45 service (QoS) delivery, IPv4 tunneling, VPN and other mechanisms. 46 Through look-ups of 20-bit labels instead of 128-bit IPv6 addresses, 47 the architecture may provide potential memory and processing savings, 48 the latter through significantly reduced address fetches for the low- 49 powered, handheld devices. The label has two components comprising 50 Global Label value and Local Label value. The Global Label value 51 from the source is delivered to the destination unmodified. However, 52 the intermediate network nodes in 6LSA are allowed to temporarily 53 replace the Local Label value with a value of local significance. 54 This enables 6LSA flows to be hop-specific although session-based and 55 as such a unique QoS delivery technique for bandwidth constrained 56 media. 6LSA also enhances security since label generation and 57 assignment algorithms can be modified periodically. 59 Finally, it must be pointed out that the 6LSA concept of temporary 60 flow label assignment is applicable to the 6LSA domain only. The 61 concept is not applicable to domains outside the 6LSA. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Distinguishing Characteristics of 6LSA . . . . . . . . . . . . 7 69 5. Routing Versus Switching of IP Traffic . . . . . . . . . . . . 8 70 6. 6LSA Basic Components and Their Attributes . . . . . . . . . . 9 71 6.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6.2. Forwarding Equivalence Class (FEC) . . . . . . . . . . . . 9 73 6.3. Label . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.4. Labeled Packet . . . . . . . . . . . . . . . . . . . . . . 13 75 6.5. IPv6 Label Switching Router (6LSR) . . . . . . . . . . . . 13 76 6.6. Lead Packet . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.7. Switching Table . . . . . . . . . . . . . . . . . . . . . 14 78 7. Attributes of Label Binding . . . . . . . . . . . . . . . . . 14 79 8. IPv6 Label Switched Path (6LSP) . . . . . . . . . . . . . . . 15 80 9. 6LSA Architectural Functionalities . . . . . . . . . . . . . . 15 81 10. Label Assignment . . . . . . . . . . . . . . . . . . . . . . . 17 82 10.1. Locally Generated Label Model . . . . . . . . . . . . . . 17 83 10.2. Distributed Label Model . . . . . . . . . . . . . . . . . 18 84 10.3. Reuse Label Model . . . . . . . . . . . . . . . . . . . . 19 85 11. Scope and Uniqueness of Labels . . . . . . . . . . . . . . . . 19 86 12. Label Retention Mode . . . . . . . . . . . . . . . . . . . . . 19 87 13. Label Stacking . . . . . . . . . . . . . . . . . . . . . . . . 20 88 14. Label Swapping . . . . . . . . . . . . . . . . . . . . . . . . 20 89 15. Packet Processing Algorithms . . . . . . . . . . . . . . . . . 20 90 16. Fast Switching . . . . . . . . . . . . . . . . . . . . . . . . 22 91 17. FEC Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 18. Invalid Incoming Labels . . . . . . . . . . . . . . . . . . . 23 93 19. Flow Aggregation or Merging . . . . . . . . . . . . . . . . . 23 94 20. Label Encodings . . . . . . . . . . . . . . . . . . . . . . . 23 95 21. Anycast in 6LSA . . . . . . . . . . . . . . . . . . . . . . . 23 96 22. Multicast in 6LSA . . . . . . . . . . . . . . . . . . . . . . 24 97 23. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 24. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 25. Informative Referneces . . . . . . . . . . . . . . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 101 Intellectual Property and Copyright Statements . . . . . . . . . . 27 103 1. Introduction 105 Several approaches have been developed over the past decade to 106 provide QoS in large networks. These include DiffServ, RSVP, MPLS, 107 ATM, extensions to routing protocols, and proprietary mechanisms. 108 Some of these techniques can also be applied to IPv6 transport but 109 not directly. IPv6 offers strong features to enable QoS delivery, 110 most significant among them are the Flow Label and the Routing Header 111 extensions. 113 The IPv6 Label Switching Architecture (6LSA) specified here enables 114 fast switching using 20-bit labels instead of 128-bit IPv6 addresses 115 and thereby provides memory and processing savings, the latter 116 because address fetches for low-powered, handheld devices, which are 117 mostly 32-bit architectures, could be up to four times as fast. The 118 architecture allows temporary replacement of labels inserted by a 119 source node with the proviso that the original labels are reinserted 120 prior to the packet arriving at its destination. 122 This document introduces an architectural framework for the use of 123 IPv6 packet header Flow Labels for setting up labeled paths of local 124 significance to provide services that cannot be provided by a purely 125 routed, connectionless approach. The 6LSA allows local label 126 generation in a network node. It also allows a network management 127 entity updating available label tables, across the network to reduce 128 man-in-the-middle attacks. 130 This local label generation coupled with dynamic labeling helps the 131 6LSA to provide the means for mobile nodes to set up labeled paths, 132 automatically and/or manually, for end-to-end QoS delivery or for any 133 other service delivery. 135 2. Overview 137 The IPv6 label switching mechanism makes use of the 20-bit Flow Label 138 in the IPv6 header to assign flow IDs which are used for labeled 139 paths, also called IPv6 label switched paths (6LSPs). The 140 specification of IPv6 label is in conformance with RFC 3697 RFC 3697 141 [1], IPv6 Flow Label Specification, in which the use of Flow Label 142 has been recommended for establishing different types of flows at the 143 source nodes and packet classification in the intermediate nodes. 144 The proposed mechanism of IPv6 label switching broadens the scope of 145 the use of Flow Labels beyond its simple use for packet 146 classification to its use of packet classification and forwarding. 147 The component of the Flow Label, called Local label value, is locally 148 assigned in the packet header along a path. This part of the Flow 149 Label can be different from the corresponding part of the original 150 Flow Label assigned by the source and as such this component is 151 temporary and has only per hop significance unless such significance 152 is extended to multiple hops. 154 The 6LSA concept of Flow Label assignment is applicable to the 6LSA 155 domain only. Whether the concept is applicable to domains outside 156 the 6LSA is of no concern to 6LSA unless there is one-to-one mapping 157 in the labels and implied significance. 159 In a conventional router, the forwarding decision is independently 160 made in each router as the packet travels from one router to the 161 next. In each router, the packet header is analyzed using a network 162 layer routing algorithm to find the best next-hop that is often the 163 shortest distance to the next router. Since this forwarding in each 164 router is "independent" of how the previous packet for the same 165 destination was processed and forwarded, the routing is considered 166 connectionless. 168 The process specified in this document supports two functions: first, 169 grouping of packets of similar flow requirements into a Forwarding 170 Equivalence Class (FEC), and second, forwarding all packets belonging 171 to an FEC along the same path. The forwarding of packets does not 172 necessarily have to be along the paths as determined by the routing 173 algorithms or by manual configuration provided there is no looping of 174 packets caused by the 6LSA forwarding. 176 In 6LSA, the FEC is encoded in the Flow Label field as a non-zero 177 value, which is also called label in this document. The label is 178 available in one of 3 ways: (1) locally generated, based on certain 179 algorithm or policy, (2) in the incoming packet, as Flow Label from a 180 source node, or (3) distributed, through a label distribution 181 process. The assignment of a label to an FEC is identified as a 182 binding. Once the binding of a label is created and provided to an 183 FEC, the forwarding policy of the packet may be represented through 184 the label and is maintained at a minimum for the duration of the 185 session. 187 The selection of the FEC is based on one or more flow 188 characteristics. The selection of flow characteristics and therefore 189 of FEC is an administrative, service or policy decision, or a 190 combination thereof. Such a decision is meant to support certain 191 traffic requirements, such as availability bandwidths on certain 192 links, VPN (Virtual Private Network) configuration, values encoded or 193 configured into the Traffic Class field of IPv6 packet headers, or 194 requirements conveyed by the source or administrative entity or by 195 other means. A superset of global FEC selections and corresponding 196 label values are included in this document. 198 Merging of flows on a single 6LSP is possible with the consequence 199 that two or more flows are inseparable and indistinguishable inside a 200 6LSA domain from the merger node to the egress or penultimate node. 201 Merging of flows may lessen the amount of state maintained within 202 6LSA nodes, however, since there is no stacking of labels in 6LSA and 203 each packet's label has to be examined individually, the processing 204 saving is insignificant. 206 The 6LSA label supports the forwarding of packets belonging to the 207 same FEC along an IPv6 Label Switched Path (6LSP). For the lead 208 packet of each flow, traffic class, source and destination addresses, 209 and possibly other special handling requirements conveyed by the 210 source (e.g., by a control plane protocol) may be examined for FEC 211 identification and label selection. This decision process is 212 independently carried out on each 6LSA node transited by the lead 213 packet across a 6LSA domain. Subsequent packets of the same flow (or 214 a group of flows) typically do not go through the same process of 215 label selection and assignment because the label binding to an FEC 216 and egress interface has been cached. So, the subsequent packets can 217 be rapidly forwarded. 219 The 6LSA domain routers are not cognizant of labels outside of their 220 domain. 222 3. Terminology 224 This section provides a general overview of alphabetically arranged 225 terms that are used in this document. Some of these terms are more 226 precisely defined in the later sections of this document. 228 6LSA a set of nodes that perform 6LSA routing and 229 forwarding operations and are in one 230 6LSA domain 232 6LSP label switched path, a virtual path, through 233 a pair or more 6LSA nodes 235 6LSR IPv6 label switching router that is capable 236 of forwarding IPv6 packets based on 237 FEC attributes 239 FEC Forwarding Equivalent Class, collection of IP 240 packets that receive the same forwarding 241 treatment and are forwarded over the 242 same 6LSP 244 Flow sequence of packets identified by the 245 Flow Label 247 Switching table forwarding table that comprises packet 248 forwarding information 250 4. Distinguishing Characteristics of 6LSA 252 The 6LSA characteristics justify its application wherever IPv6 is 253 deployed and where QoS network performance or other service delivery 254 is required, or where other available packet forwarding mechanisms 255 cannot deliver packet performance end-to-end. The following special 256 characteristics of 6LSA are listed here in no particular order: 258 o 6LSA technology offers a methodology for use of flow label in 259 the IPv6 header which is as yet unused. 261 o No Extraneous Label Bindings - 6LSA eliminates the need for 262 using extraneous labels (labels from other than Layer 3) and/or 263 eliminates the need for associated label distribution across the 264 network 266 o No IPSec Constraints - 6LSA does not need to use the Layer 4 267 ports to define a flow and therefore can be used with IPSec VPNs or 268 other IPSec based services. 270 o Free of Layer 2 Overheads - Being a layer 3 packet forwarding 271 solution, the 6LSA does not need a layer 2 packet forwarding 272 mechanism such as ATM and as such 6LSA avoids ATM's fragmentation and 273 re-assembly delays and associated header overhead. It also avoids 274 the need for added signaling and state machine mechanisms to provide 275 ATM switched paths and ship-by-night capabilities. Additionally, 276 being based on routing protocols (6LSRs peer in Layer 3), 6LSA tends 277 to avoid the potential for O(N2) and O(N3) problems. 279 o Deployment Ease - The 6LSA can be deployed over all layer 2 280 protocols such as Ethernet and PPP. There is no layer 2 interface 281 limitation in 6LSA. 283 o Extensive QoS Label Space - The 20-bit Flow Label in addition 284 to the 8-bit Traffic Class field can provide a huge traffic 285 classification space, both the fields may be used together in the 286 6LSA. 288 o Feature Visibility - All of the IPv6 packet header features are 289 available while the packet is enroute to destination as such IPSec or 290 similar packet encryption does not disable the delivery of QoS or 291 other similar services that 6LSA can provide. 293 o IPv6 Transition Support - During the transition from IPv4 to 294 IPv6, the latter is generally deployed as network-islands surrounding 295 IPv4/MPLS core. The implementation of 6LSA in native IPv6 edge 296 networks will greatly facilitate traffic engineering between the edge 297 and the core by mapping 6LSA Global Label value in the Flow Label to 298 be carried over to MPLS label in the core if the FEC representation 299 by the flow label is common in both domains, for example, if the 300 label represents a given bandwidth, say. 302 o Security Enhancement - Since 6LSA allows node-local generation 303 of labels, such generation, where adopted, can be made totally random 304 or periodically synchronized across the 6LSA domain to considerably 305 reduce man-in-the-middle attacks. 307 To summarize, 6LSA provides a significant layer 3 capability for 308 switching IP packets - with little or no added overhead for 309 signaling. 311 5. Routing Versus Switching of IP Traffic 313 The routing of packets on the Internet has the following essential 314 characteristics in addition to connectionless, non-sequential packet 315 transport: 1) The paths are not dedicated virtual paths, and 2) There 316 is generally no delivery or QoS guarantee - only a single class of 317 traffic is available. 319 Switching of packets has the following basic characteristics: 1) The 320 routing of packets is connection-oriented; the flow of packets 321 comprises sequential packets, 2) The packets travel over dedicated, 322 virtual paths or virtual circuits (VCs) which are either temporary or 323 permanent, and 3) Switching is generally associated with certain 324 delivery guarantees and traffic classification. 326 The issues with switching are: 328 * There are delays caused by VC setup time across the network. 330 * There is a need for VC state maintenance. 332 * IP address to VC translation latency is always present however 333 small. 335 * Potential is there for large resource wastage in case of a link or 336 node failure in IP virtual network over switched network, for example 337 IP over ATM that may cause N2 and N3 problems. 339 The design of 6LSA overcomes the above disadvantages of switching by 340 making the establishment of the switched path hop-specific but flow 341 session bound. 343 6. 6LSA Basic Components and Their Attributes 345 In this section, the 6LSA basic components and their attributes are 346 defined. 348 6.1. Flow 350 A flow in 6LSA is identified by the label value in the Flow Label 351 field in the IPv6 packet header. All packets belonging to the same 352 flow must be sent with the same Flow Label per hop, at a minimum, and 353 from the source node to the destination node, at a maximum. The 354 label in the lead packet and that in the subsequent packets of a flow 355 may be different or the same depending upon the algorithm selected. 356 In 6LSA domain, non-zero label identifies a best effort delivery. 358 6.2. Forwarding Equivalence Class (FEC) 360 The FEC represents a group of IPv6 packets that all receive the same 361 forwarding treatment. The forwarding treatment may be based on one 362 or more attributes associated with an FEC or other processing 363 requirements imposed on the flow externally. 365 Several flows from multiple sources may receive the same forwarding 366 treatment and thus belong to the same FEC. For example, if multiple 367 flows are to be processed in the same outgoing queue because they all 368 deliver the same service, they are identified by the same FEC. 370 6.3. Label 372 A label is the 20-bit, fixed length Flow Label identifier in the IPv6 373 header. A node in the 6LSA binds the Flow Label to a Forwarding 374 Equivalency Class (FEC) and uses it to forward the packet. The label 375 may thus represent the FEC. In the 6LSA, the FEC indicates the 376 forwarding treatment a group or class of packets (with a given label) 377 receives. This label and the FEC it represents have only local (per 378 hop) significance unless the attributes associated with a FEC are 379 shared among multiple hops. 381 A label is thus associated with the characteristics of a flow which 382 is represented in the FEC. 384 A flow label is assigned to a flow by the flow's source node. New 385 flow labels must be chosen (pseudo-)randomly and uniformly. The 386 purpose of the random allocation is to make any set of bits within 387 the Flow Label field suitable for use as a hash key by routers, for 388 looking up the state associated with the flow. 390 A label in an incoming packet is called an "incoming label", and that 391 in an outgoing packet is called an "outgoing label". 393 The 6LSA nodes are permitted, but not required, to verify that the 394 flow conditions are satisfied. If a violation is detected, it should 395 be reported to the source by an ICMP parameter Problem message, Code 396 0, pointing to the high-order octet of the Flow Label field. 398 A source node must not reuse a flow label for a new flow within the 399 maximum lifetime of any flow-handling state that might have been 400 established for the prior use of that flow label. 402 The first 7 bits of the Flow Label are of global nature that all 403 nodes in a 6LSA domain need to treat identically. This component of 404 the Flow Label thus must be maintained end-to-end without any change. 405 The security implications of maintaining Global Labels end-to-end are 406 clear and therefore will not be addressed further in this document. 408 A primary selection of Global Label value is presented here below for 409 FEC usage as guidance. Note that the most significant bit is the 410 left most bit. In the selection provided below, only the first 3 411 leftmost bits identify the superset of the flow characteristics. The 412 next four bits provide further identify granularity of the flow 413 characteristics. 415 The selection for the Enterprise Specific category allows an 416 enterprise such as a corporation, service provider, or governmental 417 agency to have their own specific Global Value component to take 418 advantage of enterprise's unique feature sets and for added security. 420 The last 13 bits can be locally selected by each node or a group of 421 nodes; they are typically hop-specific. This hop specificity may 422 extend for more than one hop. Any node not associated with this hop 423 need not adhere to the selected FEC. The Local Label Value is of 424 local significance only unless it is extended to more than the local 425 hop associated nodes. 427 The Global Label value provides space for 8 major categories each 428 with 16 different subcategories. A substantive subcategory of 429 reserved space is also available for future or application specific 430 use. 432 The total Local Label value space available to 6LSA nodes is between 433 1 and 2^13 times yielding the ability to uniquely identify 8,192 434 6LSPs per physical (or virtual) port per hop. The label space 435 applies to each physical interface. 437 +--------------------------+-------------+--------------------------+ 438 | FEC (First 3 Bits) | Next 4 Bits | Purpose | 439 +--------------------------+-------------+--------------------------+ 440 | No FEC (000) | 0000 | | 441 | Domain Specific (000) | 0001 - 1111 | | 442 | ------------------------ | | | 443 | VPN (001) | 0001 | (IPSec - Tunnel Mode) | 444 | | 0010 | (IPSec - Transport Mode) | 445 | | 0011 | (Special Encryption) | 446 | | 0100 | (VRF) | 447 | | 0101 | (End Network Specific) | 448 | | 0110 - 1111 | (Reserved) | 449 | ------------------------ | | | 450 | TE Subset/ | 0001 | (DiffServ) | 451 | QoS Enhancement (010) | 0010 | (RSVP) | 452 | | 0011 | (RSVP-TE) | 453 | | 0100 | (SIP) | 454 | | 0101 | (H323) | 455 | | 0110 | (Large File) | 456 | | 0111 | (Circuit Emulation) | 457 | | 1000 | (Fixed Bandwidth) | 458 | | 1001 | (Video Streaming) | 459 | | 1010 | (Multicast) | 460 | | 1011 | (Anycast) | 461 | | 1100 | (Queue Weighting) | 462 | | 1101 | (Precedence Sensitive) | 463 | | 1110 | (Enterprise Signal) | 464 | | 1111 | (Reserved) | 465 | ------------------------ | | | 466 | Encapsulation (011) | 0001 | (IPv6 in IPv6) | 467 | | 0010 | (IPv4 in IPv6) | 468 | | 0011 | (Other in IPv6) | 469 | | 0100 | (Enterprise Specific) | 470 | | 0101 - 1111 | (Reserved) | 471 | ------------------------ | | | 472 | Enterprise Specific(111) | 0000 - 1111 | (Reserved) | 473 +--------------------------+-------------+--------------------------+ 475 As an example, between nodes A and B in a 6LSA domain, if there is a 476 group of packets that are tunneling IPv4 packets in IPv6, then the 477 first 7 bits of the label for all these packets will be marked 478 0110011. A 6LSA node may choose to use the remaining bits to signify 479 different physical or logical ports or such other characteristics 480 that are locally assignable. 482 For each of the above selections, up to 8,192 additional local 483 selections are available for each FEC group for one or more hops as 484 represented by the remaining 13-bit space. 486 A total of 16 selections are available to an enterprise for use as 487 desired. For each of these 16 selections, an enterprise may use 488 additional 13 bits in the remaining flow label space for node 489 specific processing needs. 491 It is envisioned that an application, middleware, end-system socket 492 software or network node software will be enabled to encode the 493 needed FEC for a flow just as DSCP marking is encoded for DiffServ. 495 In this document, the nomenclature of label or Flow Label is 496 variously used though the meaning is the same and while referring to 497 the word label used in other technologies, such as in MPLS, the 498 context of the technology is also mentioned to distinguish the 499 application and meaning of the word. 501 6.4. Labeled Packet 503 In 6LSA, a labeled packet is an IPv6 packet whose header has a non- 504 zero Flow Label value. 506 If an incoming packet into a 6LSA node has a zero label value and it 507 is not a lead packet, it is assigned a non-zero label value before it 508 is forwarded. This is because in 6LSA, a zero label is used to 509 indicate that the packet is a best-effort packet. 511 The label from a flow in the 6LSA may be transferred to a non-6LSA 512 network layer or to a non-6LSA data link layer as long as there is a 513 field available that can carry the 6LSA label. The particular 514 encoding technique and its significance must be agreed by both the 515 layers - layer 3, the network layer, and layer 2, the data link 516 layer. Specifics of the method of this encoding are outside the 517 scope of this document. 519 6.5. IPv6 Label Switching Router (6LSR) 521 A router operating in the 6LSA is an IPv6 label switching router, 522 called 6LSR, which performs as a minimum the two 6LSA functions of: 523 1) replacing (swapping) an incoming label in a packet with an 524 outgoing label, and 2) forwarding the packet based on the appropriate 525 forwarding treatment. 527 6.6. Lead Packet 529 A packet arriving at a 6LSA node is a lead packet if it is the first 530 packet of the flow that this node has received. A lead packet may or 531 may not be the first packet of the flow that the upstream router or 532 6LSR forwarded to this 6LSR. It is possible that the first packet in 533 the flow is lost or misdirected, or for that matter, first few 534 packets in the flow are lost or misdirected. 536 All lead packets, whether they are the first packet from the upstream 537 6LSA node or not, are treated like they were the first packet of the 538 flow. 540 Lead packets have no existing entry in the switching table of a 6LSR 541 or 6LSA node. 543 6.7. Switching Table 545 A switching table in 6SLA is often called the forwarding table in the 546 networking literature. This table comprises the following 547 information as they become available: 549 -- Label value from the lead packet, if there is a non-zero 550 label otherwise a zero value is entered 551 -- Incoming interface, that is, interface on which the 552 packet arrived 553 -- Next hop IPv6 address 554 -- Outgoing interface, that is, the interface on which the 555 packet is forwarded to the next-hop 6LSR 556 -- FEC value that identifies the forwarding operation that 557 needs to be performed on a packet 559 The outgoing label entered in the switching table has to be unique so 560 that this node or 6LSR is able to identify a unique LSP for the 561 packet. 563 Additional information that may be available in the switching table 564 is as follows. 566 * The data link layer and encapsulation to use 567 * How the label value, typically the Local Label value, needs 568 to be encoded in the label field 569 * Timers associated with the packet 570 * Last packet in the flow 571 * Information with regard to how to discard labels or packets 573 The format and content of the switching table entry are 574 implementation and configuration specific and are not specified here. 576 7. Attributes of Label Binding 578 The binding of a label to a FEC is based on known attributes of the 579 packet or on externally applied constraints. The binding of a label 580 to a FEC is local to a 6LSA node unless such binding is promulgated 581 across the network through some exterior means such as a using a 582 label distribution protocol (LDP) commonly used for MPLS. LDP is 583 outside the scope of this document. 585 8. IPv6 Label Switched Path (6LSP) 587 A label switched path in the 6LSA is called 6LSP and identifies a 588 virtual circuit through which one or more flows are routed to the 589 next-hop 6LSR. 591 The sequence of 6LSA nodes, that is, the sequence of nodal interfaces 592 through which labeled packets are transported represents a 6LSP. A 593 6LSP is thus represented by a label between any two nodes, and by one 594 or more sequence of labels between multiple nodes, or between two or 595 more hosts, or any combination thereof. Conversely, a 6LSP may also 596 represent the FEC binding of each flow in each of the 6LSR on the 597 6LSP. In this regard, 6LSP closely resembles a virtual circuit (VC) 598 in ATM, and LSP in MPLS. 600 9. 6LSA Architectural Functionalities 602 This section describes 6LSA functionalities including label 603 acquiring, label binding to FEC, and label swapping. 605 a) The 6LSA comprises two basic functions: first, 606 grouping of packets of similar flow requirements 607 into a FEC, and second, speedily forwarding all 608 packets belonging to an FEC along the same path - 609 including flow merging when multiple flows have 610 the same FEC characteristics. 612 b) A 6LSA domain edge 6LSR replaces the incoming 613 Local Label in a packet with an outgoing Local Label 614 establishing a unique 6LSP for one or more packets 615 in the flow associating it with the same incoming 616 Flow Label and source and destination address 617 combination. Each 6LSA node ensures there is no 618 duplication of 6LSPs from itself to the downstream 619 node for the same FEC. 621 c) An intermediate 6LSR receives a flow on a unique 622 6LSP. It replaces the incoming label with a FEC 623 bound outgoing label based on the needed local 624 treatment of the packet. The last 13 bits in the 625 label that this 6LSR encodes represent the local 626 6LSP that this 6LSR sets up. This last locally 627 encoded 13-bit value may add unique characteristics 628 to the treatment of the packet or its path in 629 addition to the global FEC treatment requirements. 630 The total label value is entered in the local 631 switching table. The packet is then forwarded to 632 the next downstream 6LSR. The first 7 bits 633 representing global FEC part may not be changed by 634 a 6LSA node. 636 d) Within a 6LSA domain, if a router is a 6LSR, it 637 swaps the label, if it is not a 6LSR; it lets the 638 flow pass without any label changes. 640 e) Each 6LSP is maintained at least for the duration 641 of the session of transport of all packets in a 642 flow. In 6LSA, labels may be maintained for a 643 pre-determined time after a session has ceased to 644 exist, that is, for a fixed amount of time 645 determined a-priori after packets belonging to a 646 flow have ceased to arrive. 648 There are two salient points that need to be emphasized. First, the 649 same label is not used for any two 6LSPs from an upstream 6LSR to a 650 downstream 6LSR for the same pair of physical ports. Second, the 651 last 13 bits of a label may have little significance for the 652 downstream 6LSR unless it is aware of the significance of these bits 653 a-priori. It has relevance for the upstream 6LSR which uses it to 654 bind an FEC to the label and then uses the 6LSP to forward all the 655 packets in a flow. The 6LSP thus becomes a representation of the FEC 656 and forwarding pointer for the upstream 6LSR. The only time a 6LSP 657 and therefore the associated full label has any relevance value to 658 the downstream 6LSR is when the label bindings are distributed across 659 a given 6LSA domain. 661 A 6LSA label by default creates a tunnel for all packets in a flow 662 since the significance of the label bound to an FEC requires a 663 special handling by every node for all packets in the flow which is 664 not unlike a tunnel. The processing of packets based only on the 665 label, once a specific label has been assigned to a flow for each 666 hop, is similar to processing of a tunneled flow where the processing 667 is generally determined by the tunnel header bits. 669 The incoming flows into any of the nodes can arrive on one or more 670 6LSPs. If the outgoing flows are merged onto the same 6LSP, the 671 downstream node receives the merged flow with the same label. 672 Packets belonging to a merged flow although are from different flows, 673 they each still need to be examined by their label. However, once 674 the flows are merged, distinction between individual flows may not be 675 necessary for packet forwarding. 677 10. Label Assignment 679 In the 6LSA, the decision to assign or bind a label to a particular 680 FEC is made by a 6LSA node, generally by the ingress node if it is 681 not the origination point for that flow. The 6LSA host or node then 682 informs the next-hop, downstream node of this binding via this 683 labeled IPv6 packet or via some other method depending on the nature 684 of label generation and distribution methodologies. 686 Three models have been identified for acquiring label space. The 687 first model specifies how the labels can be generated locally; the 688 second model refers to how labels can be acquired from label 689 distribution, and the third, how labels are acquired from incoming 690 packet headers. Only one of these three models of label assignment 691 is allowed in a network of 6LSA-based nodes. 693 Once a label binding is available, the 6LSA requires that the label 694 binding be retained for the duration of the session. 696 It is quite possible that multiple flows may require the same label 697 and label binding to a single FEC. In these cases, all such flows 698 may be multiplexed or merged together as one outgoing flow and 699 forwarded on one 6LSP using the same label. At the de-multiplexing 700 6LSA node downstream, the flows must be discernible through the 701 unique source and destination addresses or through other means. 703 The 6LSA does not prevent any 6LSA node from storing any label 704 generated at a time different from when it is being used nor does it 705 prevent a node from using any label that was used earlier or 706 retrieved from a flow that used an algorithm or a model other than 707 those identified here. 709 10.1. Locally Generated Label Model 711 In this model, 6LSA allows a node to generate its own labels to be 712 used in the IPv6 header. The specification for the algorithm(s) used 713 to generate the 20-bit labels is beyond the scope of this document. 715 An example algorithm for generating flow labels is a pseudorandom 716 number generator outputting values within the parameters algorithm in 717 which the bit values are within the parameters specified in Section 718 6.1, Label. It is envisioned that a set of labels will be generated 719 for every service class, elastic and inelastic, such as file 720 transfer, voice, video, etc. 722 The Locally Generated Label model does not preclude manual generation 723 of a label or range of labels through a configurator or similar other 724 means. The locally generated label may have a value related to one 725 or more attributes that is applicable to the next-hop node or nodes 726 across the network. 728 The 6LSA specification allows labels that are locally generated but 729 may have non-local significance. Such attributes may be regularly or 730 randomly refreshed by a network management or other systems. 731 Methodologies for such refreshment are outside the scope of this 732 specification. The Global Label part (the first 7 bits) has by 733 default the same significance for all nodes in 6LSA. However, the 734 Local Label value (the last 13 bits) may or may not have only local 735 significance. 737 This model is not a mandatory part of 6LSA, i.e., a node is not 738 required to implement this model in order to be considered 6LSA- 739 compliant. However, when a 6LSA node claims to implement the Locally 740 Generated Label Model, the implementation must conform to the 741 specification given in this document. 743 The use of this model is encouraged because it is simple, efficient 744 and avoids control plane traffic for label distribution as in the 745 Distributed Label Model. 747 The Locally Generated Label Model enhances security since the labels 748 have local significance only and can be randomly or periodically 749 refreshed all through the 6LSA domain prior to their use. 751 10.2. Distributed Label Model 753 The 6LSA allows distribution of the Local Label (value) space 754 generated in one or more nodes or externally in a server. The 755 architecture also allows more than one label distribution protocol 756 (LDP) and sharing of necessary information amongst the label 757 distribution peers. 759 Mechanisms or protocols that allow a Local Label distribution and do 760 not violate any of the 6LSA specification with regard to use of such 761 labels and the operation of 6LSA nodes are allowed. The specifics of 762 label distribution protocols are outside the scope of this document. 764 The specifics of the process by which a node binds a label to a FEC 765 are implementation specific and thus outside the scope of this 766 document. 768 The Distributed Label Model enhances security if the labels have 769 local significance only and can be randomly or periodically refreshed 770 all through the 6LSA domain prior to their use. For reasons of 771 efficiency, this label model may only distribute the Local Value part 772 of the label. 774 10.3. Reuse Label Model 776 The 6LSA allows a node to reuse existing label available in the node 777 or obtained from labels in the incoming packets and where the flows 778 can be associated with unique label bindings. 780 11. Scope and Uniqueness of Labels 782 A label in a packet on a 6LSP must be unique to a flow, in any given 783 direction, between interfaces on peering nodes that are one hop 784 apart. 786 A flow always originates at the upstream source node in the 6LSA 787 domain, continues through multiple 6LSRs and terminates in the 788 destination node which also must exist in the 6LSA. Such a flow must 789 carry a non-zero label in its lead packet. 791 In the unusual event where two flows have lead packets with the same 792 label, the follow-on labels used by the ingress routers are kept 793 different for the two flows. In all 6LSR routers, the discriminator 794 for these two lead packets is the physical port, source and 795 destination address pair or such other means as allowed by the 6LSA 796 implementer. 798 To summarize, the discriminator for the incoming packets from an 799 upstream 6LSR to this 6LSR is the 6LSP and the discriminator for the 800 outgoing packets from this 6LSR to a downstream 6LSR is the FEC. 801 Generally, for a flow, an incoming label represents the upstream 6LSP 802 and an outgoing label represents the downstream FEC. In many cases, 803 the same label may be usable or used for both. 805 12. Label Retention Mode 807 If a 6LSR B receives a label binding from a 6LSR A for a particular 808 FEC via LDP, even though B is more than one hop apart from A, then 809 such binding may be retained or discarded by B. If the binding is 810 retained, then this binding may be used later when A becomes a next- 811 hop 6LSR to B. If the binding is discarded, then B will have to 812 acquire a new binding for traffic from A through one of the three 813 models described in Section 10. 815 13. Label Stacking 817 The 6LSA does not allow IPv6 label stacking. There is only one label 818 in an IPv6 packet and this label must be in the Flow Label field in 819 the IPv6 packet header. The 6LSA allows multiple label spaces per 820 platform; however, the use of the label must conform to the 821 specifications stated in this document. It should be noted that this 822 does not preclude other non-IPv6 label stacking such as layer 2 label 823 stacking. 825 14. Label Swapping 827 Label swapping or label switching is a process in which the incoming 828 label in a packet is replaced with an outgoing label. In this 829 document, this process is associated with multiple other activities. 830 These activities include matching the switching table entries with 831 certain incoming packet header fields, binding a label to the FEC, 832 updating the switching table and finally, forwarding the packet. 833 However, when the swapping involves only incoming label replacement 834 with an outgoing label, it is called label switching, which typically 835 is a fast process and may be carried out in the interface card 836 itself. 838 15. Packet Processing Algorithms 840 The 6LSA packet processing algorithm refers to handling of packets 841 that arrive from hosts in a 6LSA domain. The 6LSA packet processing 842 provides for QoS priority, VPN handling and other forwarding 843 treatments. 845 At a source node when an IPv6 packet is created, the Flow Label field 846 is encoded with a Global Value of the label depending on the nature 847 of the application. The Global value represents the generic nature 848 of the service or flow characteristics. It may be incognizant of and 849 unrelated to the hop-specific flow constraints that may exist. This 850 Global Value encoding is then followed by the hop specific Local 851 Value label encoding. This value may be locally generated, provided 852 by a routing or such other protocol, manually configured or a 853 combination thereof. 855 An example can best expound the labeling at a source node. Thus if a 856 source node application intends to send a SIP packet to the far end, 857 it determines the related Global Label value of the label which is 858 0100100 from the table provided in Section 6.3. Thereafter if the 859 local hop specific treatment requires that it be sent on a specific 860 physical port for a prioritized flow (since this signaling), it will 861 search the configuration information provided to it for a 862 corresponding applicable Local Label value. Let's assume, this flow 863 has to go through the fourth port and has the highest priority 864 handling requirement. Let's also assume that this is represented by 865 0000010000001. The total label value is then 0100100 00000010000001 866 and this then is encoded in the Flow Label field. Note that the node 867 carries out a few other activities such as inserting in the switching 868 table the source and destination of the packet, its Global and Local 869 label values, and such other needed items. This switching table can 870 also be used for holding configuration information such as FECs and 871 related Local Label values. 873 The Local label value may well have been determined from the routing 874 table as much as the Global Value from the Traffic Class field in the 875 packet header. How this determination is made in any specific 6LSA 876 domain or node is implementation specific. 878 In this example, the two characteristics of the flow represent the 879 FEC of the flow and the selected 20-bit label is then said to be 880 bound to this FEC. 882 Once the label has been bound to the FEC, the source node continues 883 to send packets encoding them with the same label for this flow. The 884 path of the flow then becomes the 6LSP for the flow. 886 At the next hop, an intermediate 6LSA node receives the packet on its 887 third port connected to the source node. It first checks to see if 888 either the Global or Local Label value exists in its Switching Table. 889 If there is a match available for the Global Value label, it goes to 890 Step 2, otherwise it follows Step 1. 892 Step 1: On examining the Global Label value, it determines the nature 893 of the flow. From information provided through routing protocol, 894 manual configuration or otherwise, it knows that such signaling flows 895 need to be sent out via the second port of the node and that all such 896 packets have to be queued ahead of all other packets. It identifies 897 a proper Local Label value, which say is: 0001010000001. It replaces 898 the incoming Local Label value with this value, queues the packet 899 ahead of all other packets in the outgoing buffer and forwards the 900 packet through the second port. This then presents the processing of 901 packet in the intermediate node. As was stated earlier for the 902 source node, additional processing takes place in the intermediate 903 node regarding updating of the switching table with the needed 904 information from the outgoing and incoming packets. 906 Step 2: If there is a match for the Global Label value, then the 907 Local Label value field is also searched in the Switching table and 908 if they both match, the incoming Local Label value is switched and 909 the packet is sent out via the second port. This continues for all 910 packets that have both values match. However, if there is no match 911 for the Local Value field, then the received packet is treated as the 912 lead packet of another flow coming from the same source and the 913 processing is identical to Step 1 since a new 6LSP has to be 914 established for this flow. 916 In uncommon cases, a source node may create two flows for the same 917 destinations with two FECs. If it does, the intermediate node has to 918 assign two different labels and provide two label bindings for the 919 two flows. 921 The processing that takes place in the second and subsequent 922 intermediate nodes is the same as that in the first. 924 The process at the destination node is similar to the first 925 intermediate node with the variation that the packets are forward to 926 the corresponding application in this node instead of forwarding them 927 out of this node. 929 Duplication of flow labeling is not possible since the local label is 930 always unique for each flow and LSP although the same label may be 931 used for different flows in unrelated hops out of the same node or 932 other nodes in the same 6LSA domain. 934 16. Fast Switching 936 When a 6LSR can simply swap an incoming label with an outgoing label 937 without going through insertion of new entry in the switching table 938 for that packet, then this swapping is termed fast switching in this 939 specification. This occurs when flow characteristics are well- 940 established or deterministic enough that no additional processing is 941 needed. One instance of this can occur in a 6LSA node where there is 942 one incoming port and one outgoing and there is only one FEC such as 943 is found commonly in the edge networks or other small or campus 944 network nodes. 946 17. FEC Mapping 948 Each FEC may map to a set of flows, node and route characteristics 949 which may be represented in the switching table. The switching table 950 may consist of more than one entry that a particular FEC can be 951 mapped to and forwarded via a labeled packet. 953 18. Invalid Incoming Labels 955 An incoming or acquired label is invalid if it has a value that does 956 not allow the 6LSA node to bind the label to a FEC. Such a label may 957 be discarded after the lead packet is forwarded. Invalid labels may 958 not include a zero-labeled packet. 960 19. Flow Aggregation or Merging 962 If it can be determined that two or more flows are destined for the 963 same network or non-6LSA domain, then flow merging are implemented. 964 The advantages are: less state is maintained in each 6LSR and there 965 is no need to differentiate between individual flows after the merge 966 point. 968 The 6LSA allows aggregation of labels when FECs represent address 969 prefixes. Since IPv6 address prefixes are aggregatable, aggregation 970 of FECs corresponding to aggregatable prefixes is allowed in the 971 6LSA. The extent of aggregation is a function of the address 972 aggregation, granularity of service desired or both. Such 973 aggregation may further be decided by the IPv6 packet header Traffic 974 Class parameters. 976 20. Label Encodings 978 The 6LSA allows encoding of the label value in layer 2 protocols such 979 as in ATM packet's VPI/VCI fields. Since only one label is used and 980 that each such label is uniquely identifiable in the 6LSA, encoding 981 the label in the ATM VPI/VCI field is feasible. Considerations with 982 respect to how flows are identified, the FEC-based forwarding 983 treatment, and flow merging issues, need careful planning in the 984 layer 2 label encoding. 986 How a 6LSA label value is encoded in the ATM VPI/VCI field is outside 987 the scope of this document. 989 21. Anycast in 6LSA 991 IPv6 defines the anycast address like a regular unicast address with 992 a prefix specifying the subnet and an identifier that is set to all 993 zeroes. Anycast packets delivered to this address are delivered to 994 one router in that subnet. There are reserved subnet anycast 995 addresses such as for mobile IPv6 Home-Agents anycast. The 6LSA 996 allows the use of anycast addressing. Whenever a 6LSR is a node in 997 any anycast subnet, such a subnet may be a 6LSA, a subset of 6LSA or 998 some other part of 6LSA. 1000 When an anycast packet arrives in anycast subnet 6LSR where the 1001 subnet is a part or whole of 6SLA, the 6LSR binds the packet to the 1002 appropriate FEC which has anycast routing as part of the forwarding 1003 treatment attributes of the FEC. The packet is thus forwarded to a 1004 next-hop 6LSR through an interface determined by the FEC attributes 1005 related to anycast forwarding. 1007 22. Multicast in 6LSA 1009 IPv6 defines the multicast address by the high-order octet FF or 1010 11111111 in binary notation and 4 bits for the scope of the multicast 1011 and an identifier bit that indicates whether the multicast address 1012 belongs to a well-known IANA multicast address group or is a 1013 temporary address. 1015 The 6LSA allows the use of multicast addressing. A multicast tree 1016 may be a 6LSA, or a subset of 6LSA. For multicast transmission, the 1017 6LSR binds the packet to a FEC which may represent multicast routing. 1018 The packet is thus forwarded to a next-hop 6LSR through an interface 1019 determined by the FEC attributes related to multicast delivery. See 1020 Section 6.3 above. 1022 23. Security Considerations 1024 The 6SLA allows Security Association (SA). If the security 1025 association partners are outside the 6SLA, then there is no effect on 1026 the 6SLA by the SA whether the mode of operation is in the transport 1027 mode or in the tunnel mode. 1029 In the transport mode of SA, only the packet payload is subject to 1030 encryption or authentication, so the IPv6 packet header features are 1031 not affected and the 6LSA being a transport mechanism that sets up 1032 6LSPs and provides specific FEC-driven forwarding treatment, there is 1033 no impact on the 6LSA or impact on SA operation by the 6SLA. 1035 In the tunnel mode of SA, the SA requires an outer wrapper IPv6 1036 packet. The sending gateway wraps the whole IPv6 packet including 1037 the content. The receiving gateway performs the checksum on the 1038 outer wrapper packet and then unwraps the packet and verifies the 1039 checksum of the inner packet through end-to-end SA. If the outer 1040 wrapper packet conveys the Flow Label value of the inner packet, then 1041 6SLA provides the 6LSP transport based on the inner label value, 1042 otherwise the transport indicates the outer label value. Here also, 1043 there is no impact on the 6LSA based transport of the secure packets 1044 or vice versa. 1046 The Authentication Header (AH) is used in IPv6 for authentication of 1047 individual packets to prevent common Internet-based attacks such as 1048 IP address spoofing and session hijacking. The computation of 1049 cryptographically secure checksum over the payload as well as some 1050 fields of the IPv6 and extension headers has to take place between 1051 the SA partners. This computation does not include the Flow Label 1052 field in the packet header. This maintains label transparency in the 1053 6SLA. Authentication can be either in the transport mode or in the 1054 tunnel mode. 1056 The 6SLA security considerations that apply to Encrypted Security 1057 Payload (ESP) header comprise encryption modes that are categorized 1058 as transport mode or tunnel mode. In the transport mode, no 1059 encryption of the Flow Label field is performed, so the value is 1060 carried through the 6SLA. In the tunnel mode, the issues are the 1061 same as stated here above. 1063 24. Disclaimer 1065 Any affiliation the first two authors have with The MITRE Corporation 1066 is provided for identification purposes only, and is not intended to 1067 convey or imply MITRE's concurrence with, or support for, the 1068 positions, opinions or viewpoints expressed by the authors. 1070 25. Informative Referneces 1072 [1] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 1073 Flow Label Specification", RFC 3697, March 2004. 1075 [2] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label 1076 Switching Architecture", RFC 3031, January 2001. 1078 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1079 Specification", RFC 2460, December 1998. 1081 [4] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", 1082 RFC 2375, July 1998. 1084 [5] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1086 McManus, "Requirements for Traffic Engineering Over MPLS", 1087 RFC 2702, September 1999. 1089 [6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, 1090 "Overview and Principles of Internet Traffic Engineering", 1091 RFC 3272, May 2002. 1093 [7] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in 1094 Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, 1095 January 2003. 1097 [8] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1098 Addressing Architecture", RFC 3513, April 2003. 1100 Authors' Addresses 1102 Sham Chakravorty 1103 The MITRE Corporation 1104 7515 Colshire Dr. 1105 McLean, VA 22102 1106 USA 1108 Email: schakra@mitre.org 1110 Jeff Bush 1111 The MITRE Corporation 1112 7515 Colshire Dr. 1113 McLean, VA 22102 1114 USA 1116 Email: jbush@mitre.org 1118 Jim Bound 1119 NAv6TF 1120 PO Box 570 1121 Hollis, NH 03049 1122 USA 1124 Email: Jim.Bound@ipv6forum.com 1126 Full Copyright Statement 1128 Copyright (C) The IETF Trust (2008). 1130 This document is subject to the rights, licenses and restrictions 1131 contained in BCP 78, and except as set forth therein, the authors 1132 retain all their rights. 1134 This document and the information contained herein are provided on an 1135 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1136 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1137 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1138 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1139 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1140 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1142 Intellectual Property 1144 The IETF takes no position regarding the validity or scope of any 1145 Intellectual Property Rights or other rights that might be claimed to 1146 pertain to the implementation or use of the technology described in 1147 this document or the extent to which any license under such rights 1148 might or might not be available; nor does it represent that it has 1149 made any independent effort to identify any such rights. Information 1150 on the procedures with respect to rights in RFC documents can be 1151 found in BCP 78 and BCP 79. 1153 Copies of IPR disclosures made to the IETF Secretariat and any 1154 assurances of licenses to be made available, or the result of an 1155 attempt made to obtain a general license or permission for the use of 1156 such proprietary rights by implementers or users of this 1157 specification can be obtained from the IETF on-line IPR repository at 1158 http://www.ietf.org/ipr. 1160 The IETF invites any interested party to bring to its attention any 1161 copyrights, patents or patent applications, or other proprietary 1162 rights that may cover technology that may be required to implement 1163 this standard. Please address the information to the IETF at 1164 ietf-ipr@ietf.org.