Subject: Re: (NAT) Request to advance NAT drafts to Informational RFCs

From: [email-masked] (Pyda Srisuresh)
Date: Fri, 27 Nov 1998 08:49:01 -0800 (PST)

> Pyda,
<... snip>

> 
> Also you don't have a draft whose title corresponds to the
> "limitations and problems" milestone. If that is the "protocol
> issues" draft, the title is rather weak for a health warning.
> The applicability statement is not there at all, is it?
> 

Yes, "protocol issues" draft refers to the "limitations and problems"
milestone.

As for the Applicability statement, please refer the draft titled
"Implications of NATs on the TCP/IP architecture" by Yakov Rekhter
(draft-ietf-nat-arch-implications-00.txt).

> I understand the problems of getting all this work done; my own
> WG has its problems too, but I'm very concerned about getting
> a balanced document set out in this very contentious area.
> 
> Regards
> 
>     Brian
> 

Regards,
suresh
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Tony Hain <[email-masked]>
Date: Sun, 29 Nov 1998 23:23:36 -0800

Daniel,

As noted by the title, your draft is written from the perspective of
developing new applications. It notes there are problems with existing
applications, but the reader supporting existing apps is left to infer what
to look for from the discussion of NAT friendly design.

Section 3.3 assumes a single NAT in the path, therefore the private address
is unreachable. If more than one is in the path, it is possible the address
will answer as a different system than intended. For HTTP this could be a
minor annoyance, but for some applications private data could end up
transferred to the wrong system.

Section 3.4 does not discuss the NAPT case, and how to deal with multiple X
servers attempting to share port 6000. This is a general problem and affects
things like multiplayer games which expect to use a well known port on
multiple systems.

Section 3.5 assumes that applications only use TCP or UDP, but there are ~90
protocol identifiers for IP. Where do applications which use any of those
get discussed?

Section 3.6 is misleading as it focuses on the mapping table setup overhead
and plays down the per packet computations. The setup overhead in the NAT is
a similar order of magnitude as the setup at the originating system, and
minimizing the number of setups applies there as well. The special
characteristic NAT brings to the flow is that the header is rewritten on
each packet. This section also assumes the application is HTTP like, as
opposed to something like video/audio/application-sharing which may each
require different connection characteristics but simultaneously share the
resources of the NAT. 

Section 3.8 is misleading since it claims that NAT is functionally a router.
From a network operator perspective this may be true, but from the
application it is more. The application can not determine the globally
unique name or address of the system from behind a NAT. There are schemes to
accomplish this but they require advanced knowledge that a NAT is in the
path. Also the specific issues with Multicast should be listed. 

There is no discussion of the impact of NAT on a generic flow as additional
latency. Unfortunately many custom applications are latency sensitive so
this should be pointed out.

================================================================
Tony Hain			[email-masked]
<mailto:[email-masked]> 

		-----Original Message-----
		From:	Daniel Senie [mailto:[email-masked]]
		Sent:	Sunday, November 29, 1998 9:24 PM
		To:	Tony Hain
		Cc:	[email-masked]
		Subject:	Re: (NAT) Request to advance NAT drafts to
Informational RFCs

		Tony Hain wrote:
		> 
		> Matt Holdrege wrote:
		> 
		>                 If we describe in plain technical words
what NAT does to a
		> protocol or
		>                 application, then the reader can clearly
see for him or
		> herself what is
		>                 going on.
		> 
		> You assume the reader will understand the details of layer
interactions.
		> Many application developers write to an API and expect an
effortless
		> unobstructed transmission of bits to the remote end.
Someone has to connect
		> the dots and state how specific applications are broken by
NAT, and similar
		> functions that interfere with the end to end path. Simply
listing technical
		> issues may not catch their attention.

		Tony,

		Are you making these comments in reference to the drafts
which have been
		suggested for publishing now, or in relation to
		draft-ietf-nat-app-guide-00.txt? If the latter, I'd like to
hear your
		comments on how I can expand this draft to improve clarity.

		The point of the app-guide draft is to specifically tell
application
		developers what they need to know about NAT.

		-- 
	
-----------------------------------------------------------------
		Daniel Senie
[email-masked]
		Amaranth Networks Inc.
http://www.amaranthnetworks.com
		-
		To unsubscribe, email [email-masked]' with
		'unsubscribe nat' in the body of the message.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.