One document matched: draft-ietf-dhc-dna-ipv4-08.txt
Differences from draft-ietf-dhc-dna-ipv4-07.txt
DHC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-08.txt>
18 July 2004
Detection of Network Attachment (DNA) in IPv4
By submitting this Internet-Draft, I certify that any applicable
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 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The time required to detect movement (or lack of movement) between
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
points of attachment. This document synthesizes experience garnered
over the years in the deployment of hosts supporting ARP, DHCP and
Link-Local IPv4 addresses. A procedure is specified for detection of
network attachment in order to better accommodate mobile hosts.
Aboba Proposed Standard [Page 1]
INTERNET-DRAFT DNAv4 18 July 2004
Table of Contents
1. Introduction.............................................. 3
1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3
2. Framework ................................................ 4
2.1 Most Likely Point of Attachment ................. 5
2.2 Reachability Test ............................... 6
2.3 IPv4 Address Acquisition ........................ 8
2.4 Link-Local IPv4 Addresses ....................... 9
3. Constants ................................................ 10
4. IANA Considerations ...................................... 10
5. Security Considerations .................................. 10
6. References ............................................... 11
6.1 Normative references ............................ 11
6.2 Informative references .......................... 11
Acknowledgments .............................................. 12
Authors' Addresses ........................................... 12
Appendix A - Link Layer Hints ................................ 13
A.1 Introduction .................................... 13
A.2 Hints ........................................... 14
Intellectual Property Statement .............................. 15
Disclaimer of Validity ....................................... 15
Copyright Statement .......................................... 16
Aboba Proposed Standard [Page 2]
INTERNET-DRAFT DNAv4 18 July 2004
1. Introduction
The time required to detect movement (or lack of movement) between
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
points of attachment. As a result, optimizing detection of network
attachment is important for mobile hosts.
This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4
addresses [IPv4LL], specifying a procedure to be performed for IPv4
detection of network attachment. The procedure consists of three
phases: determination of the Most Likely Point of Attachment (MLPA),
reachability testing, and IPv4 address acquisition.
Since this procedure is dependent on the ARP protocol, it is not
suitable for use on media that do not support ARP [RFC826].
1.1. Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
1.2. Terminology
This document uses the following terms:
ar$sha
ARP packet field: Source Hardware Address [RFC826]. The hardware
(MAC) address of the originator of an ARP packet.
ar$spa
ARP packet field: Source Protocol Address [RFC826]. For IP Address
Resolution this is the IPv4 address of the sender of the ARP
packet. If the sender address is unknown, this is set to 0.0.0.0.
ar$tha
ARP packet field: Target Hardware Address [RFC826]. The hardware
(MAC) address of the target of an ARP packet, or the broadcast
address if the target hardware address is unknown.
ar$tpa
ARP packet field: Target Protocol Address [RFC826]. For IPv4
Address Resolution, the IPv4 address for which one desires to know
the hardware address.
Aboba Proposed Standard [Page 3]
INTERNET-DRAFT DNAv4 18 July 2004
DHCP client
A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address.
DHCP server
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
Point of Attachment
A location within the network where a host may be connected. This
attachment point can be characterized by its address prefix and
next hop routing information.
Most Likely Point of Attachment (MLPA)
The point of attachment heuristically determined by the host to be
most likely, based on hints from the network.
Routable address
In this specification, the term "routable address" refers to any
address other than an Link-Local IPv4 address. This includes
private addresses as specified in [RFC1918].
Valid address
In this specification, the term "valid address" refers to either a
static IPv4 address, or an address assigned via DHCPv4 which has
not been relinquished, and whose lease has not yet expired.
2. Framework
For Detection of Network attachment, the following basic principles
are suggested:
[a] Utilization of hints. Link layers such as IEEE 802
[IEEE802] provide hints whether a host remains
on the same subnet despite changing its point of
attachment, or whether a host is connected to an
ad hoc or infrastructure network. Prior to connecting
to a new point of attachment, the host uses available
hints to determine the "most likely" configuration
associated with the new point of attachment. Since
hints are not infallible, the host should be capable of
making the correct determination even in the presence of
misleading hints. For details see Appendix A.
[b] Treatment of link-up indications. On connecting
to a new point of attachment, the host attempts to
verify the "most likely" configuration associated
with the new point of attachment.
Aboba Proposed Standard [Page 4]
INTERNET-DRAFT DNAv4 18 July 2004
[c] Handling of Link-Local IPv4 addresses. Experience has
shown that Link-Local IPv4 addresses are often assigned
inappropriately. This document suggests that hosts
behave conservatively with respect to assignment of
Link-Local IPv4 addresses, configuring them only in
situations in which they can do no harm.
2.1. Most Likely Point of Attachment
In order to determine the MLPA, it is assumed that the host is
capable of obtaining and writing to stable storage parameters
relating to networks that it connects to, including:
[1] Link layer hints associated with each network.
For details, see Appendix A.
[2] The IPv4 and MAC address of the default gateway(s) on
each network.
[3] Whether a network is an infrastructure or adhoc network.
By matching the received hints against information previously
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
default the host may assume that the MLPA is the network to which it
was most recently attached.
2.1.1. Alternative Mechanisms
Aside from utilizing link layer hints, a host may also be able to
utilize Internet layer information in order to determine the MLPA.
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
Aboba Proposed Standard [Page 5]
INTERNET-DRAFT DNAv4 18 July 2004
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Note that
full support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this
information without supporting a full conforming implementation of
the routing protocol.
2.2. Reachability Test
If the host has a valid routable IPv4 address on the MLPA, the host
will typically perform a reachability test, in order to to confirm
that the host is connected to a network on which it has a valid
routable IPv4 address. If the reachability test is not successful,
the host proceeds to the IPv4 address acquisition phase, described in
Section 2.3.
The host skips the reachability test and proceeds to the IPv4 address
acquisition phase, if any of the following conditions are true:
[a] The host does not have a valid routable IPv4
address on the MLPA. In this case, the reachability
test cannot confirm that the host has a valid
routable IPv4 address, so that it is unnecessary.
[b] The host does not have information on the default
gateway(s) for the MLPA. In this case, it is not
possible to carry out the reachability test.
[c] Reliable hints are unavailable. Since confirming
failure of the reachability test requires a timeout,
mistakes are costly. In the absence of reliable
hints, a host SHOULD instead send a DHCPREQUEST from
the INIT-REBOOT state, as described in [RFC2131],
Section 3.2 and 4.3.2. Where reliable hints are
unavailable, this will on average complete more
quickly than the reachability test.
[d] If secure detection of network attachment is required.
The reachability test utilizes ARP which is insecure,
whereas DHCP can be secured via DHCP authentication,
described in [RFC3118]. See Section 5 for details.
The reachability test is performed by attempting to verify
reachability of default gateway(s) on the MLPA. This reduces roaming
latency by allowing the host to bypass DHCP as well as subsequent
Duplicate Address Detection (DAD). In contrast to a DHCP exchange,
which may be between a DHCP client and an off-link DHCP server, the
reachability test occurs between a host and its next hop router.
Aboba Proposed Standard [Page 6]
INTERNET-DRAFT DNAv4 18 July 2004
The host may probe only the primary default gateway, or it may probe
primary and secondary default gateways, in series or in parallel. If
the reachability test is successful, the host may continue to use a
valid routable IPv4 address without having to re-acquire it.
However, in order to ensure configuration validity, the host SHOULD
only configure default gateway(s) which pass the reachability test.
2.2.1. Packet Format
The reachability test is performed by sending an ARP Request. The
ARP Request SHOULD use the host's MAC address as the source, and the
broadcast MAC address as the destination. The host sets the target
protocol address (ar$tpa) to the IPv4 address of the primary default
gateway, and uses its own MAC address in the sender hardware address
field (ar$sha). The host sets the target hardware address field
(ar$tha) to 0.
If the host has a valid routable IPv4 address on the most likely
point of attachment, then it SHOULD set the sender protocol address
field (ar$spa) to that address. It is assumed that the host had
previously done duplicate address detection so that an address
conflict is unlikely.
However if the host has a private address as defined in [RFC1918],
then it SHOULD set the sender protocol address field (ar$spa) to the
unspecified address (0.0.0.0). This is to avoid an address conflict
in the case where the host has changed its point of attachment from
one private network to another.
Note: Some routers may refuse to answer an ARP Request sent with
the sender protocol address field (ar$spa) set to the unspecified
address (0.0.0.0). In this case the reachability test will fail.
If a valid ARP Response is received, the MAC address in the sender
hardware address field (ar$sha) and the IPv4 address in the sender
protocol address field (ar$spa) are matched against the list of
networks and associated default gateway parameters. If a match is
found, then if the host has a valid routable IPv4 address on the
matched network, the host continues to use that IPv4 address, subject
to the lease re-acquisition and expiration behavior described in
[RFC2131], Section 4.4.5.
Checking for a match on both the IPv4 address and MAC address of the
default gateway allows the host to confirm reachability even where
the host moves between two private networks. In this case the IPv4
address of the default gateway could remain the same, while the MAC
address would change, so that both addresses need to be checked.
Aboba Proposed Standard [Page 7]
INTERNET-DRAFT DNAv4 18 July 2004
Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
address does not provide the same level of assurance since this
requires an ARP Request/Response to be sent first, and typically does
not allow the MAC address to be checked as well. It therefore SHOULD
NOT be used as a substitute.
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
gateway has changed, as long as the IPv4 address remains the same.
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
ping is sent with TTL > 1, then an ICMP Echo Response can be received
from an off-link gateway.
If the initial ARP Request does not elicit a Response, the host waits
for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition
phase. If a valid ARP Response is received, but cannot be matched
against known networks, the host assumes it has moved subnets and
moves on to the IPv4 address acquisition phase.
2.3. IPv4 Address Acquisition
If the host has a valid routable IPv4 address on the MLPA but the
reachability test fails, then the host SHOULD verify the
configuration by entering the INIT-REBOOT state, and sending a
DHCPREQUEST to the broadcast address as specified in [RFC2131]
Section 4.4.2.
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
broadcast address, as described in [RFC2131] Section 4.4.1. If the
host supports the Rapid Commit Option [RAPID], it is possible that
the exchange can be shortened from a 4-message exchange to a
2-message exchange.
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
state that knows the address of a DHCP server may use that address in
the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
address. In the INIT-REBOOT state a DHCPREQUEST is sent to the
broadcast address so that the host will receive a response regardless
of whether the previously configured IPv4 address is correct for the
network to which it has connected.
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
Aboba Proposed Standard [Page 8]
INTERNET-DRAFT DNAv4 18 July 2004
not appropriate, since if the DHCP client has moved to another
subnet, a DHCP server response cannot be routed back to the client
since the DHCPREQUEST will bypass the DHCP relay and will contain an
invalid source address.
2.4. Link-Local IPv4 Addresses
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 preferred to a Link-Local
IPv4 address whenever it is available.
Where the host does not have a valid routable IPv4 address on the
MLPA, the host MAY configure an Link-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 MLPA, 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.
Where a host can confirm that it remains connected to a point of
attachment on which it possesses a valid routable IPv4 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
server failed to respond to an initial query or is inoperative for
some time, it is desirable to abandon the Link-Local IPv4 address
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
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.
According to [RFC2131] Section 4.1:
The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.
Aboba Proposed Standard [Page 9]
INTERNET-DRAFT DNAv4 18 July 2004
As a result, a DHCP client compliant with [RFC2131] will continue to
retry every 64 seconds, even after allocating a Link-Local IPv4
address. Should the DHCP client succeed in obtaining a routable
address, then as noted in [IPv4LL], the Link-Local IPv4 address is
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
The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This
value was chosen so as to accommodate the maximum retransmission
timer likely to be experienced on an Ethernet network.
4. IANA Considerations
This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
5. Security Considerations
Detection of Network Attachment (DNA) is based on ARP and DHCP. ARP
[RFC826] traffic is inherently insecure, so that the reachability
test described in Section 1.3 can be easily spoofed by an attacker,
leading a host to falsely conclude that it is attached to a network
that it is not connected to. Similarly, where DHCP traffic is not
secured, an attacker could masquerade as a DHCP server, in order to
convince the host that it was attached to a particular network.
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,
it would be inappropriate for a host to disable its personal firewall
based on the belief that it had connected to a home network.
Where secure detection of network attachment is required, a host
SHOULD skip the reachability test since it cannot be secured, and
instead utilize authenticated DHCP [RFC3118], possibly in combination
with the Rapid Commit Option [RAPID].
Aboba Proposed Standard [Page 10]
INTERNET-DRAFT DNAv4 18 July 2004
6. References
6.1. Normative References
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
USC/Information Sciences Institute, September 1981.
[RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or-
Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", STD 37, RFC 826, November
1982.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-17.txt, July
2004.
6.2. Informative References
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, Daydreamer, July 1994.
[RFC1918] Rekhter, Y., et al., "Address Allocation for Private
Internets", RFC 1918, February 1996.
[RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial
In User Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003.
[RFC3748] Aboba, B., et al., "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
DHCPv4", Internet draft (work in progress), draft-ietf-dhc-
rapid-commit-opt-05.txt, June 2004.
Aboba Proposed Standard [Page 11]
INTERNET-DRAFT DNAv4 18 July 2004
[IEEE8021AB]
IEEE Standards for Local and Metropolitan Area Networks:
Station and Media Access Control - Connectivity Discovery,
IEEE Std 802.1AB/D5, September 2003.
[IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2004, June 2004.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks, P802.1Q,
January 1998.
[IEEE80211]
Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications,
IEEE Std. 802.11-2003, 2003.
Acknowledgments
The authors would like to acknowledge Greg Daley of Monash
University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted
Lemon of Nominum and Thomas Narten of IBM for contributions to this
document.
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Aboba Proposed Standard [Page 12]
INTERNET-DRAFT DNAv4 18 July 2004
Appendix A - Link Layer Hints
A.1 Introduction
In order to assist in IPv4 network attachment detection, information
associated with each network may be retained by the host. Based on
link-layer information, the host may be able to make an educated
guess as to whether it has moved between subnets, or has 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
possible to make an educated guess as to which subnet it has moved
to. Since an educated guess may be incorrect, prior to concluding
that the host remains on the same subnet, further tests (such as a
reachability test or a DHCPREQUEST sent from the INIT-REBOOT state)
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.
Aboba Proposed Standard [Page 13]
INTERNET-DRAFT DNAv4 18 July 2004
A.2 Hints
For networks running IPv4 over PPP [RFC1661], IPv4 parameters
negotiated in IPCP provide direct information on whether a previously
obtained address remains valid on the link.
On IEEE 802 [IEEE802] wired networks, hints include link-layer
discovery traffic as well as information exchanged as part of IEEE
802.1X authentication [IEEE8021X].
Link-layer discovery traffic includes Link Layer Discovery Protocol
(LLDP) [IEEE8021AB] traffic as well as network identification
information passed in the EAP-Request/Identity or within an EAP
method exchange, as defined in EAP [RFC3748].
For example, LLDP advertisements can provide information on VLANs
supported by the device. When used with IEEE 802.1X authentication
[IEEE8021X], the EAP-Request/Identity exchange may contain the name
of the authenticator, also providing information on the potential
network. Similarly, 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 [IEEE8021Q] to be assigned
dynamically, so that static advertisements may not prove definitive.
In IEEE 802.11 [IEEE80211] stations provide information in Beacon
and/or Probe Response messages, such as the SSID, BSSID, and
capabilities, as well as information on whether the station is
operating in Infrastructure or Ad hoc mode. As described in
[RFC3580], it is possible to assign a Station to a VLAN dynamically,
based on the results of IEEE 802.1X [IEEE8021X] authentication. This
implies that a single SSID may offer access to multiple VLANs, and in
practice most large WLAN deployments offer access to multiple
subnets.
Thus, associating to the same SSID is a necessary, but not
necessarily a sufficient condition, for remaining within the same
subnet: while a Station associating to the same SSID may not
necessarily remain within the same subnet, a Station associating to a
different SSID is likely to have changed subnets.
In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such
as "default", "linksys" and "tsunami" are often configured by
manufacturers by default. As a result, matching an advertised SSID
against those of previously encountered networks may be misleading.
Where an SSID known to be configured by default is encountered, it is
recommended that the BSSID be stored and subsequently compared
against the advertised BSSID to determine whether a match exists.
Aboba Proposed Standard [Page 14]
INTERNET-DRAFT DNAv4 18 July 2004
In order to provide additional guidance on the subnets to which a
given AP offers access, additional subnet-related Information
Elements (IEs) have been proposed for addition to the IEEE 802.11
Beacon and Probe Response messages. As noted earlier, VLANs may be
determined dynamically so that these information elements may not be
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 likely. 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 Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Aboba Proposed Standard [Page 15]
INTERNET-DRAFT DNAv4 18 July 2004
Copyright Statement
Copyright (C) The Internet Society (2004). 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 relating to this specification are tracked on the
following web site:
http://www.drizzle.com/~aboba/DNA/dnaissues.html
Aboba Proposed Standard [Page 16] | PAFTECH AB 2003-2026 | 2026-04-21 10:41:06 |