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

From: Scott Bradner <[email-masked]>
Date: Thu, 18 Oct 2001 18:01:08 -0400 (EDT)

We would actually like to close the WG now.

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.

Scott

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

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 18 Oct 2001 15:17:15 -0700

>We would actually like to close the WG now.

If I'm the only one objecting, then go ahead and close it.

>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.

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Fri, 19 Oct 2001 20:06:49 +0530

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.

---

From: "Ed Van Horne" <[email-masked]>
Date: Fri, 19 Oct 2001 11:27:49 -0700

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: [email-masked] [mailto:[email-masked]]On Behalf Of Rajiv
Raghunarayan
Sent: Friday, October 19, 2001 7:37 AM
To: Matt Holdrege
Cc: Scott Bradner; [email-masked]; [email-masked]
Subject: Re: [NAT] Re: the future of the NAT working group

Matt/Scott,

-Rajiv.

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sun, 21 Oct 2001 23:16:02 +0530

Hi Ed,

As per the new design i.e. for conditional NAT, the BIND table would
be modified to be indexed by {local address, local port, global addr,
global port}. In essence, global address and global port would be a 
part of the index of the NAT BIND table.

Having said that, if I understand your application correctly, this
might not meet your requirements. What you are looking for (please
correct me if I'm mistaken) is that the BIND table be indexed as
{global addr, global port, local addr, local port} - because it
seems that you know the global address (and port) and need to know
the MAC address of the interface that this address pertains to.
The (proposed) new index structure would still mandate that you
hunt through the whole table to find a reverse mapping.

Coming to the base design criteria for chosing the local addr
as the first index. Consider the following scenario:

Mgmt stn --------- NAT Router --------- Inside devices

Now if a management station tries to query some info from the
inside devices the info returned might be in terms of local 
addresses/ports. This would normally be translated by an SNMP ALG,
or the management application would need to translate it itself.
For a management application to do such translations, it would need 
to find the global values given the local values. Therefore, the
existing structure of the NAT indices.

To solve you problem, we would need to provide a reverse mapping
table i.e. a table indexed by {global addr, global port, local addr
local port} - and containing only these elements. While these are
redundant information (and redundancy is normally discouraged in
mib definitions), I do see your point/need for a reverse mapping.

A few questions regarding your application, though (rather 
clarifications).

You want to map from global addresses to mac addresses and intend
to do this as follows:

1. Global address -> Local Address (via NAT BIND table)
2. Local IP address -> Local mac address (via ipNetToMedia table).

There is one small concern that I see with your second step - 
the ipNetToMediaTable provides ARP information i.e. given an 
network layer address, it gives you the mac layer address. This
information is restricted to a LAN i.e. the mapping maintained by
ipNetToMedia table is restricted to devices on the same LAN.
If the device whose MAC addr you intend to find is on a different
segment, the information would not be visible in the ipNetToMedia
table.

For e.g. consider the following case

Mgmt stn. ------- NAT router ------- Local router ------ Device (UUT)

If you are trying to get the mac address of the UUT, and (lets say)
you get the local address of the device from the NAT MIB on
the NAT router. A query on the NAT router ipNetToMedia table would
not provide you with info regarding the UUT's mac address - you 
would need to query the local router for this mapping.

I'm sure you would've considered this, but just thought I'd bring
it up to your notice.

I will, in any case, discuss the new table with the other authors 
and get back to you.

-Rajiv.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Oct 2001 16:10:05 +0200

I agree with Scott's proposal. MIBs tend to interest a very small
group of activists.

    Brian