Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"

From: Ray Hunter <[email-masked]>
Date: Tue, 03 May 2011 09:55:19 +0200

Warning: this is danger of me taking this off topic from 6to4, but John 
asked the question and made some statements about ISATAP.

IHMO [please please correct me/ improve this information if I'm wrong]

ISATAP (RFC5214)  runs over Protocol 41 tunnels.

ISATAP does not have "configured tunneling" i.e. end to end tunnels 
where both ends are configured manually: it is also an automatic 
tunneling mechanism.

ISATAP is enabled by default in Windows 7 but can be disabled in the 
registry (Services\tcpip6\Parameters\DisabledComponents to 0x4.)

Anyone who can place "isatap" in DNS or WINS can activate ISATAP for ALL 
hosts on a Windows 7 enterprise network at next reboot.

ISATAP also suffers from reliability issues within a corporate 
environment that includes firewalls (because of its use of protocol 41 
and automatic tunnels to an "unknown" endpoint).

Microsoft don't recommend "large" deployments of ISATAP as it is not 
scalable (to the best of my knowledge. I'm repeating advice from a 
Microsoft bod here and don't have a direct reference source)

IPv6 over ISATAP over IPv4 is preferred over native IPv4 as far as I 
understand from the current RFC3484. [and at least according to 
Microsoft's book Understanding IPv6 v2 p219-221]

ISATAP will still be preferred over native IPv4 in RFC3484 bis, even 
though Teredo and 6to4 aren't [I've already mailed the authors about this]

As ISATAP is based on well-known node identifiers (and not a well-known 
network prefix) it does not fit neatly into the RFC3484 
IPv6-prefix-based policy table, so a network manager can't effectively 
enable ISATAP, but force it to be less preferred than native IPv4.

IMVHO in other words, it's potentially a very nasty accident waiting to 
happen in a corporate environment. But I have no evidence of current 
problems.

- all of this is clearly way outside the scope of the 6to4 discussion, 
but should not be forgotten if anyone feels like "improving" this 
situation, especially giving network operations managers the ability to 
configure preferring native IPv4 over ISATAP, because AFAIK no-one is 
covering this item in v6ops or 6man at the moment.

regards,
RayH

---

From: "John Mann (ITS)" <[email-masked]>
Date: Tue, 3 May 2011 22:23:24 +1000

Hi,

On 3 May 2011 17:55, Ray Hunter <[email-masked]> wrote:

> ISATAP does not have "configured tunneling" i.e. end to end tunnels where
> both ends are configured manually: it is also an automatic tunneling
> mechanism.
>
> ISATAP also suffers from reliability issues within a corporate environment
> that includes firewalls (because of its use of protocol 41 and automatic
> tunnels to an "unknown" endpoint).
>

You see "reliability issues", I see "flexibility" and "control points".

There can be selective enablement using a hierarchy of DNS names -
isatap.eng.example.com and isatap.prod.example.com, but no
isatap.admin.example.com nor isatap.example.com

For reliability, the "isatap" DNS RRs can provide a list of ISATAP router
addresses, and the ISATAP router addresses can be anycast - there is no
gateway or flow -specific state like 6to4, Teredo or NAT44.

A client will periodically poll for a working ISATAP gateway.
Client routing over ISATAP doesn't come up unless the RS / RA packet
exchange can be completed over protocol-41.
The ISATAP up or not decision is not made per-flow.

Inside the enterprise, I can filter protocol-41 such that clients on subnets
with native IPv6 can't get to any ISATAP router.
Some corners of my network don't have native IPv6 (e.g. Cisco WISM wireless
VLANs using AAA-override).
Using router lists and ACLs, I plan to let IPv4-only staff subnets get to
one set of ISATAP routers, and student/guest subnets get to another set -
putting staff and students on separate ISATAP subnets.

> scalable (to the best of my knowledge. I'm repeating advice from a Microsoft
> bod here and don't have a direct reference source)
>
> understand from the current RFC3484. [and at least according to Microsoft's
> book Understanding IPv6 v2 p219-221]
>
> ISATAP will still be preferred over native IPv4 in RFC3484 bis, even though
> Teredo and 6to4 aren't [I've already mailed the authors about this]
>
> network prefix) it does not fit neatly into the RFC3484 IPv6-prefix-based
> policy table, so a network manager can't effectively enable ISATAP, but
> force it to be less preferred than native IPv4.
>

The worst behaviour I have seen is the occasional client that gets tangled
and sends out *thousands* of DNS queries per second looking for isatap.*
names that don't exist.

> - all of this is clearly way outside the scope of the 6to4 discussion, but
> should not be forgotten if anyone feels like "improving" this situation,
> especially giving network operations managers the ability to configure
> preferring native IPv4 over ISATAP, because AFAIK no-one is covering this
> item in v6ops or 6man at the moment.
>
> regards,
> RayH
>

    John

---

From: Erik Kline <[email-masked]>
Date: Thu, 5 May 2011 18:13:34 +0200

I would like to add that it's the asymmetric routing that's the
problem with proto41 blocking detection ever working for 6to4.

