Subject: Re: [email-masked]

From: Ray Hunter <[email-masked]>
Date: Mon, 09 May 2011 13:36:32 +0200

Thank you very much for replying to my message.

I have copied the 6man mailing list into the reply, plus your original 
mail is attached below, as you requested, so as to involve a larger 
community in the discussion.

Yes. You have a humble opinion that ISATAP is equivalent to native IPv6 
and therefore RFC 3484 bis is already adequate to cover all use cases.

And I have a different humble opinion, that I like native IPv6, but I 
think ISATAP is worse than native IPv4, and this use-case cannot be 
coded into RFC3484 bis.

Both of us may be correct, dependent of the deployment scenario. My 
customers generally have excellent native IPv4 networks. I'm sure that 
they want to build excellent native IPv6 networks. ANY tunnel is likely 
to be worse than their support of either native protocol. And an 
automatic tunnel where the end points may physically move (think 
traveling users) even more so.

The point is that my humble opinion cannot be encoded into RFC3484 bis 
as proposed. Indeed I cannot configure any implementation of ISATAP that 
I know of today to behave as I desire. I have no way of controlling the 
relative preference of native IPv6, versus IPv6 over ISATAP over IPv4, 
versus native IPv4.

I can either prefer all IPv6 above all IPv4, or all IPv4 above all IPv6. 
But I can't get any more granular than that. That to my mind is not 
enough, because we do not know the exact deployment decisions that are 
going to be made by all network managers in the move to IPv6. The 6man 
WG can assume that ISATAP is equivalent to native IPv6, but some others 
may conclude otherwise.

I have posted elsewhere about my opinions on the lack of adequate 
control in ISATAP in the v6ops WG in reply to the draft 
http://tools.ietf.org/html/draft-templin-v6ops-isops-00

To summarise: Because ISATAP is a host to gateway tunnel, it has no 
in-built way of controlling/ limiting additional network latency, nor of 
correctly applying DSCP QoS settings, nor can it be filtered by today's 
firewalls in a granular manner. So ISATAP is certainly not equivalent to 
native IPv6 in my mind. It also relies heavily on management of one 
particular DNS / WINS name space content (which may be dynamically 
updated as part of standard Windows AD operation), which IMHO is no way 
to control a network. One inquisitive/ incompetent server admin setting 
his Windows server name to "isatap" can change the behavior of 10000+ 
nodes on an international corporate network. That's not my definition of 
"managed." So my conclusion is that I have to switch ISATAP off, 
everywhere, until those shortcomings are addressed.

I'm not asking the 6man WG to "fix" the shortcomings of ISATAP, although 
that would be nice.

All I'm asking you guys to consider is whether your RFC3484 bis draft is 
complete if it cannot encode ALL combinations of preferences regarding 
which native network protocol or transition mechanism to prefer over 
another. The IETF does not control or mandate all deployment scenarios. 
Nor should it.

In particular I ask you to further examine supporting the use case: 
native IPv6 >> native IPv4 >> IPv6 over ISATAP over IPv4.

BTW just to say something very positive: the extension of RFC3484 bis to 
include ISATAP prioritization + DHCP(v6) distribution would likely be an 
extremely useful mechanism for controlling default end node behaviour in 
multinational companies (where AD may not be universally deployed). So 
keep up the good work in 
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00

best regards,
RayH

