draft-ietf-dna-simple-10.txt   draft-ietf-dna-simple-11.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4861 (if approved) G. Daley Updates: 4861 (if approved) G. Daley
Intended status: Standards Track NetStar Networks Intended status: Standards Track NetStar Networks
Expires: April 29, 2010 October 26, 2009 Expires: April 29, 2010 October 26, 2009
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-10 draft-ietf-dna-simple-11
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6
4.2. Steps involved in detecting link change . . . . . . . . . 6 4.2. Steps involved in detecting link change . . . . . . . . . 6
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7
4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7
4.5. Contents of the Neighbor Discovery messages . . . . . . . 8 4.5. Contents of the Neighbor Discovery messages . . . . . . . 8
4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8
4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8
4.6. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 9 4.6. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 9
4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 10 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9
4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 11 4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 10
4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11
4.9. Recommended retransmission behavior . . . . . . . . . . . 12 4.9. Recommended retransmission behavior . . . . . . . . . . . 11
5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Issues with confirming manually assigned addresses . 17 Appendix A. Issues with confirming manually assigned addresses . 17
skipping to change at page 9, line 45 skipping to change at page 9, line 45
Where the Rapid-Commit option has not been used, a present DHCP Where the Rapid-Commit option has not been used, a present DHCP
server will respond with an ADVERTISE message. The IP address server will respond with an ADVERTISE message. The IP address
contained in the Identity Association (IA_TA or IA_NA) will contain contained in the Identity Association (IA_TA or IA_NA) will contain
an IP Address which is operable for the link. an IP Address which is operable for the link.
Where Rapid-Commit option has been sent, a DHCPv6 server will respond Where Rapid-Commit option has been sent, a DHCPv6 server will respond
with REPLY. In addition to being operable, this address is allocated with REPLY. In addition to being operable, this address is allocated
to the host for the lease duration indicated in the Identity to the host for the lease duration indicated in the Identity
Association. Association.
Where the host has acquired addresses from DHCPv6 or the host does
not have a global prefix, it MAY prefer to use DHCPv6 probe messages
in parallel with the Neighbor Discovery probing. The DHCPv6 probing
procedures described in this document do not imply any changes to the
DHCPv6 protocol or state machine.
In that case, when the host receives a link-layer indication, it
sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This
message contains an Identity Association for either a Temporary
Address (IA_TA) or Non-Temporary Address (IA_NA) . Where an existing
valid address is being tested for operability, this address should be
placed in the Identity Association's IAADDR element, and the DUID
associated with that address should be copied to the DHCP SOLICIT
from the SDAT.
In order to quickly acquire a new address in the case that link
change has occurred, this SOLICIT message MAY contain the Rapid-
Commit option.
Where the Rapid-Commit option has not been used, a present DHCP
server will respond with an ADVERTISE message. The IP address
contained in the Identity Association (IA_TA or IA_NA) will contain
an IP Address which is operable for the link.
Where Rapid-Commit option has been sent, a DHCPv6 server will respond
with REPLY. In addition to being operable, this address is allocated
to the host for the lease duration indicated in the Identity
Association.
4.7. Response Gathering 4.7. Response Gathering
When a responding Neighbor Advertisement is received from a test When a responding Neighbor Advertisement is received from a test
node, the host MUST verify that both the IPv6 and link layer (MAC) node, the host MUST verify that both the IPv6 and link layer (MAC)
addresses of the test node match the expected values before utilizing addresses of the test node match the expected values before utilizing
the configuration associated with the detected network (prefixes, MTU the configuration associated with the detected network (prefixes, MTU
etc.). etc.).
On reception of a Router Advertisement or advertising DHCPv6 message On reception of a Router Advertisement or advertising DHCPv6 message
(a REPLY or ADVERTISE) which contains prefixes that intersect with (a REPLY or ADVERTISE) which contains prefixes that intersect with
 End of changes. 4 change blocks. 
33 lines changed or deleted 4 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/