RE: IPv4 Outage Planned for IETF 71 Plenary

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: RE: IPv4 Outage Planned for IETF 71 Plenary

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@xxxxxxxx]
Sent: Wed 19/12/2007 4:10 PM
To: 'Sam Hartman'
Cc: ietf@xxxxxxxx; iaoc@xxxxxxxx; 'Pete Resnick'; 'IETF Chair'; dcrocker@xxxxxxxx; 'John C Klensin'; iesg@xxxxxxxx
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@xxxxxxx]
> Sent: Wednesday, December 19, 2007 12:19 PM
> To: alh-ietf@xxxxxxxx
> Cc: 'IETF Chair'; ietf@xxxxxxxx; iaoc@xxxxxxxx; 'John C Klensin';
> dcrocker@xxxxxxxx; 'Pete Resnick'; iesg@xxxxxxxx
> Subject: Re: IPv4 Outage Planned for IETF 71 Plenary
>
> >>>>> "Tony" == Tony Hain <alh-ietf@xxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf