Nigel> I think there are 2 other forms of NAT:-
Nigel> Static NAT - where the original IP range and the remapped
Nigel> IP range have a 1:1 relationship, thus allowing incoming
Nigel> services to be handled as well.
Nigel> Dynamic NAT - where the original IP range is larger than
Nigel> the remapped IP range, and when an internal host accesses
Nigel> something outside the internal network it is given an
Nigel> external address on some form of lease. Management of
Nigel> these leases adds a whole new layer of complexity.
Nigel> Connection back to Dynamically NAT-ed hosts is possible
Nigel> while the lease persists.
Nigel> The basic difference between these is the lease management.
Nigel> Port remapping, as done by IP filter[2] is also possible.
Nigel> I guess that if we can specify things correctly, we should
Nigel> be able to come up with a model which will support all of
Nigel> these forms, including masquerading.
Nigel> Another side effect of NAT is that the box will need to
Nigel> answer on a range of IP addresses. These are effectively
Nigel> aliased interfaces. Should they be setup dynamically as
Nigel> needed by the kernel code, or should they be explicity
Nigel> configured by (someone) configuring aliases at boot time??
Not really necessary.
If a nat box is a router to a particular subnet all you need to do is configure
"translation routes" in the router.
You can take a look at the 2.1 routing code... It allows you to specify
"policies" for routes (source, destination) pairs. If the chosen policy
is "nat" the output function won't be ip_forward but an address translation
procedure that will afterwards output the packet.
Nigel> I think that these functions should all be controlled by
Nigel> additional information on the forwarding firewall. This
Nigel> means we need to redesign the firewall data structures, and
Nigel> also decide whether the input/output firewalls (which do
Nigel> not need all this extra information) need to match the
Nigel> forwarding firewall structures or not! Actually the
Nigel> easiest thing to do I guess is to add a pointer to an
Nigel> additional structure which describes the extra information
Nigel> required.
This is already in progress.
Nigel> Comments on how to take this all forward, gladly accepted!
Take a look at ANK's net/ipv4/route.c and net/ipv4/fib.c and help him
along in the development.
I'm currently trying to have the same kind of functionality from the forwarding
argotithms in the ipv6 code (which implies rewriting significative parts of
the core).
./Pedro.