Re: Jon Postel Re: 202210301538.AYC
On 11/5/22 8:19 AM, Masataka Ohta wrote: William Allen Simpson wrote: Something similar happened with IPv6. Cisco favored a design where only they had the hardware mechanism for high speed forwarding. So we're stuck with 128-bit addresses and separate ASNs. Given that high speed forwarding at that time meant TCAM, difference between 128 bit address should mean merely twice more TCAM capacity than 64 bit address. Carrying the ASN in every packet, going back to my Practical Internet Protocol Extensions (PIPE) draft that was merged into SIP->SIPP, meant there was no need for Content Addressable Memory. And was closer to the original Internet Protocol design of smart edges with dumber switches. Reminder, PIPE was 1992. We'd barely deployed BGP. I think the primary motivation for 128 bit was to somehow encode NSAP addresses into IPng ones as is exemplified by RFC1888. Probably as many motivations as there were members of the IESG. Telcos wanted their addresses, some hardware vendors wanted IEEE addresses. But several vendors seemed very intent on using the standards process for putting competitors out of business. Though the motivation does not make any engineering sense, IPv6 neither. Not much about the IPv6 result makes any sense. I'd reserved v6. For a long time, I've been rather irritated that it was used for purposes so far from my design intent.
Re: Jon Postel Re: 202210301538.AYC
On 11/2/22 8:33 AM, Abraham Y. Chen wrote: 0) "Internet Vendor Task Force indeed.": Thank you so much in distilling this thread one more step for getting even closer to its essence. As I'd mentioned already, Randy Bush has also had some cogent thoughts over the years. That's where I'd first heard this phrasing long ago. Credit where credit is due. I've been involved since 1979. Hostility to an ITU-style organization arises from the earliest days of the NSFnet (which was government funded), in part because ATT was using the existing standards bodies to prevent the academic Internet itself from going forward. There's a lot of history. There are many different models for standards organization governance. I've been the head of standards for Red Hat for a few years (until it was bought by IBM), navigating roughly 50 different organizations. Back in the day, my early involvement was funded by government grants, government oversight committees, and political campaigns. (Particularly, my PPP work was originally funded by Bob Carr for Congress and Carl Levin for Senate, via Practical Political Consulting.) And for nearly half my life, I've been spending my time with a now former Member of Congress. So I've seen folks who know politics well All human effort is inherently political. Our problem is, engineers are particularly poor at politics.
Re: Jon Postel Re: 202210301538.AYC
On 10/31/22 9:27 AM, Donald Eastlake wrote: On Mon, Oct 31, 2022 at 2:37 AM Vasilenko Eduard via NANOG wrote: 1. What is going on on the Internet is not democracy even formally, because there is no formal voting. 3GPP, ETSI, 802.11 have voting. IETF decisions are made by bosses who did manage to gain power (primarily by establishing a proper network of relationships). It could be even called “totalitarian” because IETF bosses could stay in one position for decades. I do not see how it can be called totalitarian given the IETF Nomcom appointment and recall mechanisms. Admittedly it is not full on Sortition (https://en.wikipedia.org/wiki/Sortition) but it is just one level of indirection from Sortition. (See https://www.forbes.com/sites/forbestechcouncil/2020/08/20/indirection-the-unsung-hero-of-software-engineering/?sh=2cc673587f47) Donald helped setup this Nomcom system, based upon his experience in the F&SF community WorldCon. Credit where credit is due, and our thanks! Randy Bush has also had some cogent thoughts over the years. Once upon a time, I'd proposed that we have some minimum eligibility requirements, such as contributing at least 10,000 lines of code, and/or *operational* experience. Certain IESG members objected (who stuck around for many years). Once upon a time, IETF did have formal hums. That went by the wayside with IPSec. Photuris won the hum (overwhelmingly). We had multiple interoperable international independent implementations. Then Cisco issued a press release that they were supporting the US NSA proposal. (Money is thought to have changed hands.) The IESG followed. Something similar happened with IPv6. Cisco favored a design where only they had the hardware mechanism for high speed forwarding. So we're stuck with 128-bit addresses and separate ASNs. Again with high speed fiber (Sonet/SDH). The IESG overrode the existing RFC with multiple independent implementations in favor of an unneeded extra convolution that only those few companies with their own fabs could produce. So that ATT/Lucent could sell lower speed tier fractional links. Smaller innovative companies went out of business. Of course, many of the behemoths that used the standards process to suppress competitors via regulatory arbitrage eventually went out of business too. Internet Vendor Task Force indeed.
Re: FEC AO 2022-14
On 8/1/22 9:47 PM, sro...@ronan-online.com wrote: On Aug 1, 2022, at 9:38 PM, Michael Rathbun wrote: On Sun, 31 Jul 2022 12:11:07 -0400, William Allen Simpson wrote: At our residence, the US mailbox is positioned near the recycling bin. Bulk mail generally goes directly into recycling without being viewed. Sadly, receiver has to pay for recycling (via taxes). The incremental cost of unwanted postal mail deposited in a recycling bin in most US municipalities is 0.% of the monthly charge. The sender is, however, paying USPS for (however degraded) delivery. This works for me. I’m unsure how you came up with this calculation, but I can promise you it’s not correct. Likely bulk mail may be a bit higher here, as this is the household of a former Member of Congress. There is rather a pile of political mail. But that 0.% calculation is egregious nonsense for any location. In this household, approximate percentage of curbside recycling by weight is: 70% paper, mostly bulk mail 25% cardboard, mostly Amazon 5% plastic milk jugs This year's recycling plant upgrade was $7.25M, of which $800K was a grant. Remember that grants come from taxes, too. On topic, back in the day (2003), measured bulk email was 80%+ of our traffic. It's not so much percentagewise anymore, because of streaming. I'm willing to guess that it's still on that order relative to email itself. If you have any interest regarding (for or against) an increase of spam traffic, please comment on the FEC proposal. Links in the OP. (Comments due by August 5, 2022)
FEC AO 2022-14
https://www.washingtonpost.com/politics/2022/07/29/republican-fundraising-google-spam/ Forwarded Message Subject: AO 2022-14 Date: Sun, 31 Jul 2022 12:03:20 -0400 From: William Allen Simpson To: a...@fec.gov https://www.fec.gov/data/legal/advisory-opinions/2022-14/ * Opposing the proposal as written. * Permitting unsolicited electronic bulk mail advertisements from political actors is an involuntary contribution from Gmail users. Google's statement that the Gmail service is "free" for its users is inaccurate. As Google admits against interest, Gmail users are subjected to advertisements and also may subscribe to the service. Moreover, data transmission and storage costs are significant. Political electronic bulk mail is distinguishable from physical bulk mail. Electronic mail is receiver pays (via advertisements or subscription). Physical mail is sender pays (via stamps or permits). Therefore, this is not without cost to the recipient. Google reports an immense profit. It is undesirable and unseemly to pay (via advertisements or subscription) and then receive more bulk advertisements. Support a requirement that all political and other bulk senders be "opt-in". Support that that for every bulk message: The requestor must meet reputational thresholds and ensure that their messages are secure, filterable, and follow best practices for the user experience, including for example: (i) “one-click” unsubscribe, which enables a user to efficiently opt out of future communications; (ii) approving and following unsubscribe requests within 24 hours, which respects the user’s choice; and (iii) ensuring that all links in the message can be scanned by Google for phishing and malware detection, which helps to protect the user from harmful content. At our residence, the US mailbox is positioned near the recycling bin. Bulk mail generally goes directly into recycling without being viewed. Sadly, receiver has to pay for recycling (via taxes). Likewise, we expect unsolicited electronic bulk mail to go directly to recycling (the spam folder is automatically deleted, recycling storage). This is a helpful reduction in user data transmission and storage costs. --- I have been a Gmail user for many years. I am also a Google Fi customer. Don't be evil. William Allen Simpson Ann Arbor, MI
Re: IPv6 "bloat" history
On 3/31/22 7:44 AM, William Allen Simpson wrote: [heavy sigh] All of these things were well understood circa 1992-93. That's why the original Neighbor Discovery was entirely link state. ND link state announcements handled the hidden terminal problem. Also, it almost goes without saying that the original ND tried to handle the near-far problem. For example, where I'm talking to a far away AP streaming to the TV in front of me. At my home, I've had to wire the TV. Streaming to the AP, then the AP sending the same traffic over the same wireless band to the TV caused lots of drops and jitter. The near-far problem can be detected and solved. That's the reason for the Metric field. Furthermore, one of the messages in this thread mentioned trying to backport v6 features to v4. We've already been down that road. IPsec and MobileIP were developed for v6. After quitting the v6 project(s), I'd backported both of them to v4. Like v6, then they were assigned to others who ruined them. Committee-itis at its worst.
Re: IPv6 "bloat" history
On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote: * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs. [heavy sigh] All of these things were well understood circa 1992-93. That's why the original Neighbor Discovery was entirely link state. ND link state announcements handled the hidden terminal problem. (That is, where node A can hear node B, node B can hear node C, and node C can hear node A, but A cannot hear C.) ND LSAs are/were flexible enough to handle both AP (cell) and mesh (AMPR) networks. Thus, it was not reliant on central Access Points. We envisioned mesh networks were the future. Each node should handle its own discovery and routing. SLAAC is bloat. RIPv6 is bloat. DHCPv6 is bloat. Those are reasons operators have been complaining about IPv6.
Re: IPv6 "bloat" history
On 3/23/22 2:25 AM, Masataka Ohta wrote: William Allen Simpson wrote: Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic. To make "IP uber alles", link-dependent adaptation mechanisms between IP and links are necessary. So, "ND uber alles" is a wrong goal. Meant to reply to this separately. I've implemented on the order of 35+ protocols, most of them predating IP. My first IP implementation was 1979 for the Perkin-Elmer 7/16. The link layer was X.25 to talk to Merit and over Telenet (not telnet -- Telenet was a provider in those days). John Gilmore recently gave a good history of the ARP origin. Note that for PPP, we also had to negotiate a link layer shim. Some folks then grabbed that effort, instead of building their own, resulting in such monstrosities as PPP over Ethernet. After so many times reinventing the wheel, IP uber alles is a better goal. Speaking as somebody familiar with the effort.
IPvB performance header
This was the IPvB (nee original IPv6) *performance* header. We required that each IP variant have its own link layer designation. Therefore, the IP version number wasn't needed. We could simply set two upper bits to a value (0) that would distinguish it from every extant IP version. Also, many of us thought that the type of service was poorly defined and rarely used. The longer length field was requested by Fibre Channel, and later used for InfiniBand. Finally, the Flow Label was supposed to aid in NAT mapping, without the underlying transport layer. One field to rule them all. No chains of headers. High performance. 3.2. Performance Header Format +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | V | Maximal Length | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | Flow Label | Hop Limit | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | +Source + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | + Destination + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ |Security Parameters Index (SPI)| A +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ |Sequence Number| A +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | A E ~Transform Data ~ A E | | A E +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ ... Padding | A E +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | ~ Authenticator ~ | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ For most fields, see above. Fields to be authenticated are designated by a trailing A. Fields to be encrypted are designated by a trailing E. V2 bits. Always 0. This corresponds to the unused IP Versions 0 to 3, and is readily distinguished from all extant versions. Maximal Length 30 bits. The length of the datagram, including internet header(s) and payload data. The maximum length supported by the Destination is negotiated for each Flow Label. Flow Label 24 bits. The Flow Label is relative to the IP Source and Destination pairing, and assigned by the flow’s originating node. The Flow Label subsumes the Service and Next Header information. The Flow Label MUST NOT be altered by an intervening router. Routers that do not support Flow Label functionality, or lack state for this Source and Flow Label combination, MUST treat the Service as undifferentiated. Mechanisms for assignment and reservation of Flow Labels are beyond the scope of this specification.
IPvB translation header
This was the IPvB (nee original IPv6) *translation* header. Note that it was cleverly designed to translate from IPv4. Most of the fields are in exactly the same place. Especially, the 32-bit Source IP address is in exactly the same place, hoping that filters could operate on both stacks. We were implementing on then new i386 32-bit machines, but also tested on i286 16-bit machines. We knew there would be 64-bit machines (such as the DEC Alpha), so it was carefully designed for multiple environments. 3.1. Translation Header Format +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ |Version| IHV |Service|Minimal Length | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ |Identification | Next Header | Hop Limit | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | +Source + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | + Destination + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ Version 4 bits: constant 0xB (1011 binary). Indicates the format of the internet header. This document describes version 11. Note: The IPv4 Version is 0x4 (0100 binary). IPvB is the complement (binary inverse) of IPv4. Although this field is always present, and may be used internally by systems, different headers MUST be distinguished at the link layer. Some implementations of IPv4 failed to correctly check (or set) the IPv4 Version. IHV 4 bits. Internet Header Variant. 0x0 Invalid; MUST be silently discarded. 0x6 IPv4 header translation. The least significant bit here reflects the most significant IPv4 Flags bit, as some systems used that bit in the past. (See "IPvB Translation for IPv4" [].) 0x8 Flow header (see below). 0xA Reserved for future use. The IPvB header is a fixed minimum size. However, the Version field is a scarce resource Therefore, larger values are used for format variants, transient indications, and other purposes. Note: For IPv4, this field was the Internet Header Length (IHL) in 32‐bit words. The minimum value for a matching IPvB header is 6 words. Service 8 bits: default 0. Contains the IPv4 Type of Service (ToS). Minimal Length 16 bits: minimum 64 (bytes). Smaller values MUST be silently discarded. The length of the datagram, including internet header(s) and payload data. All nodes must be prepared to accept datagrams of up to 1480 octets. It is recommended that hosts send datagrams larger than 1480 octets only after assurance that the destination is prepared to accept the larger datagrams. The number 1480 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information, and to allow typical lower‐layer encapsulations room for their respective headers. Over time, memory limitations have eased considerably, and there have been some indications that a larger minimum datagram size throughout the internet would be beneficial. Note: IPv4 has minimum required 576 and maximum 65,535 octet datagrams. Translation to IPv4 requires that
Re: IPv6 "bloat" history
On 3/23/22 2:25 AM, Masataka Ohta wrote: William Allen Simpson wrote: 6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol (PIP) had some overlapping features, so we also asked them to merge with us (July 1993). More complexity in the protocol header chaining. With the merger, Paul Francis was saying he was unhappy because PIP is dead. So the merger is not voluntary for him and the added complexity is technically meaningless. He seemed happy at the Amsterdam 1993 meeting, but as time went on he was sidelined. Likewise, I eventually regretted having joined with the others. We lost control of the main ideas. For example, originally V6 was designed to use shortest path first interior routing. All the announcements were Link State, everything was in place. I still wince at the memory of the PARC meeting where Eric stated that RIP was good enough for V4, so it is good enough for V6. Then he was assigned to be my "co-author". So I quit. What you know as Neighbor Discovery was not the original design. Nor was RIPv6 needed. When I was giving a talk at Google 25 years later I was asked why that happened (by a then member of the IAB). A sore spot, long remembered. Committee-itis at its worst. IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop. Then the committees added back the hop by hop processing (type 0). Terrible! Really? But, rfc1710 states: The SIPP option headers which are currently defined are: Hop-by-Hop Option Special options which require hop by hop processing Yep, that was one of the reasons I quit. Digging out my files, I'd forked my documents by July 17, 1994. (That's the last date I'd touched them, so it was before then.) RFC 1710 was later. Also, I registered IPvB with Jon Postel. These are all old nroff files, but I could hand format a bit and post things here. Not that it makes much difference today, yet some of my ideas made it into Fibre Channel and InfiniBand.
Re: IPv6 "bloat" history
Admitting to not having read every message in these threads, but would like to highlight a bit of the history. IMnsHO, the otherwise useful history is missing a few steps. 1) The IAB selected ISO CLNP as the next version of IP. 2) The IETF got angry, disbanded, replaced, and renamed IAB. 3) On the Big-Internet list, my Practical Internet Protocol Extensions (PIPE) was an early proposal, and I'd registered V6 with IANA. I was self-funding. PIPE was cognizant of the needs of ISPs and deployment. 4) Lixia Zhang wrote me that Steve Deering was proposing something similar, and urged us to pool our efforts. That became Simple Internet Protocol (SIP). We used 64 bit addresses. We had a clear path for migration, using the upper 32-bits for the ASN and the old IPv4 address in the lower 32-bits. We had running code. 5) The IP Address Extension (IPAE) proposal had some overlapping features, and we asked them to merge with us. That added some complexity. 6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol (PIP) had some overlapping features, so we also asked them to merge with us (July 1993). More complexity in the protocol header chaining. 7) The result was SIPP. We had 2 interoperable implementations: Naval Research Labs, and KA9Q NOS (Phil Karn and me). There were others well underway. 8) As noted by John Curran, there was a committee of "powers that be". After IETF had strong consensus for SIPP, and we had running code, the "powers that be" decided to throw all that away. 9) The old junk was added back into IPv6 by committee. There was also a mention that the Linux IP stack is fairly compact and that IPv6 is somewhat smaller than the IPv4. That's because the Linux stack was ported by Alan Cox from KA9Q NOS. We gave Alan permission to change from our personal copyright to GPL. It has a lot of the features we'd developed, such as packet buffers and pushdown functions for adding headers, complimentary to BSD pullup. They made SIPP/IPv6 fairly easy to implement. On 3/22/22 10:04 AM, Masataka Ohta wrote: Owen DeLong wrote: IPv6 optional header chain, even after it was widely recognized that IPv4 options are useless/harmful and were deprecated is an example of IPv6 bloat. Extensive use of link multicast for nothing is another example of IPv6 bloat. Note that IPv4 works without any multicast. Yes, but IPv6 works without any broadcast. At the time IPv6 was being developed, broadcasts were rather inconvenient and it was believed that ethernet switches (which were just beginning to be a thing then) would facilitate more efficient capabilities by making extensive use of link multicast instead of broadcast. No, the history around it is that there was some presentation in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast Multiple Access)in general, is multicast capable though not broadcast capable, which was blindly believed by most, if not all excluding *me*, people there. Both Owen and Masataka are correct, in their own way. IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop. Then the committees added back the hop by hop processing (type 0). Terrible! Admittedly, I was also skeptical of packet shredding (what we called ATM). Sadly, the Chicago NAP required ATM support, and that's where my connections were located. It should be noted that IPv6 was less bloat because ND abandoned its initial goal to support IP over NBMA. Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic. > There is still a valid argument to be made that in a switched > ethernet world, multicast could offer efficiencies if networks were > better tuned to accommodate it vs. broadcast. That is against the CATENET model that each datalink only contain small number of hosts where broadcast is not a problem at all. Though, in CERN, single Ethernet with thousands of hosts was operated, of course poorly, it was abandoned to be inoperational a lot before IPv6, which is partly why IPv6 is inoperational. Yes, we were also getting a push from Fermi Labs and CERN for very large numbers of nodes per link, rather than old ethernet maximum. That's the underlying design for Neighbor Discovery. Less chatty. Also, my alma mater was Michigan State University, operating the largest bridged ethernet in the world in the '80s. Agreed, it was "inoperational". My epiphany was splitting it with KA9Q routers. Suddenly the engineering building and the computing center each had great throughput. Turns out it was the administration's IBM that had been clogging the campus. Simple KA9Q routers didn't pass the bad packets. That's how I'd become a routing over bridging convert. Still, there are data centers with thousand por
Re: V6 still not supported
On 3/10/22 9:22 PM, Masataka Ohta wrote: Matthew Walster wrote: IPv6 is technologically superior to IPv4, there's no doubt about that. It is not. Though IPv6 was designed against OSI CLNP (with 20B, or, optionally, 40B addresses), IPv6 incorporated many abandoned ideas of CLNP and XNS already known to be useless or harmful with experiences on IPv4 to be a protocol as bad as or even worse than CLNP. For example, address length was extended from original 8B to 16B to allow lower 48bits be MAC addresses, which was what XNS was doing, only to make ISP operations with raw addresses prohibitively painful. IPv6 as originally designed had 8 byte (64-bit) addresses that had no difficulty including 48-bit MAC addresses for link-local deployment. It was explicitly stated that they would *NEVER* be globally visible, as there were many documented examples of duplicate MAC assignments. Then, the powers that be declared that IPv6 should have 128-bit addresses, and a host of committees were setup with competing CLNP (TUBA) co-chairs. They incorporated many ideas of CLNP and XNS that were thought (by many of us) to be worthless, useless, and harmful. Committee-itis at its worst. My original address plan had the leading 32 bits as the existing ASN, with the lower 32-bits as the existing IPv4 address. Making ISP operations eminently easier, as we already knew those two things.
Re: V6 still not supported
I'd flagged this to reply, but sadly am a bit behind On 3/10/22 11:02 AM, Matthew Walster wrote: IPv6 is technologically superior to IPv4, there's no doubt about that. It is vastly inferior when it comes to understanding what is going on by your average sysadmin, network engineer, IT helpdesk person -- it is just far too complicated. Even the wording is confusing, e.g. router/neighbor "solicitation/advertisement" instead of "request/reply". I'd wanted to clearly distinguish this from the old methods: This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6] environment. There are also elements of the OSI ES-IS and IS-IS Hello. We were forward looking to deployments of thousands of systems per link, rather than the 30 maximum under then current ethernet standards. We needed fewer announcements, less chatty traffic, and more specific traffic designation. We also prioritized network security. Moreover requiring addresses be ephemeral, such that applications would not be able to tie authentication/authorization to an IPv6 address and would be motivated to use cryptographic security. Unfortunately, later committees decided that rather than a single simpler secured address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6. Three ways to do the same thing are always a recipe for disaster. IPv6 is a case study in how all too often human factors are not considered in the design of engineering projects. [...] Reminder: I was an operator and one of the original NANOG members. We spent a lot of time considering human factors. I'd pioneered the "Operational Considerations" section of the original draft RFCs. IPv6 is a case study of what happens with committee-itis. The small design team worked well. On 3/16/22 9:03 PM, John Gilmore wrote: > Given the billions of people who eat and sleep for HOURS every day, I > think I am doing pretty well by just coordinating three people part-time > trying to improve IPv4 a little bit. [...] > Please tell me where this excellent effort is underway?
Russian aligned ASNs?
There have been reports of DDoS and new targeted malware attacks. There were questions in the media about cutting off the Internet. Apparently some Russian government sites have already cut themselves off, presumably to avoid counterattacks. Would it improve Internet health to refuse Russian ASN announcements? What is our community doing to assist Ukraine against these attacks?
Re: Rack rails on network equipment
On 9/25/21 7:52 PM, Joe Greco wrote: On Sat, Sep 25, 2021 at 04:23:38PM -0700, Jay Hennigan wrote: On 9/25/21 16:14, George Herbert wrote: (Crying, thinking about racks and racks and racks of AT&T 56k modems strapped to shelves above PM-2E-30s???) And all of their wall-warts [...] You were doing it wrong, then. :-) Oh, you young rascals! Started with Racal-Vadic triple modems connected to custom multiport serial gear (still have the wirewrap tool), upgraded to Telebit NetBlazers, then Livingston PortMasters. Built and rebuilt many Points Of Presence (POPs) back in the day. Two days per rack wasn't unusual, labeling all those wires. The real problem with racks is/was the changes in holes. My personal preference now is all square holes, because you can always replace the plugs after the threads have stripped. Stripped threads were at one time the bane of my existence. Anyway, wasn't the Open Compute Project supposed to fix all this? Why not just require OCP in all RFPs? Also, hot aisle cold aisle should have been replaced by now with rack top hats. Seem to remember a Colorado study that showed 15% power reduction by moving the air return over a suspended ceiling.
Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone?
On 5/4/21 11:34 AM, Saku Ytti wrote: On Tue, 4 May 2021 at 18:28, Adam Thompson wrote: When I look at my IPv6 routing table, the next-hops are all... well... gibberish, at least to me. My experience is that LLAs are not durable, so memorizing them is not IMHO a useful task. Figuring out an (IS-IS) IPv6 route currently involves a couple of extra steps to locate the LLA's interface route, find the MAC address of that LLA on that link, and then identify the router from its MAC address. Am I missing something obvious? I don't think you are, I read like an opinion piece so it's inherently not right or wrong. I don't have the same experience and I consider forcing LLA a blessing in limiting attack vectors and I personally don't see downsides as all addresses are gibbering to me, as my working memory contains very few digits. I wish ND had mandated LLA too, so many customer tickets due to poorly configured filters due to misunderstanding how ND works. Sadly, all 128-bit IPv6 addresses are gibberish. The original IPv6 design specified the upper 32 bits as the ASN, the lower 32 to match the subnetting of IPv4. I'd even specified an alternative representation to Karn's notation (called Simpson's notation), so that the IPv4 and IPv6 matched! Karn's notation: x.x.x.x/24 compared to :::/56 Simpson's notation: x.x.x.x//8 matching ::://8 All that went out the window with the IESG decision to override our 64-bit design and specify 128-bit addresses with no topological prefix. The IESG didn't have any operators on it. OTOH, I was the pioneer of the RFC *Operational* Considerations section (and an early operator). Link Local Addresses are/were intended to be durable. They are/were statically based upon a physical constant, such as the interface MAC. IPv6 globally routed addresses are/were intended to change every day. One of my drafts indicated that IANA would test changing a leading ASN at least once per month, ensuring that software properly handled it. Neighbor Discovery was intended to use the stable Link Local Address. Neighbor and Router Discovery were intended to be authenticated. You shouldn't allow some random device to be attached to your network. You shouldn't authenticate some unknown interface address. And you shouldn't communicate via some router that cannot demonstrate verification of your per interface secret. Also you shouldn't assign a globally routable address to any unauthenticated device. All that went out the window with the IESG decision Remember the vocal resistance (screaming) in the DHCP WG meeting? Configuring a secret key for each interface is just too hard. (Eventually, various countries required every device to have a secret, printed on the label along with the model and serial number.) Configuring a public key for every ASN is just too hard. Configuring a public key for every Domain Name is just too hard.
Re: Google peering pains in Dallas
On 4/29/20 8:53 PM, Christopher Morrow wrote: I suppose it's time for a more public: "Hey, when you want to test a service, please take the time to test that service on it's service port/protocol" Testing; "Is the internet up?" by pinging a DNS server, is ... not great ;( I get that telling 'joe/jane random user' this is hard/painful/ugh... :( (haha, also look at cisco meraki devices!! "cant ping google dns, internet is down") Sorry :( Just as an anecdote: once upon a time I had a television that began reporting it couldn't work anymore, because the Internet was down. After resorting to packet tracing, discovered that it was pinging (IIRC) speedtest.napster.com to decide. Napster had gone belly-up. Fortunately, it had a 2 year warranty, took it back to Best Buy with about a month to go. Now think about the hundreds of thousands of customers who didn't know how to diagnose the issue, or the warranty had expired, and had to buy a new smart TV? Tried to get the FTC interested, no joy. Congress made noises about passing a law requiring software updates (especially for security issues), but still nothing on that either. Besides, what are we going to do after Google goes belly-up? ;)
Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that
On 1/27/20 3:06 PM, b...@theworld.com wrote: I remember going from 300b to 1200b and thinking wow, this is it, we're done, I cannot read text scrolling on the screen at 1200b. Other than the 75 and 110 baud teletypes that only did text, my first TCP/IP connection was 300b, back when we had to rent the modems (1979). I had to write my own TCP/IP stacks, on both the Interdata 7/16 at the office and my first personal computer: a 2 MHz Z80 S-100 bus. Built my own serial device too, with a rather large switch on the back to change speeds. (Still have it, just carried it out of the garage over the weekend, haven't turned it on in years as the special floppies have died.) Eventually, got my own 300b Hayes Micromodem! It took a long time to upgrade to 1200b, as the modems were thousands of dollars each. Roughly $18,000 each in today's dollars. Only used between major sites. Racal-Vadic triple modems were a big step (circa 1986). When we first designed PPP in the late '80s to replace SLIP and SLFP, it was expected to run at 300 bps and scale up, so the timeouts reflected that. When I designed PPP over ISDN, added language to allow faster retransmission. When we designed IP/PPP/CDMA (IS-99) for cell phones, I was seriously concerned that it would not be competitive, as it only allowed 14.4 kbps when 28.8 kbps modems were becoming available. Turned out to be several times faster than ATT's CDPD offering Like many of you, I started an ISP in 1994 with a 56 kbps uplink, and only 6 local customers The routers were in a bathroom over the garage.
Re: 5G roadblock: labor
On 1/1/20 10:35 AM, Brandon Butterworth wrote: On Wed Jan 01, 2020 at 09:29:20AM -0500, jdambro...@gmail.com wrote: Given the deployment of Wi-Fi into so many different applications - your statement that 5G is to "replace" WiFi seems overly ambitious We might think that but it is serious. They want to own it all and there is a small cabal of operators owning the spectrum so little room for new competitors. Deployed WiFi '5' (ac) and WiFi '6' (ax) already outperform mobile 5G. If this were actually about performance, the standards would have converged. And there wouldn't need to be so many additional patents. The primary purpose seems to be barriers to entry and competition. [...] Perhaps preventing WiFi from further penetration is a better way to look at it? If the mobile companies are providing the WiFi routers they can control it (see LTE WiFi attempt) and one day replace it with 5G or 6G in all the things. If they make a better job of it than everyones devices fighting for 5GHz then they may succeed. Agreed. In my previous job, having spent considerable time talking to various standards' body participants, "replace" was the word used.
Re: 5G roadblock: labor
This thread has devolved into "Why 5G"? A lot of folks are missing the bigger picture. 5G is not for better voice calls. AFAICT, it won't help voice at all. 5G is not for better integration with WiFi or IP data. 5G is to *replace* WiFi, and FTTH, and ISPs, and WISPs, and bring all data back to the telco. ATT really misses owning the network monopoly. 5G is also about upstaging Amazon and Google and other data center providers. Read up on "Edge Computing". The "edge" isn't in your network or your customers' internal networks. The edge is a telco data center. That's what they mean by "reducing latency": moving your data processing into a telco data center means it is topologically closer to a cell tower. 5G is mostly about getting more unregulated data-related fees. --- History lesson: When I designed CDMA IS-99 (circa 1993-95), IP data was sent over the Operations and Management (O&M) interface. You could do voice simultaneous with data. Every original CDMA cell tower had an IP router in it. Our initial implementation significantly out-performed ATT's CDPD. I'm also the original author of Mobile IP, and the first implementer. IS-99 gave easy and fast IP roaming between interconnected cell towers. Turns out, the big telcos didn't like this model. In fact, they really didn't like a distributed traffic model at all. They wanted to centralize and monetize access to data, which they viewed as a value-added service, because they could bypass regulators and charge whatever the market could bear. Voice was regulated. Data was not. More money was to be made. Same issues, 25 years later
Re: NTP via GPS
On 5/1/19 6:12 PM, Richard wrote: I found this article very helpful as I knew very little. I was smarter for reading it though it may be to basic for many: https://timetoolsltd.com/gps/gps-ntp-server/ Although it has a good general overview, I'm fairly sure that Dave Mills would be very surprised that: "The NTP protocol was originally developed for the LINUX operating system."
Re: SLAAC in renumbering events
On 3/8/19 6:32 AM, Fernando Gont wrote: Folks, If you follow the 6man working group of the IETF you may have seen a bunch of emails on this topic, on a thread resulting from an IETF Internet-Draft we published with Jan Žorž about "Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt ) [...] We are looking forward to more input on the document (or any comments on the issue being discussed), particularly from operators. So feel free to send your comments on/off list as you prefer Thanks for bringing this to the attention of operators. Too few IETF documents have operational considerations.
Re: BGP Experiment
On 1/26/19 6:37 PM, Randy Bush wrote: to nick's point. as nick knows, i am a naggumite; one of my few disagreements with dr postel. but there is a difference between writing protocol specs/code, and with sending packets on the global internet. rigor in the former, prudence in the latter. OK, Randy, you peaked my interest: what is a naggumite? Many of us disagreed with Jon Postel from time to time, but he usually understood the alternative points of view.
Re: CenturyLink RCA?
On 12/31/18 3:31 PM, Keith Medcalf wrote: It could have been worse: https://www.cio.com.au/article/65115/all_systems_down/ "Make network changes only between 2am and 5am on weekends." Wow. Just wow. I suppose the IT types are considerably different than Process Operations. Our rule is to only make changes scheduled at 09:00 (or no later than will permit a complete backout and restore by 15:00) Local Time on "Full Staff" day that is not immediately preceded or followed by a reduced staff day, holiday, or weekend-day. We had fairly extensive discussion on this list decades ago. Deploy non-emergency changes early Tuesday morning local time, a few hours before regular working hours. Agreed about "not immediately preceded or followed by a reduced staff day, holiday, or weekend-day." Because you won't know it's really working until the actual users have no reported problems. Tuesdays give a couple of working days to ensure that there were no hidden ill affects. Weekends are terrible for that reason. As are Mondays and Fridays, because actual users aren't around in overseas locations. Even those of us who have operated regional ISPs still can effect the world. And those of us with multiple datacenters world-wide have to ensure that changes in one place don't affect the others As I remember, at the time this NANOG wisdom propagated to legal blogs. Because so much of what network operators do has legal implications.
Re: Auto-reply from Yahoo...
On 12/20/18 11:46 AM, Grant Taylor via NANOG wrote: On 12/14/2018 11:48 AM, Grant Taylor wrote: I've been seeing them for three or four days now. BUMP This has been going on for more than a week now. I'm quite confident that there have been hundreds of auto-replies. (I'm seeing 285 incoming message from the NANOG mailing list since I became aware of the auto-reply.) I'm really surprised that there has not been any reply or action by the NANOG list owner(s). I would have hoped, if not expected, better, or any, response by now. Well, somebody who seemed to be from Yahoo claimed they were fixing their auto-responder. Obviously, that hasn't been deployed yet.
Re: Stupid Question maybe?
On 12/19/18 2:47 PM, valdis.kletni...@vt.edu wrote: So at one show, the Interop show network went to a 255.255.252.0 netmask, and of course a lot of vendors had issues and complained. The stock response was "Quit whining, or next show it's going to be 255.255.250.0". Ha, I remember! Let us not forget Interop 91, where one vendor accidentally sent all its packets with an IP version field of 0. Nearly every router was shown to never check the IP version number! Moreover, it turned out later that major printer vendors weren't checking either No good way to update them in the field, ever. That was a serious worry as we designed PIPE/SIP/SIPP/IPv6, and the main reason that we had to get new link layer protocol numbers. Then there were the fine vendors that conflated the link and IP headers. That fell apart when IEEE started assigning OUIs that began with 0x4xxx. Interop really used to be a blessing, before it became just another show.
Re: Stupid Question maybe?
On 12/18/18 8:38 PM, Fred Baker wrote: On Dec 19, 2018, at 3:50 AM, Brian Kantor wrote: /24 is certainly cleaner than 255.255.255.0. I seem to remember it was Phil Karn who in the early 80's suggested that expressing subnet masks as the number of bits from the top end of the address word was efficient, since subnet masks were always a series of ones followd by zeros with no interspersing, which was incorporated (or independently invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519. - Brian Actually, not really. In the time frame, there was quite a bit of discussion about "discontiguous" subnet masks, which were masks that had at least one zero somewhere within the field of ones. There were some who thought they were pretty important. I don't recall whether it was Phil that suggested what we now call "prefixes" with a "prefix length", but it was not fait accompli. Actually, Brian is correct. Phil was w-a-y ahead of the times. But I don't remember him talking about it until the late '80s. Brian probably knew him longer. Anyway, Fred is also correct. It took many years, and a lot of argument, before prefixes were common. Partly that was me, in PIPE/SIP/SIPP and CIDRD. Required longest prefix match in early Neighbor Discovery drafts. However, I was more of an advocate for suffixes, also known as host mask, wanting them to be common between IPv4 and IPv6. I still think it would have simplified setup for operators. Most don't care how long the network part, they know how many nodes are needed on the LAN. Cisco had adopted /n for network prefixes, so I'd proposed //h for host suffixes. Anyway, /n made it into RFCs. Going with prefixes as we now describe them certainly simplified a lot of things. Take a glance at https://www.google.com/search?q=discontiguous+subnet+masks for a history discussion. Didn't see anything ancient. Circa 2010 arguments Apparently, CIDRD archives aren't up anymore.
Re: Puerto Rico Internet Exchange
On 8/12/17 7:27 AM, Mehmet Akcin wrote: Hey there! ... ok this time I am not going to call it PRIX ;) I thought that was a perfectly good name. [...] The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. What happened to Internet Exchange of Puerto Rico (ix.pr)? Run by AS36810? We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. https://www.pch.net/ We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space!
Re: The spam is real
On 10/26/15 1:10 PM, Pablo Lucena wrote: On Sun, Oct 25, 2015 at 12:22 AM, Josh Luthman wrote: Can we please get a filter for messages with the subject "Fw: new message" ??? So far I've dealt with it via Gmail's 'mute conversation' setting somewhat effectively. Gmail was smart enough to put those addressed directly to me into the spam folder -- and let those via nanog through. It's been trained well! Let's look at this as an opportunity. We have a relatively small set of websites that have been corrupted with additional links (presumably unknown to the owner), that then redirect one or more times. What's the exploit that corrupted the sites? Have the site owners been contacted? All the sites that I checked (without the added suffix) seem legit. But maybe they are spammer sites? How do we know?
Fw: new message
Hey! New message, please read <http://smbdigitals.com/together.php?31n> William Allen Simpson
Re: Sign-On Letter to the Court in the FCC's Net Neutrality Case
On 9/16/15 11:12 AM, Peter Beckman wrote: Why don't you post a copy here or a link? https://www.eff.org/files/2015/09/14/eff-aclu_internet_engineers_and_pioneers_statement.pdf I've agreed.
Re: Why is .gov only for US government agencies?
On 10/19/14 10:32 AM, John Levine wrote: # Gee, someone should alert NANOG management that the list has fallen # through a wormhole into 1996. # On 10/19/14 12:51 PM, David Conrad wrote: RFC 1591. Which is circa 1994. The real answer is that although fed.us is used by some agencies, the overall requirement was stripped out of the Telecommunications Act of 1996. Basically, the DC area incumbent provider of .gov and .com was making so insanely much money per registration, they were able to buy off persuade enough politicians to keep their monopolistic status. Slowly, slowly, technical progress (Google) and cooperative agreements have eroded that "land grab" into an oligopoly instead.
Re: Muni Fiber and Politics
On 7/21/14 3:50 PM, William Herrin wrote: On Mon, Jul 21, 2014 at 3:08 PM, Blake Dunlap wrote: My power is pretty much always on, my water is pretty much always on and safe, my sewer system works, etc etc... Mine isn't. I lost power for a three days solid last year, I've suffered 3 sanitary sewer backflows into my basement the last decade and you should see the number of violations the EPA has on file about my drinking water system. Only the gas company has managed to keep the service on, at least until I had a problem with the way their billing department mishandled my bill. Didn't get solved until it went to the lawyers. And I'm in the burbs a half dozen miles from Washington DC. God help folks in a truly remote location. Woah! Catching up on this thread -- AFAICT from public sources you (Herrin) don't actually have municipal electric or gas, and doesn't look like water/sewer either What you have are regulated monopolies, subject to what's known as "regulatory capture". I've lived in places with municipal power and water -- and also under regulated monopolies. Municipal beats the pants off them! My gas company was bought by my electric company, so not even the hint of power competition there. My water/sewer company is "owned" by a big bankrupt city nearby, but operated as a separate entity with poor oversight -- so it's pretty much the worst possible case, indistinguishable from a regulated monopoly. Michigan used to have local cable boards, which were done away with in the same law that outlawed municipal broadband. Now we have to make complaints about Comcast at the state level. That's just dandy. :(
Re: Richard Bennett, NANOG posting, and Integrity
On 7/22/14 12:07 PM, Paul WALL wrote: Provided without comment: http://www.esquire.com/blogs/news/comcast-astroturfing-net-neutrality Thanks! This is nothing new for him. There's astroturf from him going back to '08 on NANOG. Remember when he was shilling for ITIF -- a "think tank" whose board was then co-chaired by conservative congress-critters and dominated by corporate governmental affairs (nee lobbyists)?
Net Neutrality FCC COMMENTS OF THE INTERNET ASSOCIATION
http://internetassociation.org/wp-content/uploads/2014/07/Comments.pdf Really good, for those of us with the patience to ponder it. I tried writing my own FCC response, and was flummoxed by the difficulty. Official comment period ends today.
Re: OT: Below grade fiber interconnect points
On 11/13/13 11:51 PM, Roy Hockett wrote: I am guessing due to esthetics the below ground vault was selected, we just learned of this selection and thus my query to this group to find other that have dealt with similar situations and if so, experience base recommendations, and things to be aware of. Thanks, -Roy Hockett Network Architect, ITS Communications Systems and Data Centers University of Michigan Tel: (734) 763-7325 Fax: (734) 615-1727 email: roy...@umich.edu I remember seeing a below grade vault here in Michigan once. It was purpose built (years ago for MCI IIRC), but I don't know by whom. Heavy steel plate door on top, looked like those on major water pipe vaults. Likely built to similar civil engineering standards. But this was fairly early in the history of laying fiber, so there are probably newer standards. Off the top of my head, it had a lot of things concerned with water and humidity -- dual redundant sump pumps, dual heaters mounted 6' off the floor, an environmental monitoring panel, an exterior antennae pole for out-of-band reporting from the monitoring panel. I didn't have the opportunity to open the fairly beefy looking power panel, so I don't know whether there was a dual feed -- but it wouldn't surprise me. As to cleanliness, it wasn't particularly clean, but not really dirty. (Much like any exterior shopping center access demark, assuming you've seen those.) I also saw a Bell South below grade fiber vault once, but wouldn't recommend it, as it was full of water at the time To be fair, I'm not sure they had a cross-connect panel in there.
Re: Security over SONET/SDH
On 6/25/13 3:55 AM, Scott Weeks wrote: Yeah, but I was just thinking through what the original question asked. After reading his emails over the years, I am assuming he meant in addition to everything else "What security protocols are folks using to protect SONET/SDH? At what speeds?" Correct. But the answer appears to be: none. Not Google. Not any public N/ISP. I now see it quickly devolves into what various governments will allow its citizenry to do on the internet. :-( With a lot of dithering by folks who have no operational or security responsibilities at any providers. :-(
Re: Security over SONET/SDH
On 6/23/13 10:57 AM, Christopher Morrow wrote: On Sun, Jun 23, 2013 at 10:54 AM, Christopher Morrow wrote: On Sun, Jun 23, 2013 at 9:47 AM, William Allen Simpson wrote: On 6/23/13 12:48 AM, Scott Weeks wrote: http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf That's rather a surprising choice (ATM product) for an IP network. Please describe what backbone you are running that uses a FASTLANE? I'd be surprised if a civilian org could buy a fastlane device,.. maybe they moved out of the gov't only world though since the last time I saw one? It does claim to do oc-48 rate sonet though. http://www.gdc4s.com/kg-530.html claims 40gbps... I don't know that a purely civilian org can purchase these though, nor the kg-75, despite these being on the GD site. And at $189,950 MSRP, obviously every ISP is dashing out the door for a pair for each and every long haul fiber link. ;-) Hard to see the IETF multi-vendor interoperability specifications. It does mention SNMPv3, unlike all their other products which use a proprietary management scheme. Also HTTP, although no mention of its purpose. At least the FASTLANE mentioned above specifies FIREFLY -- the mere rumor of which was our basis for naming Photuris [RFC2522]. Hopefully, other folks are securing their PPP or ethernet packets? But I don't see where you mention that Google is actually using these to secure your fiber?
Re: Security over SONET/SDH
On 6/23/13 12:48 AM, Scott Weeks wrote: By security protocol do you mean encrypting the traffic? Like what a Fastlane does? http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf That's rather a surprising choice (ATM product) for an IP network. Please describe what backbone you are running that uses a FASTLANE? Hopefully, other folks are securing their PPP or ethernet packets?
Security over SONET/SDH
What security protocols are folks using to protect SONET/SDH? At what speeds?
how in the hell did that ever work? [was: huawei]
On 6/14/13 2:57 PM, Michael Thomas wrote: On 06/14/2013 11:35 AM, Scott Helms wrote: In $random_deployment they have no idea what the topology is and odd behavior is *always *noticed over time. The amount of time it would take to transmit useful information would nearly guarantees someone noticing and the more successful the exploit was the more chance for discovery there would be. As a software developer for many, many years, I can guarantee you that is categorically wrong. I'd venture to say you probably don't even notice half. And that's for things that are just bugs or misfeatures. Something that was purposeful and done by people who know what they're doing... your odds in Vegas are better IMO. Mike, who's seen way too many "how in the hell did that ever work?" Ah, how well I remember the '91 Interop. One new dialup network access server worked great everywhere -- except going through 3Com routers. Something wrong with 3Com routers? Ha! No, after a lot of network packet debugging, it turned out the NAS was setting IP version to 0. (A tiny bug in a compile.) Only 3Com was checking the IP version! That is, by definition, only 3Com routers actually worked properly!!! And we had a lot more router vendors in those days
Re: Muni network ownership and the Fourth
I'd like to join Jay, Scott, Leo, and presumably Dave supporting muni network ownership -- or at least a not-for-profit entity. I tried to start one a decade ago, but a lawsuit was threatened by the incumbent cable provider (MediaOne in those days) who claimed an exclusive right. Since then the state law has been changed, so we really ought to look into it again here. Although the 4th Amendment originally applied to only the Federal Government (states routinely violated it), the 14th Amendment applies it to the state (and local) governments now.
Re: Looking for success stories in Qwest/Centurylink land
On 1/29/13 8:30 AM, Rob McEwen wrote: On 1/29/2013 7:43 AM, William Allen Simpson wrote: The graft and corruption was in *private* industry, not the Federal government, due to lack of regulation and oversight. I never said there wasn't graft and corruption in private industry... but that is anecdotal... "hit and miss". In contrast, graft and corruption in the Federal Government is widespread and rampant. Finding one example of graft and corruption in private industry is a silly way to try to disprove my point. Actually, "graft and corruption in the Federal Government" is very rare. State and local government is more common, and the Feds are usually needed to clean up afterward. Note the Kwame Kilpatrick public corruption trial (a big deal around here) And of course, corruption is incredibly common in the private sector, notably the financial services industry, the realty developer industry, etc. Ummm, none of these were on the FCC. Some were on the "stacked" Republican F*E*C. And nobody trusts Spakovsky, the architect of voter caging, purges, and suppression -- who was (as we now know) illegally recess appointed to the FEC, and whose nomination was withdrawn after disclosure of conflict of interest and the resignation of half the Justice Department voter section staff! I think you've gone off topic here. The bottom line is that the FCC of the past few years has TRIED to make a crusade out of supposedly protecting us against those meany ISPs' allegedly unfair bandwidth allocation practices... with their proposed solution of "net neutrality"... but, in reality, "net neutrality" is really just a Federal Government power grab where they can then trample the 4th amendment. Huh? You cited a WSJ opinion piece as from the FCC, when it was FEC, and they are very different entities. Yet you claim I'm off-topic? Net Neutrality has nothing what-so-ever to do with the 4th Amendment. Why would they do that? Because the current administration is crawling with statist thugs, that is why. They can't help themselves. it is in their blood. (notice that I'm NOT defending the Republican administration FCC, nor do I care to. You seem very confused, and have devolved into ill-informed racist anti-Obama diatribe that has no place on this list. Your example is besides the point and not relevant to this conversation. But the attempted "net neutrality" power grab is relevant. Notice ALSO that neither do I defend all practices of ISPs' bandwidth allocations. But, again, their customers do have the option to "vote with their wallets". Such options are lost with a Federal Gov't monopoly.) The Internet was developed by the Federal Government. I started my first TCP/IP implementation in 1979 on a NOAA+EPA grant; I wrote the legislative boilerplate that provided funding for the NSFnet, and convinced Michigan legislators to support it; then went on to write many technical standards; and built an ISP starting in 1994. The NSFnet wouldn't have been possible without a Federal prosecution, and the resulting AT&T Green decision. With today's oligopolies, there's no way to vote with your wallet. I'm done with this thread. Please don't feed the troll.
Re: Looking for success stories in Qwest/Centurylink land
On 1/29/13 1:20 AM, Rob McEwen wrote: [...] the US Federal government: (A) ...cannot do a darn thing without MASSIVE graft & corruption... plus massive overruns in costs... including a HEAVY dose of "crony capitalism" where, often, the companies who get the contracts are the ones who pad the wallets of the politicians in charge. [...] Ummm, this isn't true. As all of us old enough to remember know, the ILECs promised that with *REDUCED* regulation they'd roll out universal broadband IFF they were given the revenues from DSL -- putting the CLECs and small ISPs out of the broadband business. The graft and corruption was in *private* industry, not the Federal government, due to lack of regulation and oversight. (B) In the US, we have this thing called the 4th amendment which ensures a certain level of freedom and civil liberties and privacy. Unfortunately, 4th amendment rights essentially disappear if the US Federal government owns and operates broadband access. [...] No, this isn't true either. The 4th Amendment applies to the US government. What happened is the end-around allowing *private* industry to collect personal data and infringe civil liberties. That should not happen with direct US government ownership. It could be a boon to civil liberties. (C) This allows them to do what the FCC ACTIVELY trying to do recently, but hasn't yet found a way. [...] Here is an article written by 8 former FCC chairmen about the "Disclose Act": http://online.wsj.com/article/SB10001424052748703460404575244772070710374.html ...can any sane person read that article... and then trust the US Federal Gov't motives with owning/operating vast amounts of Broadband? Ummm, none of these were on the FCC. Some were on the "stacked" Republican F*E*C. And nobody trusts Spakovsky, the architect of voter caging, purges, and suppression -- who was (as we now know) illegally recess appointed to the FEC, and whose nomination was withdrawn after disclosure of conflict of interest and the resignation of half the Justice Department voter section staff! Finally, while I've witnessed incompetence amongst certain unnamed baby bells, there ARE... MANY... bright spots in Internet connectivity. Frankly, we're spoiled by our successes. And the worst of the baby bells, like all baby bells, do NOT have a monopoly. [...] You seem to be living in an alternate universe. Those of us who actually owned an ISP know the ILEC oligopolies well. The one bright spot, Google Fiber, does help Internet connectivity, but doesn't help ISPs. And this is the list for operators.
Re: Looking for success stories in Qwest/Centurylink land
On 1/28/13 8:06 PM, Randy Bush wrote: Anybody have some happy success stories to share about service in Qwest service area post Centurylink acquisition? yes. switched my WA residential to comcast. *much* happier. Thanks, that made me laugh. Myself, for residential, have long left ATT/SBC/Ameritech behind, and used Comcast (nee MediaOne) for years, but am now happiest with WOW (wowway). On the ATT front, I had a campaign this past fall that setup its headquarters in a strip mall. Very time sensitive, campaigns need short term office space for about 2 months. Actually, *this* campaign (you really want to watch this video): https://www.youtube.com/watch?v=v52FLMOPSig No Comcast or anything other than ATT available. But the site was a former bank (it moved to the other end of the strip mall), and there are lots of T1 terminal blocks all ready to go, and the site has lots of wiring in place. So, no problem? HA! Getting them to sell you service: No, sorry, no actual T1s anymore. No U-Verse available (yet I can see the U-Verse labels in the neighborhood on the other side of the fence), they only offer business ADSL over those lines now, 3 times the price of U-Verse at less than half the speed. (We didn't want ADSL, because we're running our own VoIP phones and Google Voice, so preferred symmetric bandwidth.) Getting them to install service: I can read them the block and circuit labels 'til I'm blue in the face, but they have to roll a truck. The order specifically says they have to call my cell an hour in advance so I can get there and have maintenance open the dmarc. They don't call. Heck, they don't come to the right place -- apparently something in the master list tells them the bank has moved, so they go to the bank -- wrong location and different dmarc door. Again, and again, and again! Finally, after daily calls for a week, and 30+ hours of my time, a very helpful customer support Democrat in Las Vegas puts all the right things in place, and helpfully calls me during the install to ensure it's actually starting, as the truck rolls up. Bless her!!! The installer also explains that nobody likes to call in advance, because those trips cut down on their daily total, and lots of them are really treated like "independent" contractors. Unlike the old days, they don't have any responsibility for their own areas and that's why the dmarcs have fallen into utter disrepair. It's not the longest or worst install I've ever had -- that prize goes to the old Bell South -- but pretty high profile nerve wracking. Yet ATT kept trying to bill for the week without service. Anyway, she did win the election :-)
Re: TCP time_wait and port exhaustion for servers
On 12/6/12 10:20 AM, Kyrian wrote: Also, if you are going to hack the kernel to make that change, I urge you to make it part of the sysctl mechanism as well, and to send a patch back to the kernel developers to help out others who might be in a similar situation to you. This is both to help the community, and give you an easier means to tweak the setting as needed in future without a further kernel recompile. Of course, this whole problem would have gone away years ago, had more folks implemented RFC6013. Or prior recommendations going back 15+ years. Meanwhile, my experience with the Linux kernel team is that about 1/2 of the tweak will go in, and the rest will fall by the wayside. Only about 1/3 of RFC6013 made it into 2.6.32, even though I started feeding them code 6 months before publication.
Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can.
On 11/30/12 5:15 PM, Naslund, Steve wrote: Well, in that case I am really worried that the cops might charge me with a crime. They took my computers and are looking at them. I did not do anything wrong but just in case they decide to charge me with a crime, please send me some money. As well you could be, because you appear to have the same name as a registered sex offender: http://www.sexoffenderin.com/reg110698/steven_w_naslundmugshot.htm On 11/29/12 6:39 PM, Naslund, Steve wrote: # As a long time service provider ... # # my many years of experience in engineering ARPANET, MILNET, and the # Internet I would have to guess that most Tor servers are used for no # good much more than they are protecting anyone's privacy. I'm surprised that medline.com is offering network access as an ISP? Admittedly, you began posting to NANOG in 2002 as: Network Engineering Manager Hosting.com - Chicago While I was involved in engineering NSFnet and the Internet and was an "original" member of NANOG, but I don't remember you. Of course, I'm notoriously bad with names. OTOH, I have met, remember, and greatly respect the Tor engineers.
Re: Verizon's New Repair Method: Plastic Garbage Bags
On 8/20/12 4:15 PM, R. Benjamin Kessler wrote: Quality Union work! Actually, probably *not* union. And that's the problem! Remember, Verizon has been "laying off" a lot of "old hands" and making them become "independent contractors" -- so that it can hire non-union under-paid workers. A quick search shows that this has been going on for years: 2001: http://news.cnet.com/Verizon-to-lay-off-10,000-workers/2110-1033_3-252215.html 2012: http://thinkprogress.org/economy/2012/06/04/494469/verizon-layoff-ceo-pay/ "Verizon To Lay Off 1,700 Workers After Paying CEO $22 Million Last Year" "In 2011, the company’s shareholders saw an 18.8 percent increase in the value of their returns. Workers, however, have not shared in those gains. Verizon eliminated 26,000 jobs over a two-year period in 2008 and 2009 — including 16,000 jobs in 2009 alone — and laid off roughly 13,000 more in 2010."
U.S. spy agencies ... email for cybersecurity
Somebody needs to give them a clue-by-four. The private sector already has the "Internet address where an email ... originated"; it's already in the Received lines. We don't need to be informed about it, we already inform each other about it. And it's already delivered "at network speed." It is my understanding the Dept of Homeland Security already cooperates in sharing government intrusion information. We certainly don't need a "U.S. spy agency" MITM to "protect the private sector." Moreover, the US is the source of most spam and malware, so the NSA isn't really going to be much help. And the US is the source of the only known cyber attacks on other country's infrastructure, so it's not likely much help there, either. Unless they expect retaliation? === http://in.reuters.com/article/2012/07/10/net-us-usa-security-cyber-idINBRE86901620120710 U.S. spy agencies say won't read Americans' email for cybersecurity 8:48pm EDT By Tabassum Zakaria and David Alexander WASHINGTON (Reuters) - The head of the U.S. spy agency that eavesdrops on electronic communications overseas sought on Monday to reassure Americans that the National Security Agency would not read their personal email if a new cybersecurity law was enacted to allow private companies to share information with the government. ... But to help protect the private sector, he said it was important that the intelligence agency be able to inform them about the type of malicious software and other cyber intrusions it is seeing and hear from companies about what they see breaching the protective measures on their computer networks. "It doesn't require the government to read their mail or your mail to do that. It requires them, the Internet service provider or that company, to tell us that that type of event is going on at this time. And it has to be at network speed if you're going to stop it," Alexander said. He said the information the government was seeking was the Internet address where an email containing malicious software originated and where it traveled to, not the content of the email. ... But the U.S. government is also concerned about the possibility of a cyber attack from adversaries on critical infrastructure such as the power grid or transportation systems.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 1/11/12 9:58 AM, Masataka Ohta wrote: A better default could be that IGP will be automatically invoked if DHCP does not supply a default router. That's ridiculous. You need some link state to even find a DHCP server. So, the very idea that DHCP would tell you where your routers are is preposterous on its face. Besides, that's terrible system design. You should never design a system where some code paths aren't exercised regularly. If there are multiple IGPs are implemented, snooping IGPs' advertisement to know which is the locally available IGP may also be a good idea. My point w.r.t. multiple next hop routers is that RA supplied information is not good enough, which means DHCP is no worse than RA even if there are multiple next hop routers. I've not read the whole thread yet (I had read the start what seems to be weeks ago), but I'll pipe up here and point out that in my _original_ design, every host was running a link state IGP. Even without any router at all, you need link state to handle mobile nodes, hidden terminals, partitioned networks, satellite versus land-line unidirectional links, etc, etc, etc. Of course, all that was ripped out by the ignorant folks who came later. Thus, IPv6 is much worse at self-configuration, security, mobility, and *everything* than originally envisioned.
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!]
On 12/6/11 12:00 PM, Eric Tykwinski wrote: Maybe it's just me, but I would think that simply getting them listed on stopbadware.org and other similar sites would probably have much more of an effect. The bad publicity can cause them to change tactics, but it takes some time. I've seen much quicker results from blacklisting on Google and other search engines. I've reported it as a malware site via Firefox. Have you? But the whole site should be scanned for other/similar malware, and blocked accordingly. Probably a harder problem, as it gives different downloads depending on browser and OS.
Re: Facebook insecure by design
On 10/2/11 12:36 PM, Jimmy Hess wrote: On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas wrote: I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to. My understanding of his statement is that Facebook itself is the MITM, collecting all our personal information. Too true.
Facebook insecure by design
In accord with the recent thread, "facebook spying on us?" We should also worry about other spying on us. Without some sort of rudimentary security, all that personally identifiable information is exposed on our ISP networks, over WiFi, etc. Facebook claims to be able to run over TLS connections. Not so much (see attached picture). This wasn't an "app", this is the simple default content of a page accessed after a Google search. https://www.facebook.com/ceelogreen <>
Re: Nxdomain redirect revenue
On 9/27/11 11:41 AM, Rubens Kuhl wrote: On Tue, Sep 27, 2011 at 11:48 AM, wrote: On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said: It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense. Citation? Could tampering with DNSSEC and/or TLS fall into DMCA grounds ? Good thought, but I was thinking more along the lines of UETA and E-SIGN, along with the usual criminal penalties for forgery and fraud (and intent to defraud). I'm pretty sure those are state by state. On the US Federal level, there's 18 USC 2511 - Interception and disclosure of wire, oral, or electronic communications prohibited. In any case, there's plenty of law to choose, we simply need a solid test case. Family members are Wide Open West (WOW) subscribers, and they are listed among the miscreant companies that Heather linked. I'd happily be a plaintiff based on my use of their network, but we probably need some actual affected subscribers.
Re: Nxdomain redirect revenue
On 9/26/11 4:29 AM, Florian Weimer wrote: Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.) I responded: Has anybody tried bringing a criminal complaint for interference with computer (network) data? Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it? Arguably, substituting a false reply for NXDOMAIN would be, too. It's time to find a champion to lead the charge. Maybe Google? On 9/27/11 12:34 PM, Schiller, Heather A top posted: Paxfire gets sued: http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html http://www.courthousenews.com/2011/08/08/38796.htm http://www.pcmag.com/article2/0,2817,2390529,00.asp Paxfire files counter suit: http://www.techdirt.com/articles/20110809/17305215460/paxfire-responds-says-it-doesnt-hijack-searches-will-seek-sanctions-against-lawyers.shtml http://www.techdirt.com/articles/20110906/03371515808/paxfire-sues-lawyers-individual-who-filed-class-action-lawsuit-over-its-search-redirects.shtml http://www.prweb.com/releases/2011/9/prweb8765163.htm Thanks, Heather, I didn't know/remember about the civil suit. Good start. But I'm talking about criminal. They're different.
Re: Nxdomain redirect revenue
On 9/27/11 7:50 AM, Jimmy Hess wrote: On Tue, Sep 27, 2011 at 3:57 AM, William Allen Simpson wrote: [snip] Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it? I would rather see DNSSEC and TLS/HTTPS get implemented end to end. They are. The last thing we need is a court to step in and say "It's not legal for an ISP to blacklist, block, or redirect traffic, to any hostname or IP address." Don't distort my words. It amuses me when so-called conservative cyber-libertarians hate the idea of courts stepping in to enforce laws, except the laws governing their own contracts enforcing payments regardless of the quality of their goods. The cable and satellite industry forced through digital protection acts -- to protect their revenue streams. Now, it's time to use those acts against them. It's not legal for an ISP to modify computer data. Especially digitally signed data. That's a criminal offense. It's not legal for a vendor to sell or give away equipment that aids interception and modification of data. That's a criminal offense. Most likely the ISPs' lawyers were smart enough to include a clause in the ToS/AUP allowing the ISP to intercept, blackhole, or redirect access to any hostname or IP address. It's not legal to insert a clause allowing criminal conduct. There's no safe haven for criminal conduct. The name for an ISP intercepting traffic from its own users is not "interference" or "DoS", because they're breaking the operation of (er) only their own network. No, they're breaking the operation of my network and my computers. My network connects to their network. The solution is to spread their name as widely as possible, so consumers can make an informed choice if they wish to avoid service providers that engage in abusive practices, and bring it attention to regulators if the service providers are acting as an abusive monopoly in regards to their interception practices. There are no choices. They *are* abusive monopolies. Why are "regulators" better than courts? After all, the regulators will also involve courts.
Re: Nxdomain redirect revenue
On 9/26/11 4:29 AM, Florian Weimer wrote: Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.) Has anybody tried bringing a criminal complaint for interference with computer (network) data? Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it? Arguably, substituting a false reply for NXDOMAIN would be, too. It's time to find a champion to lead the charge. Maybe Google?
Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)
On 9/11/11 11:28 PM, Christopher Morrow wrote: On Sun, Sep 11, 2011 at 11:06 PM, Hughes, Scott GRE-MG wrote: Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.) So, part of my point here about ev/dv/etc certs is that in almost all cases of consumer fraud and protection, HTTPS is never used. Hell, half the spams I get are http://IP_ADDRESS/somethign/something/something.php ... Falling back on the 'well ev certs are there to provide protection to the consumer' is just FUD (I think). again, not seeing a benefit here... Normally, I heart my Mac. But Apple in its infinite wisdom decided that EV certificates are so much better, they refused to honor my edit of my own system keychain! So, negative benefit for the consumer.
Re: dynamic or static IPv6 prefixes to residential customers
On 8/3/11 4:13 AM, Owen DeLong wrote: I agree that autoconf is desirable. Now, please explain to me why it is desirable for the address to change at random intervals from the customer perspective? (i.e. why would one want dynamic rather than static auto configuration?) Because IPv6 was originally designed with the goal of completely transparent renumbering. Indeed, after many WG meetings over many years debating renumbering and all the problems that entailed for IPv4, some of my drafts proposed that IANA would renumber IPv6 for every ISP and IX at regular intervals! Thus, enforcing that all the dynamic configuration protocols actually work. :-) And nobody starts issuing licenses based on IP addresses anymore. :-(
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On 7/10/11 6:29 PM, Randy Bush wrote: The IETF is run by volunteers. They volunteer because they find designing protocols to be fun. For the most part, operators are not entertained by designing network protocols. So, for the most part they don't partiticpate. Randy Bush, "Editorial zone: Into the Future with the Internet Vendor Task Force: a very curmudgeonly view, or testing spaghetti," ACM SIGCOMM Computer Communication Review Volume 35 Issue 5, October 2005. http://archive.psg.com/051000.ccr-ivtf.html I agree with Randy. Well, that's no surprise, I usually agree with Randy. But I didn't know/remember that he'd managed to get his rant published! Good work But the problem has been pretty apparent since circa 1991. I remember calls for an Internet Operator's Task Force (IOTF) to parallel IETF sometime in '92 or '93. Folks have asked me from time to time why I stopped participating in the IETF a decade or so ago. My usual tongue-in-cheek reply is, "it's more important to use the protocols we already have before we build more." (CF. nukes.) IPv6 was certainly a part of it (as was security). As I remind folks from time to time, I'm the guy that originally registered v6 with IANA. But PIPE->SIP->SIPP was a much simpler, shorter, cleaner extension using 64-bit addresses. My proposal used the upper 32-bits extending the then 16-bit BGP ASN, making addresses match topology, shrinking the routing tables Although I *do* find designing protocols to be fun, these days I only post Experimental drafts. There are committees (dysfunctional "working groups") where the chair cannot get his own drafts through the process in under 4 years. It took about 7 years to publish the group negotiation extension to SSH, many years after it was shipping. It's no wonder that operators don't want to participate.
Re: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for internal address space)
On 5/26/11 11:23 PM, David Conrad wrote: On May 26, 2011, at 5:14 PM, Wil Schultz wrote: Out of curiosity, is there an IPv6 stack for ham devices? Well there's a loaded question. ... I won't say that there aren't "ham devices" with an IP stack built in, but I think we're talking about different layers here. Sorry, poorly worded. What I was wondering is there is an equivalent of KA9Q for IPv6. I believe one of the comments we got back when we were trying to reclaim 44/8 was that folks couldn't migrate to IPv6 because no software was available... Well, I wrote a lot of the original IPv6 stuff (back when it was PIPE -> SIP -> SIPP) for KA9Q, have the source around here somewhere But now I'd just use Linux. Alan Cox ported the KA9Q AX25 code long ago. Since everybody and his brother is coming out of the woodwork -- sadly, I've not done any AX25 since my grandfather Marvin Allen Maten (W8TQP) died; that was one of the things we did together. Although he was a ham since circa 1916, he was always wanting to try the latest! His QSL contacts went back so far, he knew Hugo Gernsback and his brother (who actually ran the electronics store).
Re: 23,000 IP addresses
On 5/10/11 10:35 PM, Mark Radabaugh wrote: Facebook charges $150.00 (not a great link but http://lawyerist.com/subpoena-facebook-information/ Sorry, that's old and incorrect. Finding that on facebook's site is difficult. Other sites have Facebook charging $250 to $500 for civil subpoena fees. http://www.facebook.com/help/?faq=17159 ... you must personally serve a valid California or Federal subpoena on Facebook. Out-of-state civil subpoenas must be domesticated in California. ... Facebook charges a mandatory fee of $500.00 per user account. Please enclose payment with your properly served subpoenas. A custodian declaration will be included with the return of materials, if any. Notarized declarations carry an additional $100.00 fee. http://www.facebook.com/help/?faq=17160 Facebook requires a minimum of 30 days to process a civil subpoena. Additional time may be required depending on various factors. You may request your subpoena be expedited by submitting an additional $200.00 fee with your subpoena. Courts like precedent. I choose Facebook's precedent. Seems reasonable to me. That's also roughly in line with Nextel and others for CALEA.
Re: gmail dropping mesages
On 4/21/11 9:24 PM, Bill Blackford wrote: I've recently observed gmail dropping messages or not forwarding all messages/posts from the nanog list. This is rather annoying. Has anyone else experienced this? Does anyone have any insight as to why? I've read the thread, and ironically all messages from Franck Martin in this thread were sent to spam by gmail. None of the others! This is like an earlier thread: Previous Message Subject: Re: sudden low spam levels? Date: Tue, 04 Jan 2011 10:10:24 -0500 From: William Allen Simpson To: nanog@nanog.org On 1/3/11 6:42 PM, Jay Farrell wrote: > I noticed a substantial drop in spam in my gmail account in recent days, > from several hundred a day to maybe a hundred. Ironically, gmail filtered > this thread to my spam folder. > Yes, I found these messages my gmail spam today, too. Lately, gmail has been regularly flagging NANOG as spam, particularly the end of week CIDR and BGP reports.
Level 3 Agrees to Purchase Global Crossing
http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html The deal will combine two unprofitable companies with total revenue of $6.26 billion as of last year, and cut annualized capital spending by about $40 million, according to the statement. It will also help reduce the pressure on prices, which have declined by as much as 30 percent a year in the industry, said Donna Jaegers, an analyst at DA Davidson & Co. “This is what telecom has needed for a long time,” said Denver-based Jaegers, who recommends buying both stocks. “You have way too many players.”
Re: Why does abuse handling take so long ?
On 3/13/11 9:35 PM, goe...@anime.net wrote: the real cesspool is POC registries. i wish arin would start revoking allocations for entities with invalid POCs. Hear, hear! Leo's remembering the old days (80s - early '90s), when we checked whois and called each others' NOCs directly. That stopped working, and we started getting front line support, who's whole purpose was to filter. Nowadays, I've often been stuck in voice prompt or voice mail hell, unable to get anybody on the phone, and cannot get any response from email, either. Ever. The big ILECs are the worst. What we need is an "abuse" for ARIN, telling them the contacts don't work properly, which ARIN could verify, revoke the allocation, and send notice to the upstream telling them to withdraw the route immediately. Force them to go through the entire allocation process from the beginning, and always assign a new block. That might make them take notice And shrink the routing table! Win, win! Since we'd only send notification to ARIN about an actual problem, we'd only drop the real troublemakers. To help enforce that, ARIN would also verify the reporter's contacts. :-)
Re: Why does abuse handling take so long ?
On 3/13/11 7:45 AM, Alexander Maassen wrote: Why o why are isp's and hosters so ignorant in dealing with such issues and act like they do not care? Because network operators rarely get together and turn off routing to abusive hosting. On the few occasions that has happened, it took years of consensus building. So, part of the problem is *your* upstream. Why didn't your upstream actively remove the entire abusive netblock? Why didn't your upstream contact other providers with your evidence, and together remove the abusive network from the global routing tables? As we get more experience with global "cyberwar", we're going to need faster response mechanisms. What will we do as some major government coordinates an attack on another? What will we do as some major North American government coordinates an attack on another region or facility?
Re: NIST IPv6 document
On 1/6/11 1:47 AM, Paul Ferguson wrote: As someone who has been immersed in security for many years now, and having previously been very intimately involved in the network ops community for equally many years, I have to agree with Roland here. Just because a lot of smart people have worked on IPv6 for many years does not mean that the security issues have been equally well thought out. ... This is not meant as a slight to anyone -- just a realization of looking at security from a real-world perspective. It seems to always have to get "bolted on" as an afterthought, instead of baked-in from the beginning. I've not read everything in this thread yet. So, this may have already been mentioned. But Security *was* baked-in from the beginning of IPv6. IT WAS TAKEN OUT! I was one of the original IPng PIPE->SIP->SIPP->IPv6 designers. We knew about *all* of these problems mentioned thus far in this thread. IPsec was originally designed for SIP->SIPP->IPv6, and I back-ported it to IPv4 after IPv6 was hijacked by committee. As to Neighbor Discovery, the original specifications eliminated ARP, DHCP, and OSPF, *and* routers knew all hosts on the local net, *and* both hosts and routers automatically renumbered. Everything that folks have asked for thus far. Google tells me that draft-ietf-sip-discovery-03.txt is still on-line. I've not found my -04, -05, or -06 on-line, so I've occasionally been looking through old backups lately as time allows. Sadly, those systems are long dead, and finding actual systems to read my old data makes the recovery process rather slow. Anyway, don't blame the original designers. We knew what we were doing! Blame the vendors (and their lackeys) that had vested interests in making IPv6 into IPv4 with bigger addresses, and *removing* security.
Re: sudden low spam levels?
On 1/3/11 6:42 PM, Jay Farrell wrote: I noticed a substantial drop in spam in my gmail account in recent days, from several hundred a day to maybe a hundred. Ironically, gmail filtered this thread to my spam folder. Yes, I found these messages my gmail spam today, too. Lately, gmail has been regularly flagging NANOG as spam, particularly the end of week CIDR and BGP reports.
Re: Muni Fiber Last Mile - a contrary opinion
On 12/23/10 12:27 PM, Jay Ashworth wrote: I was poking around to see what the current received wisdom was as to average install cost per building for suburban municipal home-run fiber, and ran across this article, which discusses the topic, and itemizes several large such deployments that "failed" or had to be sold private. I'd be interested to see what comments nanogers have on this piece. I'm not well enough read to critically evaluate the guy's assertions. http://www.digitalsociety.org/2010/03/why-municipal-fiber-has-not-succeeded/ Always consider the source. Didn't we just have a George Ou cite that was debunked on this list? Subject: RE: Level 3 Communications Issues Statement Concerning Comcast's Actions Reminder: ITIF is an ultra-conservative, anti-government outfit: http://mailman.nanog.org/pipermail/nanog/2009-November/015552.html ITIF doesn't give out information about its funding, which usually means it's industry lobbyist funded. Apparently in this case, big cable and probably big telco.
Re: Some truth about Comcast - WikiLeaks style
On 12/23/10 1:17 PM, Joel Jaeggli wrote:
On 12/23/10 9:19 AM, Jay Ashworth wrote:
And that's just another argument in favor of muni fiber -- since it's municipal,
it will by definition serve every address, and since it's monopoly, it will
enable competition by making it practical for competitors to start up, since
they'll have trival access to all comers.
Muni-fiber builds do not "by definition serve every address."
But to keep this on topic, Comcast doesn't serve every address either!
In Ann Arbor, Michigan (home of NANOG), I spent many hours attending the
local cable board meetings. Comcast refused to build toward various
*downtown* buildings, because the underground facilities would never pay
back the cost ("never" being upwards of 30 years). This is not just an
ex-urban issue.
When the board explored non-renewal of Comcast's franchise for failing to
comply with its contract, they learned that's almost impossible. Court
cases around the country side with the industry over municipalities.
In an unrelated Michigan case, where a large business signed a written
contract (to expand) in exchange for tax abatement (but didn't expand),
the Michigan Supreme Court ruled that the contract was mere "fluff and
hyperbole" required to obtain tax breaks and government favors.
http://www.michiganliberal.com/diary/7723/
It's a "right" to make taxpayers pick up the cost of subsidizing
private industry
Re: Some truth about Comcast - WikiLeaks style
On 12/20/10 9:07 PM, Steven Bellovin wrote: On Dec 20, 2010, at 8:51 01PM, JC Dill wrote: Do you have any cites saying that this was actually rolled out? Or did the project get cut during the financial crisis, and never actually rolled out? The issue I have with all these "cites" is that none of them are for services that are up and running. They are all press releases about something that will supposedly get built, maybe. Maybe I've lost the thread context, but if you're talking about FIOS it most certainly is running, in many places (http://www22.verizon.com/Residential/aboutFiOS/Overview.htm?CMP=DMC-CVS_ZZ_ZZ_E_TV_N_X001). My town has it; Comcast's responsiveness improved dramatically after FIOS was rolled out Speeds are good, prices less so, and if memory serves they charge something like $40/mo extra for static IP addresses. Heck, we've also had earlier pointers in the thread to competing cable providers! Where I founded an ISP, we used to have 2 competing cable providers, until one bought out the other over a decade ago. In Oakland County, Michigan, various pockets have WOW and Comcast and ATT. My family members there have WOW, having switched from Comcast or ATT. (IMnsHO, the only thing worse than Comcast is Ameritech/SBC/AT&T.) Once upon a time, I compared pricing with Ann Arbor (Washtenaw County), where Comcast (previously Media One) had no broadband competition. In Oakland County, Comcast prices were 20% or so less. Eventually, WOW raised prices to be just a little bit less than competitors -- just as Chrysler and GM used to raise prices following Ford -- and Comcast has gradually reduced the price difference between Oakland and Washtenaw. JC's supposition that competition functions at this level over the long term is egregiously fallacious. Fundamentally an oligopoly. As to "responsiveness", in my experience WOW (and Vonage) have *much* better customer service departments than Comcast or AT&T. Faster, friendlier, and more technically savvy. Comcast call centers apparently don't bother to check for multiple service outages in the same node, resulting in 5 (or more) truck rolls last week before they were finally fixed. Apparently, dispatchers don't have access to the NOC status information from modems, and only respond to actual repair calls from customers. If the customers cannot call because their VoIP is down, then there's nothing wrong?!?! But that's another gripe for another time. :-(
Re: Some truth about Comcast - WikiLeaks style
On 12/21/10 1:42 AM, Robert Bonomi wrote: Bzzt! It's -not- illegal to put a letter inside a FedEx box. It just has to have the appropriate (USPS) postage on it, _as_well_ as paying the FedEx service/delivery fee. This is true if it is just the letter you're sending, or if it is a sealed letter -inside- a box/package being shipped.. Now _live_scorpions_, on the other hand, are someting that the USPS _will_ delive, but AFAIK no 'express' service will handle. (One discovers some of the strangest things when one actually sits down and *reads* the _complete_ rules/regulation on a subject. In this case, it's the "Domestic Mail Manual". Scorpions are 'addressed' in 601.9.3.10) Kudos to you! It's been 20+ years since I've had a copy of the DMM! To bring this back to the topic at hand, the USPS has worked pretty well and fairly efficiently for 200+ years. It provides universal service to every (US) destination at uniform rates for all content, with some variation by size. Its competitors provide cherry-picked service only to specific areas, and even then at variable rates, by distance *and* by volume. As noted, FedEx simply doesn't deliver some types of content. The lesson here is that we need to decided what it is we are offering. As an ISP, we never offered different rates by distance or for different types of traffic. We did offer different rates for different sized pipes (aka volume). That is, we offered more USPS-like than FedEx-like service. And we certainly never expect to make more money from wealthier deliveries, because their content is possibly more valuable! AFAIK, FedEx doesn't either. The Comcast proposed business model is simply wrong, and unsustainable without essentially being a protection racket. Pay us more money or your service will be kneecapped We have laws against extortion.
Re: Some truth about Comcast - WikiLeaks style
On 12/17/10 12:08 PM, Dave Temkin wrote: George Bonser wrote: The municipality charges the cable company per HBO subscriber? The municipality gets a cut of that in a profit sharing agreement. The point was, everyone gets their tax or toll along the way. Dave, perhaps you would be kind enough to tell us where you operate a network and what municipality is able to charge "the cable company" based on a "profit sharing agreement". That would be against the law in Michigan. And I've never heard of any cable company revealing its profits on a per municipality basis
Re: Alacarte Cable and Geeks
On 12/18/10 7:27 PM, Kevin Oberman wrote: From: "Robert E. Seastrom" ... I can see a future where you buy internet from the cable co and they give you the basic cable TV channel lineup at "no charge" but in reality, you're paying for the cable internet what you used to pay for both cable internet and TV. Here in NoVA (Comcast former Adelpha territory), the future is now. I used to have internet-only service (there is little on TV that I care about). A bit over a year and a half ago, we added basic cable to the service. Total additional cost per month to go from Internet-only to Internet-plus-TV-bundle (same speed) was about $4. Hmmm. Better than the situation in my Comcast area. Internet w/o any cable costs MORE than basic cable (i.e. over the air + PEG). ... Likewise, here in Michigan I helped a brother setup Comcast, and discovered that the charge for Internet + Basic Cable was about $2 per month *cheaper* than Internet-only.
Re: Some truth about Comcast - WikiLeaks style
On 12/16/10 9:51 AM, Craig L Uebringer wrote: Funny thing about competition is that there are losers as well as winners. DSL competition didn't lose by regulation, it lost (nationally) by cheaper, more elastic bandwidth available on other media and JC's previously-noted fickle and lazy consumers. Apparently, you've never owned or run an ISP in the past dozen years Pacific Bell Telephone v. LinkLine, 07-512 It lost *precisely* by regulation: Google "Tauzin-Dingell". We used to offer up to 7 Mbps bidirectional DSL long before cable or the Bells offered anything in that range. We had our own DSLAMs. How exactly do you compete when the Incumbent charges us $80 per month wholesale for UNE lines that they sell $10 per month retail? http://www.techdirt.com/articles/20061228/181255.shtml http://www.dslreports.com/shownews/ATT-10-DSL-Today-84904 Note that's only $10 for "new" customers (that is, *our* customers). And that's just the tip of the iceberg: http://www.cybertelecom.org/broadband/dslnaked.htm org.law.rutgers.edu/publications/lawjournal/issues/38_1/Sholinsky.pdf ...
Re: Google mail admin contact needed (STARTTLS capabilities issue)
On 12/6/10 6:58 AM, Michael Wildpaner wrote: PIPELINING and STARTTLS are unrelated issues, and both are currently working as intended. - STARTTLS on MX is in the process of being rolled out and not visible from all client locations at this point. - PIPELINING is not offered under all circumstances. Hope this helps, maw Much appreciated. Could you let operators know where to look for the status as it's rolled out? Or keep us updated here? Since the client TLS (port 995) has been working for a long time, and the https is becoming the default (we used to have to specify it ourselves), getting MX transport secured is a good idea.
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
[Changed long CC list to BCC] On 12/2/10 12:49 AM, Frank Bulk wrote: George Ou touches on a similar point at the end of his article: http://www.digitalsociety.org/2010/11/level-3-outbid-akamai-on-netflix-by-re selling-stolen-bandwidth/ The Ou article makes no sense at all! It's based on the premise that Level 3 and Comcast are peering, and that traffic should be symmetric. Everywhere else, the articles and pundits indicate that Comcast is a transit customer of Level 3. All actual network operators know that traffic isn't symmetric! Ou's hit piece reads more like a pseudo-libertarian rant. In fact, other Ou posts listed there have titles that read like an ultra-conservative cum social-conservative rant: * Wrong On The Internet » Another Net Neutrality ‘violation’ debunked * Why Viacom and others justified in blocking Google TV * Wrong On The Internet » Genachowski pushing ahead with Net Neutrality during lame duck * Google hypocrisy on content blocking * Hijacking the Internet is trivial today You have to consider the source. If Ou doesn't understand contracts, peering, and/or transit, just take his posts with a grain of salt.
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
On 12/1/10 8:47 PM, William Herrin wrote: "Dual agency is not legal in all 50 states." Kinda the opposite of the monopoly/duopoly ISP who doesn't seek your permission in dealing with anyone else. Finally, realize that in both cases (real estate agent and apartment broker) you're dealing with a competitive negotiated process. The law allows -many- things in negotiated contracts that are flat illegal in the contracts of adhesion typically offered to the residential Internet buyer. I was going to reply to Derek, but William beat me to it. Excellent post.
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
I've read through the entire thread thus far, and there are several very interesting points. I'd like to know more about the Australian experiment? But there were a couple of disparate comments that seem highly related, so I'll reply to them jointly here: On 11/30/10 2:59 AM, JC Dill wrote: What is happening now between L3 and Comcast also reminds me of the dial-tone settlement deals in the 1990s. The big telcos thought they could push small telcos out by making it more expensive to place calls (paying a fee to the telco that "terminates" the call) and less expensive to receive calls (receiving the termination fee). They mistakenly thought the startup telcos would go after consumers (who typically place more calls than they receive) and they didn't think about startup telcos going after ISP dial-up services (which receive more calls than they place) and then being forced to pay those startups settlement fees for all the calls their consumer customers made into the startup telco's ISP customer's modem banks. But I remember what happened next. BellSouth refused to pay their settlements. The CLECs sued and went bankrupt. BellSouth had deeper pockets and more lawyers. We don't have an interstate telephone settlement system or PUC to "decide" what the rules will be for settlements between content providers and eyeball providers. I believe that in the end it will come down to market forces and which group can better marshal customer angst to their side when packets don't flow freely between these two types of networks. Maybe. But I'm hoping the consumer angst gives us a better FCC. The "market" hasn't worked before, and isn't working in this case. So, maybe there isn't a "market" after all On 11/30/10 2:47 AM, Kevin Blackham wrote: > I'm not convinced. Either I'm calculating something wrong, or greed is at work. Greed. Reminder: Comcast drastically raised their rates a few years back, saying to local cable commissions that they needed to "invest" in digital infrastructure. Instead, they took the massive profits and invested in NBC/Universal. When a cable "node" is an entire neighborhood of 500+ homes, because Comcast never bothered to split the nodes down to a reasonable networking size (as opposed to CATV-sized), then it's a Comcast greed problem A half year ago or so, talking with a Google manager about a certain fiber project, we ended up arguing about the size of cable nodes. He seemed to think everywhere was like Mountain View. I was trying not to embarrass him; just let it stand at -- as you drive, you don't look overhead at the cable infrastructure much, do you? (He admitted he doesn't.) On 11/29/10 11:27 PM, Jared Mauch wrote: > The issue here is cost of infrastructure. The last mile generally is more valuable than the long-distance part. Everyone can build a nationwide network for a nominal amount of money. All the carriers can provide circuits at the same IXPs where you can public/private peer. The question does become, who is in those smaller and mid-markets. Not everyone is going to build fiber in Akron, Eugene, nor Madison. It gets even more interesting if you look at what happened with Fairpoint in the northeast IMHO. Verizon realized they would not make money there and sold it off. The promises and costs consumed them and forced bankruptcy. > > I'm not saying that will happen to Comcast, but it may cause them to divest the unprofitable parts as well, leaving some parts of the country worse-off than we would be today. > Or in this case, invest in something else more profitable, NBC/Universal; and then try to leverage their customer base to gouge their CDN competitors. I'd like to see Level 3 pull a Disney/ABC or a Murdock/Fox, and publicly announce that they expect Comcast to share *their* revenue. And be willing to pull the plug! (Admittedly, I thought Disney/ABC and Murdock/Fox are evil, too. That model was only reasonable as the CATV channels had no advertising. All we have left now is Turner Classic Movies. A pox on *all* their houses!) It's really time for some anti-trust legislation/regulation. The last mile market has failed.
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On 9/13/10 5:39 PM, Sean Donelan wrote: On Mon, 13 Sep 2010, Barry Shein wrote: In the "early internet", let's call that prior to 1990, the hierarchy wasn't price etc, it was: 1. ARPA/ONR (and later NSF) Research sites and actual network research 2. Faculty with funding from 1 at major university research sites 3. Faculty with funding from 1 at not so major universities 4. Faculty at 2 and 3 w/o actual research grants from 1 4. Students at 2 and 3 (tho less so at 3) 5. Everyone else who managed to sneak onto the net (DEC salesmen etc) People worried a fair amount about bandwidth on a network with a 56kb backbone. And those thoughts tended to turn to those hierarchies. And don't forget the research & education network folks almost always charged commercial institutions a "premium" (sometimes called a "donation") to connect to the Internet in the early days. Even in the early 1990's during privatization, ANS charged differentiated pricing with educational instituations being charged less and commercial institutions being charged more. During the pre-1990's, I doubt any of the Internet "founders" were thinking of how to pay for networks other than asking for more grant money. ARPA and friends paid the bills, and asked for things like TOS/COS long before DiffServ because the military likes to prioritize things for all sorts of reasons besides price. Another dinosaur speaking. I spent some 8 years in the '80s-'90s looking at pricing for the Michigan House Fiscal Agency, and wrote the legislative boilerplate for funding the Michigan NSFnet contribution. If you think of Cerf et alia as the "fathers" of the Internet, think of me as the midwife Barry is correct. Sean is partly correct (we talked about funding beyond grants). ATT is simply wrong. While we talked *a* *lot* about public-private partnerships, we *never* agreed on pricing per packet. On the contrary, whenever it was discussed, that was shot down. Vigorously! Vociferously! Micro economists Hal Varian and Jeff MacKie-Mason were *not* Internet founders! Every so often, I like to brag that for a $5 million annual initial investment, we saved Michigan alone $100 million in telecommunication and computing costs over the first few years. ATT + Ameritech + CWA *hated* me! (As did some of the department folks that justified their salaries and empire building by the dollar totals that flowed through their department.) Reminder: when we specified the first few PPP Over ISDN products, we assumed bits are bits are bits. Then the "I Smell Dollars Now" incumbents decided "data" bits were more valuable than "voice" bits. We went back to the drawing board, and *CHANGED* the specification to require the capability to send PPP Over ISDN voice without losing to robbed bit signaling (56Kbps), so that we could provision around the pricing problem. But there's only so much we can do technically, when they use lawyers and lobbying to outlaw our technical solutions that route around problems. ISPs really need to re-invigorate the old CIX, ISP/C, whatever. Otherwise, you will not survive as NANOG.
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On 9/3/10 7:43 AM, Matthias Flittner wrote: >> Since recently we noticed "Neighbour table overflow" warnings from >> the kernel on a lot of Linux machines. As this was very annoying for >> us and our customers I started to dump traffic and tried to find the >> cause. > sounds for me as an typicall IPv6 DoS attack. (see RFC3756) > > Sheng Jiang has discussed this issue in his draft: > http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 > That's what happens when you rip all the security assumptions and requirements out of neighbor discovery! The original design wasn't subject to any of these problems, because: (1) Every request was assumed to be authenticated. Every system was assumed to have a public/private key pair, or a unique secret burned-in at manufacture, paired with its MAC address. A thing you have and a thing you know. [There were supposed exceptions for light bulbs, but good security practices dictate that light bulbs aren't globally accessible. Nowadays, I wouldn't agree to a light bulb exception, as even the puniest system on a chip has plenty of room to store a key pair, and far more processing power than we were using in the old pizza box sized cell phones!] (2) Every router wouldn't send anything from upstream until the downstream had registered its local address and been assigned one or more global dynamic addresses. Back in the day, we'd already seen subnets bigger than the 30 allowed by thinnet, we actually discussed the ARP pollution problem, and we designed to eliminate it. And by "we", I don't include the folks that mangled present-day neighbor discovery. I used to have a recording of one of them made at Xerox PARC claiming the existing ethernet process was good enough, we didn't need that extra stuff for security, mobility, unidirectional satellite links, hidden (radio) terminals, etc. On 9/3/10 9:07 AM, Matthias Flittner wrote: typically this fill the NC with faked entries and exhaust the node's cache resources. "This interrupts the normal functions of the targeted IPv6 node." In other words: The attacker sends a lot of ICMPv6 echo requests to your /64 subnet. Your router has to resolve this addresses internaly (each NA is stored in NC of the router). The node's cace resources are exhausted and no "normal" NA could be stored. I think that was your problem. Unfortunately is there no standardized way to mitigate this attacks, yet. However there are many approaches which could help or could be discussed. (like http://www.freepatentsonline.com/20070130427.pdf or other) That caused me to burst out laughing! Wow, all it takes is another 15 years, and more folk just rediscover lessons learned in the first 15 years Now, they "patent" it. Kinda fails the "skilled in the art" test.
Re: Did your BGP crash today?
On 8/29/10 3:23 AM, Mikael Abrahamsson wrote: On Sat, 28 Aug 2010, Brett Frankenberger wrote: The implementor is to blame becuase the code he wrote send out BGP messages which were not properly formed. People talk about not dropping sessions but instead dropping malformed messages. This is not safe. We've seen ISIS (which is TLV based and *can* drop individual messages) been wrongly implemented and platforms drop the entire ISIS *packet* instead of the individual message when seeing something malformed (or rather in this case, ISIS multi topology which the implementation didn't understand), and this made the link state database go out of sync and miss information for things it actually should have understood. Reminder: TCP itself has also "been wrongly implemented" with horrid consequences. Unknown TCP options are supposed to be silently discarded. Instead, some middlebox vendors simply copy them into the return packet. There are some circumstances where it makes sense to silently discard one TLV option, and others where it makes sense to discard the whole packet, and still others where it makes sense to drop the session. A problem is that many of the early designers (BGP is a fairly early design) used one-size-fits-all error handling. There's not much anybody can do about bad implementation (as in this case) that corrupts data. But a lot more thought needs to go into error recovery! This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable. Personally, I've usually advocated returning an error message. Many of the protocols I've developed use this approach. (Please forgive RADIUS, which for some odd reason is my most frequently cited work according to Google. My original draft had a Reject, subsequent WG activity took it away. All I could do is throw up my hands and walk away.)
Re: On another security note... (of sorts)
On 7/19/10 10:21 AM, valdis.kletni...@vt.edu wrote: ... my credit card is declined and flagged (I find out later) by my bank's anti-fraud group because it's being used 3 states away from where it's usually used. ... Or in my recent case, I used my card multiple times in California in April, and the next time was trying to make a *deposit* back home in Michigan a month or so later. Card rejected. Fortunately for my sanity, I was able to get hold of them the next morning and convinced them I was me by having them call me back on the phone number they already had for me - if somebody in their fraud group had realized that if the credit card was stolen, the cell phone might be as well, I'd have been screwed... Unfortunately, I had to go to a credit union branch, and have them call the main office after showing my drivers license for picture proof And that meant I had to wait 3 days for the office to be open after the holiday! Understand now how customers might have isssues? Yep, most simple algorithms are severely flawed. Doesn't mean there couldn't be better algorithms. And an understanding that banking is just the same as a grocery store or a mall -- or an ISP
Re: I went so you don't have to -- ICANN Bruxelles pour les nuls
On 7/2/10 10:00 AM, Eric Brunner-Williams wrote: There are a few people who have some passing interest in ICANN so I will inflict upon the list my few paragraph summary of things that matter. I thank you! And I'm sure others here do too The ISPSG (that's the ISP -- Internet.Service.Providers Stakeholders Group) continued to drift into senility and decay with ISPs still staffing ICANN issue advocacy out of their IP (Intellectual Property) in-house counsels rather than their IP (4&6&BGP&tone&stuff) operational sides, so wakeful behavior remains confined to the ASO input to ICANN, and limited to the last v4 /8s known to LGBT and other persons. Yeah, well -- I'd burned out after just 3 meetings forming ICANN, was truly unhappy about the treatment of Auerbach, and there's really not anything in the budget. I don't know how you do it. This exchange: On 2 Jul 2010, at 13:34, Bret Clark wrote: 28.8k Modem users... AT&T iPhone users... the new 14.4 modem of the internet. Had me laughing! Me, too.
Re: APNIC's report on traffic directed to 1.0.0.0/8
On 4/7/10 10:22 PM, Scott Howard wrote: http://mailman.apnic.net/mailing-lists/apnic-talk/archive/2010/04/msg2.html (There's also a PDF version with easier to enlarge images at http://www.potaroo.net/studies/1slash8/1slash8.pdf ) It was a nice read. But it didn't indicate where (source AS, or country, or whatever) the traffic was originating. Any data?
Re: Behold - the Address-Yenta!
On 4/8/10 8:02 PM, John Curran wrote: On Apr 8, 2010, at 7:51 PM, David Conrad wrote: In the cases I'm aware of (which were some time ago), there was (to my knowledge) no fraud involved. If you see more recent cases of this occurring, please report them. Or are you indicating the mechanisms I described are in some way fraudulent? Potentially, yes. And with no statute of limitations! Not all things are "solved" by laws. Or economics. Thanks for taking up this issue, John.
Re: Using private APNIC range in US
On 3/18/10 2:35 PM, Jared Mauch wrote: Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ? http://www.google.com/search?q=1.2.3.4+site%3Acisco.com I know that the University of Michigan utilize 1.2.3.4 for their captive portal login/logout pages as recently as monday when I was on the medical campus. Dunno about cisco. med.umich.edu seems to run their own stuff, separately from umich.edu, and quite badly. I've complained about their setup repeatedly over the past several years. No traction. Should we try again, jointly? ;-)
Re: 1/8 and 27/8 allocated to APNIC
Nick Hilliard wrote: On 22/01/2010 13:54, William Allen Simpson wrote: Why not 36 & 37? Random selection to ensure that no RIR can accuse IANA of bias. See David's previous post: http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ Because relying on a blog post for policy really meets everybody's definition of rationality :-( If you're assigning 2 at the same time, they should be adjacent. The dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6.
Re: 1/8 and 27/8 allocated to APNIC
Bill Stewart wrote: On Thu, Jan 21, 2010 at 5:13 PM, George Bonser wrote: Some of that water is dirtier than the rest. I wouldn't want to be the person who gets 1.2.3.0/24 I'd guess that 1.1.1.1 and 2.2.2.2 are probably much more widely used. At least 1.1.1.0/24 should be reserved by IANA or somebody. I agree that 1/8 was probably about the *last* that should have been allocated. It's particularly frustrating that they made two assignments at the same time, but not to adjacent routing blocks Also, 27/8 is clearly in the middle of a group of North American military assignments. So at the very least, these aren't very CIDR'ish. Why not 36 & 37?
Re: FYI, new USG Cybersecurity Coordinator ...
andrew.wallace wrote: "He was born in Lahore, Pakistan in 1959 and moved to Tallahassee, Florida with his parents and younger brother in 1961." --Wikipedia. http://en.wikipedia.org/wiki/Marcus_Sachs Just like many Americans. To me its amazing how deep into U.S Intelligence and The White House he's been allowed to go up until now. "... Georgia Institute of Technology in Atlanta, where he graduated in 1981 with a Bachelor of Civil Engineering degree. "Commissioned as a Second Lieutenant of Engineers in the United States Army in 1981, he served over 20 years as an officer in the Army Corps of Engineers. He graduated from the United States Army Command and General Staff College, and holds a master's degree in Science and Technology Commercialization from the University of Texas and a master's degree in Computer Science from James Madison University." An un-American mole, loyal to a country and a long-time US allied government that he probably doesn't remember? I'm wondering whether you're related to: http://en.wikipedia.org/wiki/George_Wallace
Re: fight club :) richard bennett vs various nanogers, on paid peering
Richard Bennett wrote: Speculation about how the money flows is a worthwhile activity. Sure, no problem. -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC In summary, Mr Bennett is an unregistered lobbyist, employed by other registered lobbyists. It's really a waste of time to engage him, as it's his full-time job to write his screed. We have neither the time nor manpower. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" -- Upton Sinclair (1935) http://www.itif.org/index.php?s=staff He claims to have been involved in IEEE Wi-Fi for 15 years. Meaning he's one of those responsible for the bad security (WEP, etc.), and the stagnation of ad hoc networking -- because the industry has a centralized solution they want to sell, customer be damned. His bio also says he was vice-chair for the hub standard, so prevented jumbo frames from being formally adopted -- again, customer be damned. Now, he works for a "think tank" called "Information Technology & Innovation Foundation". Basically, he goes to conferences. He's not responsible for operating any networks or doing any actual engineering. ITIF doesn't give out information about its funding, which usually means it's industry lobbyist funded. Apparently in this case, big cable and probably big telco. They're opposed to net neutrality, and (based on his comments and several of the papers) still think the Internet is some kind of bastard child that needs adult supervision in the middle -- by which they mean themselves /in loco parentis/. Looking at the board, it's populated by ultra-conservative wing-nut Republicans, and some Conservadems (as we call them in political circles, they call themselves "centrists") from the "New Democrat Caucus" for "bi-partisan" cover. And lots of lobbyists -- Federal lobbyists -- who seem to list their educational clients on their bio, but not whether they are also employed by a firm that represents other clients
DMCA takedowns of networks
http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html Hurricane Electric obeyed the Chamber's letter and shut down the spoof site. But in the process, they shut down hundreds of other sites maintained by May First / People Link, the Yes Men's direct provider (Hurricane Electric is its "upstream" provider). What's going on? Since when are we required to take down an entire customer's net for one of their subscriber's so-called infringement? Heck, it takes years to agree around here to take down a peering to an obviously criminal enterprise network My first inclination would be to return the request (rejected), saying it was sent to the wrong provider.
SA pigeon 'faster than broadband'
http://newsvote.bbc.co.uk/mpapps/pagetools/print/news.bbc.co.uk/2/hi/africa/8248056.stm?ad=1 Update needed for RFC 1149 (1 April 1990), A Standard for the Transmission of IP Datagrams on Avian Carriers
Re: draft-iana-ipv4-examples
Ron Bonica wrote:
In addition, some authors have used 128.66.0.0/16 (TEST-B) for example
purposes. There is no RFC that talks about this block, but my
understanding is that IANA/ARIN have marked it as reserved. If you
search the Internet you will find at least some number of examples and
firewall rule sets that use this block, but I have no good idea about
how widespread such usage is.
The only examples that I've found are firewall rule sets that block
many ranges now allocated. Such as NANOG 2002 email:
http://www.merit.edu/mail.archives/nanog/2002-12/msg00127.html
It's no different from net 69 et alia. A couple of larger examples,
widely propagated:
NoRouteIPs="{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
0.0.0.0/7, 2.0.0.0/8, 5.0.0.0/8, 10.0.0.0/8, 23.0.0.0/8, 27.0.0.0/8,
31.0.0.0/8, 69.0.0.0/8, 70.0.0.0/7, 72.0.0.0/5, 82.0.0.0/7, 84.0.0.0/6,
88.0.0.0/5, 96.0.0.0/3, 127.0.0.0/8, 128.0.0.0/16, 128.66.0.0/16,
169.254.0.0/16, 172.16.0.0/12, 191.255.0.0/16, 192.0.0.0/19,
192.0.48.0/20, 192.0.64.0/18, 192.0.128.0/17}"
block in log quick on external from 0.0.0.0/7 to any
block in log quick on external from 2.0.0.0/8 to any
block in log quick on external from 5.0.0.0/8 to any
block in log quick on external from 10.0.0.0/8 to any
block in log quick on external from 23.0.0.0/8 to any
block in log quick on external from 27.0.0.0/8 to any
block in log quick on external from 31.0.0.0/8 to any
block in log quick on external from 69.0.0.0/8 to any
block in log quick on external from 70.0.0.0/7 to any
block in log quick on external from 72.0.0.0/5 to any
block in log quick on external from 82.0.0.0/7 to any
block in log quick on external from 84.0.0.0/6 to any
block in log quick on external from 88.0.0.0/5 to any
block in log quick on external from 96.0.0.0/3 to any
block in log quick on external from 127.0.0.0/8 to any
block in log quick on external from 128.0.0.0/16 to any
block in log quick on external from 128.66.0.0/16 to any
block in log quick on external from 169.254.0.0/16 to any
block in log quick on external from 172.16.0.0/12 to any
block in log quick on external from 191.255.0.0/16 to any
block in log quick on external from 192.0.0.0/19 to any
block in log quick on external from 192.0.48.0/20 to any
block in log quick on external from 192.0.64.0/18 to any
block in log quick on external from 192.0.128.0/17 to any
block in log quick on external from 192.168.0.0/16 to any
block in log quick on external from 197.0.0.0/8 to any
block in log quick on external from 201.0.0.0/8 to any
block in log quick on external from 204.152.64.0/23 to any
block in log quick on external from 224.0.0.0/3 to any
What should we do about this block? Some of the potential answers
include documenting its role, marking it as reserved but deprecating its
use in examples, and returning it to the free pool immediately (with a
warning sign about possible filtering problems).
Return to the free pool immediately. Allocate it to *IXen, who might
appreciate it being blocked from view by random outsiders.
Re: sat-3 cut?
Eric Brunner-Williams wrote: above link, and routing, at transport, there is a tld effort as well. Randy Bush wrote: yes. informally, a fair number of nanogians have spent the last few decades doing tech transfer to the developing economies, including helping start sister groups such as afnog. nanog participates with arin in a bursary to bring engineers from developing economies to nanog and arin meetings. etc. sorry this so poorly publicized that you did not know. It's not, and I cannot find it on our NANOG website. As you may remember, I'd helped with more formal outreach and instruction via ISoc (mid-'90s), but had not heard of the same by NANOG. OTOH, I've rarely attended any NANOG meeting outside Michigan, and we've not had one here for many years. There's one coming up in October that I'm looking forward to attending (time and finances allowing). What exactly is NANOG doing do help interconnect West Africa? Moreover, what NANOG member financing assistance to Nitel paying its fees, so that its link would be restored?
Re: sat-3 cut?
Nick Hilliard wrote: On 08/08/2009 18:09, William Allen Simpson wrote: Not in a long time. My memory is that SAT-3 was supposed to be a nice cooperative effort funded by the nations themselves, rather than an outside investor. With cooperation, I'd have expected good peering. Indeed, it is a co-operative affair owned by several of the incumbent telcos along the route, and one suspects that they engage in all of the sort of benevolent, community-focussed behaviour that you'd expect from incumbents. Oh, neither of us are talking about benevolence. If you and I have a joint venture, then I'd expect we'd have no problem with interconnection. On a more serious note, and peering / interconnection arrangements aside, the cable fault indicates a critical lack of resilience on the west coast of africa. True. Does NANOG have an outreach and construction program? If not, it's probably not on-topic
Re: sat-3 cut?
William Allen Simpson wrote: By the map in the article, the termini are Spain and Portugal on one end, and South Africa on the other. Surely, a single break wouldn't affect both ends A week later article by the BBC says it didn't. Rather, the Benin branch has the break. http://news.bbc.co.uk/2/hi/technology/8176014.stm "The rest of the system is unaffected by this fault," a Telkom South Africa representative said. And the landings to Benin and Nigeria seem to be different (at least they have different numbers), so that's probably the break (between them). The Nigerian telco Nitel hasn't paid its dues, so its branch has been shut off, and most of Nigeria runs through Benin. Apparently, there is peering, and Benin is currently running "through neighbouring countries" Sounds like this happenstance will provide motivation for more peering and cooperation.
Re: Fwd: Dan Kaminsky
valdis.kletni...@vt.edu wrote: ... Mitnick came out and *said* that he knew the site was insecure, but since no sensitive data was on there, it didn't matter. Presumably the site's monthly cost, convenience, user-interface, and so on, outweigh the effort of occasionally having to recover after some idiot whizzes all over the site. Now, if they had managed to whack a site that Mitnick and Kaminsky *cared* about, it would be a different story... Remembering those ancient days, it always seemed to me that was Mitnick's usual series of excuses (as in: he was a scapegoat, nobody was physically hurt, their cleanup cost estimates were inflated, et cetera ad nauseum). This just seems like more of the same. I'm not a big fan of throw them in prison and throw away the key, but the fact that his prison sentences (plural) and restitution were so lenient is certainly a factor in the difficulty of convincing LE to take investigation and prosecution seriously. Security consultants that don't practice secure computing on their own sites aren't much more than flacks for hire. http://antilimit.net/zf05.txt Anyway, most of the reading was pretty boring and badly formatted, but it still put a bit of a knot in my intestines Are we paying enough attention to securing our systems?
Re: sat-3 cut?
Randy Bush wrote: better lay coverage in al jazeera http://english.aljazeera.net/news/africa/2009/07/2009730775992910.html Thanks, Randy. Making this more on-topic, the map show many hops down. How can a single cut affect more than 1 hop, those on either side of the cut? Surely, for a major investment like this, both ends have peers with others?
