| < draft-boucadair-tcpm-rst-diagnostic-payload-03.txt | draft-boucadair-tcpm-rst-diagnostic-payload-04.txt > | |||
|---|---|---|---|---|
| tcpm M. Boucadair | tcpm M. Boucadair | |||
| Internet-Draft Orange | Internet-Draft Orange | |||
| Intended status: Standards Track 12 April 2022 | Intended status: Standards Track T. Reddy | |||
| Expires: 14 October 2022 | Expires: 21 October 2022 Akamai | |||
| 19 April 2022 | ||||
| TCP RST Diagnostic Payload | TCP RST Diagnostic Payload | |||
| draft-boucadair-tcpm-rst-diagnostic-payload-03 | draft-boucadair-tcpm-rst-diagnostic-payload-04 | |||
| Abstract | Abstract | |||
| This document specifies a diagnostic payload format to be returned in | This document specifies a diagnostic payload format to be returned in | |||
| TCP RST segments. Such payloads are used to share with the endpoints | TCP RST segments. Such payloads are used to share with the endpoints | |||
| the reasons for which a TCP connection has been reset. This is meant | the reasons for which a TCP connection has been reset. This is meant | |||
| to ease diagnostic and troubleshooting. | to ease diagnostic and troubleshooting. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 34 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 14 October 2022. | This Internet-Draft will expire on 21 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 13 ¶ | skipping to change at page 2, line 13 ¶ | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. RST Diagnostic Payload . . . . . . . . . . . . . . . . . . . 3 | 3. RST Diagnostic Payload . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Some Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Some Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5.1. RST Diagnostic Payload CBOR Key Values . . . . . . . . . 6 | 5.1. RST Diagnostic Payload CBOR Key Values . . . . . . . . . 6 | |||
| 5.2. New Registry for TCP Failure Causes . . . . . . . . . . . 6 | 5.2. New Registry for TCP Failure Causes . . . . . . . . . . . 7 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 1. Introduction | 1. Introduction | |||
| A TCP connection [I-D.ietf-tcpm-rfc793bis] can be reset by a peer for | A TCP connection [I-D.ietf-tcpm-rfc793bis] can be reset by a peer for | |||
| various reasons, e.g., received data does not correspond to an active | various reasons, e.g., received data does not correspond to an active | |||
| connection. Also, a TCP connection can be reset by an on-path | connection. Also, a TCP connection can be reset by an on-path | |||
| service function (e.g., CGN [RFC6888], NAT64 [RFC6146], firewall) for | service function (e.g., CGN [RFC6888], NAT64 [RFC6146], firewall) for | |||
| several reasons. Typically, a NAT function can generate an RST | several reasons. Typically, a NAT function can generate an RST | |||
| segment to notify the peers upon the expiry of the lifetime of the | segment to notify the peers upon the expiry of the lifetime of the | |||
| corresponding mapping entry or because an RST segment was received | corresponding mapping entry or because an RST segment was received | |||
| skipping to change at page 3, line 30 ¶ | skipping to change at page 3, line 30 ¶ | |||
| This document makes use of the terms defined in Section 4 of | This document makes use of the terms defined in Section 4 of | |||
| [I-D.ietf-tcpm-rfc793bis]. | [I-D.ietf-tcpm-rfc793bis]. | |||
| 3. RST Diagnostic Payload | 3. RST Diagnostic Payload | |||
| The RST diagnostic payload MUST be encoded using Concise Binary | The RST diagnostic payload MUST be encoded using Concise Binary | |||
| Object Representation (CBOR) Sequence [RFC8742]. The Concise Data | Object Representation (CBOR) Sequence [RFC8742]. The Concise Data | |||
| Definition Language (CDDL) [RFC8610] for the diagnostic payload is as | Definition Language (CDDL) [RFC8610] for the diagnostic payload is as | |||
| follows: | follows: | |||
| ; This defines an array, the elements of which are to be used | ; This defines an array, the elements of which are to be used | |||
| ; in a CBOR Sequence: | ; in a CBOR Sequence. There is exactly one occurrence. | |||
| diagnostic-payload = [magic-word, reason] | diagnostic-payload = [magic-cookie, reason] | |||
| ; Magic word to identify a payload that follows this specification | ; Magic cookie to identify a payload that follows this specification | |||
| magic-word = 12345 | magic-cookie = 12345 | |||
| ; Reset reason details: | ; Reset reason details: | |||
| reason= { | reason= { | |||
| ? reason-code: uint, | ? reason-code: uint, | |||
| ? pen:uint, | ? pen:uint, | |||
| ? reason-description: tstr, | ? reason-description: tstr, | |||
| } | } | |||
| Figure 1: Structure of the RST Diagnostic Payload | Figure 1: Structure of the RST Diagnostic Payload | |||
| The RST diagnostic payload comprises a magic word that is used to | The RST diagnostic payload comprises a magic cookie that is used to | |||
| unambiguously identify an RST payload that follows this | unambiguously identify an RST payload that follows this | |||
| specification. It MUST be set to the RFC number to be assigned to | specification. It MUST be set to the RFC number to be assigned to | |||
| this document. | this document. | |||
| Note to the RFC Editor: Please replace "12345" with the RFC number | Note to the RFC Editor: Please replace "12345" with the RFC number | |||
| assigned to this document. | assigned to this document. | |||
| All parameters in the reason component of an RST diagnostic payload | All parameters in the reason component of an RST diagnostic payload | |||
| are mapped to their CBOR key values as specified in Section 5.1. The | are mapped to their CBOR key values as specified in Section 5.1. The | |||
| description of these parameters is as follows: | description of these parameters is as follows: | |||
| reason-code: This parameter takes a value from an available registry | reason-code: This parameter takes a value from an available registry | |||
| such as the "TCP Failure Causes" registry (Section 5.2). | such as the "TCP Failure Causes" registry (Section 5.2). | |||
| pen: Includes a Private Enterprise Number | pen: Includes a Private Enterprise Number | |||
| [Private-Enterprise-Numbers]. This parameter is included when the | [Private-Enterprise-Numbers]. This parameter MAY be included when | |||
| reason code is not taken from the IANA-maintained registry | the reason code is not taken from the IANA-maintained registry | |||
| (Section 5.2), but from a vendor-specific registry. | (Section 5.2), but from a vendor-specific registry. | |||
| reason-description: It includes a brief description of the reset | reason-description: It includes a brief description of the reset | |||
| reason. This parameter SHOULD NOT be included if a reason code is | reason encoded as UTF-8 [RFC3629]. This parameter SHOULD NOT be | |||
| supplied. This parameter is useful only for reset reasons that | included if a reason code is supplied. This parameter is useful | |||
| are not yet registered or for application-specific reasons. | only for reset reasons that are not yet registered or for | |||
| application-specific reasons. | ||||
| At least one of "reason-code" and "reason-description" parameters | At least one of "reason-code" and "reason-description" parameters | |||
| MUST be included in an RST diagnostic payload. It is RECOMMENDED to | MUST be included in an RST diagnostic payload. The "pen" parameter | |||
| omit "pen" if a reason code from the IANA-maintained registry | MUST be omitted if a reason code from the IANA-maintained registry | |||
| (Section 5.2) fits the reset case. | (Section 5.2) fits the reset case. | |||
| Malformed RST diagnostic payload messages that include the magic | Malformed RST diagnostic payload messages that include the magic | |||
| number MUST be silently ignored by the receiver. | cookie MUST be silently ignored by the receiver. | |||
| A peer that receives a valid diagnostic payload may pass the reset | A peer that receives a valid diagnostic payload may pass the reset | |||
| reason information to the local application in addition to the | reason information to the local application in addition to the | |||
| information (MUST-12) described in Section 3.6 of | information (MUST-12) described in Section 3.6 of | |||
| [I-D.ietf-tcpm-rfc793bis]. That information may also be logged | [I-D.ietf-tcpm-rfc793bis]. That information may also be logged | |||
| locally, unless a local policy specifies otherwise. How the | locally, unless a local policy specifies otherwise. How the | |||
| information is passed to an application and how it is stored locally | information is passed to an application and how it is stored locally | |||
| is implementation specific. | is implementation specific. | |||
| 4. Some Examples | 4. Some Examples | |||
| skipping to change at page 5, line 20 ¶ | skipping to change at page 5, line 25 ¶ | |||
| [ | [ | |||
| 12345, | 12345, | |||
| { | { | |||
| "reason-code": 2 | "reason-code": 2 | |||
| } | } | |||
| ] | ] | |||
| Figure 3: An RST Diagnostic Payload with Reason Code (Diagnostic | Figure 3: An RST Diagnostic Payload with Reason Code (Diagnostic | |||
| Notation) | Notation) | |||
| Figure 4 shows an example of RST diagnostic payload that includes a | Figure 4 shows an example of an RST diagnostic payload that includes | |||
| free description to report a case that is not covered yet by the | a free description to report a case that is not covered yet by the | |||
| IANA-maintained registry (Section 5.2). | IANA-maintained registry (Section 5.2). | |||
| [ | [ | |||
| 12345, | 12345, | |||
| { | { | |||
| "reason-description": "brief human-readable description" | "reason-description": "brief human-readable description" | |||
| } | } | |||
| ] | ] | |||
| Figure 4: An RST Diagnostic Payload with Reason Description | Figure 4: An RST Diagnostic Payload with Reason Description | |||
| (Diagnostic Notation) | (Diagnostic Notation) | |||
| An RST diagnostic payload may also be reset by an on-path service | An RST diagnostic payload may also be sent by an on-path service | |||
| function. For example, the following diagnostic payload is returned | function. For example, the following diagnostic payload is returned | |||
| by a NAT upon expiry of the mapping entry to which the TCP connection | by a NAT upon expiry of the mapping entry to which the TCP connection | |||
| is bound (Figure 5). | is bound (Figure 5). | |||
| [ | [ | |||
| 12345, | 12345, | |||
| { | { | |||
| "reason-code": 8 | "reason-code": 8 | |||
| } | } | |||
| ] | ] | |||
| skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 5 ¶ | |||
| The designated experts may approve registration once they checked | The designated experts may approve registration once they checked | |||
| that the new requested code is not covered by an existing code and if | that the new requested code is not covered by an existing code and if | |||
| the provided reasoning to register the new code is acceptable. A | the provided reasoning to register the new code is acceptable. A | |||
| registration request may supply a pointer to a specification where | registration request may supply a pointer to a specification where | |||
| that code is defined. However, a registration may be accepted even | that code is defined. However, a registration may be accepted even | |||
| if no permanent and readily available public specification is | if no permanent and readily available public specification is | |||
| available. | available. | |||
| The registry is initially populated with the following values: | The registry is initially populated with the following values: | |||
| +=======+===============================+===========================+ | +=======+========================+==============================+ | |||
| | Value | Description | Specification (if | | | Value | Description | Specification (if available) | | |||
| | | | available) | | +=======+========================+==============================+ | |||
| +=======+===============================+===========================+ | | 1 | New data is received | Sections 3.6.1 and 3.10.7.1 | | |||
| | 1 | Data lost. New data is | Sections 3.6.1 and | | | | after CLOSE is called | of [I-D.ietf-tcpm-rfc793bis] | | |||
| | | received after CLOSE is | 3.10.7.1 of | | +-------+------------------------+------------------------------+ | |||
| | | called | [I-D.ietf-tcpm-rfc793bis] | | | 2 | Received ACK while the | Section 3.10.7.2 of | | |||
| +-------+-------------------------------+---------------------------+ | | | connection is still in | [I-D.ietf-tcpm-rfc793bis] | | |||
| | 2 | Still in LISTEN. | Section 3.10.7.2 of | | | | the LISTEN state | | | |||
| | | Received ACK while the | [I-D.ietf-tcpm-rfc793bis] | | +-------+------------------------+------------------------------+ | |||
| | | connection still in the | | | | 3 | Illegal Option | Section 3.1 of | | |||
| | | LISTEN state | | | | | | [I-D.ietf-tcpm-rfc793bis] | | |||
| +-------+-------------------------------+---------------------------+ | +-------+------------------------+------------------------------+ | |||
| | 3 | Malformed Message | [ThisDocument] | | | 4 | Malformed Message | [ThisDocument] | | |||
| +-------+-------------------------------+---------------------------+ | +-------+------------------------+------------------------------+ | |||
| | 4 | Not Authorized | [ThisDocument] | | | 5 | Not Authorized | [ThisDocument] | | |||
| +-------+-------------------------------+---------------------------+ | +-------+------------------------+------------------------------+ | |||
| | 5 | Resource Exceeded | [ThisDocument] | | | 6 | Resource Exceeded | [ThisDocument] | | |||
| +-------+-------------------------------+---------------------------+ | +-------+------------------------+------------------------------+ | |||
| | 6 | Network Failure. This | [ThisDocument] | | | 7 | Network Failure | [ThisDocument] | | |||
| | | code can be used by | | | +-------+------------------------+------------------------------+ | |||
| | | service functions such | | | | 8 | Reset received from | [ThisDocument] | | |||
| | | as translators. | | | | | the peer | | | |||
| +-------+-------------------------------+---------------------------+ | +-------+------------------------+------------------------------+ | |||
| | 7 | Connection Reset | [ThisDocument] | | | 9 | Destination | [ThisDocument] | | |||
| | | received from the peer. | | | | | Unreachable | | | |||
| | | This code can be used | | | +-------+------------------------+------------------------------+ | |||
| | | by service functions | | | | 10 | Connection Timeout. | [ThisDocument] | | |||
| | | such as translators. | | | +-------+------------------------+------------------------------+ | |||
| +-------+-------------------------------+---------------------------+ | | 11 | Too much outstanding | Section 3.6 of [RFC8684] | | |||
| | 8 | Destination | [ThisDocument] | | | | data | | | |||
| | | Unreachable. This code | | | +-------+------------------------+------------------------------+ | |||
| | | can be used by service | | | | 12 | Unacceptable | Section 3.6 of [RFC8684] | | |||
| | | functions such as | | | | | performance | | | |||
| | | translators. | | | +-------+------------------------+------------------------------+ | |||
| +-------+-------------------------------+---------------------------+ | | 12 | Middlebox interference | Section 3.6 of [RFC8684] | | |||
| | 9 | Connection Timeout. | [ThisDocument] | | +-------+------------------------+------------------------------+ | |||
| | | This code can be used | | | ||||
| | | by service functions | | | ||||
| | | such as translators. | | | ||||
| +-------+-------------------------------+---------------------------+ | ||||
| Table 1: Initial TCP Failure Causes | Table 1: Initial TCP Failure Causes | |||
| Note that codes 6-10 can be used by service functions such as | ||||
| translators. | ||||
| 6. Security Considerations | 6. Security Considerations | |||
| [I-D.ietf-tcpm-rfc793bis] discusses TCP-related security | [I-D.ietf-tcpm-rfc793bis] discusses TCP-related security | |||
| considerations. RST-specific attacks and their mitigations are | considerations. RST-specific attacks and their mitigations are | |||
| discussed in Section 3.10.7.3 of [I-D.ietf-tcpm-rfc793bis]. | discussed in Section 3.10.7.3 of [I-D.ietf-tcpm-rfc793bis]. | |||
| In addition to these considerations, it is RECOMMENDED to control the | In addition to these considerations, it is RECOMMENDED to control the | |||
| size of acceptable diagnostic payload and keep it as brief as | size of acceptable diagnostic payload and keep it as brief as | |||
| possible. Also, it is RECOMMENDED to avoid leaking privacy-related | possible. The RECOMMENDED acceptable maximum size of the RST | |||
| information as part of the diagnostic payload (e.g., including a | diagnostic payload is 255 octets. | |||
| description such as "user X resets explicitly the connection" is not | ||||
| recommended). | Also, it is RECOMMENDED to avoid leaking privacy-related information | |||
| as part of the diagnostic payload (e.g., including a description such | ||||
| as "user X resets explicitly the connection" is not recommended). | ||||
| The "reason-description" string, when present, should not include any | ||||
| private information that an observer would not otherwise have access | ||||
| to. | ||||
| The presence of vendor-specific reason codes (Section 3) may be used | The presence of vendor-specific reason codes (Section 3) may be used | |||
| to fingerprint hosts. Such a concern does not apply if the reason | to fingerprint hosts. Such a concern does not apply if the reason | |||
| codes are taken from the IANA-maintained registry. Implementers are, | codes are taken from the IANA-maintained registry. Implementers are, | |||
| thus, encouraged to register new codes within IANA instead of | thus, encouraged to register new codes within IANA instead of | |||
| maintaining specific registries. | maintaining specific registries. | |||
| The reason description, when present, is not intended to be displayed | ||||
| to end users, but to be consumed by applications. Such a description | ||||
| may carry a malicious message to mislead the end-user. | ||||
| 7. Acknowledgements | 7. Acknowledgements | |||
| The "diagnostic payload" name is inspired by Section 5.5.2 of | The "diagnostic payload" name is inspired by Section 5.5.2 of | |||
| [RFC7252] that was cited by Carsten Bormann in the tcpm mailing list. | [RFC7252] that was cited by Carsten Bormann in the tcpm mailing list. | |||
| Thanks to Jon Jon Shallow for the comments. | Thanks to Jon Shallow for the comments. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [I-D.ietf-tcpm-rfc793bis] | [I-D.ietf-tcpm-rfc793bis] | |||
| Eddy, W. M., "Transmission Control Protocol (TCP) | Eddy, W. M., "Transmission Control Protocol (TCP) | |||
| Specification", Work in Progress, Internet-Draft, draft- | Specification", Work in Progress, Internet-Draft, draft- | |||
| ietf-tcpm-rfc793bis-28, 7 March 2022, | ietf-tcpm-rfc793bis-28, 7 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-tcpm- | <https://www.ietf.org/archive/id/draft-ietf-tcpm- | |||
| skipping to change at page 10, line 5 ¶ | skipping to change at page 10, line 5 ¶ | |||
| [Private-Enterprise-Numbers] | [Private-Enterprise-Numbers] | |||
| "Private Enterprise Numbers", 4 May 2020, | "Private Enterprise Numbers", 4 May 2020, | |||
| <https://www.iana.org/assignments/enterprise-numbers>. | <https://www.iana.org/assignments/enterprise-numbers>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | ||||
| 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November | ||||
| 2003, <https://www.rfc-editor.org/info/rfc3629>. | ||||
| [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data | [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data | |||
| Definition Language (CDDL): A Notational Convention to | Definition Language (CDDL): A Notational Convention to | |||
| Express Concise Binary Object Representation (CBOR) and | Express Concise Binary Object Representation (CBOR) and | |||
| JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, | JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, | |||
| June 2019, <https://www.rfc-editor.org/info/rfc8610>. | June 2019, <https://www.rfc-editor.org/info/rfc8610>. | |||
| [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. | ||||
| Paasch, "TCP Extensions for Multipath Operation with | ||||
| Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March | ||||
| 2020, <https://www.rfc-editor.org/info/rfc8684>. | ||||
| [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) | [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) | |||
| Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, | Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, | |||
| <https://www.rfc-editor.org/info/rfc8742>. | <https://www.rfc-editor.org/info/rfc8742>. | |||
| [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | |||
| Representation (CBOR)", STD 94, RFC 8949, | Representation (CBOR)", STD 94, RFC 8949, | |||
| DOI 10.17487/RFC8949, December 2020, | DOI 10.17487/RFC8949, December 2020, | |||
| <https://www.rfc-editor.org/info/rfc8949>. | <https://www.rfc-editor.org/info/rfc8949>. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| skipping to change at page 11, line 16 ¶ | skipping to change at page 11, line 21 ¶ | |||
| Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
| DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
| <https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
| [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, | [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, | |||
| S., and K. Naito, "Updates to Network Address Translation | S., and K. Naito, "Updates to Network Address Translation | |||
| (NAT) Behavioral Requirements", BCP 127, RFC 7857, | (NAT) Behavioral Requirements", BCP 127, RFC 7857, | |||
| DOI 10.17487/RFC7857, April 2016, | DOI 10.17487/RFC7857, April 2016, | |||
| <https://www.rfc-editor.org/info/rfc7857>. | <https://www.rfc-editor.org/info/rfc7857>. | |||
| Author's Address | Authors' Addresses | |||
| Mohamed Boucadair | Mohamed Boucadair | |||
| Orange | Orange | |||
| 35000 Rennes | 35000 Rennes | |||
| France | France | |||
| Email: mohamed.boucadair@orange.com | Email: mohamed.boucadair@orange.com | |||
| Tirumaleswar Reddy | ||||
| Akamai | ||||
| Embassy Golf Link Business Park | ||||
| Bangalore 560071 | ||||
| Karnataka | ||||
| India | ||||
| Email: kondtir@gmail.com | ||||
| End of changes. 23 change blocks. | ||||
| 78 lines changed or deleted | 97 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||