Network Working Group D. Thaler
INTERNET-DRAFT B. Aboba
October 22, 1999 Microsoft
Expires: April 2000
Multicast Address Allocation in Auto-Configured Networks
<draft-thaler-zeroconf-multicast-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Expires April 2000 [Page 1]
Draft Multicast Auto-Configured Networks October 1999
1. Abstract
Today, with the rapid rise of home networking, there is an
increasing need for auto-configuration mechanisms. This document
describes how small networks without a multicast address
allocation server may auto-allocate multicast addresses.
2. Introduction
The Internet Multicast Address Allocation Architecture [1]
provides a framework which includes multicast address allocation
servers (MAASs) that allocate addresses to hosts. The Multicast
Address Dynamic Client Allocation Protocol (MADCAP) [2] has been
proposed as the protocol via which hosts and servers communicate.
The Multicast Address Allocation Protocol (AAP) [3] has been
proposed as the protocol via which servers communicate with each
other to prevent allocating the same addresses. However, servers
may not be present in all environments.
Today, with the rapid rise of home networking, there is an
increasing need for auto-configuration mechanisms. This document
describes how small networks without a multicast address
allocation server may auto-allocate multicast addresses.
3. Terminology
This document uses the following terms:
Configured environment
A network area (such as the Internet or an enterprise
network) which are managed by one or more administrators
or organizations.
Zero-configuration environment
A network area consisting of devices which have no
manual configuration done to them, and are not managed
by an administrator or organization.
There are two primary zero-configuration scenarios which we
distinguish between, and between a configured environment, in this
document.
Expires April 2000 [Page 2]
Draft Multicast Auto-Configured Networks October 1999
Isolated: A group of hosts communicate as peers in a zero-
configuration environment. In this scenario, there are
no address allocation servers, and likely no routers.
Edge: In this scenario, we assume there is a router which
connects a zero-configuration environment to a
configured environment such as the Internet. In this
scenario, there are no address allocation servers
configured in the zero-configuration area, and there may
or may not be servers in the configured environment.
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to
be interpreted as described in [4].
4. Configuration requirements for small networks
In order to enable effective multicast address allocation in small
networks, the following requirements need to be met:
Allocation
A mechanism MUST be provided to allow for hosts to
allocate multicast addresses. Ideally, host behavior
should be the same in a zero-configuration environment
and in a configured environment so that transitions can
be done easily.
Isolated to Edge transition
A mechanism MUST be provided to transition between the
Isolated and Edge scenarios. This happens when a router
is added to connect an Isolated area to a configured
environment, such as when a host in an Isolated
environment dials an Internet Service Provider (ISP) and
becomes a router. Similarly, the reverse transition
occurs if the router goes down.
Isolated to Configured transition
A mechanism MUST be provided to transition between an
Isolated and a Configured environment. This occurs, for
example, in a corporate environment when a router comes
up or goes down. When a router is down, any hosts on
disconnected links may be in an Isolated environment.
Expires April 2000 [Page 3]
Draft Multicast Auto-Configured Networks October 1999
5. Auto-configuration prescription
In this section, we assume that MADCAP and AAP are the protocols
in use, since they appear to meet the requirements.
5.1. Zero-configuration host behavior
As described in [5], a host provides two services to its
applications through some API. First, it must allow applications
to enumerate the set of available multicast scopes. Second, it
must allow applications to request, renew, and release addresses,
where the scope must be specified by the application.
Note that acquiring the set of enumerated scopes does not
necessarily imply that addresses are available in each scope, only
that it is legal for an application to request an address in one.
5.1.1. Scope enumeration
To determine whether a multicast address allocation server is
available, a host SHOULD, at startup time, attempt to acquire the
list of multicast scopes available by using MADCAP's GETINFO
request as described in [2], and done periodically thereafter.
This determination MAY instead be delayed until an application
wants to enumerate scopes, at the expense of increasing the time
needed.
If any servers are found, a host should use the set of scopes
returned by the servers. In addition, if ranges are defined for
allocation of Link-Local, Node-Local, and/or Single-Source
addresses, these may be assumed as well (for example, such Link-
Local and Node-Local are currently defined in IPv6 [6], and
Single-Source is currently defined in IPv4 [7]).
If no servers are found, a host can assume that any scopes exist
which are well-known with specified ranges. These include the
Global scope, the Local scope [6], the Allocation scope [1], and
the Single-Source scope. In this situation, a host MAY also begin
passively listening to MZAP [8] messages to build up its scope
list further. (MZAP sends very low frequency reports of scopes to
listeners inside those scopes.)
Expires April 2000 [Page 4]
Draft Multicast Auto-Configured Networks October 1999
5.1.2. Address Allocation
Node-Local and Single-Source addresses can be allocated
immediately by any host. The algorithm for choosing an address is
implementation-dependent, but the address range to use MUST be the
range registered with IANA for the specified scope.
Link-Local addresses can be allocated only by hosts which
implement at least a minimal subset of AAP consisting of the ACLM
and AIU messages
For all other addresses, the following procedures apply.
If the host has recently tried to obtain the scope list, then the
host already knows whether any MAAS's are present. If it has not
tried recently, then the host can use MADCAP to discover a server
when it wants to allocate an address.
If a server is present, the host simply uses MADCAP to allocate
addresses.
If no server is present, then if the scope associated with the
request is "big" (Global, or any scope obtained from MZAP and
identified by MZAP as "big"), then no addresses may be allocated;
otherwise (if the scope is not "big") then the host MAY allocate
addresses by participating in AAP. The host MUST NOT allocate the
last 256 addresses in the range as these are reserved for scope-
relative addresses [6].
5.2. Zero-configuration router behavior
In the Edge scenario, a zero-configuration router exists, with a
link which connects to a configured environment. Here, there is
likely a well-understood distinction between the local area and
the external environment, as well as a potential requirement to be
able to scope some data to the local area. Hence, if the router
detects that it is an "Edge" router (i.e. a router in an Edge
scenario), it should instantiate a Local scope boundary on that
link.
However, before it can do this, a router must be able to
distinguish between whether it is in an Edge scenario, or in a
configured environment. This could be done in any implementation-
specific manner. For example, the router could assume it is in a
Expires April 2000 [Page 5]
Draft Multicast Auto-Configured Networks October 1999
zero-configuration environment unless it is specifically
configured otherwise. This would appear to be acceptable, since
if it is in a configured environment, the router would typically
be configured anyway.
If the router determines that it is an Edge router, the router
SHOULD instantiate a Local scope boundary and become a mini-MAAS
with behavior as follows.
5.2.1. Scope enumeration
To acquire a set of scopes, the router performs the same actions
as those described for hosts in Section 5.1.1 above, with MADCAP
queries being sent out over the link to the configured
environment.
When the router receives GETINFO messages from clients in the
zero-configuration environment asking for the scope list, it
responds as a MADCAP server would, by including the scope list it
acquired above.
5.2.2. Address Allocation
Local scope addresses can be allocated immediately by the router
as if it were a MADCAP server. For addresses in all larger
scopes, the following procedures apply.
If a MADCAP server was found in the configured environment, the
router acts as a MADCAP proxy and relays the request to an
appropriate server as if it were a client. The response is
relayed back to the client as if it were a server.
if no MADCAP server was found in the configured environment, the
router MAY allocate addresses itself if it implements AAP to
coordinate with any other MAASs (such as other Edge routers)
reached via the configured environment.
6. Transitioning Between Scenarios
In an Isolated environment, each host should periodically (either
at regular intervals, or only when applications request addresses
Expires April 2000 [Page 6]
Draft Multicast Auto-Configured Networks October 1999
or scope lists) re-check whether a server is available. This
allows simple transition to an Edge or configured environment.
Similarly, if the host stops receiving responses from any servers,
the behavior specified in Section 5.1 allows it to continue
allocating addresses.
In an Edge environment, the Edge router should periodically
(either at regular intervalue, or only when hosts request
addresses or scope lists) re-check whether a server is available
in the configured environment.
Similarly, if the Edge router stops receiving responses from any
servers in the configured environment, the behavior specified in
Section 5.2 allows it to continue allocating addresses.
7. Security Considerations
In the interest of simplicity, this draft does not prescribe a
means of securing the multicast auto-configuration mechanism. Thus
it is possible that hosts will allocate conflicting multicast
addresses for a period of time, or that non-conforming hosts will
attempt to deny service to other hosts by allocating the same
multicast addresses.
Since MADCAP is used as a mechanism for determining whether to
auto-configure, it should be noted that it is likely that hosts in
small network scenarios will not attempt to secure their MADCAP
traffic.
If unsecured, MADCAP is vulnerable to a number of threats,
including message modification and attacks by rogue servers and
unauthenticated clients. While the procedure described in this
document does not preclude implementation of MADCAP security, the
extra configuration required to set this up represents an
implementation barrier in the home network. As a result, it is
likely that most home routers will not support MADCAP
authentication, and that those networks will remain vulnerable to
attack.
These threats are most serious in wireless networks such as
802.11, since attackers on a wired network will require physical
access to the home network, while wireless attackers may reside
outside the home. In order to provide for privacy equivalent to a
Expires April 2000 [Page 7]
Draft Multicast Auto-Configured Networks October 1999
wired network, the 802.11 specification provides for RC4-based
encryption. This is known as the "Wired Equivalency Privacy" (WEP)
specification, described in [9]. Where WEP is implemented, an
attacker will need to obtain the WEP key prior to gaining access
to the home network.
8. Acknowledgements
This draft has been enriched by comments from Steve Hanna of Sun
Microsystems.
9. References
[1] Thaler, D., Handley, M., and D. Estrin, "The Internet
Multicast Address Allocation Architecture", Internet Draft,
draft-ietf-malloc-arch-03.txt, October 1999.
[2] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", Work in progress,
draft-ietf-malloc-madcap-07.txt, September 1999.
[3] Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (AAP)", Work in progrss, draft-ietf-malloc-
aap-02.txt, October 1999.
[4] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] R. Finlayson, "Abstract API for Multicast Address
Allocation", Work in progress, draft-ietf-malloc-api-07.txt,
August 1999.
[6] D. Meyer, "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[7] IANA, "Single-source IP Multicast Address Range",
http://www.isi.edu/in-notes/iana/assignments/single-source-
multicast, October 1998.
[8] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", Work in progress, draft-
ietf-mboned-mzap-04.txt, June 1999.
Expires April 2000 [Page 8]
Draft Multicast Auto-Configured Networks October 1999
[9] IEEE 802.11 specification.
10. Authors' Addresses
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 703-8835
EMail: dthaler@microsoft.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 936-6605
EMail: bernarda@microsoft.com
11. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English. The limited permissions granted
above are perpetual and will not be revoked by the Internet
Society or its successors or assigns. This document and the
information contained herein is provided on an "AS IS" basis and
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
Expires April 2000 [Page 9]
Draft Multicast Auto-Configured Networks October 1999
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." April 1,
2000.
Expires April 2000 [Page 10]