Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft)

["Gunter Van de Velde (gvandeve)" <[e-mail]>]

Many thanks for sharing. 

In some way I have a feeling that native-v6 should be promoted above
ISATAP.
ISATAP is tunneling and eventhough its not as bad as 6to4, it is way
worse as native v6.

Fact is that my affiliation company is using ISATAP right now, and it is
part of the 
migration strategy for implementing IPv6, but we do want to get away
from it asap 
due to a set of disadvantages it includes. My take is that when a new
RFC like this would 
be generated, it will be too late for actual usage because the world and
the enterprises 
have moved forward.

All the best,
G/

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Templin, Fred L
Sent: 11 April 2011 20:18
To: [e-mail]
Subject: [v6ops] Operational Guidance for IPv6 Deployment in
Predominantly IPv4 Sites - (pre-draft)

Hello,

The following should not be construed as a draft, but
rather just a set of ideas that might be considered
for inclusion in a new or existing draft. Any
comments or suggestions?

Thanks - Fred
[e-mail]

--- cut here ---

Introduction
************
Countless end user sites in the Internet today still have
predominantly IPv4 infrastructures. These sites range in
size from small home/office networks to large corporate
enterprise networks, but share the commonality that IPv4
continues to provide satisfactory internal routing and
addressing services. As more and more IPv6-only services
are deployed in the Internet, however, end user devices
within the site will increasingly require at least basic
IPv6 functionality for external access. This pre-draft
provides operational guidance for predominantly IPv4 sites
in making transitional IPv6 services available without
disrupting existing IPv4 services.

Characteristics of Existing IPv4 Sites
**************************************
Existing end user sites use IPv4 routing and addressing
internally for normal IT operations such as filesharing,
network printing, e-mail, conferencing and numerous other
critical site-internal networking services. Such sites
typically have an abundance of public 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 securing
devices. To date, such sites have had little incentive to
enable IPv6 services internally [RFC1687].

With the emergence of IPv6-only services within the public
Internet, however, existing IPv4 sites will increasingly
require a means for enabling client-side IPv6 services so
that end user devices within the site can access IPv6
Internet services. Such services must be deployable with
minimal configuration and in a fashion that will not cause
disruptions to existing IPv4 services within the site. 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 reqirements while a
longer-term site-wide IPv6 deployment plan is conducted
in parallel.

Enabling Client-Side IPv6 Services with ISATAP
**********************************************
Small sites typically arrange to obtain public IPv6 prefixes
from an Internet Service Provider (ISP) in the same fashion
as for home network users. When the ISP does not yet provide
native IPv6 services, it can instead offer a transitional
service with native-equivalent capabilities using 6RD
[RFC5569][RFC5969]. Large 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 ISP unto themselves.

In both cases, the site can automatically enable ISATAP
based IPv6 services by configuring one or more site border
routers as ISATAP routers. Each such ISATAP router is added
to the Potential Router List (PRL) for the site so that
hosts in the network can discover them for default route
and prefix auto-configuration purposes.

When there are multiple ISATAP site border routers, the
routers can advertise the same IPv6 prefix or a different
set of IPv6 prefixes of prefix length /64. For example,
a first router may advertise 2001:db8:0:0::/64, a second
may advertise 2001:db8:0:1::/64, etc. The routers can
further be configured to advertise different prefixes
to different sets of hosts within the site (e.g., as
identified by the host's IPv4 prefix) for the purpose
of site partitioning. In all cases, however, the site
border routers must take operational measures to avoid
routing loops [draft-ietf-v6ops-tunnel-loops]. As a
simple mitigation, the site border router can drop any
incoming packets that have an IPv4 source or outgoing
packets that have an IPv4 destination address of another
site border router, e.g., by checking for the address
in the site's PRL.

ISATAP hosts will automatically discover ISATAP site border
routers and configure ISATAP addresses using Stateless
Address AutoConfiguration (SLAAC) based on the advertised
IPv6 prefixes. In order to provide a simple service that
does not interact poorly with existing site topological
arrangements, the site can enable client-side only operation
so that hosts only use the ISATAP service for accessing IPv6
services on the public Internet, while continuing to use
IPv4 services for intra-site communications.

In order to maintain a client-side only service, the site
should not configure any IPv6 addresses provided by ISATAP
within site name service resource records. In this way,
intra-site communications will continue to use existing
IPv4 networking services instead of ISATAP-served IPv6
services. This arrangement prevents communication failure
modes in which a pair of ISATAP hosts are separated by a
packet filtering gateway which would prevent direct
communications via the tunneled IPv6 service.

To further disable host-to-host ISATAP communications
within the site, the ISATAP site border routers should
advertise their prefixes with the (A,L) flags set to (1,0)
in their IPv6 Router Advertisements. In that way, each
ISATAP host will autoconfigure an address from the
advertised IPv6 prefix and assign it to their ISATAP
interface, but they will not assign an IPv6 prefix to
the ISATAP interface. Therefore, no two ISATAP hosts will
see each other as on-link neighbors, and all IPv6
communications from the hosts will flow through an ISATAP
site border router in order to access IPv6 services in
the Internet.

Migration to Native IPv6 Services
*********************************
ISATAP hosts should be configured to prefer native IPv6
services instead of ISATAP whenever available. As the site
transitions its internal routers and links to use IPv6
natively, hosts will naturally begin to receive native
IPv6 router advertisments and will begin using the
native IPv6 service instead of ISATAP. As more and
more native IPv6 service is enabled in the site, IPv6
addresses can be entered into site name service resource
records to enable intra-site IPv6 service discovery. In
that way, predominantly IPv4 sites will begin to operate
a parallel native IPv6 service, and legacy IPv4 services
will gradually be phased out.
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops