Perhaps someone from HE can re-confirm their open peering policy for us?
If they aren't (open) anymore, I'm impressed by the bravado...
Deepak
To be clear, I was not trying to imply that HE has a closed policy. But I can see how people might think that given my Cogent example. My apologies to HE.
And to be fair, I'm pounding on HE because they've always cared about their customers. I expect Telia to care more about their own ego than their customers' connectivity. So banging on them is nonproductive.
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.
Anyway, I have confidence HE is trying to fix this. But I still think the fact that it happened - whatever the reason - is a black eye for the v6 "Internet", whatever the hell that is.
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. 
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.
Michael Peddemors 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 timeSpammers 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...
Reputation lists will just be on the /64, /56 and /48 boundaries, rather
than IPv4 /32.
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
There is that chance yes especially from access networks which use RA.
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.
Just a few cents,
MarcoH
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 
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?
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 addressesCan 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.
MarcoH
Marco Hogewoning 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 addressesCan 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 meJust 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).
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
Matthew Petach wrote:
As I understand it, (and Cisco's documentation seems to support this,
Catalyst Supervisor Engine 32 PISA IOS Command Reference, 12.2ZY - mls flow to pagp port [Cisco Catalyst 6500 Series Switches] - Cisco
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.
Interesting; makes sense though. Thanks for the explanation.
~Seth