Subject: [v6ops] new draft: draft-templin-v6ops-isops-00.txt

From: Ray Hunter <[email-masked]>
Date: Fri, 06 May 2011 20:56:50 +0200

Excellent document. Really clear. Thanks very much.

I still have a few outstanding operational issues with ISATAP in a 
commercial/ industrial environment that I'd greatly appreciate the 
authors expending some brain cycles on:

1) to confirm that these issues are real
2) whether there are any operational workarounds the v6ops group can provide
3) to come up with ideas for mitigation

I beg your indulgence.

After a fair bit of careful consideration, I have currently come to the 
conclusion that deploying ISATAP would probably be an epic fail if I 
deployed it in my customers' networks, and it has to be 100% disabled 
during the transition to native IPv6 (ironically enough as it is meant 
to be a transition mechanism). I suspect that deploying ISATAP in my 
customer's environments would be "career shortening." This isn't a 
flame. Just a statement of the way I see things at the moment. Maybe I'm 
wrong. But it would certainly be a risk. We're talking major 
multinationals. Maybe these aren't typical customer environments or 
target environments where ISATAP is intended to be deployed. Funnily 
enough, IPv4 has also proven quite popular in these environments too though.

The issues all revolve around SLA's, and the preference of ISATAP over 
native IPv4, rather than any "broken connectivity" like 6to4. The word 
"latency" looms large.

Firstly, I have a minor issue with the use of firewalls in commercial 
environments (They are unavoidable. Sorry. Blame the accountants)

In your draft you state that:

ISATAP client to client communications should therefore also only be 
used when the path between the clients is first tested in an initial 
reachability exchange.

I understand that this is functionality uses NUD after name resolution 
(Section 8.4 of RFC5214)

That means that IPv6 may fail after initially trying to establish a session.

Can you give me any guidance to how quickly NUD will fail when detecting 
unreachable hosts behind firewalls over ISATAP (presumably with a host 
unreachable) and then fallback to IPv4 ?

The issue is that even though the fallback is safe, it will probably not 
result in happy eyeballs (addressed elsewhere I guess) because the 
damage has already be done due to the initial connection delay.

Secondly, I see no links to any documents warning of the dangers of 
automatic tunnels.[e.g. rfc6169]

I think a link would be useful.

Again, it's the auditors. They don't seem to like it if someone can 
automatically tunnel into the finance data centre and blind side their 
firewall audit logging. Firewall support for native IPv6 and IPv6 over 
IPv4 is poor at the moment. Sorry, that was a whine. Let's move on.

Thirdly, I see no way to have common QoS mechanisms properly handle 
ISATAP encapsulated traffic.

Apparently QoS isn't that important a topic on the Public Internet yet 
(although I suspect it will become so as more people download video over 
wireless to their mobile devices)

Many corporations have spent significant amounts of money implementing 
WAN acceleration, packet shaping etc. (more fool them you might say, as 
many of the devices are not IPv6 aware).

Many corporations have also implemented IETF derived mechanisms like 
DSCP based WRED (based on RFC 2597).

Is there any guidance to vendors that they should support detection of 
IPv4 DSCP markings within an IPv6 ISATAP tunnel?
or whether/how these IPv4 DSCP bits should be made visible outside of 
the ISATAP encapsulation so that they can be acted upon by intermediate 
devices?

