NAT slides?

For a class I'm teaching, I'd like to include some basic information 
about various NAT types. Rather than duplicate work, I wonder if 
somebody has suitable PPT slides (obviously to be used with credit...).

Thanks.

Henning

Re: NAT slides?

On Tuesday 13 September 2005 09:16 am, Henning Schulzrinne wrote:
> For a class I'm teaching, I'd like to include some basic information
> about various NAT types. Rather than duplicate work, I wonder if
> somebody has suitable PPT slides (obviously to be used with credit...).

Here are some slides I made a quite a while ago. It may be suitable. The
 files were created in Visio.

Jon

On Tuesday 13 September 2005 09:16 am, Henning Schulzrinne wrote:
> For a class I'm teaching, I'd like to include some basic information
> about various NAT types. Rather than duplicate work, I wonder if
> somebody has suitable PPT slides (obviously to be used with credit...).

Here are some slides I made a quite a while ago. It may be suitable. The
 files were created in Visio.

Jon

NAT slides?

For a class I'm teaching, I'd like to include some basic information 
about various NAT types. Rather than duplicate work, I wonder if 
somebody has suitable PPT slides (obviously to be used with credit...).

Thanks.

Henning

I-D ACTION:draft-ietf-behave-nat-udp-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title		: NAT Behavioral Requirements for Unicast UDP
	Author(s)	: F. Audet, C. Jennings
	Filename	: draft-ietf-behave-nat-udp-04.txt
	Pages		: 28
	Date		: 2005-9-14
	
This document defines basic terminology for describing different
   types of NAT behavior when handling Unicast UDP and also defines a
   set of requirements that would allow many applications, such as
   multimedia communications or on-line gaming, to work consistently.
   Developing NATs that meet this set of requirements will greatly
   increase the likelihood that these applications will function
   properly.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-behave-nat-udp-04.txt".

FW: I-D ACTION:draft-ietf-behave-nat-udp-04.txt

Hi all, I want to draw everybody's attention to
draft-ietf-behave-nat-udp-04.

It includes all the changes resulting from WGLC and the Paris meeting.

Many thanks to Bryan Ford, Cullen Jennings and Dan Wing who
helped in finalizing the wording.

The changes are:
- Removal of section 5.2   
- Addition of section 4.4 (including new  REQ-7)   
- Modification to now-REQ-14   
- Adjusted the wording on the ALG requirement 
- Correction of typos and spelling mistakes
- Updated list of references.

> -----Original Message-----
> From: i-d-announce-bounces <at> ietf.org 
> [mailto:i-d-announce-bounces <at> ietf.org] On Behalf Of 
> Internet-Drafts <at> ietf.org
> Sent: Wednesday, September 14, 2005 12:50
> To: i-d-announce <at> ietf.org
> Cc: ietf-behave <at> list.sipfoundry.org
> Subject: I-D ACTION:draft-ietf-behave-nat-udp-04.txt 
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories. This draft is a work item of the 
> Behavior Engineering for Hindrance Avoidance Working Group of 
> the IETF.

Re: NAT slides?

On 9/13/05 6:16 AM, "Henning Schulzrinne" <hgs <at> cs.columbia.edu> wrote:

> For a class I'm teaching, I'd like to include some basic information
> about various NAT types. Rather than duplicate work, I wonder if
> somebody has suitable PPT slides (obviously to be used with credit...).
> 
> Thanks.
> 
> Henning
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave <at> list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

I put some slides at

http://www.dial911anddie.com/papers/Telcom04-NAT-v3.pdf
and 
http://www.dial911anddie.com/papers/Telcom04-NAT-v3.ppt

They are old but still seem 95% correct

About that TCP draft ....

We seem to have closed up the UDP stuff and I was hoping to solve some of
the issues around the TCP work. Trolling through old email traffic, I formed
a list of issues that have been discussed. We may have already come to
closure on many of these. I probably missed many. My take of the conclusions
may be all wrong, but ...

When there is not an open mapping, what is the response to an SYN? I think
we agreed not to send a RST. There has been discussion on sending an ICMP
error of some sort.

When there is an open mapping, what to do with incoming packets such at SYN,
SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them.

Should the NAT track TCP sequence numbers and timestamps and be able to
remap them when a stream is manipulated. I believe we came to the conclusion
that NATs should not be required to do this. Clearly a NAT running a
specific ALG on a protocol inside a TCP stream might have to do that but
that is about NATing some protocol that uses TCP non NATing a generic TCP
stream. 

