idnits 2.17.00 (12 Aug 2021) /tmp/idnits31445/draft-asati-eckert-multicast-local-ttl-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2011) is 4086 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Unused Reference: 'RFC5796' is defined on line 173, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Rajiv Asati 2 Internet Draft Toerless Eckert 3 Intended status: Standards Cisco 4 March 7, 2011 5 Expires: September 2011 7 Time To Live (TTL) Guideline for Link-Local-Scope Multicast Packets 8 draft-asati-eckert-multicast-local-ttl-00.txt 10 Abstract 12 This document specifies the value for the Time-to-Live in an IP 13 packet that is destined to a link-local scope IP multicast address. 14 These guidelines may be used for verification purposes. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on September 7, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction...................................................2 57 2. Conventions used in this document..............................3 58 3. TTL Value......................................................3 59 4. Security Considerations........................................3 60 5. IANA Considerations............................................3 61 6. Conclusions....................................................3 62 7. Appendix.......................................................3 63 7.1. Discussion TTL=1 or TTL=255...............................3 64 8. References.....................................................4 65 8.1. Normative References......................................4 66 8.2. Informative References....................................4 67 9. Acknowledgments................................................5 69 1. Introduction 71 It has been a common practice to encode Time to Live (TTL) for the 72 IP multicast packets that have link-local scope, 74 There has not been any standard document that specified the TTL 75 value for the IPv4 multicast packets (such as the ones belonging to 76 the protocols listed below) that have link-local scope, even though 77 a common practice has been to encode the smallest Time to Live (TTL) 78 value (=1). 80 o Protocol Independent Multicast (PIM) [RFC4601] 82 o IGMP/MLD 84 o Routing Protocol (OSPF, EIGRP etc.) Discovery 85 o LDP Discovery 87 This document specifies the IPv4 TTL value for such link-local 88 multicast packets. 90 Note: This document does not define any behavior for link-local 91 scope IP unicast packets. 93 2. Conventions used in this document 95 In examples, "C:" and "S:" indicate lines sent by the client and 96 server respectively. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. TTL Value 104 This document specifies that any protocol generating link-local IPv4 105 multicast packets must encode the corresponding TTL value to be one 106 (= 1). 108 IPv6 Neighbor Discover (ND) [RFC4861] is excluded from this for 109 historic reasons (see below). 111 4. Security Considerations 113 This specification improves the security of many link-local 114 protocols. 116 5. IANA Considerations 118 None. 120 6. Conclusions 122 This document specifies the value = 1 for IPv4 TTL to be used on IP 123 multicast packets that are not meant to be forwarded beyond the 124 first hop. 126 7. Appendix 128 7.1. Discussion TTL=1 or TTL=255 130 The use of a TTL=1 for link-local-scope IP multicast packets evolved 131 out of the logic that link-local-scope networks have a hop-count of 132 1 and that limiting the TTL of such packets to 1 did provide 133 appropriate protection against such packets leaking to other 134 subnets. 136 GTSM was introduced for unicast packets first, specifying a TTL of 137 255 and filtering of packets with a TTL smaller than 255 on receipt. 138 This was used as a mean to protect against attackers from other 139 networks sending packets with a TTL just large enough that it would 140 end up as a TTL of 1 on the target network. 142 Attacks such as those that GTSM protects against are not possible 143 with link-local scope IP multicast packets because all devices that 144 forward IP multicast packets and decrement the TTL are IP multicast 145 routers that do not forward link-local scope IP multicast packets at 146 all. There is no indication that any devices exist that break this 147 standard behavior. If one would choose to recommend GTSM for link- 148 local IP multicast packets on the premise of unknown devices, then 149 one should even more be concerned about unknown devices forwarding 150 link-local IP multicast packets without decrementing the TTL. 152 In IPv6 ND, a TTL of 255 is used, based on the early premise that 153 link-local-scope in IPv6 could optionally include networks with more 154 than one hop. This premise was later dropped, so the use of TTL=255 155 in ND is mostly for historic reasons. 157 8. References 159 8.1. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 8.2. Informative References 166 [RFC4861] Narten, T., et. al, "Neighbor Discovery for IP version 6 167 (IPv6)", RFC 4861, September 2007. 169 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 170 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 171 Protocol Specification (Revised)", RFC 4601, August 2006. 173 [RFC5796] Atwood, W., Islam, S., and Siami, M., "Authentication and 174 Confidentiality in Protocol Independent Multicast Sparse 175 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. 177 9. Acknowledgments 179 The authors would like to thank Stig Venaas for his review. 181 This document was prepared using 2-Word-v2.0.template.dot. 183 Authors' Addresses 185 Rajiv Asati 186 Cisco 187 7025 Kit Creek Rd, RTP, NC 27709 188 Email: rajiva@cisco.com 190 Toerless Eckert 191 Cisco 192 510 McCarthy Blvd., Milpitas, CA 95035 193 Email: eckert@cisco.com