headers
Paul Francis | 2 Feb 2003 22:50

stun implementations?

I'm looking for STUN client and server implementations that I can use for a
class project.  They don't need to be the latest spec (i.e. don't need
security), and they don't need to interoperate with anything but each other.

Any suggestions?

Thanks,

PF
Permalink | Reply | 0 comments |
headers
Harrington, David | 3 Feb 2003 22:37
Favicon

NAT MIB

Here is my first review of the NAT MIB (draft-ietf-nat-natmib-05.txt):

section 4.3
"Likewise, the session entries are derived from the Binds and 
   an entry MUST not exist in the Session table without a 
   corresponding Bind table entry."

What is the behavior expected when a Bind table entry is deleted, and session entry exists? MUST the session
entry be deleted as well, or MUST the Bind entry NOT be deleted while there is a reference to it?

section 5
"Following is the list of protocol specific information, identified at
this point, which could potentially require protocol specific
extensions to this mib:

o Each protocol could support its set of timers and/or other protocol
  specific configuration parameters for operation with NAT.
o Statistics could be maintained per protocol, and type of
  statistics could be protocol specific.
"

To ensure that extensions play by the same rules, these should probably be turned into SHOULDs. It will not
help interoperability if extension X1 provides timers and counters, while X2 supports only timers, and
X3 supports only counters, and so on. The purpose of IETF documents is to define standards - what is the
*standard* to be followed when implementing extensions to this mib? When is it appropriate to add timers?
When is it appropriate to add counters?

The MIB:
General comments:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harrington, David | 3 Feb 2003 22:41
Favicon

RE: It's that time - wg agenda

Hi Melinda,

As we work to design a solution to meet the semantic requirements, I think we are likely to find some issues
with the existing document. I suggest it would be better to wait until we have gotten further along on the
design team work before going to WG last call on the semantic requirements.

dbh

> -----Original Message-----
> From: Melinda Shore [mailto:mshore <at> cisco.com]
> Sent: Friday, January 31, 2003 1:13 PM
> To: midcom <at> ietf.org
> Subject: [midcom] It's that time - wg agenda
> 
> 
> It's time to start thinking about the agenda for the March
> meeting in San Francisco.  I've once again requested a one
> hour slot.  The two items we know about, aside from
> administrivia, are 1) the semantics document - any
> outstanding issues before going to WG last call, and 2) mibs
> update.  Is there anything else?
> 
> Thanks,
> 
> Melinda
> _______________________________________________
> midcom mailing list
> midcom <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rohit Rohit | 13 Feb 2003 20:19

FW: [NAT] NAT MIB

Hi, 

I am forwarding the response for the David's Comments to the MIDCOM group
for further comments.
We definitely need feedback on whether the NAT MIB just need to support
TCP, UDP and ICMP protocols; or we need to add the provision for the protocol
extensibility. IMHO, adding protocol extensibility makes MIB more complex
and we gain very little from this.

Thanks
Rohit

-----Original Message-----
From: Rohit Rohit 
Sent: Thursday, February 06, 2003 7:04 PM
To: 'Harrington, David'; nat <at> ietf.org
Subject: RE: [NAT] NAT MIB

Hi David, 

  Thanks for your comments. 
  My comments are inline.
  Please look for [ROHIT].

-----Original Message-----
From: Harrington, David [mailto:dbh <at> enterasys.com]
Sent: Monday, February 03, 2003 2:04 PM
To: nat <at> ietf.org
Subject: [NAT] NAT MIB
(Continue reading)

Permalink | Reply | 9 comments |
headers
Martin Stiemerling | 14 Feb 2003 09:21
Picon

Re: FW: [NAT] NAT MIB

Hi,

the protocols TCP, UDP and ICMP are fine. How about IP itself? The 
semantics talk about TCP, UDP and IP and don't talk about ICMP. So 
TCP,UDP and IP would be fine to have.

Martin

Rohit Rohit wrote:
> Hi, 
> 
> I am forwarding the response for the David's Comments to the MIDCOM group
> for further comments.
> We definitely need feedback on whether the NAT MIB just need to support
> TCP, UDP and ICMP protocols; or we need to add the provision for the protocol
> extensibility. IMHO, adding protocol extensibility makes MIB more complex
> and we gain very little from this.
> 
> 
> Thanks
> Rohit
> 
> -----Original Message-----
> From: Rohit Rohit 
> Sent: Thursday, February 06, 2003 7:04 PM
> To: 'Harrington, David'; nat <at> ietf.org
> Subject: RE: [NAT] NAT MIB
> 
> 
> Hi David,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christopher A. Martin | 14 Feb 2003 16:21
Favicon

RE: FW: [NAT] NAT MIB

Also IPSec ESP/AH (These are part of IP, just want to make sure it is
considered if necessary).

-----Original Message-----
From: midcom-admin <at> ietf.org [mailto:midcom-admin <at> ietf.org] On Behalf Of
Martin Stiemerling
Sent: Friday, February 14, 2003 2:21 AM
To: Rohit Rohit
Cc: midcom <at> ietf.org; srisuresh <at> yahoo.com; wang cliff; Rajiv
Raghunarayan; Nalinaksh Pai
Subject: Re: [midcom] FW: [NAT] NAT MIB

