There is no special signaling to BEHAVE-compliant NATs.
Instead, the client behind the NAT sends a packet to some device on
the public side of the NAT, and this causes the NAT to create state.
This is the way all NATs work today.
Though there are not a lot of NATs today that are 100% BEHAVE
compliant, for each BEHAVE recommendation, there are commercial NATs
that follow that recommendation. So the BEHAVE specifications are
really just a collection of the best current practices of NAT vendors.
Furthermore the STUN, TURN, and ICE protocols do not require any
support at all from the intervening NATs, and are in fact designed to
work with existing NATs, including those that are currently being
used by ISPs to NAT their entire network.
- Philip
On 19-Dec-07, at 16:10 , Tony Hain wrote:
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf