Subject: [v6ops] WGLC draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

From: Fred Baker <[email-masked]>
Date: Mon, 11 Apr 2011 05:35:14 -0700

This is to initiate a one week working group last call of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat; it will close a week from today. We had a working group last call and got some comments; the draft has since been updated. The diff from the February version is at http://tinyurl.com/4rlzaln. If you commented on the previous document, please advise the chairs and the authors of your view on the changes.

Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Apr 2011 11:18:14 -0700

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
[email-masked]

--- 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.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 12 Apr 2011 13:03:10 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Templin, Fred L
Sent: 11 April 2011 20:18
To: [email-masked]
Subject: [v6ops] Operational Guidance for IPv6 Deployment in
Predominantly IPv4 Sites - (pre-draft)

Hello,

Thanks - Fred

--- cut here ---

Introduction
************

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 08:53:35 -0700

Hi Gunter, 

> From: Gunter Van de Velde (gvandeve) [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2011 4:03 AM
> To: Templin, Fred L; [email-masked]
> Subject: RE: [v6ops] Operational Guidance for IPv6 Deployment 
> in Predominantly IPv4 Sites - (pre-draft)
> 
> Many thanks for sharing. 
> 

Yes, I said that - thanks for confirming. This is not
the only proposed way of operating ISATAP, but within
the framework of this specific proposal an automatic
sunset of ISATAP is part of the long-term plan.

> ISATAP is tunneling and eventhough its not as bad as 6to4, it is way

In this proposal, ISATAP is a way to get out of an
enterprise network in order to access IPv6 services
in the public Internet. That sort of access is likely
to go through deep packet inspection and firewalling
anyway, so any performance gains for native IPv6 over
tunneled IPv6 are likely to be lost at the site borders
anyway. Also in this proposal, unless the enterprise IT
staff wants to pull off the heroic effort of turning up
native IPv6 on all links, routers, hosts, applications,
etc., they are still good to go with IPv4 for continued
support of enterprise-interior services. Can you make a
good case that it is worth the investment of overhauling
the entire IT infrastructure just to claim support of
native IPv6 everywhere? For example, is it going to
make the end user experience better in some way?   
 
> due to a set of disadvantages it includes.

Well, if this proposal were implemented then any IPv6
communications would be for the purpose of accessing
services outside of the site, and those would be going
through a site border firewall/proxy/etc. "speed-bump"
anyway. Do you think native is going to make things
significantly better if the dominating factor in
performance is the penalty for crossing the site
border in the first place? 

> My take is that when a new
> RFC like this would 

That sounds like a good reason to have this text in a
near-term document rather than a longer-term document.
Especially since it would be nice to have this in
place before World IPv6 Day.

Thanks - Fred

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Apr 2011 12:52:09 -0700

> ISATAP.  ISATAP is tunneling and eventhough its not as bad as 6to4, it
> is way worse as native v6.

+1

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 12 Apr 2011 14:58:12 -0500

+1.  I already sent email to v6ops in the past week or two asking Fred
T. a question that a home LAN can do native ipv4 and native ipv4 and
thus why does the home need ISATAP.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Bush
Sent: Tuesday, April 12, 2011 3:52 PM
To: Gunter Van de Velde (gvandeve)
Cc: [email-masked]
Subject: Re: [v6ops] Operational Guidance for IPv6 Deploymentin
Predominantly IPv4 Sites - (pre-draft)

+1

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 13:18:35 -0700

Randy,

You are quoting out of context. Please go back and
read the rest of Gunter's original message and my
reply in their entirety. Then, if you are inclined,
please make a case as to why major enterprise
networks that have long been satisfied with IPv4
for enterprise-internal networking services should
make the jump to ubiquitous native IPv6.

Thanks - Fred

> From: Randy Bush [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2011 12:52 PM
> Cc: Templin, Fred L; [email-masked]
> Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 13:25:49 -0700

Hemant, 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hemant Singh (shemant)
> Sent: Tuesday, April 12, 2011 12:58 PM
> To: Randy Bush; Gunter Van de Velde (gvandeve)
> Cc: [email-masked]
> Subject: Re: [v6ops] Operational Guidance for 
> IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft)
> 

You have taken Randy's out-of-context quote and spun
it even further out of context. We have moved on to
a different page now; please go back and re-read the
latest posts to get proper context:

http://www.ietf.org/mail-archive/web/v6ops/current/msg08276.html
http://www.ietf.org/mail-archive/web/v6ops/current/msg08281.html
http://www.ietf.org/mail-archive/web/v6ops/current/msg08282.html

Thanks - Fred

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 12 Apr 2011 15:31:03 -0500

Fred,

Thanks for the pointers to the other messages.  When I get a chance,
will go thru the details in the URLs provided and get back to you.  But
I still reiterate my original point which was that is one has multiple
IPv6 subnets in the home LAN why not use routing for native IPv6 and
IPv4? 

Hemant

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2011 4:26 PM
To: Hemant Singh (shemant); Randy Bush; Gunter Van de Velde (gvandeve)
Cc: [email-masked]
Subject: RE: [v6ops] Operational Guidance for IPv6Deploymentin

Hemant, 

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Apr 2011 22:34:13 +0200

Fred,

> for inclusion in a new or existing draft. Any

thanks for writing this up.

I'd still like to see. as this is an operations group, how this would work in practice.
I'm particularly curious about how the host discovers its default router. e.g. would an IPv6 CE / ISATAP router be a DNS server for a given domain or inject a well known host name into a certain domain for ISATAP default router discovery to work? or would some other provisioning mechanism be used?

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 13:44:25 -0700

Hemant, 

> From: Hemant Singh (shemant) [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2011 1:31 PM
> To: Templin, Fred L; Randy Bush; Gunter Van de Velde (gvandeve)
> Cc: [email-masked]
> Subject: RE: [v6ops] Operational Guidance for 

I'm afraid I don't really understand your questions. The
point I am making is about provisioning of transitional
IPv6 services within predominantly IPv4 end user sites.
These "sites" may be of various shapes and sizes - some
quite small (e.g., the soho network of a local retailer),
and others quite large (e.g., a multi-national corporate
enterprise network). This discussion has therefore
transitioned to focus on site-internal considerations.

Thanks - Fred

> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Randy Bush

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 12 Apr 2011 15:49:58 -0500

> the (A,L) flags set to (1,0) in their IPv6 Router Advertisements.

IPv6 ND (RFC 4861) has no means to specify a prefix as off-link.  The
statement above from Fred T. has recommended to set the L-bit in the RA
as cleared to signal the prefix as off-link.  The on/off-link behavior
in ND is per destination address not a prefix.  Many folks have a
misconception that by merely clearing the L-bit in the RA, one has
signaled an IPv6 prefix off-link is not correct.  The only means to
specify (via the ND RA) a destination for off-link is to send an RA with
no PIO (Prefix Information Option).  One reason I can think of as to why
ND has no means to specify a prefix as off-link is because of the A-bit
in the RA.  The A-bit asks the hosts to perform SLAAC and thus the host
has other destinations as on-link within a /64 of the prefix doled out
in the PIO.  Thus how can the L-bit for A-bit == 1 be cleared to signal
the prefix as off-link?  Anyway, I do need to spend some time to read of
all of Fred T.'s documentation and get back to the mailer.  I will need
at least a week or two to read all of ISATAP emails and related blurbs.
Thus I will reply back in such timeframe.

Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 13:53:32 -0700

Hi Ole, 

> From: Ole Troan [mailto:[email-masked]] On Behalf Of 
> Ole Troan
> Sent: Tuesday, April 12, 2011 1:34 PM
> To: Templin, Fred L
> Cc: [email-masked]
> I'm particularly curious about how the host discovers its 
> default router. e.g. would an IPv6 CE / ISATAP router be a 
> DNS server for a given domain or inject a well known host 
> name into a certain domain for ISATAP default router 
> discovery to work?

The ISATAP router typically arranges to have its IPv4
address added to the Potential Route List (PRL) within
the name service for the site. That does not necessarily
mean the DNS - it could be some other site-internal
naming service. But, by and large, hosts should be
able to resolve the name "isatap.domainname" for the
"domainname" suffix associated with their attached link.

> or would some other provisioning mechanism be used?

We could have done it via a DHCP option as you and Mark
did for 6RD. There is in fact an expired draft from me
asking for a DHCP option, but after some initial interest
the idea just didn't seem to catch on. The lowest common
denominator as always is manual configuration, which
some hosts might choose over the name resolution method.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 14:14:00 -0700

Hemant,

What would a reasonable host implementation do with
a PIO in which the (A,L) flags are (1,0)? It would:
1) use SLAAC to configure an IPv6 address from the
advertised prefix, and 2) assign the address to the
interface over which the RA was received.

