Re: Clarification required

Rajiv Raghunarayan <[email protected]> Mon, 02 Dec 2002 12:42:06 +0530
Newsgroups gmane.ietf.nat
Organization Cisco Systems Inc.
Message-ID <[email protected]>
Hi Sam,

One comment inline..

"Sam K. Sankoorikal" wrote:
> 
> Hi Rajiv,
> 
>         Thanks for the elabourate mail. Everything is very clearly
> explained. However, your mail fails to give reason for why the OID
> natConfAddrMapEntryType has to remain read-create. I have pointed out
> reasons why it can be changed to read-only and yet give out the relevant
> information to the user. Infact, in the natConfAddrMapTable every other
> attribute  needs to be read-create, but how do we specify the
> natConfAddrMapEntryType in the case of dynamic? Please give me an
> example for such a possibility.

I'm not sure if this is cause for confusion, but just in case..
The natConfAddrMapEntryType reflects that static/dynamic nature
of entries in the natAddr*Bind tables, and *not* the nature of
entries in the natConfAddrMapTable. 

-Rajiv.

> 
>         Please be kind enough to let me know reasons for why it has to
> remain a read-create OID. In my view: if it remains a read-create OID
> then the user is forced to set a value while creating the row, which
> will have to be rejected at the agent end, if it is specified as dynamic
> [NAT or NAPT] mapping.
> 
> Thanks and Regards,
> Sam.
> 
> Rajiv Raghunarayan wrote:
> 
> >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:
> >>
> >>"  -  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 ,
> >>        Wipro Technologies
> >>        Ganapa Complex,
> >>        #53/1 Hosur Rd Madivala,
> >>        Bangalore, India 560068
> >>        PBX:     +91 80 5502001 extn 3114
> >>        [email protected]
> >>
> >>                           Name: Wipro_Disclaimer.txt
> >>   Wipro_Disclaimer.txt    Type: Plain Text (text/plain)
> >>                       Encoding: 7bit
> >>
> >
> 
> _______________________________________________
> nat mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nat