draft-ietf-dhc-dna-ipv4-05.txt   draft-ietf-dhc-dna-ipv4-06.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-05.txt> <draft-ietf-dhc-dna-ipv4-06.txt>
26 January 2004 10 March 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 This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
network attachment by mobile hosts. network attachment by 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 ............................... 5
2.3 IPv4 Address Acquisition ........................ 8 2.3 IPv4 Address Acquisition ........................ 7
2.4 IPv4 Link-Local Addresses ....................... 8
3. Constants ................................................ 9 3. Constants ................................................ 9
4. IANA Considerations ...................................... 9 4. IANA Considerations ...................................... 9
5. Security Considerations .................................. 9 5. Security Considerations .................................. 9
6. References ............................................... 10 6. References ............................................... 10
6.1 Normative references ............................ 10 6.1 Normative references ............................ 10
6.2 Informative references .......................... 10 6.2 Informative references .......................... 11
Acknowledgments .............................................. 11 Acknowledgments .............................................. 12
Authors' Addresses ........................................... 11 Authors' Addresses ........................................... 12
Appendix A - Hints ........................................... 12 Appendix A - Hints ........................................... 13
Intellectual Property Statement .............................. 13 A.1 Introduction .................................... 13
Full Copyright Statement ..................................... 14 A.2 Hints ........................................... 14
Intellectual Property Statement .............................. 15
Full Copyright Statement ..................................... 16
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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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
are suggested: are suggested:
[a] Treatment of link-down/up indications. On disconnection [a] Utilization of hints. Link layers such as IEEE 802
from a network, there is no need to take action until the [IEEE802] provide hints whether a host remains
host is reconnected, since it is typically not possible
for a host to communicate until it has obtained connectivity.
Therefore, contrary to [RFC2131] Section 3.7, no action
need be taken on network disconnection. On connecting
to a new point of attachment, the host attempts to determine
the "most likely" configuration associated with the new
point of attachment.
[b] Utilization of hints. Link layers such as IEEE 802
[IEEE802] provide hints about whether a host remains
on the same subnet despite changing its point of on the same subnet despite changing its point of
attachment, or even whether the host is connected to an attachment, or whether a host is connected to an
ad hoc or infrastructure network. On connecting to a new ad hoc or infrastructure network. Prior to connecting
point of attachment, the host attempts to use available to a new point of attachment, the host uses available
hints to determine the "most likely" configuration hints to determine the "most likely" configuration
associated with the new point of attachment. Since associated with the new point of attachment. Since
hints are not infallible, the host should be capable of hints are not infallible, the host should be capable of
making the correct determination even in the presence of making the correct determination even in the presence of
misleading hints. For details see Appendix A. misleading hints. For details see Appendix A.
[c] Link-Local IPv4 addressing as a mechanism of last resort. [b] Treatment of link-up indications. On connecting
Experience has shown that Link-Local IPv4 addresses are to a new point of attachment, the host attempts to
often assigned inappropriately. For example, an IPv4 host verify the "most likely" configuration associated
assigning an Link-Local IPv4 address may not be connected with the new point of attachment.
to any network, in which case assignment of a Link-Local
IPv4 address does no good; or the host may be attached to a [c] Treatment of link-down indications. On disconnection
network with a DHCPv4 server but may not receive a response from a network, there is no need to take action until the
to a DHCPREQUEST or DHCPDISCOVER. As described in [IPv4LL] host is reconnected, since it is typically not possible
Appendix A once a Link-Local IPv4 address is assigned, for a host to communicate until it has obtained connectivity.
existing implementations do not query the DHCPv4 server Therefore, contrary to [RFC2131] Section 3.7, no action
again for 5 minutes. As noted in Section 2.3, this behavior need be taken on network disconnection.
is in violation of [RFC2131] Section 4.1. For hosts changing
their point of attachment more frequently than this, [d] Handling of Link-Local IPv4 addresses. Experience has
inappropriate assignment of an Link-Local IPv4 address can shown that Link-Local IPv4 addresses are often assigned
result in an ongoing inability to connect. As a result, inappropriately. This document suggests that hosts
this document suggests that hosts behave conservatively with behave conservatively with respect to assignment of
respect to assignment of Link-Local IPv4 addresses, using Link-Local IPv4 addresses, configuring them only in
them only as a last resort. 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] IP and 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.
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 assumes that the "most likely" point of attachment
is the network to which it was most recently attached. is the network to which it was most recently attached.
If the host has a valid routable IPv4 address on the "most likely" If the host has a valid routable IPv4 address on the "most likely"
point of attachment, the host performs a reachability test as point of attachment, the host performs a reachability test as
described in Section 2.2. If the reachability test is not described in Section 2.2. If the reachability test is not
successful, or if the host does not have a valid routable IPv4 successful, or if the host does not have a valid routable IPv4
skipping to change at page 6, line 8 skipping to change at page 5, line 47
The purpose of the reachability test is to determine whether the host The purpose of the reachability test is to determine whether the host
is connected to a network on which it has a valid routable IPv4 is connected to a network on which it has a valid routable IPv4
address. address.
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 no hints are available. Since confirming failure of [b] If reliable hints are unavailable. Since confirming
the reachability test requires considerable latency, failure of the reachability test requires a timeout,
mistakes are costly. In the absence of hints, a mistakes are costly. In the absence of reliable
host SHOULD instead send a DHCPREQUEST hints, a host SHOULD instead send a DHCPREQUEST from
from the INIT-REBOOT state, as described in [RFC2131], the INIT-REBOOT state, as described in [RFC2131],
Section 3.2 and 4.3.2. Section 3.2 and 4.3.2.
[c] If the host does not have information on the default [c] If the host does not have information on the default
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
skipping to change at page 7, line 43 skipping to change at page 7, line 35
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.
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_TIMER and then sends another ARP Request. If no ARP for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition
Response is received in response to this second Request, the host phase. If a valid ARP Response is received, but cannot be matched
proceeds to the IPv4 address acquisition phase. If a valid ARP against known networks, the host assumes it has moved subnets and
Response is received, but cannot be matched against known networks, moves on to the address acquisition phase.
the host assumes it has moved subnets and moves on to the address
acquisition phase.
2.3. IPv4 Address Acquisition 2.3. IPv4 Address Acquisition
If the host has a valid routable IPv4 address on the "most likely" If the host has a valid routable IPv4 address on the "most likely"
point of attachment, but the reachability test fails, then the host point of attachment, but the reachability test fails, then the host
seeks to verify the configuration by entering the INIT-REBOOT state, SHOULD verify the configuration by entering the INIT-REBOOT state,
and sending a DHCPREQUEST to the broadcast address as specified in and sending a DHCPREQUEST to the broadcast address as specified in
[RFC2131] Section 4.4.2. [RFC2131] Section 4.4.2.
If the host does not have a valid routable IPv4 address on the "most If the host does not have a valid routable IPv4 address on the "most
likely" point of attachment, the host enters the INIT state and sends likely" point of attachment, the host enters the INIT state and sends
a DHCPDISCOVER packet to the broadcast address, as described in a DHCPDISCOVER packet to the broadcast address, as described in
[RFC2131] Section 4.4.1. If the host does not receive a response to [RFC2131] Section 4.4.1.
a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in
[RFC2131] Section 4.1. If the host does not receive a response to a DHCPREQUEST or
DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1.
As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
state that knows the address of a DHCP server may use that address in state that knows the address of a DHCP server may use that address in
the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
address. In the INIT-REBOOT state a DHCPREQUEST is sent to the address. In the INIT-REBOOT state a DHCPREQUEST is sent to the
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
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
recommended that hosts behave conservatively with respect to
assignment of Link-Local IPv4 addresses.
As described in [IPv4LL] Section 1.7, use of a routable address is As described in [IPv4LL] Section 1.7, use of a routable address is
preferred to a Link-Local IPv4 address whenever it is available. preferred to a Link-Local IPv4 address whenever it is available. For
[RFC2131] Section 3.2 states that if the DHCP client does not receive example, where the host does not have a valid routable IPv4 address
a response after employing the retransmission algorithm, the client on the "most likely" point of attachment, the host MAY configure an
MAY choose to use the previously allocated network address and IPv4 Link-Local address prior to entering the INIT state and sending
configuration parameters for the remainder of the unexpired lease. a DHCPDISCOVER packet, as described in Section 2.3. Should a
This is preferable to assigning a Link-Local IPv4 address if the host routable IPv4 address be obtained, then as noted in [IPv4LL], the
has good reason to believe that it remains connected to a network on Link-Local IPv4 address is deprecated.
which it possesses a valid routable IPv4 address. See Appendix A for
details. Where the DHCP client does not receive a response after employing the
retransmission algorithm a minimum of three times, the host MAY
configure a Link-Local IPv4 address.
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
after employing the retransmission algorithm, [RFC2131] Section 3.2
states that the client MAY choose to use the previously allocated
network address and configuration parameters for the remainder of the
unexpired lease. This is preferable to assigning a Link-Local IPv4
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
address.
If the host does not have a valid IPv4 address lease on the "most
likely" network and does not receive a response after employing the
retransmission algorithm, it MAY assign 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
is assigned, existing implementations do not query the DHCPv4 server
again for 5 minutes. This behavior is in violation of [RFC2131]
Section 4.1.
Where a Link-Local IPv4 address is assigned, experience has shown Where a Link-Local IPv4 address is assigned, experience has shown
that five minutes (see [IPv4LL] Appendix A.2) is too long an interval that five minutes (see [IPv4LL] Appendix A.2) is too long an interval
to wait until retrying to obtain a routable IPv4 address using DHCP. to wait until retrying to obtain a routable IPv4 address using DHCP.
According to [RFC2131] Section 4.1: According to [RFC2131] Section 4.1:
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. In order to avoid inappropriate assignment of an IPv4 deprecated.
Link-Local address, it is RECOMMENDED that such an address not be
assigned until the DHCP client has retransmitted at least 3 times.
3. Constants 3. Constants
The suggested default value of REACHABILITY_TIMER is 200 ms. This value The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This
was chosen so as to accommodate the maximum retransmission timer likely value was chosen so as to accommodate the maximum retransmission
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
registries, nor does it require any other IANA assignments. registries, nor does it require any other IANA assignments.
5. Security Considerations 5. Security Considerations
Detection of Network Attachment (DNA) is typically insecure, so that Detection of Network Attachment (DNA) is typically insecure, so that
skipping to change at page 10, line 31 skipping to change at page 10, line 43
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 IPv4 Link-Local Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-12.txt, January progress), draft-ietf-zeroconf-ipv4-linklocal-13.txt, February
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.
[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] [RFC2284bis]
Blunk, L., et al., "Extensible Authentication Protocol (EAP)", Blunk, L., et al., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-08.txt, Internet draft (work in RFC 3748, March 2004.
progress), February 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-2001, June 2001. based Network Access Control, IEEE Std 802.1X-2004, June 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.
[IEEE80211] [IEEE80211]
skipping to change at page 12, line 7 skipping to change at page 13, line 7
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 - Hints
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 IP and link-layer information, the host may be able to make an
educated guess as to whether it has moved between subnets, or educated guess as to whether it has moved between subnets, or has
remained on the same subnet. remained on the same subnet, as well as whether it has connected to
an 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
they are worth considering, if the penalty paid for an incorrect hint
is substantial.
As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to
determine if a host has remained on the same subnet, while a
reachability test typically completes in REACH_TIME and times out in
REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent.
If a hint that the host has remained on the same subnet is wrong x
fraction of the time, then it is only worth considering if:
DHCPREQUEST_TIME = (1 - x) * REACH_TIME +
x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME)
x = DHCPREQUEST_TIME - REACH_TIME
----------------------------------------------------
REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME
If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms, and
REACHABILITY_TIMEOUT = 1000ms, then:
x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent
Therefore the hint need only be wrong 8.2 percent of the time before
it is not worth considering.
A.2 Hints
IPv4 ICMP Router Discovery messages [RFC1256] provide information IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link. A host may use such a relating to prefix(es) available on the link. A host may use such a
message to conclude that an advertised prefix is available; however message to conclude that an advertised prefix is available; however
it cannot conclude the converse -- that prefixes not advertised are it cannot conclude the converse -- that prefixes not advertised are
unavailable. unavailable.
For networks running over PPP [RFC1661], IP parameters negotiated in For networks running IPv4 over PPP [RFC1661], IPv4 parameters
IPCP provide direct information on whether a previously obtained negotiated in IPCP provide direct information on whether a previously
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 [RFC2284bis].
skipping to change at page 13, line 31 skipping to change at page 15, line 18
recommended that the BSSID be stored and subsequently compared recommended that the BSSID be stored and subsequently compared
against the advertised BSSID to determine whether a match exists. against the advertised BSSID to determine whether a match exists.
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
point of attachment supports adhoc networking, and therefore that
assignment of a Link-Local IPv4 address is likey. When running IPv4
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-
Local IPv4 address is likely. In addition, certain media such as USB
or IEEE 1394 may be considered inherently more likely to support
adhoc operation, so that connection to these networks may by itself
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
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 14, line 39 skipping to change at page 16, 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-05.txt>, and expires This memo is filed as <draft-ietf-dhc-dna-ipv4-06.txt>, and expires
August 22, 2004. September 22, 2004.
 End of changes. 

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