Terminology/glossary for the example below:

    C:  the 6to4-using client

    DR:  the Decapsulating Relay (where proto41 packets from C to
192.88.99.1 actually go)

    S1:  an IPv6 server

    S2:  another IPv6 server

    Sn:  the Nth IPv6 server

    ER1:  the Encapsulation Relay for S1 (where native IPv6 packets
from S1 toward 2002::/16 actually go)

    ER2:  the Encapsulation Relay for S2 (where native IPv6 packets
from S2 toward 2002::/16 actually go)

    ERn:  the Encapsulation Relay for Sn (where native IPv6 packets
from Sn toward 2002::/16 actually go)

[Assumption 1]

The IETF issues an RFC to update 6to4 to include
6rd/ISATAP/whatever-style in-band reachability checks such that a
suitably-compliant 6to4 client can verify that proto41 is successfully
reaching its DR and know that this is working and detect rapidly when
it stops working.

[Assumption 2]

Client C is running the super-awesome newly-fixed 6to4 code update
with an implementation of Assumption 1.

[Assumption 3]

Client C is using and monitoring a fully functioning and super-awesome DR.

[Assumption 4]

There are no IPv6 peering disputes and IPv6 traffic from DR to S1..Sn
works perfectly.  [In reality, this should be the steady state of the
IPv6 Internet.]

[Assumption 5]

There are no IPv4 peering disputes and IPv4 traffic from ER1..ERn to C
works perfectly.  [In reality, this should be the steady state of the
IPv4 Internet.]

[Assumption 6]

Each S1..Sn have a route for 2002::/16 successfully reaching
corresponding ER1..ERn.

The fundamental architectural problem is that even with "proto41
detection", C can not verify that proto41 packets can be sent from ER1
to C.  And if they do happen to pass just fine, there's no way to
verify that they can flow from ER2 to C, ..., or ERn to C.

Furthermore, Assumption 6 is seriously in doubt.  In order for 6to4 to
work reliably for all S1..Sn (where N is the total number of IPv6
destinations C might ever desire to reach), Assumption 6 must not be
an assumption but a proven, working fact.  This is something that is
operationally unrealistic.  It lives solely in the "if only everyone
would just..." category of wishes and fairy tales.

"Symmetric", managed uses of proto41 don't suffer from these problems.
 There are no uncertain paths from Sn to ERn (it's just Sn back to C's
IPv6 ISP which fall under Assumption 4), and there is multitude of ERn
to C links, but rather the "ERn"s collapse into DR (philosophically,
if not quite literally in implementation, obviously).  Both the key
troubling parts in the return path from Sn to C are removed, and
proto41 detection is basically sufficient.

</ek>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 May 2011 14:09:35 -0700

Hello,

There has been quite a bit of discussion about the
uncertainty of unmanaged transition tools such as
6to4 and teredo. One way to turn off the unmanaged
tools is to turn on a managed tool such as ISATAP.

A new I-D on "Operational Guidance for IPv6 Deployment
in IPv4 Sites Using ISATAP" has been posted (see below).
Please review and send comments to the list.

Thanks - Fred
[email-masked]

--- cut here ---
From: [email-masked] 
To: [email-masked] 
Reply-to: [email-masked] 
Subject: I-D Action: draft-templin-v6ops-isops-00.txt 
X-RSN: 1/0/935/36563/39932 
 
A New Internet-Draft is available from the on-line Internet-Drafts directories. 
 
Title : Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP 
Author(s) : Fred L. Templin 
Filename : draft-templin-v6ops-isops-00.txt 
Pages : 18 
Date : 2011-05-05 
 
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 continues to provide satisfactory 
internal routing and addressing services for most applications. As 
more and more IPv6-only services are deployed in the Internet, 
however, end user devices within such sites will increasingly require 
at least basic IPv6 functionality for external access. It is also 
expected that more and more IPv6-only devices will be deployed within 
the site over time. This document therefore provides operational 
guidance for deployment of IPv6 within predominantly IPv4 sites using 
the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-00.txt 
 
Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/ 
 
This Internet-Draft can be retrieved at: 
ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-isops-00.txt 
_______________________________________________ 
I-D-Announce mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/i-d-announce 
Internet-Draft directories: http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 May 2011 12:16:00 +1000

In message <BANLkTikKj3-Mjdcu8=[email-masked]>, Erik Kline wri
tes:
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

The general case is:

1.  IPv6 client (with a 6to4 address)
2.  IPv6 encapsulating router
3.  IPv4 hops
4.  IPv6 decapsulating router
5.  IPv6 hops
6.  IPv6 server
7.  IPv6 hops
8.  IPv6 encapsulating router
9.  IPv4 hops
10. IPv6 decapsulating router
11. IPv6 client

1 and 2 can be the same box which makes 10 and 11 the same box.
6 and 8 can be the same box which removes 7.

Asymetric routing is not unique to 6to4 but almost always happens
with 6to4.  Making sure 2,3,4,9 and 10 work with dead router detection
seem like a win to me.  The rest of the problems are not unique
to 6to4.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Thu, 05 May 2011 19:59:31 -0700

