RE: IPv4 Outage Planned for IETF 71 Plenary
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPv4 Outage Planned for IETF 71 Plenary



Title: RE: IPv4 Outage Planned for IETF 71 Plenary
There is a difference between 'taking the operators position' and deciding which battles to fight.
 
The battle to fight here is to maintain the ability to exchange peer-to-peer audio and video conferencing streams. That is a battle that I beleive can be won given the right marketting approach.
 


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

Hallam-Baker, Phillip wrote:
> The double NAT approach is much closer to what the actual
> transition is going to look like. The only difference is that
> I think we might just be able to work out a viable means of
> punching holes so that video-conferencing works if we actually
> set our minds to it.

Since you are the one that is routinely taking the operator's position, why
should we allow punching holes in the IETF nat when that will never happen
in a real ISP? No ISP is going to trust their customer base to modify the
configuration of their infrastructure, so whatever the IETF experiment ends
up being has to mimic that reality.

The only exception I would make is to route the audio streams around the nat
so people that can't attend are not completely cut off. Other than that, if
you are there you are living the future. IPv6 plus multiple layers of
IPv4-nat, with trust boundary issues included.

Tony




_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.