RE: [NAT] Re: the future of the NAT working group

["Ed Van Horne" <[e-mail]>]

Rajiv,

I have raised another issue concerning how the tables are indexed. As
currently designed, one can only look up a binding using the local
addresses/ports. Is there a plan to provide tables indexed by the outside
addresses/ports? My previous comments are included in-line.

Ed Van Horne
Building Broadband Solutions Unit - San Diego
Cisco Systems
6195 Lusk Blvd
San Diego, CA 92121
858.526.1152

<Comments follow>

We have application where we want to map the inside global address and port
of a computer connected to the inside interface of a NAT router to that
computer's MAC address. We see this as a two step process, with two
variations, depending on whether NAT or NAPT is involved:

NAT:

Step 1: IG (A)   ->
natAddrBindTable.natAddrBindEntry.natAddrBindLocalAddr -> IL (A)
Step 2: IL (A)   ->
ipNetToMediaTable.natAddrBindLocalAddr.natAddrBindLocalAddr -> MAC address

NAPT:

Step 1: IG (A,P) ->
natAddrPortBindTable.natAddrPortBindEntry.natAddrPortBindLocalAddr -> IL (A)
Step 2: IL (A)   ->
ipNetToMediaTable.natAddrBindLocalAddr.natAddrBindLocalAddr -> MAC address

Step 2 works fine because ipNetToMediaTable is indexed by {
ipNetToMediaIfIndex, ipNetToMediaNetAddress }, where I assume that
ipNetToMediaNetAddress == IL (A) and ipNetToMediaIfIndex is the IfIndex of
the NAT router's inside interface. This means that a single SNMP query
obtains the computer MAC address, once we have the inside local address.

Unfortunately, as the NAT MIB is currently structured, Step 1 requires us to
walk either the natAddrBindTable or natAddrPortBindTable since these tables
are indexed on { natAddrBindLocalAddr } and { natAddrPortBindLocalAddr,
natAddrPortBindLocalPort, natAddrPortBindProtocol }, respectively.

For our application tables like natAddrBindTable or natAddrPortBindTable but
indexed by { natAddrBindGlobalAddr } and { natAddrPortBindGlobalAddr,
natAddrPortBindGlobalPort, natAddrPortBindProtocol }, respectively, are
necessary. A MIB walk is not a viable solution due to scalability issues.

<End Comments>

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of Rajiv
Raghunarayan
Sent: Friday, October 19, 2001 7:37 AM
To: Matt Holdrege
Cc: Scott Bradner; [e-mail]; [e-mail]
Subject: Re: [NAT] Re: the future of the NAT working group


Matt/Scott,

There were two main concerns with the NAT MIB, brought up on this
alias:

1. Conditional NAT, as in use bind #1 when going to Src #1 to Dest #1,
   and bind #2 when going from Src #1 to Dest #2. (This was brought
   up by Cliff)

2. Extensibility of NAT MIB - specifically the Config Table, such
   that support for other protocols (TCP, UCP are the currently
   supported ones) can be added later w/o modifications to the
   NAT MIB (this one was brought up by Randy Turner).

Both these are being currently addressed, and should reflect in the
next revision of the MIB. Further, we would be moving over to using
InetAddressType and InetAddress (as mandated by RFC 2851).

-Rajiv.

Matt Holdrege wrote:
>
> At 03:01 PM 10/18/2001, Scott  Bradner wrote:
> >We would actually like to close the WG now.
>
> If I'm the only one objecting, then go ahead and close it.
>
> >The MIB may take quite a while since some rather basic thinking
> >needs to be done on what a NAT MIB should do.  We do not see
> >that there has been enough going on relative to that in the WG
> >to warrant keeping the WG open.
>
> This is the first I've heard of any basic issues with the NAT MIB. Have
> there been any issues brought up on the list that I might have missed? I
> thought the NAT MIB was pretty much done.
>
> _______________________________________________
> nat mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/nat

_______________________________________________
nat mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/nat


_______________________________________________
nat mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/nat