Tony Hain wrote: > Sam, > > While I understand the virtue in behave-compatible nats, how realistic is it > to believe that any service provider is going to allow a consumer to > directly signal their infrastructure? This assumption was the failing of > RSVP as an endpoint qos tool. > > (Here's the problem with taking one result, and attempting to apply it to another problem space: RSVP was necessarily an in-band protocol, and tied intrinsically to the local provider's network.) There is *nothing* in IPv6->IPv4 that is *strictly* tied to the provider of IPv6 services. It may be the case that ISPs try to "scare" their customers into believing otherwise, but that is not a technical issue. So, while the "third party" problem is a concern where the third party has a de-facto monopoly, the counter-argument under the IPv6 access model exists. If you can get anywhere on the IPv6 Internet, you can get to *any* third-party IPv6->IPv4 gateway, limited only by the ability to reach & interest of the third party, e.g. someone offering it as a service. Since IPv6 access is no-NAT to/from the IPv6 DFZ, unlike much of IPv4, there is a level playing field for network-facing services, such as IPv6->IPv4 access, and IPv6-oriented ALGs. Mail relaying, for instance, via MX-IPv4 to SMTP-IPv6. The rest of your argument falls off the rails, as soon as the "third party" changes from "_the_" third party, to "_a_" third party. In an IPv6 world, ISPs can once again be differentiated to include ISPs-lite, Internet Access Providers. I'd suggest that for the experiment planned for IETF-71, that interested folks set up *competing* IPv6->IPv4 services, kind of like a mock marketplace, and including mock advertising on a special (IPv6-only) web site for just this purpose. Then the results would have multiple dimensions, comparative results much like an actual ba*k o*f. Brian Dickson > There is lots of noise about ISPs just putting up massive nat farms to push > their customers out, but when it comes right down to it there is no way that > will work for anything but the most trivial client apps. All of the > assumptions about nat working today are built around local control of the > mappings. When that mapping function has to move to a third party, all bets > are off. Worse, when that third party has strong disincentives which keep > them from allowing their customers to punch holes, there is no chance that > apps will work. ISPs are disincented by even the simple issue of > after-the-fact diagnostics being more complicated by dynamic mappings, let > alone the problem of conflict resolution between customers. > > Behave compatible nats are a nice concept for enterprises with multiple > levels of internal nat, but third-party trust issues will kill any real > deployment of a signaling based approach. > > Tony > >
begin:vcard fn:Brian Dickson n:Dickson;Brian org:Afilias Canada adr:;;;Toronto;;;Canada email;internet:briand@xxxxxxxxxxxxxxx title:Internet Operations Specialist tel;work:+1 416 673 4121 url:www.afilias.info version:2.1 end:vcard
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf