- Test - lists.nanog.org

IPvB translation header
by William Allen Simpson 25 Mar '22

25 Mar '22

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 the IPvB limits are only applicable to nodes indicating the presence of IPvB. (See "IPvB Neighbor Discovery" [] and "IPvB Translation for IPv4" [].) Identification 16 bits: default 0. Assigned by the sender. Originally used in IPv4 to aid in assembling the fragments of a datagram. However, IPvB uses a Fragmentation Header instead, and treats all IPv4 datagrams as Don’t Fragment (DF). Next Header 8 bits. Identifies the type of header immediately following this header. Uses the same values as the IPv4 Protocol field. (See [RFC‐1700] et seq.) Hop Limit 8 bits: initially 255. Indicates the maximum time the datagram is allowed to remain in the internet routing system. The intent is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime. The time is measured in units of seconds, but is only an upper bound on the time a datagram may exist. This field is modified in internet header processing. Every node that routes the datagram between interfaces MUST decrement the value by at least one. For large bandwidth‐delay paths, the value SHOULD decrease by more than one, and MAY decrease by one for each anticipated second in transit (including queuing delay) over the outgoing interface. If this field contains the value zero (0) before sending, or some higher limit upon receipt as configured for each protocol, then the datagram MUST be discarded. Note: IPv4 defaults to an initial value of 64 []. (See also "IPvB Translation for IPv4" [].) Security considerations require that the initial value be well known, so that protocol implementations can detect the number of hops from its source. Source 64 bits. The location of the node originating the datagram. Note: The least significant 32 bits are aligned with the IPv4 Source field to permit serendipitous comparisons for network egress and ingress filtering of both header versions concurrently. Destination 64 bits. The location of the routing area where an interface of the intended communication peer might be found. The IPvB header maintains 64‐bit alignment. Together with an IPvB Encapsulating Security Protocol (ESP), the header combination maintains 128‐bit and 256‐bit alignment. Serendipitous alignment allows simple loads and stores, instead of slower byte by byte iterations.

1 0

Cogent pulled out of Russia based on risk analysis
by Lady Benjamin Cannon of Glencoe, ASCE 25 Mar '22

25 Mar '22

Confirmation from their CEO that Cogent shut down service in Russia due to increased use of the connections for cyberattacks, and because only $10m in rev came from Russia. Cogent had no equipment in Russia. Details: https://youtu.be/l_x2LQZOzF8 Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO lb(a)6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” FCC License KJ6FJJ Sent from my iPhone via RFC1149.

5 4

OVH data center fire (2021) report
by Sean Donelan 24 Mar '22

24 Mar '22

French media covered this earlier in March, but I didn't see the english language reporting until now. https://www.journaldunet.com/web-tech/cloud/1509749-enquete-sur-l-incendie-… OVH has not released its own report about the fire at its SBG2 datacenter on March 10, 2021. The Bas-Rhin fire service, the local responding fire service, issued its report this month. - absence of an automatic fire extinguishing system on the site - a wooden ceiling with a "fireproof" capacity of only one hour with non-insulated technical ducts. - the two interior courtyards acted as fire chimneys - absence of a general electrical cut-off device - Electricité de Strasbourg, the site's electricity supplier, arrived on the scene at 1:20 a.m., but its teams "encountered difficulties in cutting off the electricity." - The site's power supply will be effectively disconnected at 03:28. "At this time, current is still present in the inverters (designed to take over in the event of a cut, editor's note)", specify the firefighters in their report. https://www.datacenterdynamics.com/en/news/ovhcloud-fire-report-sbg2-data-c… Update: In response to a request from DCD, OVHcloud said that it could not respond in detail to the fire report, as it is still working with its insurers and government agencies on a formal report. The company did point out that the fire report is not from a data center expert, but was not able to give a date for when its own report would be released.

1 0

Re: V6 still not supported
by james.cutler＠consultant.com 24 Mar '22

24 Mar '22

> On 23 Mar 2022, at 1:34 AM, Joe Maimon <jmaimon(a)jmaimon.com <mailto:jmaimon@jmaimon.com>> wrote: > ... > Since IPv6 was born of the effort to fix the upcoming address shortage visible at the time and to prevent and alleviate the resulting negative effects, the fact that it did not and that globally v4 address shortage is still a problem is a tally of multiple years of failure. I noticed that no one on NANOG in the nineties predicted the foot-dragging and whining regarding transition from IPv4 toIPv6. We probably should have done so. I, for one, was busy trying to manage interconnects between divisions with their autonomous ref1918 worlds. I applauded the prospect of global unique addressing. So far the technical process has had rocky moments, but it ongoing failure has not happened. Any failure experienced is largely a failure of management/accounts to invest in the future for something that the media can not turn into sound bites and flashy images. This displays a clear lack of enlightened self interest. Even in my home office, over the last nine years I have observed continually increasing IPv6 access for myself and my clients. Comcast has demonstrated that IPv6 has no deleterious effect on typical user experience. Apple and Microsoft have provided admirable support for IPv6 coexisting with IPv4 on end systems. I suggest that it may be more important to deploy solutions to BufferBloat, to the benefit of both IPv4 and IPv6 since it will improve the user experience, than to try to extend IPv4 lifetime, an effort with diminishing returns.

5 5

Historic/Retired Routing Registry
by Dan Mahoney 24 Mar '22

24 Mar '22

Hey there all, I have vague memories of some group running a routing registry that was shut down in the late 90s/early 2000s and I could’ve sworn it was ARIN. It might’ve been Internic or something like that as well. Does anyone have any recollection of this? My Google searching for “retired routing registries” or “ historic routing registries“ seems to fail, But the list of which were in existence at one point or another seems like the kind of thing I’d expect somebody to keep on a webpage somewhere. Ideas? -Dance

3 2

Reason for delayed tornado warnings in Iowa
by Sean Donelan 23 Mar '22

23 Mar '22

https://www.washingtonpost.com/weather/2022/03/06/nws-tornado-warning-disse… In a follow-up statement Monday, Buchanan said the communications delay resulted from a damaged fiber optic cable at the Weather Service’s Dallas-Fort Worth office. “The cable outage caused that office to switch from its primary, land-based communication network to a backup satellite-based network that serves every NWS field office,” she wrote. “The uptick in messages flowing to the central message handler from NWS Central Region offices due to the severe weather, combined with the performance characteristics of the satellite network in use at a co-located site, slowed down the queue of message transmissions and created a brief backlog across multiple offices.”

1 0

BCP 235
by John Kristoff 23 Mar '22

23 Mar '22

Pardon the netop relevant interjection... Most of you probably don't need this, but in my experience many did. DNS over TCP transport is a thing, please don't block it. kthxbye. <https://www.rfc-editor.org/info/rfc9210> John

1 0

V6 still not supported
by Daniel Karrenberg 23 Mar '22

23 Mar '22

Full match with my recollection about the cause for this sub optimal outcome. Happens to the best of us. One has to remember that at the time we did not consider it a forgone conclusion that the products of the IETF woukd be the foundation of the Net. Daniel (age 63, memory not totally unreliable yet) --- Sent from a handheld device. > On 22. Mar 2022, at 13:46, Randy Bush <randy(a)psg.com> wrote: > > john, > > fwiw your story matches what is left of my memory. one nuance > >> That’s not to say that there wasn’t "IETF politics” involved, but >> rather that such politics were expressed as enormous pressure to “make >> a decision” > > my take was that cidr had done a lot to relieve the immediate technical > pressure for the short term; but there was a deep fear that the industry > press was stirring a major poolpah about the end of the internet due to > ipv4 exhaustion. i.e. a seriously flawed technical compromise was > pushed on us in reaction to a perception of bad press. > > i have learned that, when i am under great pressure to DO SOMETHING, > it's time to step back, go make a cup of tea, and think. the ietf did > not. and here we are, a quarter of a century later, still trying to > clean up the mess. > > randy

5 7

Telus contact re: VPN services (ESP, SSL) impacted, Vancouver -> Las Vegas
by Hugo Slabbert 23 Mar '22

23 Mar '22

Hi folks, Could someone from Telus (852) reach out, please? We're seeing a chunk of users on Telus home connections around the Vancouver, BC, area (Lower Mainland) struggling with RTT and some chunks of loss on VPN connections endpoints through gateways in Las Vegas as of ~2022-03-17. Outer path to the tunnel gateway is fine at <60 ms with low jitter and without loss. Tunneled traffic (predominantly ESP, but some users on SSL wrapped at times) shoots up to 130+ ms or above 200, with high variability and chunks of loss. Traceroutes from the users show outer traffic handing off to Zayo in Vancouver and across Akamai in Seattle before coming to us in Vegas. Users on other providers are unaffected. I'm reaching in case there are some shenanigans with ESP or SSL-wrapped traffic being futzed with somehow before being handed to us. Gateway endpoint is v4 only at 185.34.107.131, and is advertised out from 60229 to Akamai/Prolexic (32787). Hugo Slabbert Network Engineer Demonware

1 1

Re: Any engineers from HE on the list?
by Shawn L 22 Mar '22

22 Mar '22

Thanks for all who've responded. I was able to reach a very helpful engineer @ HE. Shawn -----Original Message----- From: "Owen DeLong" <owen(a)delong.com> Sent: Tuesday, March 22, 2022 2:15pm To: "Shawn L" <shawnl(a)up.net> Subject: Re: Any engineers from HE on the list? FWIW, [ support(a)he.net ]( mailto:support@he.net ) is usually fairly responsive. Owen On Mar 22, 2022, at 05:54, Shawn L via NANOG <[ nanog(a)nanog.org ]( mailto:nanog@nanog.org )> wrote: Wondering if there are any engineers from HE (Hurricane Electric) on the list that could help with a strange traffic issue through your network If so, please contact me off-list Thanks Shawn

1 0