Re: IPv6 woes - RFC

> On Sep 24, 2021, at 10:53 AM, b...@uu3.net wrote: > > Well, I see IPv6 as double failure really. First, IPv6 itself is too > different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with > bigger address space, likely 64bit). Of course we could not extend IPv4, > so having new protocol is

Re: Rack rails on network equipment

> On Sep 24, 2021, at 3:35 PM, Niels Bakker wrote: > > * c...@cmadams.net (Chris Adams) [Sat 25 Sep 2021, 00:17 CEST]: >> Which - why do I have to order different part numbers for back to front >> airflow? It's just a fan, can't it be made reversible? Seems like that >> would be cheaper th

Re: IPv6 woes - RFC

> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote: > > Well, I think we should not compare IPX to IPv4 because those protocols > were made to handle completly different networks? > > Yeah, IPv6 is new, but its more like revolution instead of evolution. > > Well, Industry seems to addapt things

Re: IPv6 woes - RFC

> On Sep 25, 2021, at 02:10 , b...@uu3.net wrote: > > Because IPv4 loopback is 127.0.0.1/8 and its usefull? How so? Where do you actually use 16.7 million loopback addresses, let alone 18 Quitillion+ * 65536 (/48)? > > 0:0:1-:0/32 means you generate addreses from > that range and not nec

Re: Rack rails on network equipment

> On Sep 25, 2021, at 12:48 , Andrey Khomyakov > wrote: > Let me just say from the get go that no one is making toolless rails a > priority to the point of shutting vendors out of the evaluation process. I am > not quite sure why that assumption was made by at least a few folks. With > that

Re: IPv6 woes - RFC

> On Sep 25, 2021, at 14:20 , Baldur Norddahl wrote: > > > > On Sat, 25 Sept 2021 at 21:26, Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: > So the fact that: > > 2001:db8:0:1::5 > 2001:db8::1:0:0:0:5 > > Are two diffe

Re: IPv6 woes - RFC

> On Sep 28, 2021, at 02:19 , b...@uu3.net wrote: > > Heh, NAT is not that evil after all. Do you expect that all the home > people will get routable public IPs for all they toys inside house? NAT is absolutely that evil after all. The presence of NAT has basically prevented a number of produc

Re: IPv6 woes - RFC

> On Sep 28, 2021, at 08:13 , Masataka Ohta > wrote: > > Mark Andrews wrote: > >>> Heh, NAT is not that evil after all. Do you expect that all the home >>> people will get routable public IPs for all they toys inside house? >> Yes! Remember routable does not mean that it is reachable from ou

Re: IPv6 woes - RFC

Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs. Owen > On Sep 29, 2021, at 07:35, Christopher Morrow wrote: > >  >

Re: IPv6 woes - RFC

> On Sep 29, 2021, at 09:25, Victor Kuarsingh wrote: > >  > > >> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG >> wrote: >> Use SLAAC, allocate prefixes from both providers. If you are using multiple >> routers, set the priority of the

Re: IPv6 woes - RFC

>>  >> >> >> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG > <mailto:nanog@nanog.org>> wrote: >> Use SLAAC, allocate prefixes from both providers. If you are using multiple >> routers, set the priority of the preferred router to high in

Re: IPv6 woes - RFC

22 PM Owen DeLong > <mailto:o...@delong.com>> wrote: >> >> >>> On Sep 29, 2021, at 09:25, Victor Kuarsingh >> <mailto:vic...@jvknet.com>> wrote: >>> >>>  >>> >>> >>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong

Re: IPv6 woes - RFC

