Re: IPv4 Outage Planned for IETF 71 Plenary

[Philip Matthews <philip_matthews at magma.ca>]

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 at mit.edu]
> > Sent: Wednesday, December 19, 2007 12:19 PM
> > To: alh-ietf at tndh.net
> > Cc: 'IETF Chair'; ietf at ietf.org; iaoc at ietf.org; 'John C Klensin';
> > dcrocker at bbiw.net; 'Pete Resnick'; iesg at ietf.org
> > Subject: Re: IPv4 Outage Planned for IETF 71 Plenary
> >
> > > > > > > "Tony" == Tony Hain <alh-ietf at tndh.net> 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


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