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