ietf
[Top] [All Lists]

RE: IPv4 Outage Planned for IETF 71 Plenary

2007-12-19 14:58:11
Some points:
 
1) Winning a battle with the ISPs is hard but it is much easier to persuade the 
consumer that when they buy a NAT box they should get one that BEHAVEs, if we 
win the battle at the WiFi/Cable router stage we can push out the requirement 
as an expectation for ISP deployed NAT farms.
 
2) Branding is the key. Consider the case that the following Internet service 
levels are defined:
 
Internet 2: Restricted
 
Internet 2: Basic
 
Internet 2: Advanced
 
Even before I state what the requirements for the levels are it is pretty clear 
that an ISP that offers only Restricted service is at a sales disadvantage to 
an ISP that offers Basic. 
 
 
The Mappings I would propose are:
 
Restricted - IPv4 service only through dumb NAT with no means of accepting 
inbound service connections. 
 
Basic - A full /96 IPv6 subnet or better plus legacy IPv4 service, either a 
publlic IPv4 address or through an intelligent NAT with punchthrough.
 
Advanced - Same as Basic but a /88 plus a static IPv4 address and the ability 
to accept unrestricted inbound services.
 
 
The point of defining restricted is not to promote its use but to deprecate 
that level of service. Most users would opt for the Basic level of service in 
preference to advanced which is also what we want as we want to graceously 
manage the depletion of the IPv4 pool.
 
 
That is my bottom line, the problem in my view is not how we manage the IPv6 
transition, its how we manage the depletion of the IPv4 pool in a manner that 
achieves the end result that benefits everyone. Deployment of IPv6 is a 
consequence, not the stakeholder's actual objective.
 

________________________________

From: Tony Hain [mailto:alh-ietf(_at_)tndh(_dot_)net]
Sent: Wed 19/12/2007 4:10 PM
To: 'Sam Hartman'
Cc: ietf(_at_)ietf(_dot_)org; iaoc(_at_)ietf(_dot_)org; 'Pete Resnick'; 'IETF 
Chair'; dcrocker(_at_)bbiw(_dot_)net; 'John C Klensin'; iesg(_at_)ietf(_dot_)org
Subject: RE: IPv4 Outage Planned for IETF 71 Plenary



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.

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

-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
Sent: Wednesday, December 19, 2007 12:19 PM
To: alh-ietf(_at_)tndh(_dot_)net
Cc: 'IETF Chair'; ietf(_at_)ietf(_dot_)org; iaoc(_at_)ietf(_dot_)org; 'John C 
Klensin';
dcrocker(_at_)bbiw(_dot_)net; 'Pete Resnick'; iesg(_at_)ietf(_dot_)org
Subject: Re: IPv4 Outage Planned for IETF 71 Plenary

"Tony" == Tony Hain <alh-ietf(_at_)tndh(_dot_)net> writes:

    Tony> the right experiment. It is not right because it does
    Tony> nothing positive, other than the threat -maybe- spurring
    Tony> some action. A more realistic experiment would be to run the
    Tony> entire week with a double-nat for IPv4 (and nats between the
    Tony> access points to simulate consumer-to-consumer
    Tony> configurations), where the most public one has absolutely no
    Tony> provision for punching holes (because realistically an ISP
    Tony> is not going to punch inbound holes for its customers, or
    Tony> allow them to).

I strongly support this experiment and believe it would be a really
good idea to run.  I do think behave-compatible nats should be used,
but besides that, I think the experiment you propose is far more
valuable than the v6-only experiment.


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


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