Re: Should routers send redirects by default?
On Fri, Aug 20, 2010 at 07:49:43PM -0400, Ricky Beam wrote: I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.] I am not sure that is so much of an issue in IPv6. I know that in IPv4 3rd party ICMP redirects were quite common among the kiddies to knock each other off IRC, but ICMPv6 redirect reception in hosts has a number of saves and limitations that mean it should be far less, perhaps not an issue, provided your local network is secure and BCP 38 is in use. For example, an ICMPv6 implementation will not process a redirect from a router that is not the host's current next-hop for the target destination. Because this is a Link-Local Address, an off-link attacker has quite a problem guessing (and on-link attackers are a problem anyway). But I have a different memory of why we first started disabling redirects, back in the day. My memory is that hosts typically implement redirects with /32 routes, with no aggregation, installed upon receiving a redirect message. The ICMP message does not contain any TTL, and none was specified in RFC, so consequently over the lifetime of a device receiving redirects the routing table grows until every redirected destination is enumerated, or the system restarts. The ultimate size of the table reached can be quite large, beyond the scale typically engineered for in a host. Of course, that was back in the day when hosts were typically slower than the LANs they were connected to. So every additional host route installed increased per-packet forwarding overhead and decreased throughput considerably. Although ICMPv6 Redirect messages also lack a (router-advertised) TTL, an examination of [1] leads me to believe they will time out because they are implemented as part of the ND llinfo cache. A stale cache entry (the equivalent of a /128 route with link layer information) will ultimately be cleaned. If the destination is reused later, So it may be that the same conclusion does not hold, except in the unusual condition where a large number of redirects are required over a relatively short period of time (such as devices that have a large number of active sessions with hosts that its routers redirect; web servers, smtp systems...). [1] Li, Q., Jinmei, T., Shima, K., IPv6 Core Protocols Implementation, October 2006. ISBN 13: 978-0-12-447751-3 ISBN 10: 0-12-447751-8 -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgp9VZ5yntiO2.pgp Description: PGP signature
Re: Should routers send redirects by default?
On Sun, Aug 22, 2010 at 10:12:01AM +0930, Mark Smith wrote: o allow an IPv6 router to indicate to an end-node that the destination it is attempting to send to is onlink. This situation occurs when the router is more informed than the origin end-node about what prefixes are onlink. This shouldn't happen very often either, as multiple onlink IPv6 routers should be announcing the same Prefix Information Options in their RAs, and therefore end-nodes should be fully informed as to all the onlink prefixes. ICMPv6 redirects in this scenario would only occur during the introduction of that new prefix information i.e. the time gap between when the first and second onlink routers are configured with new prefix information. It may be true the situations where redirects are required for this are few in number, but I think it is not true that the use of redirects is limited solely to the configuration gap between introducing a new prefix. In NBMA networks, it is said that the nodes will have IPv6 addresses with no covering advertised prefixes (IPv6 Core Protocols Implementation, page 393, just spotted while reading today). Additionally, the typical use of /128 role addresses for services aliased onto lo0 mean the router has a /128 route for the role address to an on-link device, but a covering prefix advertisement would be both futile and inappropriate. I don't necessarily want to say that your conclusion is false, but rather that it seems to me there are more enumerations in the set. -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgpufEv5bMuqI.pgp Description: PGP signature
Re: Should routers send redirects by default?
On Tue, Aug 24, 2010 at 01:02:49PM -0700, David W. Hankins wrote: will ultimately be cleaned. If the destination is reused later, Ah, I forgot to complete this thought in editing. If packets are sent to the destination later (after a cache entry is expired) the host obviously starts over as if there was no redirection. In this way, changes in topology are ultimately discovered, whether the redirection changes or is no longer needed. -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgpWMByeqBdQR.pgp Description: PGP signature
Re: end-user ipv6 deployment and concerns about privacy
On Wed, Aug 18, 2010 at 04:41:56PM -0500, Jack Bates wrote: prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4. This is surprising to me, can you comment on why DHCPv6 TA is being used in this scenario? -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgpTGtJ5BUH5I.pgp Description: PGP signature
Re: ISC DHCP server failover
On Fri, Mar 19, 2010 at 05:10:04PM -0700, Mike wrote: With all due respect and acknowledgment of the tremendous contributions of ISC and you yourself Mr. Hankins, I have to comment that failover in isc-dhcp is broken by design because it requires the amount of handholding and operator thinking in the event of a failure that you explained to us at length is required. Failure needs to be handled automatically and without any intervention at all, otherwise you might as well not have it and I think most network operators would agree. First let me say that I wasn't involved in failover's design, I'm only a sort of maintainer, so the criticism is not offending me in the slightest. :) Failover definitely busied itself with the cross-country, geographically diverse DHCP server situation, hoping that by solving that they are also giving HA, heartbeat-cable types of folks a tool they can also use, although it isn't explicitly designed for that purpose alone. That does tend to leave this community a little under-served and unhappy, which was my motivation for failover features in 4.2 to try and support their needs better (auto partner- down, greater endurance in comms-interrupted). What you describe for an alternative (although I will criticize it slightly in suggesting you are under-estimating DHCP's needs; the question of message delivery is really not relevant) are the building blocks for something I would refer to as DHCP Server Clustering. I fully endorse it. That is a set of separate programs that work together to appear from the outside to be a single DHCP server (as those terms are defined in RFC), and the ways in which you can build-in redundancy and self- healing (self-restarting components, component failures only affect a subset of services, redundant processes that cover gaps in coverage, etc). In short, you're describing one of our key motivations for migrating ISC DHCP to the BIND 10 framework. That gives us a complete set of tools. Within the same rack, you will ultimately be able to implement a single server from all outside observance that is actually implemented in a redundant way across (N+1) systems* or CPU's within one system, while still maintaining a failover ability to tie two such geographically diverse clusters together (not to mention co-habitation with BIND 10's DNS services in the same configuration and monitoring plane) that don't actually have to be clusters if you don't want all that baggage either. So everyone's happy. Unfortunately at the moment we are still collecting sponsors for the DHCP-in-BIND-10 project, and no shovels have been turned. But I'm confident the work will proceed (and if anyone wishes to help as a sponsor or a participant, please contact us! We are in Anaheim this week, and there is also a link in my signature you can click). In the meantime, failover is a tool we have whereas DHCP clustering software is so far only a tool we want to create. * Some objects in the future-mirror may be further away than they appear. -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgp66NKQSsEEU.pgp Description: PGP signature
Re: IPv6 could change things - Was: DMCA takedowns of networks
On Tue, Oct 27, 2009 at 02:05:36PM +, Michael Dillon wrote: But, when IPv6 is a bit more common, there is no need for virtual hosters to share a single IP address between several sites. They may as well use a unique IPv6 address for every single site, even if they are all on the same server. The side effect of this is that it makes the network operator's tool sharper, and able to knock down single sites with a /32 ACL. A /128 you mean. If you look in Apache's httpd/server/vhost.c, you may notice that the server locates addressed virtual hosts using a simple 32-8 bit integer reduction hash, which produces a well balanced hash table in typical virtual server applications (generally these servers get addresses in contiguous blocks). Named virtuals are relegated to an extra hash bucket, essentially placing them all on a single unsorted linear list, which is searched if a by-address match is not found. Probably in the modern day, the additional processing (and system calls) necessary to render a web object into a reply is significantly higher than the overhead to locate a virtual server even at these orders of magnitude, but it's interesting that the software works differently. -- 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 pgp5lDTPDChD6.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Fri, Oct 23, 2009 at 12:50:47PM +1300, Perry Lorier wrote: I've implemented myself a system which firewalled all ARP within the AP and queried the DHCP server asking for the correct MAC for that lease then sent the ARP back (as well as firewalling DHCP servers and the like). It's quite easily doable, and quite reliable. If nodes were to send packets directly when associated to an AP then the 802.11 protocol would fall apart, I've never met an implementation that broke this requirement of the standard. It had not occurred to me to intercept ARP (or ND) as a transition mechanism, that is pretty clever, but the idea of using DHCPv* leasequery as a way to make IP-MAC resolution both secure and unicast is something I've heard many times. I don't know about my peers, but I would be very interested to see an RFC that describes and examines your results. You can of course pretend you're the AP and send a packet if you're wanting to be vicious enough. Yes, of course, that is much simpler. If the attacker can associate with the real wireless network, they can always bridge and provide a rogue AP to insert themselves in the middle. Sometimes in focusing on packet exchanges, we miss the forest for the trees. -- 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 pgpNQAGCnPio4.pgp Description: PGP signature
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 11:12:14AM +1100, Karl Auer wrote: To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means. This does neatly work around the problem; the hosts may now speak to one another. I don't understand this. Could you elaborate? It seems to me that the simplest network imaginable should still operate on link local addresses. To use a link local address, you also have to supply the application with the interface name for it to be used upon. The application has to pass this as an extra argument when opening a socket; it isn't part of the regular gethostbyname/socket/connect. Provided you have applications that have a separate dialog field for the interface name so LL's can be used, you're probably going to be entering in the IPv6 LL address in all its glory. First, you are not going to have LL addresses in /etc/resolv.conf because you can't list interface names there (I think it is the same for other OS's analogues of their nameservers list), and second people are not going to be very well motivated to put LL addresses in DNS because those addresses are not globally applicable; they would have to use DNS views. So it is not really very realistic to expect LL to actually be used except to bootstrap. Maybe it's possible for some proprietary printer or fileshare network stuff to continue working on LL's (or, ironically, routing protocols or DHCPv6 itself), but anywhere else (mail.example.com, contacts.example.com), anywhere real, and the network goes dark. Unless of course it can fall back on native IPv4, or has entered a bogus covering /64. -- 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 pgpK1IOWTvfyQ.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation... In both cases there may still be some wireless adapters that receive bogus packets directly from attackers. And then you bring ND into the question and wonder why you bothered with either RA or DHCP filtering. DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic authentication. The problem however has been the key distribution model. Here it all falls down, and leads to poor deployment. But with DHCPv*, we have a hope that we can secure it if we can solve that last problem (and at least I think we can). So if you accept that as an outcome, one must ponder the question: How long will people accept that a secured DHCPv6 session must rely, in order to function to expectations, upon the unsecurable RA and/or questionably secure SEND? -- 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 pgpf4lygcPQdK.pgp Description: PGP signature
Re: IPv6 Deployment for the LAN
hidden costs. -- 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 pgpfQS8LPaJm9.pgp Description: PGP signature
Re: Where to buy Internet IP addresses
On Wed, May 06, 2009 at 06:57:53AM -0700, David Conrad wrote: Of course, the builders used screen doors and windows for the below-the-waterline openings, but not to worry, the bilge pump equivalent of Moore's Law will undoubtedly save us. Speaking as a builder, I have to say the screen doors were on the plans when I got there. I gather the planners believed they would facillitate use of the ark by hybrid human-acquatic lifeforms that did not exist at the time, nor do they exist today, but were hoped to exist because mermaids and mermen are, like, totally hot. -- 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 pgp2gKH8u0rI2.pgp Description: PGP signature
DHCPv6 PD
On Tue, May 05, 2009 at 02:49:01PM -0500, Jack Bates wrote: Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that? In IA_NA's, there is a (undocumented in RFC 3315) convention to permit a client to supply an IAADDR with a zeroed address. This convention allows the client to supply preferred and valid lifetime hints without knowing a specific address it would like. I see no reason why a similar convention can't take root here; the bottom-most client supplies an IAPREFIX in its IA_PD with a zeroed network number, and the desired prefix length (suppose: /64 for its one downstream interface). The next hop combines the sum total of bitspaces required by its clients and presents a suitable requested size upstream (with memory, and resizing/renumbering as you go). What if the ISP only gave a /60? Then someone gets a STATUS_NoAddrsAvail. -- 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 pgp0jVWYbs56T.pgp Description: PGP signature
Re: Fiber cut in SF area
On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: Just dropping a note that there is a fiber cut in the SF area (I have a metro line down). AboveNet is reporting issues and I've heard unconfirmed reports that ATT and VZW are affected as well. Confirmed VZW ATT; http://cbs5.com/local/phone.internet.outage.2.980578.html Rather widespread general telco outage, the county has deployed extra patrol units in the south bay to compensate for not being able to call 911. Third video link in shows repairs underway. -- 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 pgp3AV5KN6ukx.pgp Description: PGP signature
Re: The Confiker Virus.
On Wed, Apr 01, 2009 at 10:01:29AM -0600, Jason Iannone wrote: What's the virus doing with all of those domain names? Paul Vixie gave a presentation at the IEPG meeting before IETF 74. I don't think the IEPG meeting notes are up yet (they would be very informative if they were)...I don't pretend to be an expert, but my understanding based on that presentation is that the DNS is used for CC of the botnet. Its owner only needs one of those domain names to be registered to give out orders. If they only used one, it would be relatively easy to shut them down. They use so many so that, when the good guys bust in the door and shut down the CC domain/hosting, they can just open up shop somewhere else like nothing happened. Not entirely unlike terrorist cells. -- 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 pgpUtv7oTvhCc.pgp Description: PGP signature
Re: v6 DSL / Cable modems
On Sat, Feb 07, 2009 at 07:51:36PM +1300, Nathan Ward wrote: I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. Close, but it is worth clearing up. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. Most clients default out of the box to accept RA, getting a single address within each prefix indicating automatic address assignment. The ones that do support DHCPv6 will also initiate DHCPv6 services based on RA M and O flags. There are some bugs here and there, but it mostly works. This is all well and good, you are right on these points. However, Jack was referring to a practice of temporary address assignments. In this configuration, a client has one permanent (for as long as they are on that wire) address they use (per prefix, because that is how IPv6 multihomes, so they say) for general purpose and reachability from the outside world (dial in). They also have a range of temporary addresses which are in a state of preferred use, unpreferred use, or validity-timer expiration (again, per prefix, for multi-homing). Each temporary address is allocated based on a re-hash of a previously used seed, and half of the seed bits are not used in the public address (so outsiders can not easily predict what the client's next address will be). The theory is that these temporary addresses enhance privacy, as the client seems to hop from address to address. This seems to ignore application context hints such as cookies and keys embedded in URL's, so to my thinking the point of this is to enhance privacy for spammers or illegal file sharers. Anyway. So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like. Conversely, with DHCPv6, clients that support normal and temporary addresses simply always ask for them; this indicates they possess support. The service determines which type of address to actually provide (one, the other, both, with multiple bindings in either). In this way, all is automated from a central point. The philosophies of design of these two systems are entirely at odds. In RA the client determines what configuration it seeks, placing its own arbitrary demands upon the network, but still heeds some of its vague handwaving. In DHCPv6, the client submits to the network's will, but still has some of its own vague handwaving choices. It is Marxism (turned Socialism) vs Fascism at its root. I hope I have not spent my year's worth of NANOG tolerance for DHCP related discussions with the above. :) -- 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 pgp1JN3RhM7ce.pgp Description: PGP signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
I think this part of the thread is in danger of leaving the realm of operational relevance, so I will treat these as my closing arguments. On Fri, Feb 06, 2009 at 03:48:53PM +0100, Iljitsch van Beijnum wrote: It makes more sense to look at it like this. In the 1990s we had: No, I think that shopping checklist view is exactly the kind of wrong thinking that stunts the dialogue between tools and needs, and has been a cause in IPv6's current disconnect in operational reality. So no, I don't think it makes any sense to look at it like that. It makes the most sense to look at the IPv4 configuration protocols alone as a progression of tools, each built upon what was learned from the prior, and the conclusions that were determined to work best for most of the Internet's operators (neither Appletalk's nor IPX's). These conclusions were proper supersets of previously determined operational needs, and so became a pervasively deployed universal solution. This is a functioning model for tool growth. Shopping checklists only create Frankenstein monsters, stunted half-breeds that serve only their creators. RIP is a routing protocol, not an address configuration protocol. This is a statement whose context predicates that you think I don't know that, which further confers that my intended message has been lost on you. This is far afield from the point! I am predisposed not to correct this, as the message was not intended for you, I hope this is mutually agreeable. :) asking for security problems. Also, whenever you want to put something new in DHCP you must update the client and server SOFTWARE. Because on the This actually is not true, which I have told you before. But I have to admit it is a nice contrived false factoid that supports your a-priori conclusions. My analysis of your further arguments is that you have selected a proper subset of actual Internet operational needs in order to further justify these same conclusions. I will leave it at that. :) -- 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 pgp0OhzlcjfGx.pgp Description: PGP signature
Re: v6 DSL / Cable modems
On Fri, Feb 06, 2009 at 11:50:55AM -0600, Jack Bates wrote: Two routers, 2 default routes. Support for shim6 or other multiple IP What most people do of course is VRRP. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). The net result is that the client uses the default gateway which it used to reach the DHCP server, and so will automatically receive an updated value if that router fails, as part of DHCP lease rebinding (it will reach the server via the alternate router). No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers. P.S. You can also set the DHCP server-identifier on the opposition of the giaddr field contents; so when the client reaches renewal time, if will be able to use the surviving router if its default router has failed (and thus will not have to wait for rebinding). This has further config implications as the server(s) are no longer able to detect the difference in a client's renewal or rebinding, but it can be an effective optimization. -- 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 pgpb1iKtLsD73.pgp Description: PGP signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, Feb 05, 2009 at 11:42:27PM +0100, Iljitsch van Beijnum wrote: On 5 feb 2009, at 22:44, Ricky Beam wrote: I've lived quite productively behind a single IPv4 address for nearly 15 years. So you were already doing NAT in 1994? Then you were ahead of the curve. Ahh, the 90s. No need for NAT yet. http://en.wikipedia.org/wiki/SOCKS The world was smaller then. Or maybe there was just less in it? This is the exact same bull as the /8 allocations in the early days of IPv4. The man is correct: This is class-based allocations all over again. On purpose. After watching class-based allocations crash and burn. One who believes history repeats itself will think that this will only end in pain. If anything, only the timescales change. One who believes themselves to be above the mistakes of the past will of course think this plan is totally without precedent for flaw. Never between these two beliefs shall we meet. I think Ricky and Iljitsch are discovering this. Why do people avoid and resist IPv6... because it was designed with blind ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 networks.) Dooming us to repeating ALL those mistakes again. Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is rarp. DCHP does far more than tell a host was address it should use. Actually it goes further back than rarp; IPv6 RA is actually more closely related to IPv4 ICMP Router Advertisements (itself a very RIP-like way to give only default routes), extended to also carry RIP-like local-prefix routes. Let's just say it's a slightly restricted (feature-limited?) RIP. So, start with that and add RARP- like features with (more complicated) client-based algorithms, and you've got the picture. But yeah, in that the static-RARP-BOOTP-DHCP progression was a dialogue between operators and IETF, IPv6 has basically thrown that dialogue out with the bathwater, and we're having it all over again. Fun! -- 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 pgpTe134pDUbT.pgp Description: PGP signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, Feb 05, 2009 at 05:12:19PM -0600, Jack Bates wrote: Operationally, this has been met from my experience. In fact, all of these items are handled with stateless DHCPv6 in coordination with SLAAC. Stateful DHCPv6 seems to be limited with some vendors, but unless they plan to do proxy-nd, I'm not sure they'll gain much except for end system compatibility. SLAAC fails in the end because you cannot predict what address the client will choose. So it fails in scenarios where enforcing network policy is important. The point of the excercise is that DHCPv4 and DHCPv6 are both supersets of network management needs. RA is a vast subset. Herein lies the rub; you have to implement both anyway because a client can not predict what network(s) it is going to be used in. Nobody wins. -- 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 pgp31Zvpm3F9i.pgp Description: PGP signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, Feb 05, 2009 at 04:30:12PM -0800, Joe Abley wrote: The particular example I've been working with is with a JUNOSe server and an IOS client which, as a solution for business DSL service, seems deployable. Yes! Sorry, I just try to emit a little more skepticism about pervasive client support for DHCPv6 in jubliant encouragements of DHCPv6 operational experiments and deployment. [...] Joe is not entirely wrong. Hooray! :-) I am seriously considering admitting I know you. :) -- 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 pgpnAIGUo35fd.pgp Description: PGP signature
Re: DNS Amplification attack?
On Tue, Jan 20, 2009 at 12:54:32PM -0800, Wil Schultz wrote: Anyone else noticing . requests coming in to your DNS servers? http://isc.sans.org/diary.html?storyid=5713 I was surprised to see 'amplification' in the subject line here, since on my nameservers my replies are of equal length to the queries. A little bit of asking around, and I see that it is an amplification attack, preying on old software. Let me sum up; If you're running 9.4 or later, you will reply to these packets with 45 octet RCODE:Refused replies. 1:1. 9.4 has an allow-query-cache directive that defaults to track allow-recursion, which you should have set appropriately. If you're running 9.3 or earlier, you will reply to these queries out of cache (the root hints), and those replies can be 300-500 octets I think. 1:6-11. So in lieu of keeping a new up-to-date list of IP addresses to filter, as it expands and shrinks, you can greatly reduce your own footprint in these attacks with a quick upgrade. -- 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 pgpr2ptd0spED.pgp Description: PGP signature
Re: What to do when your ISP off-shores tech support
On Wed, Dec 24, 2008 at 09:43:20AM -0800, Jay Hennigan wrote: Matthew Black wrote: I've had difficulties reaching anyone with a brain at my DSL provider Verizon California. Switch to a local ISP with local tech support. Actually, and I know this kind of experience is really subjective, but lately I have been getting better service from residents of India via web-based chat tools than I have been getting from residents of the US via telephone. At the same company. My impression as a customer is that only one of these two individuals genuinely wanted to do or keep the job they were given, and desired to do it well. That's really what you should be looking for, locality is irrelevant. -- 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 pgpOyocNFm1nW.pgp Description: PGP signature
Re: Another driver for v6?
On Thu, Oct 30, 2008 at 03:55:01PM +, Andy Davidson wrote: Do you think that industry should be working to some kind of well supported / worldwide flag day when lots of popular resources add v6 records at the same time ? This is a sound evolutionary tactic lemmings use. =) But I'll take you one step simpler; get the industry to choose a day where it will no longer be acceptable to treat IPv6 like an experimental project. Sometime last year would have been great. If you can do that, then the RRset changes would come naturally afterwards. -- 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 pgpXVKGKfRJn2.pgp Description: PGP signature
Re: Another driver for v6?
On Fri, Oct 31, 2008 at 10:41:01AM -0600, Mike Lewinski wrote: This is a sound evolutionary tactic lemmings use. =) I know this is way OT, but I can't let it pass. The lemming suicide myth was created by a very questionable Walt Disney documentary: This is also way OT, but I was actually thinking more of Lemmings(TM), the video game, as I am not really very familiar with rodents. We've already got sixxs and hurricane electric set as tunnel lemmings, we can get through the IPv4 address shortfall by setting a variety of other ISP's to explode and build bridges... The only thing to iron out is: Who gets to be (golden) parachute lemmings? -- 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 pgpuH5pHYbmyp.pgp Description: PGP signature
Re: Another driver for v6?
On Wed, Oct 29, 2008 at 06:32:31PM -0400, Steven King wrote: Does anyone see any benefits to beginning a small deployment of IPv6 now even if its just for internal usage? It is almost lunacy to deploy IPv6 in a customer-facing sense (note for example Google's choice to put its on a separate FQDN). At this point, I'd say people are still trying to figure out how clients will migrate to IPv6. Which seems like a pretty bad time to still be trying to figure that out, but ohwell. It is at this time more a question of strategic positioning. The kind of thing your boss should be thinking about. Switching your management network to IPv6 single-stack frees up IPv4 addresses (depending on how big your management network is) to use in customer-facing areas, which gives your network longer legs in the projected IPv4 address shortfall. If you get really pressed, you can tunnel your IPv4 network over an IPv6-only backbone, giving you another handful of precious moneymaking IPv4 addresses. Having your backbone and servers 'd (even on separate FQDN's), tested, and ready to go puts you ahead of the curve if clients start rolling out (you can just move your 's around). Starting now on collecting IPv6 peering wherever you peer puts you ahead of the curve in the quality of your network's connectedness, again presuming this IPv6 thing takes off. And of course you need to run your own dog food on internal LANs before you start telling customers these IPv6 address thingies are useful. IPv6: It's kind of like storing dry food in preparation for the apocalypse. -- 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 pgp8GUAktjsmi.pgp Description: PGP signature
Re: Network topology [Solved]
On Wed, Oct 15, 2008 at 08:35:33PM +0200, Colin Alston wrote: Apparently there isn't. Lots of people mentioned other tools, the problem there is they have one thing in common which is polling SNMP. I think it scales badly in general. I was hoping to find a more intelligent way of, I I don't know what scaling parameters you're looking for. The tool I wrote to recursively traverse Cisco CDP caches via SNMP, from ~7 seed routers, autodetected the interconnections of a ~100 node network (back in 1998) in just seconds (I think it was 3, but that was ten years ago). Using SNMP. It didn't strain our P90 it was running on, nor the network. People often do SNMP wrong (one PDU per packet, single-threaded transmitters, etc). Maybe there should be something (I mean like, someone should come up with a standard :P) to trace switches in a path... Problem is I think even then the simple devices won't bother to support it. Or if they do, they'll do it wrong. They can't even get ifDescr right. -- 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 pgphlwK9I0MH7.pgp Description: PGP signature
Re: [Fwd:] Nvidia NICs with duplicate mac addresses
On Fri, Sep 05, 2008 at 01:19:44PM -0400, Robert E. Seastrom wrote: The same DHCP server (ip helper-address blah) serves my office, my home, and the colo. Can you give me an idea of a good heuristic for telling the difference between moving my laptop around and finding MAC address collisions? The theoretically conforming client supplies two pieces of information; Its DHCPv4 client-identifier-option (per RFC 4361), which will be different even on systems with identical MAC addresses (unless you are very lucky). The 'chaddr' BOOTP header contents (its current MAC address), which is a return-address for unicast replies (before the client has an IP address, ARP doesn't work). The DHCPv4 client-identifier tells us it's a specific interface on your laptop, no matter where it boots. Context from the packet (giaddr (relay-agent address on that network), the interface it was received upon) is used in normal DHCPv* operation (since its dawn) to find a broadcast domain. From there, we find subnets on that domain, and dynamic addresses within that subnet that are appropriate. This is how we locate configuration when your laptop connects to different wires in normal operation. The new trick is to detect two clients with the same MAC address, but with different client identifiers, that are active on the same broadcast domain. It's just a simple database lookup to detect a collision. The solution is to: Or are you suggesting that you hand out a MAC address along with an IP address when the client DHCPs and the client then changes it? Precisely. Negotiate a new address in a broadcast reply. I suppose you could just as easily always allocate a MAC dynamically, but this seems invasive. An alternative solution is to deny the client from receiving a config, signalling an error to the operator, so the first client remains operational. But this can have false positives. It'd take years to deploy tho. Many clients today send no identifier and just use their chaddr contents. Their MAC is their ID, so there is no way to detect collisions. Most others send a client-id that is identical to their chaddr contents, which is approximately useless. You'd also be suffering MAC changes on systems that boot multiple operating systems without releasing their previous lease (because the clients send inconsistent identifiers, and even with DUID-based id's, I think this is not going to change). This is in addition to today, where such clients consume multiple IPv4 addresses. Insult to injury. -- 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 pgpC8wJuvfD0z.pgp Description: PGP signature
Re: SLAAC(autoconfig) vs DHCPv6
On Mon, Aug 18, 2008 at 03:42:29PM -0400, Howard C. Berkowitz wrote: If you want to test a resource, be it the end user or an infrastructure interface, how do you know how to foo it (foo being some value of ping, traceroute, look it up in SNMP/NetFlow, etc)? I submit that if you use dynamic assignment of any sort, you really have to have DNS dynamic update, so you can use a known name to query the function that's indexed by address. Otherwise, static addresses become rather necessary if you want to check a resource. That's close. If you use dynamic assignment via DHCP (v4 or v6), then you have a handy database of all the IPv4 addresses assigned and whatever information you want to discern them by (if not by hostname) that was available to the DHCP server at the time of assignment. Strictly speaking, Dynamic DNS isn't even necessary, but it could be reasonably handy (because IPv6 addresses do not pass 'the phone test'). With technologies like SLAAC, tho, you are right. You're going to have to give devices a means to register with the network independently of their IP address allocation, because it only takes one client to Router Solicit to configure multiple clients upon the broadcast Router Advertisement reply. Unless you start sniffing for their neighbor discovery probes (part of SLAAC is to ensure the new address is not already in use), there's no transaction where the resource(s) are assigned. There is quite obviously a key distribution problem with that kind of model, and if you have to manually configure a system to configure itself dynamically, there is a significantly diminished reward. At this point in the excercise, you may as well do what the rest of us in the current SLAAC-only world have done; disable SLAAC and set v6 addresses (and DNS) manually. Welcome to 1985, the era DHCPv4 saved us from. But this leads you back to today's IPv6 operational problem; if you need registered clients, then you can install any DHCPv6 software you can find to get it via either its database or Dynamic DNS (quite a lot of DHCPv6 server software supports Dynamic DNS). But you still wont' have any DHCPv6 clients outside of Vista. This is where the chicken meets the egg on our faces. -- 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 pgplgk5oanCDo.pgp Description: PGP signature
Re: SLAAC(autoconfig) vs DHCPv6
On Mon, Aug 18, 2008 at 12:52:50PM -0700, Scott Weeks wrote: Seeing Howard's quick response saying To try to stay operational about this... makes me realize I may have inadvertently invited a religious flame fest. I guess that rules me out. :( Please! Operational content and hands-on experiences only to the best of your ability. I want to learn from this, not delete the whole thread. The short and simple Where we are Today is that the only DHCPv6 clients you are likely to encounter in your networks are either DOCSIS modems or Windows Vista. So if you are going to deploy IPv6 to customers, you are generally going to use SLAAC today, and all the headaches that entails. Although there's now an option for domain name servers and search paths in router advertisements, you'll have an even worse time finding client support. So the current state of the art is to run dual stack so that DHCPv4 can reliably provide IPv4 nameservers, which you can use to find records, enabling SLAAC'd IPv6 access. For extra credit you can supply IPv6 nameserver information statelessly, but then you're only complicating things even more. One of the little talked about issues is the potential support cost when a customer wants to resolve some issue. My web isn't working. Are you using v4 or v6? Netscape. And of course it's a non-starter for anyone who needs to assign and approve the client's configuration, let us imagine because of differing product levels, rather than letting them pick whatever they feel like. I think the above can reasonably be said to be an accurate, if brief, depiction of current IPv6 operations. If you wanted to gaze into the future, I think that isn't precisely possible without welcoming the related philosophical (not religious) debates. -- 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 pgpDzKuLq36CU.pgp Description: PGP signature
Re: SLAAC(autoconfig) vs DHCPv6
On Mon, Aug 18, 2008 at 11:11:16PM +0200, Iljitsch van Beijnum wrote: Forget about it on XP, but it's in Vista. You can add it to BSD/Linux without too much trouble (are there good, bugfree implementations for those yet?) If anyone is aware of any bugs in ISC dhclient -6, please submit them to [EMAIL PROTECTED] -- 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 pgpjMivi6e3Oj.pgp Description: PGP signature
Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?
On Thu, Jul 24, 2008 at 09:56:32AM -0500, Joe Greco wrote: MY move? Fine. You asked for it. Had I your clout, I would have used this opportunity to convince all these new agencies that the security of the Internet was at risk, and that getting past the who holds the keys for the root zone should be dealt with at a later date. Get the root signed and secured. Get the GTLD's signed and secured. Give people the tools and techniques to sign and secure their zones. Focus on banks, I admit readily that I am not one of the 'dns guys' around here, but I have been watching with some interest for a few years now, and have more or less become convinced that the players involved are willing to tolerate, downplay, or even flat out ignore a great deal. Except losing their own relevance. This is cherished above all. The only times I have seen these parties move is when it has been realistically threatened. So in brandishing this world event as like a holy sword of fire to smite some nefarious beaurocracy, there is no danger its strike will drain any relevance. The band aid fix is there. Their relevance is saved along with all of our businesses. There is still plenty of time to argue about who gets the keys. Who gets nearly the entire pot of this magical relevance ambrosia? It wouldn't work. Paul's booming voice would serve only to make him hoarse. The strike only lands for effect if you withold the band aid fix, which simply can not be done in this case either. I'm only really aware of two ways to reduce the relevance of the root and its children (I did say I am not a DNS guy). You can join one of the alternate roots, which I do not recommend. Or you can sign your zones using a DLV registry. If DLV registries became 'de rigeur', it would effectively halve the root and by extension the GTLDs' relevance. I do not believe they will permit this to come to pass. Provided they did, we would win anyway, as signing zones itself would have become the norm. -- 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 pgpRv61cfWWHq.pgp Description: PGP signature
Re: DHCPv6 and stateless autoconf, was: NANOG 40 agenda posted
On Wed, May 30, 2007 at 09:10:02PM +0200, Iljitsch van Beijnum wrote: If you like DHCP, fine, run DHCP. But I don't like it, so please don't force _me_ to run it. OK, I can (and do) live with that. I tend to prefer technical reasons to choose a technology (and in so doing, hope to avoid throwing spaghetti at the wall), but if you'd rather base your decisions on what you like (or not), you have every right to do so. In my opinion there are a bulk of technical merits that place DHCPv6 ahead of RTadv. I don't like either protocol, but they're what we've got. -- 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 pgpwl5LeW7oiR.pgp Description: PGP signature
