Michael Peddemors wrote:

On October 12, 2009, Patrick W. Gilmore wrote:

...

In summary: HE has worked tirelessly and mostly thanklessly to promote v6. They have done more to bring v6 to the forefront than any other network. But at the end of day, despite HE's valiant effort on v6, v6 has all the problems of v4 on the backbone, PLUS growing pains. Which means it is difficult to rely on it, as v4 has enough dangers on its own.

And don't forget.. Once IPv6 gets to the mainstream.. IP Reputation lists are going to have a real fun time :) Spammers would love to see IPv6 in place I am sure.

You seem to have concluded that blacklisting a prefix is much harder in ipv6 than it is in v4...

;) Routing IPv6 is going to require one heck of a thinking re- adjustment. Would be nice to just leave IPv6 in the premises, and keep IPv4 for routing.

Dan White wrote:

Reputation lists will just be on the /64, /56 and /48 boundaries, rather than IPv4 /32.

And then people will scream because someone setup a layout that hands out /128 addresses within a /64 pool. Jack

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

Can you please *NOT* suggest people *STUPID* ideas like filtering on arbitrary bits inside an address!? Thank you. I hope that you realize that stupid people will use these kind of practices and then "forget" to update them when they are actually realize that they are just that: stupid. Just a note: it is very useful to be able to just throw boxes in an ethernet, bootp them and assign them a function. This is how most large scale ISPs work, maybe no yours but there are lots that do. Assigning addresses using a stateless method like RA is suddenly a god-given. Of course if you do not want to receive mail from anybody, just don't use the Internet.

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.

Just use a *DYNAMIC* RBL, aka one which updates, aka the same system as currently in use on IPv4. These will most likely start blocking per /64, and when reaching a certain amount of /64s /48, will block the /48 and when reaching a certain amount of /48s per /32 just block out the whole /32. Of course other current "IPv4" practices for fending of botted hosts include: - require a valid and correct SMTP conversation - require HELO/EHLO + that the given hostname properly forward + reverses and matches the host that is connecting (this simple check cuts out most botted hosts) - Score sending hosts and message based on RBL and message content (aka use spamassassin and keep your rules up to date) For IPv6 nothing changes, the only thing that might change is that RBLs will take above policy, aggregating their prefixes to avoid hosts that swap addresses inside a /64, /48 or even a complete /32 to spam the world. This is also a good thing, because ISPs who keep their network clean will not go into the RBL, just like in IPv4. or in postfix config something like: 8<---------------------------------------------------------------------- smtpd_data_restrictions = reject_unauth_pipelining smtpd_recipient_restrictions = reject_unauth_pipelining, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_recipient_maps smtpd_sender_restrictions = reject_unknown_sender_domain, reject_unauth_pipelining, permit_mynetworks smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_unknown_hostname, reject_invalid_hostname, reject_unauth_pipelining smtpd_helo_required = yes smtpd_client_restrictions = permit_mynetworks ---------------------------------------------------------------------->8 Problem solved. Happy internetting.... Greets, Jeroen (Who indeed is not calling Marco stupid, as he is one of those people who is not stupid, he sometimes just has a wrong idea, just like me ;)

Marco Hogewoning wrote:

On Oct 12, 2009, at 9:40 PM, Jeroen Massar 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

Can you please *NOT* suggest people *STUPID* ideas like filtering on arbitrary bits inside an address!? Thank you.

I was just testing out how others feel about this...

...

(Who indeed is not calling Marco stupid, as he is one of those people who is not stupid, he sometimes just has a wrong idea, just like me ;)

Just testing the waters, the solution you suggested is more practical but you know as well as i do that there are those people out there who just filter out any inetnum object which matches *dsl* or *dhcp* which is about the same.

Well, that is simply because some people are stupid ;) Greets, Jeroen (Who now hopes these couple of messages are properly archived so that if stupid people at least google they don't fall into the above pitfulls).

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

On October 12, 2009, Dan White wrote:

Reputation lists will just be on the /64, /56 and /48 boundaries, rather than IPv4 /32.

IF Network Operators started advertising and routing /64 addresses, and assuming there were email servers our there running MX records on IPv6, http://eng.genius.com/blog/2009/09/14/email-on-ipv6/ for the spammers to send too, they would quickly adopt the idea of large blocks of IPv6 Addresses. If you had to apply reputation to them individually, it would make a much larger dataset to maintain. If you look at for instance the number of IP's on RATS-DYNA and RATS-NOPTR, (examples of IP's typically representative of DUL's) they have 65 Million IP's in the database at /32 IPv4, just think what the numbers would be with IPv6. Spammers could in theory be using a much larger set of routable IP's to send from. Once NAT is out, it opens a huge can of worms to detect and maintain the size of databases that would be needed to reflect this new space. With 18,446,744,073,709,551,616 compared to 4,294,967,296 anyone who is trying to build an effecient way to gather and store reputation, has their work cut out for them. Currently, maintaining the reputation of the IPv4 space is feasible, however once we reach IPv6 numbers, it would almost require a model of registering IP's for certain uses. We have enough trouble getting current providers to even have whois delgation, of who is using what part of their IPv4 spaces, I don't expect it to get any easier with IPv6. Imagine the size of ACL lists? -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.