Otherwise all of the companies' QoS policies get blown out of the water 
as soon as ISATAP kicks in (and by default it does kick in on many 
popular operating systems, as confirmed in a customer's environment.)

QoS and differential services is a cornerstone of many SLA's.

Fourthly, many of my customers have strict SLA's for latency. The 
presumption of ISATAP would still seem to be that tunneled connectivity 
is fine, and that any additional latency to the nearest gateway router 
is not operationally significant.

Given that in a large multinational corporation there may be 
inter-continental hops involved to reach an ISATAP router, compared to a 
typical engineering requirement of <50mS round trip delay within a 
country for accelerated X windows applications, is there any mechanism 
to detect and/or limit the additional latency to the ISATAP router, over 
and above the basic test for connectivity?

This is complicated by the fact that so many of these executive types 
seem to insist on flying around the World and taking their laptops with 
them, rather than video conferencing over IP from their own desk. They 
also like to work from home, or on their customers' premises. I keep on 
telling them about speed of light limitations and to move the sites 
closer together, but they won't listen.

I'm guessing the answer will be "no" on the existence of a built-in 
ISATAP latency reduction/optimization mechanism. Such a mechanism could 
theoretically detect the round trip latency to a number of candidate 
ISATAP routers in the prl and then select the "closest" as part of the 
initial ISATAP router selection mechanism. Perhaps something to consider 
recommending to vendors as a future enhancement? Possibly with a 
configurable upper limit on the acceptable latency before declaring the 
router unusable?

Since the list of candidate ISATAP routers in the prl is fetched via DNS 
in many implementations, I guess my clients could implement some 
mitigation by setting the DNS server via DHCP based on location, and 
then serving different answers for isatap.foobar.com. However a lot of 
corporations have centralised their DNS servers via IPAM tooling, so 
there's only one per region nowadays, so that may or may not fly 
depending on the tooling. We're back to geographically aware DNS services.

But even then, they'd probably have to deploy an ISATAP router per site 
(several hundred sites) which may not all be rolled out at the same 
time. By the time you've done that, rolling out native IPv6 on multiple 
MPLS networks doesn't look so bad after all.

I'm not expecting ISATAP to be perfect, so please don't take this as 
whining, but I would like to avoid it breaking anything by default.

Now the main two showstoppers in common implementations:

a. by default, ISATAP is enabled

Is there any plan to request vendors disable ISATAP by default?

b. also by default, IPv6 over ISATAP over IPv4 appears to be preferred 
over native IPv4.

If I want to use ISATAP at all, at the moment I expect it'll always be 
preferred over native IPv4 if I prefer native IPv6 over native IPv4 
(default).

Can I prefer native IPv6 above native IPv4 above IPv6 over ISATAP over IPv4?

Because ISATAP is based on a well-known node prefix (last 64 bits of an 
IPv6 address, and not well-known IPv6 prefixes (left anchored front 
portion of an IPv6 address), and it provides IPv6 connectivity using 
standard IPv6 prefixes, even after implementing RFC3484 bis,  I know of 
no mechanism where a network administrator of a network with 
well-managed native IPv4 connectivity can prefer native IPv6 above 
native IPv4, but also prefer native IPv4 above ISATAP during a migration.

Is there any other operational way to achieve this?

Because if there isn't, the only options left over are to prefer 
corporate native IPv4 above all IPv6 (ouch, and not default today), or 
to disable ISATAP completely on all nodes (ouch, a potentially herculean 
task, because ISATAP is enabled by default today).

None of which is very satisfactory.

Thanks for reading this far.

regards,
RayH

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 May 2011 13:52:01 -0700

Hi Ray, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ray Hunter
> Sent: Friday, May 06, 2011 11:57 AM
> To: [email-masked] WG
> Subject: [v6ops] new draft: draft-templin-v6ops-isops-00.txt
> 

Thanks for taking the time to review and comment.

> enough, IPv4 has also proven quite popular in these 

Wow - these seem like fairly strong sentiments. But,
I appreciate that you have a serious obligation to
your customers!

> native IPv4, rather than any "broken connectivity" like 6to4. 

OK, but the preference only applies when there are
AAAA records for the intended correspondent in the
site name service. When there are only A records,
then native IPv4 will be used. So, a simple solution
is for the site administrator to simply not add any
AAAA records to the site-internal name service for
SLAAC-derived ISATAP addresses.

> I understand that this is functionality uses NUD after name 

I think you mean NUD after *address* resolution? The
RFC says: "ISATAP hosts SHOULD perform an initial
reachability confirmation by sending Neighbor
Solicitation messages and receiving a Neighbor
Advertisement message.". But, that does not prevent
the hosts from performing an initial reachability
confirmation via some other means, e.g., RS/RA,
ICMP echo/reply, etc.

> That means that IPv6 may fail after initially trying to 

The only time this would happen is when a pair
of ISATAP clients attempt to communicate directly
without sending their initial packets through an
advertising ISATAP router. The draft is advocating
that all initial communications go through an
advertising ISATAP router, which may return
redirection messages. When an ISATAP client
receives the redirection messages, however, it
does not need to heed them immediately. It could
instead continue to send its packets via the
advertising ISATAP router while testing the path
to the peer ISATAP client in parallel. Maybe the
draft could say this explicitly.

> unreachable) and then fallback to IPv4 ?

According to the draft recommendations, direct
peer-to-peer comms would only be enabled after
the path between the peers has been tested. Again,
this can be done in parallel with continuing to
send packets via an advertising ISATAP router,
hence ordinary data packets would not be subject
to loss.

The host unreachable is a nice optimization,
but if it is not generated nor dropped due to
filtering then it can't be counted on. You may
have better knowledge on this point than I do;
in well-managed sites, is it reasonable to
expect that ICMPs will be delivered by the
network without loss due to filtering? 

> damage has already be done due to the initial connection delay.

Again, this comes down to whether AAAA records
should be entered into the site-internal name
service in the first place. For SLAAC-derived
ISATAP addresses, the draft says no.

> I think a link would be useful.

OK.

> IPv4 is poor at the moment. Sorry, that was a whine. Let's move on.

OK.
 
> the ISATAP encapsulation so that they can be acted upon by 

Well, this is an interesting point. RFC5214 is
silent on the subject, and RFC4213 says: "Type
of Service: 0 unless otherwise specified.". But,
when I look at the Linux source code I see it
doing both DSCP and ECN mapping between inner
and outer headers - I guess that would be in
keeping with RFCs 2983 and 3168?
 
> and above the basic test for connectivity?

Well, yes. The site could put an IPv4 anycast
address as the lone address in the PRL. Then,
ISATAP clients will find the advertising ISATAP
router that is topologically closest. All the
site needs to do then is deploy sufficiently
distributed advertising ISATAP routers.

> closer together, but they won't listen.

Agreed that moving the sites closer together
would be a useful but miraculous feat. For
example, asking everyone in the southwest region
to relocate to the northeast would be a recipe
for failure (not that I have anything against
the northeast).

> configurable upper limit on the acceptable latency before 

The two options are to either manage the name
service entries so that there are "regional"
PRL names (e.g., northeast.example.com,
southwest.example.com, etc.) and put regionally
localized unicast IPv4 addresses in each PRL
name. Or, simply put an IPv4 anycast address
in the PRL and let IPv4 routing steer ISATAP
clients to the closest advertising ISATAP
router.

> depending on the tooling. We're back to geographically aware 

Or geographically-relative FQDNs as noted
above. Or simply place an IPv4 anycast
address in the PRL.

> MPLS networks doesn't look so bad after all.

I think this would very much depend on how the
site is organized. Surely, each partition within
the site needs to have a border router that can
reach the Internet. If that border router were
to become an advertising ISATAP router, then
the partition has a way of using ISATAP.

> a. by default, ISATAP is enabled

Yes.

> Is there any plan to request vendors disable ISATAP by default?

No.

> b. also by default, IPv6 over ISATAP over IPv4 appears to be 

That's not a problem as long as the ISATAP clients
only need to access IPv6 services that are outside
of the site and/or as long as site administrators
only place AAAA records within the site name service
for IPv6-only correspondents.

> Can I prefer native IPv6 above native IPv4 above IPv6 over 

There is not really a way to distinguish IPv6
prefixes used for ISATAP from any other native
IPv6 prefixes unless there were some sort of
distributed configuration files maintained.
However, the draft advocates that no ISATAP
addresses derived from SLAAC be entered into
AAAA records within the site name service.

> Is there any other operational way to achieve this?

Simply don't put SLAAC-derived ISATAP addresses
in AAAA records in the site name service, as
discussed in the draft.

> Thanks for reading this far.

I hope this response has helped?

Thanks - Fred
[email-masked]
 
> regards,
> RayH
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ray Hunter <[email-masked]>
Date: Sat, 07 May 2011 11:16:30 +0200

Thanks for the reply. I appreciate it. Sounds like I've got a problem 
for every solution though. :(

> I appreciate that you have a serious obligation to
They employ me because I keep on delivering. I'm only as good as my last 
project. I've successfully executed dis-entanglements and complex 
migrations of tens of thousands of users without any unplanned downtime. 
That requires control, advance planning, and most of all, predictability.

We're talking 10000+ users on 100+ sites in 20+ countries with 4 major 
outsource providers. And that's a mid-sized customer. Big ones are 100K 
users on 500+ sites in 50+ countries. All combinations are possible. 
There'll be both AAAA records and A records simultaneously. There'll be 
IPv4 only servers and dual stack servers simultaneously. There'll be 
every flavour of Windows you have ever heard of, and possibly even some 
you haven't. There'll be machines that are so ancient that they need to 
have the entire OS recompiled just to renumber the IPv4 address (so they 
won't be renumbering). I came across one PDP11 machine in a factory 
running DECnet phase III (yes III, not IV) There'll be some laptops that 
have migrated and some that haven't. There'll be broken 
implementations.  There'll be admins with limited IPv6 knowledge and 
experience. There'll be at least 2 major LAN switch vendors (one of 
which is now bankrupt). There'll be some site LANs that have migrated to 
dual stack and some that haven't. There'll be some firewalls that work 
well, and others that don't.

And above everything, there's the expectation in senior management that 
this will be a smooth migration (hey even the most recent IETF v6ops 
drafts are still claiming this.)

Nothing will be migrating in a big bang. So I think you get the idea 
that these are not homogeneous environments.
> then native IPv4 will be used.

Got that one. If there are only A records then they'll be used, because 
AAAA won't even be known to the address selection algorithm. Sounds 
obvious, and logical, However, an awful lot of systems are already 
registering IPv6 addresses automatically, even in an IPv4 only environment.

Also got the fact that global addresses are preferred over local 
addresses (due to scope = rule 2 from RC3484).

So IPv4 (global) is preferred over ISATAP using a link local derived 
address (local scope). Got that too.
> So, a simple solution

This could be the key gap in my knowledge / incorrect assumption.
Thanks for identifying this.

This is homework for me to see what exactly gets registered automatically.

When looking at Microsoft's book Understanding IPv6 v2 page 219-221.

Here it shows 2 ISATAP addresses:
2001:db8:21a5:a499::5fe:157.60.17.211 (global ISATAP address, non 
deprecated state)
and
fe80::5fe:157.60.17.211 (link-local address, non deprecated state)

So I'm not afraid of the fe80:: address. It's got lower scope (local) 
than a public PI IPv4 (global)
This is unlikely to cause any harm. It appears safe if a node complies 
with RFC3484 or anything similar.

p221 then goes on to show how 2001:db8:21a5:a499::5fe:157.60.17.211 
*would* be preferred over 157.60.17.211

That's the case that really scares me. The native IPv4 connectivity is 
undoubtedly fully functional and in control.
But that automatic tunnel is very probably out of control, slow, 
possibly broken, but it's still preferred by default.

Sorry, but that does not sound at all logical to me.

The key questions for me are then
when would that 2001:db8:21a5:a499::5fe:157.60.17.211 address be 
generated by a server?
when and how would that SLAAC derived ISATAP address appear in a naming 
service (DNS WINS host files etc.)?

That's the two things I know I don't know right now.

Windows auto registers a lot of AAAA records for servers in the IPAM / 
DNS system automagically as part of Active Directory (a non IETF 
protocol) by default using DNS dynamic update. Active Directory requires 
DNS. There's a direct mapping between the AD tree and the DNS tree. You 
cannot decouple AD and DNS, or disable this function.

Windows servers register these AAAA records even over an IPv4 only 
transport.

Microsoft recommend that you do not disable IPv6 as part of server 2008, 
because IPv6 is used internally for clustering (non IETF protocol).

Windows 7 also quite happily resolves these AAAA records over an IPv4 
only transport, and all of those nodes will try to contact an ISATAP 
router as soon as "isatap" is resolvable (via DNS, WINS or whatever).

So I'm guessing / hoping that the Windows implementations are well 
behaved and do not auto register the SLAAC derived ISATAP addresses as 
per the RFC: but then again they have incorrectly turned on RA when 
"connection sharing" has been enabled, creating rogue RA advertisements 
on wireless networks. That's a good example of how to create an 
unplanned downtime for many users caused by a seemingly innocent action 
by one single admin.

OMG here it is .... page 282 of Microsoft's Understanding IPv6 2nd 
edition. Last sentence.

"By default, an ISATAP host running Windows Server 2008 or Windows Vista 
will attempt to register global and unique local addresses in DNS using 
DNS dynamic update"

That's the problem right there if it's true. Servers auto registering 
SLAAC-derived ISATAP addresses in DNS, whereas the RFC recommends not to 
do this unless.... That's what I need to check.

Your assumption that it took human intervention to register a SLAAC 
derived ISATAP address in DNS would seem to be incorrect (if that text 
is correct and I've read it correctly), and at first glance the Windows 
implementation of ISATAP would NOT appear to be compliant with the 
recommendation of not registering SLAAC-derived ISATAP addresses into 
DNS. [to be checked of course]

> confirmation via some other means, e.g., RS/RA,
sorry yes. my bad. Ah OK, but do they really do this today? My 
understanding was that implementations only detected reachability 
information of the ISATAP router. Is it recommended practice to always 
ICMP ping before starting a session?

What would that time out be (or is it implementation dependent)?
> draft could say this explicitly.
I'm not sure I agree with your statement. These automatic tunnel 
mechanisms assume transparent and contiguous IPv4 and IPv6 clouds, with 
a single consistent crossing point between the two clouds.

Three letters and two words: "SOX compliance" & "outsourcing."

There are dozens, if not hundreds, of firewalls in most corporate 
environments. There is sometimes even a firewall per host for sensitive 
machines (like a database server).

All of these firewalls have different access rules and are managed by 
different groups. Sometimes they have thousands of rules each.

I don't think it is going to be safe to assume that all IPv6 nodes are 
available transparently to all ISATAP routers with the same access 
rules. That certainly isn't true for IPv4, so I see no reason why this 
would be true for IPv6. That means client to client connectivity can be 
highly irregular, but very predictable (you only get through if you've 
been authorized, but two machines next door to each other may have very 
different access)

Especially when different management groups / sites/ suppliers may be 
migrating at different times.

The ISATAP router may be on site A, the laptop of the traveling user on 
the customer's design-in project located on Site B, the DNS server on 
site C, and the server machines that the user is trying to access on 
site D, E, F & G (engineering simulation server, outsourced project 
management service server, cloud computing code repository, and home 
file server).

These sites could be hundreds of kilometers/miles apart and are very 
likely to be under different management regimes.

Both the IPv4 and (more than likely) the IPv6 clouds are anything but 
transparent and contiguous.

During transition it is definitely going to be a complete nightmare to 
synchronise all firewall rules for IPv4, native IPv6, and IPv6 over 
ISATAP/6to4/Teredo over IPv4 (especially given the awful support for 
IPv6 in firewalls, but I'm whining again)

That firewall rules synchronization problem could be a reason to kill 
ISATAP on its own. Just so that the firewall rules are native IPv4 and 
native IPv6 only. That takes away at least half of the additional effort 
of rule synchronization.

I don't know of any firewall implementation that allows you to properly 
filter and maintain control of IPv6 over ISATAP over IPv4. They have 
enough problems switching native IPv6 fast enough without performing 
deep packet inspection on tunnels. Which means you could lose control of 
connectivity over network security zone boundaries, which is a certain 
no-no.
[this is almost certainly a showstopper for deploying ISATAP in any sort 
of useful manner, but at least it means it's less harmful]
> network without loss due to filtering?
They'll  almost certainly be filtered by stateful firewalls. Those 
accountants have a lot to answer for.
> ISATAP addresses, the draft says no.
OK. That's very clear to me. Thanks. This is a key focus area. 
Unfortunately DNS content is generally not under the same control as the 
network transport provider in any multinational I know of. So to talk 
about a single "site admin" is pretty meaningless. There's a LAN admin, 
a workstation admin, a server admin, an engineering server admin, a DNS 
admin, a WAN admin .... and most are located off site and outsourced.

> keeping with RFCs 2983 and 3168?
As I say, the engineering guys start to get twitchy at anything >35mS 
(and that's between sites 800Km / 500 miles apart in different countries).

There are at least 2 different MPLS clouds so I'd have to check which 
each carrier offers which facilities.
Some companies have 4 or 5 separate MPLS clouds.

I know one of them certainly does NOT support NBAR (network based 
application recognition) matching.

Fortunately the match commands within the backbone "match DSCP" act on 
both IPv4 and IPv6 traffic, so that those do not need updating.

RFC 2983 seems to be IPv4 only. But I guess the Linux boys interpreted 
IP liberally as IPv4 or IPv6. Creative thinking.

Mapping sounded promising at first reading, but not for too long I'm 
afraid now I think about it more deeply.

The current DSCP classifiers act at the edge of the wide area network 
and are pretty basic. They generally act on a match of IPv4 source + 
IPv4 destination address + source port + destination port number + 
protocol (you know the usual 5 tuple suspects), or they allow a whole 
VLAN to set the EF bit for voice traffic for hard VoIP phones.

These classifier ACL's can be easily updated to include similar matches 
for native IPv6 protocols. No worries there.

They will almost certainly never be able to look inside a tunnel like 
ISATAP. It's way too heavy an operation for a CPE router.

I think this is beginning to sound tough, as the customers are unlikely 
to want to accept the DSCP markings from the end node. They've always 
done the DSCP marking in the WAN ingress routers / CPE. The classifiers 
generally over-write any existing DSCP bits set in the end node to 
prevent theft of service. It's going to mean a policy change to accept 
DSCP settings from end nodes.

Not only that, but the end node does not usually have a clue what the 
correct/appropriate QoS policy settings are in the first place. So you 
usually end up with defaults like EF for voice transport, but not much 
more than that.

Also each wide area network supplier generally has their own local 
configuration standard of what each DSCP marking means.....

One may use AF41 marking for video, and another AF41 for class 1 
traffic, which then translate into carrier-specific traffic engineering 
rules in their MPLS backbones, which are common for all customers, so 
these cannot be fiddled with.

So unless we can roll out a company specific classifying scheme to every 
single ISATAP node (= every workstation) that says ISATAP should mark 
traffic from Node X to Node Y as DSCP AF31, but with a default AF21 
(when connected in China) but to use AF41 and AF21 (when the laptop is 
outside of China).....

I not sure this sounds like it will fly in any sort of a manageable way.

So I guess anyone in my customers who wants QoS just has to avoid 
ISATAP. End of story.

I can certainly communicate that in advance. At least it might prevent 
people experimenting and being disappointed with IPv6.

>> typical engineering requirement of<50mS round trip delay within a
Sites do not manage their own LANs. That's ancient history. The 
outsourcer could put in an anycast address and an ISATAP router. But at 
a fee. And if it isn't in their standard service, that's going to be a 
big fee. Multiply that by 500 sites.

Sounds once again like a single step to native IPv6 is going to be the 
correct migration route.
> for failure (not that I have anything against
Oh intra-continental would be easy, we're talking moving continents. 
Engineers collaborating in India and Europe, factory in China.
> clients to the closest advertising ISATAP
OK understood. Might just be workable, but that might be too expensive. 
We'll have to investigate that thanks.

> above. Or simply place an IPv4 anycast
Right, but then we almost certainly lose the ability to debug 
meaningfully (see 6to4 discussion on anycast). The helpdesk is not 
located on site any more and has to debug remotely.
> the partition has a way of using ISATAP.
There are multiple outsourcers and LAN providers in any multinational.

Sites are generally much more complicated than you'd imagine you could 
possibly make them. I sometimes think people do this on purpose just to 
make my life interesting. Some are flat LANs. Some are campus networks 
shared among multiple companies. Campus networks are managed by the 
campus IT provider and not by the company: then there's a demarc hand 
over point into the corporate WAN. Campus / research sites mostly 
already have native IPv6 anyway.

Some physical sites house researchers, sales staff, engineering staff, 
high-security engineering staff (with their own firewalls), 
manufacturing, and third party engineers from a previous merger or 
de-merger, all on the same site. Some of them have multiple firewalls 
within the sites. Some of these sites have a firewall at the site egress 
(between the site router and the WAN router). Some don't.  Some of the 
data centres run their own internal MPLS networks, shared amongst 
multiple customers. Many sites don't have any local servers any more 
(file servers centralised per region)

So yes there is generally a main site site egress router at the WAN 
entry point, but there is often a debate about security and feature support.

So it's going to be very much on a case by case basis, and you can't 
talk about a "typical site."

The WAN CPE router is generally where it all comes together. Again if 
the WAN outsourcer decides to offer ISATAP as part of their standard 
service then maybe we'll get lucky. But that WAN router is also outside 
any site firewall so end users may be vey reluctant to use it. 
Considering the WAN suppliers relutance to turn on native IPv6, I 
suspect it will be an uphill/ expensive battle to get them to support an 
ISATAP router on that device too.

>> Is there any plan to request vendors disable ISATAP by default?
ah. That's where I have a problem. Default behavior for automatic 
tunneling should just be "off". Plain and simple IMVHO.

The default end node behavior should not be dependent on assumptions 
like if X and Y then do W, but if Z then do V, but only if A and B, 
unless .... but that's the way it is today. And RFC 3484 isn't even 
widely implemented apparently, so who knows how many implementations 
really behave and whether they've been tested in a particular 
combination of environments?

The default behavior should remain understandable to mere mortals, and 
it should always remain predictable throughout the migration. I submit 
that "Automatic tunneling = off" is both simple and predictable as a 
default.

If people want to consciously enable ISATAP, then fine make that easy. 
But make it so that they have to consciously touch each and every node 
in some way (AD policy setting, local config file, click here to enable 
whatever), and not so that the behavior of 10000+ nodes can be changed 
dramatically en masse and in an opaque way just because of a simple 
mistake or experiment in DNS by one administrator on the other side of 
the globe.

One shouldn't second guess the machine admin unless one is certain that 
it will not cause them problems, because the protocol designers and 
implementers have no way of checking whether the assumptions that were 
made when designing or implementing the protocol match the real 
assumptions and requirements in the actual deployment.

With all due respect, (and taking into account your email address), I'm 
sure that aircraft aren't designed with complex default behavior that 
may kick in unexpectedly dependent on external factors. Satellites are 
built the same way: if all else goes wrong, they go into "safe mode". 
IMVHO We should also design and specify protocols with simple, 
predictable, and safe-mode default behavior.
> for IPv6-only correspondents.
See above for the quote from Microsoft and auto registration [again to 
be confirmed].
> AAAA records within the site name service.
Exactly what I thought. The nodes currently pretty much universally use 
PI IPv4 addresses even internally (which of course confuses the 
assumption made for Teredo that everyone uses RFC1918 addresses on their 
LANs) These assumptions made in the design of the transition mechanisms 
are killing in all sorts of practical scenarios.

No matter what else you do, it's good practice to prefer native 
protocols over automatic tunneling as a default, unless this has been 
overruled by a conscious action by the machine administrator. RFC3484 
bis has finally come to that conclusion for 6to4 and Teredo.

The node administrator should be able to specify (and override) the 
default preference selection behavior for ISATAP SLAAC (global) and 
link-local (local) derived addresses compared to IPv4, but he can't as 
there's not tool or switch to do this.

I'd really like to change the prioritization of these global SLAAC 
derived ISATAP addresses (which are also automatic tunnels) to be less 
preferred than native IPv4 (for a warm safety feeling and to protect 
from rogue DNS admins) but I can't.

So that leaves the option of disabling ISATAP completely in all nodes.
> in AAAA records in the site name service, as
Yeah, and as I said you have potentially rogue DNS admins (you always 
have these, but one record could derail an awful lot) and potentially 
rogue implementations (again you have little protection here from bad 
programmers) but at least you could put in place multiple lines of defense.

I'm finding it's very difficult to override default policies and 
settings for the IPv6 transition mechanisms if I don't like them, or 
they don't fit my customers' operational requirements. And defaults 
should be just that: a default. Certainly not mandated or difficult to 
override behavior. Again, we should apply the principle of "the local 
node admin knows best."
> [email-masked]

It certainly helped clarify an awful lot, and I appreciate you taking 
the time to look at my questions, but I still don't have workable 
solutions for:
1) managing security of ISATAP automatic tunnels between network 
security zones (and every multinational has these, but it's outside the 
scope of your document),
2) setting correct QoS at a new point in the network (at an end node 
tunnel) (and many multinationals use DSCP),
3) really being able to mange latency introduced by tunneling (apart 
from via DNS content, which is not under the direct control of the 
network transport guys)
4) protecting against the odd rogue/incompetent DNS admin. (and I have 
seen them)
5) being able to set and manage default behavior and protocol preference 
settings with the granularity I need, which is a real concern. Relying 
on DNS content is not an acceptable solution for this IMHO.
6) there's still that question about Windows specific behavior and 
whether it registers SLAAC derived IPv6 addresses automatically in DNS 
by default (which would be a broken implementation)

On the flip side I perceive little or no benefit in having ISATAP 
enabled in the environments I work in. It just doesn't really feel 
scalable or manageable in a long and dynamic transition. There's just 
too many cross-functional / cross departmental / cross supplier 
dependencies. This is a personal opinion. Others working in more 
homogeneous, more geographically limited, less security paranoid, 
environments may come to a very different conclusion, and think it's a 
blessing.

The strategy to go forward would appear to be a one step to native IPv6 
on the end nodes.

That means employing transition mechanisms like GRE, 6in4, 6PE, and 
perhaps 6RD.

But in any case, solutions where native IPv6 goes in one end, and native 
IPv6 comes out the other end at a predictable location, managed by the 
network transport people, without anything in the middle or periphery 
being able to mess around with it.

So in conclusion, I still think the only sensible option at this time is 
to disable ISATAP completely in all end nodes. That's horrible I know, 
and a lot of work, and IMHO should be the default. This isn't just a 
knee jerk reaction. It's just the best least worst option IMHO.

regards,

---

From: Ray Hunter <[email-masked]>
Date: Sat, 07 May 2011 22:07:57 +0200

Ray Hunter wrote:
> security zones (and every multinational has these, but it's outside 
> the scope of your document),
> 5) being able to set and manage default behavior and protocol 
> preference settings with the granularity I need, which is a real 
> concern. Relying on DNS content is not an acceptable solution for this 
> IMHO.

