[...]
>> Anyway, IPv4 seems to die slowly. The Internet Service Provider I
>> connect through from home, for example, offers a gray-IP-plus-NAT
>> access, which is barely the /Internet/ access
> What is "gray IP" ? RFC 1918 private addressing ?
Yes. (I'm surprised to find that calling these networks or
addresses ``gray'' is apparently a part of the Russian jargon.)
>> Fortunately, IPv6 has no NAT.
> Unfortunately, some people want a NAT implementation for IPv6. I
> guess that they have always lived in a NAT environment they view as a
> protection, and would feel so naked without it.
Yes. Also, it may be of some value when one ``arranges'' its
connections...
... It may make sense to help these people to learn IPv6
routing.
> NAT is not a part of the IPv4 specification, it is just a hack and it
> could be implemented for IPv6 too. Now that netfilter has IPv6
> conntrack, I guess that it could be done in Linux. However the
> netfilter developpers do not want to add IPv6 NAT and I support this
> decision, although IPv6 NAT could be a helpful quick and dirty hack
> in a some situations (e. g. source NAT to work around some flaws in
> the source address selection).
Couldn't ip(8) be used for that? I'm not very keen at it, but I
recently did the following at home (following the suggestions
from the Linux IPv6 HOWTO, the section on 6to4 tunnels.)
$ /sbin/ip rule list
...
32x-3: from <IPv4> lookup myvpn
This particular rule invokes the `myvpn' routing table
for all the packets with the source explicitly set (via
bind () or accept ()) to the <IPv4> address.
32x-2: from all to <Teredo-server> lookup myvpn
32x-1: from all to 192.88.99.1 lookup myvpn
These rules are so that the table will be invoked for
6to4 and Teredo as well.
...
$ /sbin/ip route show table myvpn
default via <IPv4> dev <Tunnel-Iface>
This rule makes all the packets for which this table was
invoked to be routed through <Tunnel-Iface>...
default dev <Tunnel-Iface> scope link src <IPv4>
... and this one apparently alters the source address
selection.
$
(This particular setup is all about getting an IPv4 address for
the box via an OpenVPN tunnel to yet another ISP; the 6to4
tunnelling failed to work, so I'm using Teredo for now.)
For the more complicated cases, some ``mark'' (fwmark?) selector
could be used in conjunction with iptables-based marking of
packets. Obviously, even though it relies on iptables, like
NAT, it:
* isn't stateful;
* doesn't rely on the particular transport protocols and
features (i. e., port numbers.)
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
No comments:
Post a Comment