That's it! The host has no reasonable guidance whereby 
it can conceivable assign the IPv6 prefix to the link.
Remember that, unlike with IPv4, address and prefix
assignment in IPv6 are separate functions.

Also, the method of operating ISATAP I am describing
does not depend on strict adherence to any on-link vs
off-link determinations. The only thing is that hosts
that ignore the L bit may not be able to ping6 other
hosts via ISATAP within a partitioned site. But, unless
AAAA records for ISATAP IPv6 addresses are entered in
the site name service there is no reason for the host
to be ping6'ing within the site anyway. And, the sceanrio
I am describing is one in which no AAAA records for
ISATAP IPv6 addresses are entered in the site name
service.

I am sorry to hear that it may take you weeks and
weeks to catch up on this thread. If you try for
the three messages I cited, you would have all of
the context you need:

Thanks - Fred

> Sent: Tuesday, April 12, 2011 1:50 PM
> To: Ole Troan; Templin, Fred L
> Cc: [email-masked]
> inPredominantly IPv4 Sites - (pre-draft)
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Apr 2011 07:12:47 +0930

Hi Fred,

On Mon, 11 Apr 2011 11:18:14 -0700

> for inclusion in a new or existing draft. Any

I don't know if it has been though of before, however one alternative
use of ISATAP I've thought of is to facilitate IPv6 topology
hiding. The underlying IPv4 addresses probably would expose the network
typology, however if they're RFC1918 ones, they'd be unreachable
externally. Possibly this could be resolved by having only the ISATAP
domain link-local addresses use IPv4 addresses, and then have global ->
link local IPv6 translation tables which are then used to resolve a
global IPv6 ISATAP host address which doesn't include an interior IPv4
host address into a ISATAP link local and then interior IPv4 address. As
external parties would only use externally visible IPv6 addresses, the
IPv4 topology would then be hidden as well.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 15:07:24 -0700

Hi Mark, 

> From: Mark Smith 
> [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2011 2:43 PM
> To: Templin, Fred L
> Cc: [email-masked]
> externally.

There is probably a discussion point here, but I'll
note that other IPv4-embedding mechanisms like 6to4
and 6rd are not shy about exposing IPv4 addresses
externally. Especially with 6rd, the IPv4 addresses
may be from the private internal IPv4 addressing realm
of the ISP, so there would seem to be precendence for
just letting the IPv4 addresses leak out.

> Possibly this could be resolved by having only the ISATAP

I'm almost on-board with this, however I would not
want to see the site number all of its ISATAP host
interfaces with only link-local IPv6 addresses. Or,
maybe that's not what you were saying?

What I *could* see happening is for the ISATAP
router to maintain a translation table whereby
it translates the IPv6 address 2001:db8::[ISATAP]
coming from a host within the site to the IPv6
address 2001:db8::[EUI64] for communications with
hosts outside the site.

Even moreso, ISATAP hosts inside an enterprise
network are likely to need to go through an
enterprise-border proxy in order to talk to IPv6
servers out on the Internet, so the proxy itself
could do the translation as I suspect many IPv4
proxies currently do today.

Is that what you had in mind?

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Apr 2011 08:31:42 +0930

Hi Fred,

On Tue, 12 Apr 2011 15:07:24 -0700

> just letting the IPv4 addresses leak out.

I think people who're using those sorts of mechanisms probably aren't
concerned about using topology hiding so much, or are aware that only
one or a small number of public IPv4 addresses are exposed.

I'm imagining a conversation with people who like the topology
hiding that IPv4 NAPT provides, and think they need IPv6 NAPT for the
same reason. I think you could rebut that by saying that ISATAP could
be used to make all IPv6 hosts appear to be attached to a single /64,
also pointing out that ISATAP implementations are commonly available.
However, when they find out that underlying IPv4 addresses are embedded
in the ISATAP addresses, they'll then say that thats still exposing
IPv4 topology information that isn't exposed with IPv4 NAPT, and
therefore ISATAP isn't adequate, and therefore they need IPv6 NAPT.

So I think ISATAP is nearly capable of providing IPv6 and underlying
IPv4 topology hiding, as long as the exterior devices don't see the
underlying IPv4 addresses. It has just occurred to me that ISATAP +
stateful DHCPv6 addressing might achieve that. Do you know if that
would work or has been implemented anywhere?

> maybe that's not what you were saying?

No, it was that the underlying IPv4 addresses were only embedded in the
link local addresses used within the ISATAP domain, and the global IPv6
addresses used within the ISATAP domain were generic (non-IPv4
embedded) IPv6 addresses (e.g. SLAAC using some other non-IPv4 IID, or
privacy addresses, or stateful DHCPv6 addresses).

To resolve the underlying IPv4 address for inbound packets, with these
generic global IPv6 addresses, the look up mechanism would be -

1. Match up the global IPv6 address to an ISATAP domain link-local
address with the embedded IPv4 address.
2. Extract the IPv4 address from the link local address and use that
for the encapsulating packet IPv4 destination.

> address 2001:db8::[EUI64] for communications with

I think the drawback of that is that it is IPv6-to-IPv6 address
translation with all the related issues of NAT.

> [email-masked]

(got to rush off to catch my train!)

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Apr 2011 17:06:49 -0700

Hi Mark,

It sounds like what you'd prefer would be DHCPv6
over ISATAP interfaces. In that case, the routing
system matches up the (non-ISATAP) DHCPv6-delegated
IPv6 addresses with an ISATAP link-local address of
the host to which the address has been delegated.
We talk about how to do exactly that in Section
3.2.4 of 'draft-ietf-v6ops-tunnel-loops'.

So, this has come down to a DHCPv6 vs SLAAC bakeoff
on ISATAP links, I guess? I was told by an employee
of a major host implementation vendor that their
ISATAP host implementation does not do DHCPv6. But,
you list a number of reasons why DHCPv6 would be
beneficial.

This sounds like a recipe for a food-fight. Can I
run off to catch that train with you??

Fred

> Sent: Tuesday, April 12, 2011 4:02 PM
> To: Templin, Fred L
> Cc: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Apr 2011 13:44:28 -0700

The following is not a draft, but rather just a set
of ideas. Any comments or suggestions?

Thanks - Fred

--- 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, hosts within the
site will increasingly require IPv6 functionality for
external access.

Such IPv4 sites can use ISATAP [RFC5214] to provide IPv6
services to hosts within the site. Advertising ISATAP
routers distribute IPv6 prefixes obtained from an ISP
to hosts within the site via DHCPv6 or SLAAC for address
autoconfiguration purposes. If the site subsequently
reconnects to a different ISP, however, the site must
renumber to use addresses derived from the new IPv6
prefixes [RFC1900][RFC4192][RFC5887]. This non-draft
provides operational guidance for accommodating
simplified automatic renumbering within ISATAP sites.

With the emergence of IPv6-only services within the public
Internet, however, existing IPv4 sites will increasingly
require a means for enabling IPv6 services so that hosts
within the site can communicate with IPv6 correspondents
in the Internet. 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.

own behalf, i.e., they act as an ISP unto themselves. (Such
large sites need never incur a site-wide IPv6 renumbering.)

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

ISATAP hosts will automatically discover ISATAP site border
routers and configure ISATAP addresses using either Stateless
Address AutoConfiguration (SLAAC) or the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6). In order to provide
a simple service that does not interact poorly with existing
site topological arrangements, the site should limit IPv6
operation for external access only so that hosts only use
the ISATAP service for communicating with IPv6 correspondents
on the public Internet, while continuing to use IPv4 services
for intra-site communications.