> On Sep 30, 2021, at 19:35 , Victor Kuarsingh wrote: > > > > On Thu, Sep 30, 2021 at 10:01 PM Valdis Klētnieks > wrote: > On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said: > > > - Both providers provide IPv6 and delegate a prefix to the router (let'

Re: S.Korea broadband firm sues Netflix after traffic surge

The bottom line problem is that we have allowed vertical integration to allow the natural monopoly that exists in last mile infrastructure in most locations to be leveraged into an effective full-stack monopoly for those same players. Lack of competition in the last-mile/eyeball space has allowed

Re: FYI: NANOG and ICANN

I see this as a way to allow NANOG to help channel some of ICANN’s incredible excess of funding towards more useful pursuits than those ICANN has endowed so far. Owen > On Oct 4, 2021, at 9:27 AM, Edward McNair wrote: > > This partnership will have no ill effect on NANOG conferences. The focu

Re: FYI: NANOG and ICANN

> On Oct 8, 2021, at 12:39 PM, Warren Kumari wrote: > > > > On Fri, Oct 8, 2021 at 2:39 PM Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: > I see this as a way to allow NANOG to help channel some of ICANN’s incredible > excess of funding > toward

Re: DNS pulling BGP routes?

> On Oct 7, 2021, at 06:49 , Masataka Ohta > wrote: > > William Herrin wrote: > This is quite common to tie an underlying service announcement to BGP announcements in an Anycast or similar environment. >>> >>> Yes, that is a commonly seen mistake with anycast. >> You don't know wh

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 10, 2021, at 12:08 , Doug Barton wrote: > > On 10/1/21 7:45 AM, Mark Tinka wrote: >> The reason Google, Facebook, Microsoft, Amazon, e.t.c., all built their own >> global backbones is because of this nonsense that SK Broadband is trying to >> pull with Netflix. At some point, the co

Re: S.Korea broadband firm sues Netflix after traffic surge

>> (in the same way that corporations don't pay taxes, their customers do),... > > > Many a company pays corporate tax, which is separate from the income tax they > pay for compensation to their staff. > > Of course, YMMV depending on where you live. That’s irrelevant to what he is saying. Wh

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 10, 2021, at 13:18 , Mark Tinka wrote: > > > > On 10/10/21 22:10, Geoff Huston wrote: > >> I have to agree with Doug Barton's earlier observation is that the base >> problem is that the ISPs are using a flawed business model and they don't >> want to charge their customers what i

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 10, 2021, at 13:21 , Mark Tinka wrote: > > > > On 10/10/21 22:13, Michael Thomas wrote: > >> Isn't that what Erlang numbers are all about? My suspicion is that after >> about 100Mbs most people wouldn't notice the difference in most cases. My >> ISP is about 25Mbs on a good day (

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 11, 2021, at 00:01 , Mark Tinka wrote: > > > > On 10/11/21 00:31, Geoff Huston wrote: > >> In many environments, the words we use to describe this form of price >> setting are generally prefixed by the adjective “illegal” :-) > > Indeed - colluding is generally frowned upon, in w

Re: S.Korea broadband firm sues Netflix after traffic surge

> I am almost sure Netflix have some degree of presence in South Korea. What > I'm not sure about is what else SK wants them to do beyond that. They’ve made it pretty clear… They want Netflix to pay their protection^wbandwidth charges. >> And for the record, not only have I never worked for an

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 11, 2021, at 00:32 , Mark Tinka wrote: > > > > On 10/11/21 02:58, Owen DeLong wrote: > >> That’s irrelevant to what he is saying. >> >> What he’s saying (and he’s 100% correct) is that any tax a corporation pays >> is collected from their customers one way or another. >> >> A co

Re: S.Korea broadband firm sues Netflix after traffic surge

> Going back to the fact that it's not the content providers "using" > a lot of bandwidth, it's the eyeball customer *requesting* a lot > of bandwidth, I think the best approach is for the content providers > to help manage traffic levels by lowering bit rates towards eyeball > networks that ar

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 11, 2021, at 13:05 , Matthew Petach wrote: > > > > On Mon, Oct 11, 2021 at 1:01 AM Mark Tinka wrote: > However, in an era where content is making a push to get as close to the > eyeballs as possible, kit getting cheaper and faster because of merchant > silicon, and abundance of ag

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 11, 2021, at 13:57 , Matthew Walster wrote: > > > > On Mon, 11 Oct 2021 at 21:05, Matthew Petach > wrote: > I think it would be absolutely *stunning* for content providers > to turn the model on its head; use a bittorrent like model for > caching and

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 12, 2021, at 06:45 , Mark Tinka wrote: > > > > On 10/11/21 22:57, Matthew Walster wrote: > >> Ignoring for the moment that P2P is inherently difficult to stream with >> (you're usually downloading chunks in parallel, and with devices like Smart >> TVs etc you don't really have the

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 12, 2021, at 08:13 , Jared Brown wrote: > > Mark Tinka wrote: >> Someone can correct me if I'm wrong, but the way I know BitTorrent to >> work is the file is downloaded to disk, unarchived and then listed as >> ready to watch. > That's not how it works. Several streaming BitTorrent c

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 12, 2021, at 09:04 , Jared Brown wrote: > > Doug Barton wrote: >> One incentive I haven't seen anyone mention is that ISPs don't want to >> charge customers what it really costs to provide them access. > For the sake of argument, let's assume this is true. > > For this to work, I

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 18, 2021, at 14:48 , Jay Hennigan wrote: > > On 10/18/21 07:02, Josh Luthman wrote: > >>Netflix, as an example, has even been willing to bear most of the cost >>with peering or bringing servers to ISPs to reduce the ISP's costs and >>improve the ISP customer's experience.

Re: S.Korea broadband firm sues Netflix after traffic surge

… The trick is which side is able to convince the users that the other is the one preventing that. Owen > > On Mon, Oct 18, 2021 at 9:37 PM Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: > > > > On Oct 18, 2021, at 14:48 , Jay Hennigan > <mailto:j

Re: Network visibility

> On Oct 20, 2021, at 08:26 , Mel Beckman wrote: > > Mark, > > As long as we’re being pedantic, January 1, 1983 is considered the official > birthday of the Internet, when TCP/IP first let different kinds of computers > on different networks talk to each other. January 1, 1983 is actually

Re: Network visibility

> On Oct 20, 2021, at 11:31 , Miles Fidelman wrote: > > Jay Hennigan wrote: >> On 10/20/21 10:30, Mel Beckman wrote: >>> Owen, >>> >>> LOL! Yeah, and in 1838 Samuel Morse’s telegraph system used electric >>> impulses to transmit encoded messages over a wire to Speedwell Iron Works >>> in Mo

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 20, 2021, at 11:53 , Jared Brown wrote: > > Not to be outdone, British Telecom joins the cephalopod games: > > “Every Tbps (terabit-per-second) of data consumed over and above current > levels costs about £50m,” says Marc Allera, the chief executive of BT’s > consumer division. “In

Re: Network visibility

> On Oct 20, 2021, at 13:09 , Michael Thomas wrote: > > > > On 10/20/21 12:38 PM, james.cut...@consultant.com > wrote: >> I miss DECUS, but not DELNIs. I miss DECUS, too. Not only do I not miss DELNIs, I don’t miss any of the trappings of coaxial-base

Re: Network visibility

> On Oct 20, 2021, at 14:19 , b...@theworld.com wrote: > > > On October 20, 2021 at 16:08 m...@beckman.org (Mel Beckman) wrote: >> Mark, >> >> Before 1983, the ARPANET wasn’t an internet, let alone The Internet. Each >> ARPANET connection required a host-specific interface (the “IMP”) and sim

Re: S.Korea broadband firm sues Netflix after traffic surge

> On Oct 21, 2021, at 06:30 , Allen McKinley Kitchen (gmail) > wrote: > > > > ..Allen > >> On Oct 20, 2021, at 15:43, Matthew Walster wrote, >> among other things: >> >> Seems pretty disingenuous to now say the called party has to pay as well, in >> stark contrast to decades of precede

Re: Network visibility

> On Oct 21, 2021, at 08:55 , Mel Beckman wrote: > > >> On Oct 21, 2021, at 8:19 AM, Owen DeLong > > wrote: >> >> No, but you are ignoring the point of my message… >> >> The TCP/IP internet existed _BEFORE_ the flag day you mentioned. The flag >> day was the end of N

Re: S.Korea broadband firm sues Netflix after traffic surge

Uh, that is what is being said… The user originated the call, so the CDN shouldn’t have to pay the user’s ISP to deliver the replies to the users’ requests. Owen > On Oct 21, 2021, at 11:28 , Fred Baker wrote: > > I’m not sure I disagree, but let throw in a point of consideration. > Historic

Re: Network visibility

> On Oct 21, 2021, at 13:50 , Lady Benjamin Cannon of Glencoe, ASCE > wrote: > > Outside the datacenter is where DC power really shines in my opinion. Inside > the DC, everything is AC now and probably for the best. > > We never came up with a modular standard for -48VDC. Perhaps that coul

Re: more spaces in PTRs, this time totisp.net

\032 is not a space. Decimal 32 (0x20, \040) is a space. \032 is a Ctrl-Z (26 decimal, 0x1a) Owen > On Oct 21, 2021, at 22:14 , Mel Beckman wrote: > > Typo I’d say. DB-drive DNS servers, which don’t keep their entries in > traditional PTR-record text format, can fall victim to this. Rather

Re: Redploying most of 127/8 as unicast public

This will break a significant number of existing deployments where people have come to depend on a feature in Linux where any address within 127.0.0.0/8 can be “listened” and operate as a valid loopback address without configuring the addresses individually as unicast on the interface. In fact, th

Re: Redploying most of 127/8 as unicast public

> On Nov 17, 2021, at 16:32 , Sean Donelan wrote: > > On Wed, 17 Nov 2021, Jay R. Ashworth wrote: >> That's over a week old and I don't see 3000 comments on it, so maybe it's >> just >> me. So many things are just me. > > Someone is wrong on the Internet. > https://xkcd.com/386/ > > Other

Re: WKBI #586, Redploying most of 127/8 as unicast public

> On Nov 17, 2021, at 19:03 , John Levine wrote: > > It appears that Joe Maimon said: >> Mark Andrews wrote: >>> It’s a denial of service attack on the IETF process to keep bringing up >>> drafts like this that are never going to be approved. 127/8 is >> in use. It isn’t free. >> >> There

Re: Redploying most of 127/8 as unicast public

> On Nov 17, 2021, at 19:40 , Jerry Cloe wrote: > > > > Subject: Redploying most of 127/8 as unicast public > To: nanog mailto:nanog@nanog.org>>; > This seems like a really bad idea to me; am I really the only one who noticed? > > https://www.ietf.org/id/draft-schoen-intarea-unicast-127-0

Re: FERC releases final report on Texas power outages (2021)

Which is a double whammy for Californians after Enron managed to triple our electric rates practically overnight through their nefarious acts. Owen > On Nov 17, 2021, at 21:31 , Haudy Kazemi via NANOG wrote: > > Yet, in spite of claims of TX being an island, customers all over the country >

Re: Redploying most of 127/8 as unicast public

> On Nov 17, 2021, at 21:33 , Joe Maimon wrote: > > > > Mark Andrews wrote: >> >>> On 18 Nov 2021, at 11:58, Joe Maimon wrote: >>> >>> >>> >>> Mark Andrews wrote: It’s a denial of service attack on the IETF process to keep bringing up drafts like this that are never going to

Re: Redploying most of 127/8 as unicast public

Can you be more specific about what changes to IPv6 you believe would resolve the issue? Owen > On Nov 18, 2021, at 01:43 , b...@uu3.net wrote: > > No, you are not alone. This just gets kinda pathetic. > It also shows how an IPv6 is a failure. > (No please, leave me alone all you IPv6 zealots)

Re: WKBI #586, Redploying most of 127/8 as unicast public

I don’t see the difference between 6 and 7 usable addresses on all the /29s in the world as actually making a significant impact on the usable lifespan of IPv4. Owen > On Nov 17, 2021, at 19:33 , Dave Taht wrote: > > I am sad to see the most controversial of the proposals (127/16) first > disc

Re: Redploying most of 127/8 as unicast public

> > You are proposing a deal involving paper money you have on your person > to your fellow passengers on the Titanic; that is the essence of your > proposed bet hedging. Having studied the market for IPv4, it is a no- > brainer to realise the driving force behind all these schemes. Delaying > the

Re: Redploying most of 127/8 as unicast public

> On Nov 19, 2021, at 07:23 , Dave Taht wrote: > > On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG wrote: >> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not >> particularly widespread, having a prefix >> dedicated to that purpose

Re: Redploying most of 127/8 as unicast public

> On Nov 19, 2021, at 07:39 , Joe Maimon wrote: > > > > Owen DeLong wrote: >> >>> On Nov 17, 2021, at 21:33 , Joe Maimon wrote: >>> >>> >>> And I think the basic contention is that the vast majority of 127/8 is not >>> in use. Apples to oranges, indeed. >> This contention is provably fa

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

> On Nov 18, 2021, at 12:54 , John Gilmore wrote: > > Steven Bakker wrote: >> The ask is to update every ip stack in the world (including validation, >> equipment retirement, reconfiguration, etc)... > > This raises a great question. > > Is it even *doable*? What's the *risk*? What will i

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

> On Nov 19, 2021, at 10:22 , John Curran wrote: > > On 18 Nov 2021, at 8:14 PM, b...@theworld.com > wrote: >> That suggests an idea: >> >> Repurpose these addresses and allow the RIRs to sell them in the IPv4 >> secondary markets with some earmark for the funds. Pl

Re: Redploying most of 127/8 as unicast public

> On Nov 19, 2021, at 10:50 , Joe Maimon wrote: > > > > Owen DeLong wrote: >> >>> LLA and ULA and whatever random prefix you may wish to use for loopback, >>> whether in IPv6 or even IPv4 have none of these qualities. >> And if we implement the proposal at hand, which as near as I can tell

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

> On Nov 19, 2021, at 11:46 , John Gilmore wrote: > > Joe Maimon wrote: >> And all thats needed to be done is to drop this ridiculous .0 for >> broadcast compatibility from standards.why is this even controversial? > > Not to put words in his mouth, but that's how original BSD maintaine

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

> On Nov 19, 2021, at 12:11 , Jim wrote: > > On Thu, Nov 18, 2021 at 8:24 PM David Conrad wrote: >> > ... >> Some (not me) might argue it could (further) hamper IPv6 deployment by >> diverting limited resources. > > It may help IPv6 deployment if more V4 addresses are eventually > released

Re: is ipv6 fast, was silly Redeploying

> On Nov 20, 2021, at 00:41 , Masataka Ohta > wrote: > > Speed of router depends on degree of parallelism. > > So, for quick routing table lookup, if you provide 128bit TCAM > for IPv6 in addition to 32bit TCAM for IPv4, speed is mostly > same, though, for each entry, TCAM for IPv6 costs 4 t

Re: Redploying most of 127/8 as unicast public

> On Nov 20, 2021, at 03:16 , Matthew Walster wrote: > > > > On Sat, 20 Nov 2021, 09:21 Måns Nilsson, > wrote: > Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, > 2021 at 10:26:33AM +0900 Quoting Masataka Ohta > (mo...@necom830.h

Re: Redploying most of 127/8 as unicast public

> On Nov 20, 2021, at 13:15 , Matthew Walster wrote: > > > > On Sat, 20 Nov 2021 at 13:47, Måns Nilsson > wrote: > Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, > 2021 at 11:16:59AM + Quoting Matthew Walster (matt...@walster

Re: Redploying most of 127/8 as unicast public

Please make sure there’s video we can all watch when you try to take DoD’s IP addresses by force. ROFLMAO Owen > On Nov 20, 2021, at 11:20 , Gaurav Kansal wrote: > > > >> On 18-Nov-2021, at 09:10, Jerry Cloe > > wrote: >> >> >> >> Subject: Redploying most of 1

Re: Redploying most of 127/8 as unicast public

> On Nov 20, 2021, at 15:35 , Matthew Walster wrote: > > > > On Sat, 20 Nov 2021 at 22:35, Owen DeLong > wrote: >> On Nov 20, 2021, at 03:16 , Matthew Walster > > wrote: >> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, >

Re: Redploying most of 127/8 as unicast public

> On Nov 20, 2021, at 19:11 , Joe Maimon wrote: > > > > Owen DeLong wrote: >> >> I guess I don’t see the need/benefit for a dedicated loopback prefix in >> excess of one address. I’m not necessary inherently opposed to designating >> one (which would be all that is required for IPv6 to ha

Re: Redploying most of 127/8 as unicast public

> On Nov 20, 2021, at 19:47 , Joe Maimon wrote: > > > > Owen DeLong via NANOG wrote: > > (snips for brevity and reply relevancy) >> >> This is a common fallacy… The real concept here isn’t “universal >> reachability”, but universal transparent ad

Re: Redploying most of 127/8 as unicast public

> On Nov 20, 2021, at 20:37 , Joe Maimon wrote: > > > > Owen DeLong wrote: >> >>> On Nov 20, 2021, at 19:11 , Joe Maimon wrote: >>> >>> >>> >>> Owen DeLong wrote: I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary

Re: Redploying most of 127/8 as unicast public

> On Nov 20, 2021, at 21:00 , Joe Maimon wrote: > > > > Owen DeLong wrote: > >> Agreed. But I have every right to express my desires and displeasures with >> widespread plans to encourage what I perceive as misuse and that’s exactly >> what’s happening here. >> >> My right to attempt to

Re: is ipv6 fast, was silly Redeploying

> On Nov 21, 2021, at 09:04 , Masataka Ohta > wrote: > > Owen DeLong wrote: > >> Uh, no. It is so because on average IPv4 is so fragmented that most >> providers of any size are advertising 8+ prefixes compared to a more >> realistic IPv6 average of 1-3. > > Mergers of entities having an IP

Re: is ipv6 fast, was silly Redeploying

> On Nov 22, 2021, at 02:45 , Masataka Ohta > wrote: > > Mans Nilsson wrote: > > > Not everyone are Apple, "hp"[0] or MIT, where initial > > allocation still is mostly sufficient. > > The number of routing table entries is growing exponentially, > not because of increase of the number of IS

Re: is ipv6 fast, was silly Redeploying

> On Nov 23, 2021, at 12:28 AM, Masataka Ohta > wrote: > > Owen DeLong wrote: > >>> The number of routing table entries is growing exponentially, not >>> because of increase of the number of ISPs, but because of multihoming. >> Again, wrong. The number is growing exponentially primarily becau

Re: multihoming

> On Nov 25, 2021, at 12:06 , Michael Thomas wrote: > > > On 11/25/21 11:54 AM, Bjørn Mork wrote: >> Christopher Morrow writes: >> >>> Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows... >>> nor IPSEC nor GRE nor... >>> unless you HTTP over MP-TCP and encap UDP/ICMP/GR

Re: IPv6 and CDN's

> On Nov 27, 2021, at 06:04 , Mark Tinka wrote: > > > > On 11/27/21 02:41, Michael Thomas wrote: > >> Amazon's in this case. They are monetizing their lack of v6 support >> requiring you go through all kinds of expensive hoops instead of doing the >> obvious and routing v6 packets. >> >

Re: IPv6 and CDN's

> On Nov 27, 2021, at 06:05 , Mark Tinka wrote: > > > > On 11/27/21 02:39, Jean St-Laurent via NANOG wrote: > >> But CFOs like monetization. Was that thread about IPv6 or CFO? > > In 2021, what's the difference? > > Mark. Even in 2021, one improves network capabilities while the other cou

Re: IPv6 and CDN's

> On Nov 27, 2021, at 06:05 , Mark Tinka wrote: > > > > On 11/27/21 02:15, Jean St-Laurent via NANOG wrote: > >> We now have apple and fb saying ipv6 is faster than ipv4. >> >> If we can onboard Amazon, Netflix, Google and some others, then it is a done >> deal that ipv6 is indeed faster

Re: IPv6 and CDN's

Actually, I think it’s in the fine print here… “Connection setup is 1.4 times faster”. I can believe that NAT adds almost 40% overhead to the connection setup (3-way handshake) and some of the differences in packet handling in the fast path between v4 and v6 could contribute the small remaining

Re: IPv6 and CDN's

, so if it takes 1.4 times as long in IPv4, that’d be 70-210 ms, so still mostly under 1/5th of a second, which is not below human perception, but likely below human notice. Owen > On Nov 27, 2021, at 14:30 , Michael Thomas wrote: > > > On 11/27/21 2:22 PM, Owen DeLong via

Re: IPv6 and CDN's

> On Nov 27, 2021, at 17:21 , Christopher Morrow > wrote: > > > > On Sat, Nov 27, 2021, 17:36 Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: > Well, 1.4x faster is a bit of an odd metric. I presume that means that > connection set up times measured

Re: IPv6 and CDN's

> On Nov 27, 2021, at 19:37 , Masataka Ohta > wrote: > > Mark Tinka wrote: > >> On 11/27/21 17:07, Masataka Ohta wrote: >>> Because lengthy IPv6 addresses mean a lot more opex than IPv4. >> I disagree > > Try to type in raw IPv6 addresses. Rarely necessary in the modern age, but really not

Re: IPv6 and CDN's

> On Nov 28, 2021, at 02:42 , Mark Tinka wrote: > > > > On 11/28/21 06:43, Masataka Ohta wrote: > >> >> Here in nanog, we are talking about network operations, considerable >> part of which can not rely on DNS. > > And yet Facebook were unable to access their kit to fix their recent outag

Re: IPv6 and CDN's

> On Nov 28, 2021, at 04:58 , Masataka Ohta > wrote: > > Mark Tinka wrote: > >>> Here in nanog, we are talking about network operations, considerable >>> part of which can not rely on DNS. >> And yet Facebook were unable to access their kit to fix their recent outage >> because of it (or, l

Re: IPv6 and CDN's

> On Nov 28, 2021, at 08:55 , Mark Tinka wrote: > > > > On 11/28/21 16:20, Jean St-Laurent via NANOG wrote: > >> I like to put some servers behind that scheme. >> >> 2601::443: for https servers >> 2601::25: for MTA servers. >> 2601::993: for IMAP >> >> It gives a quick note

Re: IPv6 and CDN's

> On Nov 28, 2021, at 15:51 , Mark Andrews wrote: > > > >> On 29 Nov 2021, at 09:41, scott wrote: >> >> >> On 11/28/2021 9:47 AM, Owen DeLong via NANOG wrote: >>> Why not properl

Re: IPv6 and CDN's

> On Nov 28, 2021, at 23:19 , Mark Tinka wrote: > > > > On 11/29/21 00:41, scott wrote: > >> Side note: I recently tried to get /48 per customer with ARIN on repeated >> emails and they refused. We were already given an IPv6 block a while back. >> I told them I wanted to expand it so I

Re: IPv6 and CDN's

> On Nov 28, 2021, at 23:25 , Mark Tinka wrote: > > > > On 11/29/21 03:33, Masataka Ohta wrote: > >> The end result was that our DNS servers became unreachable even though they >> were still operational. This made it impossible for the rest of the internet >> to find our servers. > > So

Re: questions about ARIN ipv6 allocation

> On Dec 3, 2021, at 12:44 PM, Edvinas Kairys wrote: > > Hello, > > We're setting up IPv6 network is USA. Our company has branches and different > legal entities in EU and US. We've some ipv6 PI subnets already allocated by > RIPE for EU datacenters. I have few questions: > > 1) Is it poss

Re: questions about ARIN ipv6 allocation

> On Dec 4, 2021, at 8:59 AM, John Curran wrote: > > Just for clarity - ARIN’s fee schedule is such that ISP customers (i.e. those > with registration service plans) pay an annual services fee based on their > higher category of IPv4 or IPv6 resources – i.e. those with IPv4 resources > can

Re: questions about ARIN ipv6 allocation

I would be more than happy to consilolidate my ipv6 addresses under my lrsa, but ARIN will not allow it. Owen > On Dec 4, 2021, at 17:43, John Curran wrote: > >  Yes Owen, that is correct… > > If an organization insists on maintaining multiple contractual relationships > with ARIN (for wh

Re: questions about ARIN ipv6 allocation

I’d also be willing to consolidate under RSA if I could get the same protections I have under LRSA. ARIN won’t do that, either. Owen > On Dec 4, 2021, at 7:12 PM, John Curran wrote: > > Owen - > > Correct - ARIN will not allow you to bring non-legacy resources under > an LRSA agreeme

Re: questions about ARIN ipv6 allocation

> On Dec 4, 2021, at 8:24 PM, Sylvain Baya wrote: > > Dear NANOGers, > > Le dim. 5 déc. 2021 04:00, Owen DeLong via NANOG <mailto:nanog@nanog.org>> a écrit : > I would be more than happy to consilolidate my ipv6 addresses under my lrsa, > but ARIN will

Re: questions about ARIN ipv6 allocation

> On Dec 5, 2021, at 4:24 AM, Rubens Kuhl wrote: > > On Sun, Dec 5, 2021 at 12:00 AM Owen DeLong via NANOG wrote: >> >> I would be more than happy to consilolidate my ipv6 addresses under my lrsa, >> but ARIN will not allow it. > > > And they are ri

Re: questions about ARIN ipv6 allocation

> On Dec 5, 2021, at 7:41 AM, Gary Buhrmaster wrote: > > On Sun, Dec 5, 2021 at 2:23 PM Owen DeLong via NANOG wrote: > >> The double billing (had it been present at the time) would have prevented me >> from signing the LRSA for my IPv4 resources. > > There we

Re: questions about ARIN ipv6 allocation

> On Dec 5, 2021, at 9:03 AM, John Curran wrote: > > Owen - > > The RSA and LRSA agreements are identical, however, it is true that you would > lose legacy holder resource status (for those IPv4 resources issued to you > before ARIN’s formation) if you consolidate to a single Org with one b

Re: questions about ARIN ipv6 allocation

> On Dec 5, 2021, at 10:42 AM, William Herrin wrote: > > On Sun, Dec 5, 2021 at 7:43 AM Gary Buhrmaster > wrote: >> On Sun, Dec 5, 2021 at 2:23 PM Owen DeLong via NANOG wrote: >>> The double billing (had it been present at the time) would have prevented >>

Re: .bv ccTLD

> On Dec 5, 2021, at 10:59 PM, Stephane Bortzmeyer wrote: > > On Sat, Dec 04, 2021 at 10:20:16AM -0500, > Jay Ashworth wrote > a message of 121 lines which said: > >> Oh dear. They actually gave them .SS? > > It's an european reference. For the local people, this 2-letters code > probably

Re: questions about ARIN ipv6 allocation

> On Dec 6, 2021, at 19:28, Gary Buhrmaster wrote: > > On Mon, Dec 6, 2021 at 5:59 PM Owen DeLong wrote: > >> The situation is such that the current economic incentives would be most >> advantageous to me to preserve my LRSA and abandon my RSA, which would >> involve simply turning off IP

Re: questions about ARIN ipv6 allocation

> On Dec 11, 2021, at 02:44 , John Curran wrote: > > >> On 10 Dec 2021, at 5:00 PM, John Gilmore > > wrote: >> ... >> Owen, the root of your problem is that you signed an LRSA with ARIN, >> rather than keeping your legacy resources un-tainted by an ARIN contract >> that d

Re: Log4j mitigation

The bigger problem seems to be the ever growing list of products you may be using which depend on it potentially without your knowledge. Owen > On Dec 11, 2021, at 03:41 , Jared Mauch wrote: > > This is largely a patching exercise for people that use the software. If you > use it, please pat

Re: Log4j mitigation

> On Dec 11, 2021, at 04:11 , Nick Hilliard wrote: > > Andy Ringsmuth wrote on 11/12/2021 03:54: >> The intricacies of Java are over my head, but I’ve been reading about this >> Log4j issue that sounds pretty bad. >> What do we know about this? What, if anything, can a network operator do to

Re: Log4j mitigation

> On Dec 14, 2021, at 06:54 , Doug McIntyre wrote: > > On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote: >>> On Dec 11, 2021, at 04:11 , Nick Hilliard wrote: > ... >>> https://logging.apache.org/log4j/2.x/security.html >>> >>

Re: Log4j mitigation

c 14, 2021 at 6:57 AM Doug McIntyre <mailto:mer...@geeks.org>> wrote: > On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote: > > > On Dec 11, 2021, at 04:11 , Nick Hilliard > > <mailto:n...@foobar.org>> wrote: > ... > > > https://log

<    1   2   3   4   5   >