back to article We've found another problem with IPv6: It's sparked a punch-up between top networks

We've discovered another reason why IPv6 is, right now, a poor substitute to IPv4: fisticuffs have broken out over the protocol on the internet's trunk roads, causing traffic jams. In a report this month by Qrator Labs, researchers dug into what they are calling national internet reliability: the ability of a country's …

                  1. AbeChen

                    Re: IPv4 Address Pool Has Been Expanded Significantly

                    Hi, Jellied Eel:

                    1) "(Re your earlier quote, it wasn't me who suggested millions of devices would need updating, that was Alan Brown..) ": Sorry for the misquote. It was a bit difficult for me to keep track of the short messages on this forum because it does not provide individualized notification for response. To minimize the mis-correlation, I tried to open my writing by addressing the person whom wrote the comment that I was responding to. In this case, you caught my cross-correlation among several comments arrived at the same time. My apologies, although my general comment stands.

                    2) "These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service. ... So political, rather than practical " : Yes, you are correct! Knowing the controversy of the general environment, the EzIP Draft was phrased as diplomatic as possible in order not to offend others with different mindset.

                    3) ". ... Once it was decided that the 'fix' was IPv6, activity shifted to mostly making that happen. ... That activity is then mostly driven by the vendors and ops community. ": Yes, the whole thing is incredibly convoluted among technology, business, politics (domestic and international) and personal ego. It has gotten to the point that If we try to dig into any one of these, we can waste an awful amount of energy and resources. So, if we want an alternative solution to this mess, it has to be modular enough for local deployment as the starting point. EzIP provides such facility to establish the Internet's equivalent to PSTN's "Interconnect" business (PABX as one of the main vehicles). Like it or not, Internet governing bodies can not stop someone providing sub-Internet services from one IPv4 public address, based on EzIP. It blows apart many of the Internet marketing banners. This is the punch line that I believe why EzIP is getting the attention from formal organizations now.

                    4) As I outlined to Nanashi an hour ago, let's focus on the technical merits of the EzIP technique itself, now that both sides (private and government) of the major organizations (IETF & ITU-T) on the subject have been informed of this technology. That is, if there were any fundamental flaw, either side would have shot the EzIP down already, instead of spending resources to evaluate it. From my limited knowledge of the networking, anything beyond RFC791, 240/4 address block, RG-NAT & CG-NAT makes my eyes watery. If we can stay within the boundaries of these few subjects, I am sure that more colleagues will be interested in participating the discussion. All the unnecessary advanced terminologies, especially those related to IPv6 just discourage many by making them feel inadequate or ill-equipped, which is counter-productive.

                    Thanks,

                    Abe (2018-08-30 15:24)

      1. AbeChen

        Re: IPv4 Address Pool Has Been Expanded Significantly

        Hi, gnarlymarley:

        1) What I am saying is that IPv6 itself is not backward compatible with IPv4. I did not comment on the good services provided by NAT64 and NAT46 that make the two compatible, although at the expense of one extra layer of protocols.

        2) The primary goal of the EzIP approach is to provide a simple new layer of routers utilizing no new protocol but the original RFC791. In fitting into the existing Internet configurations, we saw the utility of the CG-NAT for bridging the gap between the EzIP-unaware IoTs and the new service. So, we integrated it into the EzIP implementation module SPR (Semi-Public Router) as described in the IETF Draft.

        3) SPR provides the appropriate connection service depending on which type of IoT is initiating a session. Appendix A. describes the operation details, while Appendix B.2. outlines the logic that determines the choice of service. These maintain the connectivity for the EzIP-unaware IoTs during the transition. With enough addresses in the 240/4 block and the straight router service from SPR, we hope that the EzIP-unaware IoTs will eventually fade out on its own, but not by force.

        4) This is very much analogous to the rotary dial to DTMF dialing transition. The latter is much better in practically every aspect, while there were a lot of the former. Although the latter is dominant now, there are still some former types in use. The PSTN accommodates both all the way along. The intention of the EzIP is similarly deploying one solution with both EzIP-unaware and EzIP-capable IoTs in mind.

        Abe (2018-08-29 15:04)

    1. philnc

      Re: IPv4 Address Pool Has Been Expanded Significantly

      G-d dammit. This is brilliant!

      1. Ken Hagan Gold badge

        Re: IPv4 Address Pool Has Been Expanded Significantly

        The 240/4 proposal is no more backwards compatible than IPv6. Once you consider all the likely combinations of "aware" and "unaware" endpoints and intermediates, you conclude that everyone's stack needs to be at least partially aware. That means writing, testing and deploying dual stack software on zillions of existing boxes. For IPv6 that task has largely been done. For any and all rival proposals, you are twenty years behind.

        1. AbeChen

          Re: IPv4 Address Pool Has Been Expanded Significantly

          Hi, Ken:

          1) You might have misread the EzIP architecture. The only implementation module is the SPR (Semi-Public Router) that is to form a full spherical layer of simple routers as inline devices between the ER (Edge Router) and subscriber premises. The existing components do not need be EzIP-aware, but continue the operations as if they were under the current CG-NAT configuration.

          2) Only if an EzIP-capable IoT initiates a session with EzIP header will the connection service be upgraded to EzIP router mode.

          3) So, we are not going to modify any existing Internet components including IoTs in the field.

          4) Perhaps the diagram in page 8 of the following would provide a better picture:

          https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf

          Abe (2018-08-29 16:13)

        2. Anonymous Coward
          Anonymous Coward

          Re: IPv4 Address Pool Has Been Expanded Significantly

          As a network engineer, there are two key problems with IPv6 that are holding back deployments in environments that have yet to move:

          - it costs money to move and so far, the cost of not moving or using existing workarounds outweighs the benefits of moving for the majority of the existing user base.

          - it's a little different from IPv4. Not much but enough to make enough things break or need tweaks that large environments won't move unless pushed. This is the "fear of change" rather than the cost implications, as there are still memories of getting the stack fully over to IPv4 in the last 10-15 years...

          The workaround you suggest are affected by both issues and IPv6 has significantly more real-world testing AND scalability.

          1. AbeChen

            Re: IPv4 Address Pool Has Been Expanded Significantly

            Hi, Anonymous Coward:

            0) Thanks for your comments.

            1) Yes, the challenge for IPv6 is that it is not an incremental change because it is not even backward compatible to IPv4. So, the cost is higher than reasonable. And, it does not promise enough benefits to justify the cost.

            2) However, EzIP does not have your concerns. EzIP is formulated with not only backward compatibility to IPv4 by relying on only RFC791, but also incremental deployment in mind. It was designed from system architecture, not technology, point of view. And, the implementation has only one functional module, called SPR (Semi-Public Router) that is intended to be installed inline between an ER and the subscriber premises that it serves. Furthermore, the SPR consists of not only the eventual simple router, but also the CG-NAT function for transitional support of serving EzIP-unaware IoTs. So, the SPR may be installed wherever needed, not relying on any other parts of the Internet. In other words, all of the concerns identified by you have been designed out of the SPR.

            3) The above may sound too idealistic to be explained over this kind of short forum chats. To expedite this dialog, allow me to share my LinkedIn profile. It would provide you some idea about the disciplines that I was trained for, thus the list of unspoken criteria applied to the EzIP project:

            https://www.linkedin.com/in/chen-abraham-b7a918/

            I look forward to your comments.

            Regards,

            Abe (2018-08-29 22:48)

      2. AbeChen

        Re: IPv4 Address Pool Has Been Expanded Significantly

        Hi, philnc:

        1) Thanks for your comment. I had the honor of learning from two great professors who taught me the "same" principle. That is, instead of being distracted by "multitudes of manifestations", one must trace back to the origins of similar subjects. Once the "common source" is identified, a "parallelism" may be established between two or more systems. Life becomes "simple".

        2) For the incident case, please have a look at the diagram on page 12 of the following that pairs the PSTN with the Internet:

        https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf

        3) To paraphrase a politically incorrect phrase, KISS - Keep It Stupidly Simple.

        Cheers!

        Abe (2018-08-29 15:21)

    2. Anonymous Coward
      Anonymous Coward

      Re: IPv4 Address Pool Has Been Expanded Significantly

      "eee zed ip" doesn't sound very snappy.. Maybe you should have called it easyip?

    3. Alan Brown Silver badge

      Re: IPv4 Address Pool Has Been Expanded Significantly

      ".....backward compatibility to IPv4."

      Idiots do like to prattle on about hthings they have no clue about.

      IPv4 CAN'T be made compatible with IPv6 or vice versa. If it could have been done it would have been done. Kludging solutions were looked at and found to be even harder to implement than just using a clean sheet and dual-stacking.

      And before we get yet another round of clueless raving about "ivory tower academics", fuck off and look at the actual list of IPv6 developers. It's full of senior engineers at networking companies trying to find a solution that can be implemented ONCE and not have to be redone every 20-30 years into the forseeable future.

    4. Alan Brown Silver badge

      Re: IPv4 Address Pool Has Been Expanded Significantly

      "Essentially, EzIP utilizes...."

      An idea which was looked at and discarded 20 years ago as being a useless kludge as it would buy an extra 5 years at most, whilst costing massive extra complexity AND STILL requiring a move to IPv6 in the long term.

      Do the words "Heath-Robinson" or "Rube-Goldberg" mean much to you?

      1. AbeChen

        Re: IPv4 Address Pool Has Been Expanded Significantly

        Hi, Alan Brown:

        0) You posted consecutive three separate comments which are difficult to respond with the format of this forum. So, I will just start with this one that has the most critical subject that I like to share.

        1) "An idea which was looked at and discarded 20 years ago as being a useless kludge as it would buy an extra 5 years at most ": I believe that you are referring to a long series of activities leading to the 2008 idea in Reference [2] of EzIP's IETF Draft document.

        A. For sure, if we did not believe that EzIP has surpassed that last hurdle, we would not have mentioned it as "Normative ".

        B. Without disclosing the specifics, I can inform you that a couple of precisely those people involved then have been chewing on EzIP proposal for near one month without definitive comments, after a couple initial clarification questions, that I would say very pointed with substance, but not vague general objections.

        2) ".....backward compatibility to IPv4. ": As I explained to " Anonymous Coward", What EzIP is doing is taking advantage of the "forward thinking" that was embedded into RFC791 by its author. It is a more exact expression than the common backward compatibility phrase. In essence, it is one level higher thinking process because it was kind of predicting the future.

        3) "As for using 240/4.. It would mean deleting it from ISP's 'bogons' filters, ": Pardon me to say that your mindset probably is still in the time frame of Reference [2]. EzIP is using 240/4 in a different way that is why it offers a new approach (touching no existing equipment) that can last quite sometime to come (by expanding the IPv4 address pool by 256M fold).

        Hope these help.

        Abe (2018-08-30 10:53)

        1. Jellied Eel Silver badge

          Re: IPv4 Address Pool Has Been Expanded Significantly

          3) "As for using 240/4.. It would mean deleting it from ISP's 'bogons' filters, ": Pardon me to say that your mindset probably is still in the time frame of Reference [2]. EzIP is using 240/4 in a different way that is why it offers a new approach

          It goes back further than that to the 1-line reason why IPv6-

          https://tools.ietf.org/html/rfc790

          224.000.000.000-255.255.255.255 Reserved [JBP]

          And like you say, why all these years later, it's still reserved. Me, being a simple type would say just allocate and route it. It's happened in the past with RIRs, and usually handled by announcements and 'please update your filters' messages.

          But I've also seen 240/4 addresses used, ie create a 'legal' VPN using public addresses & then tunnelling 240/4 space. Which was considered 'secure' because 240 wouldn't get routed otherwise.. Which is probably an issue with EzIP given IETF reluctance to support anything that looks like an overlay network. Then there's the general position that IPv6 is THE solution, regardless of alternatives, or whether the problem was well defined.

          And also as you say, RFC791 covered a lot of these eventualities in the first place, leaving hooks to support interesting features. It's also a good bit of history, eg the section on security classification bits showing the Internet's heritage.

    5. Nanashi

      Re: IPv4 Address Pool Has Been Expanded Significantly

      If anybody cares, I actually went to the effort of getting my head around the linked draft a couple of months ago in the comments to this article:

      https://forums.theregister.co.uk/forum/1/2018/06/06/vint_cerf_ipv6_program/

      The short summary is: it doesn't manage to be backwards-compatible with v4 in any way that v6 isn't already. It can't talk to v4 without using either dual stack (which v6 has) or cross-protocol NAT (which v6 has, as NAT64). And it works over the v4 internet essentially by tunnelling, which v6 also has (6to4).

      This shouldn't be a surprise, because v4's design isn't forwards compatible, and as a result it's impossible to do direct backwards compatibility in the manner that people seem to want. There is no possible design for v6 that can change this existing limitation of v4.

      Any engineer who claims that this lack of backwards compatibility in v6 is an engineering failure on v6's part is themselves failing at one of the fundamental requirements of being an engineer -- the need to understand what they're talking about. If you don't understand the limitations of v4, then you are in no position to insult the ability of the people that designed v6.

      If you think I'm wrong, don't just downvote me. Reply with an explanation of how, exactly, you'd make that backwards compatibility work. All you have to do to show me that I'm wrong is to demonstrate how to do it. Put your money where your mouth is, and I'll give you fair consideration, as I did for this draft. But you won't be very convincing if your idea doesn't work, or if it has the same limitations that v6's existing options for backwards compatibility have.

      1. AbeChen

        Re: IPv4 Address Pool Has Been Expanded Significantly

        Hi, Nanashi:

        0) I am a person believing in openness, even in debates. This is called mutuality in legal terms (whether lawyers actually do so is a question.). So, before any of us jumping into betting on something, I would like to make sure that everyone is aware of the following:

        1) Without disclosing the specifics, I can inform you that a couple of people in the Internet governing bodies who are precisely those involved with this general subject back then have been chewing on the EzIP proposal for near one month without comment, after a couple initial clarification questions, that I would classify as very pointed with substance, yet without vague general objections. Since it is a well-known fact that IETF, etc. have been doing everything to shut down IPv4 related efforts, this situation makes me nervous.

        2) By the way, many of the participants on this forum probably are aware of the ongoing debate / dispute between IETF and ITU-T on IPv6 numbering plan, etc. I just got an ITU-T message on my submission of the EzIP Draft that “it was not related with current work items. But the mentioned method is helpful and Q4 experts are encouraged to read it”. This is the result of a very compact online message that I sent to TSB Director due their word restriction in the form. I will follow up with more specific implications.

        3) So, to expedite this discussion, I would request everyone to point out any specifics in the EzIP Draft that seems to lead to problems. It would limit the knowledge base to only RFC791 and 240/4 address block, therefore encouraging more participation because no knowledge of IPv6 is required. Fair enough?

        Regards,

        Abe (2018-08-30 12:43)

        1. Nanashi

          Re: IPv4 Address Pool Has Been Expanded Significantly

          I don't think that ignoring v6 in a discussion of v4 address shortage is appropriate. It's the solution that we've already developed and that we're already deploying. It's extremely relevant.

          How can you hope to improve upon v6 without knowing about v6? ...and if you don't plan on improving upon v6, then why should we care?

          1. AbeChen

            Re: IPv4 Address Pool Has Been Expanded Significantly

            Hi, Nanashi:

            0) Pardon me to be blunt.

            1) Strictly speaking, since IPv6 is not backwards compatible to IPv4 which is the first rule in engineering for improving something that is working, it should have never been allowed to be deployed in the first place. (In the old days when I was working for the largest corporation in the world, such thought would send one out the door and hopefully back to school.) Now that IPv6 had the extra years (20 years of development and 10 years of deployment) to prove itself and still did not work (carrying only about 2% of the total Internet traffic), why should anyone care about safeguarding its welfare anymore?

            https://ams-ix.net/technical/statistics/sflow-stats/ether-type

            2) Do you like to see the repeat of the US government bailing out the banking industry because it was "too big to fail", even though they themselves created the disaster by offering the sub-prime interest rate mortgage that old timers like me have never heard of?

            3) Similarly, the auto industry was saved by civilian's money after their executives ran them to the ground while making a lot of money of the business.

            4) Not talking about the long term prospect of IPv6, just ask what is happening to security breaches everyday. Are they necessary or the result of someone making money unethically?

            5) In a sense, we just have to admit the mistake of the current IPv6 and swallow it, then move on with something more reasonable, instead of continue piling new ""6" related sophistication" onto it that fewer and fewer people can understand. What kind of technical empire are we trying to build?

            6) Perpetuating something that does not have enough "Kosher" ground to stand upon is immoral in my book. When there was no alternatives to serve as a mirror to check it, we have to bear it. Once there is yard-stick to measure against, we better apply our true logic minds.

            Regards,

            Abe (2018-08-30 19:16)

            1. Jellied Eel Silver badge

              Re: IPv4 Address Pool Has Been Expanded Significantly

              I think the issue is a combination of pragmatism and cold, hard commercial reality.

              So a couple of decades ago, it was pretty much decided that Internet v2 would be Internet v6. Then much effort over those decades thrashing out the details, and getting boxes to market that can be used. And starting the painful process of implementation and encouraging migration. Plus some issues like this one, which are commercial/regulatory rather than technical. ISPs have a choice whether to peer or transit, the protocol is agnostic.

              That's the Internet for you. It mostly just works, and there's a lot of inertia. So it would be very hard to get the Internet community to change course away from IPv6. Especially given some speed-bumps. Way back, CG-NAT wasn't really recognised as as bigger issue as it's turned out because carrier grade solutions didn't really exist, or were stonkingly expensive and unreliable. That changed, they're in widespread use and work. Or work well enough to disincentivise carriers from changing. Especially as they can also act as convenient choke-points for regulatory activities. Or inconvenient chokepoints for users. They make establishing inbound connections harder. But that can be convenient for carriers who don't want you having an ability to use telephony services they're not billing you for.

              But along the way, there have been thousands of IETF drafts. Most go nowhere. The ones that succeed tend to have the support of the large vendors, or networks. So way back in the early '90s, Cisco created a tag-switching mailing list that caught my eye. That proposed using switching tags rather than routing, so a cheaper networking solution that also promised non-IP support. There were also some drafts by Kompella and Martini for allowing L2 VPNs across 'IP' infrastructure & Kompella was a Juniper engineer. At the time, I was doing product development, and these looked interesting for being able to offer fixed link emulations across a common infrastructure and being ATM-like, could be robust enough to convince classical telco types to trust them. Eventually those morphed into MPLS services, we launched one of the first EoMPLS services and they're widely used today.

              But only because the big vendors supported it, ie Cisco & Juniper.. And also because big carriers wanted the service, ie there was an incentive to offer it when large networks could/would potentially order thousands of switch/routers to replace their 'legacy' L2 switch infrastructure and consolidate everything into MPLS backbones. That duopoly's being challenged by the likes of Huawei now, but still an issue, ie RFPs (especially on the wholesale/infrastructure side) want to know & trust how solutions are delivered. An unknown or lesser known vendor's going to be a harder sell. So anything new has a hard time gaining acceptance.

              That doesn't mean it's impossible. So it's not really necessary to get the IETF's seal of approval and an RFC. As EzIP's an overlay network, find some operators that will implement it. If it works and it's seen to fill an operational need, it'll get more interest and become easier to get standards-tracked. Problem is again it's arguably missed the boat. Due to it's history and the US-centric nature of the Internet, address depletion largely affected the newer RIRs, ie APNIC/AfriNIC, who unsuprisingly became early IPv6 adopters due to necessity.

              1. AbeChen

                Re: IPv4 Address Pool Has Been Expanded Significantly

                Hi, Jellied Eel:

                0) Thanks for recapping details of the Internet history. As you correctly pointed out, much of the current Internet situation is the result of commercial efforts. In a perfect world, this openness would be great. But, we need to look at the result of the over three decades of "experiments". Essentially, we have fostered a few monopolies, one in each business sector. Now, they are not only swaying the general public's opinions, but also influencing government regulatory actions, while they are making the money off the consumers without feeling much obligation to their welfare. It is very scary.

                1) " it's not really necessary to get the IETF's seal of approval and an RFC. As EzIP's an overlay network, find some operators that will implement it. If it works ": Correct. with the ability to establish a sub-Internet supporting 256M IoTs from a single IPv4 address, the EzIP deployment is pretty much a freelance operation. From the big picture perspective, each sub-Internet is just a CPE (Customer Premises Equipment), not affecting anyone else. So, we can just do it without telling any Internet governing body anything about it. However, this new type of CPE is capable of covering such a large area (as large as Tokyo metro or 75% of countries) that my system engineering training told me that it would be prudent to let the organization in charge of the Internet know about it. So that proper coordination activities may take place along the way. Then, using EzIP or not will be an informed decision. This is why we continued to submit several EzIP Draft versions to IETF, knowing full well that they have been winding down the only Working Group SunSet4 and eventually concluded it this past May. I have made this clear to a senior Internet governing body member in charge of this matter, upon finally getting through to him.

                2) On the practical side, we need to inform the general mass of the availability of an alternative, ASAP. So that they may stop the current "suffering", or continue being led by current players. This is a tough challenge, because most people do not have any idea what is going on, besides it seems to be nice to have Internet services on daily basis, while "surprises" happen frequently. Since IETF has "institutionally" decided to go for IPv6, the only organization that may be able to provide some influence is ITU. This is where "politics" comes in. Internet camp has been against ITU participation with various reasons. Since ITU does not have much expertise in the Internet technology, they are at a difficult position to represent member states (in this case, mostly the developing countries, or more plainly, the non US-centric block). I believe that EzIP is the first facility that can clear up the smoke screen at the baseline, so that all parties can be relieved from the urgent tasks (address shortage and cyber security vulnerability) for focusing on the design of a solid next generation Internet, be it an improved IPv6 or a brand new version.

                Regards,

                Abe (2018-08-31 10:40)

              2. AbeChen

                Re: IPv4 Address Pool Has Been Expanded Significantly

                Hi, Jellied Eel:

                0) Thanks for your in-depth comments with historical references. It is very educational, I appreciate very much. Sorry that I did not respond earlier because I was still trying to figure out how to present the EzIP. Some of the points that you brought up near the end are very controversial and convoluted. Fortunately, I believe applying the demarcation principle, the EzIP can largely avoid them.

                1) I agree with your observation and recommendation. That is, EzIP could just go find a carrier / operator to deploy the SPRs without the blessing from the IETF, because each SPR looks like an IoT or one CPE from the Internet. We submitted the EzIP Draft to IETF just for the purpose of doing due diligence, because we are an US company. I wanted to be sure that all US related organizations got the right of first refusal.

                2) The next step is to ask how big is the 240/4 address block and what does it mean when a CPE gets to be this size? Although the second letter of the SPR is spelled out as "public", you likely have realized from our description of what triggered this approach that it may be installed on a private premises just in front of the existing RG. Then, the "P" means "Private". Any two private parties may operate SPRs through the Internet as a telephone modem pair through the PSTN. This is subtle but extremely important, because the whole region (the sub-Internet in the Draft) served by an SPR utilizing one 240/4 block becomes much bigger than a LAN and about one sixteenth of the full IPv4 based Internet! Yet, it is practically transparent to the current Internet fabric. Let's call this as a RAN (Regional Area Network) for facilitating the following discussion.

                3) The exciting part of a RAN is that as long as it is compatible with the interface to the serving ER for communicating with the global Internet, the SPR may be constructed with any technology. This gives SPR the freedom of pick and choose desirable characteristics from the current Internet, while rejecting anything that is known to cause issues. This is why we proposed to utilize one of the RANs (sub-Internets) in the EzIP environment for the proposed satellite based Internet which is still in the conceptual stage, with nothing concrete yet.

                4) Along this line, the RANs will be perfect test beds for developing new Internet Protocols in real time and in coexistence with existing IPv4, IPv6, etc. based operations, as long as the interface through the single IPv4 address is compatible with current IPv4 packet definition. This can be easily achieved by using the Caching Gateway for the translation of the packet, only at one point.

                I would appreciate your thoughts very much.

                Abe (2018-09-28 23:05)

            2. Nanashi

              Re: IPv4 Address Pool Has Been Expanded Significantly

              As I explained before, it's fundamentally not possible to do the kind of backwards compatibility that you seem to want from v6. v4 doesn't support it. There are a few ways of working around that deficiency of v4, and v6 uses those ways, and I would argue that v6 is backwards compatible because of its use of those workarounds.

              You already know what those workarounds are. In fact, you figured them out yourself for EzIP, because it uses those exact same workarounds. (By your argument, this means that either EzIP isn't backwards compatible either, or it means that v6 is.)

              and still did not work (carrying only about 2% of the total Internet traffic)

              I know that's what is written on AMS-IX's graphs, but that's not an accurate measure of internet-wide v6 traffic. Over half of ISP traffic comes from on-net caches, which are typically v6, and over half of the remaining traffic goes via direct peering and never hits an IX. There's a correlation between "big enough to peer" and "does a lot of v6 traffic". IXs are going to see abnormally low amounts of v6 traffic.

              25% of internet users have v6, and on average ~50% of traffic for a dual-stacked user goes over v6. These stats sound a lot better, don't they?

              In a sense, we just have to admit the mistake of the current IPv6 and swallow it, then move on with something more reasonable,

              Do you have something more reasonable? Because, as I've mentioned, v6 is already about as simple as it can possibly be given the constraints it's working under. EzIP ends up being more complicated because it permanently requires running on top of v4 using workarounds intended for backwards compatibility, whereas v6 is also capable of working without the workarounds.

              EzIP also has the exact same deployment difficulties that v6 has (e.g. the need to upgrade everything that needs to interact directly with it) and offers nothing to ease those deployment issues that v6 itself doesn't offer.

              So if you want us to use something more reasonable then EzIP isn't it, and I haven't seen any better suggestions. Why should we abandon the substantial v6 deployment we have to start over from scratch with something that isn't even better?

              Also, seriously, you need to learn v6. It's not difficult, I swear. 80% of it is pretty much identical to v4 but with longer addresses. If you have your head around v4 (as you clearly do) then you already understand all of the concepts; v6 just makes the addresses longer, which doesn't change how any of it works.

              Go and grab a tunnel from tunnelbroker.net and set it up on your network. Play around with it for a bit. Seeing it in action should show you that it's not as scary as you think.

              1. AbeChen

                Re: IPv4 Address Pool Has Been Expanded Significantly

                Hi, Nanashi:

                0) It looks that we are getting into word-smith arguments.

                1) To save both of our time, let me begin with a question which is stupidly simple. Send yourself back to Year 1982. After you studied the RFC791 and understood the 240/4 address block was "RESERVED" for "Future use". (Both were time marked in 1981-09), you read about EzIP. Could you understand it? If so, how could anything like IPv6 that is built on top of lots of RFCs afterwards be simpler?

                2) "it's fundamentally not possible to do the kind of backwards compatibility that you seem to want from v6. v4 doesn't support it.": Of course, IPv6 can't because it is now publicly known that it ignored this basic engineering discipline. As to the second part, I am not sure what you are referring to. The only IPv4 standard that EzIP relies upon is RFC791. So, RFC791 has built-in "Forward Thinking" to support EzIP, while EzIP is backwards compatible to RFC791. Together, they are a pretty "Kosher" pair.

                3) " AMS-IX's graphs ... ": You have another interesting argument. I do not know Internet enough to provide counter argument. However, two facts I can supply. First, this article talks about disputes among fairly good sized ISPs about peering arrangements. So, what portion of IPv6 traffic is peered would be significant factor in influencing this discussion. Secondly, I have been talking with fairly high level people in IETF, ICANN & ITU. None of them shot me down from this angle. If you can identify your level of expertise, maybe I will accept your opinion.

                4) "Do you have something more reasonable? Because, as I've mentioned, v6 is already about as simple as it can possibly be given the constraints it's working under.": What constraints that IPv6 is working under? In comparison, EzIP gets the job done without relying on any RFC after RFC791. What could be more reasonable?

                5) "EzIP also has the exact same deployment difficulties that v6 has (e.g. the need to upgrade everything that needs to interact directly with it) ": Please be specific. I can reiterate the deployment conditions of EzIP for you. The basic configuration is an inline device (SPR) between Internet's ER (Edge Router) and private premises RG (Routing / Residential Router). Nothing in the current Internet setup is affected. For its sub-Internet configuration, it is even more stealthy because an entire region up to the size of Tokyo Metro served by the degenerated SPR appears as one single IoT to the existing Internet. There is really no "difficulty" in deployment to speak of.

                6) " Why should we abandon the substantial v6 deployment we have to start over from scratch with something that isn't even better? ": If something isn't delivering what it promised, anytime is a good time to abandon it. It does not matter how much we have sunk into it. The more we wait, the more we waste. I have seen enough cases of swallowing the missteps. IPv6 is just the biggest "public experiment" that has had its chance to demonstrate its wisdom. We have been dragging on by it because there has no alternative to challenge it and it is "too big to fail", until EzIP. And, you have not made clear enough description about why EzIP isn't better, except by statements of your own words.

                7) "Also, seriously, you need to learn v6. It's not difficult, I swear. 80% of it is pretty much identical to v4 but with longer addresses. If you have your head around v4 (as you clearly do) ... ": Thanks for the compliment. However, as I professed, I have already stretched my brain cells to learn enough IPv4 to come up with EzIP. I heard enough negative experience from IT professionals that I am not able to get to the IPv6 level just because your encouragement.

                8) Again, please come down to the earth by answering my question in Pt. 1) above. Then, we will have a common ground to proceed.

                Thanks,

                Abe (2018-09-06 16:51)

                1. Nanashi

                  Re: IPv4 Address Pool Has Been Expanded Significantly

                  No, v6 didn't "ignore" backwards compatibility. v6 CAN'T DO backwards compatibility because v4 doesn't support it. There's no way to do complete bi-directional transparent backwards compatibility with v4. Nothing can be backwards compatible in that manner with existing, unmodified v4 nodes. It's not possible.

                  v6 isn't transparently backwards compatible with v4. Neither is EzIP, for the same reasons.

                  You need to decide whether you consider EzIP to be backwards compatible or not. If you think it is, then you also think that v6 is backwards compatible, because v6 uses the exact same mechanisms (dual stack, NAT, tunnelling) that EzIP does to be compatible with v4.

                  Do those mechanisms count as backwards compatibility or not? I'll let you decide. But either both v6 and EzIP are backwards compatible, or they both are not. You can't have it both ways. Not when they use the same methods.

                  If you don't believe me then you're welcome to learn v6 and see for yourself. If you're not going to do that, then you're going to have to rely on other people who do know it. Either way, please stop using your own preconceptions of what v6 can and cannot do, because they're wrong.

                  Re: peering, I'm talking about direct peering agreements between end-user ISPs and big content networks - people like Google, Netflix, Akamai. These people all push huge amounts of traffic, and they all do v6. Peering between end-user ISPs and content providers effectively takes that traffic off of the public internet (and it's the public internet that the article is talking about).

                  If so, how could anything like IPv6 that is built on top of lots of RFCs afterwards be simpler?

                  By not requiring that it be run as an overlay network. v6 can run as an overlay, but it also supports running natively, and running natively is way simpler than requiring a fully operational v4 internet and then running on top of it forever.

                  The number of RFCs isn't the important part. You'll find that going from a draft idea to something with completely defined behavior that can be implemented correctly everywhere requires thinking about and defining a bazillion things you never thought you'd need to deal with. That's what those RFCs represent. (That, plus 20 years' worth of further development on core internet protocols.)

                  Please be specific. I can reiterate the deployment conditions of EzIP for you. [...] There is really no "difficulty" in deployment to speak of.

                  Great to hear there's no difficulty! v6 can be deployed in exactly the same way. For example, you can deploy dual-stack routers without affecting anything in anybody's current internet setup. The various forms of NAT cover communicating between protocol versions. 6to4 covers the "give every existing IP more IPs" aspect (although it gives a trillion trillion IPs per v4 IP, rather than just 256M).

                  And, you have not made clear enough description about why EzIP isn't better, except by statements of your own words.

                  What else can I give? The way v6 works is public knowledge, and you're free to go and verify anything I've said.

                  1. AbeChen

                    Re: IPv4 Address Pool Has Been Expanded Significantly

                    Hi, Nanashi

                    0) Thanks for your comments. However, we must focus on essence, not on philosophy.

                    1) " No, v6 didn't "ignore" backwards compatibility. v6 CAN'T DO backwards compatibility because v4 doesn't support it. ... ": As I was saying, you seemed to be more interested in word-smith debates on conceptual topics than dealing with the actual technical subject matter. Allow me to repeat this truly "Back to The Future" question. That is, if you were sent back to 1982, could you see that making use of RFC791 and 240/4 address block in the way prescribed by EzIP could expand the IPv4 address pool by 256M fold so that the trigger for considering IPv6 was eliminated?

                    Note: Unlike the same titled movie that I am referring to that applied certain modern day knowledge and skills, the EzIP scheme does not rely on anything that came after RFC791.

                    2) All the rest of your opinions are the consequence and variations of not being able to achieve the above. So, let's concentrate on Pt. 1) to establish our baseline first. I will be glad to dig into them afterwards. Thanks.

                    Regards,

                    Abe (2018-09-09 16:40)

                    1. Nanashi

                      Re: IPv4 Address Pool Has Been Expanded Significantly

                      If you insist, I'll answer it directly: yes, I can roughly figure it out. I don't agree that it would be the right way to do it, and at 60 bits I'm not convinced it would be big enough, but it's certainly a way, and I did think I made it clear already that I understood how EzIP is supposed to work.

                      (I also don't agree that it relies on nothing after RFC791. It relies on a lot of things after RFC791, including its own 43 page draft.)

                      Now perhaps you could answer my question, so that we can stop flip-flopping between two different definitions for it: what, exactly, do you mean by backwards compatibility? This is a technical matter, given that it concerns the technical capabilities of the things we're talking about.

                      1. AbeChen

                        Re: IPv4 Address Pool Has Been Expanded Significantly

                        Hi, Nanashi:

                        1) " yes, I can roughly figure it out. ": Thanks, this is a good starting point for us to move forward. (Maybe I missed it. But I do not recall any positive statement from you previously.)

                        2) "at 60 bits I'm not convinced it would be big enough,": I am not sure where you get the number "60" from? Perhaps it is just a typo? A full EzIP address has 64 bits, 32 bits from the basic public IPv4 pool and 32 bits from the 240/4 block. This give us a 1BB (4B x 256M) combination. In addition, if you review the derivation / logic analysis in Section 5. that leads to paragraph 5. C., you will see that even a 128 bit address system out of the current IPv4 pool is possible, if we can give up the idea of keeping IP address as personal property. (This is a big philosophical issue that we can discuss about next, separately.) However, since the first two bits of each 32 bit segment are used to distinguish among the four evenly divided parts from the full IPv4 pool, the actual effective total address has only 120 bits. So, instead of 256BBBB combination that IPv6 has, EzIP can only get up to 1BBBB. Since the latter is huge already anyway, I hope we do not need to debate on which one is better based on their size ratio.

                        3) "It relies on a lot of things after RFC791, including its own 43 page draft.": All 43 pages of the EzIP are just describing in detail about how the 240/4 address may be transported across the Internet, so that it can be used by SPRs at either end of a link. They are NOT disclosing a new method / protocol in the strictest sense at all, according the disciplines that I learned through my engineering training. The key mechanism, the Option Word was defined clearly enough by RFC791 back in 1981-09. There have been many applications of it in the RFC library. To put in another way, the 43 pages of the EzIP Draft are kind like the lecture notes that a professor brings into the classroom to assist the student to understand the topic of the day which is "transporting new address across the Internet for new routers to perform an extra stage of routing". And, the ingredients to be relied upon were covered by earlier lectures.

                        4) "what, exactly, do you mean by backwards compatibility? ": Allow me to describe what I was taught in the good old days by the biggest telecom company (the previous life of the current AT&T). The "Kosher" definition of a product / system that is backwards compatible to its predecessor is that upon introduction, everyone (from operator to end-user) can continue what each has been doing previously. And, no one can tell something has happened. As time goes on, individuals will realize that the bad aspects of the old system have been eliminated, while those venturous will discover that new capabilities / features have been added. Of course, the designer of the new system is eager to tell everyone what is new. So, there would be normally a brochure of some sort with highlights of the new system distributed to everyone involved during the introduction. So that everyone can enjoy the new system, ASAP.

                        5) Based on the above outline, how close would you say that IPv6 is backwards compatible to IPv4? Hope you can now appreciate why I am so critical about various aspects of IPv6.

                        Thanks,

                        Abe (2018-09-13 23:06)

                        1. Nanashi

                          Re: IPv4 Address Pool Has Been Expanded Significantly

                          60 bits is 32+28 bits. 2^32 is ~4 billion and 2^28 is ~256 million.

                          The "Kosher" definition of a product / system that is backwards compatible to its predecessor is that upon introduction, everyone (from operator to end-user) can continue what each has been doing previously.

                          By this definition, v6 is definitely backwards compatible. Adding v6 support to a network, router or host has no impact on its existing v4 support, and you can continue using v4 as you were previously. So it meets this definition.

                          1. AbeChen

                            Re: IPv4 Address Pool Has Been Expanded Significantly

                            Hi, Nanashi:

                            No, you are talking about IPv6 is "coexisting" with IPv4.

                            When I say "predecessor", I mean that the new one is providing the service in place of the old one. The old one is practically retired or being phased out. There is only one active system at a time that the operator or user sees.

                            Abe (2018-09-18 22:15)

                            1. Nanashi

                              Re: IPv4 Address Pool Has Been Expanded Significantly

                              It would've been helpful to put that in your kosher definition of backwards compatibility when I asked you for it. By this expanded definition, EzIP is not backwards compatible, because it uses v4 unless both sides have EzIP. Operators and users need to deal with both.

                              1. AbeChen

                                Re: IPv4 Address Pool Has Been Expanded Significantly

                                Hi, Nanashi:

                                1) " By this expanded definition, EzIP is not backwards compatible, because it uses v4 unless both sides have EzIP. ":

                                Backward compatibility in this case means that the new system (EzIP) is able to transparently handle the old format (basic IPv4), so that no one is required to be capable of the advanced capability (EzIP) if not interested in it. Thus," falling back" to requiring both sides to use IPv4 when someone in the loop is not capable of EzIP is actually conforming to the Kosher definition of "backward" compatibility.

                                2) "Operators and users need to deal with both. ": Actually, the current "operators" (the CR & ER - Core and Edge Routers) are not expected to handle EzIP at all, because the Option Word is transparent to them. Only "users" are encouraged to upgrade their IoTs to be EzIP-capable, so that they can enjoy the straight routing that offers end-to-end connectivity.

                                Abe (2018-09-29 09:40)

                                1. Nanashi

                                  Re: IPv4 Address Pool Has Been Expanded Significantly

                                  By this definition, v6 is backwards compatible. It can transparently handle v4 on any system that has the appropriate software support, and it doesn't require anybody to be capable of doing v6 if they don't want to do v6.

                                  Is this what you mean by backwards compatibility, or are you going to change your mind again?

                                  1. AbeChen

                                    Re: IPv4 Address Pool Has Been Expanded Significantly

                                    Hi, Nanashi:

                                    1) "... any system that has the appropriate software support ... ":

                                    What do you mean by this? Who is counting on some extra support? What is the "software support" that you are implying? And, it even has to be "appropriate"? Aren't you getting too vague now?

                                    2) Putting it in another way, since IPv6 has been relying heavily on so much marketing push to get the deployment going, the activities are too explicit for anyone to overlook. It just could not be classified as "transparent" which is part of the implied requirements for being qualified as backward compatible.

                                    (Remember what I described to you about hot-swaps and midnight cut-overs for the telephony equipment updates in the old days? Those events were so transparent to the subscribers that everyone executed as routines. No one made it a subject to talk about.)

                                    Abe (2018-10-07 19:04)

                                    1. Nanashi

                                      Re: IPv4 Address Pool Has Been Expanded Significantly

                                      I just mean any system that can parse a v4 address and generate a v4 packet. This isn't some extra thing that needs to be added, it's literally the software that's already in those systems and which they're already using for v4.

                                      I don't think I even understand what you mean by "transparent" any more. Do you mean "existing devices keep working", or do you mean "end users don't need to change what they're doing" or is it "the engineers responsible for making the network hardware and software are unable to detect any changes in behavior or functionality"? Or maybe even something else?

                                      1. AbeChen

                                        Re: IPv4 Address Pool Has Been Expanded Significantly

                                        Hi, Nanashi:

                                        1) If you are talking about v4, I agree with you that EzIP is attempting to do so.

                                        2) All the "transparent" cases that you listed are correct, except the last part. That is, the engineers definitely have to know there is change.

                                        Abe (2018-10-22 21:24)

              2. AbeChen

                Re: IPv4 Address Pool Has Been Expanded Significantly

                Hi, Nanashi:

                1) Re: My Pt. 3) in my last reply: Come to think about it, since IPv4 is more mature, wouldn't it have larger percentage of the traffic going through the Peering arrangements instead of AMS-IX? It is IPv6 having trouble to get Peering agreements that is sending more traffic to AMS-IX, yet is still only about 2% of the total. Then, you are defeating your own argument. Correct?

                Abe (2018-09-06 18:12)

  1. Anonymous Coward
    Anonymous Coward

    Clarification please

    "If you, as a network, fall into a tier where the exchange of data is so huge that it's not really worth tracking and charging others for, you have to start paying, all the way down from large ISP to small ISP to business to, eventually, the average consumer paying $50 a month for what is, comparatively, very little."

    Can someone please explain the above paragraph? I am dim and don't understand it.

    1. Anonymous Coward
      Anonymous Coward

      Re: Clarification please

      I'm going to guess it's on a tier pricing structure where each tier pays the one above a fixed fee until you get to those that charge for usage as it wouldn't be practical to try and monitor the data at the top levels.

    2. dgeb

      Re: Clarification please

      I think the article is missing the word "imbalance" - the point is that settlement-free peering only makes sense if both parties are providing an essentially equivalent service to one another.

      That is usually considered separately in terms of transit provided to other networks than the two that are peering (on the basis that I'm not doing you a favour by accepting traffic destined for my own network).

      So a (non-telco) business network, even a multi-homed one, is essentially never providing any transit to its peers, and therefore pays its provider the entire costs of its connections; a mid-size ISP may be providing some transit (to its multi-homed customers, such as smaller ISPs) and may have some settlement-free peering with other similar networks, and some partially or fully-paid peering with bigger, more connected networks.

    3. diodesign (Written by Reg staff) Silver badge

      "Can someone please explain the above paragraph?"

      I've reworded it to make it simpler. Basically, if you shift 1PB of data a day from your network through another network, and they shift 1PB of data a day from their network through your network, you pay each other the same amount and thus pay each other zero.

      If you're a small network, and you run a lot of traffic through a larger network, and the larger player doesn't route much through you, then you need to cough up for the bandwidth difference.

      Both of these scenarios involves a peering agreement - the latter involving money.

      Hope this helps.

      C.

      1. Version 1.0 Silver badge

        Re: "Can someone please explain the above paragraph?"

        That's a good explanation - it sound like it would be possible for a large network to route some of the data to balance out the transfers where you would otherwise owe payments, and the rest of the data to networks so that you were owed money?

      2. rg287 Silver badge

        Re: "Can someone please explain the above paragraph?"

        If you're a small network, and you run a lot of traffic through a larger network, and the larger player doesn't route much through you, then you need to cough up for the bandwidth difference.

        In strict parlance, what you have there is not really peering (in the settlement-free sense). You're buying Transit from the bigger player.

        It should also be noted that settlement-free peering isn't just for networks with mutually balanced traffic, it's for networks with mutually compatible traffic - lots of asymmetric networks peer for free precisely to reduce costs. For instance, If I set up a data centre in London (i.e. heavy outbound traffic to users requesting the content I host), I would seek to peer directly with the likes of heavy inbound networks (like ISPs) who connect me to the users trying to get at my content. Peering directly with other datacentres is less relevant because I won't be exchanging much data with them.

        The alternative would be both myself and the ISPs paying a Tier 1 provider (like Cogent) to provide us both with transit.

        Buying transit from Tier 1 providers is - overall - unavoidable because no datacentre can be directly connected to every ISP in the world and likewise, no ISP can directly connect to every possible content source in the world. But BT and Virgin (heavy inbound) make damn sure they're directly peered to Google and the BBC networks (heavy outbound) because it would cost both sides a fortune to be pushing YouTube and iPlayer traffic (for instance) over a third party like Cogent.

        This is one of the problems with the US monopolies despite being heavy-inbound, they refuse to peer settlement-free with content providers like Netflix and also under-provision their Transit links so netflix traffic gets stuck coming over those connections, denying their users (who have paid for internet) reasonable service. The likes of Netflix are then forced to pay for the right to peer and gain access to the ISP's customers (even though the customers have paid for the right to access Netflix!).

        This doesn't happen so much in Europe where we have lots of neutral, community Exchange Points where networks exchange data for free and minimise the traffic they have to send via a Tier 1 (and therefore their monthly Transit bill).

        1. Jellied Eel Silver badge

          Re: "Can someone please explain the above paragraph?"

          First define 'Tier-1'..

          In classic sense, it's a default-free network. So the 'net is a blob of interconnected ASNs, each with it's own unique set of routes allocated by the RIRs. With peering, my ASN connects to your ASN and we have a route between our address space. There may be traffic.

          But that won't let your traffic reach every destination on the 'net. So if you can't find the destination directly connected via a peer, you send it via a default route to an 'upstream' who may have a path. So a 'Tier-1' has a complete set of routes to every destination, either via paid or settlement free connections.. Which is also where marketing and the economics kick in. So assume..

          user-ISP1-ISP2-Content

          If ISP1 peers with ISP2, traffic can flow freely.

          If ISP1 buys transit from ISP2, traffic also flows freely.

          Then capitalism kicks in. User pays ISP1, Content pays ISP2. Where the peering wars begin is with transit, where ISP1 has to pay ISP2, so ISP2 gets paid both sides of the session.

          That gets especially contentious where costs are considerably different, ie operating an access ISP with millions of users costs considerably more than operating a transit network, that focuses on stringing fat pipes between datacentres/peering exchanges. It's also where there's an unequal value exchange, ie

          User-Content is the cash flow for a Amazon/Netflix subscription.

          Content-ISP2 is the payment for subscription delivery.

          ISP1 gets... nothing except what it can charge for the basic Internet connection, and has to pay ISP2 to keep customers happy.

          In the good'ol days, settlement free peering was often decided on mutual benefit, or traffic ratios. Content skewed this model because that's highly asymmetric, ie small session request generates a big stream back. Transit ISPs also have more economic power, ie if ISP1's user can't connect to content, they'll blame ISP1 and maybe switch. So ISP1 has to buy more transit to keep their customer's happy.

          More rarely, 'peering' disputes can hit the content side, ie if say Netflix loses access to 10m customers due to a peering spat, then they'll start leaning on their transit provider. Generally though, the big content providers prefer the status quo, and as long as they can play T1 transit providers off against each other to lower their traffic costs, they're happy.

          This particular case is just an extension of those disputes. It's difficult (read: Expensive) to challenge the current Tier-1s, but some providers saw IPv6 as a way to challenge that dominance, and become an IPv6 'Tier-1'. Naturally, the incumbents said 'Nope', and referred them to their existing peering policies.. Which are generally impossible to meet for most ISPs, especially regional ISPs.

          And the economics behind all this lot are why the 'Net Neutrality debate exists, with the big content providers on one side trying to avoid costs, and access ISPs on the other looking to recover them.

          There's also the case where the big content providers offer to peer or install caches. That may reduce the need for ISP1/access ISPs to buy transit, but still costs ISP1 a lot more to carry that traffic than it does the content provider.

      3. Anonymous Coward
        Anonymous Coward

        Re: "Can someone please explain the above paragraph?"

        Thanks! I think it was the phrase "fall into a tier" that confused me.

  2. EveryTime

    Cogent's success is assured...

    So being relentlessly mercantile has paved Cogent's path to the future...

    1. Cavehomme_

      Re: Cogent's success is assured...

      Except that their business is declining.

      I don’t see what the problem is in this article. Today there are 12 Tier 1 providers, next few years there will be 11...or 21, depending how the market plays out.

  3. onefang

    "Analysis We've discovered another reason why IPv6 is, right mow, a poor substitute to IPv4:"

    "Right mow"? The grass is always greener on the other IP protocol?

  4. Ken Moorhouse Silver badge

    It...

    It will all end in Tiers.

  5. Anonymous Coward
    Anonymous Coward

    Fools. IPv6 is the only way forward. It is already widely deployed. We need it, our kids and grandkids will need it. We need to embrace IPv6 and work together to make the transition as pain-free as possible.

  6. Anonymous Coward
    Anonymous Coward

    The article makes the point that this peering problem is nothing to do with the IPv6 protocol, so why doesn't this happen with IPv4, in that case?

    1. Norman Nescio

      The article makes the point that this peering problem is nothing to do with the IPv6 protocol, so why doesn't this happen with IPv4, in that case?

      Perhaps because the sources, destinations, and volumes of IPv6 traffic differ from IPv4 traffic? An otherwise nondescript IPv4 ISP might, through circumstance, have a significant sink for IPv6 traffic in its customer base. While it will not be able to use its IPv4 presence to broker peering deals, it may be able to argue that the imbalance in IPv6 traffic justifies that it either charges other ISPs for IPv6 connectivity, or comes to a peering agreement which it would not otherwise be able to negotiate on its IPv4 traffic statistics alone.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021