doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc6964.txt b/doc/rfc/rfc6964.txt
new file mode 100644
index 0000000..fcae608
--- /dev/null
+++ b/doc/rfc/rfc6964.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Independent Submission                                        F. Templin
+Request for Comments: 6964                  Boeing Research & Technology
+Category: Informational                                         May 2013
+ISSN: 2070-1721
+
+
+    Operational Guidance for IPv6 Deployment in IPv4 Sites Using the
+        Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
+
+Abstract
+
+   Many end-user sites in the Internet today still have predominantly
+   IPv4 internal infrastructures.  These sites range in size from small
+   home/office networks to large corporate enterprise networks, but
+   share the commonality that IPv4 provides satisfactory internal
+   routing and addressing services for most applications.  As more and
+   more IPv6-only services are deployed, however, end-user devices
+   within such sites will increasingly require at least basic IPv6
+   functionality.  This document therefore provides operational guidance
+   for deployment of IPv6 within predominantly IPv4 sites using the
+   Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6964.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Informational                     [Page 1]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Enabling IPv6 Services Using ISATAP . . . . . . . . . . . . .   4
+   3.  SLAAC Services  . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  Advertising ISATAP Router Behavior  . . . . . . . . . . .   5
+     3.2.  ISATAP Host Behavior  . . . . . . . . . . . . . . . . . .   6
+     3.3.  Reference Operational Scenario - Shared Prefix Model  . .   6
+     3.4.  Reference Operational Scenario - Individual Prefix Model    9
+     3.5.  SLAAC Site Administration Guidance  . . . . . . . . . . .  12
+     3.6.  Loop Avoidance  . . . . . . . . . . . . . . . . . . . . .  14
+     3.7.  Considerations for Compatibility of Interface Identifiers  14
+   4.  Manual Configuration  . . . . . . . . . . . . . . . . . . . .  15
+   5.  Scaling Considerations  . . . . . . . . . . . . . . . . . . .  15
+   6.  Site Renumbering Considerations . . . . . . . . . . . . . . .  16
+   7.  Path MTU Considerations . . . . . . . . . . . . . . . . . . .  16
+   8.  Alternative Approaches  . . . . . . . . . . . . . . . . . . .  17
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
+   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Informational                     [Page 2]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+1.  Introduction
+
+   End-user sites in the Internet today internally use IPv4 routing and
+   addressing for core operating functions, such as web browsing, file
+   sharing, network printing, email, teleconferencing, and numerous
+   other site-internal networking services.  Such sites typically have
+   an abundance of public and/or private IPv4 addresses for internal
+   networking and are separated from the public Internet by firewalls,
+   packet filtering gateways, proxies, address translators, and other
+   site-border demarcation devices.  To date, such sites have had little
+   incentive to enable IPv6 services internally [RFC1687].
+
+   End-user sites that currently use IPv4 services internally come in
+   endless sizes and varieties.  For example, a home network behind a
+   Network Address Translator (NAT) may consist of a single link
+   supporting a few laptops, printers, etc.  As a larger example, a
+   small business may consist of one or a few offices with several
+   networks connecting considerably larger numbers of computers,
+   routers, handheld devices, printers, faxes, etc.  Moving further up
+   the scale, large financial institutions, major retailers, large
+   corporations, etc., may consist of hundreds or thousands of branches
+   worldwide that are tied together in a complex global enterprise
+   network.  Additional examples include personal-area networks, mobile
+   vehicular networks, disaster relief networks, tactical military
+   networks, various forms of Mobile Ad Hoc Networks (MANETs), etc.
+
+   With the proliferation of IPv6 services, however, existing IPv4 sites
+   will increasingly require a means for enabling IPv6 services so that
+   hosts within the site can communicate with IPv6-only correspondents.
+   Such services must be deployable with minimal configuration and in a
+   fashion that will not cause disruptions to existing IPv4 services.
+   The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
+   [RFC5214] provides a simple-to-use service that sites can deploy in
+   the near term to meet these requirements.
+
+   ISATAP has also often been mentioned with respect to IPv6 deployment
+   in enterprise networks [RFC4057] [RFC4852] [ENT-IPv6].  ISATAP can
+   therefore be considered as an IPv6 solution alternative based on
+   candidate enterprise network characteristics.
+
+   This document provides operational guidance for using ISATAP to
+   enable IPv6 services within predominantly IPv4 sites while causing no
+   disruptions to existing IPv4 services.  The terminology of ISATAP
+   (see [RFC5214], Section 3) applies also to this document.
+
+
+
+
+
+
+
+Templin                       Informational                     [Page 3]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+2.  Enabling IPv6 Services Using ISATAP
+
+   Existing sites within the Internet will soon need to enable IPv6
+   services.  Larger sites typically obtain provider-independent IPv6
+   prefixes from an Internet registry and advertise the prefixes into
+   the IPv6 routing system on their own behalf, i.e., they act as an
+   Internet Service Provider (ISP) unto themselves.  Smaller sites that
+   wish to enable IPv6 can arrange to obtain public IPv6 prefixes from
+   an ISP, where the prefixes may be either purely native or the near-
+   native prefixes offered by the IPv6 Rapid Deployment on IPv4 (6rd)
+   [RFC5969].  Alternatively, the site can obtain prefixes independently
+   of an ISP, e.g., via a tunnel broker [RFC3053], by using one of its
+   public IPv4 addresses to form a 6to4 prefix [RFC3056], etc.  In any
+   case, after obtaining IPv6 prefixes, the site can automatically
+   enable IPv6 services internally by configuring ISATAP.
+
+   The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA)
+   tunnel virtual interface model [RFC2491] [RFC2529] based on IPv6-in-
+   IPv4 encapsulation [RFC4213].  The encapsulation format can further
+   use Differentiated Services (DS) [RFC2983] and Explicit Congestion
+   Notification (ECN) [RFC3168] mapping between the inner and outer IP
+   headers to ensure expected per-hop behavior within well-managed
+   sites.
+
+   The ISATAP service is based on two node types known as advertising
+   ISATAP routers and ISATAP hosts.  (While out of scope for this
+   document, a third node type known as non-advertising ISATAP routers
+   is defined in [ISATAP-UPDATE].)  Each node may further have multiple
+   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
+   ISATAP host on others.  Hence, the node type is considered on a per-
+   interface basis.
+
+   Advertising ISATAP routers configure their ISATAP interfaces as
+   advertising router interfaces (see [RFC4861], Section 6.2.2).  ISATAP
+   hosts configure their ISATAP interfaces as simple host interfaces and
+   also coordinate their autoconfiguration operations with advertising
+   ISATAP routers.  In this sense, advertising ISATAP routers are
+   "servers" while ISATAP hosts are "clients" in the service model.
+
+   Advertising ISATAP routers arrange to add their IPv4 addresses to the
+   site's Potential Router List (PRL) so that ISATAP clients can
+   discover them, as discussed in Sections 8.3.2 and 9 of [RFC5214].
+   Alternatively, site administrators could include IPv4 anycast
+   addresses in the PRL and assign each such address to multiple
+   advertising ISATAP routers.  In that case, IPv4 routing within the
+   site would direct the ISATAP client to the nearest advertising ISATAP
+   router.
+
+
+
+Templin                       Informational                     [Page 4]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   After the PRL is published, ISATAP clients within the site can
+   automatically perform unicast IPv6 Neighbor Discovery Router
+   Solicitation (RS) / Router Advertisement (RA) exchanges with
+   advertising ISATAP routers using IPv6-in-IPv4 encapsulation [RFC4861]
+   [RFC5214].  In the exchange, the IPv4 source address of the RS and
+   the destination address of the RA are an IPv4 address of the client,
+   while the IPv4 destination address of the RS and the source address
+   of the RA are an IPv4 address of a server found in the PRL.
+   Similarly, the IPv6 source address of the RS is a link-local ISATAP
+   address that embeds the client's IPv4 address, while the source
+   address of the RA is a link-local ISATAP address that embeds the
+   server's IPv4 address.  (The destination addresses of the RS and RA
+   may be either the neighbor's link-local ISATAP address or a link-
+   scoped multicast address, depending on the implementation.)
+
+   Following router discovery, ISATAP clients can configure and assign
+   IPv6 addresses and/or prefixes using Stateless Address
+   AutoConfiguration (SLAAC) [RFC4862] [RFC5214].  While out of scope
+   for this document, use of the Dynamic Host Configuration Protocol for
+   IPv6 (DHCPv6) [RFC3315] is also possible, pending future updates (see
+   [ISATAP-UPDATE]).
+
+3.  SLAAC Services
+
+   Predominantly IPv4 sites can enable SLAAC services for ISATAP clients
+   that need to communicate with IPv6 correspondents.  SLAAC services
+   are enabled using either the "shared" or "individual" prefix model.
+   In the shared prefix model, all advertising ISATAP routers advertise
+   a common prefix (e.g., 2001:db8::/64) to ISATAP clients within the
+   site.  In the individual prefix model, advertising ISATAP router
+   advertise individual prefixes (e.g., 2001:db8:0:1::/64,
+   2001:db8:0:2::/64, 2001:db8:0:3::/64, etc.)  to ISATAP clients within
+   the site.  Note that combinations of the shared and individual prefix
+   models are also possible, in which some of the site's ISATAP routers
+   advertise shared prefixes and others advertise individual prefixes.
+
+   The following sections discuss operational considerations for
+   enabling ISATAP SLAAC services within predominantly IPv4 sites.
+
+3.1.  Advertising ISATAP Router Behavior
+
+   Advertising ISATAP routers that support SLAAC services send RA
+   messages in response to RS messages received on an advertising ISATAP
+   interface.  SLAAC services are enabled when advertising ISATAP
+   routers advertise non-link-local IPv6 prefixes in the Prefix
+   Information Options (PIOs) with the A flag set to 1 [RFC4861].  When
+   there are multiple advertising ISATAP routers, the routers can
+   advertise a shared IPv6 prefix or individual IPv6 prefixes.
+
+
+
+Templin                       Informational                     [Page 5]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+3.2.  ISATAP Host Behavior
+
+   ISATAP hosts resolve the PRL and send RS messages to obtain RA
+   messages from an advertising ISATAP router.  When the host receives
+   RA messages, it uses SLAAC to configure IPv6 addresses from any
+   advertised prefixes with the A flag set to 1 as specified in
+   [RFC4862] and [RFC5214], then it assigns the addresses to the ISATAP
+   interface.  The host also assigns any of the advertised prefixes with
+   the L flag set to 1 to the ISATAP interface.  (Note that the IPv6
+   link-local prefix fe80::/64 is always considered on-link on an ISATAP
+   interface.)
+
+3.3.  Reference Operational Scenario - Shared Prefix Model
+
+   Figure 1 depicts an example ISATAP network topology for allowing
+   hosts within a predominantly IPv4 site to configure ISATAP services
+   using SLAAC with the shared prefix model.  The example shows two
+   advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'),
+   and an ordinary IPv6 host ('E') outside of the site in a typical
+   deployment configuration.  In this model, routers 'A' and 'B' both
+   advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6
+   routing system, and also advertise the prefix in the RA messages they
+   send to ISATAP clients.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Informational                     [Page 6]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+                    .-(::::::::)      2001:db8:1::1
+                 .-(::: IPv6 :::)-.  +-------------+
+                (:::: Internet ::::) | IPv6 Host E |
+                 `-(::::::::::::)-'  +-------------+
+                    `-(::::::)-'
+                ,~~~~~~~~~~~~~~~~~,
+           ,----|companion gateway|--.
+          /     '~~~~~~~~~~~~~~~~~'  :
+         /                           |.
+      ,-'                              `.
+     ;  +------------+   +------------+  )
+     :  |  Router A  |   |  Router B  |  /
+      : |  (isatap)  |   |  (isatap)  |  :
+      : | 192.0.2.1  |   | 192.0.2.1  | ;
+      + +------------+   +------------+  \
+     fe80::*:192.0.2.1   fe80::*:192.0.2.1
+     | 2001:db8::/64       2001:db8::/64  |
+     |                                   ;
+     :              IPv4 Site         -+-'
+      `-.       (PRL: 192.0.2.1)       .)
+         \                           _)
+          `-----+--------)----+'----'
+     fe80::*:192.0.2.18          fe80::*:192.0.2.34
+   2001:db8::*:192.0.2.18      2001:db8::*:192.0.2.34
+     +--------------+           +--------------+
+     |  192.0.2.18  |           |  192.0.2.34  |
+     |   (isatap)   |           |   (isatap)   |
+     |    Host C    |           |    Host D    |
+     +--------------+           +--------------+
+
+   (* == "0000:5efe", i.e., the organizational unique code for ISATAP,
+    per Section 6.1 of [RFC5214])
+
+    Figure 1: Example ISATAP Network Topology Using Shared Prefix Model
+
+   With reference to Figure 1, advertising ISATAP routers 'A' and 'B'
+   within the IPv4 site connect to the IPv6 Internet either directly or
+   via a companion gateway.  The routers advertise the shared prefix
+   2001:db8::/64 into the IPv6 Internet routing system either as a
+   singleton /64 or as part of a shorter aggregated IPv6 prefix.  For
+   the purpose of this example, we also assume that the IPv4 site is
+   configured within multiple IPv4 subnets -- each with an IPv4 prefix
+   length of /28.
+
+   Advertising ISATAP routers 'A' and 'B' both configure the IPv4
+   anycast address 192.0.2.1 on a site-interior IPv4 interface, then
+   configure an advertising ISATAP router interface for the site with
+   link-local ISATAP address fe80::5efe:192.0.2.1.  The site
+
+
+
+Templin                       Informational                     [Page 7]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   administrator then places the single IPv4 address 192.0.2.1 in the
+   site's PRL.  'A' and 'B' then both advertise the anycast address/
+   prefix into the site's IPv4 routing system so that ISATAP clients can
+   locate the router that is topologically closest.  (Note: advertising
+   ISATAP routers can also use individual IPv4 unicast addresses instead
+   of, or in addition to, a shared IPv4 anycast address.  In that case,
+   the PRL will contain multiple IPv4 addresses of advertising routers
+   -- some of which may be anycast and others unicast.)
+
+   ISATAP host 'C' connects to the site via an IPv4 interface with
+   address 192.0.2.18/28 and also configures an ISATAP host interface
+   with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4
+   interface.  'C' next resolves the PRL and sends an RS message to the
+   IPv4 address 192.0.2.1, where IPv4 routing will direct it to the
+   closest of either 'A' or 'B'.  Assuming 'A' is closest, 'C' receives
+   an RA from 'A' then configures a default IPv6 route with next-hop
+   address fe80::5efe:192.0.2.1 via the ISATAP interface and processes
+   the IPv6 prefix 2001:db8::/64 advertised in the PIO.  If the A flag
+   is set in the PIO, 'C' uses SLAAC to automatically configure the IPv6
+   address 2001:db8::5efe:192.0.2.18 (i.e., an address with an ISATAP
+   interface identifier) and assigns it to the ISATAP interface.  If the
+   L flag is set, 'C' also assigns the prefix 2001:db8::/64 to the
+   ISATAP interface, and the IPv6 address becomes a true ISATAP address.
+
+   In the same fashion, ISATAP host 'D' configures its IPv4 interface
+   with address 192.0.2.34/28 and configures its ISATAP interface with
+   link-local ISATAP address fe80::5efe:192.0.2.34.  'D' next performs
+   an RS/RA exchange that is serviced by 'B', then uses SLAAC to
+   autoconfigure the address 2001:db8::5efe:192.0.2.34 and a default
+   IPv6 route with next-hop address fe80::5efe:192.0.2.1.  Finally, IPv6
+   host 'E' connects to an IPv6 network outside of the site.  'E'
+   configures its IPv6 interface in a manner specific to its attached
+   IPv6 link and autoconfigures the IPv6 address 2001:db8:1::1.
+
+   Following this autoconfiguration, when host 'C' inside the site has
+   an IPv6 packet to send to host 'E' outside the site, it prepares the
+   packet with source address 2001:db8::5efe:192.0.2.18 and destination
+   address 2001:db8:1::1.  'C' then uses IPv6-in-IPv4 encapsulation to
+   forward the packet to the IPv4 address 192.0.2.1, which will be
+   directed to 'A' based on IPv4 routing.  'A' in turn decapsulates the
+   packet and forwards it into the public IPv6 Internet, where it will
+   be conveyed to 'E' via normal IPv6 routing.  In the same fashion,
+   host 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B'
+   to send IPv6 packets to IPv6 Internet hosts such as 'E'.
+
+   When host 'E' outside the site sends IPv6 packets to ISATAP host 'C'
+   inside the site, the IPv6 routing system may direct the packet to
+   either 'A' or 'B'.  If the site is not partitioned internally, the
+
+
+
+Templin                       Informational                     [Page 8]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   router that receives the packet can use ISATAP to statelessly forward
+   the packet directly to 'C'.  If the site may be partitioned
+   internally, however, the packet must first be forwarded to 'C's
+   serving router based on IPv6 routing information.  This implies that,
+   in a partitioned site, the advertising ISATAP routers must connect
+   within a full or partial mesh of IPv6 links, and they must either run
+   a dynamic IPv6 routing protocol or configure static routes so that
+   incoming IPv6 packets can be forwarded to the correct serving router.
+
+   In this example, 'A' can configure the IPv6 route
+   2001:db8::5efe:192.0.2.32/124 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::5efe:192.0.2.16/124 with the IPv6 address of
+   the next hop toward 'A' as the next hop.  (Notice that the /124
+   prefixes properly cover the /28 prefix of the IPv4 address that is
+   embedded within the IPv6 address.)  In that case, when 'A' receives a
+   packet from the IPv6 Internet with destination address
+   2001:db8::5efe:192.0.2.34, it first forwards the packet toward 'B'
+   over an IPv6 mesh link.  'B' in turn uses ISATAP to forward the
+   packet into the site, where IPv4 routing will direct it to 'D'.  In
+   the same fashion, when 'B' receives a packet from the IPv6 Internet
+   with destination address 2001:db8::5efe:192.0.2.18, it first forwards
+   the packet toward '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'.
+
+   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
+   ISATAP IPv6-in-IPv4 encapsulation service.  When there is operational
+   assurance that IPv4 services between the two hosts are available, the
+   hosts may be better served to continue to use legacy IPv4 services in
+   order to avoid encapsulation overhead and to avoid communication
+   failures due to middleboxes in the path that filter protocol-41
+   packets [RFC4213].  If 'C' and 'D' could be in different IPv4 network
+   partitions, however, IPv6-in-IPv4 encapsulation should be used with
+   one or both of routers 'A' and 'B' serving as intermediate gateways.
+
+3.4.  Reference Operational Scenario - Individual Prefix Model
+
+   Figure 2 depicts an example ISATAP network topology for allowing
+   hosts within a predominantly IPv4 site to configure ISATAP services
+   using SLAAC with the individual prefix model.  The example shows two
+   advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'),
+   and an ordinary IPv6 host ('E') outside of the site in a typical
+   deployment configuration.  In the figure, ISATAP routers 'A' and 'B'
+   both advertise different prefixes taken from the aggregated prefix
+   2001:db8::/48, with 'A' advertising 2001:db8:0:1::/64 and 'B'
+   advertising 2001:db8:0:2::/64.
+
+
+
+Templin                       Informational                     [Page 9]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+                    .-(::::::::)      2001:db8:1::1
+                 .-(::: IPv6 :::)-.  +-------------+
+                (:::: Internet ::::) | IPv6 Host E |
+                 `-(::::::::::::)-'  +-------------+
+                    `-(::::::)-'
+                ,~~~~~~~~~~~~~~~~~,
+           ,----|companion gateway|--.
+          /     '~~~~~~~~~~~~~~~~~'  :
+         /                           |.
+      ,-'                              `.
+     ;  +------------+   +------------+  )
+     :  |  Router A  |   |  Router B  |  /
+      : |  (isatap)  |   |  (isatap)  |  :
+      : | 192.0.2.17 |   | 192.0.2.33 | ;
+      + +------------+   +------------+  \
+     fe80::*:192.0.2.17   fe80::*:192.0.2.33
+     2001:db8:0:1::/64   2001:db8:0:2::/64
+     |                                   ;
+     :              IPv4 Site         -+-'
+      `-.       (PRL: 192.0.2.1)       .)
+         \                           _)
+          `-----+--------)----+'----'
+     fe80::*:192.0.2.18          fe80::*:192.0.2.34
+   2001:db8:0:1::*:192.0.2.18  2001:db8:0:2::*:192.0.2.34
+     +--------------+           +--------------+
+     |  192.0.2.18  |           |  192.0.2.34  |
+     |   (isatap)   |           |   (isatap)   |
+     |    Host C    |           |    Host D    |
+     +--------------+           +--------------+
+
+   (* == "0000:5efe")
+
+              Figure 2: Example ISATAP Network Topology Using
+                          Individual Prefix Model
+
+   With reference to Figure 2, advertising ISATAP routers 'A' and 'B'
+   within the IPv4 site connect to the IPv6 Internet either directly or
+   via a companion gateway.  Router 'A' advertises the individual prefix
+   2001:db8:0:1::/64 into the IPv6 Internet routing system, and router
+   'B' advertises the individual prefix 2001:db8:0:2::/64.  The routers
+   could instead both advertise a shorter shared prefix such as
+   2001:db8::/48 into the IPv6 routing system, but in that case they
+   would need to configure a mesh of IPv6 links between themselves in
+   the same fashion as described for the shared prefix model in
+   Section 3.3.  For the purpose of this example, we also assume that
+   the IPv4 site is configured within multiple IPv4 subnets -- each with
+   an IPv4 prefix length of /28.
+
+
+
+
+Templin                       Informational                    [Page 10]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   Advertising ISATAP routers 'A' and 'B' both configure individual IPv4
+   unicast addresses 192.0.2.17/28 and 192.0.2.33/28 (respectively)
+   instead of, or in addition to, a shared IPv4 anycast address.  Router
+   'A' then configures an advertising ISATAP router interface for the
+   site with link-local ISATAP address fe80::5efe:192.0.2.17, while
+   router 'B' configures an advertising ISATAP router interface for the
+   site with link-local ISATAP address fe80::5efe:192.0.2.33.  The site
+   administrator then places the IPv4 addresses 192.0.2.17 and
+   192.0.2.33 in the site's PRL.  'A' and 'B' then both advertise their
+   IPv4 addresses into the site's IPv4 routing system.
+
+   ISATAP host 'C' connects to the site via an IPv4 interface with
+   address 192.0.2.18/28 and also configures an ISATAP host interface
+   with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4
+   interface.  'C' next resolves the PRL and sends an RS message to the
+   IPv4 address 192.0.2.17, where IPv4 routing will direct it to 'A'.
+   'C' then receives an RA from 'A' then configures a default IPv6 route
+   with next-hop address fe80::5efe:192.0.2.17 via the ISATAP interface
+   and processes the IPv6 prefix 2001:db8:0:1:/64 advertised in the PIO.
+   If the A flag is set in the PIO, 'C' uses SLAAC to automatically
+   configure the IPv6 address 2001:db8:0:1::5efe:192.0.2.18 (i.e., an
+   address with an ISATAP interface identifier) and assigns it to the
+   ISATAP interface.  If the L flag is set, 'C' also assigns the prefix
+   2001:db8:0:1::/64 to the ISATAP interface, and the IPv6 address
+   becomes a true ISATAP address.
+
+   In the same fashion, ISATAP host 'D' configures its IPv4 interface
+   with address 192.0.2.34/28 and configures its ISATAP interface with
+   link-local ISATAP address fe80::5efe:192.0.2.34.  'D' next performs
+   an RS/RA exchange that is serviced by 'B', then uses SLAAC to
+   autoconfigure the address 2001:db8:0:2::5efe:192.0.2.34 and a default
+   IPv6 route with next-hop address fe80::5efe:192.0.2.33.  Finally,
+   IPv6 host 'E' connects to an IPv6 network outside of the site.  'E'
+   configures its IPv6 interface in a manner specific to its attached
+   IPv6 link, and it autoconfigures the IPv6 address 2001:db8:1::1.
+
+   Following this autoconfiguration, when host 'C' inside the site has
+   an IPv6 packet to send to host 'E' outside the site, it prepares the
+   packet with source address 2001:db8::5efe:192.0.2.18 and destination
+   address 2001:db8:1::1.  'C' then uses IPv6-in-IPv4 encapsulation to
+   forward the packet to the IPv4 address 192.0.2.17, which will be
+   directed to 'A' based on IPv4 routing.  'A' in turn decapsulates the
+   packet and forwards it into the public IPv6 Internet, where it will
+   be conveyed to 'E' via normal IPv6 routing.  In the same fashion,
+   host 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B'
+   to send IPv6 packets to IPv6 Internet hosts such as 'E'.
+
+
+
+
+
+Templin                       Informational                    [Page 11]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   When host 'E' outside the site sends IPv6 packets to ISATAP host 'C'
+   inside the site, the IPv6 routing system will direct the packet to
+   'A' since 'A' advertises the individual prefix that matches 'C's
+   destination address.  'A' can then use ISATAP to statelessly forward
+   the packet directly to 'C'.  If 'A' and 'B' both advertise the shared
+   shorter prefix 2001:db8::/48 into the IPv6 routing system, however,
+   packets coming from 'E' may be directed to either 'A' or 'B'.  In
+   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
+   and must either run a dynamic IPv6 routing protocol or configure
+   static routes so that incoming IPv6 packets can be forwarded to the
+   correct serving router.
+
+   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
+   as the next hop, and 'B' can configure the IPv6 route
+   2001:db8:0.1::/64 with the IPv6 address of the next hop toward 'A' as
+   the next hop.  Then, when 'A' receives a packet from the IPv6
+   Internet with destination address 2001:db8:0:2::5efe:192.0.2.34, it
+   first forwards the packet toward 'B' over an IPv6 mesh link.  'B' in
+   turn uses ISATAP to forward the packet into the site, where IPv4
+   routing will direct it to 'D'.  In the same fashion, when 'B'
+   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
+   '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'.
+
+   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
+   ISATAP IPv6-in-IPv4 encapsulation service.  When there is operational
+   assurance that IPv4 services between the two hosts are available, the
+   hosts may be better served to continue to use legacy IPv4 services in
+   order to avoid encapsulation overhead and to avoid any IPv4
+   protocol-41 filtering middleboxes that may be in the path.  If 'C'
+   and 'D' may be in different IPv4 network partitions, however,
+   IPv6-in-IPv4 encapsulation should be used with one or both of routers
+   'A' and 'B' serving as intermediate gateways.
+
+3.5.  SLAAC Site Administration Guidance
+
+   In common practice, firewalls, gateways, and packet filtering devices
+   of various forms are often deployed in order to divide the site into
+   separate partitions.  In both the shared and individual prefix models
+   described above, the entire site can be represented by the aggregate
+   IPv6 prefix assigned to the site, while each site partition can be
+   represented by "sliver" IPv6 prefixes taken from the aggregate.  In
+   order to provide a simple service that does not interact poorly with
+   the site topology, site administrators should therefore institute an
+
+
+
+Templin                       Informational                    [Page 12]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   address plan to align IPv6 sliver prefixes with IPv4 site partition
+   boundaries.
+
+   For example, in the shared prefix model in Section 3.3, the aggregate
+   prefix is 2001:db8::/64, and the sliver prefixes are
+   2001:db8::5efe:192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124,
+   2001:db8::5efe:192.0.2.32/124, etc.  In the individual prefix model
+   in Section 3.4, the aggregate prefix is 2001:db8::/48, and the sliver
+   prefixes are 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64,
+   etc.
+
+   When individual prefixes are used, site administrators can configure
+   advertising ISATAP routers to advertise different individual prefixes
+   to different sets of clients, e.g., based on the client's IPv4 subnet
+   prefix such that the IPv6 prefixes are congruent with the IPv4
+   addressing plan.  (For example, administrators can configure each
+   advertising ISATAP router to provide services only to certain sets of
+   ISATAP clients through inbound IPv6 Access Control List (ACL) entries
+   that match the IPv4 subnet prefix embedded in the ISATAP interface
+   identifier of the IPv6 source address.)  When a shared prefix is
+   used, site administrators instead configure the ISATAP routers to
+   advertise the shared prefix to all clients.
+
+   Advertising ISATAP routers can advertise prefixes with the (A, L)
+   flags set to (1,0) so that ISATAP clients will use SLAAC to
+   autoconfigure IPv6 addresses with ISATAP interface identifiers from
+   the prefixes and assign them to the receiving ISATAP interface, but
+   they will not assign the prefix itself to the ISATAP interface.  In
+   that case, the advertising router must assign the sliver prefix for
+   the site partition to the advertising ISATAP interface.  In this way,
+   the advertising router considers the addresses covered by the sliver
+   prefix as true ISATAP addresses, but the ISATAP clients themselves do
+   not.  This configuration enables a hub-and-spoke architecture, which
+   in some cases may be augmented by route optimization based on the
+   receipt of ICMPv6 Redirects.
+
+   Site administrators can implement address selection policy rules
+   [RFC6724] through explicit configurations in each ISATAP client in
+   order to give preference to IPv4 destination addresses over
+   destination addresses derived from one of the client's IPv6 sliver
+   prefixes.  For example, site administrators can configure each ISATAP
+   client associated with a sliver prefix such as
+   2001:db8::5efe:192.0.2.64/124 to add the prefix to its address
+   selection policy table with a lower precedence than the prefix
+   ::ffff:0:0/96.  In this way, IPv4 addresses are preferred over IPv6
+   addresses from within the same sliver.  The prefix could be added to
+   each ISATAP client either manually or through an automated service
+   such as a DHCP option [ADDR-SELECT] discovered by the client, e.g.,
+
+
+
+Templin                       Informational                    [Page 13]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   using Stateless DHCPv6 [RFC3736].  In this way, clients will use IPv4
+   communications to reach correspondents within the same IPv4 site
+   partition and will use IPv6 communications to reach correspondents in
+   other partitions and/or outside of the site.
+
+   It should be noted that sliver prefixes longer than /64 cannot be
+   advertised for SLAAC purposes.  Also, sliver prefixes longer than /64
+   do not allow for interface identifier rewriting by address
+   translators.  These factors may favor the individual prefix model in
+   some deployment scenarios, while the flexibility afforded by the
+   shared prefix model may be more desirable in others.  Additionally,
+   if the network is small, then the shared prefix model works well.  If
+   the network is large, however, a better alternative may be to deploy
+   separate ISATAP routers in each partition and have each advertise its
+   own individual prefix.
+
+   Finally, site administrators should configure ISATAP routers to not
+   send ICMPv6 Redirect messages to inform a source client of a better
+   next hop toward the destination unless there is strong assurance that
+   the client and the next hop are within the same IPv4 site partition.
+
+3.6.  Loop Avoidance
+
+   In sites that provide IPv6 services through ISATAP with SLAAC as
+   described in this section, site administrators must take operational
+   precautions to avoid routing loops.  For example, each advertising
+   ISATAP router should drop any incoming IPv6 packets that would be
+   forwarded back to itself via another of the site's advertising
+   routers.  Additionally, each advertising ISATAP router should drop
+   any encapsulated packets received from another advertising router
+   that would be forwarded back to that same advertising router.  This
+   corresponds to the mitigation documented in Section 3.2.3 of
+   [RFC6324], but other mitigations specified in that document can also
+   be employed.
+
+   Note that IPv6 packets with link-local ISATAP addresses are exempt
+   from these checks, since they cannot be forwarded by an IPv6 router
+   and may be necessary for router-to-router coordinations.
+
+3.7.  Considerations for Compatibility of Interface Identifiers
+
+   [RFC5214], Section 6.1 specifies the setting of the "u" bit in the
+   Modified EUI-64 interface identifier format used by ISATAP.
+   Implementations that comply with the specification set the "u" bit to
+   1 when the IPv4 address is known to be globally unique; however, some
+   legacy implementations unconditionally set the "u" bit to 0.
+
+
+
+
+
+Templin                       Informational                    [Page 14]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   Implementations interpret the ISATAP interface identifier only within
+   the link to which the corresponding ISATAP prefix is assigned; hence,
+   the value of the "u" bit is interpreted only within the context of an
+   on-link prefix and not within a global context.  Implementers are
+   responsible for ensuring that their products are interoperable;
+   therefore, implementations must make provisions for ensuring "u" bit
+   compatibility for intra-link communications.
+
+   Site administrators should accordingly configure ACL entries and
+   other literal representations of ISATAP interface identifiers such
+   that both values of the "u" bit are accepted.  For example, if the
+   site administrator configures an ACL entry that matches the prefix
+   "fe80::0000:5efe:192.0.2.0/124", they should also configure a
+   companion list entry that matches the prefix
+   "fe80::0200:5efe:192.0.2.0/124".
+
+4.  Manual Configuration
+
+   When no autoconfiguration services are available (e.g., if there are
+   no advertising ISATAP routers present), site administrators can use
+   manual configuration to assign IPv6 addresses with ISATAP interface
+   identifiers to the ISATAP interfaces of clients.  Otherwise, site
+   administrators should avoid manual configurations that would in any
+   way invalidate the assumptions of the autoconfiguration service.  For
+   example, manually configured addresses may not be automatically
+   renumbered during a site-wide renumbering event, which could
+   subsequently result in communication failures.
+
+5.  Scaling Considerations
+
+   Section 3 depicts ISATAP network topologies with only two advertising
+   ISATAP routers within the site.  In order to support larger numbers
+   of ISATAP clients (and/or multiple site partitions), the site can
+   deploy more advertising ISATAP routers to support load balancing and
+   generally shortest-path routing.
+
+   Such an arrangement requires that the advertising ISATAP routers
+   participate in an IPv6 routing protocol instance so that IPv6
+   addresses/prefixes can be mapped to the correct ISATAP router.  The
+   routing protocol instance can be configured as either a full-mesh
+   topology involving all advertising ISATAP routers, or as a partial-
+   mesh topology with each advertising ISATAP router associating with
+   one or more companion gateways.  Each such companion gateway would in
+   turn participate in a full mesh between all companion gateways.
+
+
+
+
+
+
+
+Templin                       Informational                    [Page 15]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+6.  Site Renumbering Considerations
+
+   Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients
+   within the site.  If the site subsequently reconnects to a different
+   ISP, however, the site must renumber to use addresses derived from
+   the new IPv6 prefixes [RFC6879].
+
+   For IPv6 services provided by SLAAC, site renumbering in the event of
+   a change in an ISP-served IPv6 prefix entails a simple renumbering of
+   IPv6 addresses and/or prefixes that are assigned to the ISATAP
+   interfaces of clients within the site.  In some cases, filtering
+   rules (e.g., within filtering tables at site-border firewalls) may
+   also require renumbering, but this operation can be automated and
+   limited to only one or a few administrative "touch points".
+
+   In order to renumber the ISATAP interfaces of clients within the site
+   using SLAAC, advertising ISATAP routers need only schedule the
+   services offered by the old ISP for deprecation and begin to
+   advertise the IPv6 prefixes provided by the new ISP.  Lifetimes of
+   ISATAP client interface addresses will eventually expire, and the
+   host will renumber its interfaces with addresses derived from the new
+   prefixes.  ISATAP clients should also eventually remove any
+   deprecated SLAAC prefixes from their address selection policy tables,
+   but this action is not time-critical.
+
+   Finally, site renumbering in the event of a change in an ISP-served
+   IPv6 prefix further entails locating and rewriting all IPv6 addresses
+   in naming services, databases, configuration files, packet filtering
+   rules, documentation, etc.  If the site has published the IPv6
+   addresses of any site-internal nodes within the public Internet DNS
+   system, then the corresponding resource records will also need to be
+   updated during the renumbering operation.  This can be accomplished
+   via secure dynamic updates to the DNS.
+
+7.  Path MTU Considerations
+
+   IPv6-in-IPv4 encapsulation overhead effectively reduces the size of
+   IPv6 packets that can traverse the tunnel in relation to the actual
+   Maximum Transmission Unit (MTU) of the underlying IPv4 network path
+   between the tunnel ingress and egress.  Two methods for accommodating
+   IPv6 path MTU discovery over IPv6-in-IPv4 tunnels (i.e., the static
+   and dynamic methods) are documented in Section 3.2 of [RFC4213].
+
+   The static method places a "safe" upper bound on the size of IPv6
+   packets permitted to enter the tunnel; however, the method can be
+   overly conservative when larger IPv4 path MTUs are available.  The
+   dynamic method can accommodate much larger IPv6 packet sizes in some
+
+
+
+
+Templin                       Informational                    [Page 16]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   cases, but can fail silently if the underlying IPv4 network path does
+   not return the necessary error messages.
+
+   This document notes that sites that include well-managed IPv4 links,
+   routers, and other network middleboxes are candidates for use of the
+   dynamic MTU determination method, which may provide for a better
+   operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels.
+
+   Finally, since all ISATAP tunnels terminate at a host, transport
+   protocols that perform packet-size negotiations will see an IPv6 MTU
+   that accounts for the encapsulation headers and therefore will avoid
+   sending encapsulated packets that exceed the IPv4 path MTU.
+
+8.  Alternative Approaches
+
+   [RFC4554] proposes a use of VLANs for IPv4-IPv6 coexistence in
+   enterprise networks.  The ISATAP approach provides a more flexible
+   and broadly applicable alternative and with fewer administrative
+   touch points.
+
+   The tunnel broker service [RFC3053] uses point-to-point tunnels that
+   require end users to establish an explicit administrative
+   configuration of the tunnel's far end, which may be outside of the
+   administrative boundaries of the site.
+
+   6to4 [RFC3056] and Teredo [RFC4380] provide "last resort" unmanaged
+   automatic tunneling services when no other means for IPv6
+   connectivity is available.  These services are given lower priority
+   when the ISATAP managed service and/or native IPv6 services are
+   enabled.
+
+   6rd [RFC5969] enables a stateless prefix delegation capability based
+   on IPv4-embedded IPv6 prefixes, whereas ISATAP enables a stateful
+   prefix delegation capability based on native IPv6 prefixes.
+
+9.  Security Considerations
+
+   In addition to the security considerations documented in [RFC5214],
+   sites that use ISATAP should take care to ensure that no routing
+   loops are enabled [RFC6324].  Additional security concerns with IP
+   tunneling are documented in [RFC6169].
+
+
+
+
+
+
+
+
+
+
+Templin                       Informational                    [Page 17]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+10.  Acknowledgments
+
+   The following are acknowledged for their insights that helped shape
+   this work: Dmitry Anipko, Fred Baker, Ron Bonica, Brian Carpenter,
+   Remi Despres, Thomas Henderson, Philip Homburg, Lee Howard, Ray
+   Hunter, Joel Jaeggli, John Mann, Gabi Nakibly, Christopher Palmer,
+   Hemant Singh, Mark Smith, Ole Troan, and Gunter Van de Velde.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
+              (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862, September 2007.
+
+   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
+              March 2008.
+
+11.2.  Informative References
+
+   [ADDR-SELECT]
+              Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
+              Address Selection Policy using DHCPv6", Work in Progress,
+              April 2013.
+
+   [ENT-IPv6] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
+              Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
+              Guidelines", Work in Progress, February 2013.
+
+   [ISATAP-UPDATE]
+              Templin, F., "ISATAP Updates", Work in Progress, May 2012.
+
+
+
+
+
+Templin                       Informational                    [Page 18]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   [RFC1687]  Fleischman, E., "A Large Corporate User's View of IPng",
+              RFC 1687, August 1994.
+
+   [RFC2491]  Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
+              over Non-Broadcast Multiple Access (NBMA) networks", RFC
+              2491, January 1999.
+
+   [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
+              Domains without Explicit Tunnels", RFC 2529, March 1999.
+
+   [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
+              2983, October 2000.
+
+   [RFC3053]  Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
+              Tunnel Broker", RFC 3053, January 2001.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP", RFC
+              3168, September 2001.
+
+   [RFC4057]  Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
+              June 2005.
+
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380, February
+              2006.
+
+   [RFC4554]  Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
+              Enterprise Networks", RFC 4554, June 2006.
+
+   [RFC4852]  Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
+              Green, "IPv6 Enterprise Network Analysis - IP Layer 3
+              Focus", RFC 4852, April 2007.
+
+   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
+              Infrastructures (6rd) -- Protocol Specification", RFC
+              5969, August 2010.
+
+   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
+              Concerns with IP Tunneling", RFC 6169, April 2011.
+
+   [RFC6324]  Nakibly, G. and F. Templin, "Routing Loop Attack Using
+              IPv6 Automatic Tunnels: Problem Statement and Proposed
+              Mitigations", RFC 6324, August 2011.
+
+
+
+
+Templin                       Informational                    [Page 19]
+
+RFC 6964               ISATAP Operational Guidance              May 2013
+
+
+   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
+              "Default Address Selection for Internet Protocol Version 6
+              (IPv6)", RFC 6724, September 2012.
+
+   [RFC6879]  Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
+              Network Renumbering Scenarios, Considerations, and
+              Methods", RFC 6879, February 2013.
+
+Author's Address
+
+   Fred L. Templin
+   Boeing Research & Technology
+   P.O. Box 3707 MC 7L-49
+   Seattle, WA  98124
+   USA
+
+   EMail: fltemplin@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Templin                       Informational                    [Page 20]
+