Subject: Re: [BEHAVE] NAT Control STUN Usage

From: Philip Matthews <[email-masked]>
Date: Wed, 14 Mar 2007 17:37:43 -0400

Sorry to be coming into this conversation late.
I am just catching up on various mailing lists after finishing my  
drafts.

BEHAVE is chartered to work on STUN.
STUN requires STUN servers to work, and defined how they behave.
Why shouldn't we recommend placing some of the servers into NATs
as this draft does?

This draft is trying to address the problem of finding the allocated  
mappings
for nested NAT cases. I think this problem is an important one to solve,
because nested NATs are becoming more and more common.

I think BEHAVE is a good place to work on a solution to this problem,
and I think the proposed solution is reasonable.

I think it would be silly to NOT solve this problem just because of
charter issues.

- Philip

On 27-Feb-07, at 16:59 , David Barrett wrote:

> I agree this would be great.  I just think it's not what BEHAVE is  
> doing.
>
> BEHAVE is (largely) just specifying what the default configuration  
> should be
> for NATs as they come "out of the box".  This is much different than
> mandating all NAT vendors build in support for a new control  
> interface.
>
> Despite my massive reservations with UPnP, that seems like a much more
> appropriate place to add control functionality (because it already  
> has it),
> rather than reinventing an incompatible subset of UPnP under a  
> different
> name.
>
> -david
>
>> -----Original Message-----
>> From: Eric Cooper [mailto:[email-masked]]
>> Sent: Tuesday, February 27, 2007 12:04 PM
>> To: Dan Wing; 'Lars Eggert'
>> Cc: [email-masked]
>> Subject: Re: [BEHAVE] NAT Control STUN Usage
>>
>> I think there's a lot of value in this draft simply because it allows
>> discovery of multiple levels of NATs.
>>
>> I'm specifically interested in knowing the 'public' IP addresses  
>> and keep-
>> alive times associated with each NAT.  I think that could be  
>> accomplished
>> without attempting to control the keep-alive times in the NATs.
>>
>> So, it might be possible to skirt charter issues by limiting this  
>> draft to
>> 'discovery' functions and not including 'control' functions.
>>
>> Best Regards,
>>
>> Eric.
>>
>> ----- Original Message -----
>> From: "Dan Wing" <[email-masked]>
>> To: "'Lars Eggert'" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Wednesday, February 21, 2007 5:00 PM
>> Subject: RE: [BEHAVE] NAT Control STUN Usage
>>
>>
>>>> On 2007-1-12, at 20:09, ext Dan Wing wrote:
>>>>> At the San Diego meeting there were positive comments around this
>>>>> approach.
>>>>> Is there interest in moving this work forward?
>>>>
>>>> this document takes STUN in a whole new direction (middlebox
>>>> control) that would probably require a recharter.
>>>
>>> I asked Magnus that question offline, and he concurs it doesn't
>>> fit within BEHAVE's existing charter.
>>>
>>>>>    Also, the draft says:
>>>>>    Unlike some other
>>>>>    techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour
>>>>>    [Bonjour]),
>>>>>    STUN does not interact directly with the NAT.  Because
>>>>>    STUN doesn't
>>>>>    interact directly with the NAT, STUN cannot request additional
>>>>>    services from the NAT such as longer lifetimes (which
>>>>>    would reduce keepalive messages).
>>>>>
>>>>>    This paper describes a mechanism for the STUN client to  
>>>>> interact
>>>>>    directly with the NAT and request additional services,
>>>>>    by using the
>>>>>    STUN protocol itself.
>>>>
>>>> For a convincing rechartering argument, it'd be very useful to  
>>>> see a
>>>> discussion on why adding this to STUN is significantly better than
>>>> the myriad of exiting approaches to control middleboxes. In  
>>>> addition
>>>> to the ones mentioned in the draft, at least NSIS and SIMCO
>>>> also exist.
>>>
>>> -01 added a little more information showing advantages of the NAT
>>> Control STUN Usage.  We can add a point-by-point comparison of this
>>> approach versus NSIS, SIMCO (an implementation of MIDCOM), UPnP,
>>> and Bonjour, and ask the community again if there seems to be
>>> sufficient merit to this approach versus the other protocols for
>>> NAT traversal and NAT control.
>>>
>>> -d
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/behave
>>>
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Mar 2007 09:44:56 +0100

Philip Matthews skrev:
> I am just catching up on various mailing lists after finishing my drafts.
> 

The problem is that large parts of this problem already has been solved 
in the numerous NAT control protocols. Even in IETF we have two 
different WG currently chartered with solving NAT control issues, MIDCOM 
and NSIS. Going in this new direction for BEHAVE needs IETF wide 
consensus and also good arguments why previous efforts are not solving 
the problem. So if you are interested in this issue, please get together 
and start discussing having a BOF.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------