Network Working Group A. White Internet-Draft A. Williams Expires: August 21, 2002 Motorola February 20, 2002 Zero-Configuration Subnet Prefix Allocation Using UIAP draft-white-zeroconf-subnet-alloc-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. This Internet-Draft will expire on August 21, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The ability of a multiple segment network to zero configure has advantages. This is especially the case when the network designer/builder has few IP networking skills, as can be expected in the home environment. This document describes a method for the zero- configuration of unique subnet prefixes in a network. The method proposed is based on the existence of the Unique Identifier Allocation Protocol (UIAP) but can be modified to use another protocol providing the same service. White & Williams Expires August 21, 2002 [Page 1] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Automatic Subnet Prefix Allocation . . . . . . . . . . . . 3 3.1 Overview of Mechanism . . . . . . . . . . . . . . . . . . 3 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 5 4. UIAP Domains . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 IPv4 Subnet Domain . . . . . . . . . . . . . . . . . . . . 5 4.2 IPv6 Subnet Domain . . . . . . . . . . . . . . . . . . . . 6 5. Implementation . . . . . . . . . . . . . . . . . . . . . . 6 5.1 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1 Address Structure . . . . . . . . . . . . . . . . . . . . 6 5.1.1.1 External Prefix . . . . . . . . . . . . . . . . . . . . . 6 5.1.1.2 Site Allocated Subnet Identifier (SASI) . . . . . . . . . 7 5.1.1.3 Interface Identifier . . . . . . . . . . . . . . . . . . . 7 5.1.2 Allocating IPv6 Subnet Prefixes Using UIAP . . . . . . . . 7 5.1.2.1 Sample IPv6 Claim . . . . . . . . . . . . . . . . . . . . 8 5.1.3 IPv6 SASI-derived Subnet Prefix Distribution . . . . . . . 9 5.2 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1 Address Structure . . . . . . . . . . . . . . . . . . . . 9 5.2.1.1 External Prefix . . . . . . . . . . . . . . . . . . . . . 9 5.2.1.2 Site Allocated Subnet Identifier . . . . . . . . . . . . . 10 5.2.1.3 Host Identifier . . . . . . . . . . . . . . . . . . . . . 10 5.2.2 IPv4 Subnet Allocation Using UIAP . . . . . . . . . . . . 10 5.2.2.1 Sample IPv4 Claim . . . . . . . . . . . . . . . . . . . . 10 5.2.3 IPv4 SASI-derived Prefix Distribution . . . . . . . . . . 11 5.3 Handling Prefix Allocation Collisions . . . . . . . . . . 11 5.3.1 Active Detection . . . . . . . . . . . . . . . . . . . . . 11 5.3.2 Passive Detection . . . . . . . . . . . . . . . . . . . . 12 5.3.3 Transient Failure . . . . . . . . . . . . . . . . . . . . 12 6. Routing Behaviour . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 14 B. Intellectual Property . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . 16 White & Williams Expires August 21, 2002 [Page 2] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 1. Introduction This document describes a zero configuration (zeroconf) method for the allocation of unique subnet prefixes in a local network. It uses UIAP [1], a router independent identifier allocation protocol, to bootstrap the subnet prefix allocation process. However, an alternative mechanism for network-wide validation of identifiers could be used. Detailed implementation information is only provided for IPv4 and IPv6 aggregatable unicast subnets. However, the mechanism may be suitable for any protocol using link-based subnetting. 2. Background Subnetting is a key task in network configuration. Traditional configuration requires the system administrator to manually assign subnet prefixes to each link, and configure the routers and configuration servers to use these prefixes. If these prefixes are incorrectly configured (i.e. non-unique), the routing algorithms may fail to work correctly. It would be advantageous for prefix allocation to occur in a zeroconf fashion in the absence of a system administrator. This would be especially useful in home networking where the "system administrator" may have few IP networking skills. The goal of this document is to describe a mechanism that enables subnet prefixes to be robustly auto-configured without excessive network traffic. One approach proposed has been to multilink subnets together [10] to form a bridged network at the IP layer where all subnets share the same network address. However, routing between subnets offers several advantages over bridged networks, especially in a multicast environment or an environment with loops. 3. Automatic Subnet Prefix Allocation This section presents a mechanism for automatic subnet prefix allocation. Details specific to various target protocols are discussed in Implementation (Section 5). 3.1 Overview of Mechanism Each link in a network must be allocated a unique subnet prefix. Traditional network design allocates one prefix to each network segment and, if the network and address space available is large enough, allocate prefixes in a hierarchical fashion. White & Williams Expires August 21, 2002 [Page 3] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 The mechanism described here uses a different approach. Network prefixes are allocated to attached router interfaces, rather than to links. A link connected to more than one router will thus be allocated multiple prefixes, each administered by a different router. This avoids the overhead of routers negotiating with each other on whether or not a network prefix has been assigned and what it may be. Routers sharing a link may acquire addresses in all subnets on the link and may advertise routes to subnets they have not allocated. Each participating router interface acquires a unique identifier (within a specified range) and uses this identifier to generate a unique subnet prefix. The uniqueness of the subnet prefix is guaranteed by the uniqueness of the identifier. This mechanism may seem expensive in terms of address space, in that each link consumes multiple prefixes. However, the smallest IPv4 private address space, 192.168/16, allows 254 subnets (0 and 255 are reserved). If every router had four configured interfaces, this allows 63 routers, enough for a sizeable local network. An IPv6 /48 prefix provides 16 bits of subnet identifier, or 2^14 routers (at four interfaces per router). Links without connected routers will not be allocated a subnet prefix. This is not a problem, since links without routers do not participate in routing, and thus can operate using only link-local protocols. The mechanism does not allocate subnets hierarchically. It is assumed that the network on which this mechanism is running is small enough that each router forwarding table can list an explicit route to each network segment. Section 5 deals with the configuration and routing issues (including multihoming) for the IPv6 and IPv4 protocols. 3.2 Requirements The following are required to deploy this mechanism: o A site-scoped identifier allocation protocol that is available to the routers (such as UIAP [1]). o An addressing domain. Subnet prefixes are allocated out of a prefix space. This space is protocol and deployment dependent. o Configuration services for hosts. The allocated subnet prefix/es must be made available to hosts on the link. Again, the mechanisms for doing this are protocol and deployment dependent. White & Williams Expires August 21, 2002 [Page 4] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 o Routing protocol support for dynamic subnet prefix allocation. Support for address collision detection and handling is recommended. Configuration servers include DHCP and other mechanisms for providing configuration information to hosts. While this document describes configuration servers as separate entities, it will often be convienient to deploy the mechanisms on the same device that performs subnet allocation. Deployment in an IPv6 or IPv4 space is considered in Implementation (Section 5). 3.3 Mechanism The mechanism for generating each subnet prefix is quite simple. 1. The router decides (in a protocol and deployment dependent manner) the range from which the prefix is to be allocated. It generates a unique identifier in that range which becomes the subnet ID. 2. The subnet ID is combined with any other prefix information to generate a complete subnet prefix. 3. The complete prefix is then used by routers, configuration servers and other devices that need it. This document only considers generation of the subnet component of a prefix (subnet ID). The subnet ID may need to be combined with a site-dependent component to form a complete prefix. This site- dependent component (also referred to as the external prefix) may be pre-set for private networks, or may be acquired through an additional prefix propagation mechanism. Collision detection is more complex and is discussed in Section 5.3. 4. UIAP Domains Subnet prefix allocation defines two UIAP domains [1] within the IANA space. These domains are the IPv4 subnet domain and the IPv6 subnet domain. 4.1 IPv4 Subnet Domain The IPv4 subnet domain uses domain identifier 1:0:4:0, and reserves all domains in the range 1:0:4:*. The IPv4 number space contains left justified binary data and supports bitwise comparison. IPv4 White & Williams Expires August 21, 2002 [Page 5] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 subnet UIDs (UIAP "unique identifiers") have a nominal length of four octets, but will be shorter as most subnet prefixes are at most 24 bits long. IPv4 subnet prefixes are stored as up to 4 octets of binary data, with each octet matching a term from an IPv4 address. The length of the UID prefix matches the CIDR [2] length. Bit alignment is used when the prefix length does not match an octet boundary. Example: The UID for a claim for subnet prefix 10.24.13/24 is prefix '0a180d' with length 3. This will claim all addresses in the 10.24.13/24 range. Note that this mechanism will usually be used in private networks only, due to the already scarce allocation in the globally addressable space. 4.2 IPv6 Subnet Domain The IPv6 subnet domain uses domain identifier 1:0:6:0, and reserves all domains in the range 1:0:6:*. The IPv6 number space contains left justified binary data and supports bitwise comparison. IPv6 subnet UIDs have a nominal length of 16 octets, but will usually be UIAP prefixes of 8 octets or smaller. 5. Implementation 5.1 IPv6 5.1.1 Address Structure Current IPv6 unicast network addresses (see [4] for basic IPv6 address formats) can be considered to consist of three main parts. o External prefix. o Site allocated subnet identifier (SASI). o Interface identifier 5.1.1.1 External Prefix The external prefix is the portion of the subnet prefix that is not available for the site to configure. It is the address of the site, and (unless site-local) is allocated externally to the site. The exact nature of this prefix depends on the type of IPv6 unicast address under consideration. White & Williams Expires August 21, 2002 [Page 6] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 Global aggregatable unicast address prefixes[5] have a "public topology" portion up to 48 bits in length. If the site is part of a larger site, some of the site local aggregate (SLA) portion may also have been allocated resulting in a prefix longer than 48 bits. Site local unicast addresses have a fixed fec0::/48 prefix followed by a 16 bit subnet-ID. As for global aggregatable unicast addresses, some of the subnet portion may not be available. This is less well defined for site local unicast addresses, since the definition of a "site" is somewhat uncertain. The 6to4 transition mechanism[8] also uses a 48 bit prefix, consisting of the 6to4 format prefix (2002::/16) followed by an embedded 32 bit IPv4 address. In each case, at least one prefix of at least 48 bits in length is imposed on the network to be configured. The space used for each of these prefixes is not available for automatic subnet prefix allocation. Mechanisms for distributing and configuring external prefixes have been proposed [7][9]. 5.1.1.2 Site Allocated Subnet Identifier (SASI) The SASI is the portion of the address space available for allocation by the network. The size of the SASI is the bits remaining between the external prefix and the 64 bit host identifier. The size of the SASI may be different for each external prefix. The external prefix and the SASI together form the 64 bit network address (routing portion) of an IPv6 address. These addresses are assigned to subnets. This address is the subnet prefix. This document describes zeroconf allocation of subnet prefixes using UIAP[1]. 5.1.1.3 Interface Identifier The IPv6 interface identifier occupies the lower 64 bits of the IPv6 address. Interface identifiers are determined during host configuration and are not part of subnet prefix allocation. RFC2462 [6] describes autoconfiguration of interface identifiers. 5.1.2 Allocating IPv6 Subnet Prefixes Using UIAP To generate a subnet prefix, the router generates a likely prefix (by appending a SASI to the external prefix) and validates it using UIAP. If the prefix is unique, it is accepted and becomes a subnet prefix. If the prefix is not unique, the router tries again until it succeeds White & Williams Expires August 21, 2002 [Page 7] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 in finding a unique prefix. When claiming prefixes using UIAP, the claim is made not only for the prefix, but for all addresses that may be derived from the prefix. For example, to claim prefix 2002:0102:0304:000a::/64, the UIAP claim is for domain 1:0:4:0, UID 0x200201010304000a, length 8, bit alignment 0, in prefix format. Routers may choose to claim prefixes on a per-interface basis, or may choose to claim a larger space and then internally allocate prefixes within this space. For example, a router with three interfaces might independently claim prefixes fec0:0:0:21::/64, fec0:0:0:22::/64, fec0:0:0:23::/64, or may simply claim the common fec0:0:0:20::/60 prefix. Claiming a common space reduces the UIAP messaging requirements and may make routing more efficient. However, it also introduces the possibility of unused address space. For most deployment situations, configuring all routers to claim either 2 bit (4 interface) or 3 bit (8 interface) selections is recommended. IPv6 subnet prefixes should be allocated using the UIAP Domain 1:0:6:0 (see Section 4.2). SASI-derived prefix lifetimes must be shorter than external prefix lifetimes. The router must ensure that it does not allow the UIAP claim to expire before the subnet prefix expires. Shorter lifetimes improve the network's ability to adapt at the expense of more messages (both UIAP and other configuration protocols). Recovering after a failed reclaim is covered in Section 5.3. 5.1.2.1 Sample IPv6 Claim Consider the above example, where the router claims fec0:0:0:20::/60, and assume a claim time of 1 hour. The subnet allocation application requests UIAP to claim all UIDs with the UID prefix 0xfec0000000000020, length 8, bit alignment 4 (which maps to the mask 0xF0), in domain 1:0:6:0, for 3600 seconds. Left justification is specified by 0 in the first bit of the flag octet of the domain ID. In response, UIAP will return either success or failure. If the claim succeeds, UIAP will also return an identifier that allows the router to refer to this claim (e.g. when reclaiming). The router must remember this identifier and associate it with this subnet prefix claim. White & Williams Expires August 21, 2002 [Page 8] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 5.1.3 IPv6 SASI-derived Subnet Prefix Distribution Once a SASI-derived subnet prefix has been created, it is made available to routers and configuration servers. Routers in an IPv6 network provide stateless autoconfiguration information[6] and should advertise subnet prefixes served by the router. According to RFC2462 [6], an IPv6 host interface receiving multiple prefix configuration messages should use the union of these messages in constructing its interface addresses. Thus, each host interface will have one set of addresses for each router on the link. 5.2 IPv4 5.2.1 Address Structure IPv4 CIDR addressing[2] is substantially similar to IPv6 addressing, as is the subnet prefix allocation mechanism. While the method in this document is unlikely to be used to allocate scarce global IPv4 addresses, it is suitable for automatic allocation of subnets in privately addressed networks[3]. While not explicitly described, the three address parts of an IPv6 address (Section 5.1.1) are equally applicable to IPv4. o External prefix. o Site allocated subnet identifier (SASI). o Host identifier Each of these parts may be configured by different devices in a subnetted zeroconf network. 5.2.1.1 External Prefix The external prefix is the portion of the subnet prefix that is not available for the site to configure. These are analogous to IPv6. For example, in a 10/8 private network, the 10/8 portion of the address is the external prefix. It is expected that this mechanism will primarily be used in private networks, and thus the external prefix will be one of 10/8, 172.16/12, or 192.168/16 [3]. A zeroconf network could also be a subnet of a larger private network (e.g. 10.2/16). White & Williams Expires August 21, 2002 [Page 9] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 5.2.1.2 Site Allocated Subnet Identifier The remaining portion of the CIDR address is divided between subnets and hosts. Networks typically use a /24 subnet address and reserve the last octet for hosts. However, this varies from network to network. As for IPv6, the SASI occupies the space between the external prefix and the host identifier. For example, a privately addressed 192.168/16 network could use one byte of SASI allowing the allocation of 256 /24 subnets. 5.2.1.3 Host Identifier Unlike IPv6 host identifiers which are in theory globally independent, IPv4 host identifiers are allocated only within the scope of the subnet prefix. In an automatic configuration environment, the IPv4 host generally obtains its host address directly from a configuration server (via DHCP for example) and does not independently generate a host identifier. A DHCP server may be colocated in a router and can allocate from the pool of addresses available to the subnet. 5.2.2 IPv4 Subnet Allocation Using UIAP Although the address structures are different, the IPv4 prefix claim mechanism is identical to that used for IPv6. IPv4 subnet prefixes should be allocated using the UIAP Domain 1:0:4:0 (see Section 4.1). IPv4 addresses (and thus prefixes) do not naturally support the concept of an address lifetime. However, the presence of DHCP servers may mean that the affected hosts are prepared to deal with a limited lifetime address. It is recommended that the claim lifetime be longer than the DHCP lease length, but not substantially so. As with IPv6, the router must not allow the claim to expire during the lifetime of the DHCP lease, except in case of conflict. 5.2.2.1 Sample IPv4 Claim Assume that a network uses private address space 172.16/12 (the external prefix), and that a router intends to claim the subnets 172.19.4/24, 172.19.5/24, and 172.19.6/24 for its three interfaces, using a single claim for 172.19.4/22. The router offers DHCP leases for 6 hours, so makes the UIAP claim for 9 hours (it renews the claim every 3 hours). The subnet allocation application requests UIAP to claim all UIDs with the UID prefix 0xac1304, length 3, bit alignment White & Williams Expires August 21, 2002 [Page 10] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 6 (mask 0xF6, last two bits insignificant), in domain 1:0:4:0, for 32400 seconds. Left justification is specified by 0 in the first bit of the flag octet of the domain ID. In response, UIAP will return either success or failure. If the claim succeeds, UIAP will also return an identifier that allows the router to refer to this claim (e.g. for use when reclaiming). The router must remember this identifier and associate it with this subnet prefix claim. 5.2.3 IPv4 SASI-derived Prefix Distribution As with IPv6, subnet prefixes must be made available to routing tables and configuration servers (e.g. a DHCP server in the router). Because IPv4 configuration servers typically hand out addresses as well as prefixes, the configuration servers need to know how to generate a legal range of host addresses from a subnet prefix. In IPv4, a host that receives multiple DHCP responses will choose one and discard the rest. If DHCP functionality is integrated into each router a link with multiple routers will have multiple DHCP servers. In this situation, each host is supplied and address by one router only, and will need to acquire a new address from another router should the original router / DHCP server become unavailable. DHCP servers on different devices do not need to coordinate or communicate; each server operates independently. 5.3 Handling Prefix Allocation Collisions A prefix allocation collision occurs when two subnets are allocated the same prefix. In normal operation, this only happens when two previously unconnected networks (UIAP sites) are merged. Although global addresses should be unique (by virtue of their external prefixes being unique), it is possible for two networks to share common private address prefixes, either IPv6 site local or IPv4 private. UIAP defends existing claims against new claims. Since both networks have successfully claimed their prefix prior to merging, UIAP will not prevent collisions when the two networks merge. Thus, another mechanism must be used to detect and resolve collisions. Two possible options are discussed briefly below. 5.3.1 Active Detection Active detection involves routers frequently reclaiming their addresses (using UIAP) in an attempt to detect collisions. If a White & Williams Expires August 21, 2002 [Page 11] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 reclaim fails, then the router assumes a collision has occurred. It would then stop advertising the old invalid address and attempt to claim a new address to replace the invalid one. The problem with active detection is that it is chatty, and requires frequent reclaims by every router on the network, even though collisions are very unlikely. 5.3.2 Passive Detection Passive detection takes the opposite approach: do nothing until something breaks. Passive detection is best done by the routing protocol. The routing protocol collects reachability information about the subnets in the network and passes it to all routers. At some point, the routing protocol may discover that the subnet information is inconsistent; two physically distinct links are using the same subnet identifier. When this information is propagated to the offending routers, one of them MUST choose a new prefix. A deterministic method (e.g. larger MAC address) SHOULD be used to decide which router must surrender its claims. 5.3.3 Transient Failure A poorly timed transient interface or network failure could also lead to a conflict situation. If a router is aware that one of its interfaces has failed and been restarted, it SHOULD reclaim at least the subnet prefix of that interface, if not all prefixes. If this is not possible, then this situation is identical to a network merge. 6. Routing Behaviour This section briefly considers routing behaviour in an environment with automatic subnet prefix allocation. In particular, it considers links with multiple routers and router failure. If only a single router is present on a link, then that router is the router for that link, and all external traffic passes through that router. Should this router fail, hosts are restricted to link local operation, and the subnet prefixes will eventually time out. If multiple routers exist on a link, then that link will have multiple prefixes. Each router will act as an autoconfiguration server only for the subnet prefixes that it configured. However, all router interfaces on the subnet should acquire a full set of subnet addresses (using a suitable routing protocol). All routers advertise external routes to that subnet, allowing traffic to be routed via any White & Williams Expires August 21, 2002 [Page 12] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 router. If a router fails, its subnet prefixes will time out (since other routers are not serving those prefixes). When this happens, the other routers must stop advertising routes to that subnet. Eventually, traffic routing via these addresses will fail as hosts and routers time out the addresses; connections using those addresses will need to be reestablished using other addresses. New devices joining a link may only acquire configuration information from active routers. IPv6 hosts will acquire configuration information from all active routers and will continue to do so; only long-term connections will be disrupted by router failure. IPv4 hosts must reacquire new configuration information once their current DHCP lease expires. 7. Security Considerations The Zeroconf Subnet Prefix Allocation employs the Unique Identifier Allocation Protocol (UIAP)[1] and relies on the security measures taken to secure UIAP. Since the consistent allocation of network prefixes is critical for reliable network operation, securing UIAP is strongly recommended. References [1] White, A. and A. Williams, "Unique Identifier Allocation Protocol", draft-white-uiap-00.txt (work in progress), July 2001. [2] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter- Domain Routing: an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [5] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggretable Global Unicast Address Format", RFC 2374, July 1998. [6] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. White & Williams Expires August 21, 2002 [Page 13] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. [8] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [9] Haberman, B. and J. Martin, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", draft- haberman-ipngwg-auto-prefix-01.txt (work in progress), July 2001. [10] Thaler, D. and C. Huitema, "Multi-link Subnet Support in IPv6", draft-thaler-ipngwg-multilink-subnets-02.txt (work in progress), November 2001. Authors' Addresses Andrew White Motorola Australian Research Centre Locked Bag 5028 Botany, NSW 1455 AU Phone: +61 2 9666 0500 EMail: Andrew.E.White@motorola.com URI: http://www.motorola.com.au/marc/ Aidan Williams Motorola Australian Research Centre Locked Bag 5028 Botany, NSW 1455 AU Phone: +61 2 9666 0500 EMail: Aidan.Williams@motorola.com URI: http://www.motorola.com.au/marc/ Appendix A. Acknowledgements The authors thank John Judge and Kwan-Wu Chin for their participation in the discussion that led to this draft. Roger Kermode conducted several detailed reviews which improved the text considerably. White & Williams Expires August 21, 2002 [Page 14] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 Appendix B. Intellectual Property Motorola has submitted a patent claim covering UIAP technology. White & Williams Expires August 21, 2002 [Page 15] Internet-Draft Zeroconf Subnet Prefix Allocation February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 implementation 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 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. White & Williams Expires August 21, 2002 [Page 16]