In order to maintain an external-only service, the site
should not publish any IPv6 addresses provided by ISATAP
within the site name service. The site should further not
write down any IPv6 literal addresses within configuration
files, documentation, packet filter rules, etc. An exception
to this rule is that literal addresses may be used within
packet filtering rules as long as they can be automatically
rewritten during a site renumbering event. In this way,
intra-site communications will continue to use existing
IPv4 networking services instead of ISATAP served IPv6
services.

Simplified Automatic Renumbering within ISATAP Sites
****************************************************
When the site is configured in the manner described above,
site renumbering in the event of a change in an ISP-served
IPv6 prefix entails only the renumbering of IPv6 addresses
and/or prefixes that are assigned to the ISATAP interfaces
of hosts within the site. In some cases, filtering rules
(e.g., within site border firewall filtering tables) may
also require renumbering, but this operation can be automated
and limited to only one or a few "touch points" at the site
border.

In order to renumber the ISATAP interfaces of hosts within
the site, however, the ISATAP routers need only schedule
the services offered by the old ISP for deprecation while
beginning to advertise the IPv6 prefixes provided by the
new ISP. ISATAP host interface address lifetimes will
eventually expire, and the host will renumber its interfaces
with addresses derived from the new prefixes.

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 need to be updated
during the renumbering operation. This can be accomplished
via secure dynamic updates to the DNS.

