draft-ietf-6man-ipv6-subnet-model-09.txt   draft-ietf-6man-ipv6-subnet-model-10.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 10, 2010 Sun Microsystems Expires: September 26, 2010 Oracle, Inc.
March 9, 2010 March 25, 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-09 draft-ietf-6man-ipv6-subnet-model-10
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 to IETF 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
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 10, 2010. 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Observed Incorrect Implementation Behavior . . . . . . . . . . 9 5. Observed Incorrect Implementation Behavior . . . . . . . . . . 9
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 4, line 31 skipping to change at page 4, line 31
address's netmask could be derived directly from the address simply address's netmask could be derived directly from the address simply
by determining whether it was a Class A, B or C address. Today, by determining whether it was a Class A, B or C address. Today,
assigning an address to an interface also requires specifying a assigning an address to an interface also requires specifying a
netmask to use. In the absence of specifying a specific netmask when netmask to use. In the absence of specifying a specific netmask when
assigning an address, some implementations would fall back to assigning an address, some implementations would fall back to
deriving the netmask from the class of the address. deriving the netmask from the class of the address.
The behavior of IPv6 as specified in Neighbor Discovery [RFC4861] is The behavior of IPv6 as specified in Neighbor Discovery [RFC4861] is
quite different. The on-link determination is separate from the quite different. The on-link determination is separate from the
address assignment. A host can have IPv6 addresses without any address assignment. A host can have IPv6 addresses without any
related on-link prefixes or has on-link prefixes that are not related related on-link prefixes or can have on-link prefixes that are not
to any IPv6 addresses that are assigned to the host. Any assigned related to any IPv6 addresses that are assigned to the host. Any
address on an interface should initially be considered as having no assigned address on an interface should initially be considered as
internal structure as shown in [RFC4291]. having no internal structure as shown in [RFC4291].
In IPv6, by default, a host treats only the link-local prefix as on- In IPv6, by default, a host treats only the link-local prefix as on-
link. link.
The reception of a Prefix Information Option (PIO) with the L-bit set The reception of a Prefix Information Option (PIO) with the L-bit set
[RFC4861] and a non-zero valid lifetime creates (or updates) an entry [RFC4861] and a non-zero valid lifetime creates (or updates) an entry
in the Prefix List. All prefixes on a host's Prefix List, i.e., have in the Prefix List. All prefixes on a host's Prefix List (i.e., have
not yet timed out, are considered to be on-link by that host. not yet timed out) are considered to be on-link by that host.
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 a modified by this document, defines the complete list of cases where a
host considers an address to be on-link. Individual address entries host considers an address to be on-link. Individual address entries
can be expired by the Neighbor Unreachability Detection mechanism. can be 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
the sender considers to be on-link. Packets to any other address are the sender considers to be on-link. Packets to any other address are
sent to a default router. If there is no default router, then the sent to a default router. If there is no default router, then the
node should send an ICMPv6 Destination Unreachable indication as node should send an ICMPv6 Destination Unreachable indication as
specified in [RFC4861] - more details are provided in the Host specified in [RFC4861] - more details are provided in the Host
Behavior and Rules section. (Note that [RFC4861] changed the Behavior and Host Rules sections. (Note that [RFC4861] changed the
behavior when the Default Router List is empty. In the old version behavior when the Default Router List is empty. In the old version
of Neighbor Discovery [RFC2461], if the Default router List is empty, of Neighbor Discovery [RFC2461], if the Default router List is empty,
rather than sending the ICMPv6 Destination Unreachable indication, rather than sending the ICMPv6 Destination Unreachable indication,
the [RFC2461] node assumed that the destination was on-link.") Note the [RFC2461] node assumed that the destination was on-link.") Note
that ND is scoped to a single link. All Neighbor Solicitation that ND is scoped to a single link. All Neighbor Solicitation
responses are assumed to be sent out the same interface on which the responses are assumed to be sent out the same interface on which the
corresponding query was received without using the Conceptual Sending corresponding query was received without using the Conceptual Sending
Algorithm. Algorithm.
Failure of host implementations to correctly implement the IPv6 Failure of host implementations to correctly implement the IPv6
skipping to change at page 10, line 26 skipping to change at page 10, line 26
Unreachable indication (for example, a locally delivered Unreachable indication (for example, a locally delivered
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
IPv6 interface re-initialization. Failure to do so may lead to
lack of IPv6 network connectivity. For example, a host receives
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
bit set and a zero lifetime to indicate a renumbering. The host
misses the renumbering. The host powers on and comes online.
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
default router. The "Observed Incorrect Implementation Behavior"
section below describes how this can result in lack of IPv6
connectivity.
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. 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
skipping to change at page 13, line 33 skipping to change at page 13, line 28
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 2030 Phone: +1 978 936 2030
Email: wbeebee@cisco.com Email: wbeebee@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Erik Nordmark Erik Nordmark
Sun Microsystems Oracle, Inc.
17 Network Circle 17 Network Circle
Menlo Park, CA 94025 Menlo Park, CA 94025
USA USA
Phone: +1 650 786 2921 Phone: +1 650 786 2921
Email: erik.nordmark@sun.com Email: erik.nordmark@sun.com
 End of changes. 12 change blocks. 
30 lines changed or deleted 17 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/