draft-ietf-6man-ipv6-subnet-model-10.txt   draft-ietf-6man-ipv6-subnet-model-11.txt 
Network Working Group H. Singh Network Working Group H. Singh
Internet-Draft W. Beebee Internet-Draft W. Beebee
Updates: 4861 (if approved) Cisco Systems, Inc. Updates: 4861 (if approved) Cisco Systems, Inc.
Intended status: Standards Track E. Nordmark Intended status: Standards Track E. Nordmark
Expires: September 26, 2010 Oracle, Inc. Expires: October 22, 2010 Oracle, Inc.
March 25, 2010 April 20, 2010
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-10 draft-ietf-6man-ipv6-subnet-model-11
Abstract Abstract
IPv6 specifies a model of a subnet that is different than the IPv4 IPv6 specifies a model of a subnet that is different than the IPv4
subnet model. The subtlety of the differences has resulted in subnet model. The subtlety of the differences has resulted in
incorrect implementations that do not interoperate. This document incorrect implementations that do not interoperate. This document
spells out the most important difference: that an IPv6 address isn't spells out the most important difference: that an IPv6 address isn't
automatically associated with an IPv6 on-link prefix. This document automatically associated with an IPv6 on-link prefix. This document
also updates (partially due to security concerns caused by incorrect also updates (partially due to security concerns caused by incorrect
implementations) a part of the definition of on-link from [RFC4861]. implementations) a part of the definition of on-link from [RFC4861].
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on October 22, 2010.
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 September 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Observed Incorrect Implementation Behavior . . . . . . . . . . 9 5. Observed Incorrect Implementation Behavior . . . . . . . . . . 10
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Updates to RFC 4861 . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
IPv4 implementations typically associate a netmask with an address IPv4 implementations typically associate a netmask with an address
skipping to change at page 10, line 32 skipping to change at page 10, line 32
not change the default behavior mentioned above for addresses and not change the default behavior mentioned above for addresses and
prefixes not specified. [RFC4943] provides justification for prefixes not specified. [RFC4943] provides justification for
these rules. these rules.
5. Observed Incorrect Implementation Behavior 5. Observed Incorrect Implementation Behavior
One incorrect implementation behavior illustrates the severe One incorrect implementation behavior illustrates the severe
consequences when the IPv6 subnet model is not understood by the consequences when the IPv6 subnet model is not understood by the
implementers of several popular host operating systems. In an access implementers of several popular host operating systems. In an access
concentrator network ([RFC4388]), a host receives a Router concentrator network ([RFC4388]), a host receives a Router
Advertisement Message with no on-link prefix advertised. The host Advertisement Message with no on-link prefix advertised. An address
incorrectly assumes an invented prefix is on-link. This invented could be acquired through the DHCPv6 IA_NA option (which does not
prefix typically is a /64 that was written by the developer of the include a prefix length), or through manual configuration (if no
API as a "default" prefix length when a length isn't specified. This prefix length is specified). The host incorrectly assumes an
may cause the API to seem to work in the case of a network interface invented prefix is on-link. This invented prefix typically is a /64
initiating SLAAC, however it can cause connectivity problems in NBMA that was written by the developer of the API as a "default" prefix
networks. Having incorrectly assumed an invented prefix, the host length when a length isn't specified. This may cause the API to seem
performs address resolution when the host should send all non-link- to work in the case of a network interface initiating SLAAC, however
local traffic to a default router. Neither the router nor any other it can cause connectivity problems in NBMA networks. Having
host will respond to the address resolution, preventing this host incorrectly assumed an invented prefix, the host performs address
from sending IPv6 traffic. resolution when the host should send all non-link-local traffic to a
default router. Neither the router nor any other host will respond
to the address resolution, preventing this host from sending IPv6
traffic.
6. Conclusion 6. Updates to RFC 4861
This document deprecates the following two bullets from the on-link
definition in section 2.1 of [RFC4861]:
o a Neighbor Advertisement message is received for the (target)
address, or
o any Neighbor Discovery message is received from the address.
7. Conclusion
This document clarifies and summarizes the relationship between links This document clarifies and summarizes the relationship between links
and subnet prefixes described in [RFC4861]. Configuration of an IPv6 and subnet prefixes described in [RFC4861]. Configuration of an IPv6
address does not imply the existence of corresponding on-link address does not imply the existence of corresponding on-link
prefixes. One should also look at API considerations for prefix prefixes. One should also look at API considerations for prefix
length as described in last paragraph of section 4.2 of [RFC4903]. length as described in last paragraph of section 4.2 of [RFC4903].
This document also updates the definition of on-link from [RFC4861] This document also updates the definition of on-link from [RFC4861]
by retracting the last two bullets. by deprecating the last two bullets.
7. Security Considerations 8. Security Considerations
This document addresses a security concern present in [RFC4861]. As This document addresses a security concern present in [RFC4861]. As
a result, the last two bullets of the on-link definition in [RFC4861] a result, the last two bullets of the on-link definition in [RFC4861]
have been retracted. US-CERT Vulnerability Note VU#472363 lists the have been deprecated. US-CERT Vulnerability Note VU#472363 lists the
implementations affected. implementations affected.
8. IANA Considerations 9. IANA Considerations
None. None.
9. Contributors 10. 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.
10. Acknowledgements 11. 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, Bert Manfredi, David Miles, Madhu Sudan, Krishnan, Josh Littlefield, Bert Manfredi, David Miles, Madhu Sudan,
Jinmei Tatuya, Dave Thaler, Bernie Volz, and Vlad Yasevich for their Jinmei Tatuya, Dave Thaler, Bernie Volz, and Vlad Yasevich for their
consistent input, ideas and review during the production of this consistent input, ideas and review during the production of this
document. The security problem related to an NS message that document. The security problem related to an NS message that
provides one reason for invalidating a part of the on-link definition provides one reason for invalidating a part of the on-link definition
was found by David Miles. Jinmei Tatuya found the security problem was found by David Miles. Jinmei Tatuya found the security problem
to also exist with an RS message. to also exist with an RS message.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
11.2. Informative References 12.2. Informative References
[RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting [RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, August 1985. Procedure", STD 5, RFC 950, August 1985.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993. Aggregation Strategy", RFC 1519, September 1993.
 End of changes. 18 change blocks. 
50 lines changed or deleted 58 lines changed or added

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