draft-ietf-6man-ipv6-subnet-model-11.txt   draft-ietf-6man-ipv6-subnet-model-12.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: October 22, 2010 Oracle, Inc. Expires: October 29, 2010 Oracle, Inc.
April 20, 2010 April 27, 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-11 draft-ietf-6man-ipv6-subnet-model-12
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 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on October 22, 2010. This Internet-Draft will expire on October 29, 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 10, line 37 skipping to change at page 10, line 37
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. An address Advertisement Message with no on-link prefix advertised. An address
could be acquired through the DHCPv6 IA_NA option (which does not could be acquired through the DHCPv6 IA_NA option (which does not
include a prefix length), or through manual configuration (if no include a prefix length), or through manual configuration (if no
prefix length is specified). The host incorrectly assumes an prefix length is specified). The host incorrectly assumes an
invented prefix is on-link. This invented prefix typically is a /64 invented prefix is on-link. This invented prefix typically is a /64
that was written by the developer of the API as a "default" prefix that was written by the developer of the operating system network
length when a length isn't specified. This may cause the API to seem module API to any IPv6 application as a "default" prefix length when
to work in the case of a network interface initiating SLAAC, however a length isn't specified. This may cause the API to seem to work in
it can cause connectivity problems in NBMA networks. Having the case of a network interface initiating SLAAC, however it can
incorrectly assumed an invented prefix, the host performs address cause connectivity problems in NBMA networks. Having incorrectly
resolution when the host should send all non-link-local traffic to a assumed an invented prefix, the host performs address resolution when
default router. Neither the router nor any other host will respond the host should send all non-link-local traffic to a default router.
to the address resolution, preventing this host from sending IPv6 Neither the router nor any other host will respond to the address
traffic. resolution, preventing this host from sending IPv6 traffic.
6. Updates to RFC 4861 6. Updates to RFC 4861
This document deprecates the following two bullets from the on-link This document deprecates the following two bullets from the on-link
definition in section 2.1 of [RFC4861]: definition in section 2.1 of [RFC4861]:
o a Neighbor Advertisement message is received for the (target) o a Neighbor Advertisement message is received for the (target)
address, or address, or
o any Neighbor Discovery message is received from the address. o any Neighbor Discovery message is received from the address.
 End of changes. 4 change blocks. 
13 lines changed or deleted 13 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/