I have worked out what I think is a workable and scalable answer to one 
of the problems anyway. It probably won't help me to be honest, but I 
think it may be useful for others to know who have less challenges. 
Maybe you could include this in a section on "Avoiding Excessive Latency 
to ISATAP routers"

so for

Problem 3) really being able to mange latency introduced by tunneling 
(apart from via DNS content, which may not be under the direct control 
of the transport network manager)

The "normal" suggested way of controlling which ISATAP client connects 
to which ISATAP router in a large organization network would be via 
controlling DNS content distribution, so users on site X would connect 
to isatap.sitex.example.com, whilst users on site Y would connect to 
isatap.sitey.example.com.

This creates a dependency between correct management of the content of 
DNS and the routing of traffic through the transport network.

Another alternative would be to deploy anycast addresses, so that the 
ISATAP client would connect to the nearest "local" ISATAP router. Use of 
anycast can also bring operational and debugging issues, which may not 
be desirable.

Yet another alternative is to use geographically aware DNS services to 
provide different answers for the list of routers to place in the plr 
list, dependent on the location of the ISATAP client. Geographically 
aware DNS can be complex to implement.

A related problem is the deployment of rogue ISATAP routers in the 
network, which may suffer from long-latency especially in international 
networks.

The optimal management of DNS content is thus not always practical in 
all cases. Although the management of the DNS server itself might be 
under tight central control of the group responsible for managing the 
transport network, the management of the DNS content may be distributed 
to separate entities and managed via IPAM tooling, including 
configuration of individual name and address records by less experienced 
or knowledgeable LAN and host managers. Some AAAA and A records may also 
be entered into DNS automatically (e.g. Windows Active Directory DNS 
dynamic updates). The DNS tree may not be subdivided by site. Use of 
geographically aware DNS services, or anycast addresses may not be 
desirable. Or there may be a large proportion of traveling users who 
move between sites.

All of the above may lead to inefficiencies, additional latency, and 
trombone-ing (where traffic travels from one site to an ISATAP router 
located on remote site via an ISATAP tunnel, before returning as native 
IPv6 to a third site) Trombone-ing would likely be particularly harmful 
in large international organizations, where there is generally 
significant base network latency due to speed of light limitations.

All of which leaves the transport network manager with the potential 
problem of how to control ISATAP client to router latency independently 
of DNS / plr content.

from http://tools.ietf.org/html/draft-templin-v6ops-isops-00#page-14

In order to avoid communication failures that may result from filtering, 
ISATAP clients (i.e., hosts and non-advertising routers) should only 
enable the service after an initial reachability exchange with an 
advertising ISATAP router (e.g., in an initial RS/RA exchange).

The ISATAP service should always check for connectivity before selecting 
one of the ISATAP routers from the plr list and enabling the service, 
and this is a one off action at start up, providing another potential 
and workable control mechanism.

Therefore a possible solution for the case where the transport network 
is separately managed from the DNS content, would be to intentionally 
disrupt the communication process during ISATAP service start up to 
disable ISATAP clients connecting to ISATAP routers with too high 
latency, or to off site ISATAP routers which have not been authorized 
for use by central management (partial rogue ISATAP router prevention).

