At 1:59 PM +0000 11/16/07, Colin Perkins wrote: >The following BoF has been proposed for the Vancouver IETF. There is a mailing list <safe@xxxxxxxx> for discussion. > >Colin This seems to be scheduled against both the Applications area open meeting and a RAI group focused on media servers. Both groups would have an interest in following this work and discussing where future IETF work in this area will happen. Is there still a possibility of adjusting this timing? I understand, of course, that not every conflict can be resolved, but it would be useful to know whether this is still something that might be addressed. regards, Ted Hardie > > > >SAFE - Self-Address Fixing Evolution BoF >---------------------------------------- > >Chairs: > Colin Perkins (csp@xxxxxxxxxxxxx) > Markus Isomaki (Markus.Isomaki@xxxxxxxxx) > >Mailing list: > https://www1.ietf.org/mailman/listinfo/safe > >Various NAT hole-punching techniques such as IPsec NAT traversal, Teredo, and STUN/ICE send periodic UDP keep-alive messages to keep their NAT binding alive. > >However, a drawback of these techniques is their chattiness which is a result of the host application not knowing the NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or because the application is unable to extend the lifetime of the NAT's binding (Teredo). The endpoint has to send periodic packets which consume power on battery powered devices, consume network bandwidth, and place an unnecessary load on servers. > >There are two approaches to resolve the problem of chattiness. The first is to interact directly with the NAT using a NAT control protocol. Several of these protocols exist which unfortunately have different drawbacks: > > * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT > and the endpoint have to support the same protocol > * nested NATs are not possible with UPnP IGD or NAT-PMP > * topology awareness is required of MIDCOM > * security must be established between the controlling entity and > the NAT for MIDCOM and NSIS-NSLP > * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to be > the default gateway; neither work well on routed networks > >The second approach is to empirically test the NAT's binding lifetime, as done by Teredo. This can optimise the keep-alive traffic based on the NAT's binding lifetime, but cannot extend the duration of the binding lifetime. Also, empirical testing does not always give reliable results due to varying behaviour of NAT and firewall implementations. > >This BoF is intended to discuss a newly-proposed technique for using STUN to discover, query and control firewalls and NATs, that can eliminate UDP >keep-alive traffic. The BoF will review the problem space and existing work, and decide if there is a need for new work in the area, and if the IETF is an appropriate home for that work. The intent is not to form a new working group at this time, but to gauge interest in work in this area, and consider an appropriate future home for that work. > > >Agenda: > Introduction ...................................... (Chairs, 10) > Problem statement and scope ......................... (Wing, 15) > Survey of existing work ........................... (Barnes, 30) > draft-eggert-middlebox-control-survey-01.txt > NAT/Firewall control with STUN ...................... (Wing, 15) > draft-wing-behave-nat-control-stun-usage-05.txt > Discussion ................................................ (20) > Future directions ................................. (Chairs, 30) > > >-- >version: 1.5, 16-Nov-2007 > > >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf