< draft-amend-tsvwg-dccp-udp-header-conversion-00.txt   draft-amend-tsvwg-dccp-udp-header-conversion-01.txt >
Transport Area Working Group M. Amend Transport Area Working Group M. Amend
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Experimental A. Brunstrom Intended status: Experimental A. Brunstrom
Expires: September 12, 2019 A. Kassler Expires: January 9, 2020 A. Kassler
Karlstad University Karlstad University
V. Rakocevic V. Rakocevic
City University of London City University of London
March 11, 2019 July 08, 2019
Lossless and overhead free DCCP - UDP header conversion (U-DCCP) Lossless and overhead free DCCP - UDP header conversion (U-DCCP)
draft-amend-tsvwg-dccp-udp-header-conversion-00 draft-amend-tsvwg-dccp-udp-header-conversion-01
Abstract Abstract
The Datagram Congestion Control protocol (DCCP) is a non-widely The Datagram Congestion Control Protocol (DCCP) is a transport-layer
deployed transport protocol in the Internet. The reason for that is protocol that provides upper layers with the ability to use non-
a typical chicken-egg problem. Even if there would be a use for reliable congestion-controlled flows. DCCP is not widely deployed in
application developer to rely on DCCP, middle-boxes like firewalls the Internet, and the reason for that can be defined as a typical
and NATs will prevent DCCP end-to-end since they lack support for example of a chicken-egg problem. Even if an application developer
DCCP. However, as long as the protocol penetration of DCCP will not decided to use DCCP, the middle-boxes like firewalls and NATs would
increase, middle-boxes will not handle DCCP properly. To overcome prevent DCCP end-to-end since they lack support for DCCP. Moreover,
this challenge NAT/NATP traversal and UDP encapsulation for DCCP is as long as the protocol penetration of DCCP does not increase, the
already defined. However the first requires special middle-box middle-boxes will not handle DCCP properly. To overcome this
support and the latter introduces overhead. The proposal of a challenge, NAT/NATP traversal and UDP encapsulation for DCCP is
multipath extension for DCCP further stresses the question of already defined. However, the former requires special middle-box
support and the latter introduces overhead. The recent proposal of a
multipath extension for DCCP further underlines the challenge of
efficient middle-box passing as its main goal is to be applied over efficient middle-box passing as its main goal is to be applied over
the Internet, traversing numerous uncontrolled middle-boxes. This the Internet, traversing numerous uncontrolled middle-boxes. This
document introduces a new approach, disguising DCCP during document introduces a new solution which disguises DCCP during
transmission as UDP without requiring middle-box modification nor transmission as UDP without requiring middle-box modification or
introducing any overhead. introducing any overhead.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 9, 2020.
This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 3, line 4
1. Introduction 1. Introduction
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a
transport-layer protocol that provides upper layers with the ability transport-layer protocol that provides upper layers with the ability
to use non-reliable congestion-controlled flows. The current to use non-reliable congestion-controlled flows. The current
specification for DCCP [RFC4340] specifies a direct native specification for DCCP [RFC4340] specifies a direct native
encapsulation in IPv4 or IPv6 packets. encapsulation in IPv4 or IPv6 packets.
DCCP support has been specified for devices that use Network Address DCCP support has been specified for devices that use Network Address
Translation (NAT) or Network Address and Port Translation (NAPT) Translation (NAT) or Network Address and Port Translation (NAPT)
[RFC5597]. However, there is a significant installed base of NAT/ [RFC5597]. However, there is a significant installed base of NAT/
NAPT devices that do not support [RFC5597]. An UDP encapsulation for NAPT devices that do not support [RFC5597]. An UDP encapsulation for
DCCP [RFC6773] circumvents such limitations and makes DCCP compatible DCCP [RFC6773] circumvents such limitations and makes DCCP compatible
with any UDP [RFC768] compliant device that support [RFC4787] but do with any UDP [RFC0768] compliant device that supports [RFC4787] but
not support [RFC5597]. For convenience, the standard encapsulation does not support [RFC5597]. For convenience, the standard
for DCCP [RFC4340] (including [RFC5596] and [RFC5597] as required) is encapsulation for DCCP [RFC4340] (including [RFC5596] and [RFC5597]
referred to as DCCP-STD, whereas the UDP encapsulation for DCCP as required) is referred to as DCCP-STD, whereas the UDP
[RFC6773] is referred to as DCCP-UDP. encapsulation for DCCP [RFC6773] is referred to as DCCP-UDP.
It can be stated, that DCCP-STD and DCCP-UDP are techniques, which It can be stated that DCCP-STD and DCCP-UDP are techniques which
increases the success rate of DCCP transmissions significantly. increase the success rate of DCCP transmissions significantly.
However, DCCP-STD fails on devices that blocks DCCP for any reasons. However, DCCP-STD fails on devices that block DCCP for any reasons.
On the other hand, DCCP-UDP uses the well-accepted UDP to let devices On the other hand, DCCP-UDP uses the well-accepted UDP to let devices
assume they handle the UDP protocol, but for the cost of a reduced assume they are handling the UDP protocol, but at the cost of a
goodput/throughput ratio. reduced goodput/throughput ratio.
To compensate the inefficiency of DCCP-STD (device blocking) and To compensate for the inefficiency of DCCP-STD (device blocking) and
DCCP-UDP (overhead), this document proposes a beneficial modification DCCP-UDP (overhead), this document proposes a beneficial modification
scheme relying like DCCP-UDP on UDP, but for no overhead. This goal scheme relying on UDP (like DCCP-UDP), but with no overhead. This
is reached by re-arranging DCCP's extended header in that it looks goal is reached by re-arranging DCCP's extended header to make it
like UDP, without losing critical information and is referred to as look like UDP, without losing critical information. This solution is
U-DCCP. referred to as U-DCCP.
U-DCCP is limited to DCCP's extended header, requiring X is set to 1. U-DCCP is limited to DCCP's extended header, requiring X is set to 1.
Otherwise U-DCCP relies on the NAT/NATP functionalities specified for Otherwise U-DCCP relies on the NAT/NATP functionalities specified for
UDP in [RFC4787], [RFC6888] and [RFC7857]. UDP in [RFC4787], [RFC6888] and [RFC7857].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. U-DCCP 3. U-DCCP
3.1. Overview 3.1. Overview
The basic approach of U-DCCP is to modify the extended header of a The basic approach of U-DCCP is to modify the extended header of a
DCCP packet such that it appears like UDP [RFC768]. In particular, DCCP packet so that it appears like UDP [RFC0768]. In particular,
this takes place without losing information, but requires a U-DCCP this takes place without losing any header information, but requires
termination before the packet is delivered to the DCCP end system a U-DCCP termination before the packet is delivered to the DCCP end
(!!! Auto-detection via e.g. SDP required??? !!!). The method does system . This method does not change the 4-tuple of IP and port
not change the 4-tuple of IP and port addressing, however it changes addressing, however it changes the protocol carried over IP from DCCP
the protocol carried over IP to UDP. In consequence, the length of to UDP. As a consequence, the length of the packet remains unchanged
the packet remains unchanged and behaves like DCCP-STD. The solution and behaves like DCCP-STD. The solution is not a tunneling approach.
is not a tunneling approach. It requires that the same port as for It requires that the same port used by DCCP can be used by UDP.
DCCP can be used by UDP.
The method is designed to support use when these addresses are The method is designed to support use when the IP addresses are
modified by a device that implements NAT/NAPT. A NAT translates the modified by a device that implements NAT/NAPT. A NAT translates the
IP addresses, which impacts the transport-layer checksum. A NAPT IP addresses, which impacts the transport-layer checksum. A NAPT
device may also translate the port values (usually the source port). device may also translate the port values (usually the source port).
In both cases, the outer transport header that includes these values In both cases, the outer transport header that includes these values
would need to be updated by the NAT/NAPT. would need to be updated by the NAT/NAPT.
U-DCCP supports IPv4 and IPv6. U-DCCP supports IPv4 and IPv6.
The basic format of a U-DCCP packet is: The basic format of a U-DCCP packet is:
skipping to change at page 4, line 36 skipping to change at page 4, line 39
Figure 1: Format of U-DCCP packet Figure 1: Format of U-DCCP packet
The U-DCCP header is described in Section 3.4 after introducing the The U-DCCP header is described in Section 3.4 after introducing the
traditional DCCP header in Section 3.1 and its target appearance of a traditional DCCP header in Section 3.1 and its target appearance of a
UDP header in Section 3.2. Section 3.3 discusses considerations for UDP header in Section 3.2. Section 3.3 discusses considerations for
building the U-DCCP header upfront. building the U-DCCP header upfront.
3.2. The DCCP Generic header 3.2. The DCCP Generic header
The DCCP Generic Header [RFC4340] takes two forms, one with long The DCCP Generic Header [RFC4340] takes two forms: one with long
sequence numbers (48 bits) and the other with short sequence numbers sequence numbers (48 bits) and the other with short sequence numbers
(24 bits), which is not part of U-DCCP's modification. (24 bits). The short one is not part of U-DCCP's modification.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port | | Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum | | Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X| | . | | |X| | .
| Res | Type |=| Reserved | Sequence Number (high bits) . | Res | Type |=| Reserved | Sequence Number (high bits) .
skipping to change at page 6, line 5 skipping to change at page 5, line 51
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port | | Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The UDP Header [RFC768] Figure 4: The UDP Header [RFC768]
All header fields have the meaning specified in [RFC768]. All header fields have the meaning specified in [RFC0768].
3.4. U-DCCP conversion considerations 3.4. U-DCCP conversion considerations
The U-DCCP header has the goal to merge the information of DCCP's The U-DCCP header has the goal to merge the information of DCCP's
extended header (Section 3.1) and imitates in the beginning the UDP extended header (Section 3.1) and imitates in the first 64 bits the
header (Section 3.2). Information, to restore a DCCP header from any UDP header (Section 3.2). Information required to restore a DCCP
conversion, which must not be lost are source and destination port, header from any conversion, which must not be lost, includes: source
Data Offset, CCVal, CsCov, Checksum, Type, X and the Sequence Number. and destination port, Data Offset, CCVal, CsCov, Checksum, Type, X
and the Sequence Number.
Compared with the UDP header, the DCCP ext. header shows similarities Compared with the UDP header, the DCCP extented header shows
in source and destination port and checksum. The length field of UDP similarities in source and destination port and checksum. The length
(bits 33-48) is not part of the DCCP header and contains in case of field of UDP (bits 33-48) is not part of the DCCP header and contains
DCCP the fields Data Offset, CCVal and CsCov. in case of DCCP the fields Data Offset, CCVal and CsCov.
For the goal of imitating UDP, the checksum must cover the whole For the goal of imitating UDP, the checksum must cover the whole
datagram, which renders any limitation by CsCov useless. The datagram, which renders any limitation by CsCov useless. The
checksum itself is required to re-calculate after conversion anyway. checksum itself is required to re-calculate after conversion anyway.
If the conversion is limited to DCCP'S extended header only, X is If the conversion is limited to DCCP'S extended header only, X is
always "1". always "1".
Thus, Data Offset, CCVal, Type and Sequence Number must be re- Thus, Data Offset, CCVal, Type and Sequence Number must be re-
arranged in a way that the Length field of UDP can be applied. arranged in a way that the Length field of UDP can be applied.
skipping to change at page 6, line 49 skipping to change at page 6, line 48
D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | Length | Checksum | P | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | CCVal | Data Offset | Sequence Number (high bits) . | Type | CCVal | Data Offset | Sequence Number (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) | . Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The U-DCCDP Header Figure 5: The U-DCCDP Header
The first 8 bytes of the U-DCCP header corresponds to [RFC768] and The first 8 bytes of the U-DCCP header corresponds to [RFC0768] and
the fields are interpreted as follows: the fields are interpreted as follows:
Source and Dest(ination) Ports: 16 bits each Source and Dest(ination) Ports: 16 bits each
These fields identify the UDP ports used by the source and
These fields identify the UDP ports on which the source and destination (respectively) of the packet to listen for incoming UDP
destination (respectively) of the packet are listening for incoming packets. The UDP port values identify the DCCP source and
UDP packets. The UDP port values do identify the DCCP source and
destination ports. destination ports.
Length: 16 bits Length: 16 bits
This field is the length of the UDP datagram, including the UDP This field is the length of the UDP datagram, including the UDP
header and the payload (for U-DCCP, the payload comprises the payload header and the payload (for U-DCCP, the payload comprises the payload
of the original DCCP datagram and part of its header). of the original DCCP datagram and part of its header).
Checksum: 16 bits Checksum: 16 bits
This field is the Internet checksum of a network-layer pseudoheader This field is the Internet checksum of a network-layer pseudoheader
and Length bytes of the UDP packet [RFC768]. The UDP checksum MUST and Length bytes of the UDP packet [RFC0768]. The UDP checksum MUST
NOT be zero for a U-DCCP packet. NOT be zero for a U-DCCP packet.
The remaining 8 bytes of the U-DCCP header contains: The remaining 8 bytes of the U-DCCP header contains:
Type, CCVal, Data Offset, Seq. Number: As specified in [RFC4340] Type, CCVal, Data Offset, Seq. Number: As specified in [RFC4340]
In case U-DCCP is applied, the IP network layer must be instructed to In case U-DCCP is applied, the IP layer must be instructed to carry
carry an UDP datagram and its checksum must be re-calculated, for an UDP datagram and its checksum must be re-calculated. For detailed
detailed information see section 4. information see Section 3.7.
3.6. Implementation 3.6. Implementation
The process of applying U-DCCP behaves as follows and requires: The process of applying U-DCCP is defined as follows:
DCCP generation -> U-DCCP conversion -> UDP transmission -> U-DCCP DCCP generation -> U-DCCP conversion -> UDP transmission -> U-DCCP
reception and restoration -> DCCP reception reception and restoration -> DCCP reception
The conversion can be integrated into DCCP endpoints directly or as The conversion can be integrated into DCCP endpoints directly or as
an additional component on the way along the transmission route. an additional component on the way along the transmission route.
Depending on the degree of integration, especially the process of Depending on the degree of integration, especially the process of
checksum calculation and validation can be optimized. Section 4.1 checksum calculation and validation can be optimized. Section 3.7
and 4.2 provides a possible pseudo-code for the conversion without and Section 3.8 provide a possible pseudo-code for the conversion
any optimized integration into the sender's network stack nor in the without any optimized integration into the sender's network stack or
receiver's network stack. The pseudo-code assumes explicit knowledge into the receiver's network stack. The pseudo-code assumes explicit
about which U-DCCP flows need conversion between sender and receiver. knowledge on which U-DCCP flows need conversion between the sender
and the receiver.
3.7. Pseudo-code DCCP to U-DCCP conversion 3.7. Pseudo-code DCCP to U-DCCP conversion
A possible processing of an already generated DCCP datagram for A possible processing of an already generated DCCP datagram for
U-DCCP conversion: U-DCCP conversion:
1. Receive DCCP datagram. 1. Receive DCCP datagram.
2. Check eligibility for conversion otherwise bypass conversion. 2. Check eligibility for conversion; otherwise bypass conversion.
3. Verify consistency, e.g. checksum otherwise drop. 3. Verify consistency, e.g. checksum; otherwise drop.
4. Shift Type and CCVal field to the ninth octet. 4. Shift Type and CCVal field to the ninth octet.
5. Shift Data Offset field to the tenth octet. 5. Shift Data Offset field to the tenth octet.
6. Place a length information at octet 5+6 corresponding to 6. Place a length information at octet 5+6 corresponding to
[RFC768]. [RFC0768].
7. Modify the IP header's encapsulated protocol from DCCP to UDP. 7. Modify the IP header's encapsulated protocol from DCCP to UDP.
8. Re-calculate IP header checksum. 8. Re-calculate IP header checksum.
9. Reset DCCP checksum field: octet 7+8 = 0. 9. Reset DCCP checksum field: octet 7+8 = 0.
10. Generate new checksum at octet 7+8 as described in [RFC768]. 10. Generate new checksum at octet 7+8 as described in [RFC0768].
11. Forward to destination based on the unmodified 4-tuple of IP- 11. Forward to destination based on the unmodified 4-tuple of IP-
addresses and ports. addresses and ports.
3.8. Pseudo-code U-DCCP to DCCP restoration 3.8. Pseudo-code U-DCCP to DCCP restoration
A possible processing of an already converted U-DCCP datagram for A possible processing of an already converted U-DCCP datagram for
DCCP restoration: DCCP restoration:
1. Receive UDP datagram. 1. Receive UDP datagram.
2. Check eligibility for restoration otherwise bypass restoration 2. Check eligibility for restoration; otherwise bypass restoration
3. Validate UDP checksum otherwise drop. 3. Validate UDP checksum; otherwise drop.
4. Restore Data Offset field according to [RFC4340]. 4. Restore Data Offset field according to [RFC4340].
5. Restore CCVal field according to [RFC4340]. 5. Restore CCVal field according to [RFC4340].
6. Set CsCov field according to [RFC4340] to "0". 6. Set CsCov field according to [RFC4340] to "0".
7. Restore Type field according to [RFC4340]. 7. Restore Type field according to [RFC4340].
8. Set Reserved bits according to [RFC4340] to "0". 8. Set Reserved bits according to [RFC4340] to "0".
9. Set X according to [RFC4340] to "1". 9. Set X according to [RFC4340] to "1".
10. Modify the IP header's encapsulated protocol from UDP to DCCP. 10. Modify the IP header's encapsulated protocol from UDP to DCCP.
11. Re-calculate IP header checksum. 11. Re-calculate IP header checksum.
12. Reset DCCP checksum field: octet 7+8 = 0. 12. Reset DCCP checksum field: octet 7+8 = 0.
13. Generate new checksum at octet 7+8 as described in [RFC768]. 13. Generate new checksum at octet 7+8 as described in [RFC0768].
14. Forward to destination based on the unmodified 4-tuple of IP- 14. Forward to destination based on the unmodified 4-tuple of IP-
addresses and ports. addresses and ports.
3.9. U-DCCP negotiation (required????) 3.9. U-DCCP negotiation (required????)
Tbd later if required. Otherwise assumes explicit knowledge about Tbd later if required. Otherwise assumes explicit knowledge about
the U-DCCP conversion between sender and receiver. the U-DCCP conversion between sender and receiver.
4. Security Considerations 4. Security Considerations
skipping to change at page 10, line 36 skipping to change at page 10, line 36
[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>.
Authors' Addresses Authors' Addresses
Markus Amend Markus Amend
Deutsche Telekom Deutsche Telekom
T-Online-Allee 1 Deutsche-Telekom-Allee 7
Darmstadt 64295 Darmstadt
Germany Germany
Email: Markus.Amend@telekom.de Email: Markus.Amend@telekom.de
Anna Brunstrom Anna Brunstrom
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
651 88 Karlstad 651 88 Karlstad
Sweden Sweden
 End of changes. 33 change blocks. 
78 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/