draft-ietf-6man-ipv6-subnet-model-08.txt   draft-ietf-6man-ipv6-subnet-model-09.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 6, 2010 Sun Microsystems Expires: September 10, 2010 Sun Microsystems
March 5, 2010 March 9, 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-08 draft-ietf-6man-ipv6-subnet-model-09
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].
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 September 6, 2010. This Internet-Draft will expire on September 10, 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Observed Incorrect Implementation Behavior . . . . . . . . . . 10 4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Observed Incorrect Implementation Behavior . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction
IPv4 implementations typically associate a netmask with an address IPv4 implementations typically associate a netmask with an address
when an IPv4 address is assigned to an interface. That netmask when an IPv4 address is assigned to an interface. That netmask
together with the IPv4 address designates an on-link prefix. Nodes together with the IPv4 address designates an on-link prefix. Nodes
consider addresses covered by an on-link prefix to be directly consider addresses covered by an on-link prefix to be directly
attached to the same link as the sending node, i.e., they send attached to the same link as the sending node, i.e., they send
traffic for such addresses directly rather than to a router. See traffic for such addresses directly rather than to a router. See
section 3.3.1 in [RFC1122]. Prior to the development of subnetting section 3.3.1 in [RFC1122]. Prior to the development of subnetting
[RFC0950] and Classless Inter-Domain Routing (CIDR) [RFC1519], an [RFC0950] and Classless Inter-Domain Routing (CIDR) [RFC1519], an
address's netmask could be derived directly from the address simply address's netmask could be derived directly from the address simply
skipping to change at page 5, line 20 skipping to change at page 5, line 27
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.
2. Host Behavior 3. Host Behavior
1. The original Neighbor Discovery (ND) specification [RFC4861] was 1. The original Neighbor Discovery (ND) specification [RFC4861] was
unclear in its usage of the term on-link in a few places. In unclear in its usage of the term on-link in a few places. In
IPv6, an address is on-link (with respect to a specific link), if IPv6, an address is on-link (with respect to a specific link), if
the address has been assigned to an interface attached to that the address has been assigned to an interface attached to that
link. Any node attached to the link can send a datagram directly link. Any node attached to the link can send a datagram directly
to an on-link address without forwarding the datagram through a to an on-link address without forwarding the datagram through a
router. However, in order for a node to know that a destination router. However, in order for a node to know that a destination
is on-link, it must obtain configuration information to that is on-link, it must obtain configuration information to that
effect. In IPv6, there are two main ways of maintaining effect. In IPv6, there are two main ways of maintaining
skipping to change at page 8, line 44 skipping to change at page 9, line 7
the scope of ND processing from one link stays local to that the scope of ND processing from one link stays local to that
link. That is, when responding to a NS, the NA would be sent out link. That is, when responding to a NS, the NA would be sent out
on the same link on which it was received. Likewise, a host on the same link on which it was received. Likewise, a host
would not respond to a received NS for an address assigned to an would not respond to a received NS for an address assigned to an
interface on a different link. Although implementations may interface on a different link. Although implementations may
choose to implement Neighbor Discovery using a single data choose to implement Neighbor Discovery using a single data
structure that merges the Neighbor Caches of all interfaces, an structure that merges the Neighbor Caches of all interfaces, an
implementation's behavior must be consistent with the above implementation's behavior must be consistent with the above
model. model.
3. Host Rules 4. Host Rules
A correctly implemented IPv6 host MUST adhere to the following rules: A correctly implemented IPv6 host MUST adhere to the following rules:
1. The assignment of an IPv6 address, whether through IPv6 stateless 1. The assignment of an IPv6 address, whether through IPv6 stateless
address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual
configuration MUST NOT implicitly cause a prefix derived from configuration MUST NOT implicitly cause a prefix derived from
that address to be treated as on-link and added to the Prefix that address to be treated as on-link and added to the Prefix
List. A host considers a prefix to be on-link only through List. A host considers a prefix to be on-link only through
explicit means, such as those specified in the on-link definition explicit means, such as those specified in the on-link definition
in the Terminology section of [RFC4861], as modified by this in the Terminology section of [RFC4861], as modified by this
skipping to change at page 10, line 27 skipping to change at page 10, line 39
an RA from a router with on-link prefix A. The host powers down. an RA from a router with on-link prefix A. The host powers down.
During the power off, the router sends out prefix A with on-link During the power off, the router sends out prefix A with on-link
bit set and a zero lifetime to indicate a renumbering. The host bit set and a zero lifetime to indicate a renumbering. The host
misses the renumbering. The host powers on and comes online. misses the renumbering. The host powers on and comes online.
Then, the router sends an RA with no PIO. The host uses cached Then, the router sends an RA with no PIO. The host uses cached
on-link prefix A and issues NS's instead of sending traffic to a on-link prefix A and issues NS's instead of sending traffic to a
default router. The "Observed Incorrect Implementation Behavior" default router. The "Observed Incorrect Implementation Behavior"
section below describes how this can result in lack of IPv6 section below describes how this can result in lack of IPv6
connectivity. connectivity.
4. 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. The host
incorrectly assumes an invented prefix is on-link. This invented incorrectly assumes an invented prefix is on-link. This invented
prefix typically is a /64 that was written by the developer of the prefix typically is a /64 that was written by the developer of the
API as a "default" prefix length when a length isn't specified. This API as a "default" prefix length when a length isn't specified. This
may cause the API to seem to work in the case of a network interface may cause the API to seem to work in the case of a network interface
initiating SLAAC, however it can cause connectivity problems in NBMA initiating SLAAC, however it can cause connectivity problems in NBMA
networks. Having incorrectly assumed an invented prefix, the host networks. Having incorrectly assumed an invented prefix, the host
performs address resolution when the host should send all non-link- performs address resolution when the host should send all non-link-
local traffic to a default router. Neither the router nor any other local traffic to a default router. Neither the router nor any other
host will respond to the address resolution, preventing this host host will respond to the address resolution, preventing this host
from sending IPv6 traffic. from sending IPv6 traffic.
5. Conclusion 6. 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 retracting the last two bullets.
6. Security Considerations 7. 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 retracted. US-CERT Vulnerability Note VU#472363 lists the
implementations affected. implementations affected.
7. IANA Considerations 8. IANA Considerations
None. None.
8. Contributors 9. 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 10. 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.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
10.2. Informative References 11.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. 16 change blocks. 
28 lines changed or deleted 38 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/