draft-ietf-dhc-dna-ipv4-06.txt   draft-ietf-dhc-dna-ipv4-07.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-06.txt> <draft-ietf-dhc-dna-ipv4-07.txt>
10 March 2004 14 April 2004
Detection of Network Attachment (DNA) in IPv4 Detection of Network Attachment (DNA) in IPv4
This document is an Internet-Draft and is in full conformance with all By submitting this Internet-Draft, I certify that any applicable
provisions of Section 10 of RFC 2026. 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
RFC 3667.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that other
may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 material time. It is inappropriate to use Internet-Drafts as reference
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://
http://www.ietf.org/ietf/1id-abstracts.txt 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 October 22, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 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. This specification synthesizes experience points of attachment. This document synthesizes experience garnered
garnered over the years in the deployment of hosts supporting ARP, over the years in the deployment of hosts supporting ARP, DHCP and
DHCP and IPv4 Link-Local addresses, in order to optimize detection of Link-Local IPv4 addresses. A procedure is specified for detection of
network attachment by mobile hosts. network attachment in order to better accommodate mobile hosts.
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. Framework ................................................ 4
2.1 Most likely point of attachment ................. 5 2.1 Most Likely Point of Attachment ................. 5
2.2 Reachability test ............................... 5 2.2 Reachability Test ............................... 6
2.3 IPv4 Address Acquisition ........................ 7 2.3 IPv4 Address Acquisition ........................ 8
2.4 IPv4 Link-Local Addresses ....................... 8 2.4 Link-Local IPv4 Addresses ....................... 9
3. Constants ................................................ 9 3. Constants ................................................ 10
4. IANA Considerations ...................................... 9 4. IANA Considerations ...................................... 10
5. Security Considerations .................................. 9 5. Security Considerations .................................. 10
6. References ............................................... 10 6. References ............................................... 11
6.1 Normative references ............................ 10 6.1 Normative references ............................ 11
6.2 Informative references .......................... 11 6.2 Informative references .......................... 11
Acknowledgments .............................................. 12 Acknowledgments .............................................. 12
Authors' Addresses ........................................... 12 Authors' Addresses ........................................... 13
Appendix A - 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
Full Copyright Statement ..................................... 16 Full 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 Link-Local IPv4 supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4
addresses [IPv4LL], specifying a procedure to be performed for IPv4 addresses [IPv4LL], specifying a procedure to be performed for IPv4
detection of network attachment. The procedure consists of three detection of network attachment. The procedure consists of three
phases: determination of the "most likely" point of attachment, phases: determination of the "most likely" point of attachment,
reachability testing, and IPv4 address acquisition. reachability testing, and IPv4 address acquisition.
This document concerns the interaction of mechanisms used by IPv4
protocol stacks. Network attachment detection and its interaction
with interface configuration is considered elsewhere, for example in
Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address
Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6].
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. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
skipping to change at page 4, line 12 skipping to change at page 4, line 20
DHCP client DHCP client
A DHCP client or "client" is an Internet host using DHCP to obtain A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
DHCP server DHCP server
A DHCP server or "server" is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
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 Link-Local IPv4 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. Framework
For Detection of Network attachment, the following basic principles For Detection of Network attachment, the following basic principles
skipping to change at page 5, line 8 skipping to change at page 5, line 15
Therefore, contrary to [RFC2131] Section 3.7, no action Therefore, contrary to [RFC2131] Section 3.7, no action
need be taken on network disconnection. need be taken on network disconnection.
[d] Handling of Link-Local IPv4 addresses. Experience has [d] Handling of Link-Local IPv4 addresses. Experience has
shown that Link-Local IPv4 addresses are often assigned shown that Link-Local IPv4 addresses are often assigned
inappropriately. This document suggests that hosts inappropriately. This document suggests that hosts
behave conservatively with respect to assignment of behave conservatively with respect to assignment of
Link-Local IPv4 addresses, configuring them only in Link-Local IPv4 addresses, configuring them only in
situations in which they can do no harm. situations in which they can do no harm.
2.1. Most likely point of attachment 2.1. Most Likely Point of Attachment
In order to determine the "most likely" point of attachment it is In order to determine the "most likely" point of attachment it is
assumed that the host is capable of obtaining and writing to stable assumed that the host is capable of obtaining and writing to stable
storage parameters relating to networks that it connects to, storage parameters relating to networks that it connects to,
including: including:
[1] IP and link layer hints associated with each network. [1] Link layer hints associated with each network.
For details, see Appendix A. 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] Whether a network is an infrastructure or adhoc network. [3] Whether a network is an infrastructure or adhoc network.
By matching the received hints against information previously By matching the received hints against information previously
collected, the host may be able to make an educated guess of which collected, the host may be able to make an educated guess of which
network it has attached to. In the absence of other information, by network it has attached to. In the absence of other information, by
default the host assumes that the "most likely" point of attachment default the host may assume that the "most likely" point of
is the network to which it was most recently attached. attachment is the network to which it was most recently attached.
If the host has a valid routable IPv4 address on the "most likely" 2.1.1. Alternative Mechanisms
point of attachment, the host performs a reachability test as
described in Section 2.2. If the reachability test is not Aside from utilizing link layer hints, a host may also be able to
successful, or if the host does not have a valid routable IPv4 utilize Internet layer information in order to determine the "most
address on the "most likely" point of attachment, the host proceeds likely" point of attachment.
to the IPv4 address acquisition phase, described in Section 2.3.
IPv4 ICMP Router Discovery messages [RFC1256] provide information
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
conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are
unavailable.
However, since [RFC1256] is not widely implemented, in general, it is
NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as
an alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become
unavailable.
Similarly, hosts that support routing protocols such as RIP and OSPF
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes.
2.2. Reachability Test 2.2. Reachability Test
The purpose of the reachability test is to determine whether the host If the host has a valid routable IPv4 address on the "most likely"
is connected to a network on which it has a valid routable IPv4 point of attachment, the host will typically perform a reachability
address. test, as described in this section. The purpose of the reachability
test is to confirm whether the host is connected to a network on
which it has a valid routable IPv4 address.
If the reachability test is not successful, or if the host does not
have a valid routable IPv4 address on the "most likely" point of
attachment, the host proceeds to the IPv4 address acquisition phase,
described in Section 2.3.
The host skips the reachability test in the following circumstances: The host skips the reachability test in the following circumstances:
[a] If the host does not have a valid routable IPv4 [a] If the host does not have a valid routable IPv4
address on the "most likely" point of attachment. address on the "most likely" point of attachment.
[b] If reliable hints are unavailable. Since confirming [b] If reliable hints are unavailable. Since confirming
failure of the reachability test requires a timeout, failure of the reachability test requires a timeout,
mistakes are costly. In the absence of reliable mistakes are costly. In the absence of reliable
hints, a host SHOULD instead send a DHCPREQUEST from hints, a host SHOULD instead send a DHCPREQUEST from
skipping to change at page 6, line 17 skipping to change at page 6, line 50
gateway(s) for the "most likely" point of attachment. gateway(s) for the "most likely" point of attachment.
[d] If secure detection of network attachment is required. [d] If secure detection of network attachment is required.
See Section 5 for details. See Section 5 for details.
The reachability test is performed by attempting to verify The reachability test is performed by attempting to verify
reachability of default gateway(s) on the "most likely" point of reachability of default gateway(s) on the "most likely" point of
attachment. This reduces roaming latency by allowing the host to attachment. This reduces roaming latency by allowing the host to
bypass DHCP as well as subsequent Duplicate Address Detection (DAD). bypass DHCP as well as subsequent Duplicate Address Detection (DAD).
In contrast to a DHCP exchange, which may be between a DHCP client In contrast to a DHCP exchange, which may be between a DHCP client
and an offlink DHCP server, the reachability test occurs between a and an off-link DHCP server, the reachability test occurs between a
host and its next hop router. host and its next hop router.
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. If
the reachability test is successful, the host may continue to use a the reachability test is successful, the host may continue to use a
valid routable IPv4 address without having to re-acquire it. valid routable IPv4 address without having to re-acquire it.
However, in order to ensure configuration validity, the host SHOULD However, in order to ensure configuration validity, the host SHOULD
only configure default gateway(s) which pass the reachability test. only configure default gateway(s) which pass the reachability test.
2.2.1. Packet Format 2.2.1. Packet Format
skipping to change at page 8, line 23 skipping to change at page 9, line 7
broadcast address so that the host will receive a response regardless broadcast address so that the host will receive a response regardless
of whether the previously configured IPv4 address is correct for the of whether the previously configured IPv4 address is correct for the
network to which it has connected. network to which it has connected.
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
not appropriate, since if the DHCP client has moved to another not appropriate, since if the DHCP client has moved to another
subnet, a DHCP server response cannot be routed back to the client subnet, a DHCP server response cannot be routed back to the client
since the DHCPREQUEST will bypass the DHCP relay and will contain an since the DHCPREQUEST will bypass the DHCP relay and will contain an
invalid source address. invalid source address.
2.4. IPv4 Link-Local Addresses 2.4. Link-Local IPv4 Addresses
Link-Local IPv4 addresses are frequently assigned inappropriately.
For example, an IPv4 host assigning a Link-Local IPv4 address may not
be connected to a network, in which case assignment of a Link-Local
IPv4 address does no good; or the host may be attached to a network
with a DHCPv4 server but may not receive a response to a DHCPREQUEST
or DHCPDISCOVER.
To avoid inappropriate assignment of Link-Local IPv4 addresses, it is To avoid inappropriate assignment of Link-Local IPv4 addresses, it is
recommended that hosts behave conservatively with respect to recommended that hosts behave conservatively with respect to
assignment of Link-Local IPv4 addresses. assignment of Link-Local IPv4 addresses. As described in [IPv4LL]
Section 1.7, use of a routable address is preferred to a Link-Local
As described in [IPv4LL] Section 1.7, use of a routable address is IPv4 address whenever it is available.
preferred to a Link-Local IPv4 address whenever it is available. For
example, where the host does not have a valid routable IPv4 address
on the "most likely" point of attachment, the host MAY configure an
IPv4 Link-Local address prior to entering the INIT state and sending
a DHCPDISCOVER packet, as described in Section 2.3. Should a
routable IPv4 address be obtained, then as noted in [IPv4LL], the
Link-Local IPv4 address is deprecated.
Where the DHCP client does not receive a response after employing the Where the host does not have a valid routable IPv4 address on the
retransmission algorithm a minimum of three times, the host MAY "most likely" point of attachment, the host MAY configure an Link-
configure a Link-Local IPv4 address. Local IPv4 address prior to entering the INIT state and sending a
DHCPDISCOVER packet, as described in Section 2.3. However, should a
routable IPv4 address be obtained, the Link-Local IPv4 address is
deprecated, as noted in [IPv4LL].
Where a host has a valid routable IPv4 address on the "most likely" Where a host has a valid routable IPv4 address on the "most likely"
point of attachment, but the DHCP client does not receive a response point of attachment, but the DHCP client does not receive a response
after employing the retransmission algorithm, [RFC2131] Section 3.2 after employing the retransmission algorithm, [RFC2131] Section 3.2
states that the client MAY choose to use the previously allocated states that the client MAY choose to use the previously allocated
network address and configuration parameters for the remainder of the network address and configuration parameters for the remainder of the
unexpired lease. This is preferable to assigning a Link-Local IPv4 unexpired lease. Where a host can confirm that it remains connected
address if hints lead the host to believe that it remains connected
to a point of attachment on which it possesses a valid routable IPv4 to a point of attachment on which it possesses a valid routable IPv4
address. address, that address SHOULD be used, rather than assigning a Link-
Local IPv4 address.
Since a Link-Local IPv4 address is often configured because a DHCP Since a Link-Local IPv4 address is often configured because a DHCP
server failed to respond to an initial query or is inoperative for server failed to respond to an initial query or is inoperative for
some time, it is desirable to abandon the Link-Local IPv4 address some time, it is desirable to abandon the Link-Local IPv4 address
assignment as soon as a valid IPv4 address lease can be obtained. assignment as soon as a valid IPv4 address lease can be obtained.
As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4 server is assigned, existing implementations do not query the DHCPv4 server
again for 5 minutes. This behavior is in violation of [RFC2131] again for 5 minutes. This behavior is in violation of [RFC2131]
Section 4.1. Section 4.1.
skipping to change at page 9, line 34 skipping to change at page 10, line 8
The retransmission delay SHOULD be doubled with The retransmission delay SHOULD be doubled with
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 Link-Local IPv4 retry every 64 seconds, even after allocating a Link-Local IPv4
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 Link-Local IPv4 address is address, then as noted in [IPv4LL], the Link-Local IPv4 address is
deprecated. deprecated.
Since it is inevitable that hosts will inappropriately configure
Link-Local IPv4 addresses at some point, hosts with routable IPv4
addresses SHOULD be able to respond to peers with Link-Local IPv4
addresses, as per [IPv4LL]. For example, a host configured with a
routable address may receive a datagram from a link-local source
address. In order to respond, the host will use ARP to resolve the
target hardware address and send the datagram directly, not to a
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
timer likely to be experienced on an Ethernet network. timer likely to be experienced on an Ethernet network.
4. IANA Considerations 4. IANA Considerations
Guidelines for IANA considerations are specified in [RFC2434]. This Guidelines for IANA considerations are specified in [RFC2434]. This
specification does not request the creation of any new parameter specification does not request the creation of any new parameter
skipping to change at page 10, line 42 skipping to change at page 11, line 30
[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.
[IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", Internet draft (work in of Link-Local IPv4 Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-13.txt, February progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, April
2004. 2004.
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., et al., "Address Allocation for Private [RFC1918] Rekhter, Y., et al., "Address Allocation for Private
Internets", RFC 1918, February 1996. Internets", RFC 1918, February 1996.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[MIPv6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
[RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial [RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial
In User Service (RADIUS) Usage Guidelines", RFC 3580, In User Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003. September 2003.
[RFC2284bis] [RFC3748] Blunk, L., et al., "Extensible Authentication Protocol (EAP)",
Blunk, L., et al., "Extensible Authentication Protocol (EAP)",
RFC 3748, March 2004. RFC 3748, March 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, June 2004. based Network Access Control, IEEE Std 802.1X-2004, June 2004.
skipping to change at page 13, line 5 skipping to change at page 14, line 5
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
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Appendix A - Hints Appendix A - Link Layer Hints
A.1 Introduction A.1 Introduction
In order to assist in IPv4 network attachment detection, information In order to assist in IPv4 network attachment detection, information
associated with each network may be retained by the host. Based on associated with each network may be retained by the host. Based on
IP and link-layer information, the host may be able to make an link-layer information, the host may be able to make an educated
educated guess as to whether it has moved between subnets, or has guess as to whether it has moved between subnets, or has remained on
remained on the same subnet, as well as whether it has connected to the same subnet, as well as whether it has connected to an
an infrastructure or adhoc network. infrastructure or adhoc network.
If the host is likely to have moved between subnets, it may be If the host is likely to have moved between subnets, it may be
possible to make an educated guess as to which subnet it has moved possible to make an educated guess as to which subnet it has moved
to. Since an educated guess may be incorrect, prior to concluding to. Since an educated guess may be incorrect, prior to concluding
that the host remains on the same subnet, further tests (such as a that the host remains on the same subnet, further tests (such as a
reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) reachability test or a DHCPREQUEST sent from the INIT-REBOOT state)
are REQUIRED. are REQUIRED.
In practice, it is necessary for hints to be highly reliable before In practice, it is necessary for hints to be highly reliable before
they are worth considering, if the penalty paid for an incorrect hint they are worth considering, if the penalty paid for an incorrect hint
skipping to change at page 14, line 7 skipping to change at page 15, line 7
If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms, and If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms, and
REACHABILITY_TIMEOUT = 1000ms, then: REACHABILITY_TIMEOUT = 1000ms, then:
x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent
Therefore the hint need only be wrong 8.2 percent of the time before Therefore the hint need only be wrong 8.2 percent of the time before
it is not worth considering. it is not worth considering.
A.2 Hints A.2 Hints
IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link. A host may use such a
message to conclude that an advertised prefix is available; however
it cannot conclude the converse -- that prefixes not advertised are
unavailable.
For networks running IPv4 over PPP [RFC1661], IPv4 parameters For networks running IPv4 over PPP [RFC1661], IPv4 parameters
negotiated in IPCP provide direct information on whether a previously negotiated in IPCP provide direct information on whether a previously
obtained address remains valid on the link. obtained address remains valid on the link.
On IEEE 802 [IEEE802] wired networks, hints include link-layer On IEEE 802 [IEEE802] wired networks, hints include link-layer
discovery traffic as well as information exchanged as part of IEEE discovery traffic as well as information exchanged as part of IEEE
802.1X authentication [IEEE8021X]. 802.1X authentication [IEEE8021X].
Link-layer discovery traffic includes Link Layer Discovery Protocol Link-layer discovery traffic includes Link Layer Discovery Protocol
(LLDP) [IEEE8021AB] traffic as well as network identification (LLDP) [IEEE8021AB] traffic as well as network identification
information passed in the EAP-Request/Identity or within an EAP information passed in the EAP-Request/Identity or within an EAP
method exchange, as defined in EAP [RFC2284bis]. method exchange, as defined in EAP [RFC3748].
For example, LLDP advertisements can provide information on VLANs For example, LLDP advertisements can provide information on VLANs
supported by the device. When used with IEEE 802.1X authentication supported by the device. When used with IEEE 802.1X authentication
[IEEE8021X], the EAP-Request/Identity exchange may contain the name [IEEE8021X], the EAP-Request/Identity exchange may contain the name
of the authenticator, also providing information on the potential of the authenticator, also providing information on the potential
network. Similarly, during the EAP method exchange the authenticator network. Similarly, during the EAP method exchange the authenticator
may supply information that may be helpful in identifying the network may supply information that may be helpful in identifying the network
to which the device is attached. However, as noted in [RFC3580], it to which the device is attached. However, as noted in [RFC3580], it
is possible for the VLANID defined in [IEEE8021Q] to be assigned is possible for the VLANID defined in [IEEE8021Q] to be assigned
dynamically, so that static advertisements may not prove definitive. dynamically, so that static advertisements may not prove definitive.
skipping to change at page 15, line 20 skipping to change at page 16, line 14
In order to provide additional guidance on the subnets to which a In order to provide additional guidance on the subnets to which a
given AP offers access, additional subnet-related Information given AP offers access, additional subnet-related Information
Elements (IEs) have been proposed for addition to the IEEE 802.11 Elements (IEs) have been proposed for addition to the IEEE 802.11
Beacon and Probe Response messages. As noted earlier, VLANs may be Beacon and Probe Response messages. As noted earlier, VLANs may be
determined dynamically so that these information elements may not be determined dynamically so that these information elements may not be
reliable. reliable.
In IEEE 802.11, the presence of an IBSS can be used as a hint that a In IEEE 802.11, the presence of an IBSS can be used as a hint that a
point of attachment supports adhoc networking, and therefore that point of attachment supports adhoc networking, and therefore that
assignment of a Link-Local IPv4 address is likey. When running IPv4 assignment of a Link-Local IPv4 address is likely. When running IPv4
over PPP, if an IP address is not statically configured or assigned over PPP, if an IP address is not statically configured or assigned
via IPCP, this can also be taken as a hint that assignment of a Link- via IPCP, this can also be taken as a hint that assignment of a Link-
Local IPv4 address is likely. In addition, certain media such as USB Local IPv4 address is likely. In addition, certain media such as USB
or IEEE 1394 may be considered inherently more likely to support or IEEE 1394 may be considered inherently more likely to support
adhoc operation, so that connection to these networks may by itself adhoc operation, so that connection to these networks may by itself
be considered a hint. be considered a hint.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at page 16, line 39 skipping to change at page 17, line 39
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
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dhc-dna-ipv4-06.txt>, and expires This memo is filed as <draft-ietf-dhc-dna-ipv4-07.txt>, and expires
September 22, 2004. October 22, 2004.
 End of changes. 

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