Internet DRAFT - draft-white-zeroconf-subnet-alloc

draft-white-zeroconf-subnet-alloc





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]