Subject: [BEHAVE] A few minor comments on draft-ietf-behave-nat-behavior-discovery-03

From: Philip Matthews <[email-masked]>
Date: Mon, 14 Apr 2008 16:14:20 -0400

I know this comes after WGLC, but here are a few minor comments on  
this draft. Note that I haven't finished reading the document, but I  
am sending these out now in case they are helpful.

- Philip

* The wording of this draft seems to imply that it is an experimental  
extension to draft-ietf-behave-rfc3489bis (and not, for example, RFC  
3489). Perhaps it would be good to make a definite statement about  
this in the introduction section?

* From the draft:
4.2.  Determining NAT Mapping Behavior

    This will require at most three tests.  In test I, the client
    performs the UDP connectivity test.  The server will return its
    alternate address and port in OTHER-ADDRESS in the binding response.
    If OTHER-ADDRESS is not returned, the server does not support this
    usage and this test cannot be run.  The client examines the XOR-
    MAPPED-ADDRESS attribute.  If this address and port are the same as
    the local IP address and port of the socket used to send the  
request,
    the client knows that it is not NATed and the effective mapping will
    be Endpoint-Independent.

What about the case of cascaded NATs where the address gets reused in  
a different addressing domain? This will give the wrong result.

This failure seems different than some other failures in that it is  
not the NAT that is "faking out" the test, but rather a consequence of  
the network topology.

* Is section 4 normative or informative?

* From the draft:
      the server. Therefore, a client MUST be prepared for receiving a  
420
s/for receiving/to receive/

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave