[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


>>>>> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:


 >> 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

	... It may make sense to help these people to learn IPv6

 > 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 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


	(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

Reply to: