draft-ietf-dhc-dna-ipv4-03.txt   draft-ietf-dhc-dna-ipv4-04.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-03.txt> <draft-ietf-dhc-dna-ipv4-04.txt>
9 October 2003 21 October 2003
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 10 skipping to change at page 2, line 10
points of attachment. This specification synthesizes experience points of attachment. This specification synthesizes experience
garnered over the years in the deployment of hosts supporting ARP, garnered over the years in the deployment of hosts supporting ARP,
DHCP and IPv4 Link-Local addresses, in order to optimize detection of DHCP and IPv4 Link-Local addresses, in order to optimize detection of
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 .................................... 4 1.1 Requirements .................................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Framework ................................................ 4 2. Framework ................................................ 5
2.1 Reachability test ............................... 5 2.1 Reachability test ............................... 5
2.2 Packet format ................................... 5 2.2 Packet format ................................... 6
2.3 IPv4 Address Acquisition ........................ 7 2.3 IPv4 Address Acquisition ........................ 7
3. IANA Considerations ...................................... 8 3. Constants ................................................ 8
4. Security Considerations .................................. 8 4. IANA Considerations ...................................... 9
5. References ............................................... 8 5. Security Considerations .................................. 9
5.1 Normative references ............................ 8 6. References ............................................... 9
5.2 Informative references .......................... 9 6.1 Normative references ............................ 9
Acknowledgments .............................................. 10 6.2 Informative references .......................... 10
Authors' Addresses ........................................... 10 Acknowledgments .............................................. 11
Appendix A - Hints ........................................... 11 Authors' Addresses ........................................... 11
Intellectual Property Statement .............................. 12 Appendix A - Hints ........................................... 12
Full Copyright Statement ..................................... 12 Intellectual Property Statement .............................. 13
Full Copyright Statement ..................................... 13
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 23 skipping to change at page 4, line 23
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
This document uses the following terms: 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 IP 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 IP Address
Resolution, the IP address for which one desires to know the
hardware address.
DHCP client DHCP client
A DHCP client or "client" is an Internet host using DHCP to obtain A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
DHCP server DHCP server
A DHCP server or "server" is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
Routable address Routable address
In this specification, the term "routable address" refers to any In this specification, the term "routable address" refers to any
skipping to change at page 5, line 38 skipping to change at page 6, line 8
Address Detection (DAD). In contrast to a DHCP exchange, which may Address Detection (DAD). In contrast to a DHCP exchange, which may
be between a DHCP client and an offlink DHCP server, the reachability be between a DHCP client and an offlink DHCP server, the reachability
test occurs between a host and its next hop router. test occurs between a host and its next hop router.
The host skips the reachability test and proceeds to the address The host skips the reachability test and proceeds to the address
acquisition phase in the following circumstances: acquisition phase in the following circumstances:
[a] If the host does not have information on the default [a] If the host does not have information on the default
gateway on the network. gateway on the network.
[b] If the host does not have a valid routable IPv4 address [b] If the host does not have a valid routable IPv4 address
on the network. Since Link-Local IPv4 addresses are a on the network. A Link-Local IPv4 address does not
last resort, these addresses do not count as a valid count as a valid routable IPv4 address.
routable IPv4 address.
2.2. Packet Format 2.2. Packet Format
To perform the reachability test, an ARP Request SHOULD be sent, To perform the reachability test, an ARP Request SHOULD be sent,
using the host's MAC address as the source, and the broadcast MAC using the host's MAC address as the source, and the broadcast MAC
address as the destination. The host sets the target protocol address as the destination. The host sets the target protocol
address (ar$tpa) to the IPv4 address of the primary default gateway, address (ar$tpa) to the IPv4 address of the primary default gateway,
and uses its own MAC address in the sender hardware address field and uses its own MAC address in the sender hardware address field
(ar$sha). (ar$sha). The host sets the target hardware address field (ar$tha)
to 0.
If the host has a valid globally routable IP address on the most If the host has a valid globally routable IP address on the most
likely point of attachment, then it SHOULD set the sender protocol likely point of attachment, then it SHOULD set the sender protocol
address field (ar$spa) to that address. It is assumed that the host address field (ar$spa) to that address. It is assumed that the host
had previously done duplicate address detection so that an address had previously done duplicate address detection so that an address
conflict is unlikely. conflict is unlikely.
However if the host has a private address as defined in [RFC1918], However if the host has a private address as defined in [RFC1918],
then it SHOULD set the protocol address field (ar$spa) to 0.0.0.0. then it SHOULD set the sender protocol address field (ar$spa) to the
This is to avoid an address conflict in the case where the host has unspecified address (0.0.0.0). This is to avoid an address conflict
changed its point of attachment from one private network to another. in the case where the host has changed its point of attachment from
one private network to another.
Note: Some routers may refuse to answer an ARP Request sent with Note: Some routers may refuse to answer an ARP Request sent with
the protocol address field (ar$spa) set to the unspecified the sender protocol address field (ar$spa) set to the unspecified
address. In this case the reachability test will fail. 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 target If a valid ARP Response is received, the MAC address in the sender
hardware address field (ar$tha) and the IPv4 address in the target hardware address field (ar$sha) and the IPv4 address in the sender
protocol address field (ar$tpa) are matched against the list of protocol address field (ar$spa) are matched against the list of
networks and associated default gateway parameters. If a match is networks and associated default gateway parameters. If a match is
found, then if the host has a valid IPv4 address lease on the found, then if the host has a valid IPv4 address lease on the
matched network, the host continues to use that IPv4 address, subject matched network, the host continues to use that IPv4 address, subject
to the lease re-acquisition and expiration behavior described in to the lease re-acquisition and expiration behavior described in
[RFC2131], Section 4.4.5. [RFC2131], Section 4.4.5.
Checking for a match on both the IPv4 and MAC addresses of the Checking for a match on both the IPv4 and MAC addresses of the
default gateway allows the host to confirm reachability even where default gateway allows the host to confirm reachability even where
the host moves between two private networks. In this case the IPv4 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 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.
Sending an ICMP Echo Request to the default gateway IPv4 address does Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
not provide the same level of assurance since this requires an ARP address does not provide the same level of assurance since this
Request/Response to be sent first, and typically does not allow the requires an ARP Request/Response to be sent first, and typically does
MAC address to be checked as well. It therefore SHOULD NOT be used not allow the MAC address to be checked as well. It therefore SHOULD
as a substitute. Where a host moves from one private network to NOT be used as a substitute. Where a host moves from one private
another, an ICMP Echo Request can result in an ICMP Echo Response network to another, an ICMP Echo Request can result in an ICMP Echo
even when the default gateway has changed, as long as the IPv4 Response even when the default gateway has changed, as long as the
address remains the same. This can occur, for example, where a host IPv4 address remains the same. This can occur, for example, where a
moves from one home network using prefix 192.168/16 to another one. host moves from one home network using prefix 192.168/16 to another
In addition, if the ping is sent with TTL > 1, then an ICMP Echo one. In addition, if the ping is sent with TTL > 1, then an ICMP
Response can be received from an off-link gateway. Echo Response can be received 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
200ms and then sends another ARP Request. If no ARP Response is for REACHABILITY_TIMER and then sends another ARP Request. If no ARP
received in response to this second Request, the host proceeds to the Response is received in response to this second Request, the host
IPv4 address acquisition phase. If a valid ARP Response is received, proceeds to the IPv4 address acquisition phase. If a valid ARP
but cannot be matched against known networks, the host assumes it has Response is received, but cannot be matched against known networks,
moved subnets and 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 cached configuration on the "most likely" If the host has a valid cached configuration on the "most likely"
point of attachment, but is unable to confirm reachability to the point of attachment, but is unable to confirm reachability to the
primary default gateway, then the host seeks to verify the cached primary default gateway, then the host seeks to verify the cached
configuration by entering the INIT-REBOOT state, and sending a configuration by entering the INIT-REBOOT state, and sending a
DHCPREQUEST to the broadcast address as specified in [RFC2131] DHCPREQUEST to the broadcast address as specified in [RFC2131]
Section 4.4.2. Section 4.4.2.
skipping to change at page 7, line 25 skipping to change at page 7, line 43
previously obtained a routable IPv4 address on the "most likely" previously obtained a routable IPv4 address on the "most likely"
point of attachment, then the host enters the INIT state and sends a point of attachment, then the host enters the INIT state and sends a
DHCPDISCOVER packet to the broadcast address, as described in 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. If the host does not receive a response to
a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in
[RFC2131] Section 4.1. [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 IP broadcast address. the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
However, sending a DHCPREQUEST to the unicast address when in INIT- In the INIT-REBOOT state a DHCPREQUEST is sent to the broadcast
REBOOT state is not appropriate since it is possible that the client address so that the host will receive a response regardless of
has moved to another subnet, and therefore the DHCPREQUEST needs to whether the cached IP address is correct for the network to which it
be forwarded to and from the DHCP server by a DHCP Relay so that the has connected.
response can be broadcast. This ensures that the host will receive a
response regardless of whether the cached IP address is correct for Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
the network to which it has connected. not appropriate since if the 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.
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.
[RFC2131] Section 3.2 states that if the host possesses a valid [RFC2131] Section 3.2 states that if the host possesses a valid
routable IPv4 address on the "most likely" network and does not routable IPv4 address on the "most likely" network and does not
receive a response after employing the retransmission algorithm, the receive a response after employing the retransmission algorithm, 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.
This is preferable to assigning a Link-Local IPv4 address if the host This is preferable to assigning a Link-Local IPv4 address if the host
has good reason to believe that it remains connected to a network on has good reason to believe that it remains connected to a network on
skipping to change at page 8, line 21 skipping to change at page 8, line 43
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. In order to avoid inappropriate assignment of an IPv4
Link-Local address, it is RECOMMENDED that such an address not be Link-Local address, it is RECOMMENDED that such an address not be
assigned until the DHCP client has retransmitted at least 3 times. assigned until the DHCP client has retransmitted at least 3 times.
3. IANA Considerations 3. Constants
The suggested default value of REACHABILITY_TIMER is 200 ms. This value
was chosen so as to accomodate the maximum retransmission timer likely
to be experienced on an Ethernet network.
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.
4. 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
it is inadvisable for a host to adjust its security based on which 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 network it believes it is attached to. For example, it would be
inappropriate for a host to disable its personal firewall based on inappropriate for a host to disable its personal firewall based on
the believe that it had connected to a home network. the belief that it had connected to a home network.
ARP [RFC826] traffic is inherently insecure, so that the reachability ARP [RFC826] traffic is inherently insecure, so that the reachability
test described in Section 1.3 can be easily spoofed by an attacker, test described in Section 1.3 can be easily spoofed by an attacker,
leading a host to conclude that it remained attached to a former leading a host to conclude that it remained attached to a former
network. Similarly, where DHCP [RFC2131] traffic is not secured, an network. Similarly, where DHCP [RFC2131] traffic is not secured, an
attacker could masquerade as a DHCP server, in order to convince the attacker could masquerade as a DHCP server, in order to convince the
host that it was attached to a particular network. host that it was attached to a particular network.
Where secure detection of network attachment is required, a host MAY Where secure detection of network attachment is required, a host MAY
wish to skip the ARP-based reachability test entirely since it cannot wish to skip the ARP-based reachability test entirely since it cannot
be secured, and go immediately to the IPv4 address acquisition phase, be secured, and go immediately to the IPv4 address acquisition phase,
utilizing authenticated DHCP [RFC3118]. utilizing authenticated DHCP [RFC3118].
5. References 6. References
5.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
Transmission on Ethernet Hardware", STD 37, RFC 826, November Transmission on Ethernet Hardware", STD 37, RFC 826, November
1982. 1982.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991. PARC, September 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell
University, March 1997.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[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-10.txt, October progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October
2003. 2003.
5.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.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998. Protocol (EAP)", RFC 2284, March 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
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.
[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]
skipping to change at page 11, line 30 skipping to change at page 12, line 30
can be considered a "strong" hint. can be considered a "strong" hint.
For networks running over PPP [RFC1661], "weak" hints include the For networks running over PPP [RFC1661], "weak" hints include the
link characteristics negotiated in LCP, and the associated phone link characteristics negotiated in LCP, and the associated phone
number. The IP parameters negotiated in IPCP are considered a number. The IP parameters negotiated in IPCP are considered a
"strong" hint. "strong" hint.
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]. Link-layer discovery traffic 802.1X authentication [IEEE8021X]. Link-layer discovery traffic
includes Link Layer Discovery Protocol [IEEE8021AB] traffic as well includes Link Layer Discovery Protocol (LLDP) [IEEE8021AB] traffic as
as network identification information passed in the EAP- well as network identification information passed in the EAP-
Request/Identity or within an EAP method exchange, as defined in EAP Request/Identity or within an EAP method exchange, as defined in EAP
[RFC2284]. [RFC2284].
For example, LLDP advertisements can provide information on the IP For example, LLDP advertisements can provide information on the IP
address or VLANs supported by the device. These hints, if provided, address or VLANs supported by the device. These hints, if provided,
are considered "strong". When used with IEEE 802.1X authentication are considered "strong". When used with IEEE 802.1X authentication
[IEEE8021X], the EAP-Request/Identity exchange may contain the name [IEEE8021X], the EAP-Request/Identity exchange may contain the name
of the authenticator, also providing information on the potential of the authenticator, also providing information on the potential
network. Similarly, during the EAP method exchange the authenticator network. Similarly, during the EAP method exchange the authenticator
may supply information that may be helpful in identifying the network may supply information that may be helpful in identifying the network
skipping to change at page 12, line 10 skipping to change at page 13, line 10
capabilities, as well as information on whether the station is capabilities, as well as information on whether the station is
operating in Infrastructure or Adhoc mode. As described in operating in Infrastructure or Adhoc 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 [IEEE8021X] authentication. This
implies that a single SSID may offer access to multiple VLANs, and in implies that a single SSID may offer access to multiple VLANs, and in
practice most large WLAN deployments offer access to multiple 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; on the other hand, a necessarily remain within the same subnet, a Station associating to a
Station associating to a different SSID is likely to have changed different SSID is likely to have changed subnets.
subnets.
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. Such hints are considered Beacon and Probe Response messages. Such hints are considered
"strong"; all other IEEE 802.11 hints are considered "weak". "strong"; all other IEEE 802.11 hints are considered "weak".
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at page 13, line 29 skipping to change at page 14, line 28
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-03.txt>, and expires This memo is filed as <draft-ietf-dhc-dna-ipv4-04.txt>, and expires
April 22, 2004. April 22, 2004.
 End of changes. 

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