headers
Internet-Drafts | 11 Apr 2006 00:50
Picon
Favicon

I-D ACTION:draft-ietf-behave-nat-udp-05.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-05.txt
	Pages		: 28
	Date		: 2006-4-10
	
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-05.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-05.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 20 Apr 2006 01:14
Picon
Favicon

Minutes from Dallas

Minutes, BEHAVE WG at IETF 65

Minutes edited by Dan Wing based on notes by Spencer Dawkins 
Meeting chaired by Dan Wing

Thursday, March 23, 2006, 13:00-15:00
-------------------------------------

Topic:  Agenda and Chair Update (Chairs, 15 min)

  It was announced that Jiri Kuthan was stepping down as chair, and
  Dan Wing is the new co-chair (with Cullen Jennings).  The new ADs,
  Magnus Westerlund and Lars Eggert, were introduced.  The agenda was
  accepted as-is.

-----

Topic: TCP Issues (Saikat Guha, 30 min)
draft-ietf-behave-tcp-00

  Saikat presented the draft.  This is a revision of hoffman-03 draft,
  including comments from last meeting and the mailing list.  This draft
  is now a WG item.

  The TCP draft describes NAT behavior to allow simultaneous open so
  that two hosts behind their own NATs can establish a TCP connection.

  Open issues:

  * Req-3, "MUST support inbounc SYN/3-way from specific endpoints
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 20 Apr 2006 01:16
Picon
Favicon

-behave-nat-udp-05: PROTO questionnaire and write-up

draft-ietf-behave-nat-udp has been submitted to the IESG for their review.

Per the procedures described in draft-ietf-proto-wgchair-doc-shepherding-06,
a copy of the PROTO questionnaire and write-up are below.  

You can track the progress of draft-ietf-behave-nat-udp at:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1268
2&rfc_flag=0

-Dan Wing

-----

PROTO questionnaire for:  draft-ietf-behave-nat-udp-05.txt
prepared by:  Dan Wing, dwing <at> cisco.com, 14-Apr-2005

WG chair shepherd: dwing <at> cisco.com

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

Yes.

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 20 Apr 2006 01:16
Picon
Favicon

-behave-multicast and draft-ietf-magma-igmp-proxy

During WGLC, it was brought to the chairs attention that
draft-ietf-behave-multicast-01 and  draft-ietf-magma-igmp-proxy-06 had
significant overlap.  In Dallas I presented a quick summary of the problem,
which is captured in the BEHAVE minutes (below my signature).

Consensus at the meeting was to reduce the scope of behave-multicast to only
reference -magma-igmp-proxy and to point out the special issues around NATs.
Please let me know if you disagree with this change of scope.  

We will also need a new author to volunteer to make these changes.

-Dan Wing

-----

    Topic: Multicast Draft (Dan Wing, 10 min)
    draft-ietf-behave-multicast-01 
    draft-ietf-magma-igmp-proxy-06

    Magma draft has already passed IESG review.  Will drop the
    behave draft and  let it expire.  Cullen - looks close, but
    if we give MAGMA draft to NAT vendors they will  be confused.
    Make behave draft just point to MAGMA draft, point-by-point?
    Francois - how would anyone else figure this out in the first
    place.  Is  there an existing document where we can include
    the pointer?

    Philip pointed out that the MAGMA draft is in RFC
    Editor queue and we can't squeeze in a change of this
    size in AUTH-48.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 20 Apr 2006 11:00
Picon
Favicon

AD evalution comments on draft-ietf-behave-nat-udp-05

Hi,

My AD evaluation resulted in the below comments and questions. I do wish 
to have some discussion on some of these topics.

1. Section 4.1: "In particular, in
       the context of SIP, if my application supports the extensions
       defined in RFC 3605 [16] for indicating RTP and RTCP addresses and
       ports separately, but the other peer does not, there may still be
       breakage in the form of the stream losing RTP packets.  This
       requirement will avoid the loss of RTP in this context, although
       the loss of RTCP may be inevitable in this particular example."

Can you please clarify to me why the RTP packets would be lost in this 
case if the pooling is arbitrary?

2. Section 4.2.1, page 9, fourth paragraph:

"For example it will fail if two internal endpoints try to reach the
    same external destination, e.g., a server used by both endpoints such
    as a SIP proxy, or a web server, etc."

I think a web server is a confusing example. I agree that the general 
problem exist, but as a web server would be using TCP this confuses the 
matter in this UDP only document.

3. Section 4.2.1, page 9, fifth paragraph:

"It should be noted that port 0 is reserved and must not be used."
(Continue reading)

Permalink | Reply | 5 comments |
headers
Cullen Jennings | 20 Apr 2006 12:38
Picon
Favicon
Gravatar

Re: AD evalution comments on draft-ietf-behave-nat-udp-05


Hi Magnus - thanks for the careful review. Some comments inline...

PS -  Magnus knows this but just to be clear for others, I am only
commenting on this as an individual contributor. I will Recuse myself from
IESG voting on this and all chair actions to do with this are only dealt
with by Dan (or Jiri in the past).

On 4/19/06 11:00 PM, "Magnus Westerlund" <magnus.westerlund <at> ericsson.com>
wrote:

> Hi,
> 
> My AD evaluation resulted in the below comments and questions. I do wish
> to have some discussion on some of these topics.
> 
> 1. Section 4.1: "In particular, in
>        the context of SIP, if my application supports the extensions
>        defined in RFC 3605 [16] for indicating RTP and RTCP addresses and
>        ports separately, but the other peer does not, there may still be
>        breakage in the form of the stream losing RTP packets.  This
>        requirement will avoid the loss of RTP in this context, although
>        the loss of RTCP may be inevitable in this particular example."
> 
> Can you please clarify to me why the RTP packets would be lost in this
> case if the pooling is arbitrary?

