Subject: [Ietf-behave] draft-macdonald-behave-nat-behavior-discovery-00

From: [email-masked]
Date: Sun, 15 Oct 2006 22:38:13 -0500 (CDT) (envelope-from [email-masked])

Bruce and I submitted the NAT discovery draft discussed last IETF.  Until in 
shows up in the repository you can find it at:

https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-behave-nat-behavior-discovery-00.txt

and

https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-behave-nat-behavior-discovery-00.html

-Derek

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 6 Nov 2006 18:11:16 -0600 (CST) (envelope-from [email-masked])

Hi

here are some comments on draft-macdonald-behave-nat-behavior-discovery-00

> 1.  Applicability
>
>    reliability is not as strong a requirment, applications can use this
                                    ^^^^^^^^^^

typo, should be "requirement"

> 3.3.  Binding Lifetime Discovery
>
>    Binding lifetime can be discovered by performing timed tests that use
>    XOR-RESPONSE-ADDRESS.  The client uses a second port and the STUN
     ^^^^^^^^^^^^^^^^^^^^

should be RESPONSE-ADDRESS ?

> 3.4.  Diagnosing NAT Hairpinning
>
>    determine its mapped address.  The client then sends a STUN Binding
>    Request to this mapped address from a different port.  If the client
                                           ^^^^^^^^^^^^^^

is it enough to send from a different port? what if a packet is sent from
a different host on the same LAN?

according to Section 6. "Hairpinning Behavior" of 
draft-ietf-behave-nat-udp-08.txt
there are two different hosts behind the same NAT...

> 4.3.  Determining NAT Filtering Behavior
>
>    In test II, the client sends a binding request to the primary address
>    of the server with the CHANGE-REQUEST attribute set to change-port
>    and change-IP.  This will cause the server to send its response from
>    its alternate IP address and alternate port.  If the client receives
>    a response the current behaviour of the NAT is Address Independent
>    Filtering.                                     ^^^^^^^^^^^^^^^^^^^
>

I think this should be "Endpoint Independent" filtering

> 7.  New Attributes
>
>    0x0x0002: RESPONSE-ADDRESS
>    0x0003: CHANGE-REQUEST
>    0x0004: SOURCE-ADDRESS
>    0x0005: OTHER-ADDRESS
>    0x000b: REFLECTED-FROM
>    0x0023: XOR-REFLECTED-FROM

extra 0x in "0x0x0002".

the attribute  "0x8024: PADDING" is mentioned in Section 9 but not here.

also this value is in conflict with "0x8024: REFRESH-INTERVAL" which is
defined in draft-ietf-behave-rfc3489bis-05

> 7.1.  RESPONSE-ADDRESS
> 7.3.  SOURCE-ADDRESS
> 7.4.  OTHER-ADDRESS

the packet format of these attributes are omitted, I guess the description
should include the text:

    "Its syntax is identical to the MAPPED-ADDRESS attribute."

/alfred

derek@xxxxxxxxxxxxxxx wrote:

and

-Derek

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 7 Nov 2006 14:30:22 -0600 (CST) (envelope-from [email-masked])

Alfred,

Thanks for the comments.  We'll try to fix them in the next version.

                                            ^^^^^^^^^^^^^^

I think sending it from a different port is sufficient, since it's
mostly a matter of whether the NAT is capable of realizing it needs to
route it back to the private network.  Actually, if a NAT applies
filtering to hairpinning packets, it might be necessary to send
packets in both directions to complete this check.  Practically
speaking, the best you can typically do is use a different port.   I
think we can put text in suggesting the use of a different
host/private IP address to send the probes from, but that's not an
option for most clients.

Bruce