[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

NETWORK Working Group                                      Bernard Aboba
INTERNET-DRAFT                                                 Microsoft
Category: Informational
<draft-aboba-zeroconf-multi-00.txt>
6 October 1999

               Auto-Addressing in Multi-segment Networks

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.

The distribution of this memo is unlimited.  It is filed as <draft-
aboba-zeroconf-multi-00.txt>, and expires April 1, 2000. Please send
comments to the authors.

1.  Copyright Notice

Copyright (C) The Internet Society (1999).  All Rights Reserved.

2.  Abstract

Today, with the rapid rise of home networking, there is an increasing
need for simplified mechanisms for IPv4 address allocation within multi-
segment networks connected by a single router. This issue can arise, for
example, in the case of a home network supporting 802.11 wireless as
well as Ethernet.

In multi-segment small networks connected by a single router, it may be
desirable to provide for consistent IPv4 addressing in the case where
the small network has not been assigned a routable IPv4 address prefix.
This draft describes how this problem may be solved through
implementation of a mini-DHCP server within the router. The router may
either be disconnected from the Internet, in which case the hosts on the
multiple segments will only be able to reach other, or the router may
offer Internet connectivity via Network Address Translation (NAT), or
another suitable mechanism, such as RSIP.

Aboba                         Informational                     [Page 1]


INTERNET-DRAFT  Auto-Addressing in Multi-segment Networks 6 October 1999

3.  Introduction

Today, with the rapid rise of home networking, there is an increasing
need for simplified mechanisms for IPv4 address allocation within multi-
segment networks connected by a single router. This issue can arise, for
example, in the case of a home network supporting 802.11 wireless as
well as Ethernet.

In multi-segment small networks connected by a single router, it may be
desirable to provide for consistent IPv4 addressing in the case where
the small network has not been assigned a routable IPv4 address prefix.
This draft describes how this problem may be solved through
implementation of a mini-DHCP server within the router. The router may
either be disconnected from the Internet, in which case the hosts on the
multiple segments will only be able to reach other, or the router may
offer Internet connectivity via Network Address Translation (NAT),
described in [10], or another suitable mechanism, such as RSIP,
described in [11].

3.1.  Terminology

This document uses the following terms:

Site Administrator
          A Site Administrator is the person or organization responsible
          for handing out IP addresses to client machines.

DHCP client
          A DHCP client or "client" is an Internet host using DHCP to
          obtain configuration parameters such as a network address.

DHCP server
          A DHCP server or "server" is an Internet host that returns
          configuration parameters to DHCP clients.

3.2.  Requirements language

In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
"recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
described in [1].

3.3.  Configuration requirements for multi-segment networks

In order to enable effective IPv4 address allocation in multi-segment
networks connected by a single router, the following requirements need
to be met:

Aboba                         Informational                     [Page 2]


INTERNET-DRAFT  Auto-Addressing in Multi-segment Networks 6 October 1999

Multi-segment adressing consistency
          It MUST be possible to consistently assign addresses within
          multiple segments so as to avoid address conflicts either
          within segments or between segments. This consistency MUST be
          maintained in the event of addition or removal of segments, or
          in the event of interfaces going up or down.

Auto-config to Non-auto-config transition
          It MUST be possible to effectively transition a series of
          segments auto-configured as described in [8], to a consistent
          addressing scheme as described in this document.

4.  Addressing scheme

In order to provide addressing consistency in multi-segment IPv4
networks connected to a single router, this document proposes addition
of a mini-DHCP server to the router.  In order to ensure consistency of
addressing within the multiple segments, the mini-DHCP server MUST
automatically allocate /24 scopes out of the 192.168/16 prefix reserved
for private addressing, as described in [13], with a unique /24 prefix
allocated to each interface. Prefixes SHOULD be allocated from the
bottom of the range toward the top, starting with the 192.168.1/24
prefix.  The router MUST NOT allocate the 192.168.0/24 or 192.168.255/24
prefixes, as these are reserved for future use.

Note that in order to handle the case of interfaces coming up or down, a
scope MUST be allocated to each interface, whether it is functioning or
not. This allows a non-functioning interface to subsequently become
functional and to support consistent addressing. In the case where an
interface is added, such as by plugging in an additional card, a new
scope SHOULD be allocated as soon as the interface is added.

In order to allow for consistent numbering between router and host
reboots, scope assignments and address allocations should be handled as
required by [3] with respect to use of stable storage.  Scopes MUST NOT
be de-allocated on interface-down or interface removal, so as to remain
robust against short term configuration changes.

To enable reclaiming of scopes in the event of permanent removal of an
interface, scope allocations of non-existent interfaces should timeout
using with an interval of three times the DHCP lease time. For example,
if the DHCP lease time is set to 3 days, then a scope allocated to a
removed interface will timeout after 9 days.

4.1.  Compatibility with existing DHCP servers

A mini-DHCP server MUST NOT be active on an interface if there is
already another DHCP server active on that interface. Thus if the

Aboba                         Informational                     [Page 3]


INTERNET-DRAFT  Auto-Addressing in Multi-segment Networks 6 October 1999

router's BOOTP relay agent has already been configured on an interface,
the mini-DHCP server MUST NOT be active on that interface.

In order to detect the presence of a DHCP server on interfaces that have
not been configured as BOOTP relay agents, a router running a mini-DHCP
server MUST send out periodic DHCPDISCOVER requests on each interface
with the should-I-autoconfig flag set. If the DHCPDISCOVER is responded
to (either with a DHCPOFFER or with a never-autoconfig response), the
router MUST NOT provide DHCP service on that interface.  Similarly, if
the router running a mini-DHCP server hears a DHCPOFFER, DHCPACK or
DHCPNAK on an interface, then it MUST NOT provide DHCP service on that
interface.

Note that a mechanism is needed to allow the mini-DHCP server to be
brought up again once the other DHCP servers are removed.  Once the
router has detected another DHCP server and has shut down its own mini-
DHCP server, it SHOULD set a timer. Once this timer expires, the router
MUST once again send out a DHCPDISCOVER and listen for responses.  The
recommended timer interval is 5 minutes.

4.2.  Compatibility with private address spaces

Today there are ISPs that use private address space internally in order
to manage network devices. Thus it is conceivable that a router will
receive routing protocol announcements for 192.168/16 on one of its
interfaces. Were the router to listen to these announcements, it is
conceivable that it could become confused about the routing topology.

Thus routers implementing this specification MUST filter out routing
announcements for the 192.168/16 prefix on all interfaces.

4.3.  Transition from auto-config to non-auto-config

In order to allow a series of segments, each auto-configured within the
169.254/16 prefix as described in [8], to transition to a consistently
addressed state within the 192.168/16 prefix, the mini-DHCP server will
need to respond to the periodic DHCPDISCOVER messages sent by the auto-
configured hosts. In the response, the mini-DHCP server will utilize the
scope allocations described previously, and will also utilize the option
described in [7] in order to discourage hosts from subsequently
utilizing auto-configuration should a segment become temporarily
disconnected.

Note that the transition from individual auto-configured segments to a
consistently addressed multi-segment network may take some time. As
described in [8], auto-configured hosts continue to send out
DHCPDISCOVER messages in order to be able to reconfigure themselves in
the event of the addition of a DHCP server. The suggested default for

Aboba                         Informational                     [Page 4]


INTERNET-DRAFT  Auto-Addressing in Multi-segment Networks 6 October 1999

Ethernet implementations is to check every 5 minutes.

Thus it is conceivable that when the previously partitioned segments are
first connected, addressing conflicts may result.  As noted in [8],
there is currently no way to address this issue without causing all
hosts involved to re-configure IP addresses. This will occur within the
default reconfiguration interval.

In order to lessen the transition time, it may be desirable to decrease
the reconfiguration interval.  It also may be useful for nodes detecting
an address conflict to send out a DHCPDISCOVER so as to detect the
presence of a DHCP server more quickly, or to select another address
within the auto-config range after detection of a conflict.

5.  References

[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[2]  Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
     Internet draft (work in progress), draft-ietf-dhc-
     authentication-11.txt, June 1999.

[3]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
     1997.

[5]  Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
     Extensions", RFC 2132, March 1997.

[6]  Thomson,  S.,  Narten,  T.,  "IPv6  Stateless  Address
     Autoconfiguration", RFC 2462, December 1998.

[7]  Troll,  R.,  "DHCP  Option  to  Disable  Stateless Auto-
     Configuration  in  IPv4  Clients", RFC 2563, May 1999.

[8]  Troll,  R.,  "Automatically Choosing an IP Address in an Ad-Hoc
     IPv4 Network", Internet draft (work in progress), draft-ietf-dhc-
     ipv4-autoconfig-04.txt, April 1999.

[9]  IEEE 802.11 specification.

[10] Srisuresh, P., Holdrege, M., "IP Network Address Translator (NAT)
     Terminology and Considerations", RFC 2663, August 1999.

[11] Lo, J., Borella, M., Grabelsky, D., "Realm Specific IP: A
     Framework", Internet draft (work in progress), draft-ietf-nat-rsip-
     framework-01.txt, November 1999.

Aboba                         Informational                     [Page 5]


INTERNET-DRAFT  Auto-Addressing in Multi-segment Networks 6 October 1999

[12] Thomson,  S.  and  Narten,  T.,  "IPv6  Stateless  Address
     Autoconfiguration", RFC 2462, December 1998.

[13] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear,
     E., "Address Allocation for Private Internets", RFC 1918, February,
     1996.

6.  Security Considerations

DHCP, as noted in [2], 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 DHCP authentication, 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 DHCP authentication, and that those networks will remain
vulnerable to the attacks described in [2].

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 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.

7.  IANA Considerations

This draft does not create any new number spaces for IANA
administration.

8.  Acknowledgements

This draft has been enriched by comments from Ryan Troll of @Home and
Peter Ford and Yaron Goland of Microsoft.

9.  Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 (425) 936-6605
EMail: bernarda@microsoft.com

Aboba                         Informational                     [Page 6]


INTERNET-DRAFT  Auto-Addressing in Multi-segment Networks 6 October 1999

10.  Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to  pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.

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 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Aboba                         Informational                     [Page 7]


INTERNET-DRAFT  Auto-Addressing in Multi-segment Networks 6 October 1999

12.  Expiration Date

This memo is filed as <draft-aboba-zeroconf-multi-00.txt>,  and  expires
April 1, 2000.

Aboba                         Informational                     [Page 8]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/