---

From: "Lee Howard" <[email-masked]>
Date: Fri, 15 Apr 2011 18:14:55 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Templin,
> Fred L
> Sent: Monday, April 11, 2011 2:18 PM
> To: [email-masked]
> Subject: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly
IPv4 Sites -
> (pre-draft)

The requirements for end-users and large corporate networks
are different.  For a commercial network, making sure external-
facing servers are IPv6-enabled is a higher priority than making 
sure users have IPv6 access.  Commercial/enterprise networks
have network administrators who configure routers (and might
even have routers that support ISATAP).

If you're providing general advice about how to make IPv6
available, you need to advise on how to evaluate options,
which may include ISATAP.  The document you've written
isn't general operational guidance, it's an ISATAP primer, and
it would be less confusing if it were labeled as such.

Lee

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Apr 2011 15:40:19 -0700

Hi Lee,

Thanks for the thoughts, and see below: 

> From: Lee Howard [mailto:[email-masked]] 
> Sent: Friday, April 15, 2011 3:15 PM
> [mailto:[email-masked]] On Behalf Of
> Templin,
> > Fred L
> are different.

I understand your point, but end-user sites come in
infinitely many shapes and sizes. There is my home
network behind a NAT, which is really just a single
flat IP subnet supporting a few laptops, printers etc.
Then there is  my local tire dealer down the street
which probably has a network of 20-odd computers, some
number of handheld devices, printers, faxes, etc. Then
there are banks - some with only 1-2 branches, and some
with 100's or 1000's of branches. Then there are mobile
vehicular networks like cars and planes. Then there are
disaster relief networks, tactical military networks,
and other forms of MANETs. And, finally we come to major
multinational large corporations. This is why whenever
I see a solution proposal I ask folks to write an
applicability statement. So far, no one but me has:

http://www.rfc-editor.org/rfc/rfc6139.txt

What people don't seem to be getting is that there is
a rich continuum of what can be classified as a "site"
ranging from the very small (my cellphone and its
attached bluetooth devices) to the very huge (the Boeing
Corporate network). And the degree to which the site
needs to become "IPv6 native" vs. "still IPv4, but
IPv6-enabled" varies on a case by case basis and is
not binary based, e.g. on "corporate" vs. "end-user". 

> For a commercial network, making sure external-

Sure.

> it would be less confusing if it were labeled as such.

Well, this was specifically labeled as "pre-draft"
and nothing has gone to the I-D repository. I don't
mind hearing about other options - do you have any
you want to propose?

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Sat, 16 Apr 2011 10:42:47 +0200

>not binary based, e.g. on "corporate" vs. "end-user". 

I think for this discussion it would be good if you try to narrow down the
range of sites to something where ISATAP would be most appropriate. Yes we can
try to discuss how ISATAP can be used in an ordinary home site with just a
single NAT router, but it doesn't make much sense.

>mind hearing about other options - do you have any

Assuming a big site with just a few places that need IPv6 right now I can
imagine: IPv6 capable routers in places that need IPv6 connected by:
- 6in4 tunnels, or
- A parallel IPv6 backbone (assuming intra-site connection are all some kind
  of ethernet, that should be quite easy), or
- A 'sparse' IPv6 backbone based on vlans.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Apr 2011 08:44:31 -0700

Hi Philip, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Saturday, April 16, 2011 1:43 AM
> To: Templin, Fred L
> Cc: Lee Howard; [email-masked]

