home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mboned-admin-ip-space-03.txt < prev    next >
Text File  |  1997-06-11  |  13KB  |  417 lines
  1.  
  2.  
  3. MBONED Working Group                                         David Meyer
  4. Internet Draft                                      University of Oregon
  5. Category                                           Best Current Practice
  6.  
  7. draft-ietf-mboned-admin-ip-space-03.txt                        June 1997
  8.  
  9.  
  10.  
  11.  
  12.                   Administratively Scoped IP Multicast
  13.  
  14.  
  15.  
  16. 1. Status of this Memo
  17.  
  18.    This document is an Internet-Draft. Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups. Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at any
  25.    time. It is inappropriate to use Internet-Drafts as reference
  26.    material or to cite them other than as ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  30.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  31.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  32.    ftp.isi.edu (US West Coast).
  33.  
  34.  
  35. 2. Abstract
  36.  
  37.    This document defines the "administratively scoped IPv4 multicast
  38.    space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it
  39.    describes a simple set of semantics for the implementation of
  40.    Administratively Scoped IP Multicast. Finally, it provides a mapping
  41.    between the IPv6 multicast address classes [RFC1884] and IPv4
  42.    multicast address classes.
  43.  
  44.    This memo is a product of the MBONE Deployment Working Group (MBONED)
  45.    in the Operations and Management Area of the Internet Engineering
  46.    Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. David Meyer                                             FORMFEED[Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60. Internet Draft  draft-ietf-mboned-admin-ip-space-03.txt        June 1997
  61.  
  62.  
  63. 3. Acknowledgments
  64.  
  65.    Much of this memo is taken from "Administratively Scoped IP
  66.    Multicast", Van Jacobson and Steve Deering, presented at the 30th
  67.    IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and
  68.    Dave Thaler have also provided insightful comments on earlier
  69.    versions of this document.
  70.  
  71.  
  72. 4. Introduction
  73.  
  74.    Most current IP multicast implementations achieve some level of
  75.    scoping by using the TTL field in the IP header. Typical MBONE
  76.    (Multicast Backbone) usage has been to engineer TTL thresholds that
  77.    confine traffic to some administratively defined topological region.
  78.    The basic forwarding rule for interfaces with configured TTL
  79.    thresholds is that a packet is not forwarded across the interface
  80.    unless its remaining TTL is greater than the threshold.
  81.  
  82.    TTL scoping has been used to control the distribution of multicast
  83.    traffic with the objective of easing stress on scarce resources
  84.    (e.g., bandwidth), or to achieve some kind of improved privacy or
  85.    scaling properties. In addition, the TTL is also used in its
  86.    traditional role to limit datagram lifetime. Given these often
  87.    conflicting roles, TTL scoping has proven difficult to implement
  88.    reliably, and the resulting schemes have often been complex and
  89.    difficult to understand.
  90.  
  91.    A more serious architectural problem concerns the interaction of TTL
  92.    scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The
  93.    particular problem is that in many common cases, TTL scoping can
  94.    prevent pruning from being effective. Consider the case in which a
  95.    packet has either had its TTL expire or failed a TTL threshold. The
  96.    router which discards the packet will not be capable of pruning any
  97.    upstream sources, and thus will sink all multicast traffic (whether
  98.    or not there are downstream receivers). Note that while it might seem
  99.    possible to send prunes upstream from the point at which a packet is
  100.    discarded, this strategy can result in legitimate traffic being
  101.    discarded, since subsequent packets could take a different path and
  102.    arrive at the same point with a larger TTL.
  103.  
  104.    On the other hand, administratively scoped IP multicast can provide
  105.    clear and simple semantics for scoped IP multicast. The key
  106.    properties of administratively scoped IP multicast are that (i).
  107.    packets addressed to administratively scoped multicast addresses do
  108.    not cross configured administrative boundaries, and (ii).
  109.    administratively scoped multicast addresses are locally assigned, and
  110.    hence are not required to be unique across administrative boundaries.
  111.  
  112.  
  113.  
  114. David Meyer                                             FORMFEED[Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120. Internet Draft  draft-ietf-mboned-admin-ip-space-03.txt        June 1997
  121.  
  122.  
  123. 5. Definition of the Administratively Scoped IPv4 Multicast Space
  124.  
  125.    The administratively scoped IPv4 multicast address space is defined
  126.    to be the range 239.0.0.0 to 239.255.255.255.
  127.  
  128.  
  129. 6. Discussion
  130.  
  131.    In order to support administratively scoped IP multicast, a router
  132.    should support the configuration of per-interface scoped IP multicast
  133.    boundaries. Such a router, called a boundary router, does not forward
  134.    packets matching an interface's boundary definition in either
  135.    direction (the bi-directional check prevents problems with multi-
  136.    access networks). In addition, a boundary router always prunes the
  137.    boundary for dense-mode groups [PIMDM], and doesn't accept joins for
  138.    sparse-mode groups [PIMSM] in the administratively scoped range.
  139.  
  140.  
  141. 7. The Structure of the Administratively Scoped Multicast Space
  142.  
  143.    The structure of the IP version 4 administratively scoped multicast
  144.    space is loosely based on the IP Version 6 Addressing Architecture
  145.    described in RFC 1884 [RFC1884]. This document defines two important
  146.    scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These
  147.    scopes are described below.
  148.  
  149.  
  150. 7.1. The IPv4 Local Scope -- 239.255.0.0/16
  151.  
  152.    239.255.0.0/16 is defined to be the IPv4 Local Scope.  The Local
  153.    Scope is the minimal enclosing scope, and hence is not further
  154.    divisible. Although the exact extent of a Local Scope is site
  155.    dependent, locally scoped regions must obey certain topological
  156.    constraints. In particular, a Local Scope must not span any other
  157.    scope boundary. Further, a Local Scope must be completely contained
  158.    within or equal to any larger scope. In the event that scope regions
  159.    overlap in area, the area of overlap must be in its own local scope.
  160.    This implies that any scope boundary is also a boundary for the Local
  161.    Scope. The more general topological requirements for administratively
  162.    scoped regions are discussed below.
  163.  
  164.  
  165. 7.1.1. Expansion of the IPv4 Local Scope
  166.  
  167.    The IPv4 Local Scope space grows "downward". As such, the IPv4 Local
  168.    Scope may grow downward from 239.255.0.0/16 into the reserved ranges
  169.    239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not
  170.    be utilized until the 239.255.0.0/16 space is no longer sufficient.
  171.  
  172.  
  173.  
  174. David Meyer                                             FORMFEED[Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Internet Draft  draft-ietf-mboned-admin-ip-space-03.txt        June 1997
  181.  
  182.  
  183. 7.2. The IPv4 Organization Local Scope -- 239.192.0.0/14
  184.  
  185.    239.192.0.0/14 is defined to be the IPv4 Organization Local Scope,
  186.    and is the space from which an organization should allocate sub-
  187.    ranges when defining scopes for private use.
  188.  
  189.  
  190. 7.2.1. Expansion of the IPv4 Organization Local Scope
  191.  
  192.    The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are
  193.    unassigned and available for expansion of this space.  These ranges
  194.    should be left unassigned until the 239.192.0.0/14 space is no longer
  195.    sufficient. This is to allow for the possibility that future
  196.    revisions of this document may define additional scopes on a scale
  197.    larger than organizations.
  198.  
  199.  
  200. 7.3. Other IPv4 Scopes of Interest
  201.  
  202.    The other two scope classes of interest, statically assigned link-
  203.    local scope and global scope already exist in IPv4 multicast space.
  204.    The statically assigned link-local scope is 224.0.0.0/24. The
  205.    existing static global scope allocations are somewhat more granular,
  206.    and include
  207.  
  208.  
  209.            224.1.0.0-224.1.255.255         ST Multicast Groups
  210.            224.2.0.0-224.2.127.253         Multimedia Conference Calls
  211.            224.2.127.254                   SAPv1 Announcements
  212.            224.2.127.255                   SAPv0 Announcements (deprecated)
  213.            224.2.128.0-224.2.255.255       SAP Dynamic Assignments
  214.            224.252.0.0-224.255.255.255     DIS transient groups
  215.            232.0.0.0-232.255.255.255       VMTP transient groups
  216.  
  217.  
  218.    See [RFC1700] for current multicast address assignments (this list
  219.    can also be found, possibly in a more current form, on
  220.    ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234. David Meyer                                             FORMFEED[Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240. Internet Draft  draft-ietf-mboned-admin-ip-space-03.txt        June 1997
  241.  
  242.  
  243. 8. Topological Requirements for Administrative Boundaries
  244.  
  245.    An administratively scoped IP multicast region is defined to be a
  246.    topological region in which there are one or more boundary routers
  247.    with common boundary definitions. Such a router is said to be a
  248.    boundary for scoped addresses in the range defined in its
  249.    configuration.
  250.  
  251.    Network administrators may configure a scope region whenever
  252.    constrained multicast scope is required. In addition, an
  253.    administrator may configure overlapping scope regions (networks can
  254.    be in multiple scope regions) where convenient, with the only
  255.    limitations being that a scope region must be connected (there must
  256.    be a path between any two nodes within a scope region that doesn't
  257.    leave that region), and convex (i.e., no path between any two points
  258.    in the region can cross a region boundary).
  259.  
  260.    Finally, note that any scope boundary is a boundary for the Local
  261.    Scope. This implies that packets sent to groups covered by
  262.    239.255.0.0/16 must not be forwarded across any link for which a
  263.    scoped boundary is defined.
  264.  
  265.  
  266. 9. Partitioning of the Administratively Scoped Multicast Space
  267.  
  268.    The following table outlines the partitioning of the IPv4 multicast
  269.    space, and gives the mapping from IPv4 multicast prefixes to IPv6
  270.    SCOP values:
  271.  
  272.  
  273.  
  274.    IPv6 SCOP         RFC 1884 Description             IPv4 Prefix
  275.    ==================================================================
  276.       0                  reserved
  277.       1                  node-local scope
  278.       2                  link-local scope             224.0.0.0/24
  279.       3                  (unassigned)                 239.255.0.0/16
  280.       4                  (unassigned)
  281.       5                  site-local scope
  282.       6                  (unassigned)
  283.       7                  (unassigned)
  284.       8                  organization-local scope     239.192.0.0/14
  285.       A                  (unassigned)
  286.       B                  (unassigned)
  287.       C                  (unassigned)
  288.       D                  (unassigned)
  289.       E                  global scope                 224.0.1.0-238.255.255.255
  290.       F                  reserved
  291.  
  292.  
  293.  
  294. David Meyer                                             FORMFEED[Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300. Internet Draft  draft-ietf-mboned-admin-ip-space-03.txt        June 1997
  301.  
  302.  
  303.                          (unassigned)                 239.0.0.0/10
  304.                          (unassigned)                 239.64.0.0/10
  305.                          (unassigned)                 239.128.0.0/10
  306.  
  307.  
  308. 10. Security Considerations
  309.  
  310.    While security considerations are not explicitly discussed in this
  311.    memo, it is important to note that a boundary router as described
  312.    here should not be considered to provide any kind of firewall
  313.    functionality.
  314.  
  315.  
  316. 11. References
  317.  
  318.       [ASMA]    V. Jacobson,  S. Deering, "Administratively Scoped IP
  319.                 Multicast", , presented at the 30th IETF, Toronto,
  320.                 Canada, 25 July 1994.
  321.  
  322.       [DVMRP]   T. Pusateri, "Distance Vector Multicast Routing
  323.                 Protocol", draft-ietf-idmr-dvmrp-v3-03.txt,
  324.                 September, 1996.
  325.  
  326.       [PIMDM]   Deering, S, et. al., "Protocol Independent Multicast
  327.                 Version 2, Dense Mode Specification",
  328.                 draft-ietf-idmr-pim-dm-05.txt, April, 1997.
  329.  
  330.       [PIMSM]   Estrin, D, et. al., "Protocol Independent Multicast
  331.                 Sparse Mode (PIM-SM): Protocol Specification",
  332.                 draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1997.
  333.  
  334.       [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October,
  335.                 1994.
  336.  
  337.       [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
  338.                 Architecture", RFC1884, December 1995.
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354. David Meyer                                             FORMFEED[Page 6]
  355.  
  356.  
  357.  
  358.  
  359.  
  360. Internet Draft  draft-ietf-mboned-admin-ip-space-03.txt        June 1997
  361.  
  362.  
  363. 12. Author's Address
  364.  
  365.    David Meyer
  366.    Advanced Network Technology Center
  367.    University of Oregon
  368.    1225 Kincaid St.
  369.    Eugene, OR 97403
  370.  
  371.    phone:  +1 541.346.1747
  372.    email:  meyer@antc.uoregon.edu
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414. David Meyer                                             FORMFEED[Page 7]
  415.  
  416.  
  417.