idnits 2.17.1 draft-fairhurst-tsvwg-datagram-plpmtud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2017) is 2487 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6man-rfc1981bis' == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-01 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Fairhurst 3 Internet-Draft T. Jones 4 Intended status: Standards Track University of Aberdeen 5 Expires: January 4, 2018 M. Tuexen 6 I. Ruengeler 7 Muenster University of Applied Sciences 8 July 03, 2017 10 Packetization Layer Path MTU Discovery for Datagram Transports 11 draft-fairhurst-tsvwg-datagram-plpmtud-00.txt 13 Abstract 15 This document describes a robust method for Path MTU Discovery 16 (PMTUD) for datagram packetization layers. It allows these layers to 17 probe an Internet path with progressively larger packets to determine 18 a maximum packet size This method is described as an extension to RFC 19 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP 20 versions 4 and 6. The document provides functionally for datagram 21 transports that is equivalent to the packetization layer PMTUD 22 specification for TCP, specified in RFC4821. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. PMTU Probing Methods . . . . . . . . . . . . . . . . . . 7 62 4. Specification of PMTUD for Packetization Layers . . . . . . . 7 63 5. Specification or Protocol Specific Methods . . . . . . . . . 7 64 5.1. UDP and UDP-Lite . . . . . . . . . . . . . . . . . . . . 8 65 5.1.1. UDP Options . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.2.1. SCTP/IP4 and SCTP/IPv6 . . . . . . . . . . . . . . . 8 68 5.2.1.1. Probing . . . . . . . . . . . . . . . . . . . . . 8 69 5.2.1.2. PTB Message Handling . . . . . . . . . . . . . . 9 70 5.2.2. SCTP/UDP . . . . . . . . . . . . . . . . . . . . . . 9 71 5.2.2.1. Probing . . . . . . . . . . . . . . . . . . . . . 9 72 5.2.2.2. PTB Message Handling . . . . . . . . . . . . . . 9 73 5.2.3. SCTP/DTLS . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2.3.1. Probing . . . . . . . . . . . . . . . . . . . . . 9 75 5.2.3.2. PTB Message Handling . . . . . . . . . . . . . . 9 76 5.3. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.3.1. DCCP/UDP . . . . . . . . . . . . . . . . . . . . . . 10 78 5.4. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The IETF has specified datagram transport using UDP, SCTP, SCTP/UDP, 91 DCCP, and DCCP/UDP as well as upper layer protocols layered on top of 92 these transports. 94 Classical Path MTU Discovery (PMTUD) can be used with any transport 95 that is able to process ICMP Packet Too Big (PTB) messages (e.g., 96 [RFC1191][I-D.ietf-6man-rfc1981bis]). It adjusts the Effective Path 97 MTU (PMTU), based on reception of ICMP PTB messages to decrease the 98 PMTU when this is larger than the value supported along a path, and a 99 method that increases the packet size in attempt to discover an 100 increase in the supported PMTU. However, ICMP messages are being 101 increasingly filtered by middleboxes (including Firewalls) [RFC4890]. 102 Classical PMTUD is therefore subject to protocol failures (e.g., 103 traffic using a packet size larger than the actual supported PMTU is 104 blackholed when ICMP PTB messages are not delivered for some reason 105 [RFC2923]). 107 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not 108 rely upon network or transport support for ICMP messages and is 109 therefore considered more robust than Classical PMTUD. This has 110 become the preferred approach for TCP traffic. The general strategy 111 is for the Packetization Layer to find an appropriate PMTU by sending 112 probe packets along the path with a progressively larger packet size. 113 If a probe packet is successfully delivered (as determined by the 114 PL), then the effective Path MTU is raised to the probe size. 115 PLPMTUD introduces flexibility in the implementation of classical 116 PMTUD. It can be configured to only perform ICMP black hole recovery 117 to increase the robustness of classical PMTUD, or at the other 118 extreme, all ICMP processing can be disabled and PLPMTUD can 119 completely replace classical Path MTU Discovery. Using PLPMTUD, 120 classical Path MTU Discovery can also be modified to include 121 additional consistency checks without increasing the risk of 122 connection hangs due to spurious failures of the additional checks. 124 The UDP-Guidelines [RFC8085] state "an application SHOULD either use 125 the path MTU information provided by the IP layer or implement Path 126 MTU Discovery (PMTUD)", but does not provide a mechanism for 127 discovering the largest size of unfragmented datagram than can be 128 used on a path. This specification describes how these datagram 129 transports perform PLPMTUD. This mechanism has not currently been 130 specified for UDP, while Section 10.2 of [RFC4821] specifies a 131 recommended PLPMTUD probing method for SCTP. 133 Section Section 4 of this document presents a set of algorithms for 134 datagram protocols to discover the maximum transmission unit possible 135 on a path at the packetization layer. The methods described rely on 136 features of transport protocols and apply to transport protocols over 137 IPv4 and IPv6. They do not require cooperation from the lower layers 138 (except that they are consistent about which packet sizes are 139 acceptable) or from peers. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 Other terminology is directly copied from [RFC4821], the EMTU 148 definitions are from [RFC1122]. 150 Address: An IP Layer identifier for an interface or a set of 151 interfaces. 153 Classical Path MTU Discovery: The process described in [RFC1191] and 154 [I-D.ietf-6man-rfc1981bis], in which nodes rely on ICMP PTB 155 messages to learn the MTU of a path. 157 Datagram: A transport-layer protocol data unit, transmitted in the 158 payload of an IP packet. 160 Effective PMTU: The current estimated value for PMTU used by a 161 Packetization Layer. 163 EMTU_S: The Effective MTU for sending (EMTU_S) is designated in 164 [RFC1122] as " the maximum IP datagram size that may be sent, for 165 a particular combination of IP source and destination 166 addresses..." 168 EMTU_R: The Effective MTU for receiving (EMTU_R) is designated in 169 [RFC1122] as "the largest datagram size that can be reassembled by 170 EMTU_R ("Effective MTU to receive")" 172 Interface: A node's attachment to a link. 174 Link: A communication facility or medium over which nodes can 175 communicate at the link layer, i.e., the layer immediately below 176 IP. Examples are Ethernet LANs and Internet (or higher) layer and 177 tunnels. 179 Link MTU: Maximum Transmission Unit, the size in bytes of the 180 largest IP packet, including the IP header and payload, that can 181 be transmitted on a link or path. Note that this could more 182 properly be called the IP MTU, to be consistent with how other 183 standards organizations use the acronym MTU. This includes the IP 184 header, but excludes link layer headers and other framing that is 185 not part of IP or the IP payload. Be aware that other standards 186 organizations generally define link MTU to include the link layer 187 headers. 189 Packet: An IP header plus the IP payload. 191 Packetization Layer: The layer of the network stack that places data 192 into packets and performs transport protocol functions. 194 Path: The set of links traversed by a packet between a source node 195 and a destination node. 197 Path MTU, or PMTU: The minimum link MTU of all the links in a path 198 between a source node and a destination node. 200 PLPMTUD: Packetization Layer Path MTU Discovery, the method 201 described in this document, which is an extension to classical 202 PMTU Discovery. 204 3. Requirements 206 All of the requirements in [RFC4821] apply. There are also a number 207 of design constraints imposed by datagram transports. TCP PLPMTUD 208 has been defined using standard TCP protocol mechanism. Unlike TCP, 209 some datagram transports require additional or optional mechanisms to 210 implement PLPMTUD. This can place constraints on deployment when 211 only one end supports the new method. 213 There are eight functions that any Datagram PLPMTUD mechanisms needs 214 to perform: 216 1. PMTU parameters: A method MUST utilize information about the 217 maximum size of packet that can be transmitted by the sender on 218 the local link (Link MTU) and MAY utilize similar information 219 about the receiver link, when this is supplied (note this may be 220 less than EMTU_R). Some applications also have a maximum 221 transport protocol data unit (PDU) size, in which case there may 222 be no benefit from probing for a size larger than this (unless a 223 transport offers benefit from multiplexing multiple applications 224 PDUs into the same datagram.) 226 2. Effective PMTU: A datagram applications MUST be able to choose 227 the size of datagrams sent to the network, based on the effective 228 MTU. This value is managed by the PMTUD method, and sets the 229 maximum size of datagram that an application can send. The 230 effective PMTU (specified in Section 1 of [RFC1191]) is 231 equivalent to the EMTU_S (specified in [RFC1122]). 233 3. Processing ICMP PTB messages: A method MAY optionally utilize 234 ICMP PTB information from the network layer to help identify when 235 a path does not support a message size (i.e. reduce the effective 236 PMTU). The validity of PTB messages SHOULD to be verified before 237 they are used to update the path MTU discovery information 238 [I-D.ietf-6man-rfc1981bis]. 240 4. Path validation: An endpoint needs to confirm the current path 241 support the current effective datagram size, without relying 242 solely on ICMP PTB messages. In this respect, the mechanism MUST 243 be robust to path changes that could have occurred since the path 244 characteristics were last confirmed. A method MUST also be 245 robust to the possibility that a flow encounters reordering, or 246 has the traffic divided over more than one network path. 248 5. When to probe: An endpoint method SHOULD determine whether the 249 path capacity has increased since it last measured the path 250 characteristics. The endpoint needs a method to determine when a 251 probe datagram is transmitted, and it MUST cache the values 252 between probes. This method needs to consider the disruption 253 that may be incurred by an unsuccessful probe - both upon the 254 flow that incurs a probe loss, and other flows that experience 255 the effect of additional probe traffic. 257 6. Reception feedback: An endpoint MUST provide a feedback method to 258 indicate when a probe message has been received by the remote 259 endpoint. If the data in the probe message needs to be sent 260 reliably, the transport needs to arrange retransmission/repair of 261 any resulting loss. The method also needs to be robust in the 262 case where probe messages are lost due to other reasons than a 263 PMTU exceeded (e.g., link transmission error, congestion). The 264 isolated loss of a probe packet (with or without an ICMP Packet 265 Too Big message) is treated as an indication of an MTU limit, and 266 not as a congestion indicator. In this case alone, the 267 Packetization Protocol is permitted to retransmit any missing 268 data without adjusting the congestion window. 270 7. Shared state: The specification of PLPMTUD [RFC4821] states: "If 271 PLPMTUD updates the MTU for a particular path, all Packetization 272 Layer sessions that share the path representation (as described 273 in Section 5.2 of RFC821) SHOULD be notified to make use of the 274 new MTU and make the required congestion control adjustments". 275 Such methods need to robust to the wide variety of underlying 276 network forwarding behaviours. Considerations about caching have 277 been noted [I-D.ietf-6man-rfc1981bis]. 279 8. Not interfere with congestion control: If the transport protocol 280 implements a congestion control, the loss of a probe packet 281 SHOULD NOT affect the congestion control if the probe packets are 282 not contain user data. 284 3.1. PMTU Probing Methods 286 Many datagram protocols provide mechanisms to distinguish in-band 287 data from padding. In contrast, TCP to generate probes by 288 appropriately segmenting data. There are three ways of creating 289 probes, using application data, using application data and padding 290 and padding only: 292 o A probe datagram can contain only padding (these probes consume 293 capacity, but do not require retransmission of user data) and 294 control data. 296 o A probe datagram can contain user data that is combined with 297 control data and padding to inflate the length of the datagram to 298 the size required for the probe. A loss of this probe could 299 require retransmission/repair of the data if required by the 300 application/transport. 302 o A probe datagram can contain data supplied by an application that 303 matches the size required for the probe. This requires a method 304 to request the application to issue a packet of the desired probe 305 size. A loss of this probe could require retransmission/repair of 306 the data if required by the application/transport. 308 Three approaches are possible for providing datagram reliability: 310 1. A transport/application does not require a probe datagram to be 311 retransmitted in the event of the loss of a probe. 313 2. A transport/application requires retransmission of the data part 314 of a probe in the event of a loss. 316 3. A transport/application is allowed to replicate the data sent in 317 a probe in a packet (or packets) less than the size current 318 effective PMTU to reduce the need for retransmission. 320 4. Specification of PMTUD for Packetization Layers 322 << Fill in a generic algorithm based on sending probe packets, 323 receiving success indications and possibly handling PTB messages. 324 These three operations are protocol specific and are described in 325 Section 5 for various protocols. >> 327 5. Specification or Protocol Specific Methods 329 << In future revisions of this document, this section may be divided 330 into PMTUD and PLPMTUD methods >> 332 5.1. UDP and UDP-Lite 334 UDP and UDP-LIte [RFC3828] do not provide a method that allows 335 padding to be added to a datagram. 337 << This section will be completed in a future revision of this ID >> 339 5.1.1. UDP Options 341 UDP places additional design requirements on an application that 342 wishes to use PLPMTUD. UDP Options permits padding to be added to 343 UDP datagrams [I-D.ietf-tsvwg-udp-options], and can be used to 344 provide reception feedback. Therefore, UDP-Options can be used to 345 assist UDP applications by supplying the additional functionality and 346 using this to provide a Datagram PMTUD service similar to that 347 offered by other transports. 349 << This section will be completed in a future revision of this ID >> 351 5.2. SCTP 353 Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing 354 method for SCTP. It recommends use of the PAD chunk, defined in 355 [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build 356 a probe packet. This allows to perform probing without affecting the 357 transfer of user messages and without interfering with congestion 358 control. Therefore it is preferred to the use of DATA chunks (with 359 padding as required) to serve as path probes. 361 << We might define a parameter contained in the INIT and INIT ACK 362 chunk to indicated the MTU to the peer. However, multihoming makes 363 this a bit complex, so it might not be worth doing. >> 365 5.2.1. SCTP/IP4 and SCTP/IPv6 367 The base protocol is specified in [RFC4960]. 369 5.2.1.1. Probing 371 Probe packets consist of an SCTP common header followed by a 372 HEARTBEAT chunk and a PAD chunk. The PAD chunk is used to control 373 the length of the probe packet. The HEARTBEAT chunk is used to 374 trigger the sending of a HEARTBEAT ACK chunk. The reception of the 375 HEARTBEAT ACK chunk signals the successful probing. 377 5.2.1.2. PTB Message Handling 379 Normal ICMP verification MUST be performed as specified in Appendix C 380 of [RFC4960]. This requires that the first 8 bytes of the SCTP 381 common header are contained in the ICMP packet, which is normally 382 fulfilled by ICMPv4 and ICMPv6. 384 5.2.2. SCTP/UDP 386 The UDP encapsulation of SCTP is specified in [RFC6951]. 388 5.2.2.1. Probing 390 The probing can be performed as specified in Section 5.2.1.1. 392 5.2.2.2. PTB Message Handling 394 Normal ICMP verification has to be performed as specified in 395 [RFC4960]. However, this might not be possible for ICMPv4, since it 396 is not guaranteed that the ICMP packet contains the first 8 bytes of 397 the SCTP common header. ICMPv6 packets should contain enough 398 information to perform the required verification. 400 5.2.3. SCTP/DTLS 402 The DTLS encapsulation of SCTP is specified in 403 [I-D.ietf-tsvwg-sctp-dtls-encaps]. It is used for data channels in 404 WebRTC implementations. 406 5.2.3.1. Probing 408 The probing can be done as specified in Section 5.2.1.1. 410 5.2.3.2. PTB Message Handling 412 Normal ICMP verification can not be performed as specified in 413 [RFC4960], since even if the ICMP contains enough information, the 414 reflected SCTP common header would be encrypted. Therefore it is not 415 possible to process ICMP PTB messages. 417 5.3. DCCP 419 DCCP [RFC4340] implementations are required to support classical 420 PMTUD and states that a DCCP sender "MUST maintain the maximum packet 421 size (MPS) allowed for each active DCCP session" and also defines 422 "current congestion control mechanism (CCMPS), the maximum packet 423 size supported by the path's links". It recommends use of PMTUD, and 424 suggests use of DCCP-Sync packets as path probes, because they do not 425 risk application data loss. It does not currently specify the use of 426 PLPMTUD methods that could work independently of the ability to 427 utilise ICMP PTB messages. 429 << This section will be completed in a future revision of this ID >> 431 5.3.1. DCCP/UDP 433 DCCP/UDP is a UDP-based transport that permits padding to be added to 434 datagrams, and can provide reception feedback. 436 << This section will be completed in a future revision of this ID >> 438 5.4. QUIC 440 QUIC is a UDP-based transport that provides reception feedback 441 [draft-ietf-quic-transport]. 443 << This section will be completed in a future revision of this ID >> 445 6. Acknowledgements 447 This work was partially funded by the European Union's Horizon 2020 448 research and innovation programme under grant agreement No. 644334 449 (NEAT). The views expressed are solely those of the author(s). 451 7. IANA Considerations 453 This memo includes no request to IANA. 455 If there are no requirements for IANA, the section will be removed 456 during conversion into an RFC by the RFC Editor. 458 8. Security Considerations 460 The security considerations for the use of UDP and SCTP are provided 461 in the references RFCs. Security guidance for applications using UDP 462 is provided in the UDP-Guidelines [RFC8085]. 464 ICMP PTB messages could potentially be used to cause a node to 465 inappropriately reduce the PMTU. A node supporting PLPMTUD SHOULD 466 appropriately validate the payload of ICMP PTB messages to ensure 467 these are received in response to transmitted traffic (i.e., a 468 reported error condition that corresponds to a datagram actually sent 469 by the path layer. 471 9. References 473 9.1. Normative References 475 [I-D.ietf-6man-rfc1981bis] 476 <>, J., <>, S., <>, J., and R. Hinden, "Path MTU Discovery 477 for IP version 6", draft-ietf-6man-rfc1981bis-08 (work in 478 progress), May 2017. 480 [I-D.ietf-tsvwg-sctp-dtls-encaps] 481 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 482 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 483 dtls-encaps-09 (work in progress), January 2015. 485 [I-D.ietf-tsvwg-udp-options] 486 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 487 udp-options-01 (work in progress), June 2017. 489 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 490 Communication Layers", STD 3, RFC 1122, 491 DOI 10.17487/RFC1122, October 1989, 492 . 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, 496 DOI 10.17487/RFC2119, March 1997, 497 . 499 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 500 and G. Fairhurst, Ed., "The Lightweight User Datagram 501 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 502 2004, . 504 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 505 Parameter for the Stream Control Transmission Protocol 506 (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, 507 . 509 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 510 RFC 4960, DOI 10.17487/RFC4960, September 2007, 511 . 513 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 514 Control Transmission Protocol (SCTP) Packets for End-Host 515 to End-Host Communication", RFC 6951, 516 DOI 10.17487/RFC6951, May 2013, 517 . 519 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 520 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 521 March 2017, . 523 9.2. Informative References 525 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 526 DOI 10.17487/RFC1191, November 1990, 527 . 529 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 530 RFC 2923, DOI 10.17487/RFC2923, September 2000, 531 . 533 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 534 Congestion Control Protocol (DCCP)", RFC 4340, 535 DOI 10.17487/RFC4340, March 2006, 536 . 538 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 539 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 540 . 542 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 543 ICMPv6 Messages in Firewalls", RFC 4890, 544 DOI 10.17487/RFC4890, May 2007, 545 . 547 Appendix A. Revision Notes 549 Note to RFC-Editor: please remove this entire section prior to 550 publication. 552 Individual draft -00: 554 o This is the first version. Comments and corrections are welcome 555 directly to the authors or via the IETF TSVWG working group 556 mailing list. 558 Authors' Addresses 559 Godred Fairhurst 560 University of Aberdeen 561 School of Engineering 562 Fraser Noble Building 563 Fraser Noble Building Aberdeen AB24 3UE 564 UK 566 Email: gorry@erg.abdn.ac.uk 568 Tom Jones 569 University of Aberdeen 570 School of Engineering 571 Fraser Noble Building 572 Aberdeen AB24 3UE 573 UK 575 Email: tom@erg.abdn.ac.uk 577 Michael Tuexen 578 Muenster University of Applied Sciences 579 Stegerwaldstrasse 39 580 Steinfurt 48565 581 DE 583 Email: tuexen@fh-muenster.de 585 Irene Ruengeler 586 Muenster University of Applied Sciences 587 Stegerwaldstrasse 39 588 Steinfurt 48565 589 DE 591 Email: i.ruengeler@fh-muenster.de