There are two convenient locations where these additional traffic 
filters could be placed in typical corporate networks.

i) As an addition to the site egress filter / WAN ingress filter

Many corporations already deploy a WAN ingress filter to prevent IPv4 
spoofing, or to provide some base-level security via packet filtering.

The filter typically only allows traffic to enter the WAN that has 
source addresses from the ranges delegated to the site, and thus blocks 
all spoofed addresses, and other odd packets.

The existing WAN ingress filter could be extended to only allow protocol 
41 traffic to a cluster of "locally" located sites, some of which may be 
hosting ISATAP routers, some of which may be hosting ISATAP clients, 
whilst filtering all other protocol 41 traffic.

i.e. allow protocol 41 traffic from the local site address ranges to the 
address ranges associated with the cluster of sites hosting ISATAP 
routers and ISATAP clients that are connected to the network within an 
acceptable network latency distance of each other, whilst denying all 
other protocol 41 traffic.

This filter definition assumes that the 6to4 transition mechanism has 
not been deployed, because 6to4 also runs over protocol 41 tunnels. It 
also assumes that the filters are centrally coordinated so that clients 
on other sites will still be able to contact each other directly within 
the cluster via protocol 41 traffic for intra-subnet ISATAP traffic, as 
well as other native IPv6 hosts via the ISATAP router.

