idnits 2.17.1 draft-ietf-6man-udpchecksums-08.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2460, but the abstract doesn't seem to directly say this. It does mention RFC2460 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2013) is 3630 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) == Outdated reference: draft-ietf-6man-udpzero has been published as RFC 6936 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: draft-ietf-mboned-auto-multicast has been published as RFC 7450 -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Eubanks 3 Internet-Draft AmericaFree.TV LLC 4 Updates: 2460 (if approved) P. Chimento 5 Intended status: Standards Track Johns Hopkins University Applied 6 Expires: August 25, 2013 Physics Laboratory 7 M. Westerlund 8 Ericsson 9 February 21, 2013 11 IPv6 and UDP Checksums for Tunneled Packets 12 draft-ietf-6man-udpchecksums-08 14 Abstract 16 This document provides an update of the Internet Protocol version 6 17 (IPv6) specification (RFC2460) to improve the performance in the use 18 case where a tunnel protocol uses UDP with IPv6 to tunnel packets. 19 The performance improvement is obtained by relaxing the IPv6 UDP 20 checksum requirement for any suitable tunnel protocol where header 21 information is protected on the "inner" packet being carried. This 22 relaxation removes the overhead associated with the computation of 23 UDP checksums on IPv6 packets used to carry tunnel protocols. The 24 specification describes how the IPv6 UDP checksum requirement can be 25 relaxed for the situation where the encapsulated packet itself 26 contains a checksum. The limitations and risks of this approach are 27 described, and restrictions specified on the use of the method. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 25, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5 69 4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7 70 4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 8 72 6. Additional Observations . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 This work constitutes an update of the Internet Protocol Version 6 84 (IPv6) Specification [RFC2460], in the use case where a tunnel 85 protocol uses UDP with IPv6 to tunnel packets. With the rapid growth 86 of the Internet, tunnel protocols have become increasingly important 87 to enable the deployment of new protocols. Tunnel protocols can be 88 deployed rapidly, while the time to upgrade and deploy a critical 89 mass of routers, middleboxes and hosts on the global Internet for a 90 new protocol is now measured in decades. At the same time, the 91 increasing use of firewalls and other security-related middleboxes 92 means that truly new tunnel protocols, with new protocol numbers, are 93 also unlikely to be deployable in a reasonable time frame, which has 94 resulted in an increasing interest in and use of UDP-based tunnel 95 protocols. In such protocols, there is an encapsulated "inner" 96 packet, and the "outer" packet carrying the tunneled inner packet is 97 a UDP packet, which can pass through firewalls and other middleboxes 98 that perform filtering that is a fact of life on the current 99 Internet. 101 Tunnel endpoints may be routers or middleboxes aggregating traffic 102 from a number of tunnel users, therefore the computation of an 103 additional checksum on the outer UDP packet may be seen as an 104 unwarranted burden on nodes that implement a tunnel protocol, 105 especially if the inner packet(s) are already protected by a 106 checksum. In IPv4, there is a checksum over the IP packet header, 107 and the checksum on the outer UDP packet may be set to zero. However 108 in IPv6 there is no checksum in the IP header and RFC 2460 [RFC2460] 109 explicitly states that IPv6 receivers MUST discard UDP packets with a 110 zero checksum. So, while sending a UDP datagram with a zero checksum 111 is permitted in IPv4 packets, it is explicitly forbidden in IPv6 112 packets. To improve support for IPv6 UDP tunnels, this document 113 updates RFC 2460 to allow endpoints to use a zero UDP checksum under 114 constrained situations (primarily IPv6 tunnel transports that carry 115 checksum-protected packets), following the applicability statements 116 and constraints in [I-D.ietf-6man-udpzero]. 118 "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] 119 should be consulted when reading this specification. It discusses 120 both UDP tunnels (Section 3.1.3) and the usage of checksums (Section 121 3.4). 123 While the origin of this specification is the problem raised by the 124 draft titled "Automatic Multicast Tunnels", also known as "AMT" 125 [I-D.ietf-mboned-auto-multicast] we expect it to have wide 126 applicability. Since the first version of this document, the need 127 for an efficient UDP tunneling mechanism has increased. Other IETF 128 Working Groups, notably LISP [RFC6830] and Softwires [RFC5619] have 129 expressed a need to update the UDP checksum processing in RFC 2460. 130 We therefore expect this update to be applicable in the future to 131 other tunnel protocols specified by these and other IETF Working 132 Groups. 134 2. Some Terminology 136 This document discusses only IPv6, since this problem does not exist 137 for IPv4. Therefore all reference to 'IP' should be understood as a 138 reference to IPv6. 140 The document uses the terms "tunneling" and "tunneled" as adjectives 141 when describing packets. When we refer to 'tunneling packets' we 142 refer to the outer packet header that provides the tunneling 143 function. When we refer to 'tunneled packets' we refer to the inner 144 packet, i.e., the packet being carried in the tunnel. 146 2.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 3. Problem Statement 154 When using tunnel protocols based on UDP, there can be both a benefit 155 and a cost to computing and checking the UDP checksum of the outer 156 (encapsulating) UDP transport header. In certain cases, reducing the 157 forwarding cost is important, e.g., for nodes that perform the 158 checksum in software the cost may outweigh the benefit. This 159 document provides an update for usage of the UDP checksum with IPv6. 160 The update is specified for use by a tunnel protocol that transports 161 packets that are themselves protected by a checksum. 163 4. Discussion 165 "Applicability Statement for the use of IPv6 UDP Datagrams with Zero 166 Checksums" [I-D.ietf-6man-udpzero] describes issues related to 167 allowing UDP over IPv6 to have a valid zero UDP checksum and is the 168 starting point for this discussion. Sections 4 and 5 of 169 [I-D.ietf-6man-udpzero], respectively identify node implementation 170 and usage requirements for datagrams sent and received with a zero 171 UDP checksum. These introduce constraints on the usage of a zero 172 checksum for UDP over IPv6. The remainder of this section analyses 173 the use of general tunnels and motivates why tunnel protocols are 174 being permitted to use the method described in this update. Issues 175 with middleboxes are also discussed. 177 4.1. Analysis of Corruption in Tunnel Context 179 This section analyzes the impact of the different corruption modes in 180 the context of a tunnel protocol. It indicates what needs to be 181 considered by the designer and user of a tunnel protocol to be 182 robust. It also summarizes why use of a zero UDP checksum is thought 183 to be safe for deployment. 185 1. Context (i.e., tunneling state) should be established by 186 exchanging application Protocol Data Units (PDUs) carried in 187 checksummed UDP datagrams or by other protocols with integrity 188 protection against corruption. These control packets should also 189 carry any negotiation required to enable the tunnel endpoint to 190 accept UDP datagrams with a zero checksum and identify the set of 191 ports that are used. It is important that the control traffic is 192 robust against corruption because undetected errors can lead to 193 long-lived and significant failures that may affect much more 194 than the single packet that was corrupted. 196 2. Keep-alive datagrams with a zero UDP checksum should be sent to 197 validate the network path, because the path between tunnel 198 endpoints can change and therefore the set of middleboxes along 199 the path may change during the life of an association. Paths 200 with middleboxes that drop datagrams with a zero UDP checksum 201 will drop these keep-alives. To enable the tunnel endpoints to 202 discover and react to this behavior in a timely way, the keep- 203 alive traffic should include datagrams with a non-zero checksum 204 and datagrams with a zero checksum. 206 3. Receivers should attempt to detect corruption of the address 207 information in an encapsulating packet. A robust tunnel protocol 208 should track tunnel context based on the 5-tuple (tunneled 209 protocol number, IPv6 source address, IPv6 destination address, 210 UDP source port, UDP destination port). A corrupted datagram 211 that arrives at a destination may be filtered based on this 212 check. 214 * If the datagram header matches the 5-tuple and the node has 215 the zero checksum enabled for this port, the payload is 216 matched to the wrong context. The tunneled packet will then 217 be decapsulated and forwarded by the tunnel egress. 219 * If a corrupted datagram matches a different 5-tuple and the 220 zero checksum was enabled for the port, the datagram payload 221 is matched to the wrong context, and may be processed by the 222 wrong tunnel protocol, if it also passes the verification of 223 that protocol. 225 * If a corrupted datagram matches a 5-tuple and the zero 226 checksum has not been enabled for this port, the datagram will 227 be discarded. 229 When only the source information is corrupted, the datagram could 230 arrive at the intended applications/protocol, which will process 231 the datagram and try to match it against an existing tunnel 232 context. The likelihood that a corrupted packet enters a valid 233 context is reduced when the protocol restricts processing to only 234 the source addresses with established contexts. When both source 235 and destination fields are corrupted, this increases the 236 likelihood of failing to match a context, with the exception of 237 errors replacing one packet header with another one. In this 238 case, it is possible that both packets are tunnelled and 239 therefore the corrupted packet could match a previously defined 240 context. 242 4. Receivers should attempt to detect corruption of source- 243 fragmented encapsulating packets. A tunnel protocol may 244 reassemble fragments associated with the wrong context at the 245 right tunnel endpoint, or it may reassemble fragments associated 246 with a context at the wrong tunnel endpoint, or corrupted 247 fragments may be reassembled at the right context at the right 248 tunnel endpoint. In each of these cases, the IPv6 length of the 249 encapsulating header may be checked (though 250 [I-D.ietf-6man-udpzero] points out the weakness in this check). 251 In addition, if the encapsulated packet is protected by a 252 transport (or other) checksum, these errors can be detected (with 253 some probability). 255 5. Tunnel protocols using UDP have some advantages that reduce the 256 risk for a corrupted tunnel packet reaching a destination that 257 will receive it, compared to other applications. This results 258 from processing by the network of the inner (tunneled) packet 259 after being forwarded from the tunnel egress using a wrong 260 context: 262 * A tunneled packet may be forwarded to the wrong address 263 domain, for example, a private address domain where the inner 264 packet's address is not routable, or may fail a source address 265 check, such as Unicast Reverse Path Forwarding [RFC2827], 266 resulting in the packet being dropped. 268 * The destination address of a tunneled packet may not at all be 269 reachable from the delivered domain. For example, an Ethernet 270 frame where the destination MAC address is not present on the 271 LAN segment that was reached. 273 * The type of the tunneled packet may prevent delivery. For 274 example, an attempt to interpret an IP packet payload as an 275 Ethernet frame, would likely to result in the packet being 276 dropped as invalid. 278 * The tunneled packet checksum or integrity mechanism may detect 279 corruption of the inner packet caused at the same time as 280 corruption to the outer packet header. The resulting packet 281 would likely be dropped as invalid. 283 These checks each significantly reduce the likelihood that a 284 corrupted inner tunneled packet is finally delivered to a protocol 285 listener that can be affected by the packet. While the methods do 286 not guarantee correctness, they can reduce the risk of relaxing the 287 UDP checksum requirement for a tunnel application using IPv6. 289 4.2. Limitation to Tunnel Protocols 291 This document describes the applicability of using a zero UDP 292 checksum to support tunnel protocols. There are good motivations 293 behind this and the arguments are provided here. 295 o Tunnels carry inner packets that have their own semantics, which 296 may make any corruption less likely to reach the indicated 297 destination and be accepted as a valid packet. This is true for 298 IP packets with the addition of verification that can be made by 299 the tunnel protocol, the network processing of the inner packet 300 headers as discussed above, and verification of the inner packet 301 checksums. Non-IP inner packets are likely to be subject to 302 similar effects that may reduce the likelihood of a misdelivered 303 packet being delivered to a protocol listener that can be affected 304 by the packet. 306 o Protocols that directly consume the payload must have sufficient 307 robustness against misdelivered packets from any context, 308 including the ones that are corrupted in tunnels and any other 309 usage of the zero checksum. This will require an integrity 310 mechanism. Using a standard UDP checksum reduces the 311 computational load in the receiver to verify this mechanism. 313 o The design for stateful protocols or protocols where corruption 314 causes cascade effects requires extra care. In tunnel usage, each 315 encapsulating packet provides only a transport mechanism from 316 tunnel ingress to tunnel egress. A corruption will commonly only 317 affect the single tunneled packet, not the established protocol 318 state. One common effect is that the inner packet flow will only 319 see a corruption and misdelivery of the outer packet as a lost 320 packet. 322 o Some non-tunnel protocols operate with general servers that do not 323 know the source from which they will receive a packet. In such 324 applications, a zero UDP checksum is unsuitable because there is a 325 need to provide the first level of verification that the packet 326 was intended for the receiving server. A verification prevents 327 the server from processing the datagram payload and without this 328 it may spend significant resources processing the packet, 329 including sending replies or error messages. 331 Tunnel protocols that encapsulate IP will generally be safe for 332 deployment, since all IPv4 and IPv6 packets include at least one 333 checksum at either the network or transport layer. The network 334 delivery of the inner packet will then further reduce the effects of 335 corruption. Tunnel protocols carrying non-IP packets may offer 336 equivalent protection when the non-IP networks reduce the risk of 337 misdelivery to applications. However, there is a need for further 338 analysis to understand the implications of misdelievery of corrupted 339 packets for that each non-IP protocol. The analysis above suggests 340 that non-tunnel protocols can be expected to have significantly more 341 cases where a zero checksum would result in misdelivery or negative 342 side-effects. 344 One unfortunate side-effect of increased use of a zero-checksum is 345 that it also increases the likelihood of acceptance when a datagram 346 with a zero UDP checksum is misdelivered. This requires all tunnel 347 protocols using this method to be designed to be robust to 348 misdelivery. 350 4.3. Middleboxes 352 "Applicability Statement for the use of IPv6 UDP Datagrams with Zero 353 Checksums" [I-D.ietf-6man-udpzero] notes that middleboxes that 354 conform to RFC 2460 will discard datagrams with a zero UDP checksum 355 and should log this as an error. Tunnel protocols intending to use a 356 zero UDP checksum need to ensure that they have defined a method for 357 handling cases when a middlebox prevents the path between the tunnel 358 ingress and egress from supporting transmission of datagrams with a 359 zero UDP checksum. 361 5. The Zero-Checksum Update 363 This specification updates IPv6 to allow a zero UDP checksum in the 364 outer encapsulating datagram of a tunnel protocol. UDP endpoints 365 that implement this update MUST follow the node requirements in 366 "Applicability Statement for the use of IPv6 UDP Datagrams with Zero 367 Checksums" [I-D.ietf-6man-udpzero]. 369 The following text in [RFC2460] Section 8.1, 4th bullet should be 370 deleted: 372 "Unlike IPv4, when UDP packets are originated by an IPv6 node, the 373 UDP checksum is not optional. That is, whenever originating a UDP 374 packet, an IPv6 node must compute a UDP checksum over the packet and 375 the pseudo-header, and, if that computation yields a result of zero, 376 it must be changed to hex FFFF for placement in the UDP header. IPv6 377 receivers must discard UDP packets containing a zero checksum, and 378 should log the error." 380 This text should be replaced by: 382 An IPv6 node associates a mode with each used UDP port (for 383 sending and/or receiving packets). 385 Whenever originating a UDP packet for a port in the default mode, 386 an IPv6 node MUST compute a UDP checksum over the packet and the 387 pseudo-header, and, if that computation yields a result of zero, 388 it MUST be changed to hex FFFF for placement in the UDP header as 389 specified in [RFC2460]. IPv6 receivers MUST by default discard 390 UDP packets containing a zero checksum, and SHOULD log the error. 392 As an alternative, certain protocols that use UDP as a tunnel 393 encapsulation, MAY enable the zero-checksum mode for a specific 394 port (or set of ports) for sending and/or receiving. Any node 395 implementing the zero-checksum mode MUST follow the node 396 requirements specified in Section 4 of "Applicability Statement 397 for the use of IPv6 UDP Datagrams with Zero Checksums" 398 [I-D.ietf-6man-udpzero]. 400 Any protocol that enables the zero-checksum mode for a specific 401 port or ports MUST follow the usage requirements specified in 402 Section 5 of "Applicability Statement for the use of IPv6 UDP 403 Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero]. 405 Middleboxes supporting IPv6 MUST follow requirements 9, 10 and 11 406 of the usage requirements specified in Section 5 of "Applicability 407 Statement for the use of IPv6 UDP Datagrams with Zero Checksums" 408 [I-D.ietf-6man-udpzero]. 410 6. Additional Observations 412 This update was motivated by the existence of a number of protocols 413 being developed in the IETF that are expected to benefit from the 414 change. The following observations are made: 416 o An empirically-based analysis of the probabilities of packet 417 corruption (with or without checksums) has not (to our knowledge) 418 been conducted since about 2000. At the time of publication, it 419 is now 2012. We strongly suggest a new empirical study, along 420 with an extensive analysis of the corruption probabilities of the 421 IPv6 header. This can potentially allow revising the 422 recommendations in this document. 424 o A key motivation for the increase in use of UDP in tunneling is a 425 lack of protocol support in middleboxes. Specifically, new 426 protocols, such as LISP [RFC6830], may prefer to use UDP tunnels 427 to traverse an end-to-end path successfully and avoid having their 428 packets dropped by middleboxes. If middleboxes were updated to 429 support UDP-Lite [RFC3828], UDP-Lite would provide better 430 protection than offered by this update. This may be suited to a 431 variety of applications and would be expected to be preferred over 432 this method for many tunnel protocols. 434 o Another issue is that the UDP checksum is overloaded with the task 435 of protecting the IPv6 header for UDP flows (as is the TCP 436 checksum for TCP flows). Protocols that do not use a pseudo- 437 header approach to computing a checksum or CRC have essentially no 438 protection from misdelivered packets. 440 7. IANA Considerations 442 This document makes no request of IANA. 444 Note to RFC Editor: this section may be removed on publication as an 445 RFC. 447 8. Security Considerations 449 Less work is required to generate an attack using a zero UDP checksum 450 than one using a standard full UDP checksum. However, this does not 451 lead to significant new vulnerabilities because checksums are not a 452 security measure and can be easily generated by any attacker. 454 In general any user of zero UDP checksums should apply the checks and 455 context verification that are possible to minimize the risk of 456 unintended traffic to reach a particular context. This will however 457 not protect against an intended attack that create packet with the 458 correct information. Source address validation can help prevent 459 injection of traffic into contexts by an attacker. 461 Depending on the hardware design, the processing requirements may 462 differ for tunnels that have a zero UDP checksum and those that 463 calculate a checksum. This processing overhead may need to be 464 considered when deciding whether to enable a tunnel and to determine 465 an acceptable rate for transmission. This can become a security risk 466 for designs that can handle a significantly larger number of packets 467 with zero UDP checksums compared to datagrams with a non-zero 468 checksum, such as tunnel egress. An attacker could attempt to inject 469 non-zero checksummed UDP packets into a tunnel forwarding zero 470 checksum UDP packets and cause overload in the processing of the non- 471 zero checksums, e.g. if this happens in a routers slow path. 472 Protection mechanisms should therefore be employed when this threat 473 exists. Protection may include source address filtering to prevent 474 an attacker injecting traffic, as well as throttling the amount of 475 non-zero checksum traffic. The latter may impact the function of the 476 tunnel protocol. 478 9. Acknowledgements 480 We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David 481 Waltermire, J.W. Atwood, Peter Yee, Joe Touch and the IESG of 2012 482 for discussions and reviews. Gorry Fairhurst has been very diligent 483 in reviewing and help ensuring alignment between this document and 484 [I-D.ietf-6man-udpzero]. 486 10. References 488 10.1. Normative References 490 [I-D.ietf-6man-udpzero] 491 Fairhurst, G. and M. Westerlund, "Applicability Statement 492 for the use of IPv6 UDP Datagrams with Zero Checksums", 493 draft-ietf-6man-udpzero-10 (work in progress), 494 January 2013. 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 500 (IPv6) Specification", RFC 2460, December 1998. 502 10.2. Informative References 504 [I-D.ietf-mboned-auto-multicast] 505 Bumgardner, G., "Automatic Multicast Tunneling", 506 draft-ietf-mboned-auto-multicast-14 (work in progress), 507 June 2012. 509 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 510 Defeating Denial of Service Attacks which employ IP Source 511 Address Spoofing", BCP 38, RFC 2827, May 2000. 513 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 514 G. Fairhurst, "The Lightweight User Datagram Protocol 515 (UDP-Lite)", RFC 3828, July 2004. 517 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 518 for Application Designers", BCP 145, RFC 5405, 519 November 2008. 521 [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, 522 "Softwire Security Analysis and Requirements", RFC 5619, 523 August 2009. 525 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 526 Locator/ID Separation Protocol (LISP)", RFC 6830, 527 January 2013. 529 Authors' Addresses 531 Marshall Eubanks 532 AmericaFree.TV LLC 533 P.O. Box 141 534 Clifton, Virginia 20124 535 USA 537 Phone: +1-703-501-4376 538 Fax: 539 Email: marshall.eubanks@gmail.com 540 P.F. Chimento 541 Johns Hopkins University Applied Physics Laboratory 542 11100 Johns Hopkins Road 543 Laurel, MD 20723 544 USA 546 Phone: +1-443-778-1743 547 Email: Philip.Chimento@jhuapl.edu 549 Magnus Westerlund 550 Ericsson 551 Farogatan 6 552 SE-164 80 Kista 553 Sweden 555 Phone: +46 10 714 82 87 556 Email: magnus.westerlund@ericsson.com