draft-ietf-dhc-dna-ipv4-02.txt   draft-ietf-dhc-dna-ipv4-03.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-02.txt> <draft-ietf-dhc-dna-ipv4-03.txt>
28 September 2003 9 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 13 skipping to change at page 2, line 13
network attachment by mobile hosts. network attachment by mobile hosts.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements .................................... 4 1.1 Requirements .................................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Framework ................................................ 4 2. Framework ................................................ 4
2.1 Reachability test ............................... 5 2.1 Reachability test ............................... 5
2.2 Packet format ................................... 5 2.2 Packet format ................................... 5
2.3 IPv4 Address Acquisition ........................ 6 2.3 IPv4 Address Acquisition ........................ 7
3. IANA Considerations ...................................... 8 3. IANA Considerations ...................................... 8
4. Security Considerations .................................. 8 4. Security Considerations .................................. 8
5. References ............................................... 8 5. References ............................................... 8
5.1 Normative references ............................ 8 5.1 Normative references ............................ 8
5.2 Informative references .......................... 9 5.2 Informative references .......................... 9
Acknowledgments .............................................. 10 Acknowledgments .............................................. 10
Authors' Addresses ........................................... 10 Authors' Addresses ........................................... 10
Appendix A - Hints ........................................... 11 Appendix A - Hints ........................................... 11
Intellectual Property Statement .............................. 12 Intellectual Property Statement .............................. 12
Full Copyright Statement ..................................... 12 Full Copyright Statement ..................................... 12
skipping to change at page 5, line 49 skipping to change at page 5, line 49
last resort, these addresses do not count as a valid last resort, these addresses do not 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). Since the host has not yet confirmed the subnet on which (ar$sha).
it is attached, it MUST set the sender protocol address field
(ar$spa) to 0.0.0.0. This prevents poisoning of the ARP cache with a
(potentially invalid) sender IPv4 address.
Since the ARP Response is sent to the sender hardware address, the If the host has a valid globally routable IP address on the most
contents of the sender protocol address field do not affect delivery likely point of attachment, then it SHOULD set the sender protocol
of the ARP Response. Since existing implementations do not create an address field (ar$spa) to that address. It is assumed that the host
ARP cache entry for 0.0.0.0, using this as the sender protocol had previously done duplicate address detection so that an address
address is harmless. conflict is unlikely.
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.
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 protocol address field (ar$spa) set to the unspecified
address. 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 target
hardware address field (ar$tha) and the IPv4 address in the target hardware address field (ar$tha) and the IPv4 address in the target
protocol address field (ar$tpa) are matched against the list of protocol address field (ar$tpa) 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.
skipping to change at page 10, line 19 skipping to change at page 10, line 27
[IEEE80211] [IEEE80211]
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-1999, 1999. IEEE Std. 802.11-1999, 1999.
Acknowledgments Acknowledgments
The authors would like to acknowledge Erik Guttman and Erik Nordmark The authors would like to acknowledge Greg Daley of Monash
of Sun Microsystems, Ted Lemon of Nominum and Thomas Narten of IBM University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted
for contributions to this document. Lemon of Nominum and Thomas Narten of IBM for contributions to this
document.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
skipping to change at page 13, line 29 skipping to change at page 13, line 29
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-02.txt>, and expires This memo is filed as <draft-ietf-dhc-dna-ipv4-03.txt>, and expires
February 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/