ii) as an egress filter on the LAN router hosting the ISATAP router, or 
as an ingress filter on the inbound LAN interface of the ISATAP router 
itself.

The filter here would only allow protocol 41 traffic to the ISATAP 
router from client IPv4 ranges delegated to sites that are connected 
within an acceptable network latency away from the ISATAP router. Native 
IPv6 traffic would be allowed from the ISATAP router to all IPv6 ranges. 
All other protocol 41 traffic would be blocked.

The appropriate choice of whether to deploy one or other or both filters 
would probably be made based on convenience and cost considerations 
(cost of changing WAN ingress filters, versus a dedicated filter in 
front of each ISATAP router). It should be noted that the WAN ingress 
filter is perhaps better placed to protect users from any rogue (and 
high latency) ISATAP routers in the network located on sites that are 
outside of the cluster.

So then, no matter how many ISATAP routers are seeded into the plr list, 
and no matter what their geographic location relative to the ISATAP 
clients, only ISATAP routers within acceptable latency, and located on 
sites which have been authorized for use, will be reachable during the 
initial reachability exchange, thus helping to reduce unintentional long 
hop latency or trombone-ing in the network.

[thanks to Fred Templin for the draft and explanation, ans John Mann 
(ITS) for the mail that helped turn the light on]

regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Sat, 07 May 2011 22:25:57 +0200

