Let's try for some perspective on 169.254 and related issues. Trying
to remember an IETF hallway discussion, I think with Jeff Schiller of
MIT (might have been Bill Manning), the convention for using this
particular block originated at MIT, not either Apple or Microsoft.
Don't confuse this mechanism with more general DHCP intended to let
the device operate in a general network. It's really intended for
single subnet operation.
IPv6 has a link-local autoconfiguration mode that also achieves this
sort of mechanism, but IPv6 autoconfiguration derives from OSI
protocols, not AppleTalk.
The specific convention is now in the Zeroconf Working Group:
http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-01.txt
From http://www.ietf.org/html.charters/zeroconf-charter.html
>The goal of the Zero Configuration Networking (ZEROCONF) Working
>Group is to enable networking in the absence of configuration and
>administration.
>Zero configuration networking is required for environments where
>administration is impractical or impossible, such as in the home or
>small office,
>embedded systems 'plugged together' as in an automobile, or to allow
>impromptu networks as between the devices of strangers on a train.
>
>ZEROCONF requirements will make networking as easy as possible, but
>no easier. In some cases other considerations may dominate ease of
>use. For
>example, network security requires some configuration which may not
>be as easy as the unacceptable alternative of 'no security.'
>
>Networks where ZEROCONF protocols apply can include (but are not
>limited to) environments where no DHCP, MADCAP or DNS servers are
>present.
>
>This working group will address both IPv4 and IPv6.
>
>Many functions which are not of fundamental importance to host and
>application configuration are outside the scope of the working
>group. This is not
>because there are no other problems to solve for networking in an
>environment without preexisting configuration. This working group
>will focus on an
>achievable subset of these problems. The ZEROCONF WG will precisely
>define the requirements for each of the following functions:
>
>* Interface Configuration (IP address, network prefix, gateway router)
>
>* Name-to-Address Translation
>
>* Service Discovery
>
>* Automatic allocation of Multicast Addresses
>
>* Sufficient security features to prevent networks from being any
>less secure than networks which do not use ZEROCONF protocols
>
>The working group will define the requirements to provide these
>functions on two distinct network topologies:
>
>1. A single network segment, where all hosts are reachable by
>link-layer broadcast or multicast messages.
>
>2. A set of network segments, (on different IP subnetworks)
>interconnected by a single router.
>
>Automatic configuration of an arbitrary topology of routers and
>subnets is out of the scope of the ZEROCONF WG charter.
>
>The working group will also define how such a network may
>automatically transition from 'configured' to 'unconfigured'
>behavior, as well as from
>'unconfigured' to 'configured'. That is, the same hosts must be able
>to function on networks with no configuration as well as be capable
>of direct IP
>connectivity to the global Internet, including DNS entries supplied
>through standard DNS services. It is also possible that both modes
>(ZEROCONF and
>administered) may coexist on the same network; the modes may not be
>exclusive of each other.
>
>When ZEROCONF networks or hosts which are configured using ZEROCONF
>protocols are connected to the big 'I' internet, they should not
>automatically become vulnerable to new security threats.
>
>This WG will produce two documents. The first describes the
>requirements for the configuration (and security) services,
>defaults, and mechanisms a node
>needs to fully participate on ZEROCONF networks and/or configured
>networks. The second, which follows the first, will detail a
>'profile' specifying which
>standards specifically satisfy ZEROCONF requirements.
>
>The WG will also produce two protocol specifications. First, the WG
>will develop a document describing automatic generation and
>assignment of link-local
>IPv4 addresses in environments lacking host configuration (static or
>using DHCP). The document will describe existing practice as well as
>define
>recommendations for future implementations. Second, the WG will
>develop a profile of the Address Allocation Protocol (AAP) to
>provide Zero
>Configuration Multicast Address Allocation support for IPv4 and
>IPv6. No protocol modifications to AAP are expected. Rather, a
>subset of existing feature
>will be profiled for use in ZEROCONF environments.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
