draft-ietf-mboned-addrarch-01.txt | draft-ietf-mboned-addrarch-02.txt | |||
---|---|---|---|---|
Internet Engineering Task Force P. Savola | Internet Engineering Task Force P. Savola | |||
Internet-Draft CSC/FUNET | Internet-Draft CSC/FUNET | |||
Obsoletes: 2908,2909 (if approved) February 18, 2005 | Obsoletes: 2776,2908,2909 (if August 8, 2005 | |||
Expires: August 19, 2005 | approved) | |||
Expires: February 9, 2006 | ||||
Overview of the Internet Multicast Addressing Architecture | Overview of the Internet Multicast Addressing Architecture | |||
draft-ietf-mboned-addrarch-01.txt | draft-ietf-mboned-addrarch-02.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is subject to all provisions | By submitting this Internet-Draft, each author represents that any | |||
of Section 3 of RFC 3667. By submitting this Internet-Draft, each | applicable patent or other IPR claims of which he or she is aware | |||
author represents that any applicable patent or other IPR claims of | have been or will be disclosed, and any of which he or she becomes | |||
which he or she is aware have been or will be disclosed, and any of | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
which he or she become aware will be disclosed, in accordance with | ||||
RFC 3668. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as | other groups may also distribute working documents as Internet- | |||
Internet-Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on August 19, 2005. | This Internet-Draft will expire on February 9, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
Abstract | Abstract | |||
The lack of up-to-date documentation on IP multicast address | The lack of up-to-date documentation on IP multicast address | |||
allocation and assignment procedures has caused a great deal of | allocation and assignment procedures has caused a great deal of | |||
confusion. To clarify the situation, this memo describes the | confusion. To clarify the situation, this memo describes the | |||
allocation and assignment techniques and mechanisms currently (as of | allocation and assignment techniques and mechanisms currently (as of | |||
this writing) in use. | this writing) in use. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1 Terminology: Allocation or Assignment . . . . . . . . . . 3 | 1.1 Terminology: Allocation or Assignment . . . . . . . . . . 3 | |||
2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 | 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 3 | |||
2.1 Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 | 2.1 Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1.1 GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 | 2.1.1 GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 | |||
2.1.2 Unicast-prefix -based Allocation . . . . . . . . . . . 4 | 2.1.2 Unicast-prefix -based Allocation . . . . . . . . . . . 4 | |||
2.2 Scope-relative Allocation . . . . . . . . . . . . . . . . 5 | 2.2 Scope-relative Allocation . . . . . . . . . . . . . . . . 5 | |||
2.3 Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 | 2.3 Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 | |||
2.4 Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 | 2.4 Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 | 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 | |||
3.1 Derived Assignment . . . . . . . . . . . . . . . . . . . . 6 | 3.1 Derived Assignment . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2 SSM Assignment inside the Node . . . . . . . . . . . . . . 7 | 3.2 SSM Assignment inside the Node . . . . . . . . . . . . . . 7 | |||
3.3 Manually Configured Assignment . . . . . . . . . . . . . . 7 | 3.3 Manually Configured Assignment . . . . . . . . . . . . . . 7 | |||
3.4 Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 | 3.4 Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 | |||
3.5 Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 | 3.5 Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 | |||
4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 | 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 | |||
4.1 Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9 | 4.1 Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2 Address Assignment . . . . . . . . . . . . . . . . . . . . 10 | 4.2 Address Assignment . . . . . . . . . . . . . . . . . . . . 10 | |||
4.3 Future Actions . . . . . . . . . . . . . . . . . . . . . . 10 | 4.3 Future Actions . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 | 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
8.2 Informative References . . . . . . . . . . . . . . . . . . 12 | 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 | A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
B. Multicast Address Discovery . . . . . . . . . . . . . . . . . 15 | A.1 Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 | |||
Intellectual Property and Copyright Statements . . . . . . . . 16 | Intellectual Property and Copyright Statements . . . . . . . . 16 | |||
1. Introduction | 1. Introduction | |||
Good, up-to-date documentation of IP multicast is close to | Good, up-to-date documentation of IP multicast is close to non- | |||
non-existent. Particularly, this is an issue with multicast address | existent. Particularly, this is an issue with multicast address | |||
allocations (to networks and sites) and assignments (to hosts and | allocations (to networks and sites) and assignments (to hosts and | |||
applications). This problem is stressed by the fact that there | applications). This problem is stressed by the fact that there | |||
exists confusing or misleading documentation on the subject | exists confusing or misleading documentation on the subject | |||
[RFC2908]. The consequence is that those who wish to learn of IP | [RFC2908]. The consequence is that those who wish to learn of IP | |||
multicast and how the addressing works do not get a clear view of the | multicast and how the addressing works do not get a clear view of the | |||
current situation. | current situation. | |||
The aim of this document is to provide a brief overview of multicast | The aim of this document is to provide a brief overview of multicast | |||
addressing and allocation techniques. The term 'addressing | addressing and allocation techniques. The term 'addressing | |||
architecture' refers to the set of addressing mechanisms and methods | architecture' refers to the set of addressing mechanisms and methods | |||
in an informal manner. | in an informal manner. | |||
It is important to note that Source-specific Multicast (SSM) | It is important to note that Source-specific Multicast (SSM) | |||
[I-D.ietf-ssm-arch] does not have these addressing problems; hence, | [I-D.ietf-ssm-arch] does not have these addressing problems; hence, | |||
this document focuses on Any Source Multicast (ASM) model. The | this document focuses on Any Source Multicast (ASM) model. | |||
applicability of SSM has been briefly discussed in | ||||
[I-D.ietf-mboned-ipv6-multicast-issues]. | ||||
This memo obsoletes RFC 2908 and RFC 2909 and re-classifies them | This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them | |||
Historic. | Historic. | |||
1.1 Terminology: Allocation or Assignment | 1.1 Terminology: Allocation or Assignment | |||
Almost all multicast documents and many other RFCs (such as DHCPv4 | Almost all multicast documents and many other RFCs (such as DHCPv4 | |||
[RFC2131] and DHCPv6 [RFC3315]) have used the terms address | [RFC2131] and DHCPv6 [RFC3315]) have used the terms address | |||
"allocation" and "assignment" interchangeably. However, the operator | "allocation" and "assignment" interchangeably. However, the operator | |||
and address management communities use these for two conceptually | and address management communities use these for two conceptually | |||
different processes. | different processes. | |||
In unicast operations, address allocations refer to leasing a large | In unicast operations, address allocations refer to leasing a large | |||
block of addresses from Internet Assigned Numbers Authority (IANA) to | block of addresses from Internet Assigned Numbers Authority (IANA) to | |||
a Regional Internet Registry (RIR), from RIR to a Local Internet | a Regional Internet Registry (RIR) or from RIR to a Local Internet | |||
Registry (LIR) possibly through a National Internet Registry (NIR). | Registry (LIR) possibly through a National Internet Registry (NIR). | |||
Address assignments, on the other hand, are the leases of smaller | Address assignments, on the other hand, are the leases of smaller | |||
address blocks or even single addresses to the end-user sites or | address blocks or even single addresses to the end-user sites or end- | |||
end-users themselves. | users themselves. | |||
Therefore, in this memo, we will separate the two different | Therefore, in this memo, we will separate the two different | |||
functions: "allocation" describes how larger blocks of addresses are | functions: "allocation" describes how larger blocks of addresses are | |||
obtained by the network operators, and "assignment" describes how | obtained by the network operators, and "assignment" describes how | |||
applications, nodes or sets of nodes obtain a multicast address for | applications, nodes or sets of nodes obtain a multicast address for | |||
their use. | their use. | |||
2. Multicast Address Allocation | 2. Multicast Address Allocation | |||
Multicast address allocation, i.e., how a network operator might be | Multicast address allocation, i.e., how a network operator might be | |||
able to obtain a larger block of addresses, can be handled in a | able to obtain a larger block of addresses, can be handled in a | |||
number of ways as described below. | number of ways as described below. | |||
Note that these are all only pertinent to ASM -- SSM requires no | Note that these are all only pertinent to ASM -- SSM requires no | |||
address block allocation because the group address has only local | address block allocation because the group address has only local | |||
significance (however, the address assignment inside the node is | significance (however, we discuss the address assignment inside the | |||
still an issue discussed in Section 3.2). | node in Section 3.2). | |||
2.1 Derived Allocation | 2.1 Derived Allocation | |||
Derived allocations take the unicast prefix or some other properties | Derived allocations take the unicast prefix or some other properties | |||
of the network to determine unique multicast address allocations. | of the network to determine unique multicast address allocations. | |||
2.1.1 GLOP Allocation | 2.1.1 GLOP Allocation | |||
GLOP address allocation [RFC3180] inserts the 16-bit public | GLOP address allocation [RFC3180] inserts the 16-bit public | |||
Autonomous System (AS) number in the middle of the IPv4 multicast | Autonomous System (AS) number in the middle of the IPv4 multicast | |||
skipping to change at page 4, line 44 | skipping to change at page 4, line 40 | |||
tied to any prefix but to routing domains, so they cannot be used or | tied to any prefix but to routing domains, so they cannot be used or | |||
calculated automatically. | calculated automatically. | |||
2.1.2 Unicast-prefix -based Allocation | 2.1.2 Unicast-prefix -based Allocation | |||
RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first | RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first | |||
bits of an IPv6 unicast address in the prefix part of the IPv6 | bits of an IPv6 unicast address in the prefix part of the IPv6 | |||
multicast address, leaving at least 32 bits of group-id space | multicast address, leaving at least 32 bits of group-id space | |||
available after the prefix mapping. | available after the prefix mapping. | |||
A similar mapping has been proposed for IPv4 | A similar mapping has been proposed for IPv4 [I-D.ietf-mboned-ipv4- | |||
[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low | uni-based-mcast], but it provides a rather low amount of addresses | |||
amount of addresses (e.g., 1 per an IPv4 /24 block). While there | (e.g., 1 per an IPv4 /24 block). While there exist large networks | |||
exist large networks without an AS number of their own, this has not | without an AS number of their own, this has not been seen to add | |||
been seen to add sufficient value compared to GLOP addressing. | sufficient value compared to GLOP addressing. | |||
The IPv6 unicast-prefix -based allocations are an extremely useful | The IPv6 unicast-prefix -based allocations are an extremely useful | |||
way to allow each network operator, even each subnet, obtain | way to allow each network operator, even each subnet, obtain | |||
multicast addresses easily, through an easy computation. Further, as | multicast addresses easily, through an easy computation. Further, as | |||
the IPv6 multicast header also includes the scope value [RFC3513], | the IPv6 multicast header also includes the scope value [RFC3513], | |||
multicast groups of smaller scope can also be used with the same | multicast groups of smaller scope can also be used with the same | |||
mapping. | mapping. | |||
The IPv6 Embedded RP technique [RFC3956], used with Protocol | The IPv6 Embedded RP technique [RFC3956], used with Protocol | |||
Independent Multicast - Sparse Mode (PIM-SM), further leverages the | Independent Multicast - Sparse Mode (PIM-SM), further leverages the | |||
skipping to change at page 5, line 37 | skipping to change at page 5, line 34 | |||
the IPv6 multicast address prefix [RFC3513]. | the IPv6 multicast address prefix [RFC3513]. | |||
As IPv6 scope-relative allocations can be handled with unicast-prefix | As IPv6 scope-relative allocations can be handled with unicast-prefix | |||
-based multicast addressing as described in Section 2.1.2, and there | -based multicast addressing as described in Section 2.1.2, and there | |||
is no need for separate scope-relative allocations, we'll just | is no need for separate scope-relative allocations, we'll just | |||
discuss IPv4 in this section. | discuss IPv4 in this section. | |||
The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to | The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to | |||
Local Scope (239.255.0.0/16) and Organization Local Scope | Local Scope (239.255.0.0/16) and Organization Local Scope | |||
(239.192.0.0/14); other parts of the administrative scopes are either | (239.192.0.0/14); other parts of the administrative scopes are either | |||
reserved for expansion or undefined [RFC2365]. | reserved for expansion or undefined [RFC2365]. However, RFC 2365 is | |||
ambiguous as to whether it's the enterprises or the IETF who are | ||||
allowed to expand the space. | ||||
Topologies which act under a single administration can easily use the | Topologies which act under a single administration can easily use the | |||
scoped multicast addresses for their internal groups. Groups which | scoped multicast addresses for their internal groups. Groups which | |||
need to be shared between multiple routing domains (but not | need to be shared between multiple routing domains (but not | |||
propagated through Internet) are more problematic and typically need | propagated through Internet) are more problematic and typically need | |||
an assignment of a global multicast address because their scope is | an assignment of a global multicast address because their scope is | |||
undefined. | undefined. | |||
There is a large number of multicast applications (such as "Norton | There is a large number of multicast applications (such as "Norton | |||
Ghost") which are restricted either to a link or a site, but it is | Ghost") which are restricted either to a link or a site, but it is | |||
extremely undesirable to propagate them further (either to the rest | extremely undesirable to propagate them further (either to the rest | |||
of the site, or beyond the site). Typically many such applications | of the site, or beyond the site). Typically many such applications | |||
have been given a static IANA address assignment; this makes it | have been given a static IANA address assignment; this makes it | |||
challenging to implement proper propagation limiting -- which could | challenging to implement proper propagation limiting -- which could | |||
be easier if such applications could have been assigned specific | be easier if such applications could have been assigned specific | |||
scope-relative addresses instead. This is an area of further future | scope-relative addresses instead. This is an area of further future | |||
work -- it might be able to mitigate this issue if there was more | work. | |||
coordination inside the scope-relative allocation block. | ||||
There has also been work on protocol to automatically discover | ||||
multicast scope zones [RFC2776], but it has never been seriously | ||||
implemented or deployed. | ||||
2.3 Static IANA Allocation | 2.3 Static IANA Allocation | |||
In some rare cases, some organizations may have been able to obtain | In some rare cases, some organizations may have been able to obtain | |||
static multicast address allocations directly from IANA. Typically | static multicast address allocations (of up to 256 addresses) | |||
these have been meant as a block of static assignments to multicast | directly from IANA. Typically these have been meant as a block of | |||
applications, as described in Section 3.4. In principle, IANA does | static assignments to multicast applications, as described in | |||
not allocate multicast address blocks to the operators but GLOP or | Section 3.4. In principle, IANA does not allocate multicast address | |||
Unicast-prefix -based allocations should be used instead. | blocks to the operators but GLOP or Unicast-prefix -based allocations | |||
should be used instead. | ||||
2.4 Dynamic Allocation | 2.4 Dynamic Allocation | |||
RFC 2908 [RFC2908] proposed three different layers of multicast | RFC 2908 [RFC2908] proposed three different layers of multicast | |||
address allocation and assignment, where layers 3 (inter-domain | address allocation and assignment, where layers 3 (inter-domain | |||
allocation) and layer 2 (intra-domain allocation) could be applicable | allocation) and layer 2 (intra-domain allocation) could be applicable | |||
here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an | here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an | |||
example of the former, and Multicast Address Allocation Protocol | example of the former, and Multicast Address Allocation Protocol | |||
(AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest | (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest | |||
and technical problems) is an example of the latter. | and technical problems) is an example of the latter. | |||
Both of the proposed allocation protocols were quite complex, and | Both of the proposed allocation protocols were quite complex, and | |||
have never been deployed or seriously implemented. | have never been deployed or seriously implemented. | |||
It can be concluded that there are no dynamic multicast address | It can be concluded that there are no dynamic multicast address | |||
allocation protocols, and other methods such as GLOP or | allocation protocols, and other methods such as GLOP or unicast- | |||
unicast-prefix -based addressing should be used instead. | prefix -based addressing should be used instead. | |||
3. Multicast Address Assignment | 3. Multicast Address Assignment | |||
For multicast address assignment, i.e., how an application learns the | For multicast address assignment, i.e., how an application learns the | |||
address it can use, or a node (or a set of nodes) learns an address | address it can use, or a node (or a set of nodes) learns an address | |||
it could use for an application, has a number of options as described | it could use for an application, has a number of options as described | |||
below. | below. | |||
Any IPv6 address assignment method should be aware of the guidelines | Any IPv6 address assignment method should be aware of the guidelines | |||
for the assignment of the group-IDs for IPv6 multicast addresses | for the assignment of the group-IDs for IPv6 multicast addresses | |||
[RFC3307]. | [RFC3307]. | |||
3.1 Derived Assignment | 3.1 Derived Assignment | |||
There are significantly fewer options for derived address assignment | There are significantly fewer options for derived address assignment | |||
compared to derived allocation. Derived multicast assignment is only | compared to derived allocation. Derived multicast assignment has | |||
being specified for IPv6 link-scoped multicast | only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6- | |||
[I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the | link-scoped-mcast], where the EUI64 is embedded in the multicast | |||
multicast address, providing a node with unique multicast addresses | address, providing a node with unique multicast addresses for link- | |||
for link-local ASM communications. | local ASM communications. | |||
3.2 SSM Assignment inside the Node | 3.2 SSM Assignment inside the Node | |||
While the SSM multicast addresses have only local (to the node) | While the SSM multicast addresses have only local (to the node) | |||
significance, there is still a minor issue on how to assign the | significance, there is still a minor issue on how to assign the | |||
addresses between the applications running on the same node (or more | addresses between the applications running on the same node (or more | |||
precisely, an IP address). | precisely, an IP address). | |||
This assignment is not considered to be a problem because typically | This assignment is not considered to be a problem because typically | |||
the addresses for the applications are selected manually or | the addresses for the applications are selected manually or | |||
statically, but if done using an API, the API could check that the | statically, but if done using an Application Programming Interface | |||
addresses do not conflict prior to assigning one. | (API), the API could check that the addresses do not conflict prior | |||
to assigning one. | ||||
3.3 Manually Configured Assignment | 3.3 Manually Configured Assignment | |||
With manually configured assignment, the network operator which has a | With manually configured assignment, the network operator who has a | |||
multicast address prefix assigns the multicast group addresses to the | multicast address prefix assigns the multicast group addresses to the | |||
requesting nodes using a manual process. | requesting nodes using a manual process. | |||
Typically the user or administrator which wants to use a multicast | Typically the user or administrator which wants to use a multicast | |||
address for particular application requests an address from the | address for particular application requests an address from the | |||
network operator using phone, email, or similar means, and the | network operator using phone, email, or similar means, and the | |||
network operator provides the user with a multicast address. Then | network operator provides the user with a multicast address. Then | |||
the user/administrator of the node or application manually configures | the user/administrator of the node or application manually configures | |||
the application to use the assigned multicast address. | the application to use the assigned multicast address. | |||
skipping to change at page 7, line 46 | skipping to change at page 7, line 49 | |||
group is small, as each participant has to be manually configured. | group is small, as each participant has to be manually configured. | |||
This is the most commonly used technique when the multicast | This is the most commonly used technique when the multicast | |||
application does not have a static IANA assignment. | application does not have a static IANA assignment. | |||
3.4 Static IANA Assignment | 3.4 Static IANA Assignment | |||
In contrast to manually configured assignment, as described above, | In contrast to manually configured assignment, as described above, | |||
static IANA assignment refers to getting a globally unique assignment | static IANA assignment refers to getting a globally unique assignment | |||
for the particular application directly from IANA. Guidelines for | for the particular application directly from IANA. Guidelines for | |||
IANA are described in [I-D.ietf-mboned-rfc3171bis]. | IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. | |||
This is seen as lucrative because it's the simplest approach for | This is seen as lucrative because it's the simplest approach for | |||
application developers because they can then hard-code the multicast | application developers because they can then hard-code the multicast | |||
address, requiring no lease of the usable multicast address, and | address. Hard-coding requires no lease of the usable multicast | |||
likewise the client applications do not need to perform any kind of | address, and likewise the client applications do not need to perform | |||
service discovery (but depending on hard-coded addresses). However, | any kind of service discovery (but depending on hard-coded | |||
this is a bad approach architecturally, as we should focus on | addresses). However, this is a bad approach architecturally, as we | |||
enhancing and deploying service discovery and address assignment (as | should focus on enhancing and deploying service discovery and address | |||
needed) instead of encouraging a "land-grab" of multicast addresses. | assignment (as needed) instead of encouraging a "land-grab" of | |||
multicast addresses. | ||||
[RFC3138] describes how to handle those GLOP assignments (called | ||||
"eGLOP") which use the private-use AS number space (233.252.0.0/14). | ||||
It was envisioned that IANA would delegate the responsibility of | ||||
these to RIRs, which would assign or allocate addresses as best | ||||
seemed fit. However, this was never carried out as IANA did not make | ||||
these allocations to RIRs due to procedural reasons. | ||||
In summary, there are applications which have obtained a static IANA | In summary, there are applications which have obtained a static IANA | |||
assignment, some of which are really needed, and some of which | assignment, some of which are really needed, and some of which | |||
probably should not have been granted. | probably should not have been granted. | |||
3.5 Dynamic Assignments | 3.5 Dynamic Assignments | |||
The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from | The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from | |||
Multicast Address Allocation Servers (MAAS) to applications and | Multicast Address Allocation Servers (MAAS) to applications and | |||
nodes, with Multicast Address Dynamic Client Allocation Protocol | nodes, with Multicast Address Dynamic Client Allocation Protocol | |||
(MADCAP) [RFC2730] as examples. Since then, there has been a | (MADCAP) [RFC2730] as an example. Since then, there has been a | |||
proposal for DHCPv6 assignment | proposal for DHCPv6 assignment [I-D.jdurand-assign-addr-ipv6- | |||
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. | multicast-dhcpv6]. | |||
Based on a multicast prefix, it would be rather straightforward to | It would be rather straightforward to deploy a dynamic assignment | |||
deploy a dynamic assignment protocol which would lease group | protocol which would lease group addresses based on a multicast | |||
addresses to the applications wishing to use multicast. For example, | prefix to the applications wishing to use multicast. For example, | |||
only few have implemented MADCAP, and it's not significantly | only few have implemented MADCAP, and it's not significantly | |||
deployed. Moreover, it is not clear how widely for example the APIs | deployed. Moreover, it is not clear how widely for example the APIs | |||
for communication between the multicast application and the MADCAP | for communication between the multicast application and the MADCAP | |||
client operating at the host have been implemented [RFC2771]. | client operating at the host have been implemented [RFC2771]. | |||
An entirely different approach is Session Announcement Protocol (SAP) | An entirely different approach is Session Announcement Protocol (SAP) | |||
[RFC2974]. In addition to advertising global multicast sessions, the | [RFC2974]. In addition to advertising global multicast sessions, the | |||
protocol also has associated ranges of addresses for both IPv4 and | protocol also has associated ranges of addresses for both IPv4 and | |||
IPv6 which can be used by SAP-aware applications to create new groups | IPv6 which can be used by SAP-aware applications to create new groups | |||
and new group addresses. It is a rather tedious process to create a | and new group addresses. Creating a session (and obtaining an | |||
session (and obtain an address) this way which is why it isn't done | address) is a rather tedious process which is why it isn't done all | |||
all that often. (Note that the IPv6 SAP address is unroutable in the | that often. (Note that the IPv6 SAP address is unroutable in the | |||
inter-domain multicast.) | inter-domain multicast.) | |||
A conclusion about dynamic assignment protocols is that: | A conclusion about dynamic assignment protocols is that: | |||
1. multicast is not significantly attractive in the first place, | 1. multicast is not significantly attractive in the first place, | |||
2. very many applications have a static IANA assignment and thus | 2. very many applications have a static IANA assignment and thus | |||
require no dynamic or manual assignment, | require no dynamic or manual assignment, | |||
3. those that cannot be easily satisfied with IANA or manual | 3. those that cannot be easily satisfied with IANA or manual | |||
assignment (i.e., where dynamic assignment would be desirable) | assignment (i.e., where dynamic assignment would be desirable) | |||
are rather marginal, or | are rather marginal, or | |||
4. that there are other gaps why dynamic assignments are not seen as | 4. that there are other gaps why dynamic assignments are not seen as | |||
a useful approach (for example, issues related to service | a useful approach (for example, issues related to service | |||
discovery/rendezvous). | discovery/rendezvous). | |||
In consequence, more work on rendezvous/service discovery will be | In consequence, more work on rendezvous/service discovery would be | |||
needed to make dynamic assignment more useful. | needed to make dynamic assignments more useful. | |||
4. Summary and Future Directions | 4. Summary and Future Directions | |||
This section summarizes the mechanisms and analysis discussed in this | This section summarizes the mechanisms and analysis discussed in this | |||
memo, and presents some potential future directions. | memo, and presents some potential future directions. | |||
4.1 Prefix Allocation | 4.1 Prefix Allocation | |||
Summary of prefix allocation methods for ASM is in Figure 1. | Summary of prefix allocation methods for ASM is in Figure 1. | |||
skipping to change at page 10, line 15 | skipping to change at page 10, line 21 | |||
4.2 Address Assignment | 4.2 Address Assignment | |||
Summary of address assignment methods is in Figure 2. | Summary of address assignment methods is in Figure 2. | |||
+-------+--------------------------------+----------+----------+ | +-------+--------------------------------+----------+----------+ | |||
| Sect. | Address assignment method | IPv4 | IPv6 | | | Sect. | Address assignment method | IPv4 | IPv6 | | |||
+-------+--------------------------------+----------+----------+ | +-------+--------------------------------+----------+----------+ | |||
| 3.1 | Derived: link-scope addresses | No | Yes | | | 3.1 | Derived: link-scope addresses | No | Yes | | |||
| 3.2 | SSM (inside the node) | Yes | Yes | | | 3.2 | SSM (inside the node) | Yes | Yes | | |||
| 3.3 | Manual assignment | Yes | Yes | | | 3.3 | Manual assignment | Yes | Yes | | |||
| 3.4 | Static IANA assignment |LastResort|LastResort| | | 3.4 | Static IANA/RIR assignment |LastResort|LastResort| | |||
| 3.5 | Dynamic assignment protocols | Yes | Yes | | | 3.5 | Dynamic assignment protocols | Yes | Yes | | |||
+-------+--------------------------------+----------+----------+ | +-------+--------------------------------+----------+----------+ | |||
Figure 2 | Figure 2 | |||
o Manually configured assignment is what's typically done today, and | o Manually configured assignment is what's typically done today, and | |||
works to a sufficient degree in smaller scale. | works to a sufficient degree in smaller scale. | |||
o Static IANA assignment has been done extensively in the past, but | o Static IANA assignment has been done extensively in the past, but | |||
it needs to be tightened down to prevent problems caused by | it needs to be tightened down to prevent problems caused by "land- | |||
"land-grabbing". | grabbing". | |||
o Dynamic assignment, e.g., using MADCAP have been implemented, but | o Dynamic assignment, e.g., using MADCAP have been implemented, but | |||
there is no wide deployment, so a solution is there -- but either | there is no wide deployment, so a solution is there. However, | |||
there are other gaps in the multicast architecture or there is no | either there are other gaps in the multicast architecture or there | |||
need for it in the first place, when manual configuration is | is no sufficient demand for it in the first place when manual and | |||
possible, and static IANA assignments are still there. | static IANA assignments are available. Assignments using SAP also | |||
Assignments using SAP also exist but are not common; global SAP | exist but are not common; global SAP assignment is unfeasible with | |||
assignment is unfeasible with IPv6. | IPv6. | |||
o Derived assignments are only applicable in a fringe case of | o Derived assignments are only applicable in a fringe case of link- | |||
link-scoped multicast. | scoped multicast. | |||
4.3 Future Actions | 4.3 Future Actions | |||
o Multicast address discovery/"rendezvous" needs to be analyzed at | o Multicast address discovery/"rendezvous" needs to be analyzed at | |||
more length, and an adequate solution provided; the result also | more length, and an adequate solution provided; the result also | |||
needs to be written down to be shown to the IANA static assignment | needs to be written down to be shown to the IANA static assignment | |||
requestors. See [I-D.savola-mboned-address-discovery-problems] | requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. | |||
and Appendix B for more. | ||||
o IPv6 multicast DAD and/or multicast prefix communication | o IPv6 multicast DAD and/or multicast prefix communication | |||
mechanisms should be analyzed (e.g., | mechanisms should be analyzed (e.g., | |||
[I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, | [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, | |||
and specify if yes. | and specify if yes. | |||
o The IETF should consider whether to specify more ranges of the | o The IETF should consider whether to specify more ranges of the | |||
IPv4 scope-relative address space for static allocation for | IPv4 scope-relative address space for static allocation for | |||
applications which should not be routed over the Internet (such as | applications which should not be routed over the Internet (such as | |||
backup software, etc. -- so that these wouldn't need to use | backup software, etc. -- so that these wouldn't need to use global | |||
global addresses which should never leak in any case). | addresses which should never leak in any case). | |||
o The IETF should seriously consider its static IANA allocations | o The IETF should seriously consider its static IANA allocations | |||
policy, e.g., "locking it down" to a stricter policy (like "IETF | policy, e.g., "locking it down" to a stricter policy (like "IETF | |||
Consensus") and looking at developing the discovery/rendezvous | Consensus") and looking at developing the discovery/rendezvous | |||
functions, if necessary. | functions, if necessary. | |||
5. Acknowledgements | 5. Acknowledgements | |||
Tutoring a couple multicast-related papers, the latest by Kaarle | Tutoring a couple multicast-related papers, the latest by Kaarle | |||
Ritvanen [RITVANEN] convinced the author that the up-to-date | Ritvanen [RITVANEN] convinced the author that the up-to-date | |||
skipping to change at page 11, line 38 | skipping to change at page 11, line 44 | |||
6. IANA Considerations | 6. IANA Considerations | |||
This memo includes no request to IANA, but as the allocation and | This memo includes no request to IANA, but as the allocation and | |||
assignment of multicast addresses are related to IANA functions, it | assignment of multicast addresses are related to IANA functions, it | |||
wouldn't hurt if the IANA reviewed this entire memo. | wouldn't hurt if the IANA reviewed this entire memo. | |||
IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still | IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still | |||
apply to the administratively scoped prefixes. | apply to the administratively scoped prefixes. | |||
IANA may be interested in reviewing the accuracy of the statement on | ||||
eGLOP address assignments in Section 3.4. | ||||
(RFC-editor: please remove this section at publication.) | (RFC-editor: please remove this section at publication.) | |||
7. Security Considerations | 7. Security Considerations | |||
This memo only describes different approaches to allocating and | This memo only describes different approaches to allocating and | |||
assigning multicast addresses, and this has no security | assigning multicast addresses, and this has no security | |||
considerations; the security analysis of the mentioned protocols is | considerations; the security analysis of the mentioned protocols is | |||
out of scope of this memo. | out of scope of this memo. | |||
Obviously, especially the dynamic assignment protocols are inherently | Obviously, especially the dynamic assignment protocols are inherently | |||
vulnerable to resource exhaustion attacks, as discussed e.g., in | vulnerable to resource exhaustion attacks, as discussed e.g., in | |||
[RFC2730]. | [RFC2730]. | |||
8. References | 8. References | |||
8.1 Normative References | 8.1 Normative References | |||
[I-D.ietf-ipv6-link-scoped-mcast] | [I-D.ietf-ipv6-link-scoped-mcast] | |||
Park, J., "Link Scoped IPv6 Multicast Addresses", | Park, J., "A Method for Generating Link Scoped IPv6 | |||
Internet-Draft draft-ietf-ipv6-link-scoped-mcast-08, | Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09 | |||
December 2004. | (work in progress), July 2005. | |||
[I-D.ietf-mboned-rfc3171bis] | ||||
Albanna, Z., Almeroth, K., Cotton, M. and D. Meyer, "IANA | ||||
Guidelines for IPv4 Multicast Address Assignments", | ||||
Internet-Draft draft-ietf-mboned-rfc3171bis-02, March | ||||
2004. | ||||
[I-D.ietf-ssm-arch] | [I-D.ietf-ssm-arch] | |||
Holbrook, H. and B. Cain, "Source-Specific Multicast for | Holbrook, H. and B. Cain, "Source-Specific Multicast for | |||
IP", Internet-Draft draft-ietf-ssm-arch-06, September | IP", draft-ietf-ssm-arch-06 (work in progress), | |||
2004. | September 2004. | |||
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, | [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, | |||
RFC 2365, July 1998. | RFC 2365, July 1998. | |||
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, | ||||
"IANA Guidelines for IPv4 Multicast Address Assignments", | ||||
BCP 51, RFC 3171, August 2001. | ||||
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", | [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", | |||
BCP 53, RFC 3180, September 2001. | BCP 53, RFC 3180, September 2001. | |||
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 | [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 | |||
Multicast Addresses", RFC 3306, August 2002. | Multicast Addresses", RFC 3306, August 2002. | |||
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast | [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast | |||
Addresses", RFC 3307, August 2002. | Addresses", RFC 3307, August 2002. | |||
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 | [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 | |||
(IPv6) Addressing Architecture", RFC 3513, April 2003. | (IPv6) Addressing Architecture", RFC 3513, April 2003. | |||
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous | [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous | |||
Point (RP) Address in an IPv6 Multicast Address", | Point (RP) Address in an IPv6 Multicast Address", | |||
RFC 3956, November 2004. | RFC 3956, November 2004. | |||
8.2 Informative References | 8.2 Informative References | |||
[I-D.iab-dns-choices] | ||||
Faltstrom, P. and R. Austein, "Design Choices When | ||||
Expanding DNS", Internet-Draft draft-iab-dns-choices-00, | ||||
October 2004. | ||||
[I-D.ietf-malloc-aap] | [I-D.ietf-malloc-aap] | |||
Handley, M. and S. Hanna, "Multicast Address Allocation | Handley, M. and S. Hanna, "Multicast Address Allocation | |||
Protocol (AAP)", June 2000. | Protocol (AAP)", June 2000. | |||
[I-D.ietf-mboned-addrdisc-problems] | ||||
Savola, P., "Lightweight Multicast Address Discovery | ||||
Problem Space", draft-ietf-mboned-addrdisc-problems-00 | ||||
(work in progress), March 2005. | ||||
[I-D.ietf-mboned-ipv4-uni-based-mcast] | [I-D.ietf-mboned-ipv4-uni-based-mcast] | |||
Thaler, D., "Unicast-Prefix-based IPv4 Multicast | Thaler, D., "Unicast-Prefix-based IPv4 Multicast | |||
Addresses", | Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 | |||
Internet-Draft draft-ietf-mboned-ipv4-uni-based-mcast-02, | (work in progress), October 2004. | |||
October 2004. | ||||
[I-D.ietf-mboned-ipv6-multicast-issues] | [I-D.ietf-mboned-rfc3171bis] | |||
Savola, P., "IPv6 Multicast Deployment Issues", | Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA | |||
Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01, | Guidelines for IPv4 Multicast Address Assignments", | |||
September 2004. | draft-ietf-mboned-rfc3171bis-02 (work in progress), | |||
March 2004. | ||||
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] | [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] | |||
Durand, J., "IPv6 multicast address assignment with | Durand, J., "IPv6 multicast address assignment with | |||
DHCPv6", | DHCPv6", | |||
, June 2004. | draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work | |||
in progress), February 2005. | ||||
[I-D.jdurand-ipv6-multicast-ra] | [I-D.jdurand-ipv6-multicast-ra] | |||
Durand, J. and P. Savola, "Route Advertisement Option for | Durand, J. and P. Savola, "Route Advertisement Option for | |||
IPv6 Multicast Prefixes", | IPv6 Multicast Prefixes", | |||
Internet-Draft draft-jdurand-ipv6-multicast-ra-00, | draft-jdurand-ipv6-multicast-ra-00 (work in progress), | |||
February 2005. | February 2005. | |||
[I-D.palet-v6ops-tun-auto-disc] | ||||
Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point | ||||
Discovery Mechanisms", | ||||
Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January | ||||
2005. | ||||
[I-D.savola-mboned-address-discovery-problems] | ||||
Savola, P., "Lightweight Multicast Address Discovery | ||||
Problem Space", | ||||
, February 2005. | ||||
[MBONED-IETF59] | [MBONED-IETF59] | |||
"MBONED WG session at IETF59", | "MBONED WG session at IETF59", | |||
<http://www.ietf.org/proceedings/04mar/172.htm>. | <http://www.ietf.org/proceedings/04mar/172.htm>. | |||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
RFC 2131, March 1997. | RFC 2131, March 1997. | |||
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, | [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, | |||
"Service Location Protocol, Version 2", RFC 2608, June | "Service Location Protocol, Version 2", RFC 2608, | |||
1999. | June 1999. | |||
[RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address | [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address | |||
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, | Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, | |||
December 1999. | December 1999. | |||
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address | [RFC2771] Finlayson, R., "An Abstract API for Multicast Address | |||
Allocation", RFC 2771, February 2000. | Allocation", RFC 2771, February 2000. | |||
[RFC2908] Thaler, D., Handley, M. and D. Estrin, "The Internet | [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope | |||
Zone Announcement Protocol (MZAP)", RFC 2776, | ||||
February 2000. | ||||
[RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet | ||||
Multicast Address Allocation Architecture", RFC 2908, | Multicast Address Allocation Architecture", RFC 2908, | |||
September 2000. | September 2000. | |||
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., | [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., | |||
Kumar, S. and D. Thaler, "The Multicast Address-Set Claim | Kumar, S., and D. Thaler, "The Multicast Address-Set Claim | |||
(MASC) Protocol", RFC 2909, September 2000. | (MASC) Protocol", RFC 2909, September 2000. | |||
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session | [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | |||
Announcement Protocol", RFC 2974, October 2000. | Announcement Protocol", RFC 2974, October 2000. | |||
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and | [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, | |||
M. Carney, "Dynamic Host Configuration Protocol for IPv6 | June 2001. | |||
(DHCPv6)", RFC 3315, July 2003. | ||||
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., | ||||
and M. Carney, "Dynamic Host Configuration Protocol for | ||||
IPv6 (DHCPv6)", RFC 3315, July 2003. | ||||
[RITVANEN] | [RITVANEN] | |||
Ritvanen, K., "Multicast Routing and Addressing", HUT | Ritvanen, K., "Multicast Routing and Addressing", HUT | |||
Report, Seminar on Internetworking, May 2004, | Report, Seminar on Internetworking, May 2004, | |||
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>. | <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>. | |||
Author's Address | Author's Address | |||
Pekka Savola | Pekka Savola | |||
CSC - Scientific Computing Ltd. | CSC - Scientific Computing Ltd. | |||
Espoo | Espoo | |||
Finland | Finland | |||
Email: psavola@funet.fi | Email: psavola@funet.fi | |||
Appendix A. Open Issues | Appendix A. Changes | |||
(This section will be removed or merged with the rest before | ||||
publication..) | ||||
o Is the case for IPv4 Unicast-Prefix Base Multicast addressing | ||||
sufficiently strong, or could those organizations just get an AS | ||||
number themselves if they really wanted to do multicast? | ||||
Appendix B. Multicast Address Discovery | ||||
[[ NOTE IN DRAFT: the intent of this section has been mostly | ||||
superceded by [I-D.savola-mboned-address-discovery-problems] and | ||||
therefore it is put in the appendix, with pending removal in the | ||||
future. | ||||
As was noted in Section 3, multicast address discovery (i.e., service | (To be removed prior to publication as an RFC.) | |||
discovery or "rendezvous") is a problem with multicast address | ||||
assignment. In particular, an acceptable mechanism (mechanisms such | ||||
as Service Location Protocol (SLP) [RFC2608] seem to have been | ||||
considered too complex) seems to be missing which the hosts wishing | ||||
to participate in a group could use to find the address of that group | ||||
[MBONED-IETF59]. | ||||
It is worth noting that as long as not deploying an address | A.1 Changes since -01 | |||
assignment and service discovery protocols/mechanisms means that one | ||||
can get a static address assignment from IANA, there is little | ||||
interest from the application developers to actually do anything | ||||
except try to get the assignment from IANA. Conclusion: if we want | ||||
to use non-IANA processes, the assignments must be either forbidden | ||||
completely, or made sufficiently difficult that it's easier for the | ||||
application developers to take another route if a feasible mechanism | ||||
is available. | ||||
There are two issues in the service discovery: | o Mention the mechanisms which haven't been so succesful: eGLOP and | |||
MZAP. | ||||
1. The session initiator being able to publish the session somehow, | o Remove the appendices on multicast address discovery (a separate | |||
and | draft now) and IPv4 unicast-prefix based multicast addressing. | |||
2. The session participants finding out about the session (rather | o Add a note on scope-relative address space and the expansion | |||
than creating their own). | ambiguity. | |||
When manually configured or static IANA assignments are used, 1) | o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt | |||
should be relatively straightforward (if something needs to be | ||||
manually configured or statically assigned, putting it e.g., in DNS | ||||
should not be a problem). However, this is still more complex for | ||||
dynamic or derived assignments because it implies that the host or | ||||
the application has the right to make that publication on its own, | ||||
rather than through a manual process by an administrator. | ||||
2) is always a challenge, but could leverage for example DNS (e.g., | o Minor editorial cleanups. | |||
by relying on using SRV records with the DNS search path, as | ||||
described in [I-D.iab-dns-choices] and | ||||
[I-D.palet-v6ops-tun-auto-disc]). | ||||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |