Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]
On Thu, Mar 13, 2008 at 03:26:48PM +0200, Pekka Savola wrote: On Wed, 12 Mar 2008, Leo Bicknell wrote: ISP's are very good at one thing, driving out unnecessary cost. Running dual stack increases cost. While I'm not sure about the 5 year part, I'm sure ISP's will move to disable IPv4 support as soon as the market will let them as a cost saving measure. Runing for decades dual stacked does not make a lot of economic sense for all involved. So, can you elaborate why you think the cost of running dual stack is higher than the cost of spending timemoney on beind on the bleeding edge to do v6-only yet supporting v4 for your existing and future customers still wedded to the older IP protocol? I don't know why Leo thinks so, but even I can observe the extra recurring support cost of having to work through two stacks with every customer that dials in as being far greater than any technology costs in either single-stack scenario. The 'recurring' part is the real killer. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpolPyLiJUnU.pgp Description: PGP signature
Re: An Internet IPv6 Transition Plan
On Tue, Jul 24, 2007 at 10:01:44AM -0400, Chad Oleary wrote: DHCPv6 doesn't even hand out addresses. I wasn't going to say anything because Alain already said something. But we've gotten this question from at least two other sources in the last two days who read this and wanted to ask us what that was about. What were they thinking? It does seem pretty weird. So hopefully it will help people who don't have a geek to ask if I were to explain what's going on here: There are 'stateless' and 'stateful' ways to implement DHCPv6. You don't get address assignment unless you do 'stateful' DHCPv6 (and then it's complicated by wether you mean 'normal' addresses, 'temporary' addresses which change every renew, or 'prefix delegation'). But DHCPv6 does give out addresses. The easy way to think of DHCPv6 stateful vs stateless is to realize we have the same relationship in DHCPv4 - you can get an address like people normally do with DHCPv4, or you can use a DHCPINFORM if you already have one...so you can get configuration values like nameservers and such without allocating an address. That's all stateless DHCPv6 is. What Alain said is that until 12-18 months prior to today, there have not been very many sources of stateful DHCPv6 implementations. There are several implementations out now, many appearing enabled by default on production software you probably already have in your networks. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpjg14h4FrXY.pgp Description: PGP signature
Re: DNS Hijacking by Cox
On Mon, Jul 23, 2007 at 12:44:07PM -0400, Sean Donelan wrote: On Mon, 23 Jul 2007, Joe Greco wrote: I can't help but notice you totally avoided responding to what I wrote; I would have to take this to mean that you know that it is fundamentally unreasonable to expect users to set up their own recursers to work around ISP recurser brokenness (which is essentially what this is). Its more resonable to expect users to know how to remove bots and fix their compromised computers? Is it more reasonable to expect bots to implement recursive nameservers? -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpS0pbhOOJP8.pgp Description: PGP signature
Operators: the IETF's Dark Gods
On Wed, May 30, 2007 at 05:34:44PM -0700, Randy Bush wrote: about to run out of ip space. a half-assed design was released. the press stopped screaming. victory was declared, everyone went home. Actually, they didn't go home. Victory, they think, is never having to go home (but IETF Dallas is another story). I'm sorry this story is a bit long, the way I tell it, but hopefully it is entertaining (or at least easy to delete and ignore). At my first IETF, I attended a 'Scotch BoF'. It was singularly the most disturbing experience I've ever had at an IETF. Not merely because I don't drink, nor merely because of the antics of Internet professionals at a level of intoxication reminiscent of college dormatories. Every drink of scotch requires a toast, and every toast must be suffixed with ...and the Universal Deployment of IPv6. This phrase is uttered not jovially...not with celebratory thrust one usually attributes to, well, a toast...but rather with a low, monotonic, metronomic chant, in a chorus. You could hear it from outside the room, four doors down the hall. It is very much reminiscent of the congregation answers lines in church proceedings. Upon entry, I spent a few moments looking around for the Dark Altar these chants were directed to, as I expected to find chicken entrails, and black candles burning low. Perhaps a statue of a goat, or an incense burner, something to mark the demonic power they're hoping has the will and fortitude to see IPv6 universally deployed if only their chants will appease it. Actually I suppose you could say there was incense, but it was the dank, hot and humid incense of far too many people crowded in a hotel room with open flasks of single-malt. You could smell it down the hall, as near as the elevators. The point is I came to a realization: They were praying, and the altar they were praying to is an entity absent all too often in IETF proceedings in numbers sufficient to exert a presence...so it's fitting that there was no icon to represent it in their church. Operators. They're praying to the Big Operator in the Sky to deliver them to the promised land, an IPv6 network upon which their applications will multiply and flourish, and their products can be sold. Truly, I was a pilgrim in an unholy land. and, as usual, ops and engineering get to clean up the disaster. Except that this time, there are masses of people who now prostrate themselves before the Dark Altar of Operators, intoning mystic rituals of their own invention in hopes to appease you. Like the world's children who write to Santa Claus every year, these people have a list of toys they would like the Internet's operators to place in their stockings, and they're rapidly becoming more and more prepared to be good children to get them. It's progress, I think, that this places a substantially fairer share of power in the hands of those who can do something with it. For, after all, Santa Claus can always choose to give coal. But one might hope that at some point, they will give up praying for their answers, and will seek them instead. Obligatory operational content: Stock up on coal. If someone asks if you're a God, say Yes. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp9wZ4PvnUgg.pgp Description: PGP signature
Re: NANOG 40 agenda posted
On Tue, May 29, 2007 at 02:06:54PM +0200, Iljitsch van Beijnum wrote: DHCPv6 can't provide a default gateway, you need stateless autoconfig for that even if you use DHCPv6 for address assignment. I think you mean router advertisement, not stateless autoconfig. You don't need the M bit clear in order to use the router. On this topic, DHCPv6 also can't deliver a subnet prefix to clients. These are only delivered by router advertisements containing prefix options (not all router advertisements will contain prefix options, or may not include a prefix covering the allocated address), and without them, DHCPv6 implementations are justified in assuming the allocated address is a /128. Logically, they can't talk to one another without an advertising router present. So...I think how these two protocols comingle could use some work. In truth, I think we should just ditch rtadv/rtsol and add routers and subnet-mask options to DHCPv6. That's a shorter path with more finality than the pandora's box of adding options to rtadv. And there is the extra info, but DNS resolvers may be availalbe in stateless autoconfig in the future as well. Again, you mean in rtadv. Is it just me, or does it seem unusual for network infrastructure to advertise host configuration parameters? Maybe I'm getting old, but the idea of managing this configuration information in my routers sounds like a real chore compared to the old DHCP relayed central server model. This is probably the way we want to do IPv6 address provisioning for end-users in the future, but that requires that home gateways that implement IPv6 routing functionality come with the DHCPv6 prefix delegation client capability and have this configured by default so it all works out of the box. There's also a bit of a hinky issue in routing the delegated prefix to the client. Obviously, you don't trust route advertisements from the client - you're not going to run OSPF or BGP with all your broadband customers. How to do this in a way we can all just plug and play hasn't quite been decided yet. Would there be interest on a DHCPv6 related presentation at NANOG? -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp2HnT7yB8R7.pgp Description: PGP signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On Tue, Apr 17, 2007 at 08:20:08PM -0400, Leo Bicknell wrote: It's not that users are stupid, necessarily. That was a bad choice of words on my part. I was aiming at describing the perception we often have, as we sit in our back rooms and hear the varied reports from our support departments of the frustrations our users confront. We're in complete agreement, I just didn't voice it properly. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpyJTavctwaz.pgp Description: PGP signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On Mon, Apr 16, 2007 at 01:59:36PM +1200, Perry Lorier wrote: When you can plug your computer in, and automatically (with no clicking) get an IPv6 address, Router Advertisements let you automatically configure as many IPv6 addresses as you feel like. Remember that in XP, which Iljitsch recently cited to support his claim of years of operating system support, you must click IPv6 into your configuration. It probably wants your XP install disc, or something like that. In my point of view, this does not cut the mustard for such words. Let's be clear: There has been router and operating system support for years is a statement which predicates that the World has no technical excuse for not running IPv6 globally edge-to-edge already. I think such a statement is fundamentally flawed. This could be a fairly simple defacto standard if network operators start using it. This is an obvious weak link in the chain at this point tho. Does this represent years of router and operating system support? My answer is no. once you have DNS you can use the WPAD proxy auto discovery thingamabob. ...if you also had your domain suffix (unless you are suggesting that there have been WPAD records at the root for years?). RTADV won't help you here (tho they keep talking about putting domain-search and nameservers in it), and neither will DHCPv6 as it turns out (it carries a domain-search list, but not your domain suffix which is more what WPAD should really want). This is not years of operating system support. What has had years of operating system support, is the unfortunate practice of acquiring option code 252 in DHCPv4. and solve your dynamic dns problems (as IPv4 set top boxes do today), Updating your forward/reverse dns via DNS Update messages isn't that uncommon today. On Enterprise networks using GSS-TSIG, sure. On ISP networks, I think the only time end-hosts try to update their reverse DNS directly is when they're participating in a rather unfortunate, and unintentional, distributed DoS against the root servers. Which, oddly enough, you mention next. Actual reverse dns updates for end hosts (and not their NAT gateways) is relatively uncommon, owing to the fact that such end hosts generally are on RFC1918 addresses. http://www.caida.org/publications/presentations/ietf0112/dns.damage.html where hosts are trying to update the root zone with their new names. I'm confused by what you're trying to argue. Are you suggesting that AS112 represents years of operating system support for IPv6? So you can get from A to D without requiring DHCPv6. ...I hope you see that this is only so long as you require some clicking instead. This is all well and good for those of us who have sufficient growth (or equivalent feminine metaphor) on our chins, which we enjoy stroking thoughtfully while determining what all these correct configurations are. But I don't think it works for bearded geeks is setting the bar high enough when we use lofty words like supported by routers and operating systems for years. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpbIxFk401KC.pgp Description: PGP signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On Sun, Apr 15, 2007 at 12:38:42PM +0200, Iljitsch van Beijnum wrote: Sure, but that's because with IPv4, there are only three flavors: - manual configuration - PPP - DHCP Although nobody uses them: - BOOTP - RARP The distinction of DHCP, BOOTP, and RARP is important I think, and it would be good to remember the reasons for that progression, the lessons we learned on the way. If the progression from SLIP or HDLC to PPP also represents a progression in your view as it does in mine, then it is also important to remember. Both of these two progression trees represent the cumulative formulation of knowledge: Users are stupid. Automatic is not just best, it's the only way. The DHCPv6 servers and clients that I tested two years ago didn't even support address assignment to hosts. That sounds about right. The interesting events here have been this year or last. What DHCP and PPP did do, was to remove all of that, and make ISP integration of customer premise something that could just happen without any handholding or bearded geekery. Fortunately, the IETF got things right the sixth time around (?) by adding the stateless autoconfig to IPv6, so these additional mechanisms aren't necessary. Forgive me for saying (I do not mean it rudely), that I think this one sentence measures best precisely how far you've missed my point by. It is not enough to observe that the end host has been given an IP address, a prefix is imagined as part of that, and a default gateway. RARP and ICMP router discovery taught us this. It is still not enough to, after several years of thinking this was enough, throw in domain-search and nameserver configuration state. BOOTP taught us this. The main point, is that if you leave all other host configuration details up to, well, the host itself, then in practice what you're really doing is leaving it up to the user. Ultimately, it is mandatory that the end-user make a choice in this model, if not about everything, then about some things. This is intolerable in an ISP environment. Compare it to the current IPv4 network, and you see that no choice is mandatory. You just plug in and go. You might, optionally, over-ride any DHCP or PPP delivered knob, but it is easy to simply return the client to get everything dynamically and Just Work (tm). And exactly how often do people type in the address of their own system...? I'm thinking more of the 'gamer' demographic, wherein other people type in your IP address. A problem with the DNS and IPv6 is that unlike IPv4, you can't pre- populate the DNS so that each host has a valid DNS name as soon as it receives an address. Manual configuration is problematic for more than the obvious reasons: host may use temporary IPv6 addresses with random lower bits to avoid exposing their MAC address. The only reasonable way to solve this is with dynamic DNS updates. That's an excellent summary. Neither has RTADV supported dyanmic dns updates for years, nor is it likely to in the future. If it does, I would be surprised if it manages to work properly. This would be bad except that customers will usually have their own prefix in IPv6 so this should be solvable security-wise. It may not even involve DDNS, but rather be entirely internalized on the customer's home gateway. I think from everything I have just heard from you, that we could both agree: There have been IPv6 implementations for years. There has not been IPv6 support until very recently, this year or last depending on how you count. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpNNMQqjMy9K.pgp Description: PGP signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On Thu, Apr 12, 2007 at 11:11:54AM +0200, Iljitsch van Beijnum wrote: I have a Cisco 2500 with software from 1999 and a Windows XP box with software from 2001, both supporting IPv6, sitting here... I didn't get my first Mac until 2002, but that one supported IPv6 at that point, too. It would be foolish to suggest that software implementing IPv6 has not existed for many years. It would also be foolish to use support IPv6 as a blanket statement, when the features have not truly been usable by more than bearded geeks. There is a provisioning problem with IPv6, yes. Note that the word 'provisioning' is more than just 'addressing'. A given ISP may or may not directly communicate with end hosts using any form of DHCP, but the current broadband ISP models which are de rigeur would not be salient without DHCPv4 on the end hosts, even if that is only between the set top box and customer. So it might not be their job, but it's still an important facet of the architecture. One could say that although a DHCP department doesn't exist within ISP's, there would have been a need for a staffed department in its absence. I remember the era when we used to deliver install floppies to our prospective customers. And I can tell you they weren't a very good idea. Web pages full of instructions, flyers with simple to follow steps, none of them really worked very well either. Even if our iconic mascots trying to make the instructions friendlier were awfully cute. What DHCP and PPP did do, was to remove all of that, and make ISP integration of customer premise something that could just happen without any handholding or bearded geekery. When you can plug your computer in, and automatically (with no clicking) get an IPv6 address, have something tell you where your DNS assist servers, configure web proxies, and solve your dynamic dns problems (as IPv4 set top boxes do today), then I would allow you the use of the words 'supports IPv6' rather than 'implements IPv6'. On the subject of DNS, I think you are going to find that, since IPv6 addresses do not pass the 'phone test', IPv6 customers will have a new emphasis on having their names in DNS. But these are forward looking statements, and it's equally possible that people will be moved instead to use presence networks. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp3AhMWtSXvG.pgp Description: PGP signature
Re: Thoughts on increasing MTUs on the internet
Hopefully I'll be forgiven for geeking out over DHCP on nanog-l twice in the same week. On Thu, Apr 12, 2007 at 11:20:18AM +0200, Iljitsch van Beijnum wrote: 1. It's no longer necessary to limit the subnet MTU to that of the least capable system I dunno for that. 2. It's no longer necessary to manage 1500 byte+ MTUs manually But for this, there has been (for a long time now) a DHCPv4 option to give a client its MTU for the interface being configured (#26, RFC2132). The thing is, not very many (if any) clients actually request it. Possibly because of problem #1 (if you change your MTU, and no one else does, you're hosed). So, if you solve for the first problem in isolation, you can easily just use DHCP to solve the second with virtually no work and probably only (heh) client software updates. I could also note that your first problem plagues DHCP software today...it's further complicated...let's just say it sucks, and bad. If one were to solve that problem for DHCP speakers, you could probably put a siphon somewhere in the process. But it's an even harder problem to solve. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpdEnSRZ3khA.pgp Description: PGP signature
Re: Thoughts on increasing MTUs on the internet
On Thu, Apr 12, 2007 at 05:58:07PM -0400, Daniel Senie wrote: 2. It's no longer necessary to manage 1500 byte+ MTUs manually But for this, there has been (for a long time now) a DHCPv4 option to give a client its MTU for the interface being configured (#26, RFC2132). Trying to do this via DHCP is, IMO, doomed to failure. The systems most likely to be in need of larger MTUs are likely servers, and probably not on DHCP-assigned addresses. If you're bothering to statically configure a system with a fixed address (such as with a server), why can you not also statically configure it with an MTU? -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpBuU12jypmU.pgp Description: PGP signature
Re: Thoughts on increasing MTUs on the internet
On Thu, Apr 12, 2007 at 06:18:56PM -0400, Daniel Senie wrote: Neither addresses interoperability on a multi-access medium where a new station could be introduced, and can result in the same MTU/MRU mismatch problems that were seen on token ring and FDDI. Solving Ilijitsch's #1 is a separate problem, and you can solve them in isolation. If you chose to do so, #2 is already solved for all hosts where dynamic configuration is desirable. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpGBzCWda9Fn.pgp Description: PGP signature
Re: IPv6 Finally gets off the ground
On Tue, Apr 10, 2007 at 03:54:39PM +0200, Stephane Bortzmeyer wrote: IPv6 has had operating system and router support for years. I'd have to object with such a blanket statement. I don't think you can say you support IPv6 (from an ISP's point of view) without DHCPv6, since I don't think anyone at a large ISP sized scale is going to leave address assignment up to RTADV. I'm aware that Vista added support for DHCPv6, and I have heard naught else (aside from the unixes). So, it's my opinion that IPv6 may only recently have started enjoying the level of operating system support required for actual ISP-scale use by one major vendor...and I don't know how commonly deployed Vista is yet. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpkju5wVgq6x.pgp Description: PGP signature
Re: death of the net predicted by deloitte -- film at 11
On Sun, Feb 11, 2007 at 11:14:49AM -0700, brett watson wrote: Verisign, the American firm which provides the backbone for much of the net, including domain names .com and .net,... IP over domain name registration? -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins
Re: that 4byte ASN you were considering...
On Tue, Oct 10, 2006 at 01:59:22AM -0500, Randy Bush wrote: somehow we seem to have survived similar issues in IP quad representation. Or domain names. I'm concerned by the kind of discussion I'm seeing here. RFC's are not law, and if your router vendor adopts this informational document in such a way that it breaks your scripts then that's an issue to take up with your router vendor(s). I don't see why there's any reason it can't be made so (excuse me for using what little Cisco configuration language I can remember): o 'conf t' accepts: router bgp 255.255.255.254 neighbor 10.0.0.1 remote-as 255.255.255.255 o 'wr mem/term' writes out: router bgp 4294967294 # 255.255.255.254 neighbor 10.0.0.1 remote-as 4294967295 # 255.255.255.255 or even: # BGP 255.255.255.254 router bgp 4294967294 # EZ-ASN: 255.255.255.255 neighbor 10.0.0.1 remote-as 4294967295 One or both of which probably won't break anyone's scripts. The point is that this is a configuration language versioning issue, which isn't something I think of the IETF having either a lot of interest or ability to define. As Shields has indicated, email the IETF mailing lists if you must. I'm in favor of people sending mail to lists to which I do not subscribe. But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpBgptt6Z5i1.pgp Description: PGP signature
Re: that 4byte ASN you were considering...
On Tue, Oct 10, 2006 at 02:53:53PM -0500, Joe Abley wrote: On 10-Oct-2006, at 12:01, David W. Hankins wrote: But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill. It's not so weird when you realise that the notation adopted has an impact on other IETF work (RPSL is the obvious example that springs to mind). I think you misunderstand me... It's not weird that this document exists. It is weird, to me, that people who have concerns about their router's configuration syntax expect to be able to take this up with the IETF, rather than their router manufacturer. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpeITfRTo47o.pgp Description: PGP signature
Re: that 4byte ASN you were considering...
On Tue, Oct 10, 2006 at 09:23:54PM +, Michael Shields wrote: Personally, I care less about which notation we choose to express four-byte ASNs than that *everyone choose one notation*. Choosing a Totally, and I would be surprised if that were not the eventual outcome. In the absence of any other format, the dotted quad will probably bubble up into user interfaces eventually. I think everyone else is wrong that there is going to be some sort of heinous y2k doomsday scenario here in regards to breaking their current-day scripts or operational practices, or if there were that this is an issue to take up with the IETF rather than the vendors making said changes. As to whether this is within the scope of the IETF, note that they are already going far, far beyond this in the Netconf WG, which is defining a complete router configuration protocol. Netconf absolutely, and zeroconf too. These are machine languages, they aren't user interfaces. So this is just a level of indirection. If someone were suggesting a change to the netconf wire format that is not reverse compatible, that's obviously something that should be brought up at the IETF! But a change to the config file or web/scripting interface or whatever that you use to trigger Netconf into action? Totally not their bag. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpSNKKJe8Itg.pgp Description: PGP signature
Re: Best practices inquiry: tracking SSH host keys
On Wed, Jun 28, 2006 at 06:07:33PM -0700, Allen Parker wrote: Why not, on a regular basis, use ssh-keyscan and diff or something similar, to scan your range of hosts that DO have ssh on them (maybe nmap subnet scans for port 22?) to retrieve the host keys, compare them to last time the scan was run, see if anything changed, cross reference that with work orders by ip or any other identifiable information present, and let the tools do the work for you. Cron is your friend. Using rsync, scp, nfs or something similar it wouldn't be very difficult to upkeep an automated way of updating such a list once per day across your entire organization. _wow_. That's a massive why not just paragraph. I can only imagine how long a paragraph you'd write for finding and removing ex-employee's public keys from all your systems. So, here's my why not just: Why not just use Kerberos? -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp4b9fjyYjsf.pgp Description: PGP signature
Re: insane over-regulation - what not to do
On Wed, Jun 21, 2006 at 10:36:04AM -0700, Randy Bush wrote: the whole thing as a piece. it looks to be a, likely well-meaning, attempt by a gang of bureaucrats and a fancy consultant to put the universe in a glass jar and preserve it. from end user, to net operations, to infrastructure, to administration, to law. There is one thing in here which has great amusement appeal to me: g. ensure compliance with accepted International technical standards in the provision and development of electronic communications and transactions; The protocol police! It sounds like they're going to create an Industry Forum (GHANOG?), which may produce a voluntary industry code. About like our housing code in the US. That's going to be fun to watch. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpeSQViOyltm.pgp Description: PGP signature
Silicon-germanium routers?
IBM and Georgia Institute of Technology are experimenting with silicon- germanium, it is said here: http://tinyurl.com/g26bu I find this interesting having just attended NANOG 37 where some manufacturers of network devices told us in a panel that network heat problems weren't going away unless there's a 'next big thing' in manufacturing process. Is this it? Corrolary: If our routers are made of silicon-germanium, would the CLI only operate in Deutsch? -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpriRxS3Y9In.pgp Description: PGP signature
Re: Silicon-germanium routers?
On Tue, Jun 20, 2006 at 12:59:54PM -0700, Tony Li wrote: Sure doesn't sound like it. In fact, it sound like they're pushing to a high frequency regardless of the power and thermal consequences. I thought their 500 Ghz number was just for rediculous press teasing, like the people who use lHe to push AMD chips to ~10 Ghz. The 350 Ghz 'at room temperature' insinuation is the most interesting to me. It also sounds like it's a single transistor. It takes a few of them to make a router. ;-) I haven't seen any evidence to support or contradict this, so I'll take your word for it... A single-transistor test on a single chip would be both ludicrous and incomparable. I also suspsect that the community is not ready to transition to liquid-cooled systems. I rather assumed 'at room temperature' implied a standard heat sink and fan. Perhaps there's not enough information in that article to draw a conclusion from. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgptLk0mecD4k.pgp Description: PGP signature
Re: wrt joao damas' DLV talk on wednesday
On Tue, Jun 13, 2006 at 01:18:06AM -0700, Randy Bush wrote:
actually, i think it most important that a proposed dlv service
make very clear its security policy and process in vetting the
correctness of the data it serves, i.e. the trust anchors for
dependent zones.
Oh, you're asking specifically for more detail than is on our
web page, then ('Registering your zone key in the DLV tree').
You mentioned that this would have relevance to future practices
should the root be signed, and I can't for the life of me see how.
I think this is an artificial problem that arises only for ISC since
we're out of the delegation loop (except where we can authenticate
registries and receive trust anchors from them).
Do you imagine that, if IANA/ICANN/USDOT/someone were told to
implement a policy to sign the root, that they would have trouble
identifying the owners of the TLD's reliably?
If so, wouldn't this problem already exist today in the information
already present in the root zone?
once one can have confidence in the correctness of the data
served, one might then become inclined to worry about the
reliability of the service :-).
--
David W. HankinsIf you don't do it right the first time,
Software Engineer you'll just have to do it again.
Internet Systems Consortium, Inc. -- Jack T. Hankins
pgp9Ou6ZZGlFt.pgp
Description: PGP signature
Re: wrt joao damas' DLV talk on wednesday
On Tue, Jun 13, 2006 at 10:27:49AM -0700, Randy Bush wrote: if other non-delegators run dlv services, they will have the same issues. Absolutely. and if you are a delegator, why play dlv as you can directly sign? I think Paul answered this question (it's because of the way DNSSEC-bis proves non-existence). I basically can't answer your other questions. I don't know the answers to most of them and don't want to guess at the others. And as for IANA applicability, I guess I'll have to give up and defer to you and DRC. It still sounds wonky to me that you would operate the root's authentication chain out-of-band like a DLV registry when in-band seems so much more useful and reliable. But clearly I don't know enough about the root's (scary) problems. when charles mussisi flies from kampala to redwood city, I think our staff in Europe are closer to Kampala than 950 Charter, and I assume at least one of them would be authorized, and I assume that there are some events somewhere that both Mr. Mussisi and some authorized member of our staff are likely to both attend. But if you would like to imagine for a moment that we actually require people to meet us in a faraday cage embedded 30 feet under the Arctic ice in an undisclosed location - just take a metal detector with you and knock on the ice when you think you've found us - then which of Paul's list of 5 other options would you prefer? Or is there a 6th? How soon can you start? That's an important open question in this dialogue. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpPZ8bhnevTH.pgp Description: PGP signature
Re: wrt joao damas' DLV talk on wednesday
On Mon, Jun 12, 2006 at 09:41:03PM +, Paul Vixie wrote: since joao is probably still sleeping-off the time shift from san jose to madrid, i'll chime in here. the last plan i saw was the same as the last draft i heard about for what any other important zone would do with a key that has to be hard coded in a lot of places: allocate more than one KSK and an infinite lifetime. use this KSK offline (only), to generate ZSK's with short lifetimes that are in turn used online to sign the zone. At NANOG 37, possibly after you had left the room, Randy actually asked if we were writing a document describing ISC's operational guidelines and policies for the dlv zone. All those things DRC recently said no one has told him to do yet. It's in that context I think that he asks these questions now. I got the idea Randy was looking for info like appears in the BCP that describes root server operations requirements, except as applies to our DLV zone (and probably not an IETF document). So, how many boxes have the private keys? What barriers lock them away? How many people have access to the raw keys? How many authoritative servers give out dlv.isc.org and where do they sit in the network and on the globe? Do you pre-publish or double-sign (or triple-sign (or quintuple-sign (or ...)))? I have no idea if such a thing exists or plans to exist, or what might appear inside it. | 1. figure out why the root zone isn't signed and fix whatever it is. | 2. design your own version of DLV (as sam weiler has done, long before | 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code | 4. go to IETF and say i think something DLV should be a standard but 5. forget about DNSSEC until all these problems are solved by others. Even if I choose not to do any of those 5 things and adopt ISC's DLV registry, I probably would want some basis to compare ISC's DLV registry with Acme's DLV registry. Having a basis to compare ourselves with...an imagined ideal of ourselves...is a bit of an intellectual excercise, but it does set the bar for future work in similar operations, such as signing TLDs and the root zone (wether it is IANA who is asked to do it or not). And it helps people decide if they want to throw in or wait it out for someone with stronger practices (or deploy a DLV with stronger practices). I personally think Randy's request (or my imagined version of same) would be good reading, if someone could be found who had both the time and knowledge to write it, and if doing so wouldn't be construed as giving away the keys to the castle. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpTTO0IQk1fQ.pgp Description: PGP signature
Re: Is your ISP Influenza-ready?
On Wed, Apr 19, 2006 at 11:57:01AM +0100, [EMAIL PROTECTED] wrote: That recirculated air is likely to be shared with the rest of the buildings inhabitants, not just the engineers. I'd say it's 50/50 from the buildings I've worked in. The Commonwealth Building in Portland Oregon actually put the air handler in the wiring closet. http://www.emporis.com/en/wm/bu/?id=122627 I know this because when it would start up at 0600, it would brown out the electrical power. Our equipment was on a UPS that detected this and bridged the gap - but customer equipment on another floor wasn't. I was standing next to it, fancy borrowed ethernet protocol analyzer attached to the customer line...at 0600 when they described the problem would manifest, when the air handler startup noises succeeded in scaring the living daylights out of me. It didn't help that the UPS was beeping at the same time and the protocol analyzer was registering a flood of collisions and generally spitting out red text and flashy lights. As I remember the ducting, it ran from plenum, to air handler, back to our plenum (there was no false roof in the wiring closet, it was just sort of open where the neighboring office walls ended). It would be good to know for certain. And the point is kind of moot if your company is large enough that they've centralized your engineering groups into a single building (as has also been the case at some places I've worked). We had things much worse than that in the Commonwealth building however... On the other hand, engineers tend to have already perfected the art of working remotely. Continuity planning people are likely to notice that skilled technical people are essential to smooth operations and will kick them out of the office before anyone gets sick. If I ever had one of those watching over me, he never said You fool! You look like you have flu symptoms! Go home! I have on rare occaision had the converse said due to some impending deadline... I suspect by the time it's an epidemic it's probably too late. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp7asnTmB7p9.pgp Description: PGP signature
Re: Is your ISP Influenza-ready?
On Mon, Apr 17, 2006 at 02:05:41PM -0400, Jared Mauch wrote: Back to the original question, how well could you cope for such an event? It's always challenging to think about what would happen as sometimes it includes the unexpected. All the guidance suggests you're going to lose as much as 40% of your workforce. Well, what intrigues me, is: which 40? I don't think the virus is going to select sales, marketing, and Tech support in that order (unless it's an STD epidemic, har har). Were that the case we might actually look forward to such outbreaks. On the other hand, at *every* substantially sized network I've worked at, the Network Engineering types that might reasonably do something useful in such an emergency situation are generally: 1) A close-knit group, going to lunches together and cohabitating cubicles so as to avoid exposure to aforementioned sales, marketing, and tech support or customer service. Indeed, at a few places I worked, they even spent most every weekend together. For all the rest of the world decrying geeks as socially inept, they are highly efficient at social assimilation of their own kind. 2) Given a 'low desirability' office space. No windows, usually poor air circulation. It is often called The Back Room or similar, or is located in a space you wouldn't expect to find humans. This isn't (usually) anyone being mean: engineers seem to like dark corners, something about making it easier to read monitors, and locations that provide fewer interruptions due to unlikelyhood of foot traffic. 3) Better at taking care of their networks than themselves. Or at least, more willing to - too frequent is the case I see an engineer, hacking, coughing, and wheezing at his monitor, plucking away at the keyboard deep into the night. So there you have it. They're likely to come to work even though they're sick (presuming they don't know it's a lethal virus), where they work and spend all their face-to-face time in close quarters with recirculated air with the rest of the company's engineers. It's like someone intentionally optimized this function specifically to be the most pessimal. So I think it's actually highly probable that a meatspace-viral vector would take out the entire engineering staff at most service providers I've worked at if only one of them caught the bug. I have to imagine this is representative of other work environments. We all seem to share the same collective experience in this sense, at least the folks I've talked to. And that loss would be way under 40% of the total company's staff, a mere blip really. So, which 40% can you afford to lose? How likely is it that the 60% that's left behind will be able to do the job? Will they need step-by- step instructions so that even an untrained monkey can muddle through? -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpjTcTpih4qo.pgp Description: PGP signature
Re: Is your ISP Influenza-ready?
On Tue, Apr 18, 2006 at 12:43:11PM -0700, Crist Clark wrote: Barry Shein wrote: So if you're really expecting something as macro as 40% of the population dropping dead I think one has to think much bigger and much more in the realm of unexpected consequences. Uhh... I think, I _hope_ that we are talking about 40% of your workforce NOT SHOWING UP TO THE OFFICE for days or weeks, not dropping dead, not even necessarily getting sick. A slightly different aggregate: 40% of your workforce being unable to work. Some portion of that might be death, grieving, being sick, helping family or friends that are sick, fighting off zombies, or searching aimlessly for human brains to consume. That is to say that some of the remaining 60 may be working from home. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins
Re: AW: Odd policy question.
On Sat, Jan 14, 2006 at 05:31:12PM -0500, Jeffrey I. Schiller wrote: If registrars regularly checked for lame delegations (or checked on demand). Then a way to attack a domain would be to forge DNS responses to cause the registrar to remove the domain because it is lame. So DNSSEC would be needed to be sure... Something more than merely DNS-SEC. DNS-SEC is about proving zone contents (object security). To prove lame delegation you'd need a means to identify the nameserver (channel security) that's supplying the response. The difference between this zone contains (or doesn't) an RR versus this DNS packet is from the server named George. You could prove inconsistent delegation - that the parent and child differ. But this is not necessarily lame. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpZ8oY8W0ESG.pgp Description: PGP signature
Re: AW: Odd policy question.
On Fri, Jan 13, 2006 at 10:09:51AM -1000, Randy Bush wrote: it is a best practice to separate authoritative and recursive servers. why? I'm not sure anyone can answer that question. I certainly can't. Not completely, anyway. There are too many variables and motivations. Some remember to say Read RFC2010 section 2.12. But since that's a document intended specifically for root server operation, it's not as helpful to those of us that don't operate roots. This is about like saying, Because Vixie wrote it. e.g. a small isp has a hundred auth zones (secondaried far away and off-net, of course) and runs cache. why should they separate auth from cache? Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's been discussed already. Note that I can't seem to find the same claim in RFC2870, which obsoletes 2010 (and the direction against recursive service is still there). But in my own personal experience, I can still say without a doubt that combining authoritative and iterative services is a bad idea. Spammers resolve a lot of DNS names. Usually in very short order. As short as they can possibly manage, actually. The bulk of the addresses they have on their lists aren't even registered domain names. Resolving some of these bogus domain names uses substantially more CPU than you might think (spread out over several queries). The result, at a previous place of employ that did not segregate these services, was that our nameservers literally choked to death every time our colocated customers hit us with a spam run. The process' CPU utilization goes to 100%, queries start getting retransmitted, and pretty soon our authoriative queries start getting universally dropped because they're the vast minority of traffic in the system (or the answer comes back so late the client has forgotten it asked the question - has already timed out). So if someone on our network was using our recursive nameservers to resolve targets to spam, people couldn't resolve our names. Even though our servers were geographically diverse, they were all recursive - the miscreant clients would spam them all in harmony. I guess you could say it made it easy to find and shut these miscreants down. But I'd much rather 'spammer detection' be based on something that does not also take my own network down. Now, certainly, designing a network around being impervious to our clients: the spammers is not a strong motivation for everyone. But it doesn't take a spammer to see the same series of events unfold. It can just as easily be...say...a lame script in a server...handling error conditions badly by immediately retransmitting the request (we got this too - it flooded our servers with requests for a name within their own domain without any pause inbetween...we kept having to call this customer to reboot his NT box, putting their address space in and out of our ACL's...a significant operational expense, and outages that affected the majority of our customers...for a small colocation customer (not a lot of cash)). So I think this is pretty valid advice for pretty much anyone. It's just a bad idea to expose your authoritative servers to the same problems an iterative resolver is prone to. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpZg7P96gDuV.pgp Description: PGP signature
Re: AW: Odd policy question.
On Fri, Jan 13, 2006 at 12:07:11PM -1000, Randy Bush wrote: and thereby hiding the fact that someone has either lame delegated or i have forgotten to remove an auth zone, both cases i want to catch. not a win here. Responding with stale data is, arguably, more damaging than failing to respond at all. So much so that the SOA expiry field serves to protect us from this threat. So, even though Randy is wrong for wanting to catch misconfigurations by producing incorrect data, I also don't see where Joe is coming from. If I hosted my domain with someone whose server was answering recursive queries, I would probably use a lower value for expiry than I normally would otherwise. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpQkf1foE4Mp.pgp Description: PGP signature
Re: AW: Odd policy question.
On Fri, Jan 13, 2006 at 12:57:22PM -1000, Randy Bush wrote: at root, i am a naggumite. erik nagum was good at describing why broken things should not be patched over. it's better to amplify breakage if that's what it takes to get it fixed asap. In this case, the 'break' is only damaging if it is in the query path. If it is not, it ultimately reaches the expiry timer and becomes a non-issue for all involved. Perpetual entropy leading to heat death is not acheived. So, serving a zone that has a very large expiry on a recursive nameserver is, in effect, putting your hand on the burner. Remember I'm on both sides of this fence; Either use a low expiry on zones hosted by recursive nameservers, or use any (probably large) expiry on authoritative-only servers. an analogous gripe i have is do-gooder software, which also applies to configuration and other policies. if do-gooderism 'successfully' compensates for an error, no one notices. when it makes a mistake, everyone screams to the heavens and throws mud. e.g. remember when ejk put in an interceptor cache to give his customers seriously better performance? Then I guess you won't be a fan of: http://www.ietf.org/internet-drafts/draft-andrews-full-service-resolvers-01.txt pain is nature's way of telling us to take our hand off of the stove. Above is an example of a software engineer (Mr. Andrews) choosing to experience a kind of pain now (the ietf standards process), for others to experience a kind of pain later (those who use rfc1918 space adopting software implementing this), and for the as112 operators to experience less pain until gradually it is retired. Pain in this universe is absolute and eternal. All you can do is choose for whom it is fair to experience how much of it. Something like the Cyclops in Krull. Choose to get left behind in the field to die peacefully, or get crushed in the stone doors saving your friends. The mechanics of the result is unimportant. The choice is. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgppIJt2I0YiJ.pgp Description: PGP signature
Re: Gothcas of changing the IP Address of an Authoritative DNS Server
On Wed, Dec 14, 2005 at 10:29:52AM -0500, Joe Abley wrote: There are registries that store A records for nameservers that aren't subordinate to the zones they publish. While it'd be probably And for those that don't...some administrators (your predecessor hostmaster? the admin of zones you slave?) work around the problems of lack of cross-zone glue by giving one nameserver's single IP address multiple names, and therefore glue in multiple registries. So it's still wise to look either way. problems; however, see paranoia, above. It's not paranoia. They really are out to get you. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgptcSzecEfwz.pgp Description: PGP signature
North American Shipping Clerks Group
I would like to thank Eric for agreeing so violently with me: We have now established that no pretense is required for a conviction. I suggest we move the remainder of this discussion, What is the law and how can you avoid being prosecuted for funneling 'munitions' to Iraq?, to the North American Shipping Clerks Group mailing lists. If such a group exists. -- David W. HankinsIf you don't do it right the first time, Operations Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins
Re: .iq [ was: Re: Paul Vixie serving ORSN ]
On Fri, Sep 30, 2005 at 08:38:43AM -0400, Eric Brunner-Williams at a VSAT somewhere wrote: It all comes down to pretending a PC is a supercomputer, An ordinary PC, by today's standards average, is defined by US law as a supercomputer, legally a munition (weapon of war). Wether you yourself believe the object defined by the pouplar term supercomputer is required to habitate a substantially larger space, or substantially larger number of computrons is irrelevant. There is no pretense here, just that I suspect you misunderstand that the term 'supercomputer' is being used as a legal term, not the common term you use in casual language. pretending that ordinary Syrians, let alone nuclear weapons proliferating Syrians, didn't, in this period, routinely drive from Damascus to Beruit, That you might be able to buy a cannister of napalm from the grocery store in [Insert random location], doesn't mean the US has to hold all exports of napalm into that location as immune from export controls. Again, there is no pretense here, and there is no need for it. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp0C38nwHSi5.pgp Description: PGP signature
