idnits 2.17.1 draft-herbert-ipv4-eh-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 214: '...s, an IPv4 packet MAY carry zero, one,...' RFC 2119 keyword, line 258: '...information that MAY be examined and p...' RFC 2119 keyword, line 268: '...specific to IPv6 MUST NOT be used with...' RFC 2119 keyword, line 288: '... header checksum MUST be set correctly...' RFC 2119 keyword, line 290: '...fragment packets MAY contain different...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2019) is 1837 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: 'RFC791' is mentioned on line 96, but not defined == Missing Reference: 'SRV6' is mentioned on line 123, but not defined == Missing Reference: 'RFC6834' is mentioned on line 353, but not defined ** Obsolete undefined reference: RFC 6834 (Obsoleted by RFC 9302) == Missing Reference: 'EHUDPENCAP' is mentioned on line 419, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 467, but not defined == Unused Reference: 'RFC7605' is defined on line 505, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-03 == Outdated reference: A later version (-02) exists of draft-hinden-6man-mtu-option-00 == Outdated reference: A later version (-07) exists of draft-herbert-fast-03 == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-geneve-01 == Outdated reference: A later version (-13) exists of draft-carpenter-limited-domains-06 Summary: 2 errors (**), 0 flaws (~~), 13 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: Proposed Standard Quantonium 4 Expires: October 2019 6 April 8, 2019 8 IPv4 Extension Headers and Flow Label 9 draft-herbert-ipv4-eh-00 11 Abstract 13 This specification defines extension headers for IPv4 and a 14 definition of an IPv4 flow label. The goal is to provide a uniform 15 and feasible method of extensibility that is shared between IPv4 and 16 IPv6. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2 IPv4 extension headers . . . . . . . . . . . . . . . . . . . 4 59 1.3 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . 5 60 2 IPv4 extension headers . . . . . . . . . . . . . . . . . . . . 5 61 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.1 General requirements . . . . . . . . . . . . . . . . . . 6 63 2.1.2 Fragmentation and reassembly requirements . . . . . . . 7 64 2.2 Interaction with standard IPv4 mechanisms . . . . . . . . . 7 65 2.2.1 IPv4 options and IPv4 extension headers . . . . . . . . 8 66 2.2.2 IPv4 fragmentation and IPv4 extension headers . . . . . 8 67 2.2.3 Atomic datagram recommendation . . . . . . . . . . . . . 8 68 3 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1 Sender requirements . . . . . . . . . . . . . . . . . . . . 9 70 3.2 Receiver requirements . . . . . . . . . . . . . . . . . . . 9 71 4 Deployability . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 73 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 74 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 76 7.2 Informative References . . . . . . . . . . . . . . . . . . 12 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1 Introduction 81 This specification defines extension headers for IPv4 as well as an 82 IPv4 flow label. The motivation is to provide an extensible mechanism 83 in IPv4 that is unified with IPv6 and thus facilitates leveraging 84 common protocol and implementation for extensibility between the two 85 versions of the Internet Protocol. 87 The extension headers defined for IPv6 in [RFC8200], specifically 88 Hop-by-Hop Options, Destination Options, Routing Header, and Fragment 89 Header are permitted for use with IPv4 (note that Authentication 90 Header and Encapsulating Security Payload are already usable with 91 IPv4). Additionally, No Next Header (protocol number 59) is defined 92 to be usable in IPv4 packets. 94 The IPv4 flow label is similarly derived from the definition of the 95 IPv6 flow label. There is no flow label defined in the IPv4 header 96 [RFC791], however under specific circumstances the sixteen bit 97 Identification field may safely be used as a flow label. 99 1.1 Motivation 101 IPv6 is intended to become the standard protocol of the Internet, 102 however it is clear that there is a large segment of users that will 103 be using IPv4 for the foreseeable future. This is particularly true 104 in many enterprises where a business case for transitioning to IPv6 105 hasn't yet emerged [V6STATE]. 107 In lieu of sun-setting IPv4 and expecting all users to move to IPv6 108 in some time frame that is unlikely to be met, this specification 109 suggests an alternative which is to improve IPv4. However the nature 110 of these improvements is very specific, the idea is to "backport" 111 useful features of IPv6 into IPv4. Essentially, this makes IPv4 look 112 more like IPv6. The rationale for this is two fold: 114 1) Users benefit from forward looking features being actively 115 defined and developed for IPv6 without requiring them to 116 transition to IPv6. 118 2) In making IPv4 look more like IPv6, the work required to 119 complete a future transition to IPv6 at some site may be 120 reduced or simplified. 122 Various proposals that would use IPv6 extensions are currently being 123 discussed in IETF. These include Segment Routing [SRV6], Compressed 124 Routing Header [CRH], Path MTU Option [MTUOPT], In-situ OAM [IOAM], 125 Service-aware IPv6 Network [SAIN], and Firewall and Service Tickets 126 [FAST]. These proposals leverage the extensibility mechanism of 127 extension headers defined for IPv6. All of these proposals, in some 128 form, could be of value for use with IPv4. Unfortunately, IPv4 does 129 not have an extensibility mechanism that meets the requirements for 130 supporting them. IP options are quite limited and have long been 131 considered obsolete. There have been proposal for encoding host to 132 network signaling in UDP (e.g. [SPUD], IOAM over encapsulation like 133 Geneve [IOAMGEN]), however these are shown to neither be generic nor 134 robust especially in the case that encapsulated data must be modified 135 in flight. 137 The proposal contained in this document is to enable IPv4 packets to 138 carry the extension headers in the same manner that IPv6 packets can 139 carry extension headers. In doing so, the various extensions for IPv6 140 can be used with IPv4 to the benefit of the user. In many cases (such 141 as IOAM and Path MTU option), the extension being defined is protocol 142 agnostic and would be applicable and usable with IPv4 with little or 143 no change. In other cases, such as segment routing, the extension 144 being defined might be IPv6 specific, for example the segment routing 145 header contains a list of IPv6 addresses. With some modification to 146 the extension definition, it is also conceivable that these may work 147 with IPv4. For instance, in the case of segment routing the extension 148 can be adapted for use with IPv4 by defining a routing header format 149 that contains IPv4 addresses instead of IPv6 addresses. 151 1.2 IPv4 extension headers 153 IPv4 options were defined in [RFC0791] as the means of extending the 154 IP protocol. IPv4 options have not been successful. Early router 155 implementations, and even those today, either don't process IPv4 156 options or relegate them to a slow path effectively making them 157 unusable for serious applications. IPv4 options are limited to forty 158 bytes length and, unlike TCP options, no IP options have been defined 159 that are critical to communications. The upshot is that IPv4 options 160 have long not been considered an option for deployment [IPNOOP]. 162 IPv6 took a different approach. Extensibility of IPv6 is provided by 163 extension headers. Optional internet-layer information is encoded in 164 separate headers that may be placed between the IPv6 header and the 165 upper-layer header in a packet [RFC8200]. IPv6 extension headers have 166 had mixed success in deployment in that some intermediate devices 167 have trouble processing them [RFC7872], however there are several 168 active proposals in IETF that would make use of them (e.g. [FAST], 169 [MTUOPT], [IOAM], [SRV6EH]). 171 Using extension headers with IPv4 is logically straightforward. The 172 IPv4 Protocol field is effectively re-designated to be a Next Header 173 field with the same meaning and semantics as the IPv6 Next Header 174 field. In this manner, an IPv4 packet can contain IPv6 extension 175 headers that are recast as IPv4 extension headers. These include Hop- 176 by-Hop Options, Routing Header, Fragment, Destination Options, 177 Authentication, and Encapsulating Security Payload. In cases where an 178 extension header contains IPv6 specific information, the extension 179 header can be adapted for use with IPv4. For instance, a Routing 180 Header carrying IPv6 addresses to visit could be adapted to carry 181 IPv4 addresses. 183 1.3 The IPv4 flow label 185 IPv6 [RFC8200] introduced the concept of a flow label that has proven 186 quite convenient to perform flow classification, such as that needed 187 by Equal-Cost Multipath (ECMP). The base IPv4 header does not have 188 reserved bits that could be allocated as a flow label, however the 189 sixteen bit Identification field can be used as a flow label in 190 atomic datagrams [RFC6864]. 192 The IPv4 flow label will be most useful in scenarios for which the 193 existing mechanisms used to classify IPv4 packets, such as parsing 194 transport layer headers to extract port information, aren't 195 available. Defining an IPv4 flow label is another instance of back 196 porting a beneficial feature from IPv6 and further unifying the two 197 protocols. 199 2 IPv4 extension headers 201 IPv4 extension headers are optional internet-layer information 202 encoded in separate headers that may be placed between the IPv4 203 header and the upper-layer header in a packet. IPv4 extension headers 204 are based on IPv6 extension headers and share the same basic 205 properties and semantics [RFC8200]. 207 Extension headers are numbered from IANA IP Protocol Numbers [IANA- 208 PN], the same values are used for IPv4 and IPv6. When processing a 209 sequence of Next Header values in a packet, the first one that is not 210 an extension header [IANA-EH] indicates that the next item in the 211 packet is the corresponding upper-layer header. A special "No Next 212 Header" value is used if there is no upper-layer header. 214 As illustrated in these examples, an IPv4 packet MAY carry zero, one, 215 or more extension headers, each identified by Protocol field of the 216 IPv4 header or the Next Header field of a preceding extension header: 218 +---------------+------------------------ 219 | IPv4 header | TCP header + data 220 | | 221 | Protocol = | 222 | TCP | 223 +---------------+------------------------ 225 +---------------+----------------+------------------------ 226 | IPv4 header | Hop-by-Hop | TCP header + data 227 | | | 228 | Protocol = | Next Header = | 229 | Hop-by-Hop | TCP | 230 +---------------+----------------+------------------------ 232 +---------------+----------------+-----------------+----------------- 233 | IPv4 header | Hop-by-Hop | Fragment header | fragment of TCP 234 | | | | header + data 235 | Protocol = | Next Header = | Next Header = | 236 | Hop-by-Hop | Fragment | TCP | 237 +---------------+----------------+-----------------+----------------- 239 2.1 Requirements 241 2.1.1 General requirements 243 IPv4 extension headers normatively assume the requirements of IPv6 244 extension headers as defined in [RFC8200] section 4, with the 245 following modifications: 247 * References to the IPv6 header are replaced by references to the 248 IPv4 header. 250 * ICMP errors sent in the course of processing extension headers 251 use ICMPv4 instead of ICMPv6. 253 * The IPv4 header Protocol field assumes the same role and 254 semantics with respect to extension headers as the IPv6 Next 255 Header field. 257 * The Hop-by-Hop Options header is used to carry optional 258 information that MAY be examined and processed by any node along 259 a packet's delivery path. 261 * If a legacy IPv4 destination node, one that does not support 262 IPv4 extension headers, receives a packet with extension headers 263 then the packet will be processed as having an unknown protocol. 264 It is expected that the packet will be discarded and an ICMP 265 error may be generated. 267 * Extension headers or options that carry IPv6 specific data or 268 are otherwise specific to IPv6 MUST NOT be used with IPv4 269 (Segment Routing [SRV6EH] for example). IPv4 variants of these 270 might be defined if achieving the same functionality in IPv4 is 271 desirable. 273 * References to the Payload Length, for instance in reassembly 274 procedures, are reinterpreted as being the computed IPv4 payload 275 length (i.e. IPv4 Total Length minus the length of the IPv4 276 header). 278 2.1.2 Fragmentation and reassembly requirements 280 The following are modifications to fragmentation and reassembly 281 requirements: 283 * References to setting the Payload Length field in the IPv6 284 header are interpreted to be setting the Total Length in the 285 IPv4 header taking into account the IPv4 header length. 287 * When creating or modifying IPv4 headers in packets, the IPv4 288 header checksum MUST be set correctly. 290 * Different fragment packets MAY contain different IPv4 options. 291 In the reassembled packet, the IP options are taken from the 292 first fragment packet (the one with offset of zero). 294 * Different fragment packets MAY contain different extension 295 headers preceding the fragment header. In the reassembled 296 packet, the extension headers preceding the fragment header are 297 taken from the first fragment packet (the one with offset of 298 zero). 300 * If the length and offset of a fragment are such that the Total 301 Length of the packet reassembled from that fragment would exceed 302 65,535 octets, then that fragment must be discarded and an ICMP 303 Parameter Problem, Code 0, message should be sent to the source 304 of the fragment, pointing to the Fragment Offset field of the 305 fragment packet. 307 2.2 Interaction with standard IPv4 mechanisms 309 IPv4 extension headers may be used concurrently with IPv4 mechanisms 310 such as IPv4 options and IPv4 fragmentation. This section discusses 311 the interactions. 313 2.2.1 IPv4 options and IPv4 extension headers 315 An IPv4 packet MAY contain both IPv4 options and extension headers. 316 IPv4 options are completely independent of IPv4 extension headers. 317 IPv4 options MUST be processed before processing any extension 318 headers per normal requirements of processing the IP header before 319 the IP payload. 321 2.2.2 IPv4 fragmentation and IPv4 extension headers 323 An IPv4 packet MAY be fragmented both by using a Fragment extension 324 header as well as by standard IPv4 fragmentation. The Fragment header 325 can only be set at the source, however intermediate devices can 326 fragment packets using standard IPv4 fragmentation. Standard IPv4 327 fragmentation at a source node MUST be done only after any extension 328 headers are set in a packet or the packet was fragmented using the 329 Fragment header. Specifically, fragmentation using the extension 330 header MUST NOT be done on packet fragments created by standard IPv4 331 fragmentation. However, a packet fragment that contains a Fragment 332 header MAY itself be fragmented by standard IPv4 fragmentation. There 333 is no correlation between normal IPv4 fragmentation and the IPv4 334 Fragment header, the identifier space for each are unrelated and 335 reassembly procedures are independent. 337 At a destination, if a received packet was fragmented by standard 338 IPv4 fragmentation, it MUST be reassembled before processing any IPv4 339 extension headers. This requirement ensures that standard IPv4 340 reassembly is done before reassembly for the Fragment header. 342 If an IPv4 packet containing Hop-by-Hop options is fragmented using 343 standard IPv4 fragmentation, the Hop-by-Hop Options are not set in 344 each of the packet fragments. An intermediate node MAY process the 345 Hop-by-Hop options in the first fragment if the complete Hop-by-Hop 346 extension header is contained within the fragment. If the Fragment 347 header is used with IPv4 then the DF bit (Don't Fragment) bit SHOULD 348 be set and Path MTU discovery mechanisms SHOULD be used. 350 2.2.3 Atomic datagram recommendation 352 It is RECOMMENDED to only use IPv4 extensions in atomic datagrams. 353 Atomic datagrams [RFC6834] are IPv4 packets for which the Don't 354 Fragment bit set, More Fragment bit is not set, and Fragment Offset 355 is zero. In this case the packet will not be subject to IPv4 356 fragmentation, the Fragment header can alternatively be used for 357 fragmentation. 359 3 The IPv4 flow label 361 The Identification field of the IPv4 header is re-purposed to be the 362 IPv4 flow label in atomic datagrams. As stated in [RFC6864]: 364 ">> Originating sources MAY set the IPv4 ID field of atomic 365 datagrams to any value." 367 This specification allows the IPv4 ID to be used as a flow label in 368 atomic datagrams where (DF==1)&&(MF==0)&&(frag_offset==0). 370 3.1 Sender requirements 372 An origin host MAY set the IPv4 Identification field as a flow label 373 in atomic datagram packets. The IPv4 flow label is set following the 374 same procedures for setting the IPv6 flow label as described in 375 [RFC6437], with the following modifications: 377 * The Identification field MUST only be used as a flow label in 378 atomic datagrams. That is Don't Fragment (DF) bit MUST be set, 379 More Fragment (MF) bit MUST NOT be set, and Fragment Offset MUST 380 be zero. 382 * If the IPv4 Identification field is not used as a flow label in 383 atomic fragments, the Identification field MUST be set to zero. 385 * Only stateless flow labels can be set. 387 * The value to set, e.g. from a hash computation over packet 388 headers, is truncated to sixteen bits (the size of the 389 Identification field). 391 * Intermediate nodes MUST NOT set the Identification field in 392 atomic datagrams. 394 3.2 Receiver requirements 396 Receivers, including intermediate hosts, MAY process a non-zero 397 Identification field in the IPv4 header of atomic datagrams as being 398 a flow label. The IPv4 flow label for instance can be used as input 399 to ECMP as described in [RFC6438]. 401 If the Identification field is zero or the packet is not an atomic 402 datagram (either the More Fragment bit is set, the Don't Fragment bit 403 is not set, or Fragment Offset is non-zero) then the Identification 404 field MUST NOT be considered as a flow label. 406 4 Deployability 408 If a legacy host device receives an IPv4 packet with IPv4 extension 409 headers, the packet will be treated as having an unknown protocol and 410 should dropped. Intermediate devices might also see packets with a 411 protocol unknown to them and will forward the packet inasmuch as they 412 would forward any packet with an unknown protocol. 414 In the Internet, it is well known that there are some intermediate 415 nodes that will drop packets with protocols that are unknown to them 416 (firewalls would commonly to this for instance). Therefore, it is 417 unlikely that packets with IPv4 extension headers can be ubiquitously 418 deployed over the Internet. A workaround to this might be to 419 encapsulate extension headers in UDP [EHUDPENCAP]. 421 In a limited domain [LIMDOM], an operator would have control over 422 intermediate nodes and could ensure that at a minimum they properly 423 forward packets with IPv4 extension headers. Routers in a limited 424 domain can be updated to process IPv4 Hop-by-Hop Options or Routing 425 headers to provide the functionality of features like IOAM and 426 Segment Routing in IPv4. Similarly, they could be updated to support 427 the IPv4 flow label to provide flow based ECMP in the same manner 428 that the IPv6 flow label is used for ECMP [RFC6438]. 430 5 Security Considerations 432 This specification enables use of IPv6 extension headers in IPv4. 433 Related security mechanisms of IPv6 extension headers can be applied 434 for use with IPv4 extension headers. 436 The IPv4 flow label has similar security properties as the IPv6 flow 437 label. If the security intent of the sender is to prevent 438 intermediate nodes in the network from classifying its traffic into 439 flows then the IPv4 flow label SHOULD NOT be used. 441 6 IANA Considerations 443 IANA is requested to change the descriptions of IPv6 extension 444 headers and No Next Header protocol numbers to reflect that they are 445 not IPv4 specific. 447 In the Assigned Internet Protocol Numbers Registry, the modified 448 protocols descriptions are: 450 +----------+---------+------------+-----------+--------------------+ 451 | Decimal | Keyword | Protocol | IPv6 | Reference | 452 | | | | Extension | | 453 | | | | header | | 454 +----------+---------+------------+-----------+--------------------+ 455 | 0 | HOPOPT | Hop-by-Hop | | [RFC8200][RFCXXXX] | 456 | | | Option | | | 457 +----------+---------+------------+-----------+--------------------+ 458 | 43 | Route | Routing | | [Steve_Deering] | 459 | | | Header | | | 460 +----------+---------+------------+-----------+--------------------+ 461 | 44 | Frag | Fragment | | [Steve_Deering] | 462 | | | Header | | | 463 +----------+---------+------------+-----------+--------------------+ 464 | 59 | NoNxt | No Next | | [RFC8200][RFCXXXX] | 465 | | | Header | | | 466 +----------+---------+------------+-----------+--------------------+ 467 | 60 | Opts | Destination| | [RFC8200][RFCXXXX] | 468 | | | Options | | | 469 +----------+---------+------------+-----------+--------------------+ 471 IANA is requested to update "Internet Protocol Version 4 (IPv4) 472 Parameters" to include sections for "IPv6 Extension Header Types", 473 "Destination Options and "Hop-by-Hop Options", and "Routing Types". 474 These are based on the similarly named sections in "Internet Protocol 475 Version 6 (IPv6) Parameters" with appropriate modifications for IPv4. 477 7 References 479 7.1 Normative References 481 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 482 1981. 484 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 485 (IPv6) Specification", STD 86, RFC 8200, DOI 486 10.17487/RFC8200, July 2017, . 489 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 490 RFC 6864, DOI 10.17487/RFC6864, February 2013, 491 . 493 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for 494 Equal Cost Multipath Routing and Link Aggregation in 495 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 496 . 498 7.2 Informative References 500 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations 501 on the Dropping of Packets with IPv6 Extension Headers in 502 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, 503 . 505 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 506 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 507 August 2015, . 509 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 510 "IPv6 Flow Label Specification", RFC 6437, DOI 511 10.17487/RFC6437, November 2011, . 514 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for 515 Equal Cost Multipath Routing and Link Aggregation in 516 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 517 . 519 [V6STATE] B. Kuerbis and M. Mueller, Internet Governance Project, 520 "The Hidden Standards War: Economic Factors Affecting IPv6 521 Deployment", February, 2019. 523 [SRV6EH] C. Filsfils, Ed., S. Previdi, J. Leddy, S. Matsushima, D. 524 Voyer, Ed., "IPv6 Segment Routing Header (SRH)", draft- 525 ietf-6man-segment-routing-header-16 527 [CRH] Bonica, R., So, N., Xu, F., Chen, G., Zhu, Y., Yang, G., 528 Zhou, Y., "The IPv6 Compressed Routing Header (CRH)" draft- 529 bonica-6man-comp-rtg-hdr-03 531 [MTUOPT] Hinden, R. and Fairhurst, G., "IPv6 Minimum Path MTU Hop- 532 by-Hop Option", draft-hinden-6man-mtu-option-00 534 [IOAM] F. Brockners, S. Bhandari, V. Govindan, C. Pignataro, H. 535 Gredler, J. Leddy, S. Youell, T. Mizrahi, D. Mozes, P. 536 Lapukhov, R. Chang, "Encapsulations for In-situ OAM Data" 538 [SAIN] Li, Z. and Peng, S., "Service-aware IPv6 Network", draft- 539 li-6man-service-aware-ipv6-network-00 541 [FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert- 542 fast-03 544 [SPUD] Hildebrbrand, J. and Trammell, B., Substrate Protocol for 545 User Datagrams (SPUD) Prototype, draft-hildebrand-spud- 546 prototype-03 548 [IOAMGEN] Brockners, F. et al., "Geneve encapsulation for In-situ OAM 549 Data", draft-brockners-ippm-ioam-geneve-01 551 [IPNOOP] Rodrigo Fonseca, George Manning Porter, Randy H. Katz, 552 Scott Shenker and Ion Stoica, "IP Options are not an 553 option", 554 557 [IANA-PN] IANA, "Protocol Numbers", 558 . 560 [IANA-EH] IANA, "IPv6 Extension Header Types", 561 . 563 [LIMDOM] Carpenter, B., and Liu, B., "Limited Domains and Internet 564 Protocols", draft-carpenter-limited-domains-06 566 Author's Address 568 Tom Herbert 569 Quantonium 570 Santa Clara, CA 572 USA 574 Email: tom@quantonium.net