Ray Hunter wrote:
>> 4) protecting against the odd rogue/incompetent DNS admin. (and I 
>> have seen them)
>> concern. Relying on DNS content is not an acceptable solution for 
>> this IMHO.
>> whether it registers SLAAC derived IPv6 addresses automatically in 
>> DNS by default (which would be a broken implementation) 
>
> I have worked out what I think is a workable and scalable answer to 
> one of the problems anyway. It probably won't help me to be honest, 
> but I think it may be useful for others to know who have less 
> challenges. Maybe you could include this in a section on "Avoiding 
> Excessive Latency to ISATAP routers"
>
>
> so for
>
By the way. A far simpler solution, and shorter text. However it does 
require new code.

Avoidance of Excessive latency:

In order to avoid introducing excessive latency, ISATAP clients (i.e., 
hosts and non-advertising routers) should only enable the service after 
an initial check of network latency to the advertising ISATAP router 
(e.g. via an initial RS/RA exchange or ICMPv6 ping).

ISATAP client to client communications may also test the path between 
the clients in an initial exchange to check for acceptable latency.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 May 2011 07:17:55 -0700

Please see below for an update to this draft, plus
attached diffs. This version incorporates changes
that resulted mainly from list discussions. Please
review and send comments to the list.

Fred

--- cut here ---
From: [email-masked] 
To: [email-masked] 
Reply-to: [email-masked] 
Subject: I-D Action: draft-templin-v6ops-isops-01.txt 
X-RSN: 1/0/935/36699/40073 
 
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-01.txt 
Pages : 19 
Date : 2011-05-09 
 
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-01.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-01.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 May 2011 08:57:36 -0700

