Re: IPv4 Outage Planned for IETF 71 Plenary

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

briand.vcf
Description: Vcard

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf