idnits 2.17.1 draft-herbert-ipv6-service-token-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- 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 (May 12, 2017) is 2513 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5226' is mentioned on line 602, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC2460' is defined on line 621, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-herbert-6man-icmp-limits-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: November 2017 6 May 12, 2017 8 Service token option for IPv6 9 draft-herbert-ipv6-service-token-option-00 11 Abstract 13 This document describes the service token option in IPv6. The service 14 token option expresses to the network the services that should be 15 applied to a packet. The service token allows network infrastructure 16 to map packets to a service class for processing in the network. The 17 contents of service tokens are not globally defined, their meaning 18 and semantics are defined for individual networks. Applications 19 request service tokens from their network provider for the services 20 they wish to be applied. The service tokens are sent in either 21 Destination options or a Hop-By-Hop options IPv6. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Current solutions . . . . . . . . . . . . . . . . . . . . . 3 62 1.2 SPUD and PLUS solution . . . . . . . . . . . . . . . . . . . 3 63 1.3 Emerging use cases . . . . . . . . . . . . . . . . . . . . . 4 64 2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1 Example packet flow . . . . . . . . . . . . . . . . . . . . 6 66 2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3 Packet format . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1 Option format . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.2 Option types . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3 Service token . . . . . . . . . . . . . . . . . . . . . . . 9 71 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1 Origin application operation . . . . . . . . . . . . . . . . 10 73 4.2 Origin network processing . . . . . . . . . . . . . . . . . 10 74 4.3 Peer processing . . . . . . . . . . . . . . . . . . . . . . 11 75 4.4 Handling dropped extension headers . . . . . . . . . . . . . 11 76 4.4.1 Mitigations for dropped extension headers . . . . . . . 11 77 4.4.2 Fallback for dropped extension headers . . . . . . . . . 11 78 5 Implementation considerations . . . . . . . . . . . . . . . . . 12 79 5.1 Origin applications . . . . . . . . . . . . . . . . . . . . 12 80 5.2 Reflection . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 82 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 83 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 8.1 Normative References . . . . . . . . . . . . . . . . . . . 14 85 8.2 Informative References . . . . . . . . . . . . . . . . . . 14 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1 Introduction 90 Modern provider networks, such as those being designed for the 5G 91 mobile standard, offer a variety a services to applications for 92 processing packets. Applications need to coordinate with the network 93 get desired services applied to their packets. This coordination 94 entails that the applications signal to the network in some manner 95 what its characteristics are and what its requirements are for 96 service. This document describes a method for an application to 97 explicitly signal the network to request services. 99 1.1 Current solutions 101 In the current Internet, there is little coordination between hosts 102 and the network to provide services based on characteristics of the 103 application. Differentiated services provide some service 104 classification, however it is lacking in richness of expression and 105 pervasiveness in use. Some network operators have resorted to do Deep 106 Packet Inspection (DPI) whereby HTTP is parsed to determine URL, 107 content type, and other application level information the network is 108 interested in. DPI is limited only to the application layer protocols 109 that the device is programmed to parse and more importantly is being 110 effectively obsoleted in the network due the pervasive use of TLS. 112 1.2 SPUD and PLUS solution 114 SPUD (Session Protocol Underneath Datagrams) and its successor PLUS 115 (Path Layer UDP Substrate) proposed a UDP based protocol to allow 116 applications to signal a rich set of characteristics and service 117 requirements to the network. 119 SPUD has a number of drawbacks: 121 o SPUD is based on specific protocol over used over UDP. This 122 requires applications to change to use a new protocol. In 123 particular SPUD is incompatible with TCP which is the 124 predominant transport protocol on the Internet. 126 o SPUD requires that intermediate nodes parse and process UDP 127 payloads. Since UDP port numbers do not have global meaning 128 [RFC7605] this introduces the possibility of 129 misinterpretation and of silent data corruption if 130 intermediate nodes modify UDP payloads. SPUD attempts to 131 mitigate this issue with the use of magic numbers, however 132 that can only ever be probabilistically correct. 134 o SPUD included connection tracking in the network. This 135 problematic because: 137 o Not all communications have well defined connection 138 semantics-- for instance a unidirectional data stream has 139 no connection semantics at all. 141 o Connection tracking breaks multi-homing; it assumes that 142 all packets of a connection in both directions are seen 143 by the node doing connection tracking. Firewalls for 144 instance require all packets for a flow to always go 145 through the same device in both directions. This 146 disallows flexibility and optimized traffic flow that a 147 multi-home network device affords. 149 o The meta data information in SPUD would have global 150 definition. This problematic because: 152 o Application specific information could be leaked to 153 unknown and untrusted parties. 155 o Establishing a specification on what data should be 156 conveyed in SPUD will be difficult. Different service 157 providers may want different pieces of information, 158 applications may also have different ideas about what 159 information is safe to make visible. 161 1.3 Emerging use cases 163 In a typical client/server model of serving content, end host clients 164 communicate with Internet services. The clients are typically user 165 devices that are connected to the Internet through a provider 166 network. In the case of mobile devices, such as smart phones, the 167 devices are connected to the Internet through a carrier network. 168 Content providers (web servers) tend to be more directly connected to 169 the Internet, the largest of which can connect at exchange points. 171 Provider networks can be architected to provide different services 172 and levels of services to their users based on characteristics of 173 applications. For example, a mobile carrier network can provide 174 different latency and throughput guarantees for different types of 175 content. A network may offer different services for optimizing video: 176 streaming an HD movie might need high throughput but not particularly 177 low latency; a live video chat might have lower throughput demands 178 but have low latency requirements. 180 The emerging 3GPP standard for 5G defines a set of mechanisms to 181 provide a rich array of services for users. These mechanisms employ 182 Network Function Virtulization (NFV), Service Function Chaining 183 (SFC), and network slices that divide physical network resources into 184 different virtualized slices to provide different services. To make 185 use of these services the applications running in UEs (User 186 Equipment) will need to indicate desired services of the RAN (Radio 187 Access Network). For instance, a video chat application may request 188 bounded latency that is implemented by the network as a network 189 slice; so packets sent by the application should be mapped to that 190 network slice. 192 Note that an application service applies to both packet sent by UE 193 and those sent from a peer towards the UE. For the latter case, the 194 network needs to be able to map packets sent from hosts on the 195 Internet to the services requested receiving application. 197 2 Architecture 199 The figure below illustrates an example network path between two 200 hosts on the Internet. Note that each host connects to the Internet 201 via a provider network and provider networks are connected in the 202 Internet by transit networks. 203 _____ 204 __________ ( ) __________ 205 +--------+ ( ) ( ) ( ) +--------+ 206 | User 1 +---( Provider A )--( Transit )--( Provider B )---+ User 2 | 207 +--------+ (__________) ( ) (__________) +--------+ 208 (_____) 210 Figure 1 212 Within each provider network, services may be provided on behalf of 213 the users of the network. In the example above, Provider 1 may 214 provide services and service agreements for users in its network 215 including User 1; and likewise Provider B can provide services to 216 users in its network including User 2. Transit networks service all 217 users and don't typically provide user specific services or service 218 differentiation. 220 Services provided by different provider networks may be very 221 different and dependent on the implementation of the network as well 222 as the policies of the provider. 224 Based on this model, services and service differentiation can be 225 considered local to each provider of the network. This document 226 describes a mechanism whereby each user and application can request 227 from its local provider the services to be applied to its traffic. 228 The request is made to "service token provider". The contents of the 229 request describe the service requirements that application desires. 230 The service token provider responds with a "service token" that the 231 application sets in its packets. When a packet is sent by the 232 application with a service token, the token is interpreted in the 233 provider network to map the packet to the appropriate service. The 234 token is only relevant to the provider network, to both the 235 application and nodes outside of the provider network the token is an 236 opaque value. 238 To facilitate service mapping in the reverse direction for a flow, 239 that is packets sent from a peer host, peer hosts reflect the service 240 token without modification or interpretation. 242 The use of service tokens may be symmetric for a connection so that 243 each peer requests service. Therefore packets may contain two service 244 tokens: one that is set by the sending host to signal its local 245 provider network, and the other is the reflected service token that 246 is a signal to the provider network of the peer endpoint. 248 Service tokens are scoped values, they only have meaning in the 249 network for which they were defined. The destination option includes 250 an autonomous system value with each service option to indicate which 251 network interprets the value. The format, meaning, and interpretation 252 of service tokens is network (autonomous system) specific. By mutual 253 agreement, two networks may shared the policy and interpretations of 254 service tokens. For instance, there could be an agreement between two 255 autonomous systems to interpret each others service tokens or to use 256 a common format. 258 2.1 Example packet flow 260 Referencing the diagram in figure 1, consider that User 1 is 261 communicating with User 2 and wishes to have some service provided by 262 its local network (Provider 1). The flow of events may be: 264 1. User 1 wishes to create a live video chat with User 2 266 2. User 1 makes a service token request from service token 267 provider of Provider A that describes the video application and 268 may include detailed characteristics such as resolution, frame 269 rate, latency, etc. 271 3. Service token provider provides a token 273 4. Application sends packets with the service token set for the 274 video chat 276 5. Provider A interprets the service token and applies the 277 appropriate services to the packets 279 6. Packets traverse transit networks and Provider B network, the 280 service token is ignored 282 7. Packet is received at User 2. The service token is saved in the 283 context for the video session 285 8. User 2 sends video chat packets to User 1. The service token 286 received from User 1 is reflected in these packets 288 9. Packets traverse Provider B network and transit networks 290 10. Provider A interprets the reflected service token and applies 291 appropriate services to the packets 293 11. Packets are received at User 1 295 2.2 Requirements 297 The requirements for this solution are: 299 o Service tokens should be connectionless 301 o Service tokens should work in multi-homed environments 303 o Service tokens should indicate the network for which they are 304 applicable 306 o Outside of the relevant network the service token should be 307 opaque and no application specific information should be 308 derivable from the token 310 o Service tokens should work with any transport protocol 312 o Service tokens should minimize the changes to an application. 313 Their use should should be an "add-on" to the existing 314 communications of an application 316 o Service tokens should prevent spoofing and other misuse that 317 might result in illegitimate use of network services or denial 318 of service attack 320 o Deep packet inspection is not needed 322 o Service tokens must allow services to be applied in the reverse 323 path. In a client/server application it is often the packets in 324 the reverse path that require the most service (for instance if 325 a video is being streamed to a client). 327 o A fallback exists if packets with extension headers are dropped 329 3 Packet format 330 The service token is sent as Destination option or a Hop-By-Hop 331 option. 333 3.1 Option format 335 The same option types and format are used for both a Destination and 336 Hop-By-Hop option. The format of the option is: 338 1 2 3 339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Option Type | Opt Data Len | Type | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Autonomous number | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 ~ Service Token ~ 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Fields: 352 o ICMP Option type: 0x4F or 0x6F 354 o Opt Data Len: Length of the option data field. This is 6 + the 355 length of the service token field 357 o Type: Indicates the type and action of the service token. This 358 is one of: 360 o 0x0: Service token from origin, don't reflect at receiver 362 o 0x1: Service token from origin, reflect at receiver 364 o 0x2: Reflected service token 366 o 0x3-0xf: Reserved 368 o Autonomous number: AS for for the network in which the service 369 token is valid. A value of zero indicates the locally attached 370 network of the origin. 372 3.2 Option types 374 The service token may be sent as a Destination option or Hop-By-Hop 375 option. The rationale is that the two methods exhibit different drop 376 rates. For instance, [RFC7872] indicates that the drop rate to 377 Alexa's Top 1M Sites for Destination options was 10.91%, whereas Hop- 378 By-Hop options have a drop rate of 39.03% 380 The are two option numbers requested for the service token option: 381 0x4F and 0x6F. The latter allows modification. This would be used in 382 situations where the network nodes needed to modify the option with 383 new information. If the option is modifiable it should be a Hop-By- 384 Hop option. 386 3.3 Service token 388 The service token contains service parameters that describe the 389 desired services as well as additional fields that would be used to 390 provide private and integrity. 392 The format of the service token is defined by the network in which 393 the service token originates. The service token should be obfuscated 394 or encrypted for privacy. It should also be resistant to spoofing 395 when an attacker uses a service token seen on other flows to 396 illegitimately have service applied to its packets. 398 It is recommended that service tokens are encrypted and each token 399 has an expiration time. For instance, a service token may be created 400 by encrypting the token data with an expiration time and using the 401 source address, destination address, and a shared key as the key for 402 encryption. 404 For example, the security token for a network may have the format: 406 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Expiration time | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 411 ~ Service parameters ~ 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Where the expiration time is in a format that are understood by the 416 provider network nodes which maintain synchronized time. The Service 417 parameters are relevant to network nodes and describe the services to 418 be applied. The service parameters could simply be a set of flags for 419 services, an index to a service profile known by the network nodes, 420 or possibly have more elaborate structure that could indicate 421 numerical values for characteristics that have a range. The service 422 parameters could also include a type field to allow a network to 423 define different representations of service parameters. 425 A simple service token containing a service protocol index might be: 427 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Expiration time | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type | Service Profile Index | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 4 Operation 436 4.1 Origin application operation 438 An application that wishes to request services first requests a 439 service token from a service token provider. The application request 440 could be in the form of an XML structure with a canonical format (the 441 definition is outside the scope of this document). The application 442 makes a request to a service token provider for the local network. 443 This could be done a web service using HTTP PUT/GET. Internally in 444 the host the security token provider might be accessed through a 445 library that interfaces to a service token provider daemon that in 446 turn arbitrates requests between the applications and the network 447 infrastructure. 449 When the service token provider returns a token, the application sets 450 the token as Hop-By-Hop option or Destination option as indicated. 451 This is typically done by setting socket option on a socket (in the 452 case of TCP) or by indicating the option in the ancillary data when 453 sending on a socket (in the case of UDP). 455 The service token provider should return an expiration time with the 456 service token. An application can use the token until the expiration 457 time, at which point it must request a new service token. The service 458 token itself is opaque to the application and the application should 459 no attempt to interpret any meaning from it. 461 4.2 Origin network processing 463 When a packet with a service token enters a network referred to by 464 the autonomous system number it should be processed. The service 465 token is decrypted if necessary and the expiration time is checked. 466 If the service token is valid then the packet is mapped to be 467 processed by the requested services. For instance, in a 5G network 468 the packet may be forwarded on a network slice for the 469 characteristics the application has requested (real-time video for 470 instance). 472 Note that there are two points at which the provider needs to process 473 the service token: when a local user sends a packet into the provider 474 network, and when a packet from an external network enters the 475 provider's network with a reflected security token. Once the service 476 token is processed and mapped to the network's mechanism it should 477 not need further examination. 479 4.3 Peer processing 481 When an application receives a packet with a service token whose type 482 is "from origin and needs to be reflected", it should save the 483 service option in its flow context and reflect it on subsequent 484 packets. When the application reflects the option is copies the whole 485 option and only modifies the type to indicate a reflected option. The 486 application continues to reflect the service token until a different 487 one is received from the origin or a packet without a service token 488 option is received for the flow. 490 4.4 Handling dropped extension headers 492 The downside of using IPv6 extension headers on the Internet is that 493 they are unreliable. Some intermediate nodes will drop extension 494 headers with rates described in [RFC7872]. 496 4.4.1 Mitigations for dropped extension headers 498 There are some mitigating factors for this problem: 500 o A provider network that implements the service token protocol 501 defined in this document would need to ensure that the service 502 token option is usable within the network 504 o Transit networks are less likely to arbitrarily drop packets 505 with extension headers 507 o Many content providers, especially the larger ones, may be 508 directly connected to the Internet. For example, front end web 509 servers may be co-located as exchange points. 511 4.4.2 Fallback for dropped extension headers 513 Since the possibility that extension headers are dropped cannot be 514 eliminated, a fallback is included for use with service tokens. 516 When an application connects to a new destination for which it has no 517 history about the viability of extension headers, it can perform a 518 type of Happy Eyeballs probing. The concept is for the to send a 519 number of packets with and without the service token. The application 520 should observe whether packets with service tokens are being dropped. 522 There are a few possible outcomes of this process: 524 o A packet with a service token is dropped and an ICMP for 525 extension headers [ICMPEH] processing limits is received. This 526 is a signal that extension headers are not viable and should not 527 be used for the flow. 529 o A packet with a service token is dropped and no ICMP error is 530 received. This is a signal that extension headers may not be 531 usable. If such drops are observed for all or a significant 532 fraction of packets and there are no drops for packets that were 533 sent without the service token, then extension headers should be 534 considered not viable for the flow. 536 o Packets with service tokens are not being dropped, however 537 service tokens are not being reflected. This is a signal that 538 the peer application does not support reflection. Service tokens 539 may be sent, however they are only useful in the outbound path. 541 o Packet with service tokens are not being dropped and service 542 tokens are being reflected. Service tokens are useful in both 543 direction. 545 5 Implementation considerations 547 5.1 Origin applications 549 Existing client applications can be modified to request service 550 tokens and set them in packets. The kernel may need some small 551 changes or configuration to enable an application to specify the 552 option for its packets. 554 The interface to the service provider would likely be via a library 555 API. 557 Using the BSD sockets interface, for a connected socket (TCP, SCTP, 558 or connected UDP socket) the destination option can be set on the 559 socket via the setsockopt system call. For an unconnected socket 560 (UDP) the service token option can be set as ancillary data in the 561 sendmsg system call. 563 Extension header probing, described in section 4.4.2, could be 564 implemented in the kernel for a connection oriented transport 565 protocol such a TCP. For connectionless protocols, probing could be 566 handled by an application library. 567 5.2 Reflection 569 To perform reflection of the service option, a server must be 570 updated. In the case of a connected socket (TCP, SCTP, or a connected 571 UDP socket) this can be done as relatively minro change to the kernel 572 networking stack which would be transparent to application. For 573 unconnected UDP, an application could receive the security token as 574 part of the ancillary data in recvmsg system call, and then send the 575 security option in a reply using ancillary data in sendmsg. 577 6 Security Considerations 579 Service token options may be visible to the Internet including 580 untrusted and unknown networks in the path of sent packets. As such 581 the token should be encrypted or obfuscated by the origin network. 583 7 IANA Considerations 585 IANA is requested to assigned the following Destination and Hop-By- 586 Hop options: 588 +-----------+---------------+-------------+---------------+ 589 | Hex Value | Binary value | Description | Reference | 590 | | act chg rest | | | 591 +-----------+---------------+-------------+---------------+ 592 | 0x0F | 00 0 01111 | Service | This document | 593 | | | Token | | 594 +-----------+---------------+-------------+---------------+ 595 | 0x2F | 00 0 01111 | Modifiable | This document | 596 | | | Service | | 597 | | | Token | | 598 +-----------+---------------+-------------+---------------+ 600 IANA is requested to set up a registry for the Service Token option 601 types. These types are 4 bit values. New values for control types 602 0x3-0xf are assigned via Standards Action [RFC5226]. 604 +----------------+--------------------+---------------+ 605 | Service Token | Description | Reference | 606 | option type | | | 607 +----------------+--------------------+---------------+ 608 | 0x0 | Token from origin | This document | 609 | | and don't reflect | | 610 +----------------+--------------------+---------------+ 611 | 0x1 | Token from origin | This document | 612 | | and reflect | | 613 +----------------+--------------------+---------------+ 614 | 0x2 | Token not from | This document | 615 | | origin and reflect | | 616 +----------------+--------------------+---------------+ 618 8 References 619 8.1 Normative References 621 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 622 (IPv6) Specification", RFC 2460, December 1998. 624 8.2 Informative References 626 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 627 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 628 August 2015, . 630 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations 631 on the Dropping of Packets with IPv6 Extension Headers in 632 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, 633 . 635 [ICMPEH] Herbert, T., "ICMPv6 errors for discarding packets due to 636 processing limits", draft-herbert-6man-icmp-limits-00.txt 638 Author's Address 640 Tom Herbert 641 Quantonium 642 Santa Clara, CA 643 USA 645 Email: tom@herbertland.com