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
- To: alh-ietf at tndh.net
- Subject: Re: IPv4 Outage Planned for IETF 71 Plenary
- From: Eric Rescorla <ekr at networkresonance.com>
- Date: Wed, 19 Dec 2007 13:30:10 -0800
- Cc: ietf at ietf.org, iaoc at ietf.org, 'John C Klensin' <john-ietf at jck.com>, 'IETF Chair' <chair at ietf.org>, dcrocker at bbiw.net, 'Pete Resnick' <presnick at qualcomm.com>, 'Sam Hartman' <hartmans-ietf at mit.edu>, iesg at ietf.org
- In-reply-to: <083301c84284$c835e270$58a1a750$@net>
- List-help: <mailto:ietf-request@ietf.org?subject=help>
- List-id: IETF-Discussion <ietf.ietf.org>
- List-post: <mailto:ietf@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
- References: <E1J3IFS-0002yV-CG@ietf.org> <200712142154.lBELs1ne090300@drugs.dv.isc.org> <200712181644.lBIGisBx090029@romeo.rtfm.com> <476800BC.5030504@dcrocker.net> <38033976C354EAB237181075@[192.168.101.1]> <p06250103c38dc78214d8@[74.134.5.163]> <080c01c84276$ec9a79e0$c5cf6da0$@net> <tsl8x3qphdd.fsf@mit.edu> <2788466ED3E31C418E9ACC5C31661557084FAF@mou1wnexmb09.vcorp.ad.vrsn.com> <083301c84284$c835e270$58a1a750$@net>
- User-agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
At Wed, 19 Dec 2007 13:19:03 -0800,
Tony Hain wrote:
>
> 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.
Tony,
I'm trying to understand on what evidence you're basing this
assertion. Remember that the IETF hole punching techniques only
implicitly modify the configuration of the NAT, relying on the
ordinary NAT state management mechanisms.
I would encourage you to read
draft-sipping-stucker-media-path-middleboxes-00.txt, which
describes the sorts of enforcement mechanisms that 3G style
providers are starting to deploy, which indeed do incorporate
hole punching mechanisms for the media traffic.
-Ekr
_______________________________________________
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.