draft-ietf-6man-ipv6-subnet-model-04.txt   draft-ietf-6man-ipv6-subnet-model-05.txt 
Network Working Group H. Singh Network Working Group H. Singh
Internet-Draft W. Beebee Internet-Draft W. Beebee
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: November 8, 2009 E. Nordmark Expires: November 16, 2009 E. Nordmark
Sun Microsystems Sun Microsystems
May 7, 2009 May 15, 2009
IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes
draft-ietf-6man-ipv6-subnet-model-04 draft-ietf-6man-ipv6-subnet-model-05
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. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 8, 2009. This Internet-Draft will expire on November 16, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 41 skipping to change at page 3, line 41
in the Prefix List. All the prefixes that are on the Prefix List, in the Prefix List. All the prefixes that are on the Prefix List,
i.e., have not yet timed out, are considered to be on-link. i.e., have not yet timed out, are considered to be on-link.
The on-link definition in the Terminology section of [RFC4861], as The on-link definition in the Terminology section of [RFC4861], as
modified by this document, defines the complete list of cases where modified by this document, defines the complete list of cases where
an address is considered on-link. Individual address entries can be an address is considered on-link. Individual address entries can be
expired by the Neighbor Unreachability Detection mechanism. expired by the Neighbor Unreachability Detection mechanism.
IPv6 packets sent using the Conceptual Sending Algorithm as described IPv6 packets sent using the Conceptual Sending Algorithm as described
in [RFC4861] only trigger address resolution for IPv6 addresses that in [RFC4861] only trigger address resolution for IPv6 addresses that
are on-link. Note that transmission of ND messages is not governed are on-link. Packets to any other address are sent to a default
by the Conceptual Sending Algorithm. Packets to any other address router. If there is no default router, then the node should send an
are sent to a default router. If there is no default router, then ICMPv6 Destination Unreachable indication as specified in [RFC4861] -
the node should send an ICMPv6 Destination Unreachable indication as more details are provided in the Host Behavior and Rules section.
specified in [RFC4861] - more details are provided in the Host (Note that [RFC4861] changed the behavior when the Default Router
Behavior and Rules section. (Note that [RFC4861] changed the List is empty. In the old version of Neighbor Discovery [RFC2461],
behavior when the Default Router List is empty. The behavior in the if the Default router List is empty, rather than sending the ICMPv6
old version of Neighbor Discovery [RFC2461] was different when there Destination Unreachable indication, the [RFC2461] node assumed that
were no default routers.) Note that ND is scoped to a single link. the destination was on-link.") Note that ND is scoped to a single
All Neighbor Solicitaton responses are assumed to be sent our the link. All Neighbor Solicitation responses are assumed to be sent out
same interface on which the corresponding query was received. the same interface on which the corresponding query was received
without using the Conceptual Sending Algorithm.
Failure of host implementations to correctly implement the IPv6 Failure of host implementations to correctly implement the IPv6
subnet model can result in lack of IPv6 connectivity. See the subnet model can result in lack of IPv6 connectivity. See the
Observed Incorrect Implementation Behavior section for details. Observed Incorrect Implementation Behavior section for details.
This document deprecates the last two bullets from the definition of This document deprecates the last two bullets from the definition of
on-link from [RFC4861] to address security concerns arising from on-link from [RFC4861] to address security concerns arising from
particular ND implementations. particular ND implementations.
Host behavior is clarified in the Host Behavior and Rules section. Host behavior is clarified in the Host Behavior and Rules section.
skipping to change at page 10, line 14 skipping to change at page 10, line 14
8. Contributors 8. Contributors
Thomas Narten contributed significant text and provided substantial Thomas Narten contributed significant text and provided substantial
guidance to the production of this document. guidance to the production of this document.
9. Acknowledgements 9. Acknowledgements
Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph
Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh
Krishnan, Josh Littlefield, David Miles, Madhu Sudan, Jinmei Tatuya, Krishnan, Josh Littlefield, Bert Manfredi, David Miles, Madhu Sudan,
Dave Thaler, Bernie Volz, and Vlad Yasevich for their consistent Jinmei Tatuya, Dave Thaler, Bernie Volz, and Vlad Yasevich for their
input, ideas and review during the production of this document. The consistent input, ideas and review during the production of this
security problem related to an NS message that provides one reason document. The security problem related to an NS message that
for invalidating a part of the on-link definition was found by David provides one reason for invalidating a part of the on-link definition
Miles. Jinmei Tatuya found the security problem to also exist with was found by David Miles. Jinmei Tatuya found the security problem
an RS message. to also exist with an RS message.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
10.2. Informative References 10.2. Informative References
 End of changes. 6 change blocks. 
22 lines changed or deleted 23 lines changed or added

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