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 protected]
TEL +81-422-59-3334 FAX +81-422-59-6364
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
