[Xorp-hackers] XORT-NAT: Proposal for NAT interface XIF and a config file syntaks

[Pavlin Radoslavov]

> >>I would also like to have ideas / comments about how to add more
> >>datatypes to the idl generator scripts. (for the port type, and an
> >>eventually ipv4-range type (which I here has made with 2 ipv4 ip-addresses.)
> > 
> > 
> > Can you clarify what you mean by "idl generator scripts".
> 
> i mean the tgt-gen and clnt-gen in the xrl/scripts directory.
> 
> > 
> > If you need ipv4-range type support, there is rtrmgr template type
> > named "ipv4range" and "ipv6range" which has the syntax IPADDR..IPADDR.
> > E.g. see the policy section inside etc/templates/bgp.tp.
> 
> I would also need some support for the "port" description language in
> the scripts (as far as I understand) Is this doable?

If the "port" type you need is just 16-bit wide integer, you could
just reuse the existing i32 or u32 types (the 32-bit wide integers).
Then, inside the rtrmgr template you can add "%allow-range" command
to restrict the allowed values in the [0, 65535] interval.

> > I would recommend to generalize the source and destination syntax by
> > separating the concept of protocol and port. Of course, for
> > protocols like tcp and udp you must have ports, so your syntax must
> > incorporate that too :)
> > 
> I did this with NAT in my mind, but it seems naturally to come up with a
> more generic dexcription for this which can be used more generally in xorp.
> 
> Do I understand you correct, that you would like a language that
> supports all possible protocols in the IP packet not only TCP, UDP.
> 
> or do you also want the layer 2 protocols included in the language?

I had in mind the IP protocols. E.g., if you have a field to specify
"tcp" or "udp", then this field should be generic to specify the IP
protocol (including "tcp" and "udp"). Of course, then the TCP/UDP
application port would be applicable only for the tcp/udp protocols.

I'd recommend to have a look into existing NAT languages such as
ipnat(5) from FreeBSD or the Juniper NAT configuration:
http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-services/frameset.htm
FYI, in general we have the tendency to use configuration statements
that are similar to Juniper.
Hence, you may want to start with the Juniper syntax and improve it
where you find necessary.

> >>interface nat/0.1 {
> >>
> >>	/** 
> >>	 * set nat disable (and enable) function
> >>	 *
> >>	 * @param disabled sets the status of the nat module true = disabled, 
> >>	 * false = enabled
> >>	 * @param disabledstatus returns the status of the module, 
> >>	 * true = disabled, false = enabled
> >>	 */
> >>	set_nat_disable		? disabled:bool -> disabledstatus:bool
> > 
> > 
> > What is the purpose of the returned disabledstatus?
> > If "set_nat_disable" returned success, then the status must be same
> > as the "disabled:bool" argument when the XRL was invoked.
> 
> I believe that the returned success was a "the communication went
> through" kind of reply, and a no-success would indicate some kind of
> fatal fault.
> Did I misunderstand some of the docs?

The XRL mechanism provides return status for every XRL invoked.
E.g., XrlCmdError::OKAY() indicates success,
XrlCmdError::COMMAND_FAILED() indicates failure in processing the
command, etc. See libxipc/xrl_error.hh for list of all XRL error
codes.

Regards,
Pavlin