Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel

From: "Francois Audet" <[email-masked]>
Date: Mon, 11 Jul 2005 09:41:07 -0700 (PDT)

Can you propose some text? Perhaps for section 1, or whatever section
you
feel is appropriate.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> David Barrett
> Sent: Sunday, July 10, 2005 23:42
> To: 'Behave'
> Subject: Re: [Ietf-behave] Determining the precise behavior 
> of a given NATmodel
> 
> 
> Francois Audet wrote:
> > I don't see anything at this point that is not sufficiently 
> clear for 
> > NAT vendors in the udp draft.
> > 
> > If there is anything SPECIFIC that is not clear, let me know.
> 
> I agree, the BEHAVE draft defines a specific lexicon.  
> However, having 
> the language is only half the problem.  Compelling NAT 
> vendors to use it 
> in a standardized fashion is the other half.
> 
> For example, it wouldn't be enough for scientists to merely define a 
> language for nutrition.  Rather, it takes the FDA to mandate 
> that labels 
> must *use* the language in a standardized form in order for 
> consumers to 
> benefit from it.
> 
> In our case, I'd like the IETF to recommend that NAT vendors 
> label their 
> products in a consistent fashion, using the BEHAVE 
> terminology.  BEHAVE 
> defines the language; let's go the extra step and recommend that NAT 
> vendors actually use it, so consumers can benefit from it.
> 
> -david
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: David Barrett <[email-masked]>
Date: Mon, 11 Jul 2005 17:57:20 -0700 (PDT)

Francois Audet wrote:
Can you propose some text? Perhaps for section 1, or whatever section
you feel is appropriate.
I'd be happy to try.  Reviewing the UDP draft [1] I'd propose including 
the following text:

[1] ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt

----

12. Standard Disclosure

To help consumers compare and choose between competing NAT products, for 
each NAT variation there SHOULD be made available a standard disclosure 
of the NAT's behavior in the following form:

    Address and port mapping behavior:
        "endpoint independent" |
        "address dependent" |
        "address and port dependent"
    IP address pooling behavior:
        "unsupported" |
        "arbitrary" |
        "paired"
    Port preservation:
        "yes" |
        "no" |
        "overloading"
    Port-range preservation:
        "none" |
        "registered" |
        "dynamic" |
        "registered and dynamic"
    Port-parity preservation:
        "yes" |
        "no"
    Port-contiguity preservation:
        "yes" |
        "no"
    Mapping refresh timer:
        <seconds> |
        "configurable"
    Mapping outbound refresh:
        "yes" |
        "no"
    Mapping inbound refresh:
        "yes" |
        "no"
    Unsolicited packet filtering:
        "endpoint independent" |
        "address dependent" |
        "address and port dependent"
    Filter refresh timer:
        <seconds> |
        "configurable"
    Filter outbound refresh:
        "yes" |
        "no"
    Filter inbound refresh:
        "yes" |
        "no"
    Hairpining behavior:
        "none" |
        "external source address and port" |
        "internal source address and port"
    Fixed application level gateways:
        <DNS, FTP, etc.> |
        "none"
    Configurable application level gateways:
        <DNS, FTP, etc.> |
        "none"
    Mapping and filtering determinism:
        "deterministic" |
        "non-deterministic"
    Supports ICMP destination unreachable:
        "yes" |
        "no"
    Supports fragmentation:
        "yes" |
        "no"
    Fragment receive ordering:
        "ordered" |
        "out of order" |
        "none"
    Maximum transmission unit (MTU):
        <bytes> |
        "configurable"
For example, the product datasheet for a given NAT device might include 
the following complete description of its NAT behavior:

    Address and port mapping behavior:       endpoint independent
    IP address pooling behavior:             paired
    Port preservation:                       yes
    Port-range preservation:                 registered and dynamic
    Port-parity preservation:                yes
    Port-contiguity preservation:            yes
    Mapping refresh timer:                   configurable
    Mapping outbound refresh:                yes
    Mapping inbound refresh:                 yes
    Unsolicited packet filtering:            endpoint independent
    Filter refresh timer:                    configurable
    Filter outbound refresh:                 yes
    Filter inbound refresh:                  yes
    Hairpining behavior:                     external source address 
and port
    Fixed application level gateways:        DNS, FTP
    Configurable application level gateways: none
    Mapping and filtering determinism:       deterministic
    Supports ICMP destination unreachable:   yes
    Supports fragmentation:                  yes
    Fragment receive ordering:               out of order
    Maximum transmission unit (MTU):         configurable

REQ-14: The product literature and documentation for a NAT SHOULD
   include a standard description of its behavior in the form detailed
   by this document.
----

Questions:
1) Are they called "external ports and addresses" or "public ports and 
addresses"?  I'm using "external".
2) Should we use "yes/no" or "true/false"?  I'm using "yes/no".
3) Where should this be put?  I'm recommending a new section after all 
the definitions, but before the requirements.
4) How strongly should it be required?  I'm proposing "SHOULD".

Naturally as the terminology in the draft changes, this section would 
need to be updated.  However, I believe it provides a concise way to 
completely define a NAT's behavior, and thus enable the consumer to make 
an informed choice between competing choices.

-david