Ray,

Most of your grievances wrt ISATAP seem to stem from
an application in sites with either poor or ad-hoc
adminstrative coordination. ISATAP is only enabled
when the site administrators explicitly enable it,
and hosts should be able to assume that the site
administrators have done their homework beforehand
the same as for any other managed networking services
offered by the site.

You asked about latency to ISATAP routers, and I
responded that anycast is an alternative. The anycast
model for ISATAP is similar to that for 6rd, and the
6rd guys seem to have done a good job of convincing the
ISPs that the model is valid. And, remember that this
is a *managed* anycast service and not an unmanaged one.
Even without anycast, a host when presented with a PRL
that includes multiple IPv4 addresses could fire off a
salvo of RS messages (one to each PRL IPv4 address)
and simply accept the first RA reply it receives.

You seem also to be concerned about ISATAP'ing around
between hosts within the site, and in the SLAAC-based
model suggested in my draft that would still work. But,
my draft is advocating the SLAAC-based ISATAP service
as primarily a way for hosts within the site to access
IPv6 content outside of the site, i.e., all external
IPv6 communications would need to flow through a site
border router in any event. IPv4 within the site would
still be preferred.

About QoS, you were concerned that RFC2983 is IPv4
only, but that is not correct. RFC2983 talks about
IP in IP tunnels, but IP can be read within this
context as "either IP protocol version". RFC2983
cites RFC2474, which says:

   "This document defines the IP header field, called the DS (for
   differentiated services) field.  In IPv4, it defines the layout of
   the TOS octet; in IPv6, the Traffic Class octet."

i.e, the DS field is treated in the same fashion for
both IP protocol versions.

So, two options seem to be to roll out the ISATAP
service via well-planned and coordinated
administrative actions or to somehow overhaul the
entire site to understand native IPv6 - possibly
at great expense. Some sites may see it as much
simpler and cost-effective to roll out the ISATAP
service and to not have to update all of their
existing IPv4 infrastructure (apps, routers,
bridges, switches, etc.) to also recognize IPv6.

Fred

> From: Ray Hunter [mailto:[email-masked]] 
> Sent: Saturday, May 07, 2011 1:08 PM
> To: Templin, Fred L
> Cc: [email-masked] WG
> Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-00.txt
> 
> Ray Hunter wrote: