rfc6964v2.txt   rfc6964.txt 
skipping to change at page 2, line 14 skipping to change at page 2, line 19
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. to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Enabling IPv6 Services Using ISATAP . . . . . . . . . . . . . 3 2. Enabling IPv6 Services Using ISATAP . . . . . . . . . . . . . 4
3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . 5 3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . 5 3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . 5
3.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . 5 3.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . 6
3.3. Reference Operational Scenario - Shared Prefix Model . . 5 3.3. Reference Operational Scenario - Shared Prefix Model . . 6
3.4. Reference Operational Scenario - Individual Prefix Model 9 3.4. Reference Operational Scenario - Individual Prefix Model 9
3.5. SLAAC Site Administration Guidance . . . . . . . . . . . 12 3.5. SLAAC Site Administration Guidance . . . . . . . . . . . 12
3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 14 3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 14
3.7. Considerations for Compatibility of Interface Identifiers 14 3.7. Considerations for Compatibility of Interface Identifiers 15
4. Manual Configuration . . . . . . . . . . . . . . . . . . . . 15 4. Manual Configuration . . . . . . . . . . . . . . . . . . . . 15
5. Scaling Considerations . . . . . . . . . . . . . . . . . . . 15 5. Scaling Considerations . . . . . . . . . . . . . . . . . . . 15
6. Site Renumbering Considerations . . . . . . . . . . . . . . . 15 6. Site Renumbering Considerations . . . . . . . . . . . . . . . 16
7. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 16 7. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 16
8. Alternative Approaches . . . . . . . . . . . . . . . . . . . 17 8. Alternative Approaches . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
End-user sites in the Internet today internally use IPv4 routing and End-user sites in the Internet today internally use IPv4 routing and
addressing for core operating functions, such as web browsing, file addressing for core operating functions, such as web browsing, file
sharing, network printing, email, teleconferencing, and numerous sharing, network printing, email, teleconferencing, and numerous
other site-internal networking services. Such sites typically have other site-internal networking services. Such sites typically have
an abundance of public and/or private IPv4 addresses for internal an abundance of public and/or private IPv4 addresses for internal
networking and are separated from the public Internet by firewalls, networking and are separated from the public Internet by firewalls,
packet filtering gateways, proxies, address translators, and other packet filtering gateways, proxies, address translators, and other
skipping to change at page 4, line 14 skipping to change at page 4, line 35
Notification (ECN) [RFC3168] mapping between the inner and outer IP Notification (ECN) [RFC3168] mapping between the inner and outer IP
headers to ensure expected per-hop behavior within well-managed headers to ensure expected per-hop behavior within well-managed
sites. sites.
The ISATAP service is based on two node types known as advertising The ISATAP service is based on two node types known as advertising
ISATAP routers and ISATAP hosts. (While out of scope for this ISATAP routers and ISATAP hosts. (While out of scope for this
document, a third node type known as non-advertising ISATAP routers document, a third node type known as non-advertising ISATAP routers
is defined in [ISATAP-UPDATE].) Each node may further have multiple is defined in [ISATAP-UPDATE].) Each node may further have multiple
ISATAP interfaces (i.e., one interface for each site) and may act as ISATAP interfaces (i.e., one interface for each site) and may act as
an advertising ISATAP router on some of those interfaces and a simple an advertising ISATAP router on some of those interfaces and a simple
ISATAP host on others. Hence, the node type is considered on a ISATAP host on others. Hence, the node type is considered on a per-
per-interface basis. interface basis.
Advertising ISATAP routers configure their ISATAP interfaces as Advertising ISATAP routers configure their ISATAP interfaces as
advertising router interfaces (see [RFC4861], Section 6.2.2). ISATAP advertising router interfaces (see [RFC4861], Section 6.2.2). ISATAP
hosts configure their ISATAP interfaces as simple host interfaces and hosts configure their ISATAP interfaces as simple host interfaces and
also coordinate their autoconfiguration operations with advertising also coordinate their autoconfiguration operations with advertising
ISATAP routers. In this sense, advertising ISATAP routers are ISATAP routers. In this sense, advertising ISATAP routers are
"servers" while ISATAP hosts are "clients" in the service model. "servers" while ISATAP hosts are "clients" in the service model.
Advertising ISATAP routers arrange to add their IPv4 addresses to the Advertising ISATAP routers arrange to add their IPv4 addresses to the
site's Potential Router List (PRL) so that ISATAP clients can site's Potential Router List (PRL) so that ISATAP clients can
skipping to change at page 12, line 20 skipping to change at page 12, line 18
shorter prefix 2001:db8::/48 into the IPv6 routing system, however, shorter prefix 2001:db8::/48 into the IPv6 routing system, however,
packets coming from 'E' may be directed to either 'A' or 'B'. In packets coming from 'E' may be directed to either 'A' or 'B'. In
that case, the advertising ISATAP routers must connect within a full that case, the advertising ISATAP routers must connect within a full
or partial mesh of IPv6 links the same as for the shared prefix model or partial mesh of IPv6 links the same as for the shared prefix model
and must either run a dynamic IPv6 routing protocol or configure and must either run a dynamic IPv6 routing protocol or configure
static routes so that incoming IPv6 packets can be forwarded to the static routes so that incoming IPv6 packets can be forwarded to the
correct serving router. correct serving router.
In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64 In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64
with the IPv6 address of the next hop toward 'B' in the mesh network with the IPv6 address of the next hop toward 'B' in the mesh network
as the next hop, and 'B' can configure the IPv6 route 2001:db8:0.1::/ as the next hop, and 'B' can configure the IPv6 route
64 with the IPv6 address of the next hop toward 'A' as the next hop. 2001:db8:0.1::/64 with the IPv6 address of the next hop toward 'A' as
Then, when 'A' receives a packet from the IPv6 Internet with the next hop. Then, when 'A' receives a packet from the IPv6
destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards Internet with destination address 2001:db8:0:2::5efe:192.0.2.34, it
the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses first forwards the packet toward 'B' over an IPv6 mesh link. 'B' in
ISATAP to forward the packet into the site, where IPv4 routing will turn uses ISATAP to forward the packet into the site, where IPv4
direct it to 'D'. In the same fashion, when 'B' receives a packet routing will direct it to 'D'. In the same fashion, when 'B'
from the IPv6 Internet with destination address receives a packet from the IPv6 Internet with destination address
2001:db8:0:1::5efe:192.0.2.18, it first forwards the packet toward 2001:db8:0:1::5efe:192.0.2.18, it first forwards the packet toward
'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the
packet into the site, where IPv4 routing will direct it to 'C'. packet into the site, where IPv4 routing will direct it to 'C'.
Finally, when host 'C' inside the site connects to host 'D' inside Finally, when host 'C' inside the site connects to host 'D' inside
the site, it has the option of using the native IPv4 service or the the site, it has the option of using the native IPv4 service or the
ISATAP IPv6-in-IPv4 encapsulation service. When there is operational ISATAP IPv6-in-IPv4 encapsulation service. When there is operational
assurance that IPv4 services between the two hosts are available, the assurance that IPv4 services between the two hosts are available, the
hosts may be better served to continue to use legacy IPv4 services in hosts may be better served to continue to use legacy IPv4 services in
order to avoid encapsulation overhead and to avoid any IPv4 order to avoid encapsulation overhead and to avoid any IPv4
protocol-41 filtering middleboxes that may be in the path. If 'C' protocol-41 filtering middleboxes that may be in the path. If 'C'
and 'D' may be in different IPv4 network partitions, however, IPv6 and 'D' may be in different IPv4 network partitions, however,
-in-IPv4 encapsulation should be used with one or both of routers 'A' IPv6-in-IPv4 encapsulation should be used with one or both of routers
and 'B' serving as intermediate gateways. 'A' and 'B' serving as intermediate gateways.
3.5. SLAAC Site Administration Guidance 3.5. SLAAC Site Administration Guidance
In common practice, firewalls, gateways, and packet filtering devices In common practice, firewalls, gateways, and packet filtering devices
of various forms are often deployed in order to divide the site into of various forms are often deployed in order to divide the site into
separate partitions. In both the shared and individual prefix models separate partitions. In both the shared and individual prefix models
described above, the entire site can be represented by the aggregate described above, the entire site can be represented by the aggregate
IPv6 prefix assigned to the site, while each site partition can be IPv6 prefix assigned to the site, while each site partition can be
represented by "sliver" IPv6 prefixes taken from the aggregate. In represented by "sliver" IPv6 prefixes taken from the aggregate. In
order to provide a simple service that does not interact poorly with order to provide a simple service that does not interact poorly with
skipping to change at page 15, line 19 skipping to change at page 15, line 16
responsible for ensuring that their products are interoperable; responsible for ensuring that their products are interoperable;
therefore, implementations must make provisions for ensuring "u" bit therefore, implementations must make provisions for ensuring "u" bit
compatibility for intra-link communications. compatibility for intra-link communications.
Site administrators should accordingly configure ACL entries and Site administrators should accordingly configure ACL entries and
other literal representations of ISATAP interface identifiers such other literal representations of ISATAP interface identifiers such
that both values of the "u" bit are accepted. For example, if the that both values of the "u" bit are accepted. For example, if the
site administrator configures an ACL entry that matches the prefix site administrator configures an ACL entry that matches the prefix
"fe80::0000:5efe:192.0.2.0/124", they should also configure a "fe80::0000:5efe:192.0.2.0/124", they should also configure a
companion list entry that matches the prefix companion list entry that matches the prefix
"fe80::0200:5efe:192.0.2.0/124. "fe80::0200:5efe:192.0.2.0/124".
4. Manual Configuration 4. Manual Configuration
When no autoconfiguration services are available (e.g., if there are When no autoconfiguration services are available (e.g., if there are
no advertising ISATAP routers present), site administrators can use no advertising ISATAP routers present), site administrators can use
manual configuration to assign IPv6 addresses with ISATAP interface manual configuration to assign IPv6 addresses with ISATAP interface
identifiers to the ISATAP interfaces of clients. Otherwise, site identifiers to the ISATAP interfaces of clients. Otherwise, site
administrators should avoid manual configurations that would in any administrators should avoid manual configurations that would in any
way invalidate the assumptions of the autoconfiguration service. For way invalidate the assumptions of the autoconfiguration service. For
example, manually configured addresses may not be automatically example, manually configured addresses may not be automatically
 End of changes. 10 change blocks. 
22 lines changed or deleted 21 lines changed or added

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