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