Subject: Re: [NAT] Clarification required

From: "Sam K. Sankoorikal" <[email-masked]>
Date: Sat, 30 Nov 2002 16:42:04 +0530

Hi Rajiv,

??? ??? Good Day!

??? ??? I have gone through section 4.3 of the NAT-MIB . I quote the 
section:

"  -  Setting  the natConfStatus to 'active'(1) will enable
      nat on the interface. Note that the associated entries in the
      natConfAddrMapTable and natConfProtTable (if any) must also
      be made active.

   -  The Address Bind and Address-Port Table will have the entries 
      created due to this nat configuration. A Management Station may
      also, if deemed necessary, create entries Address Bind or a 
      Address-Port Bind entry and link those entries to the appropriate
      address map configured. "

The above section does not tell us the values to be set in case you 
needed to create an entry in the natConfAddrMapTable. ie what value 
would I have to set natConfAddrMapEntryType to go on and create an entry

NatConfAddrMapEntry ::= SEQUENCE {
    natConfAddrMapName             SnmpAdminString,
    natConfAddrMapIndex            Integer32,
    natConfAddrMapEntryType        INTEGER,
    natConfAddrMapDirection        INTEGER,
    natConfLocalAddrType           InetAddressType,
    natConfLocalAddrFrom           InetAddress,
    natConfLocalAddrTo             InetAddress,
    natConfLocalPortFrom           Integer32,
    natConfLocalPortTo             Integer32,
    natConfGlobalAddrType          InetAddressType,
    natConfGlobalAddrFrom          InetAddress,
    natConfGlobalAddrTo            InetAddress,
    natConfGlobalPortFrom          Integer32,
    natConfGlobalPortTo            Integer32,
    natConfProtocol                BITS,
    natConfAddrMapStorageType      StorageType,
    natConfAddrMapStatus           RowStatus
}

natConfAddrMapEntryType OBJECT-TYPE
    SYNTAX  INTEGER {
                static (1),
                dynamic (2)
            }
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "This config parameter can be used to set up static 
             or dynamic address maps."
    ::= { natConfAddrMapEntry 3 }

I also quote Rohits' input:

Static Address assignment

?? In the case of static address assignment, there is one-to-one address
?? mapping for hosts between a private network address and an external
?? network address for the lifetime of NAT operation.? Static address
?? assignment ensures that NAT does not have to administer address
?? management with session flows.

Dynamic Address assignment

?? In this case, external addresses are assigned to private network
?? hosts or vice versa, dynamically based on usage requirements and
?? session flow determined heuristically by NAT. When the last session
?? using an address binding is terminated, NAT would free the binding so
?? that the global address could be recycled for later use. The exact
?? nature of address assignment is specific to individual NAT
?? imp
lementations.?

(The functionality has been described. More could be added on how we would configure the same)

Based on the above definition of dynamic NAT it seems that the 
NatConfAddrMapEntry 's? which are dynamic are created on the fly, on a 
need basis by the NAT module/protocol and can't be exactly specified as 
dynamic and created by a user through SNMP. However if we wanted to 
configure a Static NAT entry then that configuration could be created by 
the user by specifying other [Direction, Addresses, Ports, protocols] 
OID value other than the natConfAddrMapEntryType. This value will be 
derived. Hence I think it would be clearer if the 
natConfAddrMapEntryType were given a max access of read-only. This is 
something which cannot be specified by the user. To tell more about the 
dynamic entries I think by enabling NAT on an interface and running a 
network application using NAT, then dynamic NAT entries would be 
created. The same could be repeated for NAPT.

natConfAddrMapEntryType OBJECT-TYPE
    SYNTAX  INTEGER {
                static (1),
                dynamic (2)
            }
    MAX-ACCESS  *read-only*

Thanks and Regards,
Sam.

-- 
? Sam K. Sankoorikal.
??Home Net Solutions <http://www.wipro.com/homenet> ,
? Wipro Technologies <http://www.wipro.com>
? Ganapa Complex,
? #53/1 Hosur Rd Madivala,
? Bangalore, India 560068
? PBX:???? +91 80 5502001 extn 3114
? [email-masked]

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sat, 30 Nov 2002 18:01:19 +0530

