Re: [time-nuts] Fwd: FW: Memorial service for David Mills
On Thu, 7 Mar 2024 at 14:16, wrote: > On 2024-03-07 04:10, Dave Hart via time-nuts wrote: > > [...] this coming Monday at 3:00pm local time. With Sunday's leap > > ahead in local time, that's 17:00 UTC, Noon US Pacific time. > > Thank you for this notice. However, if this is 3:00 PM (1500) EDT that's > 1900 UTC. > > Is that interpretation correct? > Yes, thanks for the correction. I clearly shouldn't do time math in public. To further confuse matters, I took the option in Gmail's triple-dot "more" composition menu to "Set up a time to meet" hoping it would include a useful calendar attachment or at least a link to include the event in a recipient's Google Calendar. As received by another account of mine, it was neither, and the text had the wrong time (13:00 UTC) despite having the correct time in my Google Calendar, which is set to show both UTC and Eastern time. Local time can be tricky, and I'm glad NTP generally shrugs and leaves that problem to others.
[questions] Fwd: FW: Memorial service for David Mills
The University of Delaware is hosting a memorial service for "Father Time" David Mills this coming Monday at 3:00pm local time. With Sunday's leap ahead in local time, that's 17:00 UTC, Noon US Pacific time. There will be a live stream: https://sites.udel.edu/udlive/mills/ Cheers, Dave Hart Dr. David L. Mills Memorial Service 11 Mar 2024, 13:00 – 11 Mar 2024, 16:00 (GMT+00:00) Coordinated Universal Time Mitchell Hall Memorial Service for David MillsMonday, March 11 | 3 p.m. Mitchell Hall David Mills, a retired University of Delaware professor known as the “father time” of the Internet, *passed away* <https://udel.us11.list-manage.com/track/click?u=5a1d5390cbd9e87290b0346fe=c862ff63c9=288a146672> on January 17, 2024. Dr. Mills is survived by his wife Beverly Mills, his daughter Eileen Schnitzler, his son Keith Mills, and his brother Gregory Mills. You’re invited to join the Mills family and the University of Delaware College of Engineering for a secular memorial for Dr. David Mills at 3 p.m. on March 11 in Mitchell Hall. Dr. Mills, who held appointments in UD’s College of Engineering in the departments of electrical and computer engineering and computer and information sciences, is most well-known for developing the network time protocol, the system that allows computers on a network to synchronize their time. Along with being a pioneer of the early Internet, he is remembered for his curiosity, knowledge and enthusiasm. The impact of Dr. Mills’ work was recognized by several professional societies—Dr. Mills was a member of the National Academy of Engineering, the Internet Society (ISOC), the American Association for the Advancement of Science and he was a Fellow of both the Association for Computing Machinery and the Institute of Electrical and Electronic Engineering. Outside of his career’s many achievements, Dr. Mills’ hobbies included running an amateur radio station (W3HCF) out of his home in Newark. He was also a member of the American Radio Relay League, the Radio Society of Great Britain and the Amateur Satellite Organization. *Please let us know if you’ll attend.* <https://udel.us11.list-manage.com/track/click?u=5a1d5390cbd9e87290b0346fe=967bc954b9=288a146672> *Read the New York Times obituary* <https://udel.us11.list-manage.com/track/click?u=5a1d5390cbd9e87290b0346fe=9786453fb4=288a146672> *Copyright © 2024 University of Delaware College of Engineering, All rights reserved.* You are receiving this email message as a member of the University of Delaware College of Engineering community. *Our mailing address is:* University of Delaware College of Engineering 102 DuPont Hall Newark, Delaware 19716
Re: FYI Netflix is down
On Mon, Jul 9, 2012 at 15:50 UTC, Rayson Ho wrote: There are also bugs from the Netflix side uncovered by the AWS outage: Lessons Netflix Learned from the AWS Storm http://techblog.netflix.com/2012/07/lessons-netflix-learned-from-aws-storm.html We continue to investigate why these connections were timing out during connect, rather than quickly determining that there was no route to the unavailable hosts and failing quickly. potential translation: We continue to shoot ourselves in the foot by filtering all ICMP without understanding the implications. Cheers, Dave Hart
Re: F-ckin Leap Seconds, how do they work?
On Wed, Jul 4, 2012 at 17:22 UTC, Scott Howard wrote: On Wed, Jul 4, 2012 at 8:50 AM, Jimmy Hess mysi...@gmail.com wrote: The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump. Unless I'm mis-reading things, it already does - of sorts. I hope anyone implementing systems that depend on minutae of leap seconds does not rely solely on your reading, but actually tests by inconveniently setting their clock and ntpd leapfile to actually insert a leap second. According to the ntpd website ( http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499) : That FAQ is woefully out of date. http://support.ntp.org/ has more current information. The best reference for a given ntpd version is the html docs included in the tarball for that version. Some widely-used versions' html documentation is archived at http://doc.ntp.org/ *The theory of leap seconds in explained in Q: 2.4.. In reality there are two cases to consider: If the operating system implements the kernel discipline described in Section 5.2, ntpd will announce insertion and deletion of leap seconds to the kernel. The kernel will handle the leap seconds without further action necessary. But exactly how it handles it is up to the kernel. Linux and FreeBSD essentially step the clock backward 1s at 23:59:60.0 UTC. At least one system (I believe it was NetBSD or OpenBSD) instead stalls the clock for 1s, though each reading of the clock during that period is greater than the prior, the delta is microscopic and not related to elapsed time within that second, but simply preserves ordering of events. Dr. Mills attempted to exhort kernel developers to implement leap seconds while keeping the system time ever-increasing, but that advice was largely ignored because of implementation difficulty. For example, when first considered, NTP kernel extensions had microsecond precision. The approach of adding a tiny amount with each reading would open the system up to problems if apps could read the clock more than 1 million times during the leap second. It's also ugly for a SMP kernel to maintain global state on the last clock reading across processors. Most systems offer a monotonic alternative to the wall clock, typically implemented as an uptime counter in nominal SI seconds (nominal as defined by hardware, as the monotonic clock is _not_ disciplined by ntpd or affected by steps (setting the wall clock to a particular value). Look for CLOCK_MONOTONIC in the documentation of clock_gettime. There are also interval-only timer facilities like timer_settime. The tools are at hand for those who understand the implications of clock steps (which can occur under circumstances other than leap seconds). If the operating system does not implement the kernel discipline, the clock will show an error of one second relative to NTP's time immediate after the leap second. The situation will be handled just like an unexpected change of time: The operating system will continue with the wrong time for some time, but eventually ntpd will step the time. Effectively this will cause the correction for leap seconds to be applied too late. * This is the historic behavior of ntpd, but after years of complaints, it was changed. ntpd 4.2.6 and later step the clock backward 1s at the scheduled insertion if using the daemon loop discipline (as opposed to the kernel loop discipline). Linux does implement the kernel discipline (via ntp_adjtime), so the first option is what normally happens. However you can disable this with an ntpd config option (disable kernel) or via ntpdc at which point I'm presuming it will fall back to the second option. The second option still gives you a step, but using the -x option to NTPD will slew this step, giving a gradual correction to the 1 second difference. That is incorrect. -x is often misunderstood -- it does not disable stepping entirely, it raises the step threshold from 0.128s default to 600s. When ntpd synchronizes the clock and determines the offset exceeds the step threshold, the clock is stepped to the correct time. So long as you manage to keep your clock within 10 minutes of correct, -x isn't terribly different from disabling steps, but that's not what it does. In particular, when ntpd using the daemon loop implements a leap second by stepping the clock backward one second, the step threshold (and hence -x) are not a decision factor -- the step is taken. Cheers, Dave Hart
Re: strat-1 gps
On Tue, Jun 26, 2012 at 9:11 PM, Majdi S. Abbas m...@latt.net wrote: On Tue, Jun 26, 2012 at 04:33:35PM -0400, Robert E. Seastrom wrote: Word around the campfire is that the 18x is jittery compared to the 18. The 18x is much worse than the 18LVC. Thankfully I still have 2 18LVCs... but that said, given the hockey puck design, and that Randy already has an antenna, I wouldn't recommend this approach anyway. It's really only suitable next to a window, or in a short, wooden structure. I agree the Garmin GPS 18x LVC solution is only appropriate near a window, or in a short wooden structure. David J. Taylor's experience was the older GPS 18 LVC had a substantially less sensitive receiver, so that his needed to be mounted outside, while his 18x LVC works inside. The area where 18x LVC underperforms the 18 LVC is the jitter of the timing of its NMEA output relative to the leading edge of the PPS. Configured correctly, this should matter very little, and only transiently at startup where ntpd first uses the NMEA end-of-line timestamp (possibly fudged to bring it closer to the top of second) to number the seconds before engaging the PPS. I don't recommend attempting to use any NMEA source without PPS. With it, I don't understand why Majdi finds the 18x LVC much worse. The 18x is a number of years old at this point. Newer GPS receivers (such as the Sure GPS evaluation kits at around $30) are likely to be much more sensitive. I've heard reports of them working in basements and in office buildings 20 or more feet from a window. Also, we've got a leap second pending, and at least the 18LVCs...do not appear to handle those gracefully. Mine freaked out pretty badly in 2008 and had to be reset and reconfigured. I've also seen them lose their configuration (which has to be reset using a Garmin utility.) For this reason I can't recommend running them unattended. There was a bug in early firmware versions of the GPS 18x LVC that could result in the device wedging until you either left it unpowered long enough to drain its battery/capacitor and thereby clear its configuration, or cracked it open to achieve the same, or (as many did) exchanged it with Garmin for a replacement. I believe that bug was first fixed in the 3.20 or 3.30 release, but one of those made the NMEA timing even worse, sometimes causing NMEA sentences to continue past the next top-of-second that could have fit easily in one second if not so delayed. The NMEA timing was improved in the 3.70 firmware, which I recommend all GPS 18x LVC + ntpd users upgrade to, particularly those using 3.20 or earlier. The change history included with the 3.70 firmware doesn't completely align with my recollection. There's no mention of fixing the bricking bug I mentioned. The closest likely mention is of a 3.60 fix: Version 3.50 to 3.60 1. Fixed factory firmware flash capabilities. It does confirm the NMEA timing fix for 3.70, on the other hand. Cheers, Dave Hart
Re: LinkedIn password database compromised
On Thu, Jun 21, 2012 at 12:56 PM, Rich Kulawiec r...@gsp.org wrote: On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: (on the use of public/private keys) The leaks stop immediately. There's almost no value in a database of public keys, heck if you want one go download a PGP keyring now. It's a nice thought, but it won't work. There are two large-scale security problems which prevent it from working: 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, but any estimate of this population under 100M should be laughed out of the room. Plausible estimates are now in the 200M to 300M range. Any private key present on any of those is accessible to The Bad Guys whenever they can trouble themselves to grab it. (Just as they're already, quite obviously, grabbing passwords en masse.) 2. Pre-compromised-at-the-factory smartphones and similar. There's no reason why these can't be preloaded with spyware similar to CarrierIQ and directed to upload all newly-created private keys to a central collection point. This can be done, therefore it will be done, and when some security researcher discovers it, the usual excuses and justifications will be made by the designated spokesliars for the companies involved... which will of course keep right on doing it, albeit perhaps with more subterfuge. Problem #1 has been extant for ten years and no (meaningful) progress whatsoever has been made on solving it. Problem #2 is newer, but I'm willing to bet that it will also last at least a decade and that it will get worse, since there are substantial economic incentives to make it so. In both cases, the evildoers may only gain access to a passphrase-protected private key. That doesn't help if the private key is generated on a compromised system, but it helps if the system is compromised after the private keys are generated, or if the private key is generated elsewhere and loaded onto the compromised system. And it doesn't help if the passphrase is easily guessed. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 20, 2012 at 8:44 AM, Masataka Ohta wrote: Because we still have enough IPv4 addresses, because most users are happy with legacy NAT and because some people loves legacy NAT, there is not much commercial motivation. Sure, there are folks out there who believe NAT gives them benefits. Some are actually sane (small multihomers avoiding BGP). You stand out as insane for attempting to redefine transparent to mean inbound communication is possible after negotatiation with multiple levels of NAT. However, it does not invalidate end to end NAT as a counter argument against people insisting on IPv6 so transparent with a lot of legacy NAT used by people who loves it. That is, end to end transparency can not be a reason to insist on IPv6. It certainly is, for those of us not arguing by redefinition. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 20, 2012 at 11:05 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Dave Hart daveh...@gmail.com Sure, there are folks out there who believe NAT gives them benefits. Some are actually sane (small multihomers avoiding BGP). You stand out as insane for attempting to redefine transparent to mean inbound communication is possible after negotatiation with multiple levels of NAT. However, it does not invalidate end to end NAT as a counter argument against people insisting on IPv6 so transparent with a lot of legacy NAT used by people who loves it. That is, end to end transparency can not be a reason to insist on IPv6. It certainly is, for those of us not arguing by redefinition. Ah, you're on the I should be required to allow direct outside connection to my interior machines if I want to be connected to the Internet crowd. Not quite. I'd go for I should be able to permit direct outside connection to my interior machines via stable IPv6 prefix, or it's not really the Internet to me. Packet filter to your heart's content. 1:1 NAT your clients if you believe breaking connectivity is in your interest. Cheers, Dave Hart
Re: Article: IPv6 host scanning attacks
On Wed, Jun 13, 2012 at 6:52 AM, Fernando Gont ferna...@gont.com.ar wrote: Folks, TechTarget has published an article I've authored for them, entitled Analysis: Vast IPv6 address space actually enables IPv6 attacks. The aforementioned article is available at: http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-space-actually-enables-IPv6-attacks published and available are misleading at best. The article is teased with a sentence and a half, truncated by a demand for an email address with tiny legalese mentioning a privacy policy and terms of use that undoubtedly would take far longer to read than Gont's valuable content. (FWIW, it's a human-readable version of the IETF Internet-Draft I published a month ago or so about IPv6 host scanning (see: http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning)) I guess I'll take a look at this to see what you're smoking. You can get news about this sort of stuff by following @SI6Networks on Twitter. news in quotes is appropriate given it's really eyeball harvesting for marketing purposes. Cheers, Dave Hart
Re: EBAY and AMAZON
On Wed, Jun 13, 2012 at 5:36 PM, Barry Shein b...@world.std.com wrote: On Tue, Jun 12, 2012 at 11:44:44AM +, Jamie Bowden wrote: While MS may be a favorite whipping boy, let's not pretend that if the dominant OS were Apple or some flavor of *nix, things would be any better. That assumes the security architectures of all these OS's is similar which is simply not true. You're right. Windows has an architecture that's easier to secure, with auditing, ACLs, and capabilities (privileges) part of every NT-derived release. This means everything interesting doesn't have to be root, for which there is no equivalent in Windows -- no magic user which bypasses access checks. There have been security flaws in Microsoft OS's which led to the spread of malware which would have been almost impossible on any unix-like operating system. One of the biggest problems was creating the first and often only user on MS systems with administrator privileges allowing any piece of software they ran to do anything on the system. Is it not common to install unix-like operating systems similarly, with setup completed after a root password is chosen but before any human-named accounts are created? I'm not impartial, I once worked for the architect of NT's security. Discount my opinion appropriately. My opinion is 20 years of hardening have likely made Windows a tougher nut to crack than other mass-market OSes. It could hardly be otherwise -- there have been large piles of money fueling a free market in 0-day Windows exploits for many years now. Windows has grown over that time, of course, and more code means more holes, but other OSes have been growing as well. Meanwhile, the most security-sensitive parts of Windows have slower to change and grow. Yes, Windows evolved from an essentially security-ignorant single-user environment. Unix evolved from an essentially security-ignorant multiuser environment. The baseline of unix security with magic root, setuid apps, and primitive access permissions are nonetheless inferior to the baseline of NT-derived Windows. There are varying degrees of ACL support in some unix-like systems, and wide support for capabilities that allow services to start as a non-root user, or drop root after starting as such. There is not, across the POSIX world, a strong security infrastructure that can be relied on to be universal. On the other hand, with the death in the wild of the Windows 9x/ME house of cards, today Windows does provide that universal security infrastructure. Unix systems can be secured. So can Windows systems. No OS can simultaneously provide lazy users with power tools and completely protect those users from self-injury. Security costs overhead for too-often no perceived benefit until someone gets hurt. When you are forced to deal with it, it's nice to have the best in class infrastructure under your feet. Cheers, Dave Hart
Re: Article: IPv6 host scanning attacks
On Wed, Jun 13, 2012 at 5:42 PM, Fernando Gont wrote: On 06/13/2012 02:28 PM, Dave Hart wrote: The aforementioned article is available at: http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-space-actually-enables-IPv6-attacks published and available are misleading at best. It is not. Just scroll down the page, and you'll find the whole article. -- it was easy to talk crap than to do that, right? Yes, I'm an idiot for believing what I read on that site: Requires Free Membership to View Of course I should have expected that means scroll past me and the page of whitespace to view. (FWIW, it's a human-readable version of the IETF Internet-Draft I published a month ago or so about IPv6 host scanning (see: http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning)) I guess I'll take a look at this to see what you're smoking. I find it amazing the number of people that will talk crap when one publishes something when compared to the number of people that provides technical comments or criticism (even if it's you're completely wrong because of this and that). The draft and the article raise valid points about the predictability of widely-used MAC-derived IIDs, but it does not in any way justify the headline Analysis: Vast IPv6 address space actually enables IPv6 attacks. Whomever wrote that should share their stash. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 13, 2012 at 4:23 AM, Masataka Ohta wrote: I just need a UPnP capable NAT to restore the end to end transparency. You're not restoring transparency, you're restoring communication after stateful reconfiguration of the network for each service. It is not transparent when you have to negotiate an inbound path for each service. Even for apps that work today through local NATs, the future is dim. Increasing use of carrier NAT will force apps to additionally try Port Control Protocol to overcome evolving IPv4 brokenness. UPnP is inadequate for carrier NAT due to its model assuming the NAT trusts its clients. When TCP headers are being rewritten, it's a strong hint that transparency has been lost, even if some communication remains possible. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, Jun 7, 2012 at 8:42 PM, Ricky Beam jfb...@gmail.com wrote: On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer ka...@biplane.com.au wrote: c) Similarly, ND (the direct equivalent of ARP) goes only to solicited node multicast addresses, ARP goes to every node on the link. Effectively the same as broadcast in the IPv6 world. If everyone is running IPv6, then everyone will see the packet. (things not running ipv6 can filter it out, but odds are it'll be put on the cable.) Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet to the OS. With ND, only those nodes sharing the same last 24 bits of the IPv6 address indicate the packet up the stack. The rest of the IPv6 nodes filter the multicast in the NIC. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, Jun 7, 2012 at 10:14 PM, Karl Auer ka...@biplane.com.au wrote: On Thu, 2012-06-07 at 21:07 +, Dave Hart wrote: Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet to the OS. With ND, only those nodes sharing the same last 24 bits of the IPv6 address indicate the packet up the stack. The rest of the IPv6 nodes filter the multicast in the NIC. Still not quite correct :-) The filtering is done by a MLD-aware switch, which will send multicast packets only to nodes that are listening to the appropriate multicast group. The filtering you describe is pretty much what ARP does - ALL nodes receive the packet, all but one ignore it. It depends on the platform whether the CPU that does the ignoring is just in the NIC or is in the node itself. Karl, you seem to fail to understand how ethernet NICs are implemented in the real world. Ignoring the optional (but common) promiscuous mode support and various offloading, IPv4 ARP is sent as ethernet broadcast and the NIC hardware and driver is in no position to filter -- it must be done by the IP stack. In contrast, ND is sent as ethernet multicast which are filtered by receivers in hardware. Whether or not the switches are smart enough to filter is an implementation decision that has no bearing on the requirement to filter in the NIC hardware. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, Jun 8, 2012 at 12:48 AM, Karl Auer ka...@biplane.com.au wrote: Yes - whether with ARP or ND, any node has to filter out the packets that do not apply to it (whether it's done by the NIC or the host CPU is another question, not relevant here). It is relevant to the question of the scalability of large L2 networks. With IPv4, ARP presents not only a network capacity issue, but also a host capacity issue as every node expends software resources processing every broadcast ARP. With ND, only a tiny fraction of hosts expend any software capacity processing a given multicast packet, thanks to ethernet NIC's hardware filtering of received multicasts -- with or without multicast-snooping switches. The original post posited that ND could cause as much traffic as ARP. My point is that it probably doesn't, because the ND packets will only be seen on the specific switch ports belonging to those nodes that are listening to the relevant multicast groups, and only those nodes will actually receive the ND packets. In contrast to ARP, which is broadcast, always, to all nodes, and thus goes out every switch port in the broadcast domain. This is pretty much the *point* of using multicast instead of broadcast. I agree.
economic value of low AS numbers
AS path geeks: At the risk of invoking ire and eliciting comparisons to the widely-reviled and growing practice of selling IPv4 addresses, I'm wondering if anyone has sold legacy AS numbers for quick cash. For example, NASA has AS23 among others, and does not use 23. Could they help fund a Mars mission study or two by offering it to the highest bidder? Or would they be lucky to top the $500 ARIN charges for a 32-bit ASN? How about AS1? Level3 uses a different AS. There's one nonpaying customer advertised from AS1, and despite their historical involvement creating the first predecessor of the internet, I bet DoD Network Information Center would be willing to use a different AS for the single prefix advertised by 1 now, if Level3 asked them nicely. Is Level3 leaving money on the table? I looked a bit for any transfer or change policy that might apply without success. Given these are legacy assignments, I have a feeling the POC could be changed without merger or acquisition, and I bet the AS descriptive name could be as well. I know I'd personally find a low AS number worth a pretty penny, if I could find a willing seller. I recognize there's no practical shortage of AS numbers. BGP's preference for low AS numbers doesn't come into play much. On the other hand, a low AS number can't hurt at the human level when negotiating peering or attracting customers. Cheers, Dave Hart
Re: economic value of low AS numbers
On Thu, Nov 17, 2011 at 15:22, Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Nov 17, 2011 at 02:53:26PM +, Dave Hart wrote: I recognize there's no practical shortage of AS numbers. BGP's preference for low AS numbers doesn't come into play much. On the other hand, a low AS number can't hurt at the human level when negotiating peering or attracting customers. I think you are confusing a low ASN with a low router ID, or maybe low neighbor IP address. For a refresher, see: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml A low ASN has no technical value, as far as I know. I am exposed! I have never connected to a router that wasn't a looking glass. I am not worthy... I did try to hide that fact by doing a little research. I was fooled by: Prefer the route learned from the BGP speaker with the numerically lowest BGP identifier and (mis)interpreted BGP identifier as ASN. Socially perhaps some folks give additional respect/envy to those with low ASN's. There's an old joke in the peering community, ASN 3 digits, peer with them. ASN with 4 digits, think about peering with them. ASN with 5 digits, forget it. However, I do believe it's just a joke, I'm sure more folks peer with Akamai (20940) than with NASA (24). That's both funny and helpful, thanks. Dave Hart
Re: economic value of low AS numbers
On Thu, Nov 17, 2011 at 18:55, Keegan Holley keegan.hol...@sungard.com wrote: I suppose I can't argue with that, but anyone technical enough to know what an AS is should know better. Also, would it really count? What if I opened a small ISP in some carrier hotel and paid 1000 bucks for AS 1. I'm not sure I'd want to sign a contract with someone dumb enough to think I was the first company on the internet. Did you intend to say the first autonomous system number assigned for use on ARPAnet? Pedantically yours, Dave Hart
Re: economic value of low AS numbers
On Thu, Nov 17, 2011 at 19:08, David Conrad d...@virtualized.org wrote: whois -h whois.arin.net 42 RFC 943: 42 THINK-AS [BJN1] [BJN1]Bruce Nemnich TMC b...@mit-mc.arpa I have no idea which registry was maintaining AS number registrations when AS42 changed hands. I suppose it's possible the current registrant acquired or merged with whatever entity THINK refers to, but I doubt it, so it seems likely at least at one time transfers were reflected in updated registrations. I bet Douglas would have been tickled. Cheers, Dave Hart
Re: economic value of low AS numbers
On Thu, Nov 17, 2011 at 21:11, Robert E. Seastrom r...@seastrom.com wrote: Jeffrey Ollie j...@ocjtech.us writes: On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth j...@baylink.com wrote: The real question is whether it was issued after HHGTTG. HHGTTG first appeared on the BBC in 1978. Thinking Machines Corporation was formed in 1982. As far as I can tell the first BGP RFC is 1105 and was published in 1989. http://tools.ietf.org/html/rfc827 AS42 was assigned after publication of RFC 923 (Oct 1984) and no later than the superceding RFC 943 (April 1985). AS numbers definitely predate BGP. AS1 was assigned by or before RFC 820 (Jan 1983). EGP was RFC 827 (Oct 1982). Presumably the development involved informal assignment of at least test AS numbers. Cheers, Dave Hart
Re: Arguing against using public IP space
On Wed, Nov 16, 2011 at 20:38, Ray Soucy r...@maine.edu wrote: I would go as far as to argue that the false sense of security provided by NAT is more dangerous than any current threat that NAT alone would prevent. Agreed, and I don't think that's going far at all. My opinion is _both_ stateful firewalls and NATs have been responsible for providing cover for those who fail to secure their endpoints. Yes, dropping a choke point in front of X hosts is X times easier than securing the X hosts. No, it didn't secure X hosts. Outside is dangerous, inside is trusted is the root of much current evil. Breaking end-to-end and encouraging everything that needs it to jump through ugly hoops such as UDP NAT traversal or carrying all sorts of non-HTTP over 80 and 443 has made it harder to secure networks, not easier. Cheers, Dave Hart
Re: routing issue for verizon dsl customers in western massachusetts
On Thu, Sep 15, 2011 at 20:52 UTC, Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Sep 15, 2011 at 4:13 PM, Steve Bohrer skboh...@simons-rock.edu wrote: Traceroutes from Brian's house show that for our blocked hosts, the users don't get beyond Verizon's NAT. I wasn't aware verizon implemented CGN already... way to be a 'first mover' in this field verizon! I am betting they have not. FAILS: Tracing route to wilbur.simons-rock.edu [208.81.88.15] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 192.168.10.1 2 1 ms 1 ms 1 ms 192.168.1.1 3 53 ms 104 ms 116 ms 10.14.1.1 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. Here's a trace to the same destination from a Verizon residential DSL on Maryland's Eastern Shore: Tracing route to wilbur.simons-rock.edu [208.81.88.15] over a maximum of 30 hops: 11 ms1 ms1 ms 192.168.201.1 225 ms25 ms24 ms 10.31.8.1 338 ms99 ms78 ms at-4-3-0-1712.sal-core-rtr1.verizon-gni.net [130.81.136.122] 426 ms26 ms26 ms so-0-0-0-0.sal-core-rtr2.verizon-gni.net [130.81.18.247] 594 ms31 ms31 ms 130.81.20.238 632 ms32 ms32 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73] 732 ms33 ms31 ms te2-3.ar6.DCA3.gblx.net [64.215.195.113] 833 ms33 ms32 ms xe6-2-0-10G.scr2.WDC2.gblx.net [67.16.136.197] 937 ms38 ms38 ms so2-2-0-10G.scr2.NYC1.gblx.net [67.17.95.102] 1043 ms44 ms44 ms pos9-0-2488M.cr2.BOS1.gblx.net [67.17.94.157] 11 244 ms 200 ms 204 ms pos1-0-0-155M.ar1.BOS1.gblx.net [67.17.70.165] 1250 ms51 ms50 ms 64.213.79.250 1349 ms50 ms48 ms wilbur.simons-rock.edu [208.81.88.15] 192.168.201.1 is the router behind the bridged ADSL CPE which terminates the customer PPPoE. 10.31.8.1 is RFC 1918, but is not a NAT. I know from various test my crappy broadband sites that the only drain bramage on the provider side of the link is routine consumer-class port blocking (SMB networking, SQL, and of course port 80 so the mothe#@#$rs can charge extra for business with static IP and unblocked http). At least https works. Looking at Brian's trace above, I can't help wondering if the client is 444'd, but not due to CGN/LSN. Could both 192.168.10.1 and 192.168.1.1 be on-premises, with 192.168.1.1 terminating PPPoE? The latencies seem to confirm. It is possible it's only a single level of NAT on .1.1, with more-respectable routing by .10.1... Cheers, Dave Hart
Re: dynamic or static IPv6 prefixes to residential customers
On Wed, Aug 3, 2011 at 20:38 UTC, Jay Ashworth j...@baylink.com wrote: From: Owen DeLong o...@delong.com Did I mention I haven't implemented v6 yet? :-) No, you didn't. Perhaps you should spend some time learning about it before you opine on how it should or should not be implemented. Perhaps. But that's a SHOULD, not a MUST; it's possible to make useful observations without having every single implementation detail, quite often. It's also possible to demonstrate you're talking out your ass with IPv4 assumptions about IPv6 issues in front of a few thousand people who aren't ignorant of IPv6. Cheers, Dave Hart
Re: best practices for management nets in IPv6
On Mon, Jul 18, 2011 at 13:12, Tim Franklin t...@pelican.org wrote: You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default. In the context of addresses I'm using to manage kit, having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :( Remember, every interface has multiple addresses in IPv6. While I don't know if Linux behaves similarly, for Windows, the privacy address is primarily used for outbound connections. The MAC-derived IPv6 address is also still active, and is the one registered automatically in DNS, so you would still reach your kit via stable addresses (well, as stable as the physical network interface). Cheers, Dave Hart _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: Emulating ADSL bandwidth shaping
On Tue, May 4, 2010 at 08:54 UTC, Raymond Dijkxhoorn wrote, quoting Patrick: For emulating cable traffic, latencies (in the USA) will be about 60-80ms to typical sites. [...] For DSL, I seem to recall latency being about 90-110ms (note, I haven't used DSL in many years). [...] The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor 4... Either you're looking only at the loop contribution, or you're in the SF bay area and nearly every typical site is available locally. Here in the relatively backwater Seattle suburbs, unless it's served by Microsoft or a content distribution network, there are substantial latencies to typical sites. To make it concrete I used Windows ICMP tracert against a few sites from both cable and DSL in the Seattle suburbs. First from a consumer-grade cable offering: http://pastebin.com/TGc6xsHk Then from a business-class telco DSL (complete with more than 1 static IP, someone tie me down lest my soul escape my body from sheer joy!): http://pastebin.com/DMrsiUQf Note I made no attempt to ensure I was tracing to the same numeric IP address from both, and the tests were simultaneous. Cheers, Dave Hart P.S. A special flip of the bird to those IWFs who filter all ICMP at the edge and break path MTU detection.
Re: Connectivity to an IPv6-only site
On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand st...@ibctech.ca wrote: - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative name servers - both of these servers *only* have IPv6 addresses Which seems a bit far afield from reality to me. Yes, there are lots of folks with IPv6 connectivity and v4-only recursive DNS servers. I don't think ISPs will have problems setting aside a handful of IPv4 addresses for authoritative DNS infrastructure to work around this until v6 transport in recursive DNS servers is common enough. Cheers, Dave Hart
Re: Connectivity to an IPv6-only site
On Fri, Apr 23, 2010 at 11:38 UTC, Tim Franklin t...@pelican.org wrote: Assuming your ISP is providing your DNS. What if I, as a new start-up in the IPv4-exhausted world, want to buy pure bit-pipes from my ISP, and be responsible for *everything* further up the stack? I don't believe this is entirely uncommon. Then you're going to either accept the hit to reachability, or you're going to use at least one third-party authoritative DNS service provider who can slave your zone over v6 and serve it over v4. puck.nether.net likely fits the bill and is free of charge. Cheers, Dave Hart
Re: APNIC Allocated 14/8, 223/8 today
On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote: On 14/04/2010 08:06, Srinivas Chendi su...@apnic.net wrote to SANOG: 014/8 223/8 Sunny, Please be careful about how you write this. 014 is formally an octal representation, and what you've written there actually means that APNIC has received 12/8 (= octal 014). Nick Nick, My eyebrow raised at the leading zero as well, but I'd call it ambiguous. 0x14 is unambiguously decimal 20, but 014 is only unambiguous in a context that defines leading zero as implying octal. For a C program relying on the runtime to convert text to numeric representation, it depends. sscanf(%d, myint) will convert 014 to decimal 14, %i gets decimal 12. I personally hunt down and kill %i and other octal-assuming code when I see it, except where octal is conventional. To my eyes, 0xFF (or FF) screams all bits lit while 0377 (or 377) only hesitantly clears its throat. Moreover, I assume computers will be used by people who have never had reason to believe a leading zero implies base 8, and I find no joy in forcing them to learn that quirk of computing history. Take care, Dave Hart
Re: APNIC Allocated 14/8, 223/8 today
On Wed, Apr 14, 2010 at 14:35 UTC, Vincent Hoffman wrote: PING 014.0.0.1 (12.0.0.1): 56 data bytes C:\Documents and Settings\Administratorping 014.0.0.01 Pinging 12.0.0.1 with 32 bytes of data: Connecting to 014.0.0.1|12.0.0.1|:80... Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80... When it comes to IP addresses, its not history, its important :) Good point. In most of these classic utility contexts, octal is generally accepted. 32-bit unsigned decimal representation has provided obfuscation for fun and profit in HTTP URIs. I'm sure you can find some software that still accepts it, and some that doesn't. For me, with no proxy, Chrome and IE both accept a non-dotted numeric IPv4 URI, but rewrite it in the address bar to the familiar dotted quad format. FireFox shows an error page that appears equivalent to: h1Bad Request (Invalid Hostname)/h1 FireFox is probably violating some spec. Thankfully. Cheers, Dave Hart
Re: NTP clock source
On Thu, Mar 25, 2010 at 12:51 UTC, Kyle Bader kyle.ba...@gmail.com wrote: Can anyone recommend a solid clock souce (stratum 0) that's not overly expensive? All the options I'm aware of have no prices posted, sadly. For me, that means forget it, you don't want to spend that much, but then I'm not spending other people's money :) In addition to Symmetricom and EndRun Technologies, Meinberg has a solid reputation in this space: http://www.meinberg.de/english/products/#network_sync I'm biased toward Meinberg because several of their staff contribute their skills to the development and maintenance of the ntp.org reference implementation. They have also been generous donating hardware over the years to ntp.org and pool.ntp.org, and their Windows NTP binaries and GUI installer are widely used. The cheapest solution involves the Garmin GPS 18x LVC receiver and a soldering iron. Unlike the USB and PC (232) versions of the GPS 18x, the LVC version supplies a pulse-per-second signal which makes it suitable for sub-millisecond NTP sync. The supplied connector has to be cut off, a DB-9 serial hood wired in its place, and either a USB cable or other 5V power supply needs to be attached. Or you can do as I did and pay for the completed GPS 18x LVC with DB-9 and USB connectors from a third party. $105 from: http://psn.quake.net/gps/gps18.html You also need a junkbox PC with real serial ports (not via a USB adapter), or the capacity on an existing server. The GPS 18x cable is either 3m or 5m long, if your PC is not close enough to a southern-exposed window or to roof access for the 18x to lock, you may also need a RS-232 extension cable and USB power supply. Unlike timing-focused GPSes, the 18x needs 3 or more birds in view to provide a PPS signal. Good luck, Dave Hart
