nanog mailing list archives
Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering)
From: Matthew Petach <mpetach () netflight com>
Date: Tue, 13 Oct 2009 11:22:23 -0700
On Mon, Oct 12, 2009 at 2:44 PM, Seth Mattinen <sethm () rollernet us> wrote:
Marco Hogewoning wrote:As this thread has drifted off topic any way, would it for instance be a good idea to simply not accept mail from hosts that clearly use autoconfig ie reject all smtp from EUI-64 addresses. Of course not a wise idea for your own outbound relays which should handle mail from your customers but on the incoming side it might as well save a lot of headache and there is no need to keep track of which /64 are access networks.That would be really, really bad. My 3750's won't accept arbitrary /128's in an ACL unless it's EUI-64 or I make up something similar that it will like. I'm sure I'm not the only person who owns a 3750. As such, my mail servers are using EUI-64 addresses. ~Seth
As I understand it, (and Cisco's documentation seems to support this, http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2ZY/command/reference/M1.html#wpxref54198 as an example), if you put a /128 in an ACL, you cannot specify any L4 port information for the address due to the limited width of the TCAM; in order to specify L4 information for the ACL, Cisco stuffs it into bits 24 through 39, losing what information was originally stored in those bits. It just so happens those are the fixed FFFE bits in an EUI-64 address, so if you're using EUI-64, no "real" information is lost. You can do your own non-EUI-64 addressing and still use ACLs with layer 4 port information as long as you don't put any addressing information into bits 24 through 39. Or, if you want to be *really* clever, you can address blocks of hosts with identical functions and identical security rules by assigning them addresses that differ *only* in bits 24 through 39; then, a single L4 /128 rule in you v6 ACL will actually apply to the entire equivalence class of servers, since from the router's perspective, it doesn't distinguish one server from the next as far as applying the ACL rule. However, if you opt to do this, make sure you document it *really* carefully, so the poor engineer who has to pick up after you will understand why the router is treating all of the servers identically, in spite of having what looks to be a single /128 listed in its ACL. ^_^; Matt
Current thread:
- Re: IPv6 internet broken, cogent/telia/hurricane not peering, (continued)
- Re: IPv6 internet broken, cogent/telia/hurricane not peering Patrick W. Gilmore (Oct 12)
- Re: IPv6 internet broken, cogent/telia/hurricane not peering Michael Peddemors (Oct 12)
- Re: IPv6 internet broken, cogent/telia/hurricane not peering Joel Jaeggli (Oct 12)
- Re: IPv6 internet broken, cogent/telia/hurricane not peering Dan White (Oct 12)
- Re: IPv6 internet broken, cogent/telia/hurricane not peering Jack Bates (Oct 12)
- IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) Marco Hogewoning (Oct 12)
- Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) Jeroen Massar (Oct 12)
- Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) Marco Hogewoning (Oct 12)
- Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) Jeroen Massar (Oct 12)
- Re: IPv6 internet broken, cogent/telia/hurricane not peering Patrick W. Gilmore (Oct 12)
- Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) Seth Mattinen (Oct 12)
- Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) Matthew Petach (Oct 13)
- Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) Seth Mattinen (Oct 13)
- Re: IPv6 internet broken, cogent/telia/hurricane not peering Michael Peddemors (Oct 12)