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.
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.
What's to say that the audio streams can't be carried over v6? The
encoders weren't streaming over v6 this last time but the icecast server
that was employed for 69 and 70 has a AAAA record and the application is
listening on all 3 of it's v6 addresses...
Some people actually used v6 to retrieve the stream probably without
knowing they were and I didn't hear screaming except when I broke them
on Tuesday.
Tony
_______________________________________________
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