IPv6 network policies

[Jim Burwell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
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).
>
> Cheers
>
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.

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.

I actually tested this by doing the unreachable route thing to the
entire /64, and it actually had no effect.  Pings to both sides of the
tunnel worked, traffic still flowed through, and the ping-ping still
happened when I did a ping6 of :3 from inside or outside.  I believe
this is because the interface was still up and running with an address
on that /64, even though the connected route vanished from the routing
table when I put in the "unreachable".

The ACL method definitely does the job and gets rid of the ping-pong
by simply dropping traffic to anything but the two valid IPv6s on
either end of the tunnel.  Sure, it could get "messy" especially on a
router with a lot of ptp style connections since you'd need a bunch of
ACLs.

Actually, in a particular case, a Cisco style "wildcard" instead of
prefix length traffic filter would only require two entries to cover
an entire chunk of space dedicated to ptp links.  Say you allocated a
/48 for a raft of /64 ptp link addresses, and designed it so one side
would always be :1 and the other side would be :2.   You could fashion
a wildcard match so that the "accept" part matched the first 48 bits
exactly, was wild for the next 16 bits, and matched exactly all but
the last two bits (ie: "2001:db8:1234::[12] ::ffff:0:0:0:3" using 1 or
2 depending on which side you were on).  The "reject" (or drop) part
would be for the whole /48.  That'd cover and entire /48 worth of /64
ptp links with two ACL entries.

I'm not sure if Cisco (or other vendors for that matter) support wild
matching with IPv6 though, like the old IPv4 ACLs.  From what I've
seen in my playing with IPv6 under IOS so far, the IPv6 traffic filter
ACLs only do prefix length based matching (someone correct me if I'm
wrong!).  It'd be super fast in hardware too, since it's just a
bitwise AND of the address in-packet + compare with the ACL address
(I'm sure the prefix length methods work the same, generating the AND
mask from the addr/length pair).

- -Jim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvCwj0ACgkQ2fXFxl4S7sQ6GACcDJ+FjNlYUuf2NFedMW7tOrnw
x08AoMktXQwv26KQX9qgYbr141aaaJDA
=s5vg
-----END PGP SIGNATURE-----