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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
> Markus Isomaki ([EMAIL PROTECTED])
>
>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@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