Arifumi Matsumoto wrote:
> Ray,
>
> On 2011/05/02, at 19:57, Ray Hunter wrote:
>
>    
>> Appreciate your work on RFC3484 bis. I sent a comment regarding http://www.ietf.org/id/draft-ietf-6man-rfc3484-revise-02.txt via the IETF web site, but I have a suspicion it black-holed.
>>
>> Excuse me if I'm barking up the wrong tree here. Also forgive me if I'm wrong because interpreting some of these rules confuse me a lot.
>>      
>
> These addresses are good. But, the ietf mailing list 6man may be even more better in that you can gather comments from more people.
>
>    
>> ISATAP (RFC5214) uses an IPv6 node identifier (based on an IPv4 address) that is appended to a standard IPv6 /64 prefix to create an IPv6 overlay network over an existing IPv4 network. So far so good, it provides IPv6 connectivity over IPv4 to IPv6 only hosts.
>>
>> But what about dual stack hosts?
>>
>> Given that you have now concluded that 6to4 is bad, and Teredo is even worse, because it is based on a transition mechanism that works over a dynamic tunnel, shouldn't IPv6 over ISATAP be similarly assigned a low priority compared to native IPv4?
>>      
>
> I do not think all the transition mechanisms should be less-preferred.
> 6to4 and Teredo are un-managed transition mechanisms, so they are less-preferred for that reason.
> IMO, ISATAP is deployed and controlled by a site administrator who may be ISP or enterprise network admin.
> So, I do not think it is unmanaged.
>
>    
>> In Microsoft's book "Understanding IPv6 v2" on page 219-221, they even give an example showing how ISATAP combined with a global unique IPv6 unicast prefix would be preferred over native IPv4.
>>
>> I can't imagine a single case of a dual stack host that would get better performance using IPv6 over ISATAP over IPv4 than it would get over a native IPv4 connection. Unless we are in the last days of IPv4, and there really are only IPv4 islands left.
>>      
>
> Just like 6rd, IPv6 may not be better than IPv4 with regard to MTU.
> However that point alone should not be a reasonable motivation to de-prioritize IPv6.
>
>    
>> Then again, I'm not at all sure how you could handle that in a RFC3484 bis type policy table, given that ISATAP does not conform to the comfortable notion that all mechanisms are left-anchored in the addressing scheme / are IPv6 prefix length based.
>>
>> Maybe the whole mechanism needs a review?
>>
>> Or ISATAP needs moving to historic status?
>>      
>
> RFC3484-bis does not include any changes with regard to ISATAP.
> And, as I mentioned above, IMO ISATAP should be just treated like global IPv6 addresses.
>
> Best regards,
>
> --
> Arifumi Matsumoto
>    NGN System Architecture Project
>    NTT Service Integration Laboratories
>    E-mail: [email-masked]
>    TEL +81-422-59-3334 FAX +81-422-59-6364
>
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 10 May 2011 19:59:30 +0900

I do not see exactly what your problem is.
Is it the default policy to be defined in RFC3484bis ?
Or, RFC3484's flexibility to prefer/de-prefer ISATAP ?

If it's the latter case, you can configure the policy table so that it de-prefer your own ISATAP prefix. As you mention it, draft-ietf-6man-addr-select-opt-00 should be a good way to go.

If it's the former case, I do not agree to de-prefer ISATAP prefix than IPv4, because IPv4 does and will bring worse user experience with the advance of IPv4 address shortage.

Best regards,

On 2011/05/09, at 20:36, Ray Hunter wrote:

> I have copied the 6man mailing list into the reply, plus your original mail is attached below, as you requested, so as to involve a larger community in the discussion.
> 
> Yes. You have a humble opinion that ISATAP is equivalent to native IPv6 and therefore RFC 3484 bis is already adequate to cover all use cases.
> 
> And I have a different humble opinion, that I like native IPv6, but I think ISATAP is worse than native IPv4, and this use-case cannot be coded into RFC3484 bis. 
> 
> Both of us may be correct, dependent of the deployment scenario. My customers generally have excellent native IPv4 networks. I'm sure that they want to build excellent native IPv6 networks. ANY tunnel is likely to be worse than their support of either native protocol. And an automatic tunnel where the end points may physically move (think traveling users) even more so.
> 
> The point is that my humble opinion cannot be encoded into RFC3484 bis as proposed. Indeed I cannot configure any implementation of ISATAP that I know of today to behave as I desire. I have no way of controlling the relative preference of native IPv6, versus IPv6 over ISATAP over IPv4, versus native IPv4. 
> 
> I can either prefer all IPv6 above all IPv4, or all IPv4 above all IPv6. But I can't get any more granular than that. That to my mind is not enough, because we do not know the exact deployment decisions that are going to be made by all network managers in the move to IPv6. The 6man WG can assume that ISATAP is equivalent to native IPv6, but some others may conclude otherwise.
> 
> I have posted elsewhere about my opinions on the lack of adequate control in ISATAP in the v6ops WG in reply to the draft http://tools.ietf.org/html/draft-templin-v6ops-isops-00 
> 
> To summarise: Because ISATAP is a host to gateway tunnel, it has no in-built way of controlling/ limiting additional network latency, nor of correctly applying DSCP QoS settings, nor can it be filtered by today's firewalls in a granular manner. So ISATAP is certainly not equivalent to native IPv6 in my mind. It also relies heavily on management of one particular DNS / WINS name space content (which may be dynamically updated as part of standard Windows AD operation), which IMHO is no way to control a network. One inquisitive/ incompetent server admin setting his Windows server name to "isatap" can change the behavior of 10000+ nodes on an international corporate network. That's not my definition of "managed." So my conclusion is that I have to switch ISATAP off, everywhere, until those shortcomings are addressed.
> 
> I'm not asking the 6man WG to "fix" the shortcomings of ISATAP, although that would be nice.
> 
> All I'm asking you guys to consider is whether your RFC3484 bis draft is complete if it cannot encode ALL combinations of preferences regarding which native network protocol or transition mechanism to prefer over another. The IETF does not control or mandate all deployment scenarios. Nor should it.
> 
> In particular I ask you to further examine supporting the use case: native IPv6 >> native IPv4 >> IPv6 over ISATAP over IPv4.
> 
> BTW just to say something very positive: the extension of RFC3484 bis to include ISATAP prioritization + DHCP(v6) distribution would likely be an extremely useful mechanism for controlling default end node behaviour in multinational companies (where AD may not be universally deployed). So keep up the good work in http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00
> 
> best regards,
> RayH
> 
> Arifumi Matsumoto wrote:
>> Ray,
>> 
>>> Appreciate your work on RFC3484 bis. I sent a comment regarding http://www.ietf.org/id/draft-ietf-6man-rfc3484-revise-02.txt
>>>  via the IETF web site, but I have a suspicion it black-holed.
>>> 
>>   E-mail: 
>> [email-masked]

---

From: Ray Hunter <[email-masked]>
Date: Tue, 10 May 2011 17:00:53 +0200

Thanks. You have answered my basic question in that it is possible to 
encode individual ISATAP subnet prefixes, and I accept that'll probably 
work for most people (together with the assumption that RFC1918 IPv4 + 
NAT is now "global.")

I'm just trying to explore the boundaries and assumptions here via use 
cases. If it isn't helpful to you, just let me know.

The only mechanism that I know of for selecting between the preference 
order for alternative encapsulations is RFC 3484 (and your proposed RFC 
3484 bis) or hard coding. All initiatives so far seem to make certain 
assumptions about the desirability of various preferences. (e.g. 
paraphrasing some history: IPv4 is going to be awful so prefer IPv6). We 
can discuss requirements and defaults, but I think a discussion on 
flexibility and being able to over ride the default might also be useful.

The reason that this has an impact on network managers, as I'm sure 
you're aware, is that although there is often a fall back mechanism to a 
different encapsulation method, this fall back takes a finite amount of 
time, which may or may not be an operational problem depending on a 
particular SLA. See e.g. happy eyeballs, although I can think of more 
extreme examples like control and trading systems where certain 
protocols require a different preference setting. So being able to 
tightly manage the selection preference order could be critical to some 
network managers.

I don't have a real "problem" with the current default for ISATAP. I 
find it unfortunate for my particular needs that I can think of today, 
that's all.

Different people have different requirements and SLA'a and transition 
paths. We are very early in the transition to IPv6 and I read all sorts 
of assumptions and debates on various blogs about the suitability of 
various preference schemes and protocols. In reality I'm not sure anyone 
knows the "correct" answer at this time, and certainly not the "single 
correct answer." The reality is that transition will probably be a 
process. RFC3484 was probably the "right thing to do" at the time, but I 
think we all agree it needs at least some updating. Once again thanks 
for taking the lead in this.

I certainly recognise that any one version of requirements may not be 
universal. In fact I acknowledge that the version I have presented is 
probably more driven by latency SLA's than most.

Some people may want a use case of native IPV6 >> native IPv4 >> tunnel 
protocols if they want to build networks with great IPv6 connectivity 
whilst keeping native IPv4 in production if they have certain SLA issues 
and requirements.

The opposite case may also be true for people who have great IPv4 
connectivity, but that their native IPv6 connectivity is somehow broken 
(I can think of a local CPE router which advertises IPv6, but the 
intermediate native IPv6 connectivity is broken due to a non-conformant 
device e.g. firewall) So people may actually prefer a tunnel over IPv4 
versus a native protocol.

That use case would be particular_tunnel_protocol >> native IPv4 >> 
native IPV6

Some people use RFC 1918 address on their local LANs. Others use PI IPv4 
space (Teredo makes an assumption that PI addresses space = Internet and 
RC1918 = private LAN. Again an assumption that is not always true.)

I can also think of other tunnel encapsulation technologies like IPv6 
IPSec over blah (Microsoft directAccess), IPv6 over GRE over blah, 6rd, 
IP-HTTPS .....

I now understand the workaround for my specific ISATAP case: to encode 
each ISATAP prefix individually in the prefix table. Thanks.

First follow up question on implementation detail: Do you think this 
solution will be sufficiently scalable for larger environments? e.g. If 
there were 200+ ISATAP routers. I'm not sure the prefix policy table 
would still work efficiently if it had to be scanned before every 
session start up. Maybe it would. I don't know. Do you have some 
operational experience on the limits? Or is this way out of scope of the WG?

I also recognize that requirements will probably change over time.

Second more generic follow up question: Your draft suggests that RFC 
1918 IPv4 addresses should now be considered global. I have read that 
some earlier implementations consider them local. There are arguments 
for both views.

So even if the ISATAP (global) IPv6 range was encoded with a lower 
priority than IPv4 in an old implementation, my understanding is that 
Rule 2 of source selection in RFC3484 would over ride that and prefer an 
IPv6 address. So the prefix table would effectively be ignored in this case.

RFC3484 bis clarifies (and "fixes") this by suggesting that RFC 1918 
address is global. That works for my use case today. But is this future 
proof?

I think that this assumes that RFC1918 addresses are also connected to 
the global IPv4 internet via NAT.

I realise that this again is probably a no-win case. Corporations who 
have implemented RFC 1918+ NAT probably can consider RFC1918 to be 
equivalent to global. But one day we may very well end up with islands 
of IPv4 connectivity in an IPv6 global Internet, with RFC1918 once again 
reverting to local scope.

Similarly there's a debate about whether to deprecate the 6to4 address 
range in 
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-02. 
(perhaps including a phase out plan so there might be no one universal 
set date for all network operators). One way of achieving that is 
reducing the preference. Another is hard coding 6to4 as "deprecated." A 
third would be to make detecting an address as deprecated a user 
configurable setting with a default (thus allowing the flexible roll out 
date).

In the ISATAP use case, I guess I was hoping for a single setting based 
on selecting preference by "encapsulation type=ISATAP" with address 
range = "don't care" that could be rolled out to all nodes, rather than 
adding multiple address prefix ranges. This may or may not be 
operationally practicable within the existing structure of RFC3484.

Are these examples adding up to an argument that the RFC 3484 bis 
mechanism needs some sort of extension to allow network managers 
themselves to make more of the changes via configuration, rather than 
via code? Considering that different groups will take different 
transition paths at different times?

I understand of course there is a balance to be struck somewhere, and 
not everything can be configuration.

I also don't want to derail your work (which as I am already on record 
as stating is very positive), but maybe you might like to consider a 
restructuring of the (notional) RFC3484 bis table(s) to include not only 
the prefix in the address selection table, but also to cover perhaps the 
other different address "types" identified in section 3 of RFC3484:

i) whether an address range is deprecated [rfc3484 rule 3 of destination 
selection]
ii) the encapsulation method that would be used with this address, 6to4, 
native, ISATAP, IPSec, blah [rfc3484 rule 7 destination address]
iii) the scope classification for a range as interface-local, 
link-local, admin-local, site-local, organization-local or global 
[RFC3484 rule 2 source address]
......
to make the selection rules more configurable, whilst keeping the rules 
themselves invariant.

One way of achieving this might be to specify that the prefix policy 
table may have an additional columns which is by default "don't care" 
and which could be expanded later to include the exceptions/ difficult 
cases. Or that the single prefix policy table is augmented by additional 
policy tables to cover the classification of the other address "types" 
e.g. a (notional) table that translates prefix range to scope.

Maybe this is just a completely new piece of work / RFC. Maybe these are 
such an off the wall cases that you decide that it isn't worth 
investigating further at this time. I leave that choice to you. But I do 
have a feeling that it could help future proof the implementations and 
give more granularity to individual network managers to implement 
RFC3484 bis table contents as they see fit, whilst still allowing the 
IETF WG to suggest useful defaults.

The bottom line I guess is whether you are convinced that all potential 
use cases for the coming X years are already covered.

Once again, thanks for your efforts.

regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Wed, 11 May 2011 09:10:52 +0200

> I do not see exactly what your problem is.
Ah. Maybe the light bulb has gone on at my end about a possible 
disconnect in requirements after having read RFC 5220 and RFC 5221 and 
the discussion thread from 2005 here 
http://www.ietf.org/mail-archive/web/ipv6/current/msg05566.html.

In these days of BYOD (bring your own device),  exploding numbers of 
mobile devices, embedded devices, and traveling users, I feel there is a 
need for a standardized non-proprietary way for a transport network 
manager to be able to signal to end nodes (that may not be under his 
direct administrative management) what is appropriate behavior when 
connected to this particular transport network.

The usage case I had thought about for RFC 3484 in one sentence was "to 
allow a transport network manager to provide hints to end nodes so that 
the end nodes could optimize the selection order of various network 
encapsulations when there were multiple choices available, in order to 
reduce the number of unsuccessful session establishment attempts which 
would lead to fall back to another encapsulation, thus reducing overall 
session establishment time, leading to happier users, and to be able to 
ensure compliance with an SLA e.g. by avoiding additional latency 
introduced by tunnels."

Does that explain the "problem" and help put my questions in context?

regards,
RayH