IPv6 network policies

[Alexander Clouter]

Jim Burwell <jimb at jsbc.cc> wrote:
> 
> On 4/11/2010 03:33, Alexander Clouter wrote:
>> Jim Burwell <jimb at jsbc.cc> wrote:
>>>
>>> Yes.  The ping-pong problem can be easily demonstrated on my 6in4
>>> link.  My simple solution is two ACL entries:
>>>
>>> Router A: ip6tables --append FORWARD --destination
>>> 2001:db8:1234:567::1/128 - -out-interface he6 --jump ACCEPT
>>> ip6tables --append FORWARD --destination 2001:db8:1234:567::/64
>>> - -out-interface he6 --jump REJECT --reject-with
>>> icmp6-adm-prohibited
>>>
>> That's an ugly use of icmp6-adm-prohibited if I might say.
>>
>> A better approach IMO: ---- ip route add unreachable
>> <your-whole-IPv6-allocation> ----
>>
>> This then only needs to be done at your end, which is the correct
>> thing to do (as you are the one using the default route).
>
> Yeah this is more of a "working example".  Any icmp6 type could be
> used (addr-unreachable perhaps), or the traffic could simply be
> dropped silently.
>
Probably better still (and then applicable for all):

ip6tables -A -i he6 -o he6 -j REJECT --reject-with icmp-host-unreachable

> Would that route really do what I want it to do?  Remember, the ptp
> link (6in4 tunnel) is a /64.  I wish only traffic to the :1 and :2
> addresses to flow for that particular /64.  Any other traffic to that
> /64 (such as :3) is dropped or rejected so there is no "ping-pong"
> situation.  Without that ACL the forwarding loop definitely does happen.
> 
Yeah, my fault, I mis-read your iptables rule and was thinking of the 
obvious case where loops arise from the use of the 'default' route, 
rather than in the case of P2P links.

I would still personally try to avoid the use of a firewall.  A filter 
is for filtering, not solving routing glitches. :)

Try something the following instead and let me know if that helps:

ip rule add to 2001:db8:1234:567::/64 iif he6 unreachable

Cheers

-- 
Alexander Clouter
.sigmonster says: It looks like blind screaming hedonism won out.