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

Rajiv Raghunarayan <raraghun@cisco.com> Sun, 21 October 2001 17:53 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15684; Sun, 21 Oct 2001 13:53:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14806; Sun, 21 Oct 2001 13:45:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14781 for <nat@optimus.ietf.org>; Sun, 21 Oct 2001 13:45:49 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15619 for <nat@ietf.org>; Sun, 21 Oct 2001 13:45:48 -0400 (EDT)
Received: from cbin2-mira-01.cisco.com (cbin2-mira-01.cisco.com [192.135.246.89]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9LHjKY24173; Sun, 21 Oct 2001 10:45:21 -0700 (PDT)
Received: from cisco.com ([64.104.134.130]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id ANU08883 (AUTH raraghun); Sun, 21 Oct 2001 23:15:14 +0530 (IST)
Message-ID: <3BD309DA.458EF4C9@cisco.com>
Date: Sun, 21 Oct 2001 23:16:02 +0530
From: Rajiv Raghunarayan <raraghun@cisco.com>
Reply-To: rrajiv@cisco.com
Organization: Cisco Systems Inc.
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Van Horne <evh@cisco.com>
CC: rrajiv@cisco.com, Matt Holdrege <matt.holdrege@verizon.net>, Scott Bradner <sob@harvard.edu>, nat@ietf.org, srisuresh@yahoo.com
Subject: Re: [NAT] Re: the future of the NAT working group
References: <OOEOLEGAOBLEBAAJAODKEEOICDAA.evh@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: nat-admin@ietf.org
Errors-To: nat-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Network Address Translation <nat.ietf.org>
X-BeenThere: nat@ietf.org
Content-Transfer-Encoding: 7bit

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.

Ed Van Horne wrote:
> 
> 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: nat-admin@ietf.org [mailto:nat-admin@ietf.org]On Behalf Of Rajiv
> Raghunarayan
> Sent: Friday, October 19, 2001 7:37 AM
> To: Matt Holdrege
> Cc: Scott Bradner; nat@ietf.org; srisuresh@yahoo.com
> 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
> > nat@ietf.org
> > http://www1.ietf.org/mailman/listinfo/nat
> 
> _______________________________________________
> nat mailing list
> nat@ietf.org
> http://www1.ietf.org/mailman/listinfo/nat

_______________________________________________
nat mailing list
nat@ietf.org
http://www1.ietf.org/mailman/listinfo/nat