idnits 2.17.1 draft-manner-tsvwg-gut-02.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 12, 2010) is 5034 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Source' is mentioned on line 397, but not defined == Missing Reference: 'IP A' is mentioned on line 397, but not defined == Missing Reference: 'Dest' is mentioned on line 397, but not defined == Missing Reference: 'IP B' is mentioned on line 397, but not defined == Missing Reference: 'GUT-hdr' is mentioned on line 422, but not defined == Missing Reference: 'DCCP' is mentioned on line 422, but not defined -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft N. Varis 4 Intended status: Experimental Aalto University 5 Expires: January 13, 2011 B. Briscoe 6 BT 7 July 12, 2010 9 Generic UDP Tunnelling (GUT) 10 draft-manner-tsvwg-gut-02.txt 12 Abstract 14 Deploying new transport protocols on the Internet is a well-known 15 problem, as NATs and firewall drop packets with e.g. new protocol 16 types or unidentified TCP options. Tunnelling over UDP is one way to 17 make IP packets hide the actual payload and enable end-to-end 18 delivery. This document proposes a simple UDP tunnelling 19 encapsulation and end-host operation to enable new (and old) IP 20 payloads, e.g., new transport protocols, to be deployed on the 21 Internet. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 13, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Extension headers . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Sender operation . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. Receiver operation . . . . . . . . . . . . . . . . . . . . 9 63 3.4. Example with one NAT-PT between the initiator and 64 responder . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 66 5. Encapsulation of protocols without port numbers . . . . . . . 12 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in BCP 14, RFC 2119 81 [RFC2119]. 83 In addition, we use the following terms: 85 Native: the IP protocol that will, or has been, encapsulated by GUT, 86 e.g., DCCP, SCTP, etc., even protocols like ICMP or RSVP. We also 87 refer to native IP packet as the IP packet that carries the native IP 88 protocol. 90 Initiator: the node that has sent the first packet belonging to an 91 exchange by the native protocol. 93 Responder: the node that received the first packet of the native 94 protocol. 96 Data packet (D-packet): a GUT packet that carries an encapsulated 97 native protocol. 99 Control packet (C-packet): a GUT packet that carries only extension 100 header(s). 102 Data-Control packet (DC-packet): a GUT packet that carries an 103 encapsulated native protocol and an extension header. 105 2. Introduction 107 New IP paylods, e.g., transport layer technologies, such as SCTP 108 [RFC4960] and DCCP [RFC4340], have well-known problems with 109 deployment on the Internet. Firewalls drop IP packets with unknown 110 (too new) transport protocol types or protocol extensions, e.g., TCP 111 options, and NAT boxes do not know how to translate these protocols. 113 Tunnelling over UDP has often been mentioned as a means to traverse 114 middleboxes. Mostly the solutions are ad-hoc and protocol-specific. 115 In order to make deployment of UDP tunnelling at least somewhat 116 consistent, this document proposes a simple mechanism to realise the 117 goal. The benefit is that with a generic solution we avoid the need 118 to define tunneling specifications for each IP protocol separately. 119 The fundamental goal of GUT is to mitigate the problem of existing 120 NATs and firewalls, while still allowing middleboxes that 121 deliberately want to block to do so. 123 The basic idea of GUT is to encapsulate the native transport protocol 124 and its payload (in general the whole IP payload) within a UDP packet 125 destined to the well-known port GUT_P. Between the outer UDP header 126 and the inner transport header, we have a 4-byte GUT header that 127 carries information about the encapsulated protocol to help 128 decapsulation on the receiving side. GUT also introduces extension 129 headers. 131 GUT does not specify, nor need, a specific tunnel setup protocol. It 132 just encapsulates the native protocol and its payload - to any 133 middlebox on the way this looks like a normal UDP flow to port GUT_P. 135 In other words, this specification, i.e, GUT, only defines 137 1. The encapsulation of the native IP payload, 138 2. The GUT header structure and content, and 139 3. The state machine on the initiator and responder sides. 141 If the native protocol has a handshake or any back-and-forth 142 messaging, these are run automatically within the UDP-tunnel created 143 by GUT: GUT is meant to be fully transparent to the native protocol. 144 Note that GUT can also tunnel protocol types which do not have any 145 port informations, such as RSVP or ICMP. The GUT encapsulation is 146 agnostic to the IP protocol version being used (IPv4 or IPv6). 148 3. Basic operation 150 The basic idea of the protocol is to encapsulate the problematic 151 native IP payload within a UDP header and send the packet to a well- 152 known UDP port GUT_P - any return packets from the responder will be 153 tunneled to the UDP source port used by the initiator. The responder 154 will get the UDP packets, check the encapsulated payload and evaluate 155 if it wants to receive the packet, reconstruct the native IP packet, 156 and forward it for further processing within the network stack; GUT 157 is not meant to bypass explicit firewall rules and configuration. 158 Figure 1 shows the encapsulation. 160 +------------------+ +------------------+ 161 | | ------> | | 162 | | | | 163 | Payload data | ------> | Payload data | 164 | | | | 165 | | ------> | | 166 +------------------+ +------------------+ 167 | | ------> | | 168 | Nat. payload hdr | | Nat. payload hdr | 169 | (DCCP, SCTP,...) | | (DCCP, SCTP,...) | 170 | | ------> | | 171 +------------------+ +------------------+ <--| 172 | | | GUT header | | 173 | IP header | \ | Next header|IHL | N 174 | | \ +------------------+ E 175 +------------------+ \ | | W 176 \ | UDP header | | 177 \ +------------------+ <--| 178 \ | | 179 \-> | IP header | 180 | | 181 +------------------+ 183 Figure 1: GUT encapsulation 185 The GUT header is 32 bits and carries three pieces of information 186 that enable reconstructing the native IP packet and perform checksum 187 calculations. 189 1. The GUT Header Length (12 bits) gives the length in bytes of the 190 headers after the 4-byte GUT header and before the encapsulated 191 payload. Any IP option headers encapsulated from the native IP 192 packet are included. The GUT header itself is not included. Thus, a 193 value of 0 indicates straight encapsulation, no headers between the 194 GUT header and the encapsulated protocol. 196 2. The IPv4 Header Length (IHL, 4 bits) field from the native IPv4 197 packet. 199 3. The IP protocol number (next header, 8 bits) of the native IP 200 packet (v4 and v6). The value 255 is used to indicate a GUT 201 extension header (this value is Reserved in the IP protocol numbers 202 registry). Thus, all extension headers carry the same Next header 203 value but a different internal type. 205 The first 8-bit field is currently unused. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Reserved | GUT Header Length | IHL | Next header | 211 +--------------------------------+--------+--------+----------------+ 213 Figure 2: GUT header 215 3.1. Extension headers 217 In addition to the GUT main header, we define extendion headers, 218 objects. An extension header can be added into a GUT packet carrying 219 an encapsulated native protocol frame, or it can be sent standalone, 220 without an actual native protocol, i.e., below the GUT header we have 221 one or more extension headers but no further payload. Any extension 222 headers MUST be appended straight after the GUT main header and 223 before any encapsulated native protocol. 225 Each extendion header begins with a fixed 32-bit part giving the 226 object Type and object Length and Next header. This is followed by 227 the object Value, which is a whole number of 32-bit words long. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |E|r|r|r| Type | Length | Next header | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 // Value // 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 3: Extension header structure 239 E flag (extensibility): A value of "0" indicates that if the object 240 is not understood, the whole GUT packet must be silently discarded. 241 A value of "1" indicates that the unknown object can simply be 242 ignored and the rest of the packet processed as usual. 244 Type (12 bits): An IANA-assigned identifier for the type of object. 246 Length (12 bits): Length has units of 32-bit words, and measures the 247 length of Value. If there is no Value, Length equals 0. If the 248 Length is not consistent with the contents of the object, the message 249 MUST be discarded. 251 Value (variable): Value is (therefore) a whole number of 32 bit 252 words. If there is any padding required, the length and location are 253 be defined by the object-specific format information; objects which 254 contain variable length (e.g. string) types may need to include 255 additional length subfields to do so. 257 This specification introduces three extension headers. All these 258 extension headers are sent as Control packets, i.e., without an 259 encapsulated native protocol. 261 o TEST: to test if the responder supports GUT. 262 o TEST-REPLY: a reply to a TEST. 264 A TEST object can be sent to check whether the receiving host 265 supports GUT. The Responder SHOULD reply with a TEST-REPLY if it 266 supports GUT. A TEST object MAY carry a Value field giving a nonce 267 that should be send back in the TEST-REPLY. A nonce MUST be copied 268 to the TEST-REPLY if the Responder is going to answer the TEST. The 269 Responder MUST NOT store a flow state when receiving a TEST message. 270 The TEST handshake is a similar function than the ICMP ECHO, i.e., 271 both can be used to test if the other end point is alive (without 272 assurance, though, since replying is voluntary). 274 o KEEPALIVE: to maintain a flow state on a middlebox. 276 A native protocol, e.g., a TCP flow, may be using keepalive messages 277 to maintain middlebox states for a flow. Since GUT makes the native 278 flow appear to be UDP, the timeouts of the native flow may be longer 279 than what the middlebox is configured to use for a UDP flow. A GUT 280 node MAY send KEEPALIVE headers in Control packets to maintain the 281 state in middleboxes on the path. A GUT node that receives KEEPALIVE 282 Control packets MUST discard them. The keepalives are always 283 associated to a certain unique GUT flow. Therefore, the receiver MAY 284 use the keepalives as an indication that the native protocol flow is 285 still active and thus maintain it's own states for the flow. 287 3.2. Sender operation 289 In implementation terms, the GUT process running on a host or router 290 (proxy) receives the native IP packet, the whole packet including the 291 IP header, grabs the bytes immediately after the native IP static 292 header, adds a UDP and GUT header, and sends the packet to the 293 destination indicated in the received IP packet. Header checksums 294 are recalculated and IP options are encapsulated. 296 The sender MAY limit the UDP checksum coverage to just the octets 297 outside the native transport header, i.e., not include the 298 encapsulated payload. This is purely for efficiency - to avoid 299 running the whole payload through the checksum calculation twice - 300 with all the memory shifts that will entail. 302 The source port in the UDP header MAY be chosen freely, although if 303 the native encapsulated protocol had a notion of port numbers, the 304 sender SHOULD choose the same source port (note that the source port 305 may already be used by another process, thus the processing may have 306 to choose another port number). The IP header indicates a UDP 307 transport, the GUT header is the first 4 bytes of the UDP payload. 308 The Total Length field in the IP header gives the length of the whole 309 datagram including the encapsulated transport protocol packet. The 310 GUT IP header length gives the length of any encapsulated IPv4 311 Options; this value is actually copied directly from the native IP 312 packet. 314 The current value of GUT_P is 4887 (rule of thumb 1-800-GUTP) 316 The GUT daemon is not considered as an IP hop, thus, when the sender 317 builds the IP header, it MUST use the TTL from the native IP packet. 318 Similarly any ECN and DSCP bits are copied from the native IP packet 319 to the outgoing IP packet. 321 GUT adds 12 octets of headers (UDP+GUT) which may cause fragmentation 322 to happen. GUT is meant as transparent a functionality as possible. 323 Thus, in principle GUT relies on the network stack to do IP packet 324 fragmentation and reassembly. 326 If the native IP packet had IP options, those are preserved within 327 the GUT encapsulation. Here the processing must store the original 328 IHL-field from the native IPv4 packet to be used on the responder 329 side for building the native IP packet properly. 331 It is possible, that the sender gets fragmented IP packets from the 332 network stack to be GUT-encapsulated. In such case, the GUT process 333 MUST reassemble the whole IP packet before adding the UDP and GUT 334 header. The subsequent packet is given back to the network stack for 335 transmission, and may be fragmented at that point to fit the MTU of 336 the link. The initiator may decide to use Path MTU Discovery when 337 the first packet of a flow is received for encapsulation, yet, this 338 will add a delay to the transmission of the first packet and may 339 result in the native protocol to react accordingly. 341 The initiator has to store state, the 5-tuple or 3-tuple (or any 342 information that enables tracking a particular flow), for each 343 initiated GUT encapsulation. This state is needed for properly 344 catching potential return packets of the native IP protocol from the 345 responder (e.g. DCCP, SCTP). This state can be made to expire after 346 a certain timeout, or an implementation can decide to monitor open 347 sockets in the operating system, and remove state of encapsulated 348 native protocols that have their socket closed. 350 3.3. Receiver operation 352 On the receiver side (responder and initiator), the GUT service 353 receives UDP packets, verifies the checksums, does further analysis 354 about whether it wants to process the packet further, and either 355 drops the packet or continues processing. 357 GUT must be able to receive packets with two distinct destination 358 port ranges: 360 GUT_P port: this port number is seen when the packet was sent by a 361 flow initiator. 362 Any other UDP port: the flow initiator has chosen a source port 363 number and if the encapsulated IP protocol included two-way 364 messaging (e.g. a handshake, acknowledgement packets, etc.), it 365 will receive return packets to this UDP port. 367 When the host receives packets to port GUT_P, i.e., it is the 368 destination of the flow, the responder, it MUST store the 5-tuple or 369 3-tuple (or any information that enables tracking a particular flow) 370 of the encapsulated IP packet flow. This state information is needed 371 to send back packets belonging to the same flow. An implementation 372 may optimize the overall resource consumption of the state in GUT by 373 omitting state information for flows where the source ports of the 374 native- and UDP transport protocols match. 376 After decapsulation of the 32-bit GUT header and the UDP header, the 377 GUT processing reconstructs the native IP packet by using the 378 received IP header fields but exchanges the encapsulated next header 379 and IHL fields found in the GUT header. Then the rebuilt packet is 380 injected into the network stack for further processing. Any 381 checksums are recalculated. Any IP options will now be visible to 382 the network stack. 384 A responder should never receive fragmented IP packets since the 385 operating system IP stack will take care of rebuilding the fragments 386 into a full IP packet. 388 3.4. Example with one NAT-PT between the initiator and responder 390 The following figure describes how various protocol fields are mapped 391 on a two-way IP packet flow. The example shows a DCCP-transfer going 392 from A to B. The figure presents the content of IP packets as they 393 are sent out from a component on the path. Note that if the 394 encapsulated protocol does not have port numbers, the GUT processing 395 is even simpler. 397 [Source, IP A] [GUT@A] [NAT, ext IP C] [GUT@B] [Dest, IP B] 399 ------------- Source A to destination B ------------------- 400 1. [IP: A->B, DCCP] 401 2. [DCCP: E->F] 403 3. [IP: A->B, UDP] 404 4. [UDP: E->GUT] 405 5. [GUT-hdr, DCCP] 406 6. [DCCP: E->F] 408 7. [IP: C->B, UDP] 409 8. [UDP: P->GUT] 410 [GUT-hdr, DCCP] 411 ... 413 9. [IP: C->B, DCCP] 414 10. [DCCP: E->F] 416 ------------- Destination B to source A ------------------- 417 11. [IP: B->C,DCCP] 418 12. [DCCP: F->E] 420 13. [IP: B->C, UDP] 421 14. [UDP: GUT->P ] 422 15. [GUT-hdr, DCCP] 423 16. [DCCP: F->E] 425 17. [IP: B->A, UDP] 426 18. [UDP: GUT->E] 427 ... 429 19. [IP: B->A, DCCP] 430 20. [DCCP: F->E] 432 Figure 4: GUT encapsulation example 434 A few details from the figure above: 436 o Line 4: the GUT process takes GUT_P as the destination port, and 437 chooses a source port based on the DCCP header. 438 o Line 8: the NAT may choose a new source port P, instead of E, and 439 rewrite the UDP header. 441 o Line 10: before giving the packet to the local IP stack, the GUT 442 process takes note of the source IP and port numbers, and the 443 encapsulated protocol. 444 o Line 11-12: the tunneled protocol has not seen the GUT 445 encapsulation, thus, it will use the native port numbers in the 446 reverse traffic. 447 o - Lines 13-16: the GUT process has earlier stored state about the 448 flow, knows now that the packet is for an existing stream, and can 449 direct the flow to the right destination port "P", instead of 450 sending it to GUT_P, as if the packet belonged to a new stream. 452 4. Deployment Considerations 454 The basic goal of GUT is to look like generic UDP messaging to any 455 middlebox on the path. If the native transport protocol has support 456 for congestion control, GUT encapsulated packets that are lost will 457 trigger the native transport to react. 459 As GUT-encapsulated traffic looks like an ordinary stream of UDP 460 packets, existing NAT traversal protocols and techniques work out of 461 the box. For example, a responder GUT-daemon can, when needed, 462 maintain the GUT_P open at the NAT using any suitable NAT-traversal 463 protocol. The KEEPALIVE extension header in Control packets may also 464 be used to maintain the state on middleboxes. 466 GUT was originally designed to be used for host-to-host 467 communication. Yet, nothing actually prohibits to have a network 468 node that takes the IP packets coming from a host, and tunnels them 469 through GUT. Similarly, a network node on the receiving side of the 470 connection can decapsulate the packets before they actually hit the 471 receiving end-host, so essentially making a GUT-proxy service. 473 There is yet one critical issue to consider, namely when to 474 encapsulate a transport protocol in GUT, and when not. GUT 475 introduces the TEST/TEST-REPLY handshake that can be used to verify 476 if the receiver has support for GUT; the TEST extension header could 477 be sent at the same time as the initial packet of a native protocol. 478 When using a TEST Control packet, the Initiator may get back an ICMP 479 port unreachable ICMP message. This is a clear indication that GUT 480 is not supported by the receiver. 482 A further option is to trigger GUT when replies to a transport 483 protocol Y's connection initiation are not received within a given 484 timeout. Using GUT can also be a configuration parameter, say, e.g., 485 the host always encapsulates DCCP packets into GUT; this operation is 486 fully transparent to the inner transport protocol. 488 This document does not try to define all potential cases and triggers 489 that might result in an initiator to employ GUT for a certain flow. 490 The actual triggers will emerge as GUT is experimented with. 492 5. Encapsulation of protocols without port numbers 494 GUT is originally designed to counter the problems of deploying 495 relatively new transport protocols on existing Internet. Yet, GUT 496 can also be used to encapsulate any other protocol, e.g., RSVP or 497 HIP. 499 Note that some protocols may not involve port numbers, e.g., RSVP. 500 In such cases, GUT is free to choose a random port for the 501 initiator's port number; the responder's port is always GUT_P. 503 6. Security Considerations 505 In general GUT has the same security concerns as the IP protocol it 506 encapsulates. For example, if the encapsulated protocol can be 507 harmed by injecting false packets into the stream, GUT can not 508 prohibit this. 510 The main additional concern GUT introduces is the increased state 511 needed to properly tunnel packets back-and-forth. Yet, here an 512 implementation SHOULD analyze the encapsulated IP protocol and drop 513 the packet, without storing state, if it does not match the 514 expectations. For example, if the host does not have a transport 515 port open at the indicated destination port, GUT SHOULD drop the 516 packet silently. Also, in case the native IP packet flow does not 517 have a notion of port numbers to enable more accurate matching of 518 pakcets, an implementation may consider storing more information 519 about the flow that just the 3-tuple. This has the downside that GUT 520 must be more aware of each individual native IP protocol - currently 521 GUT basically only needs to know if the native protocol has a notion 522 of port numbers or not; thus, a GUT implementation only needs special 523 treatment of native UDP, TCP, SCTP and DCCP packet flows. 525 Packets belonging to a GUT encapsulated flow will go through a 526 firewall processing twice, (1) once when the IP packet arrives, 527 either locally or from the network, and before it is given to GUT, 528 and (2) when GUT sends out the encapsulated IP protocol inside UDP. 530 GUT itself does not employ any security functions for content 531 protection. Yet, one could use any one-way mechanism, or purely rely 532 on the security functions of the inner payload. If security measures 533 are used on GUT, it should be a one-way scheme, which does not rely 534 on back-and-forth signalling; we don't want to force two-way 535 signaling within GUT, this may or may not happen due to the inner 536 protocol being tunneled. 538 The TEST/TEST-REPLY hanshake can be used for DoS attacks. Therefore, 539 the Responder SHOULD employ rate limitation when answering TEST 540 Control packets. 542 7. IANA Considerations 544 This document requests IANA to 546 1. Allocate a new UDP port number GUT_P as referred to in the 547 document. 549 2. Create a GUT extension headers repository and allocate three 550 values for TEST, TEST-REPLY and KEEPALIVE. The values are 8 bits 551 long. 553 8. Summary 555 Essentially this document define a generic mechanism for tunneling 556 any IP payload over a UDP tunnel. The benefits are: 558 1. Existing IP protocols, with or without port information, work 559 without changes. 560 2. Deployment can be done on the end-host or a network proxy. 561 3. No changes are required for existing NAT and firewall devices. 563 9. Acknowledgements 565 This work was partly performed and funded by Trilogy, a research 566 project supported by the European Commission under its Seventh 567 Framework Program (INFSOICT-216372). 569 The authors thank Robert Hancock for various ideas behind the generic 570 UDP tunneling concepts. 572 10. References 574 10.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 10.2. Informative References 581 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 582 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 584 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 585 RFC 4960, September 2007. 587 Authors' Addresses 589 Jukka Manner 590 Aalto University 591 Department of Communications and Networking (Comnet) 592 P.O. Box 13000 593 FIN-00076 Aalto 594 Finland 596 Phone: +358 9 470 22481 597 Email: jukka.manner@tkk.fi 598 URI: http://www.netlab.tkk.fi/~jmanner/ 600 Nuutti Varis 601 Aalto University 602 P.O. Box 13000 603 Espoo FIN-00076 Aalto 604 Finland 606 Email: nvaris@cc.hut.fi 608 Bob Briscoe 609 BT 610 B54/77, Adastral Park 611 Martlesham Heath 612 Ipswich IP5 3RE 613 UK 615 Phone: +44 1473 645196 616 Email: bob.briscoe@bt.com 617 URI: http://bobbriscoe.net/