There was discussion of if the NAT should initiate keep alives. I don't
think we got to consensus on this but it seemed at last IETF that most
people where not in favor of this.

There was discussion of timer values - one of the comments I got that made a
lot of sense was that we should logical derive these based on the
recommendations in the TCP RFCs.

Anyways, I am sure these are not all the issues and I may have summarized

FW: Approval to Post Version -00 Internet-Drafts for the 64th IETF Meeting in Vancouver, British Columbia, Canada

If anyone is expecting new 00 WG drafts before Vancouver, please let Jiri
and I know. 

------ Forwarded Message
From: Internet-Drafts Administrator <internet-drafts <at> ietf.org>
Date: Fri, 16 Sep 2005 00:00:01 -0400
Subject: Approval to Post Version -00 Internet-Drafts for the 64th IETF
Meeting in Vancouver, British Columbia, Canada

Dear IETF Working Group Chairs:

In order to expedite the processing of the many version -00 I-Ds that
the Secretariat receives before an IETF meeting, we ask that you
please notify the Secretariat prior to the initial submission cutoff
date of all version -00 I-Ds that you expect to approve for posting as
WG documents.  Please send the filenames of your approved -00 I-Ds to
internet-drafts <at> ietf.org.  We would appreciate receiving your list of
approved drafts five (5) business days prior to the cutoff date for -00
submissions, or by Monday, October 10th at 9:00 AM ET for the 64th IETF
Meeting.  Please include the word "Approved I-Ds" in the "Subject"
field.  This procedure will help to ensure that version -00 I-Ds are
posted in a timely manner, allowing more time for review by the public.

Thank you for your cooperation in this matter.

The Internet-Drafts Administrator

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 64th IETF Meeting can be found at

Re: NAT slides?

Well, I donot have any slides on this. However, I looked at Cullen's slides and
the slides from Jon Ringle (earlier posting in response to the same query).
Both sets of slides are nicely done. However, both sets of slides refer to
Symmetric NAT, Port-restricted Cone NAT, Address-Restricted Cone NAT and Full
Cone NATs only. These are variations of NAPT, but leave out other NAT types.

I figured, I should mention that there are other NAT types in addition to those
listed above. Here they are - Basic NAT, Twice NAT, Bi-directional NAT, V4/V6
NAT-PT and Load Share NAT. Hairpin NAT is a new NAT type introduced to cover
the multi-level NAT realities. Cullen's slides cover this new NAT type. Below
is an ASCII art to illustrate the distinction amongst these NAT types. Hope
this helps.

-------------+---------+---------+---------+---------+---------+----------
NAT Type     | Address | Port    | Bindings| UDP NAT | TCP NAT | Session
             | Binding | Binding | per NAT | Sessions| Sessions| Direction
             |         |         | Session |         |         | 
-------------+---------+---------+---------+---------+---------+----------
Basic NAT    | Yes,    | No      | 1       | Yes     | Yes     |Outbound
             | Outbound|         |         |         |         |        
-------------+---------+---------+---------+---------+---------+----------
Twice NAT    | Yes,    | Yes,    | 2       | Yes     | Yes     |Outbound
             | Outbound| Outbound|         |         |         |
-------------+---------+---------+---------+---------+---------+----------
Bidirectional| Yes,    | Yes,    | 1       | Yes     | Yes     |Outbound,
NAT          | Bi-direc| Bi-direc|         |         |         |Inbound
             | tional  | tional  |         |         |         |
-------------+---------+---------+---------+---------+---------+----------
Load Share   | Yes,    | Yes,    | 1       | Yes     | Yes     |Inbound
NAT          | Inbound | Inbound |         |         |         |

Re: About that TCP draft ....

--- Cullen Jennings <fluffy <at> cisco.com> wrote:

> 
> We seem to have closed up the UDP stuff and I was hoping to solve some of
> the issues around the TCP work. Trolling through old email traffic, I formed
> a list of issues that have been discussed. We may have already come to
> closure on many of these. I probably missed many. My take of the conclusions
> may be all wrong, but ...
> 
> When there is not an open mapping, what is the response to an SYN? I think
> we agreed not to send a RST. There has been discussion on sending an ICMP
> error of some sort.

[suresh] My recollection is to simply drop. 

> 
> When there is an open mapping, what to do with incoming packets such at SYN,
> SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them.
> 

[suresh] Cullen - By "open mapping", if you are refering to an open TCP NAT
Session, I agree with what you say. However, if "open mapping" refers to an
open Binding, permitting or not permitting the SYN packet depends on the
directionality of the Binding on the NAT.

cheers,
suresh