Thus wrote Rémi Després ([email protected]):
> 1.
> - Some consider that some form of NAT66 is useful for some real customer
> needs.
> - Clear descriptions of which scenarios benefit from which type of NAT66 are
> however still missing. (At this stage, this seems to only be scenarios where
> baring all incoming connectivity is found desirable, but more precisions are
> lacking.)
A case for stateless prefix translation with the intention to pick the
correct source address for a given connection:
Site A:
/-- FWE-A1 -- Provider A1
Internal -- FWI-A -- DMZ -- FWE-A2 -- Provider A2
| \-- FWE-A3 -- Provider A3
|
Site B:
|
Internal -- FWI-B -- DMZ -- FWE-B1 -- Provider B1
\-- FWE-B2 -- Provider B2
The DMZs contain IPSEC tunnel routers, mail relays, web proxies and
reverse proxies for services where the users know there are alternates
(and to pick foo2 or foo3 if foo1 is slow or unavailable).
The DMZs are not flat, and use both private and public addresses.
"Internal" is supposed to run on ULA in the future, as are the destinations
of the IPSEC tunnels (so tunneled communications never need renumbering).
The DMZs get a snippet of the local ULA, so communications that
don't cross the external firewalls also never need renumbering.
Prefix translation would happen on the external firewalls for selected
parts of the ULA space:
There are hosts on the internal network that communicate with partners
not through a IPSEC tunnel router but that open their own individual
secured connections. A simple default route would not allow to pick the
best upstream to reach a given partner. Expecting the hosts in the internal
network to be able to cope with two dozen routes and 6 prefixes announced
via RA faultlessly is naive IMHO, expecting fast failover in case one
upstream breaks even more so. The network admin does not administrate the
internal hosts, and the admins of the hosts are by no means network admins.
Rerouting will break all previous connections for the route that gets
changed. Expected reason for such a change is a network outage. This will
create some colorful cursing from the affected users, but not too much
damage if they can re-open their connections via a different path within
5 minutes or so; waiting half an hour OTOH would be too slow.
Automation via monitoring, at present, with v4, switches routes ons
the internal firewalls (plus other cleanup) if tests indicate that
an outside link went missing, within the acceptable timeframe.
Using PI and an AS would be technically simple and even prevent breaking
of connections, but would cost significantly more.
Without prefix translation and PI, the realistic method is to set up
vhosts that have a decent static network config for a communication partner
that can be changed by automation, and have the users connect remotely
from their desktops. This gives us extra DMZ hosts, extra management
effort (thus, extra cost) and is annoying for the users.
Being able to connect to a news server via nntp or similar would probably
not have enough of a business case to be implemented; currently that's
allowed to 'reputable' destinations since it costs nothing extra now.
Cost considerations will likely make us use translation whether it's
standardized or not. Currently available translation is stateful, which is
more interference with the packets than needed here.
regards,
spz
--
[email protected] (S.P.Zeidler)
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