Hi Sam,

A typical NAT config and usage would be as follows:

1. Define the translations/address maps. E.g. local address: 
   10.0.0.0/24, global address: 64.0.0.0/24 (ports may also be 
   involved, but I've ignored it for simplicity).

   This is done by the network administrator, based on the
   addresses available/in use and the network configuration.
   At this stage, depending on various factors (e.g. ratio of
   internal hosts v/s available external addresses, future
   expansion, accessibility necessary for hosts/servers etc.),
   the network administrator also decides whether the mapping
   must be static or dynamic, what type of NAT (basic, napt) 
   needs to be used etc.

2. Depending on the mapping type i.e. static/dynamic (and, of
   course, implementation) BINDs are created in the BIND table 
   either immediately or when the traffic flows from/to the 
   addresses defined in the address map. 

   The BINDs created are based off the address maps defined
   earlier. E.g. 10.0.0.1 => 64.0.0.1, 10.0.0.2 => 64.0.0.2.

   In case of static address maps, the BINDs are defined and
   fixed at the time of the address map definition i.e. the
   number of local address will be equal to the no. of 
   external addresses and these will have one-to-one mapping
   as defined above (again ignoring ports for simplicity).

   In case of dynamic address maps, the BINDs are defined
   only when the traffic flows. The number of local address 
   needn't be (and usually aren't) same as the no. external
   addresses. This is, therefore, a dynamic mapping.

From a MIB perspective, the natConfAddrMapTable represents
the translation/address mapping definition (step #1 above).
The entries in this table may be created via SNMP, or any
other means (CLI, HTTP etc.). The actual BINDs (as created 
in step #2 above) are represented by the natAddrBind and 
natAddrPortBind tables in the MIB.

-Rajiv.

> "Sam K. Sankoorikal" wrote:
> 
> Hi Rajiv,
> 
>         Good Day!
> 
>         I have gone through section 4.3 of the NAT-MIB . I quote the
> section:
> 
>    In the case of static address assignment, there is one-to-one
> address
>    mapping for hosts between a private network address and an external
>    network address for the lifetime of NAT operation.  Static address
>    assignment ensures that NAT does not have to administer address
>    management with session flows.
>    In this case, external addresses are assigned to private network
>    hosts or vice versa, dynamically based on usage requirements and
>    session flow determined heuristically by NAT. When the last session
>    using an address binding is terminated, NAT would free the binding
> so
>    that the global address could be recycled for later use. The exact
>    nature of address assignment is specific to individual NAT
>    imp
> lementations.
> NatConfAddrMapEntry 's  which are dynamic are created on the fly, on a
> need basis by the NAT module/protocol and can't be exactly specified
> as dynamic and created by a user through SNMP. However if we wanted to
> configure a Static NAT entry then that configuration could be created
> by the user by specifying other [Direction, Addresses, Ports,
> protocols] OID value other than the natConfAddrMapEntryType. This
> value will be derived. Hence I think it would be clearer if the
> something which cannot be specified by the user. To tell more about
> the dynamic entries I think by enabling NAT on an interface and
> running a network application using NAT, then dynamic NAT entries
> would be created. The same could be repeated for NAPT.
> 
>     MAX-ACCESS  read-only
>  [ ]    Sam K. Sankoorikal.
>         Home Net Solutions ,
>         Wipro Technologies
>         Ganapa Complex,
>         #53/1 Hosur Rd Madivala,
>         Bangalore, India 560068
>         PBX:     +91 80 5502001 extn 3114
>         [email-masked]
> 
>                            Name: Wipro_Disclaimer.txt
>    Wipro_Disclaimer.txt    Type: Plain Text (text/plain)
>                        Encoding: 7bit
_______________________________________________
nat mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nat

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sat, 30 Nov 2002 18:01:19 +0530

Hi Sam,

-Rajiv.