RFC 8468

📄 RFC 8468 ✨: IPv4, IPv6, and IPv4-IPv6 Coexistence 🎀

okay bestie, let's get into it 💅 this one is an Informational doc (so not a Standards Track thing, it's published just to share info) 🌸 It's from the IETF, dated November 2018, and the authors are A. Morton (AT&T Labs), J. Fabini (TU Wien), N. Elkins (Inside Products, Inc.), M. Ackermann (Blue Cross Blue Shield of Michigan), and V. Hegde (Consultant) 🧚

It UPDATES RFC 2330 💖, which is the original IPPM framework. So this doc is basically an upgrade patch for it 🦋 It doesn't obsolete anything.

The title block stuff is done, so here's the full doc in the rewritten voice 🫶

---

1. Introduction 🌈

okay so the IETF IP Performance Metrics (IPPM) working group made the very first framework for metric development in [RFC2330] 👑 and honestly it has stood the test of time, like iconic 💅 it's been updated for metric composition in [RFC5835] and for active stream measurement of modern networks with reactive properties in [RFC7312] ✨

the IPPM framework [RFC2330] recognized (in Section 13) that a bunch of aspects of an IP packet can influence how it gets processed while it's moving across the network 🚀

so in Section 15 of [RFC2330], there's this idea of a "standard-formed" packet 🎀 but here's the tea: the definition never got expanded to include IPv6 😭 even though the authors of [RFC2330] literally called out the need for this update in Section 15: "the version field is 4 (later, we will expand this to include 6)" 🙈

and rn IPv6 Extension Headers and protocols that use IPv6 header compression are getting way more popular 📈 so this memo is here to provide the updates the original definition in [RFC2330] needs 🦋

2. Requirements Language 🍓

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in BCP 14 [RFC2119] [RFC8174] 💜 but only when they show up in all capitals, just like here ✨

3. Scope 🧚

the whole point of this memo is to expand what IPPM covers so it includes IPv6 🌸 plus it highlights extra stuff about test packets and makes them part of the IPPM framework 💖

the scope is to update key sections of [RFC2330] and add considerations that help people build new measurement methodologies for today's IP networks 🫶 specifically, this memo expands the Type-P examples in Section 13 of [RFC2330] and expands the definition (in Section 15 of [RFC2330]) of a standard-formed packet to cover IPv6 header aspects and other features 🌈

other topics in [RFC2330] that could also be updated or augmented are deferred to future work 🔮 that includes passive measurement and the various forms of hybrid active/passive measurement 🙈

more parts coming, stay tuned bestie 🦋

4. Packets of Type-P ✨

okay bestie, so here's the big idea 🧚 a LOT of Internet metrics give different results depending on what the IP packets actually look like 💅 The measured value depends on the IP header fields and their values, plus the higher-layer protocol headers and their values. 🎀 Say you're checking IP-connectivity. You'll get different answers if you're asking about packets going to well-known TCP ports vs unreserved UDP ports, packets with invalid IPv4 checksums, or packets with TTL or Hop Limit of 16. 😭 Sometimes those differences get special treatment in intermediate nodes and end systems, like when Diffserv [RFC2474], Explicit Congestion Notification (ECN) [RFC3168], Router Alert [RFC6398], Hop-by-Hop extensions [RFC7045], or Flow Labels [RFC6437] are in use, or when there are firewalls or RSVP reservations in the mix 🔥

Because of that, we introduce the generic notion of a "packet of Type-P" 💖 Sometimes P is totally explicit (exactly what type of packet we mean), sometimes it's partially defined (like "with a payload of B octets"), and sometimes it's left generic. So we can talk about generic IP-Type-P-connectivity or the more specific IP-port-HTTP-connectivity 🦋 Some metrics can be defined with generic Type-P definitions and then made specific when you actually go and measure stuff 🌸

Whenever a metric's value depends on the type of packets involved, the metric's name has to include either a specific type or a phrase like "Type-P" ✨ So we won't define an "IP-connectivity" metric. Instead we'll define an "IP-Type-P-connectivity" metric and/or maybe an "IP-port-HTTP-connectivity" metric. This naming convention is an important reminder that you need to be conscious of the exact type of traffic being measured 🫶

If the information constituting Type-P at the Source is found to have changed at the Destination (or at a measurement point between the Source and Destination, as in [RFC5644]), then the modified values MUST be noted and reported with the results. 📝 Some modifications happen because of conditions in transit (like congestion notification) or because of the requirements of segments on the Source-to-Destination path. For example, the packet length will change if IP headers get converted to the alternate version/address family, or if optional Extension Headers are added or removed. 🌈 Even header fields like TTL/Hop Limit, which usually change in transit, may be relevant to specific tests. For example, Neighbor Discovery Protocol (NDP) [RFC4861] packets are transmitted with the Hop Limit value set to 255, and the validity test specifies that the Hop Limit MUST have a value of 255 at the receiver, too. 👑 So while other tests may intentionally exclude the TTL/Hop Limit value from their Type-P definition, for this particular test the correct Hop Limit value is highly relevant and MUST be part of the Type-P definition 😭💅

Local policies in intermediate nodes that look at IPv6 Extension Headers may affect measurement repeatability 🙈 If intermediate nodes follow the recommendations of [RFC7045], repeatability may be improved to some degree ✨

A closely related note: it would be very useful to know if a given Internet component (like a host, link, or path) treats a class C of different types of packets equally. 🦋 If it does, then any one of those types of packets can be used for subsequent measurement of the component. This suggests we should devise a metric or suite of metrics that attempt to determine class C (a designation that has no relationship to address assignments, of course) 💜

Load-balancing over parallel paths is one particular example where such a class C would be more complex to determine in IPPM measurements 🍓 Load balancers and routers often use flow identifiers, computed as hashes (of specific parts) of the packet header, to decide among the available parallel paths a packet will traverse. Packets with identical hashes are assigned to the same flow and forwarded to the same resource in the load balancer's (or router's) pool. 🌀 The presence of a load balancer on the measurement path, plus the specific headers and fields used for the forwarding decision, aren't known when you measure the path as a black box 🙃 Potential assessment scenarios include measuring one of the parallel paths, or measuring all of the available parallel paths that the load balancer can use. So knowing a load balancer's flow definition (or its class-C-specific treatment in terms of header fields in scope of hash operations) is a prerequisite for repeatable measurements 🔥 A path may have more than one stage of load-balancing, which adds to the complexity of the class C definition 💀

5. Standard-Formed Packets ✨

okay bestie, so unless we say otherwise, every metric about IP packets quietly assumes the packet is standard-formed 💅 A packet counts as standard-formed if it meets all of the following REQUIRED criteria 🎀

• It includes a valid IP header. See below for version-specific criteria.
• It is not an IP fragment.
• The Source and Destination addresses correspond to the intended Source and Destination, including Multicast Destination addresses.
• If a transport header is present, it contains a valid checksum and other valid fields.

For an IPv4 packet (as specified in [RFC791] and the RFCs that update it) to be standard-formed, the following additional criteria are REQUIRED 🦋

• The version field is 4.
• The Internet Header Length (IHL) value is >= 5; the checksum is correct.
• Its total length as given in the IPv4 header corresponds to the size of the IPv4 header plus the size of the payload.
• Either the packet possesses sufficient TTL to travel from the Source to the Destination if the TTL is decremented by one at each hop or it possesses the maximum TTL of 255.
• It does not contain IP options unless explicitly noted.

For an IPv6 packet (as specified in [RFC8200] and any future updates) to be standard-formed, the following criteria are REQUIRED 🌈

• The version field is 6.
• Its total length corresponds to the size of the IPv6 header (40 octets) plus the length of the payload as given in the IPv6 header.
• The payload length value for this packet (including Extension Headers) conforms to the IPv6 specifications.
• Either the packet possesses sufficient Hop Limit to travel from the Source to the Destination if the Hop Limit is decremented by one at each hop or it possesses the maximum Hop Limit of 255.
• Either the packet does not contain IP Extension Headers or it contains the correct number and type of headers as specified in the packet and the headers appear in the standard-conforming order (Next Header).
• All parameters used in the header and Extension Headers are found in the "Internet Protocol Version 6 (IPv6) Parameters" registry specified in [IANA-6P].

Two mechanisms need a little discussion in the standard-formed context, namely IPv6 over Low-Power Wireless Area Networks (6LowPAN) [RFC4944] and Robust Header Compression (ROHC) [RFC3095] 🧚 6LowPAN, as defined in [RFC4944] and updated by [RFC6282] with header compression and [RFC6775] with neighbor discovery optimizations, proposes solutions for using IPv6 in resource-constrained environments. An adaptation layer enables the transfer of IPv6 packets over networks having an MTU smaller than the minimum IPv6 MTU. Fragmentation and reassembly of IPv6 packets, as well as the resulting state that would be stored in intermediate nodes, poses substantial challenges to measurements. Likewise, ROHC operates statefully in compressing headers on subpaths, storing state in intermediate hosts. The modification of measurement packets' Type-P by ROHC and 6LowPAN requires substantial work, as do requirements with respect to the concept of standard-formed packets for these two protocols. For these reasons, we consider ROHC and 6LowPAN packets to be out of the scope of the standard-formed packet evaluation.

The topic of IPv6 Extension Headers brings current controversies into focus, as noted by [RFC6564] and [RFC7045]. However, measurement use cases in the context of the IPPM framework, such as in situ OAM [IOAM-DATA] in enterprise environments, can benefit from inspection, modification, addition, or deletion of IPv6 extension headers in hosts along the measurement path. 🙈

[RFC8250] endorses the use of the IPv6 Destination Option for measurement purposes, consistent with other relevant and approved IETF specifications. 💜

The following additional considerations apply when IPv6 Extension Headers are present 👑

• Extension Header inspection: Some intermediate nodes may inspect Extension Headers or the entire IPv6 packet while in transit. In exceptional cases, they may drop the packet or route via a suboptimal path, and measurements may be unreliable or unrepeatable. The packet (if it arrives) may be standard-formed, with a corresponding Type-P.
• Extension Header modification: In Hop-by-Hop headers, some TLV-encoded options may be permitted to change at intermediate nodes while in transit. The resulting packet may be standard-formed, with a corresponding Type-P.
• Extension Header insertion or deletion: Although such behavior is not endorsed by current standards, it is possible that Extension Headers could be added to, or removed from, the header chain. The resulting packet may be standard-formed, with a corresponding Type-P. This point simply encourages measurement system designers to be prepared for the unexpected and notify users when such events occur. There are issues with Extension Header insertion and deletion, of course, such as exceeding the path MTU due to insertion, etc.
• A change in packet length (from the corresponding packet observed at the Source) or header modification is a significant factor in Internet measurement and REQUIRES a new Type-P to be reported with the test results.

It is further REQUIRED that if a packet is described as having a "length of B octets", then 0 <= B <= 65535; and if B is the payload length in octets, then B <= (65535-IP header size in octets, including any Extension Headers). The jumbograms defined in [RFC2675] are not covered by the above length analysis, but if the IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a packet with corresponding length MUST be considered standard-formed. In practice, the path MTU will restrict the length of standard-formed packets that can successfully traverse the path. Path MTU Discovery for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU Discovery (PLPMTUD, [RFC4821]) is recommended to prevent fragmentation. 🍓

So, for example, one might imagine defining an IP-connectivity metric as "IP-Type-P-connectivity for standard-formed packets with the IP Diffserv field set to 0", or, more succinctly, "IP-Type-P-connectivity with the IP Diffserv field set to 0", since standard-formed is already implied by convention. Changing the contents of a field, such as the Diffserv Code Point, ECN bits, or Flow Label may have a profound effect on packet handling during transit, but does not affect a packet's status as standard-formed. Likewise, the addition, modification, or deletion of extension headers may change the handling of packets in transit hosts. ✨

[RFC2330] defines the "minimal IP packet from A to B" as a particular type of standard-formed packet often useful to consider. When defining IP metrics, no packet smaller or simpler than this can be transmitted over a correctly operating IP network. However, the concept of the minimal IP packet has not been employed (since typical active measurement systems employ a transport layer and a payload), and its practical use is limited. Therefore, this memo deprecates the concept of the "minimal IP packet from A to B". 🥀

6. NAT, IPv4-IPv6 Transition, and Compression Techniques 🦋

This memo adds the key considerations for utilizing IPv6 in two critical conventions of the IPPM framework, namely packets of Type-P and standard-formed packets. The need for coexistence of IPv4 and IPv6 has originated transitioning standards like the framework for IPv4/IPv6 translation in [RFC6144] or the IP/ICMP translation algorithms in [RFC7915] and [RFC7757].

The definition and execution of measurements within the context of the IPPM framework is challenged whenever such translation mechanisms are present along the measurement path. In use cases like IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header compression may result in modification of the measurement packet's Type-P along the path. All these changes MUST be reported. Example consequences include, but are not limited to: 💅

