November 2019 - Test - lists.nanog.org

We've lost another innovator
by Rich Kulawiec 28 Nov '19

28 Nov '19

----- Forwarded message from Russ Allbery <eagle(a)eyrie.org> ----- > From: Russ Allbery <eagle(a)eyrie.org> > Date: Tue, 26 Nov 2019 20:56:23 -0800 > Subject: Brian Kantor has died > > Slashdot reported, via a contributor from the 44Net amateur radio mailing > list, that Brian Kantor died suddenly in his home last week. > > https://tech.slashdot.org/story/19/11/24/0051236/brian-kantor-internet-and-… > > Brian was the co-inventor of NNTP and the co-author of RFC 977, with Phil > Lapsley. I never met him in person, but have had several opportunities to > chat with him electronically, including as recently as last month (via > NNTP and netnews newsgroups, of course). He will be missed. I never met Brian either, but have "known" him electronically for decades. His was a voice I always paid attention to, even when I disagreed with what he had to say. I'm sorry he's gone, and I'll miss him. ---rsk

3 2

Comcast iNET Contact
by Stephen M 27 Nov '19

27 Nov '19

Hello, I'm a network engineer with a county government and I'm trying to get in contact with someone from Comcast who can provide a .KMZ or similar of our iNET (Institutional Network) dark fiber. I've called through the normal support lines and gotten bounced around a few times... Which isn't surprising... This stuff is 20 years or so old. Thanks in advance! Cheers, Stephen //please pardon any brevities - sent from mobile//

4 4

Re: RIPE our of IPv4
by Scott Weeks 27 Nov '19

27 Nov '19

--- surfer(a)mauigateway.com wrote: From: "Scott Weeks" <surfer(a)mauigateway.com> No, it's just that (at least in my case at several different companies) we're so focused by management on getting the sale done by augmenting the existing network there is not enough time to devote to **planning an entire network from the ground up**, then working your plan. The other way (just start configuring stuff) is replete with troubles. BTW, I have been the IPv6 loudmouth every time, but I don't get any traction at all in any of the companies I've worked for. Eyes gloss over and someone quickly changes the conversation. Then we talk about sizing subnets and stuff... --------------------------------------------- BTW, what Mark Andrews said about 6rd fixes (I'm assuming a relatively low level of network architecturing work is necessary to get it done) what I am saying, but it feels so dirty. I would like to go straight to dual stack. scott

1 0

Re: RIPE our of IPv4
by Scott Weeks 27 Nov '19

27 Nov '19

--- brandon(a)rd.bbc.co.uk wrote: From: Brandon Butterworth <brandon(a)rd.bbc.co.uk> If you're an internet professional you are a negligent one if by now you are not ensuring all you build quietly includes IPv6, no customer should need to know to ask for it. It's not like it needs different kit. ----------------------------------------------------- No, it's just that (at least in my case at several different companies) we're so focused by management on getting the sale done by augmenting the existing network there is not enough time to devote to **planning an entire network from the ground up**, then working your plan. The other way (just start configuring stuff) is replete with troubles. BTW, I have been the IPv6 loudmouth every time, but I don't get any traction at all in any of the companies I've worked for. Eyes gloss over and someone quickly changes the conversation. Then we talk about sizing subnets and stuff... scott

1 0

Re: RIPE our of IPv4
by Scott Weeks 27 Nov '19

27 Nov '19

Top posting... --------------------------------- :: But it is not that simple in the real corporate world. :: Execs have bonus targets. Why would an exec care? Ipv6 is just normal work like ipv4. --------------------------------- No, you have to make purchases and have folks across the company do work to get everything going. Refocusing folks work on deploying IPv6 to *everything* (rather than, say, getting that shiny new Nokia 7750 deployed so we can sell more services) costs money. Ancient boxen are out here and don't support aye pee vee six well or at all. Getting ones that do costs money. Training lower level folks takes them away from their current work and costs money. Etc. ::> - Modifying old (ancient) internal code; :: Ancient in 2019 means what? Is this code not in security :: compliance ? I recently started back with a company after being gone nine years. My code was still running and no one in neteng had the knowledge of how to do anything with it much less to try to write in IPv6 sections. To take an SA and look into the networking code I wrote takes them away from things they need to do to sell services. That costs money. What Sabri wrote hit home here. Folks are not looking into it and will wait until forced to do so. Then said companies will be behind the ball in a big way, but that it what it is here and in the other companies I worked for. A lot of this read to me as flippant. You don't seem to be willing to listen to those of us out here on the raggedy edges. I've said what Sabri said at least a few times on this list. scott --- cb.list6(a)gmail.com wrote: From: Ca By <cb.list6(a)gmail.com> To: Sabri Berisha <sabri(a)cluecentral.net> Cc: nanog <nanog(a)nanog.org> Subject: Re: RIPE our of IPv4 Date: Tue, 26 Nov 2019 15:11:40 -0800 On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri(a)cluecentral.net> wrote: > ----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb(a)dougbarton.us wrote: > > > I get that some people still don't like it, but the answer is IPv6. Or, > > folks can keep playing NAT games, etc. But one wonders at what point > > rolling out IPv6 costs less than all the fun you get with [CG]NAT. > > When the MBAs start realizing the risk of not deploying it. > Hey, i have an mba. That and $5 will get me cup of coffee. > I have some inside knowledge about the IPv6 efforts of a large eyeball > network. Me too. In that particular case, the cost of deploying IPv6 internally is not > simply configuring it on the network gear; that has already been done. The > cost of fully supporting IPv6 includes (but is probably not limited to): > > - Support for deploying IPv6 across more than 20 different teams; Wow. I support 80M mobile subscribers, 90% of which are ipv6-only. I think 20 people in the company can spell ipv6, but somehow you need 20 teams.... how many teams speak ipv4 ? > - Modifying old (ancient) internal code; Ancient in 2019 means what? Is this code not in security compliance ? > - Modifying old (ancient) database structures (think 16 character fields > for IP addresses); Hash 128 bits into 240/4 is how i heard Google handled it early on > - Upgrading/replacing load balancers and other legacy crap that only > support IPv4 (yeah, they still exist); Again, with all the CVEs, this code is always moving in the real world. > - Modifying the countless home-grown tools that automate firewalls etc; Home grown means it can be fixed instead of replaced. > - Auditing the PCI infrastructure to ensure it is still compliant after > deploying IPv6; > Ah, so you are keeping up with compliance / cve and are upgrading at regular intervals? > If it was as simple as upgrading a few IP stacks here and there, it would > be a non-issue. > Usually is just a few edge stacks to start and scale the edge > Don't get me wrong, I'm not advocating against IPv6 deployment; on the > contrary. But it is not that simple in the real corporate world. Execs have > bonus targets. Why would an exec care? Ipv6 is just normal work like ipv4. IPv6 is not yet important enough to become part of that bonus target: The bonus target was normal business continuity planning... in 2008. Sorry you missed that one. Here you go, just put 1 in 2009 to make it 2019 so you dont look so bad https://www.arin.net/vault/knowledge/about_resources/ceo_letter.pdf there is no ROI at this point. In this kind of environment there needs to > be a strong case to invest the capex to support IPv6. > > IPv6 must be supported on the CxO level in order to be deployed. > > Thanks, > > Sabri, (Badum tsss) MBA I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile providers in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets. >

5 4

Re: RIPE our of IPv4
by Scott Weeks 27 Nov '19

27 Nov '19

--- cb.list6(a)gmail.com wrote: From: Ca By <cb.list6(a)gmail.com> If your business is dysfunctional, that is a different issue from ipv6 being dysfunctional. ----------------------------------------- I was just expressing the problems eyeball networks are having getting this done. Shittons of stuff is out there in the CPE that mobile and DC networks do not have to deal with. The suits are looking at the short term cost/risk. scott

3 2

Re: RIPE our of IPv4
by Scott Weeks 27 Nov '19

27 Nov '19

--- cdel(a)firsthand.net wrote: From: Christian <cdel(a)firsthand.net> Sounds like your company is about to go offline. So I will say bye bye for now just in case it happens faster than you expected. --------------------------------------------- Speaking of flippant... No the ILEC has been here since the 1800s. I don't think it's going anywhere fast. scott

2 1

Question about normal ops - BGP Flaps nightly
by Christopher Morrow 27 Nov '19

27 Nov '19

Howdy! A question of interest to me, currently, is whether it's normal for providers to cause BGP flaps to their customers nightly... This seems, in my case, to be the provider PROBABLY updating prefix-filters on my session(s). Particularly AS56554 is currently getting v4/v6 transit from 2 providers, one of which we have 2 links toward. That provider appears to flap both of our ipv6 (only) bgp peers each night at about the same time each night. This smells like: "filter updates', but something that's different than the v4 filter update? (or perhaps they have no v4 filtering to update?) In the end, should customers expect nightly (or on a regular cadence) to see their sessions bounce? It hasn't been my experience in other situations... -chris

9 13

Landing Stations used as datacenter
by Mehmet Akcin 27 Nov '19

27 Nov '19

Hey there I have been putting my thoughts on Infrapedia blog and sharing with folks like https://www.infrapedia.com/post/top20cities-datacenters I am working on a new article and this time my topic will be looking at cable landing stations(cls). Do you consider cable landing stations as a datacenter? Do you have any experience deploying a pop in CLS? Are you able to share (on or off record) your experience which I can refer as your experience (good or bad) why deploying a pop inside a CLS is good or bad idea. Any additional comments.. I am not a big fan of CLS deployments. They have limited networks ( like only carriers and no eyeballs) and very expensive connectivity (usually) Thank you in advance sharing your experience Mehmet -- Mehmet +1-424-298-1903

12 18

Re: RIPE our of IPv4
by Willy Manga 27 Nov '19

27 Nov '19

Hello, On 26/11/2019 16:00, nanog-request(a)nanog.org wrote: > Date: Tue, 26 Nov 2019 00:13:48 -0800 (PST) > From: Sabri Berisha <sabri(a)cluecentral.net> > To: Doug Barton <dougb(a)dougbarton.us> > Cc: nanog <nanog(a)nanog.org> > Subject: Re: RIPE our of IPv4 > Message-ID: > <1383247942.183700.1574756028904.JavaMail.zimbra(a)cluecentral.net> > Content-Type: text/plain; charset=utf-8 > > ----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb(a)dougbarton.us wrote: > >> I get that some people still don't like it, but the answer is IPv6. Or, >> folks can keep playing NAT games, etc. But one wonders at what point >> rolling out IPv6 costs less than all the fun you get with [CG]NAT. > When the MBAs start realizing the risk of not deploying it. > > I have some inside knowledge about the IPv6 efforts of a large eyeball network. In that particular case, the cost of deploying IPv6 internally is not simply configuring it on the network gear; that has already been done. The cost of fully supporting IPv6 includes (but is probably not limited to): > > - Support for deploying IPv6 across more than 20 different teams; > - Modifying old (ancient) internal code; > - Modifying old (ancient) database structures (think 16 character fields for IP addresses); > - Upgrading/replacing load balancers and other legacy crap that only support IPv4 (yeah, they still exist); > - Modifying the countless home-grown tools that automate firewalls etc; > - Auditing the PCI infrastructure to ensure it is still compliant after deploying IPv6; > > If it was as simple as upgrading a few IP stacks here and there, it would be a non-issue. No matter how complex is your network (and your teams), from my humble point of view, there is always something you can do regarding IPv6. The key is not to solve one million problems on one day. The key is to go gradually, one small block after another one. You can even keep all your internal network on v4 (forever if that is your intent ) and use IPv6 on specific portions of your network. > Don't get me wrong, I'm not advocating against IPv6 deployment; on the contrary. But it is not that simple in the real corporate world. Execs have bonus targets. IPv6 is not yet important enough to become part of that bonus target: there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. > > IPv6 must be supported on the CxO level in order to be deployed. I would have said the very very minimum could be to invest in a dual-stack 'proxy' for public-facing services; internal or external solution, you have the choice. And why even do that ? Because the other side is not only on IPv4. -- Willy Manga @ongolaboy https://ongola.blogspot.com/

3 2