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-02.txt < prev    next >
Text File  |  1997-04-28  |  13KB  |  395 lines
  1.  
  2. INTERNET-DRAFT                                           David Meyer
  3. draft-ietf-mboned-admin-ip-space-02.txt         University of Oregon
  4. Category:Best Current Practice                            April 1997
  5.  
  6.  
  7.                   Administratively Scoped IP Multicast
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This document specifies an Internet Best Current Practice for the
  13.    Internet Community, and requests discussion and suggestions for
  14.    improvements.  Distribution of this memo is unlimited.
  15.  
  16. Internet Drafts
  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. Abstract
  35.  
  36.    This document defines the "administratively scoped IPv4 multicast
  37.    space" to be  the range 239.0.0.0 to 239.255.255.255 . In addition,
  38.    it describes a simple set of semantics for the implementation of
  39.    Administratively Scoped IP Multicast. Finally, it provides a mapping
  40.    between the IPv6 multicast address classes [RFC1884] and IPv4
  41.    multicast address classes.
  42.  
  43.    This memo is a product of the MBONE Deployment Working Group (MBONED)
  44.    in the Operational Requirements area of the Internet Engineering Task
  45.    Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
  46.  
  47.  
  48.  
  49.  
  50. Expires October 1997                                            [Page 1]
  51.  
  52.  
  53.  
  54.  
  55.  
  56. INTERNET-DRAFT    Administratively Scoped IP Multicast        April 1997
  57.  
  58.  
  59. Acknowledgments
  60.  
  61.    Much of this memo is taken from "Administratively Scoped IP
  62.    Multicast", Van Jacobson and Steve Deering, presented at the 30th
  63.    IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and
  64.    Dave Thaler also provided insightful comments on earlier versions of
  65.    this draft.
  66.  
  67. Introduction
  68.  
  69.  
  70.    Most current IP multicast implementations achieve some level of scop-
  71.    ing by using the TTL field in the IP header. Typical MBONE (Multicast
  72.    Backbone) usage has been to engineer TTL thresholds that confine
  73.    traffic to some administratively defined topological region.  The
  74.    basic forwarding rule for interfaces with configured TTL thresholds
  75.    is that a packet is not forwarded across the interface unless its
  76.    remaining TTL greater than the threshold.
  77.  
  78.    TTL scoping has been used to control the distribution of multicast
  79.    traffic with the objective of easing stress on scarce resources
  80.    (e.g., bandwidth), or to achieve some kind of improved privacy or
  81.    scaling properties.  In addition, the TTL is also used in its tradi-
  82.    tional role to limit datagram lifetime. Given these often conflicting
  83.    roles, TTL scoping has proven difficult to implement reliably, and
  84.    the resulting schemes have often been complex and difficult to under-
  85.    stand.
  86.  
  87.    A more serious architectural problem with TTL scoping is that, in
  88.    many cases, it can prevent pruning from being effective. Consider the
  89.    case in which a packet either has its TTL expire or does not meet a
  90.    TTL threshold. The point (e.g., tunnel, interface) at which the
  91.    packet fails the TTL check will not be capable of pruning upstream
  92.    and hence will sink all traffic, independent of whether there are
  93.    downstream group members. Note that without somehow associating prune
  94.    state and TTL, this problem will persist. For example, while it might
  95.    seem possible to send a prune upstream from the point where the
  96.    packet is discarded, this strategy could prevent legitimate traffic
  97.    from being forwarded (subsequent packets could take a different path
  98.    and wind up at the same point with a larger TTL). However, if a prune
  99.    had been sent, the packet may not be forwarded on interfaces that it
  100.    should have been.
  101.  
  102.    On the other hand, by using administratively scoped IP multicast, one
  103.    can achieve locally scoped multicast with simple, clear semantics.
  104.  
  105.  
  106.  
  107. Expires October 1997                                            [Page 2]
  108.  
  109.  
  110.  
  111.  
  112.  
  113. INTERNET-DRAFT    Administratively Scoped IP Multicast        April 1997
  114.  
  115.  
  116.    The key properties of any implementation of administratively scoped
  117.    IP multicast are that (i). packets addressed to administratively
  118.    scoped multicast addresses do not cross configured administrative
  119.    boundaries, and (ii). administratively scoped multicast addresses are
  120.    locally assigned, and hence are not required to be unique across
  121.    administrative boundaries. These properties are sufficient to imple-
  122.    ment administrative scoping.
  123.  
  124. Allocation of the Administratively Scoped IPv4 Multicast Address Space
  125.  
  126.    IANA should allocate the  range 239.0.0.0 to 239.255.255.255 to be
  127.    the "Administratively Scoped IPv4 Multicast" address space.
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134. Discussion
  135.  
  136.  
  137.    In order to support administratively scoped IP multicast, a router
  138.    should support the configuration of scoped IP multicast boundaries.
  139.    Such a router, called a boundary router, does not forward packets
  140.    matching its boundary definition in either direction across its
  141.    border (the bi-directional check prevents problems with  multi-access
  142.    networks).  In addition, a boundary router always prunes the boundary
  143.    for dense-mode groups, or doesn't accept joins for sparse-mode groups
  144.    [PIMSM] in the administratively scoped range.
  145.  
  146. Structure of the Administratively Scoped Multicast Space
  147.  
  148.  
  149.    The structure of the IP version 4 administratively scoped multicast
  150.    space is based on the IP Version 6 Addressing Architecture described
  151.    in RFC 1884. The following table outlines the partitioning of the
  152.    IPv4 multicast space, and gives the mapping to IPv6 SCOP values
  153.    [RFC1884].
  154.  
  155.    IPv6 SCOP         RFC 1884 Description             IPv4 Prefix
  156.    ==================================================================
  157.       0                  reserved
  158.       1                  node-local scope
  159.       2                  link-local scope             224.0.0.0/24
  160.       3                  (unassigned)                 239.255.0.0/16
  161.  
  162.  
  163.  
  164. Expires October 1997                                            [Page 3]
  165.  
  166.  
  167.  
  168.  
  169.  
  170. INTERNET-DRAFT    Administratively Scoped IP Multicast        April 1997
  171.  
  172.  
  173.       4                  (unassigned)                 239.254.0.0/16
  174.       5                  site-local scope             239.253.0.0/16
  175.       6                  (unassigned)
  176.       7                  (unassigned)
  177.       8                  organization-local scope     239.192.0.0/14
  178.       A                  (unassigned)
  179.       B                  (unassigned)
  180.       C                  (unassigned)
  181.       D                  (unassigned)
  182.       E                  global scope                 224.0.1.0-238.255.255.255
  183.       F                  reserved
  184.                          (unassigned)                 239.0.0.0/10
  185.                          (unassigned)                 239.64.0.0/10
  186.                          (unassigned)                 239.128.0.0/10
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195. The IPv4 Local Scope -- 239.255.0.0/16
  196.  
  197.  
  198.  
  199.    239.255.0.0/16 is the IPv4 Local Scope.  While how local is the Local
  200.    Scope is site dependent, locally scoped regions must obey certain
  201.    topological constraints. In particular, a Local Scope must not span
  202.    any other boundary.  That is, it must be completely contained within,
  203.    or equal to, any larger scope. In the event that two scope regions
  204.    overlap in area, the area that overlaps must be in it's own local
  205.    scope. This also means that any scope boundary is also a boundary for
  206.    the Local Scope. The more general topological requirements for admin-
  207.    istratively scoped regions are discussed below.
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214. Other IPv4 Scopes of Interest
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Expires October 1997                                            [Page 4]
  222.  
  223.  
  224.  
  225.  
  226.  
  227. INTERNET-DRAFT    Administratively Scoped IP Multicast        April 1997
  228.  
  229.  
  230.    The other two scope classes of interest, statically assigned link-
  231.    local scope and global scope already exist to some extent in IP ver-
  232.    sion 4 multicast space. In particular, the statically assigned link-
  233.    local scope is 224.0.0.0/24. The existing global scope allocations
  234.    are currently somewhat more granular, and include
  235.  
  236.  
  237.            224.1.0.0-224.1.255.255         ST Multicast Groups
  238.            224.2.0.0-224.2.127.253         Multimedia Conference Calls
  239.            224.2.127.254                   SAPv1 Announcements
  240.            224.2.127.255                   SAPv0 Announcements (deprecated)
  241.            224.2.128.0-224.2.255.255       SAP Dynamic Assignments
  242.            224.252.0.0-224.255.255.255     DIS transient groups
  243.            232.0.0.0-232.255.255.255       VMTP transient groups
  244.  
  245.    See ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses
  246.    for current multicast address assignments.
  247.  
  248.  
  249.  
  250.  
  251.  
  252. Topological Requirements for Administrative Boundaries
  253.  
  254.  
  255.    An administratively scoped IP multicast region is defined to be a
  256.    topological region in which there are one or more boundary routers
  257.    with common boundary definitions. Such a router is said to be a boun-
  258.    dary for scoped addresses in the range defined in its configuration.
  259.  
  260.    Network administrators may configure a scope region whenever local
  261.    multicast scope is required. In addition, an administrator may con-
  262.    figure overlapping scope regions (networks can be in multiple scope
  263.    regions) where convenient, with the only limitations being that a
  264.    scope region must be connected (there must be a path between any two
  265.    nodes within a scope region that doesn't leave that region), and con-
  266.    vex (i.e., no path between any two points in the region can cross a
  267.    region boundary). Finally, as mentioned above, an important con-
  268.    straint on the configuration of local scopes is that the local scope
  269.    must not span any other boundary.
  270.  
  271.    Finally, note that any scope boundary is a boundary for the Local
  272.    Scope.  This implies that packets sent to groups in the 239.255/16
  273.    range must not be forwarded across any link with any scoped boundary
  274.    defined. That is, setting a boundary on a link for any prefix must
  275.  
  276.  
  277.  
  278. Expires October 1997                                            [Page 5]
  279.  
  280.  
  281.  
  282.  
  283.  
  284. INTERNET-DRAFT    Administratively Scoped IP Multicast        April 1997
  285.  
  286.  
  287.    also set a boundary on that link for the local scope prefix.
  288.  
  289.  
  290.  
  291. Example: DVMRP
  292.  
  293.  
  294.    DVMRP [DVMRP] implementations could be extended to support a boundary
  295.    attribute in the interface configuration [ASMA]. The boundary attri-
  296.    bute that includes a prefix and mask, and has the semantics that
  297.    packets matching the prefix and mask do not not pass the boundary. As
  298.    mentioned above, the implementation would also prune the boundary.
  299.  
  300. Security Considerations
  301.  
  302.    While security considerations are not explicitly discussed in this
  303.    memo, it is important to note that a boundary router as described
  304.    here should not be considered to provide any kind of firewall func-
  305.    tionality.
  306.  
  307. References
  308.  
  309.  
  310.       [ASMA]    V. Jacobson,  S. Deering, "Administratively Scoped IP
  311.                 Multicast", , presented at the 30th IETF, Toronto,
  312.                 Canada, 25 July 1994.
  313.  
  314.       [DVMRP]   T. Pusateri, "Distance Vector Multicast Routing
  315.                 Protocol", draft-ietf-idmr-dvmrp-v3-03, September,
  316.                 1996.
  317.  
  318.       [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
  319.                 Architecture", RFC1884, December 1995.
  320.  
  321.       [PIMSM]   Estrin, D, et. al., "Protocol Independent Multicast
  322.                 Sparse Mode (PIM-SM): Protocol Specification",
  323.                 draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1996.
  324.  
  325.  
  326. Author's Address
  327.  
  328.    David Meyer
  329.    Advanced Network Technology Center
  330.    University of Oregon
  331.    1225 Kincaid St.
  332.  
  333.  
  334.  
  335. Expires October 1997                                            [Page 6]
  336.  
  337.  
  338.  
  339.  
  340.  
  341. INTERNET-DRAFT    Administratively Scoped IP Multicast        April 1997
  342.  
  343.  
  344.    Eugene, OR 97403
  345.  
  346.    phone:  +1 541.346.1747
  347.    email:  meyer@antc.uoregon.edu
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392. Expires October 1997                                            [Page 7]
  393.  
  394.  
  395.