• Modification or addition of headers or header field values in intermediate nodes. IPv4-IPv6 transitioning or IPv6 header compression mechanisms may result in changes of the measurement packets' Type-P, too. Consequently, hosts along the measurement path may treat packets differently because of the Type-P modification. Measurements at observation points along the path may also need extra context to uniquely identify a packet.
• Network Address Translators (NAT) on the path can have an unpredictable impact on latency measurement (in terms of the amount of additional time added) and possibly other types of measurements. It is not usually possible to control this impact as testers may not have any control of the underlying network or middleboxes. There is a possibility that stateful NAT will lead to unstable performance for a flow with specific Type-P, since state needs to be created for the first packet of a flow and state may be lost later if the NAT runs out of resources. However, this scenario does not invalidate the Type-P for testing; for example, the purpose of a test might be exactly to quantify the NAT's impact on delay variation. The presence of NAT may mean that the measured performance of Type-P will change between the source and the destination. This can cause an issue when attempting to correlate measurements conducted on segments of the path that include or exclude the NAT. Thus, it is a factor to be aware of when conducting measurements. 🙈
• Variable delay due to internal state. One side effect of changes due to IPv4-IPv6 transitioning mechanisms is the variable delay that intermediate nodes experience for header modifications. Similar to NAT, the allocation of internal state and establishment of context within intermediate nodes may cause variable delays, depending on the measurement stream pattern and position of a packet within the stream. For example, the first packet in a stream will typically trigger allocation of internal state in an intermediate IPv4-IPv6 transition host. Subsequent packets can benefit from lower processing delay due to the existing internal state. However, large interpacket delays in the measurement stream may result in the intermediate host deleting the associated state and needing to re-establish it on arrival of another stream packet. It is worth noting that this variable delay due to internal state allocation in intermediate nodes can be an explicit use case for measurements. 🧠
• Variable delay due to packet length. IPv4-IPv6 transitioning or header compression mechanisms modify the length of measurement packets. The modification of the packet size may or may not change how the measurement path treats the packets. 🌸

7. Security Considerations 🛡️

okay bestie, security is the part everyone skips but it's SO important 💀 Any active measurement of live paths comes with its own security concerns, and those apply here too. Go read [RFC4656] and [RFC5357] for the details ✨

Privacy is the other big one 🙈 When you use active techniques like the ones in this scope, the sensitive stuff that a potential observer can see is way reduced. Passive watching of user traffic for measurement is a whole different story with lots of privacy issues 😭 For the full privacy picture, check the privacy considerations in the Large Scale Measurement of Broadband Performance (LMAP) framework [RFC7594]. It covers both active and passive techniques, so it's the one to read 💜

8. IANA Considerations 🌸

No IANA actions here, bestie 🫶 Nothing to register or update.

9. References 📚

9.1. Normative References

Here are the normative references, the ones that are essential to reading this doc 🎀

[RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
           DOI 10.17487/RFC0791, September 1981,
           <https://www.rfc-editor.org/info/rfc791>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
           "Framework for IP Performance Metrics", RFC 2330,
           DOI 10.17487/RFC2330, May 1998,
           <https://www.rfc-editor.org/info/rfc2330>.

[RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
           "Definition of the Differentiated Services Field (DS
           Field) in the IPv4 and IPv6 Headers", RFC 2474,
           DOI 10.17487/RFC2474, December 1998,
           <https://www.rfc-editor.org/info/rfc2474>.

[RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
           RFC 2675, DOI 10.17487/RFC2675, August 1999,
           <https://www.rfc-editor.org/info/rfc2675>.

[RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
           Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
           K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
           Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
           Compression (ROHC): Framework and four profiles: RTP, UDP,
           ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
           July 2001, <https://www.rfc-editor.org/info/rfc3095>.

[RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
           of Explicit Congestion Notification (ECN) to IP",
           RFC 3168, DOI 10.17487/RFC3168, September 2001,
           <https://www.rfc-editor.org/info/rfc3168>.

[RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
           M. Zekauskas, "A One-way Active Measurement Protocol
           (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
           <https://www.rfc-editor.org/info/rfc4656>.

[RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
           Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
           <https://www.rfc-editor.org/info/rfc4821>.

[RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
           "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
           DOI 10.17487/RFC4861, September 2007,
           <https://www.rfc-editor.org/info/rfc4861>.

[RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
           "Transmission of IPv6 Packets over IEEE 802.15.4
           Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
           <https://www.rfc-editor.org/info/rfc4944>.

[RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
           J. Babiarz, "A Two-Way Active Measurement Protocol
           (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008,
           <https://www.rfc-editor.org/info/rfc5357>.

[RFC5644]  Stephan, E., Liang, L., and A. Morton, "IP Performance
           Metrics (IPPM): Spatial and Multicast", RFC 5644,
           DOI 10.17487/RFC5644, October 2009,
           <https://www.rfc-editor.org/info/rfc5644>.

[RFC5835]  Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for
           Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April
           2010, <https://www.rfc-editor.org/info/rfc5835>.

[RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
           IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
           April 2011, <https://www.rfc-editor.org/info/rfc6144>.

[RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
           Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
           DOI 10.17487/RFC6282, September 2011,
           <https://www.rfc-editor.org/info/rfc6282>.

[RFC6398]  Le Faucheur, F., Ed., "IP Router Alert Considerations and
           Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
           2011, <https://www.rfc-editor.org/info/rfc6398>.

[RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
           "IPv6 Flow Label Specification", RFC 6437,
           DOI 10.17487/RFC6437, November 2011,
           <https://www.rfc-editor.org/info/rfc6437>.

[RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
           M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
           RFC 6564, DOI 10.17487/RFC6564, April 2012,
           <https://www.rfc-editor.org/info/rfc6564>.

[RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and
           C. Bormann, "Neighbor Discovery Optimization for IPv6 over
           Low-Power Wireless Personal Area Networks (6LoWPANs)",
           RFC 6775, DOI 10.17487/RFC6775, November 2012,
           <https://www.rfc-editor.org/info/rfc6775>.

[RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
           of IPv6 Extension Headers", RFC 7045,
           DOI 10.17487/RFC7045, December 2013,
           <https://www.rfc-editor.org/info/rfc7045>.

[RFC7312]  Fabini, J. and A. Morton, "Advanced Stream and Sampling
           Framework for IP Performance Metrics (IPPM)", RFC 7312,
           DOI 10.17487/RFC7312, August 2014,
           <https://www.rfc-editor.org/info/rfc7312>.

[RFC7757]  Anderson, T. and A. Leiva Popper, "Explicit Address
           Mappings for Stateless IP/ICMP Translation", RFC 7757,
           DOI 10.17487/RFC7757, February 2016,
           <https://www.rfc-editor.org/info/rfc7757>.

[RFC7915]  Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
           "IP/ICMP Translation Algorithm", RFC 7915,
           DOI 10.17487/RFC7915, June 2016,
           <https://www.rfc-editor.org/info/rfc7915>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", STD 86, RFC 8200,
           DOI 10.17487/RFC8200, July 2017,
           <https://www.rfc-editor.org/info/rfc8200>.

[RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
           "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
           DOI 10.17487/RFC8201, July 2017,
           <https://www.rfc-editor.org/info/rfc8201>.

[RFC8250]  Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
           Performance and Diagnostic Metrics (PDM) Destination
           Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
           <https://www.rfc-editor.org/info/rfc8250>.

9.2. Informative References

These ones are just helpful background reading, not required 💅

[IANA-6P]  IANA, "Internet Protocol Version 6 (IPv6) Parameters",
           <https://www.iana.org/assignments/ipv6-parameters>.

[IOAM-DATA]
           Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
           Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
           P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
           "Data Fields for In-situ OAM", Work in Progress,
           draft-ietf-ippm-ioam-data-03, June 2018.

[RFC7594]  Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
           Aitken, P., and A. Akhter, "A Framework for Large-Scale
           Measurement of Broadband Performance (LMAP)", RFC 7594,
           DOI 10.17487/RFC7594, September 2015,
           <https://www.rfc-editor.org/info/rfc7594>.

Acknowledgements 🫶

The authors gave a big shoutout to Brian Carpenter 👑 He spotted that the IPPM framework didn't really cover IPv6, and he listed extra factors that help tell packets of Type-P apart. Brian and Fred Baker also talked through lots of the cool IPv6 stuff with the coauthors, which made the first draft way more solid. Thank you both, you're iconic 💖

Bill Jouris gets a thank-you for the editorial pass over the pre-00 text 🎀 And as the doc was wrapping up, Nevil Brownlee, Mike Heard, Spencer Dawkins, Warren Kumari, and Suresh Krishnan all dropped useful suggestions 🌈 The squad really came through ✨

Authors' Addresses 🦋

Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ  07748
United States of America
Phone: +1 732 420 1571
Fax:   +1 732 368 1192
Email: acm@researh.att.com


Joachim Fabini
TU Wien
Gusshausstrasse 25/E389
Vienna  1040
Austria
Phone: +43 1 58801 38813
Fax:   +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at
URI:   http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/


Nalini Elkins
Inside Products, Inc.
Carmel Valley, CA  93924
United States of America
Email: nalini.elkins@insidethestack.com


Michael S. Ackermann
Blue Cross Blue Shield of Michigan
Email: mackermann@bcbsm.com


Vinayak Hegde
Consultant
Brahma Sun City, Wadgaon-Sheri
Pune, Maharashtra  411014
India
Phone: +91 9449834401
Email: vinayakh@gmail.com
URI:   http://www.vinayakhegde.com