IPv6 Firewall on CPEs - Default on or off

Andre Tomt andre at tomt.net
Mon Dec 3 03:47:49 CET 2012


On 03. des. 2012 02:42, Lorenzo Colitti wrote:
> On Mon, Dec 3, 2012 at 10:29 AM, Andre Tomt <andre at tomt.net
> <mailto:andre at tomt.net>> wrote:
>
>     Most newer devices do support DHCPv6 addressing* so I don't see too
>     many downsides of giving the managed addresses the full, unfiltered
>     experience, leaving the others only outbound + return traffic. Other
>     than making CPE's support something like it of course.
>
>
> Then filter all addresses with ff:fe in the middle bits?

Hmmm. Thats an intriguing idea. Seems like a fairly good security 
compromise to me. Perhaps as an additional level "medium" to the three 
levels (off, low - problematic inbound ports blocked, high - no inbound) 
Swisscom ended up with. And make it the default level instead of off. If 
it works well, anyway.

>     * Most devices I've seen not supporting DHCPv6 addressing have so
>     many problems with IPv6 that they dont belong on a public IPv6
>     network anyway.
>
>
> DHCPv6 has limitations such as reduced capabilities for host to
> implement privacy addresses, reduced reliability compared to SLAAC in
> multihoming scenarios, etc. Whatever you do in the filtering realm,
> please don't tie it to DHCPv6.

I did not consider the implications on multi-homing at all. So thats a 
fairly big drawback for this DHCPv6 based approach indeed, and puts it 
out of scope for ISP deployment. Different prefix multihoming is a 
pretty big feature of IPv6 we do not want to cause (possibly longer 
term) damage to. You are right - not a good idea for CPE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4234 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20121203/a86a3250/attachment.bin 


More information about the ipv6-ops mailing list