idnits 2.17.1 draft-finlayson-ttl-admin-scope-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 155 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: A later version (-05) exists of draft-ietf-mboned-admin-ip-space-01 == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-sdp-02 -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ross Finlayson 2 Internet-Draft Live Networks 3 Expire in six months 1997.03.25 5 Using TTLs with Administratively Scoped IP Multicast Addresses 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or 25 ftp.isi.edu (US West Coast). 27 2. Abstract 29 The use of "administratively scoped" multicast address ranges (as 30 described in [1]) leads to a multicast traffic scoping mechanism 31 that is superior to the original "TTL scoping" mechanism. 33 Contrary to popular opinion, however, administrative (often 34 abbreviated as "admin") scoping does not truly *replace* 35 TTL scoping. In particular, multicast-based applications must 36 still be aware of which TTL value(s) they use. 38 In this document, we note that each definition of a range of 39 admin scoped multicast addresses should be accompanied by a 40 corresponding "maximum effective TTL" that should be used with 41 these addresses. We describe how these TTL values are used by 42 applications, and how they may influence the configuration 43 of multicast border routers. 45 3. The need for a "maximum effective TTL" for each admin scoped range 47 A multicast-based application needs to be aware of the TTL value(s) 48 that is uses in the packets that it sends. If it uses a TTL that's 49 too low, it may not reach all of the other nodes that it wants to. 50 On the other hand, if it uses a TTL that's too high, it may waste 51 network resources. 53 If the entire MBone were to use admin scoping, then it would, in 54 principle, be OK for applications to always use a TTL of 255 55 (the maximum possible value). In reality, however, this would be 56 disastrous, because there will inevitably be some sections of the 57 MBone that (i) do not implement admin scoping, and (ii) use 58 "flood-and-prune" multicast routing protocols (such as DVMRP). 59 If many applications were to use a TTL of 255, then these sections 60 of the MBone would likely become overwhelmed. Instead, well-behaved 61 multicast-based applications should use a TTL that's large enough 62 to reach all of the nodes that they're interested in, but not much 63 larger. 65 To address this problem, we propose that whenever a range of 66 admin scoped multicast addresses is defined (e.g., by IANA), then 67 this definition be accompanied by the explicit definition of a 68 "maximum effective TTL" for this range. This TTL is chosen to 69 be large enough to guarantee reaching all nodes within the 70 corresponding scope, but not too much larger. Thus, the 71 "maximum effective TTL" for an admin scoped range describes the 72 topological 'size' of the scope. (As with pure TTL scoping, each 73 such range will typically also be given a descriptive label, such 74 as "continent", that describes the size in human terms.) 76 4. Use by applications 78 Many multicast-based applications will not have to concern 79 themselves with this, because they will already know both the 80 multicast address(es) that they use, and the corresponding 81 TTL(s). In particular, applications that are launched from 82 "session descriptions" (e.g., in SDP [2]) will get both the 83 multicast address and the TTL from the session description itself. 85 However, applications that choose multicast addresses dynamically 86 should be aware of the corresponding "maximum effective TTL" for 87 each multicast address that they choose. For example, an 88 application that *creates* a new session description might 89 prompt the user for the size of the scope required (perhaps 90 using descriptive human-understandable labels such as 91 "continent"). It would then use the user's response to select 92 an appropriate-sized admin scope, with a corresponding address 93 range and TTL. 95 An application that varies its TTL - e.g., to perform "expanding 96 ring"-type searches - need not (and should not) increase the 97 TTL beyond the "maximum effective TTL" for the multicast address 98 that it's using. 100 5. Implementation & configuration of multicast border routers 102 A multicast router that implements admin scoped boundaries 103 (as described in [1]) need have no knowledge of "maximum effective 104 TTLs". Such routers may be configured by defining only the multicast 105 addresses that define the boundaries. 107 However, because a "maximum effective TTL" is defined for each admin 108 scoped range, a (reimplemented) multicast router could, in principle, 109 be configured using TTL thresholds only. That is, a specification of 110 a TTL threshold "t" would denote a boundary for addresses in all 111 admin scoped ranges whose "maximum effective TTL" is less than or 112 equal to "t". 114 An advantage of this approach is that TTL-threshold-based 115 configuration is (arguably) more intuitive and easier to understand 116 (and thus less susceptible to errors) than address-range-based 117 configuration. Also, existing configuration files (that define only 118 TTL threshold boundaries) could remain unchanged, and admin scoping 119 would get implemented automatically via a router software upgrade. 121 Finally, it should be noted that - regardless of how admin scope 122 boundaries may be configured - all border routers in the MBone should 123 eventually implement such boundaries. It has been noted [3] that 124 optimal pruning (with flood-and-prune routing protocols) in the MBone 125 does not occur if admin scoped boundaries are not used. 127 6. Security considerations 129 While the use of "maximum effective TTLs", as described here, helps 130 limit the distribution of multicast traffic, neither this mechanism, 131 nor administrative scoping itself, should be viewed as a mechanism 132 for ensuring confidentiality. 134 7. References 136 [1] David Meyer. "Administratively Scoped IP Multicast". 137 Work in progress, 138 Internet Draft: draft-ietf-mboned-admin-ip-space-01.txt 139 [2] M Handley, V. Jacobson. "SDP: Session Description Protocol" 140 Work in progress, Internet Draft: draft-ietf-mmusic-sdp-02.txt 141 [3] Stephen Casner. "Discovery of Pruning Problem" 142 Email to the MBONED working group, 30 January 1997. 144 8. Author's address 146 Ross Finlayson 147 finlayson@lvn.com