Re: Shutting Down a Network and Selling off Assets
and this is not spam?
Re: Shutting Down a Network and Selling off Assets
Remember, never blame malice for what can be explained by stupidity. I don't know the guy's intentions, but I'm pretty sure this is against the list policy. I would agree that the more appropriate avenue for him is probably ebay. -- -- Brian Raaen Network Engineer bra...@zcorum.com Tel 678-507-5000x5574 On Monday 22 March 2010, Randy Bush wrote: and this is not spam?
OpenLDAP and Active Directory
Please forgive me if this is an inappropriate place to make this requests. I need to setup an OpenLDAP server for proxy authentication to Microsoft Active Directory. From what I have been able to determine this is completely possible but I am missing something. I have the O'Reilly LDAP book but it was written several years prior to the current OpenLDAP version and there has been a major rewrite of the software. Can anyone help me or point me to somewhere I can get assistance? I have tried one consulting firm and that was a stellar failure. I've tried many different searches but a search for 'active directory, openldap, authentication, proxy, pass-through' either gives information for Squid or all go back to the same OpenLDAP Administrators guide from which I am missing something. Thanks! Carl
Re: OpenLDAP and Active Directory
On 03/22/2010 10:24 AM, Andrews Carl 448 wrote: I need to setup an OpenLDAP server for proxy authentication to Microsoft Active Directory. From what I have been able to determine this is completely possible but I am missing something. I have the O'Reilly LDAP book but it was written several years prior to the current OpenLDAP version and there has been a major rewrite of the software. Check out the Fedora Directory Server. http://directory.fedoraproject.org/
Re: OpenLDAP and Active Directory
On 22/03/10 12:24 -0500, Andrews Carl 448 wrote: Please forgive me if this is an inappropriate place to make this requests. I need to setup an OpenLDAP server for proxy authentication to Microsoft Active Directory. From what I have been able to determine this is completely possible but I am missing something. I have the O'Reilly LDAP book but it was written several years prior to the current OpenLDAP version and there has been a major rewrite of the software. Depending on details, you might find assistance with these two lists: http://www.openldap.org/lists/mm/listinfo/openldap-software http://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl If you're wanting to authenticate based on username/password (as apposed to client Kerberos credentials), include 'saslauthd' in your search. Can anyone help me or point me to somewhere I can get assistance? I have tried one consulting firm and that was a stellar failure. I've tried many different searches but a search for 'active directory, openldap, authentication, proxy, pass-through' either gives information for Squid or all go back to the same OpenLDAP Administrators guide from which I am missing something. -- Dan White
AOL Postmaster
Hi, If at all possible can a AOL Postmaster please get a hold of me. I have a client that co-lo's with use and we do the support for them and we need some help on getting mail to be delivering again to AOL. Thank You in advance. Sincerely, Mark Keymer
Re: AOL Postmaster
On 3/22/2010 14:03, Mark Keymer wrote: Hi, If at all possible can a AOL Postmaster please get a hold of me. I have a client that co-lo's with use and we do the support for them and we need some help on getting mail to be delivering again to AOL. Didn't I read that all of the AOL Postmasters had beenwhat is the word this week...made redundant? -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Network Naming Conventions
Sorry for the delay; I've been traveling and neglecting my lists. on Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote: With many changes going on this year in our network, I figured it's a good time to revisit our naming conventions used in our networks. I study PTR naming conventions as part of my Enemieslist project; it turns out that genericity in naming is highly correlated to bot spam, so some folks find my patterns useful to block and/or score inbound mail for risk of being bot-originated. As such, I've written a few rants about /poor/ naming practices that you may find useful and/or amusing, as well as a few pointing out the rare /good/ naming practices. (See below) In a nutshell, it boils down to this: - note static/dynamic hosts in the name, in the furthest-right-hand token possible (dyn.example.net, not dyn-foo-1-2-3-4.ny.ny.example.net). - cute and funny are not useful to others trying to decide whether to block services originating from a host; clarity and forethought and transparency are. - use different conventions for different services, this helps us differentiate dialup from dsl from cable and other infrastructure; don't assume everyone will do a whois lookup to find out this block is all consumer dsl and this other one is fixed business class. - be consistent, for the love of all that is good and holy. I've got over a hundred patterns for vsnl.net.in *alone*. There are a couple of IDs that discuss naming, in the anti-abuse context: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Here's what I've had to say on the matter over the years: DHCP doesn't necessarily mean dynamic http://enemieslist.com/news/archives/2009/09/dhcp_doesnt_nec.html annoying-stupidity.volia.net http://enemieslist.com/news/archives/2009/08/annoyingstupidi.html A few thoughts on reverse DNS / PTR naming http://enemieslist.com/news/archives/2009/06/a_few_thoughts_1.html Basic principles of DNS and their discontents http://enemieslist.com/news/archives/2009/06/basic_principle.html http://enemieslist.com/news/archives/2009/06/basic_principle_1.html http://enemieslist.com/news/archives/2009/06/basic_principle_2.html Today's DNS Spotlight: Eircom http://enemieslist.com/news/archives/2009/06/todays_dns_spot.html A couple more: kudos, and mixed kudos/gripe http://enemieslist.com/news/archives/2009/06/a_couple_more_k.html Principles http://enemieslist.com/news/archives/2009/06/principles.html There's a few dozen more in the gripes archive: http://enemieslist.com/news/archives/gripes/ HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: IP4 Space
On Mon, Mar 22, 2010 at 3:53 PM, Stan Barber s...@academ.com wrote: In this case, I am talking about an IPv6-IPv6 NAT analogue to the current IPv4-IPv4 NAT that is widely used with residential Internet service delivery today. I don't necessarily see 6-6 nat being used as 4-4 is today, but I do think you'll see 6-6 nat in places. the current ietf draft for 'simple cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is potentially calling for some measures like nat, not nat today but... I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6-IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of I think you'll see apps like this die... quickly, but that's just my opinion. the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT. Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive That's not obvious. if a low-cost (low pain, low price) means to multihome became available I'm sure it'd change... things like shim-6/mip-6 could do this. than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold. Now, there are clearly lots of specifics here that may change over time concerning what the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some want that to be /32, other are ok with something longer). I don't know how that will change over time. I also think that that peering will continue to increase and that the prefix lengths that peers will exchange with each other are and will continue to be less constrained by the conventions of the DFZ since the whole point of peering is to be mutually beneficial to those two peers and their customers. But, that being said, I don't think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4 tunneling is and will continue to be popular and that already makes for some interesting IPv6 routing concerns. I firmly hope that ipv6-in-ipv4 dies... tunnel mtu problems are horrific to debug. (we'll see though!) -chris Hope that clarifies my comment for you. Obviously, they are my opinions, not facts. The future will determine if I was seeing clearly or was mistaken in how these things might unfold. However, I think a discourse about these possibilities is helpful in driving consensus and that's one of the valuable things about mailing lists like this. On Mar 18, 2010, at 8:20 PM, Christopher Morrow wrote: On Thu, Mar 18, 2010 at 7:36 PM, Stan Barber s...@academ.com wrote: Ok. Let's get back to some basics to be sure we are talking about the same things. First, do you believe that a residential customer of an ISP will get an IPv6 /56 assigned for use in their home? Do you believe that residential customer will often choose to multihome using that prefix? Do you believe that on an Internet that has its primary layer 3 protocol is IPv6 that a residential customer will still desire to do NAT for reaching how are nat and ipv6 and multihoming related here? (also 'that has a primary layer 3 protocol as ipv6' ... that's a LONG ways off) -chris IPv6 destinations? I am looking forward to your response. On Mar 18, 2010, at 2:25 PM, William Herrin wrote: On Mar 5, 2010, at 7:24 AM, William Herrin wrote: Joel made a remarkable assertion that non-aggregable assignments to end users, the ones still needed for multihoming, would go down under IPv6. I wondered about his reasoning. Stan then offered the surprising clarification that a reduction in the use of NAT would naturally result in a reduction of multihoming. On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber s...@academ.com wrote: I was not trying to say there would be a reduction in multihoming. I was trying to say that the rate of increase in non-NATed single-homing would increase faster than multihoming. I guess I was not very clear. Hi Stan, Your logic still escapes me. Network-wise there's not a lot of difference between a single-homed IPv4 /32 and a single-homed IPv6 /56. Host-wise there may be a difference but why would you expect that to impact networks? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IP4 Space
On 2010-03-22 17:42, Christopher Morrow wrote: the current ietf draft for 'simple cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is potentially calling for some measures like nat, not nat today but... This is being reversed as we speak. Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: IP4 Space
On Mon, Mar 22, 2010 at 5:51 PM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
On 2010-03-22 17:42, Christopher Morrow wrote:
the current ietf draft for 'simple
cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is
potentially calling for some measures like nat, not nat today but...
This is being reversed as we speak.
yup, the 'simple' part of that proposal didn't stay 'simple'.. it's
looking to get more simple (simple again?) but, my point was there are
efforts to provide a not-wide-open-network for v6 deployments at the
residential-cpe end.
I think the goal of the author(s) intend to provide as much freedom as
possible, but wanted a base level of security for the end users, so we
dont re-learn 'lookie i have a dsl! Doh! i got pwned :(' again.
-Chris
Re: NSP-SEC
Guillaume FORTAINE wrote: This is a very pertinent question. My reply would be : How much money would you evaluate a security incident on your Cisco device ? Because, the fundamental questions are : a) How much value does your network bring to your business ? b) How much money are you ready to spend to ensure its security ? Conclusion : if you can't reply to these fundamental questions, hire a CISO and build a CSIRT. Best Regards, Guillaume FORTAINE Folks, this is why you shouldn't let your kids do crystal meth, just in case you were wondering. Andrew
Re: IP4 Space
On Mar 22, 2010, at 5:42 PM, Christopher Morrow wrote: On Mon, Mar 22, 2010 at 3:53 PM, Stan Barber s...@academ.com wrote: In this case, I am talking about an IPv6-IPv6 NAT analogue to the current IPv4-IPv4 NAT that is widely used with residential Internet service delivery today. I don't necessarily see 6-6 nat being used as 4-4 is today, but I do think you'll see 6-6 nat in places. the current ietf draft for 'simple cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is potentially calling for some measures like nat, not nat today but... That would be unfortunate, but, not unlikely. I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6-IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of I think you'll see apps like this die... quickly, but that's just my opinion. This I think is both unfortunate and unlikely. They haven't died yet in IPv4 land, we just use ridiculous heroic measures like STUN, SNAT, UPNP, etc. to attempt to circumvent the damage known as NAT. the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT. Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive That's not obvious. if a low-cost (low pain, low price) means to multihome became available I'm sure it'd change... things like shim-6/mip-6 could do this. Heh.. I don't see shim-6 deployment as low-pain. I think we will eventually need a true ID/Locator split, and I have an idea how it might be accomplished without altering the packet size, but, time will tell. than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold. Now, there are clearly lots of specifics here that may change over time concerning what the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some want that to be /32, other are ok with something longer). I don't know how that will change over time. I also think that that peering will continue to increase and that the prefix lengths that peers will exchange with each other are and will continue to be less constrained by the conventions of the DFZ since the whole point of peering is to be mutually beneficial to those two peers and their customers. But, that being said, I don't think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4 tunneling is and will continue to be popular and that already makes for some interesting IPv6 routing concerns. I firmly hope that ipv6-in-ipv4 dies... tunnel mtu problems are horrific to debug. Indeed. I think at worst, IPv6-in-IPv4 will advance to a state where IPv4 MTU problems become largely historic. This will occur because as IPv6 gains popularity, an increasing number of IPv4-only users will be forced to this as their only means of achieving IPv6 connections in many cases. I wish it weren't so, but, it'll be a wonderful surprise if 6in4 dies any time soon. Arguably, having it become popular enough to force resolution to the various IPv4 MTU issues by default would be just as useful. Owen
Re: IP4 Space
On 19/03/2010, at 4:07 AM, Stan Barber wrote: 1. Almost all home users (not businesses) that are connected to the Internet today via IPv4 are behind some kind of NAT box. In some cases, two NATs (one provided by the home user's router and one provided by some kind of ISP). There is no need for this using IPv6 to communicate with other IPv6 sites. There are a large number of users, here in NZ at least, but I imagine in other places, that have a single ethernet port ADSL Modem which terminates PPP, does IPv4 NAT, DHCP, etc. and then a Wireless Router which has its ethernet Internet plug connected to the ADSL Modem, and does IPv4 NAT, DHCP to end hosts, etc. This means that they have double NAT inside the home, and then in the future a potential third NAT. We did some looking at packets, and 17% of outbound packets from customers at an ISP had TTLs that indicated two L3 hops in the home - which for the majority of cases would mean double NAT. In NZ the most popular ADSL deployment is PPPoATM, so the ADSL unit the ISP ships (either loaned, or included in the install cost) is an IPv4 router terminating a PPPoATM connection, not a bridge or anything. -- Nathan Ward
Re: IP4 Space
On Mar 22, 2010, at 6:53 PM, Stan Barber wrote: In this case, I am talking about an IPv6-IPv6 NAT analogue to the current IPv4-IPv4 NAT that is widely used with residential Internet service delivery today. I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6-IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT. End-to-end applications will face much of the same interruption issues in the future as today. They will face firewall equipment that inspects the packet stream and purposefully blocks applications that are potentially harmful (e.g. vectors for systems infection). While the address translation part of stateful inspection firewall processing may not be used for IPv6, all other aspects of firewall function will be as applicable to IPv6 packets as they are to IPv4. Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold. I deal more with small businesses than residences, but I will take issue with the premise presented. Today there are many products, especially firewalls that allow multihoming of a sort using multiple upstream connections in conjunction with IPv4 and NAT. This is fairly simple, and can allow smaller offices, such as a company's field offices to combine multiple broadband connections, such as a cable modem and a DSL connection, to attain higher reliability and increased bandwidth. Because these appear to be just two broadband customer modems in one location (whether small business or residence), you cannot easily determine that such combining is being done. As this is a VERY useful, and well-used capability, it will be interesting to see what the vendors choose to offer in their equipment as IPv6 support improves.
