Subject: RE: (NAT) draft-ietf-nat-natmib-00.txt

From: Randy Turner <[email-masked]>
Date: Mon, 19 Mar 2001 05:41:04 -0800

I think the initial version of the MIB could contain the majority of IP
protocol tables that we are likely to see in the NAT world, and if we left
out one or two, the path to extensibility would be very clear. These initial
tables would include support for TCP, UDP, ICMP, GRE, and maybe ESP.

Randy

-----Original Message-----
From: Rajiv Raghunarayan
To: Randy Turner
Cc: NAT-WG
Sent: 3/19/01 5:29 AM
Subject: Re: (NAT) draft-ietf-nat-natmib-00.txt

Hi Randy,

I do think your approach sounds pretty reasonable - my only
concern is the number of tables that we may end up having (more 
the number of protocols using NAT, more the number of tables!!), 
and where/when should these tables be added is one more thing to 
be addressed (which I believe should not be a big issue).

Having said that, I still think your idea makes the MIB pretty 
flexible.

Also CCing the NAT-WG for inputs, if any.

-Rajiv.

Randy Turner wrote:
> 
> 
> Basically, each IP protocol uses different information to maintain a
NAT
> "session", like TCP and UDP use src/dst IP address and port number
> information.
> 
> ICMP NAT looks at src/dst IP, and ICMP transaction info, subtype, and
code,
> etc.
> 
> IPSEC ESP uses other types of information (not port numbers).
> 
> I think it would be easier to have the MIB be extended/augmented by
the
> addition of new IP protocol types, *if* there was a separate table of
NAT
> sessions for each type IP protocol. Having an "ip-protocol" object
would let
> you know which table to index, and the "ipProtIndex" would be an index
into
> the table for a particular NAT session.
> 
> The global NAT session table would include these two objects "table"
and
> "tableindex" to allow a manager to drill down to find out details of
the
> particular NAT session, from a transport perspective. Note that NAT
session
> information that is common to all IP protocols (like session timers,
src &
> dest IP, etc. ) would still exist in the global session table since
there's
> no need to replicate it.
> 
> Does this sound reasonable?
> 
> Randy
> 
> -----Original Message-----
> From: Rajiv Raghunarayan
> To: Randy Turner
> Sent: 3/17/01 6:07 AM
> Subject: Re: (NAT) draft-ietf-nat-natmib-00.txt
> 
> Hi Randy,
> 
> Thanks for reviewing the MIB. I have a small query regarding your
> suggestion (rather it's more of a clarification).
> 
> Are you suggesting that we replace all the timeout parameters
> in the natConfTable with 'ipProtocol' and 'ipProtocolIndex',
> where ipProtocol is a pointer to a table of protocol specific
> information, while ipProtocolIndex is an index into an entry of
> that table. I certainly seem to agree with you idea separating
> the protocol specific info from NAT, but that would entail
> adding procotol specific tables to maintain the same, and we
> may end up having lots of tables (depending on the quirks of
> individual protocols). Unfortunately, I'm not completely aware
> of the requirements of all protocols (as far as NAT is concerned),
> and hence cannot immediately judge if we could come up with a
> set of common information (which can be later extended by all
> protocols as and when necessary).
> 
> Do let me know your thoughts/opinions - I'm sure we could come
> up with something that's extensible and simple.
> 
> Thanks,
> Rajiv.
> 
> Randy Turner wrote:
> >
> > Hi Rajiv,
> >
> > Looking at the MIB, I think there should be a way to "table" ip
> protocols
> > that can be NAT'd. What I mean by this, is that you currently have
> static
> > fields in the NatConfEntry structure for TCP, UDP, and ICMP. In
order
> to
> > make this extensible, you might have a field called "ipProtocol" and
> > "ipProtocolIndex". We would then be able to define a table of
> > IP-protocol-specific information that is required to properly NAT a
> > particular IP protocol. Of course, for TCP and UDP, these entries
> could
> > point to the same type of table that uses IP addresses and the
notion
> of
> > "port numbers". However, for other protocols like GRE, 6to4, and
> others,
> > they would have their own table definitions that contain columns
that
> > describe fields that are required to NAT this particular IP
protocol.
> >
> > Is this something you have thought about?
> >
> > Randy
> >
> > -----Original Message-----
> > From: Rajiv Raghunarayan [mailto:[email-masked]]
> > Sent: Thursday, March 15, 2001 6:26 AM
> > To: NAT-WG
> > Subject: (NAT) draft-ietf-nat-natmib-00.txt
> >
> > Hello Folks,
> >
> > We have recently submitted a draft on NAT MIB, which can be
> > accessed at
> > http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-00.txt
> >
> > We would appreciate your feedback/comments/questions on it, so we
> > can work on improving it, as may be necessary.
> >
> > Thanks and Regards,
> > Rajiv.
> > -
> > To unsubscribe, email [email-masked]' with
> > 'unsubscribe nat' in the body of the message.
> > List archive: <URL:http://www.portmasters.com/archives/>
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.
List archive: <URL:http://www.portmasters.com/archives/>

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Mon, 19 Mar 2001 19:48:05 +0530

Randy,

There's one small difference I notice in what you're suggesting 
and the way the current architecture attends to the configuration.
To be more explicit, in the current arch. we can specify one row 
of info all protocols e.g. tcp, udp etc. (in the natConfTable).
While in case of the suggested approach, we'll need to have one
row for each protocol i.e. ip-protocol specifying the protocol 
and ip-prot-index the index into the protocol table. This would 
necessitate in having multiple entries (per protocol) not only in 
the natConfTable, but also correspondingly in the nat*AddrMap 
tables (since they an extension of the natConfTable). I think it
would complicate things a bit here..

Off hand, one thing that I think we could do is to define ip-protocol 
as a bit-field consisting of all protocols that need to be supported
i.e. tcp, udp, icmp etc., and have an ip-prot-index pointing into
each of these tables (as in the case above). One problem with this 
approach is that addition of new protocol tables would require 
addition of new flags/bits into the bit-field.

What do you think??

-Rajiv.

-