draft-ietf-6man-ipv6-subnet-model-07.txt   draft-ietf-6man-ipv6-subnet-model-08.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: June 26, 2010 Sun Microsystems Expires: September 6, 2010 Sun Microsystems
December 23, 2009 March 5, 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-07 draft-ietf-6man-ipv6-subnet-model-08
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 June 26, 2010. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Observed Incorrect Implementation Behavior . . . . . . . . . . 9 4. Observed Incorrect Implementation Behavior . . . . . . . . . . 10
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. 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
skipping to change at page 10, line 15 skipping to change at page 10, line 15
error message) as specified in the Terminology section of error message) as specified in the Terminology section of
[RFC4861]. [RFC4861].
On-link information concerning particular addresses and prefixes On-link information concerning particular addresses and prefixes
can make those specific addresses and prefixes on-link, but does can make those specific addresses and prefixes on-link, but does
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. Hosts MUST verify that on-link information is still valid after 5. Hosts MUST verify that on-link information is still valid after
IPv6 interface re-initialization before using cached on-link IPv6 interface re-initialization. Failure to do so may lead to
determination information. Failure to do so may lead to lack of lack of IPv6 network connectivity. For example, a host receives
IPv6 network connectivity. For example, a host receives an RA an RA from a router with on-link prefix A. The host powers down.
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 4. 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 and performs incorrectly assumes an invented prefix is on-link. This invented
address resolution when the host should send all non-link-local prefix typically is a /64 that was written by the developer of the
traffic to a default router. Neither the router nor any other host API as a "default" prefix length when a length isn't specified. This
will respond to the address resolution, preventing this host from may cause the API to seem to work in the case of a network interface
sending IPv6 traffic. initiating SLAAC, however it can cause connectivity problems in NBMA
networks. Having incorrectly assumed an invented prefix, the host
performs address 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.
5. Conclusion 5. 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 6. 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.
 End of changes. 8 change blocks. 
28 lines changed or deleted 31 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/