draft-ietf-dhc-dna-ipv4-10.txt   draft-ietf-dhc-dna-ipv4-11.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-10.txt> <draft-ietf-dhc-dna-ipv4-11.txt>
25 March 2005 12 April 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, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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 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."
skipping to change at page 1, line 42 skipping to change at page 1, line 42
This Internet-Draft will expire on October 22, 2005. This Internet-Draft will expire on October 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 subnets, and to obtain (or continue to use) a valid IPv4
configuration may be significant as a fraction of the total delay in configuration may be significant as a fraction of the total handover
moving between points of attachment. This document specifies a latency in moving between points of attachment. This document
procedure for optimizing the detection of network attachment and IP specifies a procedure for optimizing the detection of network
configuration in order to decrease the delay in moving between points attachment and IPv4 configuration in order to decrease the handover
of attachment. latency in moving between points 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. Overview ................................................. 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 ........................ 9 2.3 IPv4 Address Acquisition ........................ 9
skipping to change at page 2, line 27 skipping to change at page 2, line 27
5. Security Considerations .................................. 11 5. Security Considerations .................................. 11
6. References ............................................... 11 6. References ............................................... 11
6.1 Normative references ............................ 11 6.1 Normative references ............................ 11
6.2 Informative references .......................... 12 6.2 Informative references .......................... 12
Acknowledgments .............................................. 13 Acknowledgments .............................................. 13
Authors' Addresses ........................................... 13 Authors' Addresses ........................................... 13
Appendix A - Link Layer Hints ................................ 14 Appendix A - Link Layer Hints ................................ 14
A.1 Introduction .................................... 14 A.1 Introduction .................................... 14
A.2 Hints ........................................... 15 A.2 Hints ........................................... 15
Intellectual Property Statement .............................. 16 Intellectual Property Statement .............................. 16
Disclaimer of Validity ....................................... 16
Copyright Statement .......................................... 17 Copyright Statement .......................................... 17
Disclaimer of Validity ....................................... 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 handover latency in moving
points of attachment. As a result, optimizing detection of network between points of attachment.
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 for optimizing detection addresses [RFC3927], specifying a procedure for optimizing detection
of network attachment and IPv4 configuration, in order to minimize of network attachment and IPv4 configuration, in order to minimize
the latency in moving between points of attachment. Since this the handover latency in moving between points of attachment. Since
procedure is dependent on the ARP protocol, it is not suitable for this procedure is dependent on the ARP protocol, it is not suitable
use on media that do not support ARP [RFC826]. 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 44 skipping to change at page 4, line 41
DNAv4 consists of three phases: determination of the Most Likely DNAv4 consists of three phases: determination of the Most Likely
Point of Attachment (MLPA), reachability testing, and IPv4 address Point of Attachment (MLPA), reachability testing, and IPv4 address
acquisition. acquisition.
On connecting to a new point of attachment, the host responds to On connecting to a new point of attachment, the host responds to
"Link Up" indications from the link layer by carrying out the DNAv4 "Link Up" indications from the link layer by carrying out the DNAv4
procedure. As noted in Appendix A, hints about the point of procedure. As noted in Appendix A, hints about the point of
attachment may be available from the link and Internet layers. Based attachment may be available from the link and Internet layers. Based
on these hints, the host determines the "Most Likely Point of on these hints, the host determines the "Most Likely Point of
Attachment" (MLPA) and determines whether it has a valid IP Attachment" (MLPA) and determines whether it has a valid IPv4
configuration associated with it. configuration associated with it.
If the host believes that it has attached to a network on which it If the host believes that it has attached to a network on which it
has a valid IP configuration, then it performs a reachability test in has a valid IPv4 configuration, then it performs a reachability test
order to confirm that configuration. In contrast to a DHCP exchange, in order to confirm that configuration. In contrast to a DHCPv4
which may be between a DHCP client and an off-link DHCP server, the exchange, which may be between a DHCPv4 client and an off-link DHCPv4
reachability test is designed to verify bi-directional connectivity server, the reachability test is designed to verify bi-directional
to the default gateway(s) on the MLPA. connectivity to the default gateway(s) on the MLPA.
If the reachability test is successful, the host MAY continue to use If the reachability test is successful, the host MAY continue to use
a valid routable IPv4 address without having to re-acquire it. This a valid routable IPv4 address without having to re-acquire it. This
reduces roaming latency by allowing the host to bypass DHCP as well reduces roaming latency by allowing the host to bypass DHCPv4 as well
as subsequent Duplicate Address Detection (DAD). If the host as subsequent Duplicate Address Detection (DAD). If the host
believes that it has attached to a network on which it has no valid believes that it has attached to a network on which it has no valid
IPv4 configuration, or if the reachability test fails, then the host IPv4 configuration, or if the reachability test fails, then the host
attempts to obtain an IPv4 configuration using DHCPv4. attempts to obtain an IPv4 configuration using DHCPv4.
Since DNAv4 represents a performance optimization, it is important to Since DNAv4 represents a performance optimization, it is important to
avoid compromising robustness. In some circumstances, DNAv4 may avoid compromising robustness. In some circumstances, DNAv4 may
result in a host successfully verifying an existing IPv4 result in a host successfully verifying an existing IPv4
configuration where attempting to obtain configuration via DHCPv4 configuration where attempting to obtain configuration via DHCPv4
would fail (such as when the DHCP server is down). would fail (such as when the DHCPv4 server is down).
To improve robustness, this document suggests that hosts behave To improve robustness, this document suggests that hosts behave
conservatively with respect to assignment of IPv4 Link-Local conservatively with respect to assignment of IPv4 Link-Local
addresses, configuring them only in situations in which they can do addresses, configuring them only in situations in which they can do
no harm. Experience has shown that IPv4 Link-Local addresses are no harm. Experience has shown that IPv4 Link-Local addresses are
often assigned inappropriately, and that inappropriate assignment can often assigned inappropriately, and that inappropriate assignment can
compromise both performance and connectivity. compromise both performance and connectivity.
While the performance of DNAv4 is dependent on the reliability of the While the performance of DNAv4 is dependent on the reliability of the
hints provided to the client, the host will ultimately determine the hints provided to the client, the host will ultimately determine the
skipping to change at page 7, line 24 skipping to change at page 7, line 23
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
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 DHCPv4 can be secured via DHCPv4 authentication,
described in [RFC3118]. See Section 5 for details. described in [RFC3118]. See Section 5 for details.
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. In primary and secondary default gateways in series or in parallel. In
order to ensure configuration validity, the host SHOULD only order to ensure configuration validity, the host SHOULD only
configure default gateway(s) which pass the reachability test. 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
skipping to change at page 8, line 30 skipping to change at page 8, line 28
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 The risk of an address conflict is greatest when the host moves
between private networks, since in this case the completion of between private networks, since in this case the completion of
Duplicate Address Detection on the former network does not provide Duplicate Address Detection on the former network does not provide
assurance against an address conflict on the new network. Until a assurance against an address conflict on the new network. Until a
host has conformed the validity of its IPv4 configuration, it SHOULD host with a private address has confirmed the validity of its IPv4
NOT respond to ARP requests. In addition, prior to confirming its configuration, it SHOULD NOT respond to ARP requests, and SHOULD NOT
IPv4 configuration, a host with a private address SHOULD NOT send ARP send ARP requests containing its address within the sender protocol
requests containing its address within the sender protocol address address field (ar$spa). Instead it SHOULD use the unspecified
field (ar$spa); instead it SHOULD use the unspecified address, as address, as described above. However, where the host has a valid
described above. However, where the host has a valid routable non- routable non-private address on the MLPA, it MAY send ARP requests
private address on the MLPA, it MAY send ARP requests using its using its address within the sender protocol address field (ar$spa)
address within the sender protocol address field (ar$spa) prior to prior to confirming its IPv4 configuration, and MAY respond to ARP
confirming its IPv4 configuration. requests.
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 may address does not provide the same level of assurance since this may
require an ARP Request/Response exchange. Where the host has moved require an ARP Request/Response exchange. Where the host has moved
between two private networks, this could result in ARP cache between two private networks, this could result in ARP cache
pollution. 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.
skipping to change at page 9, line 26 skipping to change at page 9, line 25
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
broadcast address, as described in [RFC2131] Section 4.4.1. If the broadcast address, as described in [RFC2131] Section 4.4.1. If the
host supports the Rapid Commit Option [RAPID], it is possible that host supports the Rapid Commit Option [RFC4039], it is possible that
the exchange can be shortened from a 4-message exchange to a the exchange can be shortened from a 4-message exchange to a
2-message exchange. 2-message exchange.
If the host does not receive a response to a DHCPREQUEST or If the host does not receive a response to a DHCPREQUEST or
DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1. 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
skipping to change at page 10, line 4 skipping to change at page 9, line 51
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. IPv4 Link-Local Addresses
To avoid inappropriate assignment of IPv4 Link-Local addresses, it is To avoid inappropriate assignment of IPv4 Link-Local addresses, it is
recommended that hosts behave conservatively with respect to recommended that hosts behave conservatively with respect to
assignment of IPv4 Link-Local addresses. As described in [IPv4LL] assignment of IPv4 Link-Local addresses. As described in [RFC3927]
Section 1.7, use of a routable address is preferred to a IPv4 Link- Section 1.7, use of a routable address is preferred to a IPv4 Link-
Local address whenever it is available. Local address whenever it is available.
Where the host does not have a valid routable IPv4 address on the Where the host does not have a valid routable IPv4 address on the
MLPA, the host MAY configure an IPv4 Link-Local address prior to MLPA, the host MAY configure an IPv4 Link-Local address prior to
entering the INIT state and sending a DHCPDISCOVER packet, as entering the INIT state and sending a DHCPDISCOVER packet, as
described in Section 2.3. However, should a routable IPv4 address be described in Section 2.3. However, should a routable IPv4 address be
obtained, the IPv4 Link-Local address is deprecated, as noted in obtained, the IPv4 Link-Local address is deprecated, as noted in
[IPv4LL]. [RFC3927].
Where a host has a valid routable IPv4 address on the MLPA, but the Where a host has a valid routable IPv4 address on the MLPA, but the
DHCP client does not receive a response after employing the DHCP client does not receive a response after employing the
retransmission algorithm, [RFC2131] Section 3.2 states that the retransmission algorithm, [RFC2131] Section 3.2 states that the
client MAY choose to use the previously allocated network address and client MAY choose to use the previously allocated network address and
configuration parameters for the remainder of the unexpired lease. configuration parameters for the remainder of the unexpired lease.
Where a host can confirm that it remains connected to a point of Where a host can confirm that it remains connected to a point of
attachment on which it possesses a valid routable IPv4 address, that attachment on which it possesses a valid routable IPv4 address, that
address SHOULD be used, rather than assigning a IPv4 Link-Local address SHOULD be used, rather than assigning a IPv4 Link-Local
address. address.
Since a IPv4 Link-Local address is often configured because a DHCP Since a IPv4 Link-Local 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 IPv4 Link-Local address some time, it is desirable to abandon the IPv4 Link-Local 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 [RFC3927] 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 violates [RFC2131] Section 4.1. again for 5 minutes. This behavior violates [RFC2131] Section 4.1.
Where a IPv4 Link-Local address is assigned, experience has shown Where a IPv4 Link-Local address is assigned, experience has shown
that five minutes (see [IPv4LL] Appendix A.2) is too long an interval that five minutes (see [RFC3927] Appendix A.2) is too long an
to wait until retrying to obtain a routable IPv4 address using DHCP. interval to wait until retrying to obtain a routable IPv4 address
According to [RFC2131] Section 4.1: using DHCP. 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 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 [RFC3927], 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 need to 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 [RFC3927]. 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
timer likely to be experienced on an Ethernet network. timer likely to be experienced on an Ethernet network.
skipping to change at page 11, line 38 skipping to change at page 11, line 37
convince the host that it was attached to a particular network. convince the host that it was attached to a particular network.
As a result, it is inadvisable for a host to adjust its security As a result, it is inadvisable for a host to adjust its security
based on which network it believes it is attached to. For example, based on which network it believes it is attached to. For example,
it would be inappropriate for a host to disable its personal firewall it would be inappropriate for a host to disable its personal firewall
based on the belief that it had connected to a home network. based on the belief that it had connected to a home network.
Where secure detection of network attachment is required, a host Where secure detection of network attachment is required, a host
SHOULD skip the reachability test since it cannot be secured, and SHOULD skip the reachability test since it cannot be secured, and
instead utilize authenticated DHCP [RFC3118], possibly in combination instead utilize authenticated DHCP [RFC3118], possibly in combination
with the Rapid Commit Option [RAPID]. with the Rapid Commit Option [RFC4039].
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
USC/Information Sciences Institute, September 1981. USC/Information Sciences Institute, September 1981.
[RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or-
Converting Network Addresses to 48-bit Ethernet Address for Converting Network Addresses to 48-bit Ethernet Address for
skipping to change at page 12, line 37 skipping to change at page 12, line 37
February 1996. February 1996.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the
DHCPv4", Internet draft (work in progress), draft-ietf-dhc- Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC
rapid-commit-opt-05.txt, June 2004. 4039, March 2005.
[IEEE8021AB] [IEEE-802.1AB]
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, March 2005.
[IEEE8021X] [IEEE-802.1X]
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, December based Network Access Control, IEEE Std 802.1X-2004, December
2004. 2004.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: [IEEE-802]
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] [IEEE-802.1Q]
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] [IEEE-802.11]
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
skipping to change at page 15, line 11 skipping to change at page 15, line 11
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
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 media supporting EAP [RFC3748], network identification information
discovery traffic as well as information exchanged as part of IEEE may be passed within the EAP-Request/Identity or within an EAP method
802.1X authentication [IEEE8021X]. exchange. For example, the EAP-Request/Identity may contain the name
of the authenticator. During the EAP method exchange the
authenticator may supply information that may be helpful in
identifying the network to which the device is attached. However,
as noted in [RFC3580], it is possible for the VLANID defined in
[IEEE-802.1Q] to be assigned dynamically, so that static
advertisements may not prove definitive.
Link-layer discovery traffic includes Link Layer Discovery Protocol On IEEE 802 [IEEE-802] wired networks, hints can be obtained via the
(LLDP) [IEEE8021AB] traffic as well as network identification Link Layer Discovery Protocol (LLDP) defined in [IEEE-802.1AB]. LLDP
information passed in the EAP-Request/Identity or within an EAP advertisements can include the chassis ID, which represents the
method exchange, as defined in EAP [RFC3748]. authenticator's chassis identification, enabling a host to determine
if it has attached to a previously encountered device. However,
since a device may support dynamic VLANs, re-attachment does not
necessarily imply that the VLAN has remained the same, although this
is likely.
For example, LLDP advertisements can provide information on VLANs LLDP also enables advertisement of the port's VLAN identifier, as
supported by the device. When used with IEEE 802.1X authentication well as a VLAN name, allowing the host to determine whether it has
[IEEE8021X], the EAP-Request/Identity exchange may contain the name attached to a VLAN on which it had previously obtained a valid
of the authenticator, also providing information on the potential configuration. Since such an advertisement cannot be heard until
network. Similarly, during the EAP method exchange the authenticator 802.1X authentication has completed, the advertised VLAN will reflect
may supply information that may be helpful in identifying the network a dynamic VLAN assignment if one has been made, so that it is likely
to which the device is attached. However, as noted in [RFC3580], it to be definitive.
is possible for the VLANID defined in [IEEE8021Q] to be assigned
dynamically, so that static advertisements may not prove definitive.
In IEEE 802.11 [IEEE80211] stations provide information in Beacon In IEEE 802.11 [IEEE-802.11] stations provide information in Beacon
and/or Probe Response messages, such as the SSID, BSSID, and and/or Probe Response messages, such as the SSID, BSSID, and
capabilities, as well as information on whether the station is capabilities, as well as information on whether the station is
operating in Infrastructure or Ad hoc mode. As described in operating in Infrastructure or Ad hoc mode. As described in
[RFC3580], it is possible to assign a Station to a VLAN dynamically, [RFC3580], it is possible to assign a Station to a VLAN dynamically,
based on the results of IEEE 802.1X [IEEE8021X] authentication. This based on the results of IEEE 802.1X [IEEE-802.1X] authentication.
implies that a single SSID may offer access to multiple VLANs, and in This implies that a single SSID may offer access to multiple VLANs,
practice most large WLAN deployments offer access to multiple and in practice most large WLAN deployments offer access to multiple
subnets. subnets.
Thus, associating to the same SSID is a necessary, but not Thus, associating to the same SSID is a necessary, but not
necessarily a sufficient condition, for remaining within the same necessarily a sufficient condition, for remaining within the same
subnet: while a Station associating to the same SSID may not subnet: while a Station associating to the same SSID may not
necessarily remain within the same subnet, a Station associating to a necessarily remain within the same subnet, a Station associating to a
different SSID is likely to have changed subnets. different SSID is likely to have changed subnets.
In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such
as "default", "linksys" and "tsunami" are often configured by as "default", "linksys" and "tsunami" are often configured by
skipping to change at page 16, line 15 skipping to change at page 16, line 23
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 IPv4 Link-Local address is likely. When running IPv4 assignment of a IPv4 Link-Local address is likely. When running IPv4
over PPP, if an IP address is not statically configured or assigned over PPP, if an IPv4 address is not statically configured or
via IPCP, this can also be taken as a hint that assignment of an IPv4 assigned via IPv4CP, this can also be taken as a hint that assignment
Link-Local address is likely. In addition, certain media such as USB of an IPv4 Link-Local address is likely. In addition, certain media
or IEEE 1394 may be considered inherently more likely to support such as USB or IEEE 1394 may be considered inherently more likely to
adhoc operation, so that connection to these networks may by itself support adhoc operation, so that connection to these networks may by
be considered a hint. itself be considered a hint.
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at page 16, line 44 skipping to change at page 17, line 5
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
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 (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
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/