> 6 and 8 can be the same box which removes 7.

Erik's argument is basically that box 8 is "operationally unrealistic" by which he means it isn't operationally realistic for large content providers or content delivery networks.

How many people in favor of moving 6to4 to Historic are very much concerned with the case where box 6 is some residential subscriber's network appliance at a 6to4 address, box 4 and box 8 are the same box, i.e. a dual-stack residential CPE router, and therefore path 5 and path 7 the same path, a single, lightly managed home network link?  Not many, it seems to me, and I'll bet money that those who are concerned with it would very much prefer to see that particular profile of 6to4 usage halted immediately.

> seem like a win to me.  The rest of the problems are not unique

Alas, dead router detection won't happen quickly.  Personally, I'd prefer to just abandon the 6to4 CPE router feature altogether, if that was possible, but without a phase-out plan, I don't think I will be able to do that.  The usage case I describe above is too attractive for people with monopoly service providers that, even today, have no announced plans to deploy IPv6 any time soon.

It will take longer than you might think to get dead relay router detection, and the proper functionality for reacting to it, rolled out to the field.  Failure to reach the default relay router means that all of the other potential decapsulating relay routers for the 2002:a.b.c.d::/48 prefixes, for which the default relay router is unnecessary, are also unreachable to hosts behind the 6to4 CPE router when the default relay is dead.  RFC 4191 More-specific Routes (MSR) options would be the natural way to deal with that, except MSR option processing isn't widely deployed in host systems yet.  Yet another feature that needs to be rolled out to the field.

New features don't appear the day after an engineer codes them.  They have to be qualified and loaded into delivery vehicles that launch on their own weird schedules, in very narrow windows, that only come every now and then when the entire tribe of miscreant faeries all dance together in the moonlight under just the right oak tree.

Shorter james: you might be waiting a long time for all the pieces of a proper solution to come together.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 May 2011 13:49:23 +1000

In message <[email-masked]>, james woodyatt wri
tes:
> Erik's argument is basically that box 8 is "operationally unrealistic" by whi
> ch he means it isn't operationally realistic for large content providers or c
> ontent delivery networks.

You mean its impossible for them to add something like this to the
boot scripts of 6 yet it is possible for them to configure a http
server, database and whatever else they are using.

# ifconfig ne0 inet6 2001:..... prefixlen 64
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
# ifconfig stf0 inet6 2002:8504:0506:: prefixlen 16 alias anycast link0
# route add -inet6 2002:: -prefixlen 16 ::1
# route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0

This is how much work it is to configure a FreeBSD box to do return
encapsulation for its own traffic.  Three extra configuration lines
at boot time.  The anycast prevents the OS using 2002:8504:0506::
as a source address for IPv6 connections initiated from the box and
the link0 blocks incoming encapsulated traffic.  This is a outbound
interface only.

Alternatively they configure the first hop router to do a similar thing.

You don't need to advertise 2002::/16 to anyone, you just encapsulate
the traffic you get through normal routing.

> How many people in favor of moving 6to4 to Historic are very much concerned w
> ith the case where box 6 is some residential subscriber's network appliance a
> t a 6to4 address, box 4 and box 8 are the same box, i.e. a dual-stack residen
> tial CPE router, and therefore path 5 and path 7 the same path, a single, lig
> htly managed home network link?  Not many, it seems to me, and I'll bet money
> that those who are concerned with it would very much prefer to see that part
> icular profile of 6to4 usage halted immediately.
> 
> Alas, dead router detection won't happen quickly.  Personally, I'd prefer to 
> just abandon the 6to4 CPE router feature altogether, if that was possible, bu
> t without a phase-out plan, I don't think I will be able to do that.  The usa
> ge case I describe above is too attractive for people with monopoly service p
> roviders that, even today, have no announced plans to deploy IPv6 any time so
> on.
> 
> It will take longer than you might think to get dead relay router detection, 
> and the proper functionality for reacting to it, rolled out to the field.  Fa
> ilure to reach the default relay router means that all of the other potential
> decapsulating relay routers for the 2002:a.b.c.d::/48 prefixes, for which th
> e default relay router is unnecessary, are also unreachable to hosts behind t
> he 6to4 CPE router when the default relay is dead.  RFC 4191 More-specific Ro
> utes (MSR) options would be the natural way to deal with that, except MSR opt
> ion processing isn't widely deployed in host systems yet.  Yet another featur
> e that needs to be rolled out to the field.
> 
> New features don't appear the day after an engineer codes them.  They have to
> be qualified and loaded into delivery vehicles that launch on their own weir
> d schedules, in very narrow windows, that only come every now and then when t
> he entire tribe of miscreant faeries all dance together in the moonlight unde
> r just the right oak tree.
>

---

From: Erik Kline <[email-masked]>
Date: Fri, 6 May 2011 09:04:33 +0200

You're vastly oversimplifying it.  Google does not run on a handful of
FreeBSD boxes, with a little bit of PHP and a MySQL backend.  This
kind of absurd reduction of reality is neither convincing nor
relevant.