Hi,

the protocols TCP, UDP and ICMP are fine. How about IP itself? The 
semantics talk about TCP, UDP and IP and don't talk about ICMP. So 
TCP,UDP and IP would be fine to have.

Martin

Rohit Rohit wrote:
> Hi,
> 
> I am forwarding the response for the David's Comments to the MIDCOM 
> group for further comments. We definitely need feedback on whether the

> NAT MIB just need to support TCP, UDP and ICMP protocols; or we need 
> to add the provision for the protocol extensibility. IMHO, adding 
> protocol extensibility makes MIB more complex and we gain very little 
> from this.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Taylor | 14 Feb 2003 20:02

Re: FW: [NAT] NAT MIB

Could I put a word in for SCTP on that list of protocols?

Rohit Rohit wrote:
> Hi, 
> 
> I am forwarding the response for the David's Comments to the MIDCOM group
> for further comments.
> We definitely need feedback on whether the NAT MIB just need to support
> TCP, UDP and ICMP protocols; or we need to add the provision for the protocol
> extensibility. IMHO, adding protocol extensibility makes MIB more complex
> and we gain very little from this.
> 
[snip]
Permalink | Reply | 4 comments |
headers
Pyda Srisuresh | 15 Feb 2003 19:08
Picon
Favicon

RE: FW: [NAT] NAT MIB

Hi Martin,

Please see my comments in-line.

regards,
suresh

> -----Original Message-----
> From: Martin Stiemerling [mailto:Martin.Stiemerling <at> ccrle.nec.de]
> Sent: Friday, February 14, 2003 12:21 AM
> To: Rohit Rohit
> Cc: midcom <at> ietf.org; srisuresh <at> yahoo.com; wang cliff; Rajiv
> Raghunarayan; Nalinaksh Pai
> Subject: Re: [midcom] FW: [NAT] NAT MIB
>
>
> Hi,
>
> the protocols TCP, UDP and ICMP are fine. How about IP itself? The

I assume, you are refering to Basic-NAT.
The description for the fields natConfLocalPortFrom, natConfLocalPortTo,
natConfGlobalPortFrom, and natConfGlobalPortTo
do state that they should be 0 for Basic-NAT address mapping.

> semantics talk about TCP, UDP and IP and don't talk about ICMP. So

You are right. We did not state the interpretation of
these fields for ICMP packets. We will include the text for ICMP
(as described in RFC 3022) in the next rev.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pyda Srisuresh | 15 Feb 2003 20:03
Picon
Favicon

RE: FW: [NAT] NAT MIB

Hi Christopher,

The NAT-MIB draft is intended for use with just TCP, UDP and ICMP 
protocols (in the context of NAPT). NAPT behaviour for these 
protocols is documented in RFC 3022.

Having said that, natConfProtocol is BITS type. Any protocol 
exensions and the corresponding MIB extensions for these 
protocols should be reviewed independently in seperate docs.
IMHO, making protocol extensions to NAT in the NAT-MIB is a 
slippery slope.

cheers,
suresh

> -----Original Message-----
> From: Christopher A. Martin [mailto:christopher.a.martin <at> wcom.com]
> Sent: Friday, February 14, 2003 7:22 AM
> To: 'Martin Stiemerling'; 'Rohit Rohit'
> Cc: midcom <at> ietf.org; srisuresh <at> yahoo.com; 'wang cliff'; 'Rajiv
> Raghunarayan'; 'Nalinaksh Pai'
> Subject: RE: [midcom] FW: [NAT] NAT MIB
> 
> 
> Also IPSec ESP/AH (These are part of IP, just want to make sure it is
> considered if necessary).
> 
> -----Original Message-----
> From: midcom-admin <at> ietf.org [mailto:midcom-admin <at> ietf.org] On Behalf Of
> Martin Stiemerling
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pyda Srisuresh | 15 Feb 2003 20:22
Picon
Favicon

RE: FW: [NAT] NAT MIB

Hi Tom,

How is NAPT expected to function with SCTP (say, as different 
from TCP)? As I mentioned earlier (in reponse to Christopher),
I believe, protocol extensions (outside of TCP, UDP and ICMP)
should be considered independently in an extensions document.

cheers,
suresh

> -----Original Message-----
> From: midcom-admin <at> ietf.org [mailto:midcom-admin <at> ietf.org]On Behalf Of
> Tom Taylor
> Sent: Friday, February 14, 2003 11:03 AM
> To: Rohit Rohit
> Cc: srisuresh <at> yahoo.com; wang cliff; Rajiv Raghunarayan; Nalinaksh Pai;
> midcom <at> ietf.org
> Subject: Re: [midcom] FW: [NAT] NAT MIB
> 
> 
> Could I put a word in for SCTP on that list of protocols?
> 
> Rohit Rohit wrote:
> > Hi, 
> > 
> > I am forwarding the response for the David's Comments to the 
> MIDCOM group
> > for further comments.
> > We definitely need feedback on whether the NAT MIB just need to support
> > TCP, UDP and ICMP protocols; or we need to add the provision
(Continue reading)

Permalink | Reply | 2 comments |

Gmane