draft-ietf-dhc-dna-ipv4-09.txt   draft-ietf-dhc-dna-ipv4-10.txt 
DHC Working Group Bernard Aboba DHC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation INTERNET-DRAFT Microsoft Corporation
Category: Proposed Standard Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-09.txt> <draft-ietf-dhc-dna-ipv4-10.txt>
14 October 2004 25 March 2005
Detection of Network Attachment (DNA) in IPv4 Detection of Network Attachment (DNA) in IPv4
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2005. This Internet-Draft will expire on October 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
The time required to detect movement (or lack of movement) between The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may subnets, and to obtain (or continue to use) a valid IPv4
be significant as a fraction of the total delay in moving between configuration may be significant as a fraction of the total delay in
points of attachment. This document synthesizes experience garnered moving between points of attachment. This document specifies a
over the years in the deployment of hosts supporting ARP, DHCP and procedure for optimizing the detection of network attachment and IP
IPv4 Link-Local addresses. A procedure is specified for detection of configuration in order to decrease the delay in moving between points
network attachment in order to better accommodate mobile hosts. of attachment.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
2. Framework ................................................ 4 2. Overview ................................................. 4
2.1 Most Likely Point of Attachment ................. 5 2.1 Most Likely Point of Attachment ................. 5
2.2 Reachability Test ............................... 6 2.2 Reachability Test ............................... 6
2.3 IPv4 Address Acquisition ........................ 8 2.3 IPv4 Address Acquisition ........................ 9
2.4 IPv4 Link-Local Addresses ....................... 9 2.4 IPv4 Link-Local Addresses ....................... 9
3. Constants ................................................ 10 3. Constants ................................................ 11
4. IANA Considerations ...................................... 10 4. IANA Considerations ...................................... 11
5. Security Considerations .................................. 10 5. Security Considerations .................................. 11
6. References ............................................... 11 6. References ............................................... 11
6.1 Normative references ............................ 11 6.1 Normative references ............................ 11
6.2 Informative references .......................... 11 6.2 Informative references .......................... 12
Acknowledgments .............................................. 12 Acknowledgments .............................................. 13
Authors' Addresses ........................................... 12 Authors' Addresses ........................................... 13
Appendix A - Link Layer Hints ................................ 13 Appendix A - Link Layer Hints ................................ 14
A.1 Introduction .................................... 13 A.1 Introduction .................................... 14
A.2 Hints ........................................... 14 A.2 Hints ........................................... 15
Intellectual Property Statement .............................. 15 Intellectual Property Statement .............................. 16
Disclaimer of Validity ....................................... 15 Disclaimer of Validity ....................................... 16
Copyright Statement .......................................... 16 Copyright Statement .......................................... 17
1. Introduction 1. Introduction
The time required to detect movement (or lack of movement) between The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between be significant as a fraction of the total delay in moving between
points of attachment. As a result, optimizing detection of network points of attachment. As a result, optimizing detection of network
attachment is important for mobile hosts. attachment is important for mobile hosts.
This document synthesizes experience in the deployment of hosts This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [IPv4LL], specifying a procedure to be performed for IPv4 addresses [IPv4LL], specifying a procedure for optimizing detection
detection of network attachment. The procedure consists of three of network attachment and IPv4 configuration, in order to minimize
phases: determination of the Most Likely Point of Attachment (MLPA), the latency in moving between points of attachment. Since this
reachability testing, and IPv4 address acquisition. procedure is dependent on the ARP protocol, it is not suitable for
use on media that do not support ARP [RFC826].
Since this procedure is dependent on the ARP protocol, it is not
suitable for use on media that do not support ARP [RFC826].
1.1. Requirements 1.1. Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.2. Terminology 1.2. Terminology
skipping to change at page 4, line 33 skipping to change at page 4, line 33
Routable address Routable address
In this specification, the term "routable address" refers to any In this specification, the term "routable address" refers to any
address other than an IPv4 Link-Local address. This includes address other than an IPv4 Link-Local address. This includes
private addresses as specified in [RFC1918]. private addresses as specified in [RFC1918].
Valid address Valid address
In this specification, the term "valid address" refers to either a In this specification, the term "valid address" refers to either a
static IPv4 address, or an address assigned via DHCPv4 which has static IPv4 address, or an address assigned via DHCPv4 which has
not been relinquished, and whose lease has not yet expired. not been relinquished, and whose lease has not yet expired.
2. Framework 2. Overview
For Detection of Network Attachment (DNA), the following basic DNAv4 consists of three phases: determination of the Most Likely
principles are suggested: Point of Attachment (MLPA), reachability testing, and IPv4 address
acquisition.
[a] Utilization of hints. As described in Appendix A, On connecting to a new point of attachment, the host responds to
link layers may provide hints as to whether a "Link Up" indications from the link layer by carrying out the DNAv4
host remains on the same subnet, despite changing procedure. As noted in Appendix A, hints about the point of
its point of attachment. Based on these hints, attachment may be available from the link and Internet layers. Based
the host determines the "Most Likely Point of on these hints, the host determines the "Most Likely Point of
Attachment" (MLPA), and the corresponding Attachment" (MLPA) and determines whether it has a valid IP
configuration associated with it. Since configuration associated with it.
hints may be misleading, it is important for
the host to make the correct determination even
where hints are misleading.
[b] Response to "Link Up" indications. On connecting If the host believes that it has attached to a network on which it
to a new point of attachment, the host attempts to has a valid IP configuration, then it performs a reachability test in
verify the configuration associated with the MLPA. order to confirm that configuration. In contrast to a DHCP exchange,
which may be between a DHCP client and an off-link DHCP server, the
reachability test is designed to verify bi-directional connectivity
to the default gateway(s) on the MLPA.
[c] Handling of IPv4 Link-Local addresses. Experience has If the reachability test is successful, the host MAY continue to use
shown that IPv4 Link-Local addresses are often assigned a valid routable IPv4 address without having to re-acquire it. This
inappropriately. This document suggests that hosts reduces roaming latency by allowing the host to bypass DHCP as well
behave conservatively with respect to assignment of as subsequent Duplicate Address Detection (DAD). If the host
IPv4 Link-Local addresses, configuring them only in believes that it has attached to a network on which it has no valid
situations in which they can do no harm. IPv4 configuration, or if the reachability test fails, then the host
attempts to obtain an IPv4 configuration using DHCPv4.
Since DNAv4 represents a performance optimization, it is important to
avoid compromising robustness. In some circumstances, DNAv4 may
result in a host successfully verifying an existing IPv4
configuration where attempting to obtain configuration via DHCPv4
would fail (such as when the DHCP server is down).
To improve robustness, this document suggests that hosts behave
conservatively with respect to assignment of IPv4 Link-Local
addresses, configuring them only in situations in which they can do
no harm. Experience has shown that IPv4 Link-Local addresses are
often assigned inappropriately, and that inappropriate assignment can
compromise both performance and connectivity.
While the performance of DNAv4 is dependent on the reliability of the
hints provided to the client, the host will ultimately determine the
correct IPv4 configuration even in the presence of misleading hints.
Where the host mistakenly concludes that it has attached to a network
on which it has a valid configuration a timeout will occur, providing
poorer performance than would be experienced by initially attempting
to obtain IPv4 configuration using DHCPv4. However, after timing
out, the host will obtain its configuration using DHCPv4, so that
the correct configuration will eventually be obtained.
DNAv4 does not increase the likelihood of an address conflict. The
DNAv4 procedure is only carried out when the host has a valid IPv4
configuration on the MLPA, implying that duplicate address detection
has previously been completed. Restrictions on sending ARP requests
and replies are described in Section 2.2.1.
2.1. Most Likely Point of Attachment 2.1. Most Likely Point of Attachment
In order to determine the MLPA, it is assumed that the host saves to In order to determine the MLPA, it is assumed that the host saves to
stable storage parameters relating to the networks it connects to: stable storage parameters relating to the networks it connects to:
[1] Link layer hints associated with each network. [1] Link and Internet layer hints associated with each
For details, see Appendix A. network. For details, see Appendix A.
[2] The IPv4 and MAC address of the default gateway(s) on [2] The IPv4 and MAC address of the default gateway(s) on
each network. each network.
[3] The link type, such as whether the link utilizes [3] The link type, such as whether the link utilizes
Ethernet, or 802.11 adhoc or infrastructure mode. Ethernet, or 802.11 adhoc or infrastructure mode.
Appendix A discusses hints useful for the determination of the MLPA.
By matching received hints against network parameters previously By matching received hints against network parameters previously
stored, the host makes an an educated guess of which network it has stored, the host makes an an educated guess of which network it has
attached to. In the absence of other information, the MLPA defaults attached to. In the absence of other information, the MLPA defaults
to the network to which the host was most recently attached. to the network to which the host was most recently attached.
2.1.1. Alternative Mechanisms
Aside from utilizing link layer indications, a host may also be able Aside from utilizing link layer indications, a host may also be able
to utilize Internet layer information in order to determine the MLPA. to utilize Internet layer information in order to determine the MLPA.
IPv4 ICMP Router Discovery messages [RFC1256] provide information IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link, as well as the routers relating to prefix(es) available on the link, as well as the routers
that serve those prefix(es). A host may use ICMP Router Discovery to that serve those prefix(es). A host may use ICMP Router Discovery to
conclude that an advertised prefix is available; however it cannot conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are conclude the converse -- that prefixes not advertised are
unavailable. unavailable.
However, since [RFC1256] is not widely implemented, in general, it is However, since [RFC1256] is not widely implemented, it is NOT
NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
an alternative to the reachability test outlined in Section 2.2. alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become additional resilience in the case where default gateway(s) become
unavailable. unavailable.
Similarly hosts that support routing protocols such as RIP and OSPF Similarly hosts that support routing protocols such as RIP and OSPF
can use these protocols to determine the prefix(es) available on a can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Full link and the default gateway(s) that serve those prefixes. Full
support is not required to glean this information. A host that support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol information without supporting a fully conformant routing protocol
implementation. implementation.
2.2. Reachability Test 2.2. Reachability Test
If the host has a valid routable IPv4 address on the MLPA, the host If the host has a valid routable IPv4 address on the MLPA, a host
SHOULD perform a reachability test, in order to to confirm that it is conforming to this specification SHOULD perform a reachability test,
connected to network on which it has a valid routable IPv4 address. in order to to confirm that it is connected to network on which it
If the reachability test is not successful, the host proceeds to the has a valid routable IPv4 address. If the reachability test is not
IPv4 address acquisition phase, described in Section 2.3. successful, the host proceeds to the IPv4 address acquisition phase,
described in Section 2.3.
The host skips the reachability test and proceeds to the IPv4 address The host skips the reachability test and proceeds to the IPv4 address
acquisition phase if any of the following conditions are true: acquisition phase if any of the following conditions are true:
[a] The host does not have a valid routable IPv4 [a] The host does not have a valid routable IPv4
address on the MLPA. In this case, the reachability address on the MLPA. In this case, the reachability
test cannot confirm that the host has a valid test cannot confirm that the host has a valid
routable IPv4 address, so that completing the routable IPv4 address, so that completing the
reachability test would serve no purpose. reachability test would serve no purpose.
skipping to change at page 6, line 46 skipping to change at page 7, line 27
the INIT-REBOOT state, as described in [RFC2131], the INIT-REBOOT state, as described in [RFC2131],
Section 3.2 and 4.3.2. Where reliable hints are Section 3.2 and 4.3.2. Where reliable hints are
unavailable, this will typically complete more unavailable, this will typically complete more
quickly than the reachability test. quickly than the reachability test.
[d] If secure detection of network attachment is required. [d] If secure detection of network attachment is required.
The reachability test utilizes ARP which is insecure, The reachability test utilizes ARP which is insecure,
whereas DHCP can be secured via DHCP authentication, whereas DHCP can be secured via DHCP authentication,
described in [RFC3118]. See Section 5 for details. described in [RFC3118]. See Section 5 for details.
In contrast to a DHCP exchange, which may be between a DHCP client
and an off-link DHCP server, the reachability test is designed to
verify bi-directional connectivity to the default gateway(s) on the
MLPA.
The host MAY probe only the primary default gateway, or it MAY probe The host MAY probe only the primary default gateway, or it MAY probe
primary and secondary default gateways, in series or in parallel. If primary and secondary default gateways in series or in parallel. In
the reachability test is successful, the host MAY continue to use a order to ensure configuration validity, the host SHOULD only
valid routable IPv4 address without having to re-acquire it. This configure default gateway(s) which pass the reachability test.
reduces roaming latency by allowing the host to bypass DHCP as well
as subsequent Duplicate Address Detection (DAD). In order to ensure
configuration validity, the host SHOULD only configure default
gateway(s) which pass the reachability test.
2.2.1. Packet Format 2.2.1. Packet Format
The reachability test is performed by sending an ARP Request. The The reachability test is performed by sending an ARP Request. The
ARP Request SHOULD use the host's MAC address as the source, and the ARP Request SHOULD use the host's MAC address as the source, and the
broadcast MAC address as the destination. The host sets the target broadcast MAC address as the destination. The host sets the target
protocol address (ar$tpa) to the IPv4 address of the primary default protocol address (ar$tpa) to the IPv4 address of the primary default
gateway, and uses its own MAC address in the sender hardware address gateway, and uses its own MAC address in the sender hardware address
field (ar$sha). The host sets the target hardware address field field (ar$sha). The host sets the target hardware address field
(ar$tha) to 0. (ar$tha) to 0.
If the host has a valid routable IPv4 address on the most likely If the host has a private address as defined in [RFC1918], then it
point of attachment, then it SHOULD set the sender protocol address SHOULD set the sender protocol address field (ar$spa) to the
field (ar$spa) to that address. It is assumed that the host had unspecified address (0.0.0.0). This is to avoid a potential address
previously done duplicate address detection so that an address conflict when the host changes its point of attachment from one
conflict is unlikely. private network to another.
However if the host has a private address as defined in [RFC1918],
then it SHOULD set the sender protocol address field (ar$spa) to the
unspecified address (0.0.0.0). This is to avoid an address conflict
in the case where the host has changed its point of attachment from
one private network to another.
Note: Some routers may refuse to answer an ARP Request sent with Note: Some routers may refuse to answer an ARP Request sent with
the sender protocol address field (ar$spa) set to the unspecified the sender protocol address field (ar$spa) set to the unspecified
address (0.0.0.0). In this case the reachability test will fail. address (0.0.0.0). In this case the reachability test will fail.
If the host has a valid routable IPv4 address other than a private
address on the MLPA, then it SHOULD set the sender protocol address
field (ar$spa) to that address. It is assumed that the host had
previously done duplicate address detection so that an address
conflict is unlikely.
If a valid ARP Response is received, the MAC address in the sender If a valid ARP Response is received, the MAC address in the sender
hardware address field (ar$sha) and the IPv4 address in the sender hardware address field (ar$sha) and the IPv4 address in the sender
protocol address field (ar$spa) are matched against the list of protocol address field (ar$spa) are matched against the list of
networks and associated default gateway parameters. If a match is networks and associated default gateway parameters. If a match is
found, then if the host has a valid routable IPv4 address on the found, then if the host has a valid routable IPv4 address on the
matched network, the host continues to use that IPv4 address, subject matched network, the host continues to use that IPv4 address, subject
to the lease re-acquisition and expiration behavior described in to the lease re-acquisition and expiration behavior described in
[RFC2131], Section 4.4.5. [RFC2131], Section 4.4.5.
Checking for a match on both the IPv4 address and MAC address of the Checking for a match on both the IPv4 address and MAC address of the
default gateway enables the host to confirm reachability even where default gateway enables the host to confirm reachability even where
it has moved between two private networks. In this case the IPv4 it has moved between two private networks. In this case the IPv4
address of the default gateway could remain the same, while the MAC address of the default gateway could remain the same, while the MAC
address would change, so that both addresses need to be checked. address would change, so that both addresses need to be checked.
The risk of an address conflict is greatest when the host moves
between private networks, since in this case the completion of
Duplicate Address Detection on the former network does not provide
assurance against an address conflict on the new network. Until a
host has conformed the validity of its IPv4 configuration, it SHOULD
NOT respond to ARP requests. In addition, prior to confirming its
IPv4 configuration, a host with a private address SHOULD NOT send ARP
requests containing its address within the sender protocol address
field (ar$spa); instead it SHOULD use the unspecified address, as
described above. However, where the host has a valid routable non-
private address on the MLPA, it MAY send ARP requests using its
address within the sender protocol address field (ar$spa) prior to
confirming its IPv4 configuration.
Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
address does not provide the same level of assurance since this address does not provide the same level of assurance since this may
requires an ARP Request/Response to be sent first, and typically does require an ARP Request/Response exchange. Where the host has moved
not allow the MAC address to be checked as well. It therefore SHOULD between two private networks, this could result in ARP cache
NOT be used as a substitute. pollution.
Where a host moves from one private network to another, an ICMP Echo Where a host moves from one private network to another, an ICMP Echo
Request can result in an ICMP Echo Response even when the default Request can result in an ICMP Echo Response even when the default
gateway has changed, as long as the IPv4 address remains the same. gateway has changed, as long as the IPv4 address remains the same.
This can occur, for example, where a host moves from one home This can occur, for example, where a host moves from one home
network using prefix 192.168/16 to another one. In addition, if the network using prefix 192.168/16 to another one. In addition, if the
ping is sent with TTL > 1, then an ICMP Echo Response can be received ping is sent with TTL > 1, then an ICMP Echo Response can be received
from an off-link gateway. from an off-link gateway. As a result, if the MAC address of the
default gateway is not checked, the host can mistakenly confirm
attachment to the MLPA, potentially resulting in an address conflict.
As a result, sending of an ICMP Echo Request SHOULD NOT be used as a
substitute for the DNAv4 procedure.
If the initial ARP Request does not elicit a Response, the host waits If the initial ARP Request does not elicit a Response, the host waits
for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition
phase. If a valid ARP Response is received, but cannot be matched phase. If a valid ARP Response is received, but cannot be matched
against known networks, the host assumes it has moved subnets and against known networks, the host assumes it does not have a valid
moves on to the IPv4 address acquisition phase. IPv4 configuration and moves on to the IPv4 address acquisition
phase.
2.3. IPv4 Address Acquisition 2.3. IPv4 Address Acquisition
If the host has a valid routable IPv4 address on the MLPA but the If the host has a valid routable IPv4 address on the MLPA but the
reachability test fails, the host SHOULD verify the configuration by reachability test fails, the host SHOULD verify the configuration by
entering the INIT-REBOOT state, and sending a DHCPREQUEST to the entering the INIT-REBOOT state, and sending a DHCPREQUEST to the
broadcast address as specified in [RFC2131] Section 4.4.2. broadcast address as specified in [RFC2131] Section 4.4.2.
If the host does not have a valid routable IPv4 address on the MLPA, If the host does not have a valid routable IPv4 address on the MLPA,
the host enters the INIT state and sends a DHCPDISCOVER packet to the the host enters the INIT state and sends a DHCPDISCOVER packet to the
skipping to change at page 10, line 10 skipping to change at page 10, line 50
subsequent retransmissions up to a maximum of 64 seconds. subsequent retransmissions up to a maximum of 64 seconds.
As a result, a DHCP client compliant with [RFC2131] will continue to As a result, a DHCP client compliant with [RFC2131] will continue to
retry every 64 seconds, even after allocating a IPv4 Link-Local retry every 64 seconds, even after allocating a IPv4 Link-Local
address. Should the DHCP client succeed in obtaining a routable address. Should the DHCP client succeed in obtaining a routable
address, then as noted in [IPv4LL], the IPv4 Link-Local address is address, then as noted in [IPv4LL], the IPv4 Link-Local address is
deprecated. deprecated.
Since it is inevitable that hosts will inappropriately configure IPv4 Since it is inevitable that hosts will inappropriately configure IPv4
Link-Local addresses at some point, hosts with routable IPv4 Link-Local addresses at some point, hosts with routable IPv4
addresses SHOULD be able to respond to peers with IPv4 Link-Local addresses need to be able to respond to peers with IPv4 Link-Local
addresses, as per [IPv4LL]. For example, a host configured with a addresses, as per [IPv4LL]. For example, a host configured with a
routable address may receive a datagram from a link-local source routable address may receive a datagram from a link-local source
address. In order to respond, the host will use ARP to resolve the address. In order to respond, the host will use ARP to resolve the
target hardware address and send the datagram directly, not to a target hardware address and send the datagram directly, not to a
router for forwarding. router for forwarding.
3. Constants 3. Constants
The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This
value was chosen so as to accommodate the maximum retransmission value was chosen so as to accommodate the maximum retransmission
skipping to change at page 11, line 30 skipping to change at page 12, line 18
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, October 2004. of IPv4 Link-Local Addresses", RFC 3927, March 2005.
6.2. Informative References 6.2. Informative References
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, Daydreamer, July 1994. 51, RFC 1661, Daydreamer, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and
E. Lear, "Address Allocation for Private Internets", RFC 1918, E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996. February 1996.
skipping to change at page 12, line 12 skipping to change at page 12, line 48
DHCPv4", Internet draft (work in progress), draft-ietf-dhc- DHCPv4", Internet draft (work in progress), draft-ietf-dhc-
rapid-commit-opt-05.txt, June 2004. rapid-commit-opt-05.txt, June 2004.
[IEEE8021AB] [IEEE8021AB]
IEEE Standards for Local and Metropolitan Area Networks: IEEE Standards for Local and Metropolitan Area Networks:
Station and Media Access Control - Connectivity Discovery, Station and Media Access Control - Connectivity Discovery,
IEEE Std 802.1AB/D5, September 2003. IEEE Std 802.1AB/D5, September 2003.
[IEEE8021X] [IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: Port IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2004, November based Network Access Control, IEEE Std 802.1X-2004, December
2004. 2004.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990. Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021Q] [IEEE8021Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks, P802.1Q, Standard for Virtual Bridged Local Area Networks, P802.1Q,
January 1998. January 1998.
skipping to change at page 12, line 34 skipping to change at page 13, line 21
Information technology - Telecommunications and information Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications, Access Control (MAC) and Physical Layer (PHY) Specifications,
IEEE Std. 802.11-2003, 2003. IEEE Std. 802.11-2003, 2003.
Acknowledgments Acknowledgments
The authors would like to acknowledge Greg Daley of Monash The authors would like to acknowledge Greg Daley of Monash
University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted
Lemon of Nominum and Thomas Narten of IBM for contributions to this Lemon of Nominum Thomas Narten of IBM, and David Hankins of ISC for
document. contributions to this document.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
skipping to change at page 16, line 7 skipping to change at page 17, line 7
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Open issues Open issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
http://www.drizzle.com/~aboba/DNA/dnaissues.html http://www.drizzle.com/~aboba/DNA/dnaissues.html
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/