I suspect we have a typo here and "losing RTP packets" should be " losing
RTCP packets". The RTCP is lost when it the RTCP port can not be signaled
and the n+1 rule is broken by the NAT using ports that are not n and n+1.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Magnus Westerlund | 20 Apr 2006 16:24
Picon
Favicon

Re: AD evalution comments on draft-ietf-behave-nat-udp-05

Hi,

See inline comments.

Cullen Jennings wrote:
>> 1. Section 4.1: "In particular, in
>>        the context of SIP, if my application supports the extensions
>>        defined in RFC 3605 [16] for indicating RTP and RTCP addresses and
>>        ports separately, but the other peer does not, there may still be
>>        breakage in the form of the stream losing RTP packets.  This
>>        requirement will avoid the loss of RTP in this context, although
>>        the loss of RTCP may be inevitable in this particular example."
>>
>> Can you please clarify to me why the RTP packets would be lost in this
>> case if the pooling is arbitrary?
> 
> I suspect we have a typo here and "losing RTP packets" should be " losing
> RTCP packets". The RTCP is lost when it the RTCP port can not be signaled
> and the n+1 rule is broken by the NAT using ports that are not n and n+1.
> 

Makes much more sense.

[snipped 2]

>> 3. Section 4.2.1, page 9, fifth paragraph:
>>
>> "It should be noted that port 0 is reserved and must not be used."
>>
>> I think there are a number of ports that would be confusing to use as
(Continue reading)

Permalink | Reply | 3 comments |
headers
Francois Audet | 20 Apr 2006 18:29
Favicon

RE: AD evalution comments on draft-ietf-behave-nat-udp-05

Thanks Magnus and Cullen.

I'll make all the changes where we have resolution.

Here are the remaining issues from the list.

> >> 3. Section 4.2.1, page 9, fifth paragraph:
> >>
> >> "It should be noted that port 0 is reserved and must not be used."
> >>
> >> I think there are a number of ports that would be 
> confusing to use as 
> >> source ports. One especially would be port 9 (discard). Thus two 
> >> questions to the WG. Should it be pointed out that there 
> are several 
> >> ports that are not suitable as source ports, and secondly should 
> >> these be enumerated?
> 
> No comments on this issue?

My recommendation would be to delete the sentence "It should be noted
that port 0 is reserved and must not be used". I don't think it is
useful
to start ennumerating all the ports that shouldn't be used.

> >> 5. Section 4.3: REQ-5:
> >>    "A NAT UDP mapping timer MUST NOT expire in less than 1 minute,
> >>        unless REQ-5a applies.
> >>        a) A NAT MAY have UDP mapping timers that have much shorter
> >>           timers, but only for specific ports in the
(Continue reading)

Permalink | Reply | 503 comments |
headers
Dan Wing | 20 Apr 2006 18:57
Picon
Favicon

RE: AD evalution comments on draft-ietf-behave-nat-udp-05

> > >> 9. Section 10.2, REQ-14:
> > >>
> > >> I don't see how this requirement is connected to the section
> > >> text?  Also it is not clear if there is anything more than what
> > >> is described in section 9 and 10.1 that needs to be supported.
> > >> I think some clarification and text changes in regards to this
> > >> is needed.
> > >
> > > I might be missing what you are saying here but .... are you
> > > thinking changing
> > >
> > > REQ-14: A NAT MUST support fragmentation of packets larger than
> > > link MTU.
> > >
> > > To something more like
> > >
> > > REQ-14: A NAT MUST support fragmentation of packets larger than
> > > link  MTU by sending an ICMP for any packet larger than the
> > > MTU when DF=1 and in the case where DF=0, either break the
> > > packet into fragments smaller than the MTU or send an ICMP
> > > error.
> > >
> > > Clearly this text would need to be changed to make sense but
> > > just wanted to make sure I was understanding the scope of the
> > > change here.
> > >
> >
> > What I don't understand is what is different in Req-13 and Req-14.
> > To me REQ-13 applies independently if the packet is going from the
> > internal to the external or vice versa.
(Continue reading)

Permalink | Reply | 502 comments |
headers
Pyda Srisuresh | 24 Apr 2006 05:13
Picon
Favicon

Req-5 (Was:: Re: RE: AD evalution comments on draft-ietf-behave-nat-udp-05)


--- Francois Audet <audet <at> nortel.com> wrote:
...
> > >> 5. Section 4.3: REQ-5:
> > >>    "A NAT UDP mapping timer MUST NOT expire in less than 1 minute,
> > >>        unless REQ-5a applies.
> > >>        a) A NAT MAY have UDP mapping timers that have much shorter
> > >>           timers, but only for specific ports in the 
> > well-known port
> > >>           range (i.e., ports 0-1023) where the IANA- 
> > registered protocol
> > >>           is strictly a request/response protocol, such as 
> > for example
> > >>           DNS over UDP/53.
> > >>        b) The value of the NAT UDP mapping timer MAY be 
> > configurable.
> > >>        c) A default value of 5 minutes for the NAT UDP 
> > mapping timer is
> > >>           RECOMMENDED."
> 
> We have been trying to balance our requirement for timer values between
> what makes sense for "residential-grade" NATs versus large Enterprise
> NATs (who happens to be Firewall at the same time).
> 
> The larger timers make sense for the residential-grade NATs. Req 5-c is
> useful for residential-grade NATs, because often, the manufacturers are
> very amiable to a recommended default.
> 
> What we have found however is that the Enterprise NAT vendors where
> quite
(Continue reading)

Permalink | Reply | 48 comments |

Gmane