OK - I will narrow it down to that set of sites that
are currently predominantly IPv4 and that have
satisfactory intra-site communications using IPv4.

> - A 'sparse' IPv6 backbone based on vlans.

None of these are simpler nor more catch-all than
just turning up the domainname "isatap.domainname"
in the site.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Mon, 18 Apr 2011 19:16:38 +0200

>just turning up the domainname "isatap.domainname"

I don't have any operational experience with ISATAP, so these are just some
of questions that come to mind:
- what do you do with hosts that do support IPv6 over ethernet but don't
  support ISATAP?
- This looks like an all of nothing property: either you enable ISATAP for all
  hosts in your organisation or you don't. What if you just want a few subnets
  to have IPv6 connectivity (or if you want the phase it in gradually)?
- It seems that all hosts are in a single subnet. What about the security 
  implications. If you have internal IPv4 firewalls in your organisation do
  you also have to figure out how to filter ISATAP traffic with them?
- ISATAP doesn't have multicast. What about protocols that rely on multicast,
  like mDNS?
- Suppose that at some point you will have a native IPv6 backbone. How do you
  route (in a decentralized way) between ISATAP and the native IPv6 nets?

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Apr 2011 10:45:43 -0700

Hi Philip, 

> Sent: Monday, April 18, 2011 10:17 AM
> To: Templin, Fred L
> Cc: [email-masked]

Hosts that don't support ISATAP but that are buried
somewhere deep in an IPv4-routed site would require
the site administrator to dig down deep into the site
while turning up IPv6 routing on all of the routers
in the path. That might be easier for some sites than
for others.

You can probably tell from this that I believe all
hosts should support ISATAP. It really isn't hard to
do, and can be slipped in as part of an automated
(or pulled) host S/W upgrade.

>   to have IPv6 connectivity (or if you want the phase it in 

It doesn't have to be all or nothing, and there are
ways to operationally limit IPv6 connectivity to only
certain IPv4 subnets. For example, configure ISATAP
routers to only send RA responses to hosts that use
specific IPv4 subnet prefixes.

Another way is to partition the site based on domain
names, e.g., configure the domain name
'isatap.engineering.foo.com' but do not configure
the domain name 'isatap.marketing.foo.com'. 

>   you also have to figure out how to filter ISATAP traffic with them?

Well, if there are IPv4 firewalls in the site then the
ISATAP link (or links) would be partitioned, and some
ISATAP hosts would not be able to reach others directly.
This could be solved if the firewalls were reconfigued
to recognize ip-proto-41 and perform IPv6 firewalling
based on the inner IPv6 packet, but that seems somewhat
unlikely in general practice.

Remember however that I am anticipating the use of IPv6
only for accessing IPv6 correspondents outside of the
site, so in the general case all/most ISATAP-serviced
IPv6 traffic would be going from host<->router.

> - ISATAP doesn't have multicast. What about protocols that 

For service discovery within the site, why not just
continue to use IPv4? For site-internal communications,
why fix what isn't broken?

>   route (in a decentralized way) between ISATAP and the 

I'm not sure I quite understand the question (some
pictures might help) but when native IPv6 routers
show up on the link the hosts should begin using
native IPv6 and either deprecate ISATAP or use it
as a backup service.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 Apr 2011 10:53:25 +0200

In your letter dated Mon, 18 Apr 2011 10:45:43 -0700 you wrote:
>> - what do you do with hosts that do support IPv6 over=20
>> ethernet but don't
>>   support ISATAP?
>

That's why I suggested that routers be connected by tunnels. Or alternatively
the creation of vlans that bypass those IPv4 routers.

Note, I'm just listing alternatives. I'm not implying that ISATAP should not
be used at all. But I think that if this becomes an RFC, then it should try
to list reasonable alternatives.

>(or pulled) host S/W upgrade.

Yes, for mainstream operating systems. But these days there are many other
types of devices that people want to have internet access.

>> - This looks like an all of nothing property: either you=20
>> enable ISATAP for all
>>   hosts in your organisation or you don't. What if you just=20
>> want a few subnets
>>   to have IPv6 connectivity (or if you want the phase it in=20
>> gradually)?
>

That could be an option. Assuming that all ISATAP clients understand that
you can have an ISATAP interface without a prefix and that routers support
that kind of functionality.

>the domain name 'isatap.marketing.foo.com'.=20

I doubt that anybody is going to change their use of DNS domain names just to
accomodate ISATAP.

>> - It seems that all hosts are in a single subnet. What about=20
>> the security=20
>>   implications. If you have internal IPv4 firewalls in your=20
>> organisation do

>IPv6 traffic would be going from host<->router.

At work, there are kinds of filters between various nets. And not just
completely denying all traffic between hosts, but allowing or denying incoming
TCP connections, outgoing connections. To certain ranges of ports.

Assuming an IPv4 router doesn't know anything about IPv6, it will be very
hard to specify those kinds of filters for IPv6 traffic. So the only option
will be to disallow proto-41 completely.

If you do that, then putting IPv6 addresses for local servers in DNS will also
not be an option. 

So you set yourself up to just being a client network that cannot have any
servers.

>> - ISATAP doesn't have multicast. What about protocols that=20
>> rely on multicast,
>>   like mDNS?
>

Because it is confusing? You enable a new protocol but have to keep relying
on a legacy protocols for all kinds of services. Not a problem in the
immediate future. But I would only introduce such an option as a last resort.

>> - Suppose that at some point you will have a native IPv6=20
>> backbone. How do you
>>   route (in a decentralized way) between ISATAP and the=20
>> native IPv6 nets?
>

Suppose you have a huge number of ISATAP hosts on a site and then you
start introducing a few native subnets. How do you route the traffic from
all those ISATAP hosts in an efficient way to the native subnets?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Apr 2011 07:28:35 -0700

Hi Philip, 

> Sent: Tuesday, April 19, 2011 1:53 AM
> To: Templin, Fred L
> Cc: [email-masked]
> That's why I suggested that routers be connected by tunnels.

Networks-within-networks, I guess? I have already described
that in RANGER:

http://www.rfc-editor.org/rfc/rfc5720.txt

> Or alternatively

Tim Chown has already described that in RFC4554:

http://www.rfc-editor.org/rfc/rfc4554.txt
 
> to list reasonable alternatives.

OK. If anything gets published, I'll be sure to
cite RFC4554.

> types of devices that people want to have internet access.

Anything that runs embeded linux already has ISATAP.
But, you have a point that there may be a class of
low-end devices that might be better off as native
IPv6. I'm not advocating that there be no native
IPv6 edge networks - see Section 3.2.4 of:
'draft-ietf-v6ops-tunnel-loops'.

> that kind of functionality.

ISATAP interfaces without a prefix are certainly possible
when the hosts can run DHCPv6 over the ISATAP interface
(see Section 3.2.4 of 'draft-ietf-v6ops-tunnel-loops').
But, that's not what I'm saying. What I'm saying is
that if the router receives an RS from a host on an
IPv4 subnet that it is not configured to serve, then
it can silently ignore the RS.

> I doubt that anybody is going to change their use of DNS 

No, that's not what I'm saying. I'm just talking about
adding the hostname 'isatap' to the domain name suffixes
that the site already has deployed. The 'engineering' and
'marketing' domain names I cited above are examples of
domain names that are pre-existing within the (fictitious)
site and not something that gets added just to accommodate
ISATAP.

> TCP connections, outgoing connections. To certain ranges of ports.

Right.

> will be to disallow proto-41 completely.

Right, but that is for going "horizontally crosswise"
within a site hierarchy - not "vertically up and down".
Any path that would try to go horizontally crosswise
would first have to be tested to see if there are
filters in place.

> So you set yourself up to just being a client network that 

Why not? A client in the site can always get to the
servers by going vertically up to an ISATAP router
and then back down to the server. If there are no
filters in the path, then it can route optimize and
go horizontally crosswise instead. Again, please see
Section 3.2.4 of 'draft-ietf-v6ops-tunnel-loops'. 

> immediate future. But I would only introduce such an option 

What's confusing about just leaving well enough
alone and saving the site $M's of investment to
change out applications, data bases, routers, etc.
that only know about IPv4? Hosts will use the name
service and source address selection to know when
to use IPv4 vs. IPv6.

> all those ISATAP hosts in an efficient way to the native subnets?

Section 3.2.4 of 'draft-ietf-v6ops-tunnel-loops'.

Thanks - Fred