Re: 165 Halsey recurring power issues

[Joe Maimon]

Willing to bet that there was slicing on both sides of that conversation 
and this is what I will now refer to as the expected and resulting razor 
burn.


Babak Pasdar wrote:

Thanks James,

At signup we asked for N+1 power, two circuits to different UPS units. 
I think they sliced it thin by connecting us to two battery packs on 
the same UPS. When the UPS controller crashed both battery packs went 
down.  Which now raises the question -- is it reasonable to have to 
specify and expect that two UPS units means that they do not share any 
common points of failure.


Is the UPS the battery or the battery and controller combined?

Babak



On 10/23/23 15:16, James Jun wrote:

On Mon, Oct 23, 2023 at 10:38:09AM -0400, Babak Pasdar wrote:

I wanted to get some feedback as to what is considered standard A/B
power setup when data centers sell redundant power.?? It has always 
been
my understanding that A/B power means individually unique and 
preferably

alternate path connections to disparate UPS units.
Generally speaking, the definition of A/B has become muddied in 
recent decades.  It has almost become an inaccurate marketing term.


Most sane people have the opinion (myself included) that when "A/B" 
power is offered, it is at minimum offererd as 2N UPS (different 
building entrance and MSBs and even physically separate UPS rooms are 
also desired on a true 2N A/B, but may not always be available).  
Some data center operators go even further and architect load 
switching within their distribution, thereby preventing 
single-side/one-leg power outages for customers during most of their 
power maintenance activities


Some data center operators treat "A/B" as convenience for them to 
undertake maintenance and offload uptime responsibilities to their 
own customers, and require them to either undertake their own 
transfer switching and/or dual-cord every equipment, so that they can 
keep taking one side of the power system down for repeated 
maintenance.  This does not scale well for retail colo, as not every 
customer is going to be good at maintaining two PSUs for every single 
piece of equipment.


Some data centers also view "N+1" system deployment at the UPS as an 
acceptable form of A/B protection, as long as customer circuits are 
on different PDUs.


Long story short, whether you're receiving N+1 or 2N or 1N, it's 
important to inquire about how your power circuits will be 
architected and delivered by the data center, and either have that 
codified in the contract or reflected appropriately in SLA offering.  
There is nothing wrong with the data center providing N+1 or 1N 
power, as long as they're transparent about it and that it is what 
you're willing to accept for the right terms. However, simply 
accepting "we are providing you A/B power" or "we've never had 
primary power failure" are not sufficient to meet proper due 
diligence during a site selection process, unless you can accept the 
site outage occurring from time to time, or you're deploying your own 
power plant (i.e. DC power and batteries) to supplant data center's 
own power protection scheme.


James

Re: 165 Halsey recurring power issues

[Joe Maimon]

The building itself got into the action and their goal was to make a top 
notch facility focusing on central patch panel fiber cross connects. 
They started with half of the 9th floor originally called MMR-2 and 
continued with multiple spaces each bigger as it was quite successful. 
No raised floors, properly positioned chillers, ample power, basic but 
standard and roomy cabinets, one time fee per cross connect (plus 
initial cabling and panel setup OTC) and they have been very succesfull 
by all appearances.


Staff reflected their initial goals and I have always interacted well 
with them.


Original mmr where each xcon was actualy pulled space to space was quite 
a sight with multiple cable conduits and trays running from the tops of 
the cabs to the ceiling, all full. New space adopted modern approaches 
and looked it.


Joe

Sean Donelan wrote:

ine tume
165 Halsey (and most of its tenant) data centers is an older facility. 
Data center practices have changed over the decades, and terminlogy 
wasn't standardized until recently.



The biggest FUBAR in telco and data centers is the difference between 
"redundancy" and "diversity."


Redundant A/B power feeds are often multiple cables from the same 
power source.


Diverse A/B power feeds are cables from different backup power sources 
(within limits).  1-utility, 2 battery strings or backup generators. 
Often routed through in same conduits/cable trays. But both may be out 
of service for scheduled maintenance and some kinds of faults.


Add a spare A/B power feed.  Generally a N+1 backup power source and 
some additional power switching capability.


Fault tolerant A/B power.  Everything from utility to rack is diverse 
and redudant (cables, conduit/cable trays, switching equipment and 
backup sources).  Maintenance can be performed on one of the power 
feeds without affecting the other feeds.  Does not include redundant 
utility feed (not redundant substation, utility).


Cost increase 2x, 5x, 10x

I haven't toured 165 Halsey for 10+ years, so I don't know its current 
state.  It has multiple tenant data centers, so some may be better 
than others.



On Mon, 23 Oct 2023, Babak Pasdar wrote:

Hello,

I wanted to get some feedback as to what is considered standard A/B 
power setup when data centers sell redundant power.  It has always 
been my understanding that A/B power means individually unique and 
preferably alternate path connections to disparate UPS units.


A few months ago, 165 Halsey took us down for several hours. They 
claimed that a UPS failed causing this issue.  Our natural reaction 
was that we have A/B redundant power so a failed UPS on the A circuit 
should not take down the cabinet. Joe the facility manager claimed 
that industry standard A/B power means two circuits to the same UPS, 
which makes no sense to me.


They committed to move us to A/B power with redundant circuits to 
disparate UPS units.  However, we had a multi-hour outage again in 
that site this weekend. At first glance it seems to be the same problem.


We have checked with all of our other data center providers who have 
confirmed A/B power is in fact individually unique connections to 
disparate UPS units. 165 Halsey's definition of what constitutes 
redundant power seems unique. Why would anyone pay extra for a second 
connection to the same UPS?  However, I wanted to get feedback to see 
if I am taking crazy pills here 


None-the-less, we have lost all confidence in this facility.

Best Regards,

Babak

Re: SDN Internet Router (sir)

[Joe Maimon]

om/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
--------
*From: *"Mel Beckman" 
*To: *"Mike Hammett" 
*Cc: *"Joe Maimon" , "NANOG" 
*Sent: *Thursday, January 5, 2023 2:54:27 PM
*Subject: *Re: SDN Internet Router (sir)

Mike,

I’m not sure I understand what you mean by “suboptimal“ routing. Even 
though the Internet uses AS path length for routing,  many of those 
path lengths are bogus, and don’t really represent any kind of path 
performance value. For example, a single AS might hide many hops in 
an MPLS network as a single hop, obscuring asymmetric routing and 
other uglies. Prepending also occurs when destinations are trying to 
enforce their own engineering  policies, which often conflict with 
yours or mine.


So what do you mean by “suboptimal“? Are you thinking that the “best” 
path in BGP tables actually meant you were getting a performance 
benefit? Because that’s definitely not the case in today’s Internet. 
Were were you thinking that you would be going along less congested 
paths? That’s really at the mercy of the traffic engineering of 
backbone providers over which we have no control.


I generally populate local router FIBs to merel choose an exit point 
for purposes of load balancing, and nothing more.


 -mel

On Jan 5, 2023, at 12:38 PM, Mike Hammett  wrote:


I guess I wasn't around for those days.

As far as running out, again, assuming the tooling works
correctly, I'd think to target fewer routes than you could hold.
Maybe 1k routes is all one would need to get a significant
percent of the traffic. A lot of room to mess up if you can hold
100k, 500k routes.



-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>

<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>

<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>

<https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

*From: *"Joe Maimon" 
*To: *"Mike Hammett" , "Christopher Morrow"

*Cc: *"NANOG" 
*Sent: *Thursday, January 5, 2023 2:30:40 PM
*Subject: *Re: SDN Internet Router (sir)



Mike Hammett wrote:
> I'm not concerned with which technology or buzzword gets the
job done,
> only that the job is done.
>
>
>
> Looking briefly at the couple of things out there, they're
evaluating
> the top X prefixes in terms of traffic reported by s-flow,
where X is
> the number I define, and those get pushed into the FIB. One
> recalculates every hour, one does so more quickly. How much is
> appropriate? I'm not sure. I can't imagine it would *NEED* to
be done
> all of that often, given the traffic/prefix density an eyeball
network
> will have. Default routes carry the rest. Default routes could be
> handled outside of this process, such that if this process
fails, you
> just get some sub-optimal routing until repaired. Maybe it doesn't
> filter properly and sends a bunch of routes. Then just have a
prefix
> limit set on the box. Maybe it sends the wrong prefixes. No
harm, no
> foul. If you're routing sub-optimally internally, when it does
hit a
> real router with a full FIB, it gets handled appropriately.

Unless it loops.

The rest sounds nice. But flow caching got a bad rap back in the
early
worm days. But thats because the situation was a little worse
back then.
Cache the wrong routes or run out of cache, router dies. So long as
thats not the case automating optimization is an extremely
valuable goal.

>
>
> I would just be looking for solutions that influence what's in
the FIB
> and let the rest of the router work as the rest of the router
would.

The problem comes when the router wont work at all without the FIB
routes, like in the olden days.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
>

<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
> Mid

Re: SDN Internet Router (sir)

[Joe Maimon]

This is not a green grass problem space.

https://www.cisco.com/c/en/us/products/ios-nx-os-software/performance-routing-pfr/index.html

And you could probably envision how you could create your own internal 
scheme of route reflectors/servers, community tags, probers and updaters 
to achieve something similar.


Most likely Mike is referring to the sub-optimal result where a large 
percentage of a router's traffic is taking extra internal hops or worse, 
maybe even egressing from the AS into a less than optimal path, not 
because the AS does not have the correct route for the most likely as 
perceived by BGP optimal path, but that the traffic handling device was 
not able to be configured to accept any such routes, because doing such 
statically is not likely to achieve the results and more likely to 
result in crashed routers one unexpected fine morning.


Nanogers pointed me at this some time back, I think its germaine

https://blog.google/products/google-cloud/making-google-cloud-faster-more-available-and-cost-effective-extending-sdn-public-internet-espresso/

RIB/FIB static configuration limitation tip:

Apply the same logic on all similar capacity devices to cut down on the 
RIBFIB, because thats the best way to minimize loops. And a guaranteed 
loop free path for the default route. Policy or tag tunnel or whatever.


Joe


Mel Beckman wrote:

Mike,

I’m not sure I understand what you mean by “suboptimal“ routing. Even 
though the Internet uses AS path length for routing,  many of those 
path lengths are bogus, and don’t really represent any kind of path 
performance value. For example, a single AS might hide many hops in an 
MPLS network as a single hop, obscuring asymmetric routing and other 
uglies. Prepending also occurs when destinations are trying to enforce 
their own engineering  policies, which often conflict with yours or mine.


So what do you mean by “suboptimal“? Are you thinking that the “best” 
path in BGP tables actually meant you were getting a performance 
benefit? Because that’s definitely not the case in today’s Internet. 
Were were you thinking that you would be going along less congested 
paths? That’s really at the mercy of the traffic engineering of 
backbone providers over which we have no control.


I generally populate local router FIBs to merel choose an exit point 
for purposes of load balancing, and nothing more.


 -mel


On Jan 5, 2023, at 12:38 PM, Mike Hammett  wrote:


I guess I wasn't around for those days.

As far as running out, again, assuming the tooling works correctly, 
I'd think to target fewer routes than you could hold. Maybe 1k routes 
is all one would need to get a significant percent of the traffic. A 
lot of room to mess up if you can hold 100k, 500k routes.




-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>
<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>
<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>
<https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
--------
*From: *"Joe Maimon" 
*To: *"Mike Hammett" , "Christopher Morrow" 


*Cc: *"NANOG" 
*Sent: *Thursday, January 5, 2023 2:30:40 PM
*Subject: *Re: SDN Internet Router (sir)



Mike Hammett wrote:
> I'm not concerned with which technology or buzzword gets the job done,
> only that the job is done.
>
>
>
> Looking briefly at the couple of things out there, they're evaluating
> the top X prefixes in terms of traffic reported by s-flow, where X is
> the number I define, and those get pushed into the FIB. One
> recalculates every hour, one does so more quickly. How much is
> appropriate? I'm not sure. I can't imagine it would *NEED* to be done
> all of that often, given the traffic/prefix density an eyeball network
> will have. Default routes carry the rest. Default routes could be
> handled outside of this process, such that if this process fails, you
> just get some sub-optimal routing until repaired. Maybe it doesn't
> filter properly and sends a bunch of routes. Then just have a prefix
> limit set on the box. Maybe it sends the wrong prefixes. No harm, no
> foul. If you're routing sub-optimally internally, when it does hit a
> real router with a full FIB, it gets handled appropriately.

Unless it loops.

The rest sounds nice. But flow caching got a bad rap back in the early
worm days. But thats because the situation was a little worse back then.
Cache the wrong rout

southeast asia phillipines hong king singapore region inter-network vendor expert

[Joe Maimon]

Looking to consult with someone who has in depth knowledge and 
experience with the way things work over in the corner, trying to round 
the bases on a solution and not hit it out of the ballpark.


Contact direct for less public details and arrangements, of course 
anything of legit public networking interest belongs right here.


Joe

Re: SDN Internet Router (sir)

[Joe Maimon]

Mike Hammett wrote:
I'm not concerned with which technology or buzzword gets the job done, 
only that the job is done.




Looking briefly at the couple of things out there, they're evaluating 
the top X prefixes in terms of traffic reported by s-flow, where X is 
the number I define, and those get pushed into the FIB. One 
recalculates every hour, one does so more quickly. How much is 
appropriate? I'm not sure. I can't imagine it would *NEED* to be done 
all of that often, given the traffic/prefix density an eyeball network 
will have. Default routes carry the rest. Default routes could be 
handled outside of this process, such that if this process fails, you 
just get some sub-optimal routing until repaired. Maybe it doesn't 
filter properly and sends a bunch of routes. Then just have a prefix 
limit set on the box. Maybe it sends the wrong prefixes. No harm, no 
foul. If you're routing sub-optimally internally, when it does hit a 
real router with a full FIB, it gets handled appropriately.


Unless it loops.

The rest sounds nice. But flow caching got a bad rap back in the early 
worm days. But thats because the situation was a little worse back then. 
Cache the wrong routes or run out of cache, router dies. So long as 
thats not the case automating optimization is an extremely valuable goal.





I would just be looking for solutions that influence what's in the FIB 
and let the rest of the router work as the rest of the router would.


The problem comes when the router wont work at all without the FIB 
routes, like in the olden days.




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Christopher Morrow" 
*To: *"Mike Hammett" 
*Cc: *"Tom Beecher" , "NANOG" 
*Sent: *Thursday, January 5, 2023 12:27:08 PM
*Subject: *Re: SDN Internet Router (sir)



On Thu, Jan 5, 2023 at 11:18 AM Mike Hammett > wrote:


Initially, my thought was to use community filtering to push just
IXes, customers, and defaults throughout the network, but that's
obviously still sub-optimal.

I'd be surprised if a last mile network had a ton of traffic going
to any more than a few hundred prefixes.


I think in a low-fib box at the edge of your network your choices are:
  "the easy choice, get default, follow that"

  "send some limited set of prefixes to the device, and default, so 
you MAY choose better for the initial hop away"


you certainly can do the second with communities, or route-filters 
(prefix-list) on the senders, or
you can choose what prefixes make the cut (get the community(ies)) 
based on traffic volumes or expected destination locality:

   "do not go east to go west!"

these things will introduce toil and SOME suboptimal routing in some 
instances... perhaps it's better than per flow choosing left/right 
though and the support calls related to that choice.


In your NOLA / DFW / ATL example it's totally possible that the 
networks in question do something like:
  "low fib box in tier-2 city (NOLA), dfz capable/core devices in 
tier-1 city (DFW/ATL), and send default from left/right to NOLA"


Could they send more prefixes than default? sure... do they want to 
deal with the toil that induces? (probably not says your example).


SDN isn't really an answer to this, though.. I don't think. Unless you 
envision that to lower the toil ?

Re: SDN Internet Router (sir)

[Joe Maimon]

Lots of 1M tcam fib limits in older gear...

So yeah, its the same problem, bigger numbers and still not solved in 
any sort of non-painful or expensive way.


I think Ill explore the google path and paper on it again.

Joe

Mike Hammett wrote:

Then please bless the world with the right way.

You acknowledge that not every router in a network needs to be fully 
DFZ capable, but then crap on my desire to have more than a default 
route in one.




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Tom Beecher" 
*To: *"Mike Hammett" 
*Cc: *"Mel Beckman" , "NANOG" 
*Sent: *Thursday, January 5, 2023 9:55:38 AM
*Subject: *Re: SDN Internet Router (sir)

"The right tool for the job" gets into a religious argument in
assuming that one's way to do the job is the only reasonable way
to do the job


I disagree that it's religious. I completely agree there are locations 
in networks that having full DFZ capable routers doesn't make 
technical or economic sense. But there have long been different 
products for those different use cases.


To perhaps explain my viewpoint better,(and perhaps I didn't properly 
comprehend the problem you're aiming to solve) :


If you are trying to use SDN stuff to shuffle routes on and off a box 
because you have the wrong sized routers in place, then I would argue 
you're doing it wrong.


If you are trying to use SDN stuff to (as Christopher mentioned) make 
decisions that are not strictly LPM, and the equipment you have cannot 
do that, then that's different and entirely reasonable.


If the second use case is more of what you were asking, then I 
apologize for misunderstanding.



On Thu, Jan 5, 2023 at 9:57 AM Mike Hammett > wrote:


"The right tool for the job" gets into a religious argument in
assuming that one's way to do the job is the only reasonable way
to do the job.

Large networks historically have a very poor (IMO) model of
gigantic iron in a few locations, which results in sub-optimal
routing for the rest of their network between those large POPs.
I've heard time and time again that someone buying service from a
major network in say New Orleans has a first hop of Dallas or
Atlanta. I agree that full-route capable routers need to be in the
large, central locations, but it isn't cost effective to have them
at every POP, especially if you're a last-mile provider.

I'd go into more examples of where it doesn't make sense to have
full-route routers everywhere, but I'm afraid that the Internet
would then focus on the examples instead of the core idea of
intelligently putting routes into the FIBs of low-FIB routers
throughout my network.



-
Mike Hammett
Intelligent Computing Solutions 


Midwest Internet Exchange 


The Brothers WISP 



*From: *"Tom Beecher" mailto:beec...@beecher.cc>>
*To: *"Mike Hammett" mailto:na...@ics-il.net>>
*Cc: *"Mel Beckman" mailto:m...@beckman.org>>,
"NANOG" mailto:nanog@nanog.org>>
*Sent: *Wednesday, January 4, 2023 7:36:58 AM
*Subject: *Re: SDN Internet Router (sir)

Disagree that it’s a line in the sand. It’s use the right tool for
the job.

If a device is low FIB, it’s that way for a reason. There are
plenty of ways to massage that with policy and software, depending
on capabilities , but at the end of the day, trying to sort 10
pounds of shit to store in a 5 pound bag is eventually going to
end up the same way.

On Tue, Jan 3, 2023 at 13:18 Mike Hammett mailto:na...@ics-il.net>> wrote:

There are likely more networks with 10 gigabit or less total
external capacity than there are with more.

Creating imaginary lines in the sand doesn't really 

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

John Curran wrote:



On Nov 22, 2022, at 9:09 AM, John Curran  wrote:
...
Interoperability isn’t insurmountable, but does take some investment 
of effort.  One can imagine any number of techniques (e.g.  flag day 
after which “production devices” on the Internet must support 240/4, 
or DNS resolver hacks that fail to return “A” records with 240/4 
addresses unless a flag is set that says “we’re in the 240/4 routable 
Internet” [ick], etc., etc.)  It doesn’t seem particularly hard to 
come up with some approaches to solve the interoperability problem, 
but completely ignoring it is not an answer (and makes it rather 
difficult to take your proposal seriously…)


Joe -

By the way, you shouldn’t feel particularly bad about skipping out on 
the interoperability requirement – anything involving interworking 
with the installed Internet is hard, and this is the same lesson that 
the IPv6 folks found out the hard way…   I will confess that I was a 
member of the IETF's IPng Directorate and thus inherently complicit in 
that particular fiasco –


John,

Flags days on the internet of today have proven to be of limited value.

Suppose complete interoperability is never actually solved. Why does 
240/4 utilitarian value have to be binary? I think we should be trying 
to discover these things instead of using them to handwave away any attempt.


The part I feel bad about is that I am actually un-involved in much of 
anyway with the 240/4 or other ideas, my sole input has been to attempt 
to encourage serious consideration and to rebut  naysaying.


Yes, a standards update is only the beginning of a real effort, although 
plenty has changed even without that.


Yes, there may and likely will be a large extent of interoperability and 
usability challenges for quite some time, perhaps even enough time that 
the issue becomes moot.


Yes, it may be insurmountable.

Yes, it may render 240/4 unusable and undesirable to the extent that it 
has little contributory effect on IPv4.


However it may not and discouraging serious consideration is actually a 
contributing factor preventing any such potential.


And to the extent that you and others have discussed and aired various 
points of views and insights, I think I have had some success with my 
efforts thus far.





With IPv6, the first answer to interoperability was “let’s do tunnels 
between IPng islands”; i.e. helpful for lab environments but useless 
otherwise.  We then declared that transition was a problem “to be 
solved later” but that shouldn’t get in the way of the declaration of 
IPng as the new IPv6.  Finally, after failing to solve the problem, we 
reverted to “ships in the night”; i.e. IPv4 and IPv6 running in 
parallel on the same infrastructure – it works, but defeats the entire 
idea of IPv6 as a functional substitute for IPv4 for connecting new 
customers and infrastructure to the existing IPv4-based Internet 
(Luckily, the service provider industry that was growing most rapidly 
realized that they really needed IPv6, and they really needed 
transition solutions that allowed IPv6 to interoperate for IPv4 for 
new connections, and so we eventually saw real solutions such 
as 464xlat, ds-lite, etc.)


I feel there is some value for the internet record to contain as much as 
possible real debate and consideration instead of group think, 
short-sightedness, idealouges and top down approaches which may not look 
pretty in hindsight. Such as contained in the much larger details of 
your brief recap and that you and others have expanded upon here and 
elsewhere in the past.


In other words, a loyal opposition.



Maintaining interoperability with the existing base is hard - far 
harder than just “updating the standard” -
Without a standard update, there is a bit of a chicken and egg problem 
with pursuing interoperability with any seriousness.


I think 100.64/10 was a missed opportunity to incentivize the industry 
to pursue interoperability.


but is absolutely essential if you want viable reuse of 240/4.  Of 
course, it does raise the question of whether the total effort will be 
worth the purported gain, but that really can’t be assessed until 
there's some specification of the proposed solution for 
interoperability with the existing deployed devices that don’t know 
about the 240/4 change.


Thanks,
/John

p.s.  Disclaimer(s): my views alone. Warning: may cause dizziness, 
headaches, or nausea.



Best,

Joe

Re: Alternative Re: ipv4/25s and above

[Joe Maimon]

Jay Hennigan wrote:

On 11/21/22 16:30, Joe Maimon wrote:





IMNSHO, if such a proposal were to gain traction, by the time that 
gear capable of using 240/4 as unicast were to be widely deployed, 
IPv6-capable gear would be much more widely deployed.


Considering that is already the situation, whats your point?



META: Can whoever is doing so please stop creating new time-stamped 
subject lines for the same topic? It makes things hard to follow.

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:
How trivial would the change be in a product by a company that no 
longer exists or a product line that is no longer supported? Will 
Microsoft update all previous versions of Windows? Will the myriad of 
deployed embedded systems sitting forgotten in closets be updated? And 
if you’re going to the trouble to update those systems (in most cases, 
by simply throwing them away), why not upgrade to IPv6+IPv4aaS?

Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is 
getting all the instantiations of that bit of code implemented, tested, and 
deployed across all the myriad supported and unsupported systems (both 
operational and management) that support 5 billion+ Internet users globally in 
a timeframe and for a cost that makes business sense.

Regards,
-drc



Lets agree to stop conflating the issue of products under active support 
and refresh cycles with the issue of those that are obsolete and only 
subject to attrition.


Two different problems areas entirely.

The former, yes it is trivial. An update in standards could yield rapid 
results here.


The latter takes time. An update in standards could take years to bear 
enough fruit. All the more reason it should have happened then, all the 
more reason to let it happen now.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet 
population of about 5B, this can (simplistically and wrongly) argued 
to mean 1.5-2B people are using IPv6. For a transition to a technology 
that the vast majority of people who pay the bills will neither notice 
nor care about, and for which the business case typically needs 
projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.


But back to the latest proposal to rearrange deck chairs on the IPv4 
Titanic, the fundamental and obvious flaw is the assertion of 
"commenting out one line code”. There isn’t “one line of code”. There 
are literally _billions_ of instances of “one line of code”, the vast 
majority of which need to be changed/deployed/tested with absolutely 
no business case to do so that isn’t better met with deploying 
IPv6+IPv4aaS. I believe this has been pointed out numerous times, but 
it falls on deaf ears, so the discussion gets a bit tedious.


Regards,
-drc

Re-replying. Changing the standards is not what is intended to drive 
vendor changes. Userbase requests and projected needs do that.


The standards are not responsible for the business case. However, they 
should not unreasonably impede it.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Lincoln Dale wrote:
On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon <mailto:jmai...@jmaimon.com>> wrote:


Indeed that is exactly what has been happening since the initial
proposals regarding 240/4. To the extent that it is now largely
supported or available across a wide variety of gear, much of it not
even modern in any way.


As someone who has been involved in the deployment of network gear 
into class E space (extensively, for our own internal reasons, which 
doesn't preclude public use of class E), "largely supported" != 
"universally supported".


There remains hardware devices that blackhole class E traffic, for 
which there is no fix. https://seclists.org/nanog/2021/Nov/272 is 
where I list one of them. There are many, many other devices where we 
have seen interesting behavior, some of which has been fixed, some of 
which has not.



cheers,

lincoln.




And I am sure you would agree that un-reserving a decade ago would have 
more than likely resulted in a greatly improved situation now. Along the 
lines that doing so now could still result in a greatly improved 
situation a decade hence. Should we still need it.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric Kuhnke wrote:

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will 
take any ipv4 resources they can get. They're all on waiting lists or 
have been informed no new blocks will be forthcoming.


240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each 
ISP, MNO or other waiting list entity gets a single /16, one time only.


That's 64,000 IPs per corporate entity. Not actually very large at all 
on the scale of regional mid sized operators with 300,000 last mile 
broadband subscribers, or mobile network operators, nevermind 
top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens 
of millions of customers. One /16 is a tiny drop in the bucket 
compared to the demand for IP space for indivudual-customer DHCP pool 
usage by an ISP the size of Astound or a South Korean GPON operator or 
similar.


That's 4000 entities which each get their one time /16 and then 240/4 
is entirely exhausted.


Unrealistic?  Halve it so that each network operator waiting for IP 
space reources gets one/ 17, one time only, I would still bet good 
money that there's 8000 ASes out there that right now would happily 
take their "free "single /17 , and you'd still have immediate complete 
exhaustion of 240/8.



Right now the IPv4 scarcity is a barrier of entry to new entities and a 
major speedbump in basic growth to small entities.


So my constraint has much wider, lasting and meaningful impact than 
either of your thought exercises which essentially involve how to enable 
existing entities to resume business as usual for some amount of time. I 
am sure there many other much more meaningful ways to consider using 
240/4 than that.


New IPv4 resources to go towards addressing customers in the same 
fashion as was done ten years ago, I wouldn't bother with 240/4 for that 
either.


Best,

Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

John Curran wrote:



On Nov 21, 2022, at 7:18 PM, Joe Maimon  wrote:
… Further, presentment of options in this fashion presumes that we 
have some ability to control or decide how engineering efforts across 
the entirety of the internet should be spent.


Joe -

In the snippet above you allude to a very important aspect of the 
Internet that is rather germane to this discussion – ii.e. that we 
really don’t really have any "ability to control or decide how 
engineering efforts across the entirety of the internet should be 
spent” –, but then you don’t really work through what that fact means 
for realistic outcomes of class E space re-utilization…



True



As you alluded to, we really don’t have any "ability to control or 
decide how engineering efforts across the entirety of the internet 
should be spent”, and the practical implications of this fact is that 
there will always be many devices out there in production that will 
not pass IP packets with class E addresses in them…   (just as there’s 
always going to be some devices, somewhere that don’t know about IPv6.)
To what extent will this be? And to what extent could it have been had 
this been seriously considered dozen+ years ago? We wont really know 
until we can get serious about it.


Of course, the difference is that with IPv6 we can attempt a 
connection and then fall back to IPv4, and further that devices out 
there either support and are configured for IPv6 routing, or they are 
not - networks rather quickly learn not to announce (via routing & 
DNS) IPv6 connectivity for devices without it actually being in place 
and operational or having solid IPv4 fall-back and relying fast 
fallback/happy eyeballs.


This is a very fair point. Or perhaps we can have reverse happy eyeballs 
for IPv4 fallling back to sub-optimal auto-tunneled IPv6?


With your using repurposed class E address space in the headers, your 
customers with such addresses are rather unlikely to ever know why a 
connection won’t establish – or why existing connections sometime fail 
mid-stream – as it only takes a single non-conforming device along the 
ever-changing path through any number of network operators to 
resulting in the silent drop of that packet.


I am not that sure about silent, presumably traceroute will be just as 
(un)usable.


That may (or may not) lead to you experiencing what you consider 
reasonable support costs for your customers, but as we all know, 
everyone else has customers who are the other ends of those 
connections who will call their ISP’s customer support line trying to 
figure out why they can’t get your customer (or can only get there 
intermittently) – so it appears that your proposed use of de-reserved 
and repurposed class E space has some real interesting implications 
about imputed support burdens on everyone else – if indeed the 
intended use case is includes providing connectivity to the public 
Internet.


If you’re not proposing public Internet use, and rather just within 
your own administrative domain, then feel free to do – talk to your 
vendors, get them to support it, and turn it on. As you already noted, 
we really don’t centrally decide how everyone runs their own network – 
so using it locally is fine since it doesn’t presume others will 
diagnose connection problems with your customer traffic that quite 
reasonably is categorized as invalid.


Thanks,
/John

p.s. Disclaimer:  my views alone. Note: contents may be hot - use 
caution when opening.





Right now the gossiped growing use of 240/4 in private and non 
standardized fashions jeopardizes any potential use of it just as much 
as the factors you describe.


In either event, my main point of contention is in the lack of 
willingness for serious and prudent consideration. Such as along the 
lines of what you have brought up.


So thank you.

Best,

Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric Kuhnke wrote:
In a theoretical scenario where somebody was global benevolent 
dictator of ipv4 space, even applying a policy which limited block 
size to a few /14 per ISP, it would be possible to exhaust 240/4/in 
one week/ if they handed out /14 sized pieces to every existing last 
mile LTE network operator with 5+ million customers globally. It is 
not a long term solution or even a good medium term solution.


To to the LM LTE Operator with 5+ mill. customer globally, it is not. 
Agreed. Also, I think they have already sorted themselves out 
sufficiently in a variety of ways. I am not concerned with them, at all.


Which is why I did not offer that as an example of useful constraint. 
Re-run your projections with what I actually discussed, I think you will 
have a different conclusion.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet 
population of about 5B, this can (simplistically and wrongly) argued 
to mean 1.5-2B people are using IPv6. For a transition to a technology 
that the vast majority of people who pay the bills will neither notice 
nor care about, and for which the business case typically needs 
projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.


But back to the latest proposal to rearrange deck chairs on the IPv4 
Titanic, the fundamental and obvious flaw is the assertion of 
"commenting out one line code”. There isn’t “one line of code”. There 
are literally _billions_ of instances of “one line of code”, the vast 
majority of which need to be changed/deployed/tested with absolutely 
no business case to do so that isn’t better met with deploying 
IPv6+IPv4aaS. I believe this has been pointed out numerous times, but 
it falls on deaf ears, so the discussion gets a bit tedious.


Regards,
-drc

Had the titanic stayed afloat some hours more, many more would have 
survived and been rescued when assistance eventually arrived. So that 
makes this a debate over whether this is deck chair re-arrangement or 
something more meaningful.


As I and others have pointed out, it depends on how it is used. And 
perhaps the attempt should be made regardless of knowing in advance 
which it will be.


You assertion needs some back of the envelope numbers, which once 
provided, I suspect will render your estimate grossly incorrect.


You can hardly attempt to convince anybody that 240/4 as unicast would 
not be the more trivial change made in any of these products natural 
life cycle points.


Especially as we have examples of what that type of effort might look 
like. IGTFY and here


https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/

The burdensome position is ridiculous even more so when stated with a 
straight face.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric,

I appreciate your willingness to actual consider this rationally.

Every facet of this debate has been fully aired on this forum (and 
others), numerous times.


Allow me to pick it apart again. Apologies to those who are ad nausem.

Eric Kuhnke wrote:
Option A) Spend engineering time and equipment purchases to implement 
240/4 as unicast globally. At present consumption rates and based on 
the number of entities in ARIN, RIPE, APNIC regions that could 
*immediately* take /18 to /16 sized blocks of it, please quantify 
exactly how many years this amount of "new" IP space you predict to be 
useful before once again reaching ipv4 exhaustion. End result: Problem 
not solved. Thus my analogy of building a sand castle while the tide 
is coming in.


Option B) Spend engineering time and equipment purchases (yes, very 
possibly much more time and more costly) to implement ipv6.


This is know a false dichotomy. There is no actual reason to believe 
that any effort on option A detracts from available effort of option B. 
And when you purchase your new gear, or update the software, with its 
many many lines of code changes, it is not unreasonable to expect that 
at least some might be IPv4 related and that the removal of restriction 
on 240/4 would be the more trivial of those.


Indeed that is exactly what has been happening since the initial 
proposals regarding 240/4. To the extent that it is now largely 
supported or available across a wide variety of gear, much of it not 
even modern in any way.


Further, presentment of options in this fashion presumes that we have 
some ability to control or decide how engineering efforts across the 
entirety of the internet should be spent.


Respectively, amusing and alarming.

To be clear, the only thing preventing the Internet in freely organizing 
its own efforts is the unwillingness of curmudgeons to remove the 
reserved status in this particular instance.


As no-one is requesting that you (or others of this persuasion) lend 
their personal efforts, your concern on the budgeting of efforts is out 
of place and worse, of dictatorial bend.


For the sake of argument, ignoring above, presuming our control over the 
internet engineering efforts et al.


Were I to propose to you that 240/4 be utilized only for new or existing 
organizations with less than /20 total resources or some other useful 
constraint, it would be easy to see that 240/4 would last a very long 
time and potentially have quite a significant impact.


Earlier in this thread I contrasted a reduction from 12 to 1 of ip 
address consumption per new customer, depending on the practices 
employed by the service provider. As you can see, consumption rate is 
actually quite flexible, even now, today.


So the answer to your question is it depends how freely it is handed 
out. Certainly not very long if it is business as usual prior to runout. 
Potentially much longer if not.


And in a nod to your concern over effort expenditure, but even more so, 
conscious of 240/4 being the 32bit space last big easy gasp, I would be 
a strong proponent that it NOT be.


However, even if it were, what exactly are we saving it for, if not for 
use by those who need it?


Or is it to be a hedge over some eventuality where IPv6 has failed to 
the point of abandonment? I might actually respect that position, even 
as I doubt (and fear and hope against) such an eventualities actual 
occurrence.


The more galling aspect of the 240/4 wars is that "it will take too long 
and then Ipv6 will be deployed" crowd that managed to stifle it 
initially continue to reuse that line again, in essence blase self 
perpetuation.


Its only taking that long because of this attitude.

Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric Kuhnke wrote:
Quite simply, expecting the vast amount of legacy ipv4-only equipment 
out there in the world that is 10, 15, 20 years old to magically 
become compatible with the use of 240/4 in the global routing table is 
a non viable solution. It is not a financial reality for many small to 
medium sized ISPs in lower income countries.


The amount of time and effort that would be required to implement your 
proposal is much better spent on ipv6 implementation and various forms 
of improved cgnat.


In specific focus on 240/4

Simultaneously claiming that enabling 240/4 as unicast involves 
difficulty that in comparison makes IPv6 (and then you add in CGNAT!) 
somehow more achievable is ridiculous.


Regardless of the exact scenario.

Joe

Re: ipv4/25s and above

[Joe Maimon]

Mark Tinka wrote:



On 11/17/22 19:55, Joe Maimon wrote:



You could instead use a /31.


We could, but many of our DIA customers have all manner of CPE's that 
may or may not support this. Having unique designs per customer does 
not scale well.


its almost 2023. /31 support is easily mandatory. You should make it 
mandatory.


How many customer addressing designs does that total, 2? So that would 
be 1 more than you have already? Dont buy it.


Its 2023, your folk should be able to handle addressing more advanced 
than from the 90s. And your betting the future on IPv6?






Or private/enterprise-private


Yeah, don't like that, although I understand why some operators use it.


The only issue with it is traceroute although that isnt necessarily a 
problem.


And the CPE sourced traffic should either be all internal or sourced 
from the loopback.


OTOH CoPP protection becomes a lot easier when fewer of the CP 
addressing is globally routed.





or unnumbered and route them the single /32 to use for their NAT on 
say a loopback interface.


Same as the CPE issue I described above.


Truth is the real issue isnt CPE support, its user support. Most 
users(even their "IT" folk) really cant wrap their brain around more 
than the bare basic concepts, if that much.


And you can simply say, IPv4 is limited, this is the base model 
addressing included with the service, if your inabilities are preventing 
you from using networking techniques that have been standardized and 
usable for decades, then feel free to pony up for either for your 
comfort level or for support of your inabilities.




To be honest, we'll keep using IPv4 for as long as we have it, and for 
as long as we can get it from AFRINIC. But it's not where we are 
betting the farm - that is for IPv6.


This is the crux. So long as you can obtain more, justifiable 
consumption is rewarded with additional resources, dis-incentivizing any 
addressing efficiency progress from the ancient /30 p2p + /29(or larger) 
routed block.


You may wish to lay groundwork to nibble backwards when runout occurs 
for you.


Its on Afrinic to try and preserve their pool if they wish to by doing 
things such as getting it across that progress in addressing efficiency 
is an important consideration in fulfilling requests for additional 
resources.





Your sales people are right. Since you can deliver quite usable 
service that enables them to operate just as they have before with a 
single /32, and with technical advantages to yourself, all the extra 
wasted integers should be bringing in value.


At the risk of using IP addresses to prop uo sales numbers, and then 
you run out sooner because one customer decided to pay lots of $$ for 
a /22, even when they don't need it.


If they need more, they pay more and they get more. Most of the rest of 
the world is operating or moving to operate in that fashion.


You would still require them to submit a formal request documenting 
their need. And paying more is likely to mean that its a more honest 
request.


But see the crux above. If your RiR isnt frowning on such behavior then 
its poor strategy to implement it.


Although, if you can get away with it, allocating the /30 + /29 and 
implementing it in an easy-to-clawback approach might be a good strategy.


Not the kind of potato I want to taste, because we have seen that 
proposed far too many times to know it will become a reality when the 
commissions are due.


Mark.


Thats a question of internal discipline without motivating external 
factors. Odds are those factors will arrive and I would advise 
preparedness for them.


Joe

Re: ipv4/25s and above

[Joe Maimon]

Mark Tinka wrote:


For our DIA/Enterprise business, we offer customers a /30 for p2p 
link, and a /29 as initial standard for onward assignment within their 
LAN.


You could instead use a /31. Or private/enterprise-private or unnumbered 
and route them the single /32 to use for their NAT on say a loopback 
interface. And the /29 ? I would reserve it but not assign it without a 
formal request.


Interestingly, most customers will NAT on the p2p address space, and 
barely use the onward assignment. In such cases, link migrations cause 
issues, because customers bake their internal configurations against 
those p2p IP addresses, which are pegged to specific edge routers on 
our side that can't move due to our need to minimize the iBGP 
footprint in the network. It's not a major issue in absolute terms, 
but a headache nonetheless.



See above.

We can offer customers up to a /24 maximum (i.e., we will let the /29 
expand into a /24), and no more. 


Either you have lots of fallow ground or very few customers. I dont see 
how this strategy would work elsewhere.



If they need more than a /24, time to speak to AFRINIC.

We don't charge for address space. Our Sales people want us to, but we 
don't feel it makes sense. It's not a big-enough deterrent for us to 
keep IPv4 stock. And when we do run out of IPv4 space, it will be like 
having billions of $$ on a deserted island.


Mark.

Your sales people are right. Since you can deliver quite usable service 
that enables them to operate just as they have before with a single /32, 
and with technical advantages to yourself, all the extra wasted integers 
should be bringing in value.


And since its quite nice to assign a loopback to every CPE anyways, two 
birds, one stone. Carry that in your iBGP.


Best,

Joe

Re: Scanning the Internet for Vulnerabilities

[Joe Maimon]

Matt Palmer wrote:

On Mon, Jun 20, 2022 at 02:18:30AM +, Mel Beckman wrote:

When researchers, or whoever, claim their scanning an altruistic service,
I ask them if they would mind someone coming to their home and trying to
open all the doors and windows every night.

If there were a few hundred people with nefarious intent trying to open your
doors and windows every night, someone doing the same thing with altruistic
intent might not be such a bad thing.

- Matt



Yall seem to be saying the same thing.

So long as it blends into the general IPv4 background radiation, all good.

Joe

Re: V6 still not supported

[Joe Maimon]

Jared Brown wrote:

JORDI PALET MARTINEZ via NANOG wrote:

If I'm a gamer, and one of my possible ISPs is using CGN, and from time to time 
stops working, and another ISP is providing me a public and/or static IPv4 
address, always working, and there is not too much price difference, what I 
will do?

Changing providers only works in a competitive market, but even there a little 
bit of market segmentation isn't necessarily a bad thing.

The main thing is that ISPs should not be so accommodating to these 
malfeasants, who via their practices make a bad situation worse. Sony et al. 
are externalizing costs and that shouldn't be accepted.


- Jared


Like most things of this nature, there is a tipping point. Where exactly 
it is, either individually or communally, and whether it is ever reached 
is typically only viewable via hindsight.


Service providers tend to be on  the "make it work" side of things, 
whether due to historical reasons or their users expectations or the 
nature of any technology centered business. Usually its more efficient 
and even cost effective to just fix it if you can. And yes, that is a 
self-reinforcing cycle.


But everything has its limits.

Increasing NAT, IPv4 re-use, IPv6 is likely to push the point away from 
Network-Address-as-Customer-Identity from being the service provider's 
responsibility.


Joe

Re: V6 still not supported

[Joe Maimon]

JORDI PALET MARTINEZ via NANOG wrote:

No, isn't only a Sony problem, becomes a problem for every ISP that has customers using 
Sony PSN and have CGN (NAT444), their IP blocks are black-listed when they are detected 
as used CGN. This blocking is "forever" (I'm not aware of anyone that has been 
able to convince PSN to unblock them). Then the ISP will rotate the addresses that are in 
the CGN (which means some work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have any "not 
black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of sense 
to analyze if you have a relevant number of customers using PSN and make your 
numbers about if it makes sense or not to buy CGN vs transfer IPv4 addresses vs 
the real long term solution, which is IPv6 even if you need to invest in 
replacing the customer CPEs.


Regards,
Jordi
@jordipalet
  


I would expect the trend to become that ISP's refuse to accommodate 3rd 
party vendors shenanigans to the point where it hampers their operations 
or to the point where it cost them more to do so.


Likely, they would sooner tell the customer that their vendor (whom they 
pay money) is blocking the ISP and that there must a) deal with their 
vendor and/or b) pay/use a dedicated static IP


Because as you point out, its impossible to support this trend after a 
certain point, and really, why should you?


With enough of that attitude, the trend reverses and vendors will have 
to start using other mechanisms, perhaps even ones where cooperation 
with the SP is a possibility.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Owen DeLong wrote:


Yep… He’s absolutely right… We need to find a way to get the networks that 
aren’t deploying IPv6 to
get off the dime and stop holding the rest of the world hostage in the IPv4 
backwater.

Owen




You keep championing that approach, essentially unchanged for the past 
20 years with an impressive record of partial success and much failure 
and I will fully support and applaud your efforts in doing so. I will 
also hope that it doesnt take another 20 to finally succeed, because as 
you point out, you require an extremely high level of participation 
before its Mission Accomplished.


And its not unreasonable to expect that until that approach succeeds, 
that others' efforts to work on the ongoing problem receive the same 
support and encouragement.


IPv6 uber-alles adherents had more than enough time to claim it was 
going to solve the problem without any need for anything else and to 
"request" (quite strongly and wrongly so in my opinion) that everyone 
rally their efforts around that.


Now its time for those adherents to reciprocate.

And here is a little bit of constructive criticism to the Evangelical 
approach. Essentially, you need to pivot from how their efforts can save 
the world into how their efforts can benefit themselves.


You want more people to use IPv6? Make it worth their while. Lower the 
barriers the cost the risks and increase the bennies.


The early adopters, the activists, those who define themselves by their 
altruism you already got.


Dont be surprised when so many balk at doing things they have no 
particular defined need or interest in doing when the primary 
beneficiaries arent themselves, but the primary cost carriers are.


Or we can just wait and see how the natural course of events eventually 
plays out. Still looks likely that IPv6 will eventually take over the 
internet, but it sure would be nice if IPv4 did not become completely 
unusable before that manages to occur.


Joe

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Matthew Petach wrote:




Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.


IOW if your peer or customer has prepended 5 times or more, dont 
LOCAL_PREF or maybe even de-LOCAL_PREF it





For the most part--if you think LOCAL_PREF is the right knob to use 
for moving
traffic, it probably means you need to go back and rethink your 
traffic engineering

approach.   ^_^;

Matt


I think more and perhaps different knobs were and still are needed.

Here is an idea, as part of the all extra processing updates have to go 
through nowadays, how about a long call back to each AS in the path 
using some sort of standardized service, perhaps published via DNS, sort 
of an automated looking glass results compared to update-out. And then 
the receiver, however many AS's away starts to get a much clearer 
picture of the intent all the through and maybe perhaps some much better 
intelligent automated properly reactive internet wide traffic 
engineering standards will emerge.


Until then I think a slew of standardized communities that elicit near 
universal and predictable standard reactions is probably the best bet. 
The problem is that shifting too much control to the advertiser makes it 
a non-starter from the point of view of the receiver, and then you can 
forget about deployment.


Would be nice to be able to publish your community scheme as simply 
conforming with RFCX and the to configure peers with process-rfcX 
statement and be mostly done.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Matthew Petach wrote:



In short, at the moment, you *can't* deploy IPv6 without also having IPv4
somewhere in your network.  IPv6 hasn't solved the problem of IPv4
address shortage, because you can't functionally deploy IPv6 without
also having at least some IPv4 addresses to act as endpoints.

For the people who already have IPv4 addresses to say "hey, that's
not a problem for us" to everyone who can't get IPv4 addresses is
exactly the problem warned against in section 6 of 
https://datatracker.ietf.org/doc/html/rfc7282:


"
6 . One 
hundred people for and five people against might not be rough

consensus

Section 3   
discussed the idea of consensus being achieved when
objections had been addressed (that is, properly considered, and
accommodated if necessary).  Because of this, using rough consensus
avoids a major pitfall of a straight vote: If there is a minority of
folks who have a valid technical objection, that objection must be
dealt with before consensus can be declared. "
The point at which we have parity between IPv4 and IPv6 connectivity 
is the point
at which we can start to talk about sunsetting IPv4 and declaring it 
historic, and
no longer concern ourselves with address exhaustion.  Until then, so 
long as
being able to obtain IPv4 addresses is a mandatory step in being 
functional on
the internet, it is unreasonable to say that the address exhaustion 
problem is

"solved."

Matt



I dont know how many ways and times this needs to be said, but you said 
it quite well.


Joe

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Joe Provo wrote:

On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:

:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?


That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
where a decent low number (5) is propsed.

Chers,

Joe
  


So is there a good way to signal along with a BGP route that the 
originator of the route wants you to know that this route has very high 
suckage factor and even if you normally prefer your peers customers 
whatever, you should perhaps think twice about that for this route, 
cause its really last resort.


Because as-path is an overloaded multimeaning traffic influencing hammer 
that has imprecise and frequently undesirable results. And if that were 
not the case, than discussions of its relative size compared to internet 
diameter would be much more relevant.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Tom Beecher wrote:


If the IETF has really been unable to achieve consensus on properly
supporting the currently still dominant internet protocol, that is
seriously problematic and a huge process failure.


That is not an accurate statement.

The IETF has achieved consensus on this topic. It's explained here by 
Brian Carpenter.


https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/


As I have explained with my newly introduced consensus standards, there 
is no such consensus.


To reiterate my consensus standards, consensus is only to be considered 
as amongst stakeholders and IPv6 specific related stakes are not 
relevant to IPv4. If you consider the reverse to be true as well, I 
think my version of consensus would achieve a much wider and diverse 
consensus than the the stated IETF's consensus.


Once a consensus has been proven invalid its beyond obnoxious to cling 
to it as though it maintains its own reality field.




He expressly states with many +1s that if something IPv4 related needs 
to get worked on , it will be worked on,


IPv4 still needs address exhaustion solutions.

but the consensus solution to V4 address exhaustion was IPng that 
became IPv6, so that is considered a solved problem.


IPv6 is not a solution. Its a replacement that does not have the same 
problem. Which could be a solution to the problem, but only if the 
replacement happens on schedule. However, so long as the replacement 
hasnt happened, we still are dealing with the problem.


The IETF made a stupendously bad bet that IPv6 would happen in time. 
That is the kind of bet that you better be right about. They were a 
decade+ wrong. That they have the audacity and temerity to continue 
doubling down on that would be funny if it wasnt so outrageous, wrong 
and harmful.


Let us re-examine the premise. When did it become acceptable to quash 
work on one protocol because of the existence of another one that is 
preferred by the quashers?


Or in other words, the way you are framing things makes it seem as if 
the IETF has with intent and malice chosen to extend or at the very 
least ignore exhaustion issues for actual internet users so as to rig 
the system for their preferred outcome.




Some folks don't LIKE the solution, as is their right to do.


I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 
resolution, not addressing policy, not the chaos of choice of inadequate 
interoperability approaches, not the denial of features desired by 
users, not the pmtud, not the fragmentation, and many other warts. I 
dont even like the notation schemes. They require multiple vision passes.


I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is that it did not work. Address exhaustion 
has not been alleviated. For many years now and who knows how much longer.


But the problem of V4 address exhaustion is NOT the same thing as "I 
don't like the solution that they chose."


The problem of V4 address exhaustion is NOT the same thing as turn on 
IPv6 and wait for the rest of the world to do the same.


When considered in that manner the IETF's bet looks even worse.

What I dont like is that they were wrong. What I dislike even more is 
that they refuse to admit it and learn from their mistakes.


Joe

On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon <mailto:jmai...@jmaimon.com>> wrote:




Owen DeLong via NANOG wrote:

>
> Well… It’s a consensus process. If your idea isn’t getting
consensus,
> then perhaps it’s simply that the group you are seeking
consensus from
> doesn’t like your idea.



Consensus processes are vulnerable to tyranny of a well positioned minority.

Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Owen DeLong via NANOG wrote:
What you’re really complaining about is that it’s been virtually 
impossible to gain consensus to move anything IPv4 related forward in 
the IETF since at least 2015.


Well… It’s a consensus process. If your idea isn’t getting consensus, 
then perhaps it’s simply that the group you are seeking consensus from 
doesn’t like your idea.


If the IETF has really been unable to achieve consensus on properly 
supporting the currently still dominant internet protocol, that is 
seriously problematic and a huge process failure.


When vendors do that sort of thing people get up in arms. When open 
source projects do that sort of thing, they get forked. When community 
grassroots governance bodies do that sort of thing, I dont want to find out.


Responsible stewardship of internet community standardization would be 
excluding IPv6 strategic concerns from considerations of consensus on 
IPv4 issues.


In other words, if the only issues you can bring to bear on any matter 
pertaining solely to IPv4 is all about IPv6, your not relevant to the 
process and should be struck from the record.


I would even go so far as to say that you are actually poisoning the 
process.




Your inability to convince the members of the various working groups 
that your idea has merit isn’t necessarily a defect in the IETF 
process… It might simply be a lack of merit in your ideas.


Owen


This part is very good advice, perhaps restated as a lack of merit in 
the idea when combined with much wider and diverse perspectives.


On the other hand, with no record and history of ideology driven 
agendas, the IETF process would be a whole lot more trustworthy.


Joe

Re: A straightforward transition plan (was: Re: V6 still not supported)

[Joe Maimon]

Philip Homburg wrote:
It should be clear that an IPv4-only host only speaks IPv4. This means 
that communication with an IPv4-only host has to be IPv4.


This did not have to be true, had there been an extension/option 
standardized at the same time as IPv6 for IPv4 packets to be gateway'd 
into IPv6 transparently and efficiently (thru any dual stacked 
host/router), than at this point we would have likely been looking at 4 
classes of nodes


- IPv4 only, legacy, requires translation to communicate directly with ipv6

- IPv4 only, extended, just needs a gateway to communicate directly with 
IPv6


- Dual Stack

- IPv6 only

Such additional functionality, could have been organically updated into 
most major OS's without any required network topology changes.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joe Maimon]

james.cut...@consultant.com wrote:

On Mar 26, 2022, at 8:30 PM, Masataka Ohta  
wrote:

Owen DeLong via NANOG wrote:


It still looks like NAT to me.

Almost all the people, perhaps other than you, accept NAT
as is to keep IPv4 Internet or as part of transition
plan from IPv4 to IPv6.


NAT is a disgusting hack and destroys the universal peer to peer
nature of the internet in favor of a consumer/provider model.

As I repeatedly pointed out, end to end NAT is clean preserving
the universal peer to peer nature of the Internet.

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

The basic idea is to let NAT boxes perform address translations
only without adjusting check sums or translating ports and
to let end systems perform reverse address translations,
which restores correct check sums, and port number
restrictions.

Masataka Ohta

I have yet to find an economical way to manage a business merger involving two 
large rfc1918 networks where end to end peering is required and which partially 
or fully overlap. Ignoring short-sighted financial management views, the best 
long term solution is globally unique IPv6 addressing wherever possible. Local 
islands of IPv4 gatewayed or NATted with local management continue to be 
possible.


In other words, once its merger time, IPv6 fixes nothing.

Can one really incentivize an enterprise to standardize on IPv6 on the 
basis of it will make a future merger much more economical? And this is 
well before any such prospect usually exists.


Is there any activity that enterprises choose to engage in on that basis?

Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joe Maimon]

John Gilmore wrote:

Tom Beecher  wrote:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that
it's 'not that big a deal.', so I don't think he adequately grasps the
scale of that challenge.

>From multiple years of patching and testing, the IPv4 Unicast Extensions
Project knows that 240/4 ALREADY WORKS in a large fraction of the
Internet.


And this is without the removal of reserved status.

There is no real reason to think it would not have been practically 
universal if that had happened a decade ago.




Today Google is documenting to its cloud customers that they should use
240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
the citation.)  We have received inquiries from two other huge Internet
companies, which are investigating or already using 240/4 as private
IPv4 address space.


240/4 becoming a de-facto super rc1918 in its totality is actually a net-loss. Has 240/4 
been unreserved for potential global internet purposes a decade ago, much more 
constructive purposes could have been standardized as well. So all the delay is not a 
"no harm no foul" situation.


In short, we are actually making it work, and writing a spec for what
already works.  Our detractors are arguing: not that it doesn't work,
but that we should instead seek to accomplish somebody else's goals.

John


At this point, its more like you have publicly accepted all the blame 
for the current incomplete state of IPv6 by acknowledging that you chose 
to take on the daunting task of 240/4 and refused to direct yours and 
everyone you knew efforts into IPv6, which was missing only that.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joe Maimon]

Paul Rolland wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen"  wrote:


touching the hardware, by implementing the EzIP technique (*/disabling/*
the program code that has been */disabling/* the use of the 240/4
netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect


Paul


While we cant really know, the odds are strong that there are only a few 
lines in any particular product that need to be removed or reworked. Its 
a safe expectation that its a trivial change, as far as changes go.


The bigger hurdle is deployment. All 240/4 discussions have usually 
opined that:


There is every expectation that if 240/4 reserved distinction is removed 
that any particular product still being updated would likely have such a 
change incorporated as part of its normal update process.


And that all non supported products that would not get such a change 
would over time fade away to become a very distinct minority, as they do 
normally.


There is strong evidence that this is an accurate prediction, as even 
without the removal of reserved status, mere public discussion and 
debate over the matter has been sufficient that today a large amount of 
that change has actually occurred, organically so to speak.


If IPv6 would have had such a migration strategy it would have been over 
already.


Joe

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:



On Mar 24, 2022, at 21:18 , James R Cutler 
mailto:james.cut...@consultant.com>> wrote:


On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG > wrote:


I think that we’re still OK on allocation policies. What I’d like to 
see is an end to the IPv4-think in large ISPs, such as Comcast’s 
continued micro allocations to their customers.


What exactly is your definition of “micro allocations”? Is a 
prefix/56 a “micro allocation”? In over nine years of being an active 
forum participant and customer of Comcast, I can not recall the usage 
of the term.


They’re issuing /60s (maximum) to residential customers.

And yes, a /56 is a micro allocation. /48 is the intended norm for 
IPv6 site assignments and is a perfectly reasonable prefix size for v6 
delegation to a site.


Owen

/48 as universal site assignments is a ridiculousness that should never 
be a norm, and unsurprisingly in the real world it isnt.


Now if your goal is to pick a number which will never change and is 
large enough to work for any assignment anywhere for any network 
topology ever, well you found it.


However, thats a solution in search of a problem. Which causes its own 
problems.


A /48 gives 16 bits of /64 subnetting for the site.

Which is the same number of bits initial default ISP /32 has. Ridiculous 
in either direction.


If you apply the same logic to ISP's that you have to end user site 
assignments (which is descended from the same logic as /64 subnets), you 
need to move left. Again. Goodbye limitless ipv6.


Or you can move right on the /64 nonsense. SLAAC does not|should not 
need /64. Or, SLAAC isnt needed at all. Chaining DHCP to SLAAC is more 
nonsense.


Joe

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:



You may be right about not being worth it. More importantly, you may be wrong. 
IPv6 is replete with not only a plethora of wrong predictions, but the same 
ones over and over again. To be clear, the only effort asked from the unwilling 
is to support cutting the red tape frustrating the willing. A hearty round of 
knock yourself out from the right folk in the right place and time and we dont 
have to debate this particular point ever again.

Certainly, if we continue to waste effort that is better spent deploying IPv6 
on bandaids and hacks to make v4 last just a little longer, we will continue to 
fail and further delay IPv6 reaching a level of deployment that allows us to 
start turning down IPv4 and beginning to recognize the cost savings that come 
from moving forward.


How are we to ever find out who is right if that never happens? That alone is 
enough reason for me.

The problem is that we’re not talking about parallel experiments. We’re talking 
about an optional activity which will inherently pull resources away from a 
necessary activity, thus delaying the necessary activity and becoming somewhat 
of a self-fulfilling prophecy. Hence I oppose this wasteful experiment in favor 
of doing what we all know eventually needs to be done.



I dont know what it will take to paint this nonsensical argument as any 
more patently ridiculous than has already been done. It bears no 
relationship to actual reality.


However, hypothetically, lets say thats exactly how it works.

Too Bad. You had your chance to deploy IPv6 before the pain and now you 
must tend to both protocols.


Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:


On 3/24/22 3:13 PM, Owen DeLong wrote:



On Mar 24, 2022, at 14:46 , Michael Thomas  wrote:


On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote:
Home users aren’t the long tail here. Enterprise is the long tail 
here. Android phones are,

indeed, part of the enterprise problem, but not the biggest part.

If this were a purely technical problem, we’d have been done more 
than a decade ago. The
problem is a lack of corporate “round tuits” which for each 
enterprise are in limited supply and

usually go to things that either reduce costs or increase revenue.

So long as they have public facing v6 servers is there really a 
problem? Sure you're not going to get to 100% deployment, but 
nothing is going to do that in any of our lifetimes. The object 
should be to not have to deploy tortured hacks like CGNAT. That is 
what success is IMO, and we don't from a technical standpoint.


Mike

Yes… We need them to have v6 deployed to their clients so that 
content providers can start turning off v4 where it’s costing them 
money to support it.


Well content providers could pretty easily force the issue if they 
wanted.


MIke



Content providers are rumored to dig into the single digit percentages 
of failing connections to ensure their audiences is as large as possible.


And enterprises would likely happily settle on edge solutions for v6 
only content so long as they are workable.


Joe

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:



On Mar 24, 2022, at 03:36 , Joe Maimon  wrote:



In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible.

I think this isn’t so much preempting the vacuum as trying to pretend we can 
survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it 
were reclassified effectively as GUA, it doesn’t buy all that much life for 
IPv4.


I think it should be reclassified from never going to be used into some 
part of the internet might actually do something with it. Its important 
that happens now, better late then never. Whether its GUA or not or a 
mix of whatever, whether it buys months or years will depend greatly on 
how its actually used if it is ever used.


You may be right about not being worth it. More importantly, you may be 
wrong. IPv6 is replete with not only a plethora of wrong predictions, 
but the same ones over and over again. To be clear, the only effort 
asked from the unwilling is to support cutting the red tape frustrating 
the willing. A hearty round of knock yourself out from the right folk in 
the right place and time and we dont have to debate this particular 
point ever again.


How are we to ever find out who is right if that never happens? That 
alone is enough reason for me.






Personally, that means that although I have long disliked proposals that keep 
moving to the left of the 128bit space, were I to believe it likely to increase 
deployment and momentum I would champion it in my own limited fashion much as I 
do 240/4.

Not sure what you mean by “moving to the left of the 128 bit space”.


That Ipv6 address allocation schemes and proposals tended to enlarge 
over time, using up more bits heading from right to left.




We will obviously agree to disagree about 240/4 as we long have.

Owen


To the next time then.

Joe

Re: V6 still not supported

[Joe Maimon]

Mark Delany wrote:

On 23Mar22, Owen DeLong via NANOG allegedly wrote:


I would not say that IPv6 has been and continues to be a failure

Even if one might ask that question, what are the realistic alternatives?

1. Drop ipv6 and replace it with ipv4++ or ipv6-lite or whatever other protocol 
that
magically creates a better and quicker transition?

2. Drop ipv6 and extend above the network layer for the forseeable future? By 
extend I
mean things which only introduce ipv4-compatible changes: NATs, TURN, CDN 
at the edge,
application overlays and other higher layer solutions.

3. Live with ipv6 and continue to engineer simpler, better, easier and 
no-brainer
deployments?

I'll admit it risks being a "sunk cost falacy" argument to perpetuate ipv6, but 
are the
alternatives so clear that we're really ready to drop ipv6


I most assuredly hope not. However this is not actually within any 
specific bodies absolute control. The overblown representation of the 
top down nature of internet design is a significant fallacy.


If a vacuum persists and what fills that void is detrimental to IPv6 
global deployment, it would be a significant setback. But the internet 
wont care.


What you can do is try and preempt the vacuum.

In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible.

By all means, continue to evangelize users and pressure vendors. But 
thats not enough. Make IPv6 more attractive, more utilitarian, more 
useful. Address and remove barriers and hurdles. And that means doing 
and accepting things that many have significant distaste for.


Personally, that means that although I have long disliked proposals that 
keep moving to the left of the 128bit space, were I to believe it likely 
to increase deployment and momentum I would champion it in my own 
limited fashion much as I do 240/4.





so much as IPv6 has not yet achieved its goal.

As someone previously mentioned, "legacy" support can have an extremely long 
tail which
might superficially make "achieving a goal" look like a failure.


While true, thats not my concern. My concern is that continued 
dependence on functioning IPv4 by and large for the internet population 
has resulted in additional costs and constrains on the addresses 
required to utilize it. So long as that persists, so does the failure 
status of IPv6 towards the goal of alleviating it.


And thats the goal that actually matters to the internet population at 
large.


Forget ss7 and SIP, what about 100LL vs unleaded petrol or 1/2" bolts vs 13mm 
bolts? Both
must be 50 years in the making with many more years to come. The glacial grind 
of
displacing legacy tech is hardly unique to network protocols.

In the grand scheme of things, the goal of replacing ipv4 with ipv6 has really 
only had a
relatively short life-time compared to many other tech transitions. Perhaps 
it's time to
adopt the patience of the physical world?


Mark.




I agree. But that means behavioral modification towards a
much longer term outlook than has been in widespread evidence thus far.

Joe

Re: V6 still not supported

[Joe Maimon]

Mark Delany wrote:

On 24Mar22, Greg Skinner via NANOG allegedly wrote:


straightforward transition plan
in-hand working transition strategy
nor a straightforward transition

Any such "transition plan" whether "working" or "straightforward" is logically
impossible. Why anyone thinks such a mythical plan might yet be formulated some 
20+ years
after deploying any of ipv6, ipv4++ or ipv6-lite is absurd.


You are correct that there is no way to represent 128 bits inside of a 
32 bit field without modifications. Especially past the point of early 
adoption when there was still a 1:1 ratio of IPv4 and IPv6 actual 
addressing possible.


However, even transition mechanism that would have relied upon IPv4 
modifications would have had a better chance of being rolled out as part 
of normal update cycle at this point than mass deployment of IPv6 which 
requires a bit more than normal update cycle.





The logic goes: we support legacy "do nothing" ipv4 deployments forever. We 
also expect
those same deployments to invest significant effort, cost and risk to move off 
their
perfectly functioning network for no self-serving benefit.


No surprise that hasnt happened very quickly. You have that backwards. 
Legacy ipv4 do-nothing deployments have absolutely no need of support. 
IPv6 needs their support so that non-legacy deployments of IPv4 wont 
need continued support.




There be unicorns and denial of human nature.


Mark.




Human nature is that deployment of a technology when the larger benefit 
is unrealized in the short term by the party expected to expend the 
costs of the deployment is unlikely to have significant widespread 
initial momentum and is quite likely to have lingering inability to 
complete a global deployment.


As that is the case, efforts on both protocols are warranted.

Joe

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:


The goal of IPv6, IMHO, is to become the next lingua franca of the internet, 
eventually rendering IPv4 unnecessary except in small pockets of legacy support.

Hey Owen,

Indeed, having otherwise fallen short of the mark that is what remains.


I agree that has not yet been achieved.


Its  encouraging that progress and momentum continues, but there is no 
way to be 100% confident that IPv6 has unlimited time to obtain dominance.


It was an objective to try and reach that point prior to IPv4 address shortages 
caused real problems, but we pretty well missed that target when NAT started 
catching on.


There were still plenty of opportunities to save the day that IPv6 
global deployment missed.


I would not say that IPv6 has ben and continues to be a failure so much as IPv6 
has not yet achieved its goal. Yes, it failed the (optimistic) objective of 
achieving it’s goal prior to IPv4 shortages causing real problems, but that 
happened pretty quickly and pretty early in the lifespan of IPv6 thus far (I 
view the popularization of NAT as being the first marker of real problems in 
IPv4 due to address shortage).


There were more mile markers than NAT on the address shortage problem 
route and IPv6 failed most of those as well. Some of those happened 
early, some not so much and there are probably more to come.


While shortage might have been the main driver of development of NAT, 
provider independence and abstraction was the clear motivation for end 
users to adopt it.




  Getting IPv6 to near ubiquitous deployment in that short time would have been 
an impressive accomplishment if it had happened.

Owen


,

20 years ago it was not considered optimistic to expect that there would 
no longer be threads of this nature, it was essentially treated as 
heretical to imagine there might be. And there were concrete 
consequences to that mode of group think.


Even a naysayer as myself, back in 2004 really only expected another 
decade or so of transition to clear dominance.


I will note that a decade to make 240/4 usable was cited as a major 
opposition reason to it. And other ideas.


Joe

Re: V6 still not supported

[Joe Maimon]

John Curran wrote:
About two decades later, at the time of the IPv4 central free pool 
runout (Feb 2011), we had neither “clearly improved functionality” nor 
a straightforward transition plan for "transparent access between the 
IPv4 and IPng communities” – I do hope I was wrong about the outlook 
for IPng under such conditions, but we’ll need to wait for another few 
decades to know for sure one way or the other.


Best wishes,
/John



Well just because you were right then does not mean you cant be wrong 
now. Let us both hope so.


Best,

Joe

Re: V6 still not supported

[Joe Maimon]

james.cut...@consultant.com wrote:
On 23 Mar 2022, at 1:34 AM, Joe Maimon <mailto:jmai...@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. 


You must not be looking hard enough. There have been many accounts of 
how Dual Stack as a transition was steamrollered on over naysayers 
objections and predictions.


My personal correspondence on NANOG doesnt date that far back but here 
are some of the earliest on-topic examples readily available.


https://archive.nanog.org/mailinglist/mailarchives/old_archive/2004-10/msg00298.html

https://archive.nanog.org/mailinglist/mailarchives/old_archive/2004-11/msg00112.html

https://archive.nanog.org/mailinglist/mailarchives/old_archive/2005-07/msg00023.html



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.


Depends on the definition of the goal. And your definition appears to be 
some measure of forward momentum. Certainly plenty exists. And that is 
good news in and of itself. But the internet needed more and long ago 
already. And that is the bad news.




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.


When you build something and they dont come on schedule, you can blame 
them or you can consider what you could or should have done differently, 
especially as it may advise for the future. If you choose the former, 
there and then is the evidence of the type of thinking that tends to 
produce these outcomes.




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.



Yeah, I think blaming bufferbloat is another example of designers 
passing the buck and engaging. If the reality consists of large buffers, 
start engineering with them in mind.


Or better yet, fast large ram cheaply and widely available should be 
considered a welcome and valuable resource. Try to make proper use of it.


As for the rest, false dichotomy again. Do both. Or applaud both. Or 
support both. Or at least, dont oppose either.


Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:


On 3/23/22 11:53 AM, Joe Maimon wrote:



Michael Thomas wrote:
IETF can't force people to adopt things, film at 11. They certainly 
can't control people's saltiness from something that happened 30 years 
ago. IPv6 is manifestly deployable for operators that want to. If 
others don't want to deploy it in the face of the predictable address 
crunch, that's on the operators and not anybody else. Vendors will 
build patches and hacks and other abominations if somebody is willing 
to pay for it. If you like CGN, by all means deploy it from a vendor 
standpoint. If you don't like CGN either then, well, you're sort of 
screwed. Going back and relitigating ipng is not ever going to happen.


Mike




Which is why the IETF should not engineer things under the assumption 
that they can.


Which is why the IETF should not be citing IPv6 as cause to deny efforts 
on IPv4.


Because as you say, at this point, even if you dont like CGN, the 
internet is sort of screwed.


And the reasons that IPv6 is not deployed everywhere it could or even 
should be are myriad. Perhaps unpredictable. That reasons would abound 
was predictable.


Network A deploying IPv6 does not do nearly as much to help A as it does 
when B-Z do, which is the core problem of IPv6 transition. You can 
understand then that even in the face of shortage IPv6 is only one of 
the options on the table at network A for short term alleviation. And 
usually not even the one with most bang per buck. Those who can choose 
D) all of the above, the rest prioritize based on resources and various 
locally defined assessments and analysis. Also unpredictable, but 
predictable that they would exist.


Bygones are bygones, but not if the behavior persists.

Yes, I understand referring to the IETF as an individual entity is 
grossly oversimplifying.


Joe

Re: V6 still not supported

[Joe Maimon]

John Curran wrote:


On 23 Mar 2022, at 1:34 AM, Joe Maimon <mailto:jmai...@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.


Joe -

It all depends on your measure of success; i.e. the victory
conditions that one wishes to set.



Hi John,

That is the crux of my argument.


 If the victory conditions are “has displaced the previous IP4
protocol”, then we’re certainly not there (and may never achieve
at such an outcome for many decades to come…)

If the victory conditions are “provide an updated IP protocol that
the larger providers can use as an alternative for address their
continued growth requirements”, then it is indeed a success - as
proof one just has to look at major broadband and mobile network
deployments that use IPv6 to enable their continued growth…  (and
IPv4 on many of those networks is just network application shim to
a gateway service that’s present for obsolete software to use.)



I define the victory as avoiding the occurrence of the inevitable 
constraints that v4 shortage was going to have. I also include the 
negative effects and avoidable investment of time, effort and capex into 
CGN and the like in to what IPv6 was intended to avoid.


Perhaps a better statement of the failure is that the IPv6 deployment 
failed in its original objective to alleviate IPv4 address shortage 
before the effects became widespread and significant. I think that is a 
least common denominator we can mostly all agree on.



The fact that the majority of the network operators don’t use IPv6
is irrelevant under such victory conditions, so long as those who
needed to have it due to their growth requirements have had it as
a viable option.  Many of the largest networks out there (service
providers, cloud, social media) are running IPv6 as their primary
infrastructure because they prefer the long-term economics of that
architecture given their needs – so by that measure one can
consider definitely a success.



These are also the network operators who can use all the v4 not spent on 
infrastructure as well as the gobs of couch cushion v4 they have 
relative to their overall size to meet customer specific demand. So v6 
has mostly helped the large carriers, in increasing their internal 
supply of v4, in optimizing their use of CGN, in cohesive infrastructure 
addressing. Is that an overall internet success?


The end users and other network players not in similar circumstances 
have not benefited nearly as much. And they wont until IPv4 becomes 
optional. Now for many, Global IPv4 is indeed optional, we call them 
eyeballs and the loser here is the original concept of the end2end internet.




That doesn’t meant everyone has to run IPv6 – if your network
isn’t growing that much and you’ve got enough IPv4 addresses for
your needs then by all means continue to use just IPv4..



And then take the blame for why IPv6 deployment is not happening fast 
enough...



However, recognize that IPv6 deployment continues to grow, and
that means there could easily be a “tipping point” sometime in
your future – i.e. a point in time when your organization needs to
support IPv6 because of internal or external requirements  – and
it’s probably best for networking engineers to be up-to-speed &
comfortable with IPv6 by that point (or ready to do something else
for a living)

Thanks!
/John


Agreed and as you have pointed out, this is our continued hope. That 
doesnt mean victory is assured and inevitable, the longer this drags out.


Always a pleasure,

Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:




SIP won't displace all legacy PSTN any time soon. So it's a failure by 
your definition. And by your definition IPv6 was a failure before it 
was even born because the internet became popular -- something I'll 
add that nobody knew for certain when it was being designed. There's a 
lot of sour grapes about stuff that happened 30 years ago.


Mike


The definition of failure flows from the definition of the objective, 
the goal, the desired outcome.


What is your understanding of those for IPv6?

My understanding of the goal of IPv6 was to replace IPv4 globally before 
address shortage caused real problems. If we agree on that, we must also 
agree that it has failed to do so, ergo, IPv6 as a global solution to 
IPv4 address shortage has been and thus far continues to be a failure. 
Now it will almost certainly eventually succeed, but that doesnt change 
that for all this time, it failed and there were real consequences that 
or may not carry on with us all for quite some time, and that there were 
real costs involved to real people.


Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:


On 3/22/22 10:34 PM, Joe Maimon wrote:




There is this other side: I'm dualstack, and I simply dont notice.


Being in transition state indefinitely is not success.

The other side is when you are v6 only and you dont notice. We arent 
there yet. Thats the failure.


This is a terrible way to look at things. SIP has been gradually been 
taking over the PSTN signaling for 20 years. It has not rooted out 
every SS7 installation on the planet and probably won't until I'm long 
dead. Is that a failure? It's certainly a "transition state". After 
not paying attention for probably a decade and seeing how much it's 
penetrated I'd call that a resounding success. The same is true of 
IPv6 with all of the mobile uptake. Legacy is hard. It always has been 
hard. Calling something a failure because it doesn't instantly defeat 
legacy a terrible take. It was always going to be difficult to add 
address space to IP regardless of how it was done. All of the bagging 
on IPv6 and imagining a better ipng ignores that basic fact.


Mike


SIP wasnt formulated to save telephony. In fact sip has nearly 100% 
adoption for ip based telephony. It did displace legacy and proprietary 
protocols.


There is no comparison. IPv6 transition was intended to complete before 
run out using Dual Stack. Fail.



Joe

Re: V6 still not supported

[Joe Maimon]

George Michaelson wrote:

Thats partly why I
find a huge personal disconnect with "failure" -It hasn't failed the
way DECnet failed. Far from it.


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 will give you that address shortage and resulting constraints is 
actually a spectrum, one we have not finished traveling on. I suppose we 
can date it from the time a class-c stopped being included as part of 
your leased line all the way to the hasnt happened yet point where you 
cant get v4 for any affordable amount. So yes, IPv6 will probably save 
the internet at some point before the end of that spectrum is reached, 
but the damage has already been done, and lots of it.


Now if the goal was to produce a protocol that would work eventually as 
good as IPv4 and would theoretically fix the address shortage, but only 
if the non-practical mass conversion occurred immediately, well than its 
a success and has been for some time. However, successes like that are 
not what made the internet.




There is this other side: I'm dualstack, and I simply dont notice.


Being in transition state indefinitely is not success.

The other side is when you are v6 only and you dont notice. We arent 
there yet. Thats the failure.


  
Here's my final (serious) suggestion. We aren't going to be able to

reverse course out of the current situation. Maybe the best thing, is
to engineer it, not complain about it. Engineering won't end either
right now. Betting on 4 continuance is betting on markets over
planning. Maybe thats what some people want? What I want doesn't
matter that much btw.

-G


Hope for the best and prepare for the worst. That means improving v6 and 
making it more adoptable and appealing to more diverse user populations.


It also means taking measures to prolong v4.

That means give them DHCP the way they want it, give them NAT the way 
they want it. Give them whatever you can whatever they want in v6 the 
way they want it, whether you like it or not. Just get it out there more 
and more faster and faster.  Ideological concerns had their day and its 
over. We are past deadline. Just get it done. Or get out of the way of 
those who want to. Yes, RiR's, IPv6 costing anyone any more money was a 
false start penalty.


It also means taking a real look at proposal like 240/4 and whatever 
else can be scrounged up, extended, worked around, whatever you have, 
because if the worst happens and we are still having these threads in a 
decade, we are going to need it. bad. And if the best happens, who cares 
about v4 and what was done to it anyways?


Now you can say nah, I am betting on things working out just the way 
they are now, but lets be clear about that.


Joe

Re: V6 still not supported

[Joe Maimon]

b...@theworld.com wrote:

We know we need to get rid of fossil fuel vehicles but electric cars,
at least at this point, leave quite a bit to be desired like battery
technology (materials needed, disposal, cost, electricity generation,
etc.)



Suppose syngas becomes economical.

Who said we have to get rid of ICE vehicles?

The essential problem is portable convertible efficient economical 
stable high density energy.


Joe

Re: V6 still not supported

[Joe Maimon]

Pascal Thubert (pthubert) via NANOG wrote:

Hi:

IPv4 is 40 years  old. IPv6 is 25 years old. In Internet time, both are old 
timers.


25 years to not achieve global domination opens the door to become 
obsoleted before it does. Pretty sure that would be more bad than good.



The rest of the world will follow the evolution because there's not enough IPv4 
for Africa or Asia anyway. I see the analogy with the industrial revolution, 
England stuck to coal and steam when the world that had nothing moved on.


Some weight to lend to your theory would be if Africa and Asia IPv6 
numbers are outpacing everywhere else. Google numbers suggest that is 
not at all the case, with the notable exception of Saudia Arabia and 
India and even Gabon.


Perhaps you have better or different numbers. We could use some good news.



Which side are you on?

Pascal


The "side" thing is the problem here. The objective is a stable and 
maximally usable internet, both now and in the future.


Joe

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Joe Maimon]

John Levine wrote:

It appears that Abraham Y. Chen  said:

 C.Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

 D.I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


*ahem*
Is this is how the IETF ivory tower residents likes to try and suppress 
debate, by relegating all group think dissenters as white noise 
nobodies? And if they have succeeded in doing such on their own forums, 
its more telling about their own process problems than anything else.


I sincerely hope I am mistaken in your characterization of the many fine 
individuals who have repeatedly gone on record in support of maintaining 
IPv4 responsibly until such time as it is properly obsoleted.


While I can understand being considered a nobody, other more notable 
definitely not nobodies have even on this tired topics' nth thread made 
themselves heard and some fairly clearly.


History will continue to show that the IETF pursued the path of pain for 
the internet.


Joe

Re: Making Use of 240/4 NetBlock

[Joe Maimon]

Christopher Morrow wrote:



On Sun, Mar 13, 2022 at 10:39 AM William Herrin <mailto:b...@herrin.us>> wrote:


On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon mailto:jmai...@jmaimon.com>> wrote:
> The true dilemma is that any amelioration of IPv4 scarcity may
indeed
> contribute to further delaying mass global IPv6 adoption,
regardless of
> whose effort and time is involved.


What's the actual proposal for 240/4?
Is it: "Make this usable by me on my /intranet/?"
Is it: "Make this usable across the internet between bespoke endpoints?"
Is it: "Make this usable for any services/users on the wider internet, 
treat it like any other unicast ipv4 address?"

Is it: "Something entirely different"

The first 2 probably already work today, if you take the time to 
control the horizontal and vertical of your networking space.
The last is probably workable, given enough time to flush out all of 
the endpoints which (today) probably treat 240/4 as 'special'.


240/4 has a special problem. The problem is that the smallest bit of 
cooperation from the broader community, other than those expending 
effort on 240/4 directly is required.


Mostly so that any potential use of 240/4 continues to be standardized. 
Which in theory, is in all parties best interest.


I think the current draft pretty much wanted a word or two changed.



So.. to move forward with 240/4 on the wider internet you'd need a 
bunch of software / hardware updates, and time for those to rollout.

Then you'd need sacrificial lambs in the user and service endpoints.


Nobody is asking for any assistance with that. It will happen or not 
based upon those who wish to expend effort on it. Apparently, most if it 
has already happened.




All of this to regain ~16 /8's worth of space (presuming you could use 
255/8?).


Really, so that anything standardized can be done with it, rather than 
nothing.


This is about extending some utilization capability of IPv4, but it is 
also about preserving standard driven behavior.


I think a /8 is 'free' on the internet for about a month, so 1.5 yrs 
of new address allocations, terrific?


That was the old paradigm, in the old days. Currently a /8 goes pretty 
far and its likely to only get further.




At the end of the day, again, almost all proposals to 'add more ipv4 
space' come down to 1 month per /8.

I think part of Jordi's point is:
  "Is that 1 month really worth the effort?


All the effort requested is for all those who think its wall head 
banging to say knock yourself out, we are unopposed to changing how IPv4 
obsolete addresses are managed because we have already bet on IPv6. Take 
whatever you want. Change whatever you want. We dont care.


Thats not a whole lot of effort being requested of the unwilling in 
exchange for their continued relevance. All the rest of the efforts are 
expected to come from the willing, able and ready. Not your concern.


But perhaps you do care. Why?

  is there a reason that all of the softare/hardware uplift and time 
to deploy is not being spent on v6?"


Perhaps you think that stymieing any effort on IPv4 is important to 
marshall the worlds attention to IPv6. Which if the shoe were on the 
other foot you would find galling and obnoxious.


There are many reasons why IPv6 hasnt done that all on its own and 
pretty much most if not all of them have nothing to do with 240/4


They have to do with IPv6. And we have heard them over and over again. 
Look inwards.


In short, IPv6 apparently keep losing to the cost vs. benefits analysis 
being performed by countless people in countless situations. You can 
claim that it should not, but that is not what is happening.


You cant make IPv4 more expensive than it already is doing all by 
itself. It is wrong to try. And apparently, its not expensive enough to 
drive mass adoption of v6, with any degree of alacrity.


v6 must have costs in contexts that have been under-addressed. Its time 
to knowledge them and perhaps work to address them.




At this point in our matrix timeline it seems to me that:
  "If you were going to deploy v6, you did... if you didn't oh, well.. 
eventually you will?"


Much like Itanium vs. amd64, there are other ways this can turn out, the 
longer it drags out. I think those ways are potentially more undesirable 
than extending IPv4 use in a standardized fashion now.




I'd prefer to not have to deploy  in a rush or on timelines I can't 
cointrol if I hadn't deployed already.
Will that timeline be 'soon' anytime soon? I don't know :( I think 
Grant's "not until i'm long retired" guess

is as good as any though :(

-chris


I for one would like to say I did all the tiny amount I conceivably 
could to leave the internet a better place than I found it.


And I think that means giving IPv4 all the runway it needs to properly 
decelerate to the fullest extent possible or at least not obstr

Re: Making Use of 240/4 NetBlock

[Joe Maimon]

JORDI PALET MARTINEZ via NANOG wrote:

Because it is a single Internet, and what we do in some parts of Internet will 
affect others?

Because, at least in my case, I'm investing my efforts in what it seems to be 
the best in the long-term for the global community, not my personal preferences?


Improving IPv6? Keep up the good work and thank you.

Protesting IPv4 efforts? Not very altruistic, more like you are 
motivated by various deep-seated emotional responses to the continuation 
of the IPv4 internet.


  


El 12/3/22 9:10, "William Herrin"  escribió:


 Why are so many otherwise smart engineers so vulnerable to false
 dilemma style fallacies? There's no "either/or" here. It's not a zero
 sum game. If you don't see value in doing more with IPv4 then why
 don't you get out of the way of folks who do?

 Regards,
 Bill Herrin




The true dilemma is that any amelioration of IPv4 scarcity may indeed 
contribute to further delaying mass global IPv6 adoption, regardless of 
whose effort and time is involved.


And I find advocating for that to be wrong and perhaps to some extent, 
immoral. Unlikely to be productive. And potentially counter-productive.


Joe

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Joe Maimon]

Saku Ytti wrote:
What if many/most large CDN, cloud, tier1 would commonly announce a 
plan to drop all IPv4 at their edge 20 years from now? How would that 
change our work? What would we stop doing and what would we start doing? 


I cant see how it would change or do anything IPv6-related for myself 
for at least 19 years. And I suspect most others would fall somewhere 
between that and never.


However, such an announcement would actually signal that we should do 
all those things now to IPv4 that will take 10 years to be useful, 
because then they will be useful for at least another 10 years.


Seriously, we have already had this sort of experiment play out numerous 
times, both with a governing body and without. We already know how it goes.


With a governing body: lack of progress right up until the deadline, 
gnashing of teeth ensues until deadline is extended, more often than not 
comprehensive conversion finally completes, later than scheduled.


Without: lack of progress right up to deadline, teeth gnashing, deadline 
is arbitrarily extended, nothing much changes and deadline is forgotten.


When IPv4 is properly obsoleted, we will see many of those announcements 
and some will matter and most wont. As it should be. However 
proclamations are not going to obsolete IPv4. As we have already seen.


I dont think advocating for large players to band together to form their 
own internet-ops standard body is going to save IPv6 and the internet. 
More likely it will doom both as we know it.


Here is an equally unlikely thought experiment.

What if many/most large CDN, cloud, tier1 would commonly announce a plan 
to compatibly extend IPv4, citing a lack of progress in IPv6 deployment 
and resulting IPv4 elimination as well as a stagnant stalemate on any 
such efforts within the would-be-relevant standard bodies?


Joe

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Grant Taylor via NANOG wrote:



I believe that talking about removing IPv4 in any capacity /now/ is a 
disservice to the larger conversation.


We mostly agree. Except that there is a significant vocal portion of the 
IPv6 spectrum that would like to start obsoleting IPv4 now.


I have my doubts about getting back to a single protocol Internet 
(IPv6) in my lifetime, much less my career.


I both doubt and very much hope that it will not be quite that long, but 
even so, the fact that it can even be considered a possibility should be 
a significant wake up call.


In any event, all this underscores the reality that IPv4 requires more 
investment to carry along until that point.



And until that point, IPv6 is an optimization, not a requirement.


How long do you wait during the "optimization" window before actually 
deploying IPv6?  The 11th hour?  Why not start deploying IPv6 with new 
green field deployments at the 2nd hour?



Until you have the itch to do so, until you have a business case to do 
so, until you no longer have any excuse not to do so. The opt in 
optimization is optional.


Joe

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Ca By wrote:




Google’s number represents how many users reach it over ipv6. Given 
Google’s ubiquity in the usa, it is a fair barometer for the usa at 
large.


Given google's popularity on handheld platforms, the users of which tend 
to be much less sensitive to IPv4 translation mechanisms and have a much 
higher penetration of native v6, I would restate that a bit more 
conservatively as


Google's statistics are likely a fair barometer for USA usage in the 
large content provider arena which have a strong mobile representation.






Reading anecdotal Nanog mails from a handful of folks concluding ipv6 
has failed will not leave the passive impartial observer with an 
accurate view.


Its incontrovertible that IPv6 has racked up a long list of failures in 
its original objectives, expectations, predictions and timelines, even 
up to this point.


I am not really convinced that IPv4 can be 
ignored/marginalized/obsoleted without penetration reaching over 90%, 
globally. And until that point, IPv6 is an optimization, not a requirement.


Perhaps it will accelerate at some percentage point. But if it drags out 
for another decade or two, all bets are off.



Joe

Re: V6 still not supported

[Joe Maimon]

b...@theworld.com wrote:

I could offer a more philosophical assessment of IPv6 deployment.

Perhaps we're there, we're doing fine. This is how it is going to go.

It's out there, it works (glitches aside), those who want it use it
tho they can't force others to use it so still need to maintain a
dual-stack if that's of importance to them. Perhaps that's a
reasonable complaint, the cost and effort of accommodating those who
haven't deployed IPv6.


If this rather healthy viewpoint was more generally pervasive IPv4 
efforts would not be met with such hysteria.



Maybe it will take 50 years (we're easily half-way there.)

Put another way, by what objective measure is IPv6 deployment seen as
failing? Other than individuals' impatience. Was there a generally
agreed upon timeline which wasn't lived up to, for example?
As a protocol and product, IPv6 is a success. It works, its deployed, 
its utilized.


As the cure and solution to address scarcity experienced by network 
users and operators, it has already failed in that goal, repetitively 
and continually.


It was supposed to do that using the additional time CIDR bequeathed to 
IPv4. Fail.


It was supposed to do that upon IANA exhaustion. Fail.

It was supposed to do that upon RiR exhaustion. Annual Fail.

It was supposed to do that prior to commercialization and 
commoditization of IPv4. Fail.


It was supposed to do that before E2E on the internet became a quaint 
historical footnote. Fail.


IPv6 has failed the Internet.

Maybe, hopefully, this is the year or decade it finally stops being the 
perennial failure, but the history of fail induced net-negatives does 
not get erased by eventual success, and worse, the future will likely 
continue to contain artifacts of those failures.


Its not impossible to envision that IPv4 does not ever go away but 
actually gets extended in such a way that it obsoletes IPv6. The longer 
this drags out the less implausible it seems.


Joe

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Joe Maimon]

Tom Beecher wrote:


The only way IPv6 will ever be ubiquitous is if there comes a time 
where there is some forcing event that requires it to be.


Unless that occurs, people will continue to spend time and energy 
coming up with ways to squeeze the blood out of v4 that could have 
been used to get v6 going instead. I don't foresee anything changing 
for most of the rest of our careers, and possibly the next generation 
behind us.


I dont think it is as bad as that, but what you are implicitly saying is 
that even multi-decades efforts to prolong IPv4 have clear justification 
to begin now, if not sooner.


As for the rest of this popular meme, instead of aspirations to force a 
chosen technology down the throats of many clearly unwilling and/or 
uninterested parties whom make up a still significant percentage of the 
internet, perhaps more effort should be expended on


A) making the chosen technology more attractive, more useful, more 
deployable, more compatible, etc. Because clearly its not enough of 
those things for many, regardless of whatever personal experience or 
theories you may have on the matter.


B) Keeping the rest of the internet as functional as possible, with 
whatever tradeoffs make send, for the actual potential duration of A 
instead of pie-in-the-sky estimates. Which have a 100% track record of 
being wrong.


Persuasion, not coercion. Which even if it were possible, is wrong and 
immoral.


The internet is supposed to be about mutually beneficial cooperation, 
not hierarchical coercion.


Joe

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Joe Maimon]

Owen DeLong via NANOG wrote:

One thing is for certain… If folks had put 0.10 as much effort into deploying 
IPv6 as has been put into arguing about whether or not ~17 /8s worth of IPv4 
makes a meaningful difference to the internet as a whole, IPv4 would long since 
have become irrelevant as it must eventually be.

Owen


You might have had a decent point there instead of a soundbite, except 
that you are conflating different people together, as if the ones 
arguing to extend IPv4 are conveniently the same ones whom if they 
redirected their efforts would have IPv6 deployed in a few jiffies.


Reality is quite a bit different.

Joe

Re: home router battery backup

[Joe Maimon]

Mark Tinka wrote:



On 1/18/22 18:15, Joe Maimon wrote:



Now how about some programming available so you can decide what 
thresholds and conditions remote start your genny which powers the 
rectifier which substitutes|augments the solar array?


Any half decent battery inverters will be able to adequately support 
this, out the box.


Mark.




The inverter in question is the one being utilized in conjunction with 
the powerwall, ats, solar array. All nicely done and reliable and wired 
in already and with proper capacity.


Being able to call for and get more DC power on demand would make this a 
true uninterruptible solution.


Running a gen to support the battery means the gen size does not need to 
correlate at all with the peaks and surges of demand and can run at 
maximum efficiency and we can avoid unbalanced leg problems and other 
voltage variation issues that can happen with portable gens.


Programming comes into play for automated monthly testing, capacity 
prediction, even spot costing of utility power. Between the grid, the 
solar array, time of day, season, weather, battery level, generator 
input, load characteristics, outage duration, grid costs/stresses there 
can be a lot of factors that might need a bit more balancing and 
programming than you might typically expect available from any half 
decent battery inverter, but might find a nice place in a truly fully 
integrated home UPS solution.


Integrate it enough and perhaps the gen/rectifier components would even 
fit into typical residential facilities spaces and this sort of setup 
could be all the more typical and standard.


Joe

Re: home router battery backup

[Joe Maimon]

Mark Tinka wrote:



On 1/18/22 00:26, Jordan wrote:


Wow, that's a nice program.  Do you know what they keep the
"reserve percentage" set to, the proportion of stored energy that
will never be discharged for grid-support, but held back for
island-mode use in case of an outage?


I don't use the Tesla Powerwall, but Li-Ion is generally the same
regardless of who packages it. The difference will be what the OEM
decides to set the low-voltage cut-off to on the inverter and/or BMS.

I'm not sure how much the owner can configure a Tesla Powerwall, but
with other installations, you can decide when your battery kicks in to
run loads, or when it hands back to the grid or generator. This
assumes evening time, when solar irradiation is unavailable, of
course, as that is generally the preferred source of energy.



Now how about some programming available so you can decide what 
thresholds and conditions remote start your genny which powers the 
rectifier which substitutes|augments the solar array?


All those 6500 PS lying about would make awesome rectifiers.

Joe


I've heard that Tesla will monitor the weather in your area to
"pre-charge" the Powerwall to account for possible power disruptions.
While I find that rather invasive, it's a cool feature for folk who
"don't want to know". Then again, I also hear that Tesla will limit or
withhold support and/or warranty if you do not connect your Powerwall
to the Internet for them to "manage". The downside I hear, with that,
is that they can remotely adjust SoH (state of health) thresholds to
lengthen battery life in order to meet warranty promises. Not sure how
true that is, but I've heard it a lot.

In terms of "reserve" capacity, Li-Ion can go much deeper than Lead
Acid. Some inverters are setup to disconnect the battery anywhere
between 3% - 20% SoC, depending on the OEM. For LFP chemistries, the
BMS will usually turn the pack off at 2.50V, while for NMC, that will
be around 2.75V. But different battery OEM's may be more or less
aggressive with their BMS's, depending on who you choose to buy from.

Mark.

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

[Joe Maimon]

Jay Hennigan wrote:

On 11/19/21 10:27, William Herrin wrote:

Howdy,

That depends on your timeline. Do you know many non-technical people
still using their Pentium III computers with circa 2001 software
versions? Connected to the Internet?


There are lots of very old networked industrial machines with embedded 
computers operated by non-network-savvy people that are still very 
much in use.


Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be 
a bit surprised to find quite a few 2001-era boxes still in service.


In the context of re-purposed IPv4 address scopes specialized equipment 
will tend to be fairly limited in its communication needs and unlikely 
to be affected.


I certainly hope they are, otherwise the security implications are severe.

How about we recast this as general purpose internet communicating 
platforms likely to have occasion to interact with these re-purposed 
addresses are nearly certain to undergo an upgrade or more over the next 
decade, or how many non-technical people are still using the original 
wrtg platform to connect them to the internet?


And yes, its quite possible that even then those addresses may have some 
more baggage than the typical IPv4 block in use today (which are hardly 
clean bills of health more often than not).


But the sooner the effort begins the more likely the utilitarian value 
will be there if or when its needed.


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Max Harmony via NANOG wrote:

On 21 Nov 2021, at 00.00, Joe Maimon  wrote:

There is a clear difference of opinion on this, that there stands a very good 
chance that prompt implementation now may prove to provide significant benefit 
in the future, should IPv6 continue to lag, which you cannot guarantee it wont.

The reassignment being implemented faster than IPv6 seems like a big assumption.


Suppose you are correct. This time. Even a broken clock can be right 
twice a day.


The only loss for the most part in most of these related proposals is 
the time spent dickering on them and a few extra patches thrown in over 
the next decade.


So just agree already.

127/8 is actually the proposal with the most potential for 
implementation issues as the definition change wends its way into system 
updates. And its easy to see that typical system updates tend to bring 
far greater disruption to system administrators on a regular basis. I 
would not rule out this change in that regard.


And if you are wrong, as history suggests you may very well be?

What is lost by not acting now is possibly far greater.

Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 discourage it by opposing proposed standards is exactly 
equal to your right to encourage it by promoting them.


Since your discouragement may take form in preventing some amount of 
improvement or amelioration to IPv4 users, there is a human cost 
associated to that.


Absent the equivalent clear correlation of harm to whatever else you 
believe those resources are engaged in, I would not say those two 
behaviors are of equal consequence.



I’m really saying what I said. That IMHO, there’s no benefit to the internet 
overall if this proposed change is accepted and/or implemented and I see no 
benefit to standardizing it. As such, I remain opposed to doing so.


There is a clear difference of opinion on this, that there stands a very 
good chance that prompt implementation now may prove to provide 
significant benefit in the future, should IPv6 continue to lag, which 
you cannot guarantee it wont.


Further, there is historical precedent that discouraging re-purposing 
IPv4 addressing is the wrong decision.




Whether or not the effort that would be wasted implementing it would go to IPv6 
or to some other more useful pursuit is not a concern I factor into my opinion 
in this case.


And I appreciate that, as I consider that reasoning to be specious at 
best, morally dubious at worst.



Again, have not made any such assumption here, either. It’s not relevant. The 
only thing I consider relevant is that any resources expended on a complete 
waste of time could be better
expended elsewhere.


I dont consider my opinion as to what people's effort should be spent on 
relevant to whether a particular proposal has merit all of its own.



Which GUA and LL are not, no matter how readily available and easily assignable 
and otherwise equivalent they are in every way but the one. They are not 
loopback designated by standard (and system implementation).

And this matters why?

Owen


So re-purpose 127/8 and if users and developers agree with you, it will 
become available right about the time IPv6 should have finally managed 
to obsolete IPv4, no harm no foul. And if it fails at that again, at 
least we will have 127/8 and cohorts.


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 inherently opposed to designating one (which 
would be all that is required for IPv6 to have one, no software updates would 
be necessary), but I’d need some additional convincing of its utility to 
support such a notion.

Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 
parity would require the same, so merely designating a prefix would only be the 
beginning.

There may not be a need. But there is clearly some benefit.

Which is? You still haven’t answered that question.


You have right below.

And if there is indeed no benefit, than there is no reason not to 
repurpose 127/8 considering that you may use many other ranges in IPv4 
for loopback and that you can just use IPv6 for loopback and there you 
go you have a whole /10.


Its not like it will overnight cause system admin headaches. And they 
should be running their loopback apps on IPv6 anyways.


Well, technically, fe80::/10 is also present and predictable on every loopback 
interface. It does come with the additional baggage of having to specify a 
scope id when referencing it, but that’s pretty minor.


Nope… It’s every bit as deterministic as 127.0.0.0/8.

If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you 
try it on something other than linux, it probably doesn’t work.
That’s also true of 127.*.*.*.


So fe80::/10 is the loopback prefix for IPv6


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 addressing. Policy then 
decides about reachability.


Think stateful firewall without NAT.

No, NAT is not a firewall. The stateful inspection that NAT depends on 
is a firewall.


You can do all of the exact same things without needing NAT. You just 
get additional capabilities without NAT that you didn’t have with NAT 
due to the limitations of shared addressing.


You an do stateful inspection and reject unwanted packets without 
having to mutilate the packet header in the process.



Owen



You are completely correct in theory.

However, in IPv4 there is a generally true assumption that there are all 
these sorts of devices  that will be deployed in a somewhat secure 
fashion and not by virtue of any particular efforts on the part of their 
manufactures, because they are rarely deployed without a NAT in front of 
them simply due to address scarcity, where NAT becomes a feature of 
network functionality and not of network security.


The hope that there will be equivalent pervasiveness of a statefull 
deny-any layer in front of these classes of devices or that they will be 
deployed|developed with sufficient/equivalent security without that 
layer is not nearly as re-assuring.


Worse, with the assumption of NAT induced security in place its all too 
logical to predict and expect that these devices are woefully 
under-equipped to protect themselves in any way without it.


Best case scenario is that practically all SOHO v6 gateways default 
configuration is statefull deny-any. In which case all you can hope to 
get from theoretical E2E is less packet mangling.


(Packet mangling is a good test case for protocols who needlessly commit 
layering violations by embedding lower layer addressing directly or 
implicitly into their behavior, so NAT has actually been beneficial in 
this manner)


The security conscious are better off deploying these devices with IPv6 
turned off. Much less chance of them accidentally becoming individually 
responsible for their own protection due to any network changes that may 
not take their existence or particularly sensitive and vulnerable state 
into consideration.


Further, security track records as they are suggest that security will 
never become the prime focus or even more than an afterthought for the 
producers of these classes of devices.


We can all wish that were not the case but it would be naive to assume 
otherwise.


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 have one, no software updates would 
be necessary), but I’d need some additional convincing of its utility to 
support such a notion.


Since the loopback prefix in IPv4 is present and usable on all systems, 
IPv6 parity would require the same, so merely designating a prefix would 
only be the beginning.


There may not be a need. But there is clearly some benefit.


I can understand that sometimes you may explicitly not want to use the loopback 
prefix for loopback applications. In fact many times. However, you dont really 
have much options when it comes to IPv6

I have not encountered a device where I could not assign additional prefixes to 
a loopback interface in IPv6, so I’m having trouble understanding your meaning 
here.


In IPv6 if you want a loopback prefix you have to pick one yourself or 
determine which one the system has chosen on its own. Because there is 
no dedicated loopback prefix other than ::1/128





Anyone who wants to assign routable IPv4 to loopback is free to do so and there 
are plenty of IPv4 ranges to choose from.

The converse is not true in IPv6.

I guess that depends on what you mean by “converse”.


I mean that in IPv6 you must assign an otherwise non-loopback prefix if 
you want one.



If you mean non-routable addresses deployed on the loopback interface, I think 
LL works fine for that purpose.


It works, but it is non deterministic and system dependent.

If you mean routable addresses deployed on the loopback interface, I think ULA 
or GUA works fine for that purpose.


And IPv4 has that too.



I actually think that IPv6 evangelicals should welcome any all ideas like this, 
especially if they believe it will further degrade the overall state of IPv4, 
because that should only serve as stronger impetus for IPv6 deployment. That 
mode of thought has been commonly expressed here and other places before.

I don’t think the current proposals being discussed will improve or degrade 
IPv4. I think they will distract implementors that choose to implement them 
from useful work for a while and end in neither benefit nor detriment beyond 
the detriment that comes from wasting effort.


There seems to be some weird mental representation of how standards 
affect the real world. Standards do not demand or direct or control in 
any way what individuals do based upon their own assessment of their 
needs, available resources and resulting benefits.


You are neither responsible or in control of how people choose to expend 
their implementing resources. Nor should you.


What standards do is increase the potential benefits of conforming to 
certain behavior.


So what you are really saying is that standardizing something that 
others may then choose to recognize as a worthwhile expenditure of their 
resources is something you would like to prevent on the assumption that 
those efforts would have otherwise gone into IPv6 advancement.


You dont have the immediate moral high ground on that one.

You dont have the long term moral high ground on that one because such 
thinking isnt new and we know its wishful at best.


You dont have the logical high ground on that one because you are 
assuming facts not in evidence, namely that


- Resources are being feverishly expended deploying IPv6 (as if)

- Those same resources will be the ones redirected to implement ideas 
such as these


- That those efforts are in anyways comparable in scope to work being 
done on IPv6 (which is supposed to be done already)


- That any such diversion of activity will actually have any real world 
affect on the state of IPv6




If I thought it would significantly degrade IPv4, I might be all for it, but I 
doubt it would even be that useful.

Owen



Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create 
a clear (but narrow) case where IPv6 would be superior to IPv4, 
irrelevant of overall network state.


Objectors to the proposal based upon their real world use of far larger 
than v4 /16 for loopback applications could implement on IPv6 with even 
more space, and in the exact same addressing context.


Which GUA and LL are not, no matter how readily available and easily 
assignable and otherwise equivalent they are in every way but the one. 
They are not loopback designated by standard (and system implementation).


Joe

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

[Joe Maimon]

Tom Beecher wrote:



The biggest impediment to IPv6 adoption is that too many people invest 
too much time and resources in finding ways to squeeze more blood from 
the IPv4 stone.


Reverse that. IPv6 has impediments to adoption, which is why more time 
and resources are being spent to keep IPv4 usable until those 
impediments can be overcome.




IPv6 isn't perfect. That's not an excuse to ignore it and invest the 
limited resources we have into Yet Another IPv4 Zombification Effort.



As noted earlier, False Dilemma

Even worse, your thinking presupposes a finite amount of people-effort 
resources that must be properly managed by those superior in some 
fashion with more correct thinking.


I hope you can see when focused in that fashion all that is wrong with 
that viewpoint.


Joe

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

[Joe Maimon]

Zu wrote:

One anecdote (the non-technical grandma) illustrates a very real problem that 
would need to be addressed -- there are non-technical people (of all ages, if 
your concerned about ageism) which will need to implement technical changes for 
which they are not equipped with the skills to do.

They do not. Only if they want the extra address. Otherwise they are no 
worse off.


Unless of course their ISP somehow decides its a good idea to put their 
router on the allzero, but you cant fix stupid.


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 you are 
supporting, that changes.

Having trouble following your desired outcome here. It seems as if you both 
want 127.0.0.0/8 to retain it’s unique properties
as deterministically loopback only and also want the benefits of repurposing it 
as GUA.

Have cake, Eat cake, please to pick only one.


Let me clear that up then.

I support serious consideration of the idea. My desired outcome is to 
see ideas like these either adopted or not but based solely on their own 
merits and especially in their own protocol context. And that folk who 
have studied the issue and invested their efforts be taken seriously and 
not be met with undeserved and might I add, unkind, scorn.


(I havent studied the issue or invested the effort, so you may continue 
to direct your scorn this way)


Its well past time to stop behaving as if we are a bunch of teenagers on 
a private BBS.


I like the loopback prefix feature of IPv4.

I can easily concede that its too large, especially in this day and age. 
And that there is a good chance that significant benefit can come from 
addressing that before IPv4 becomes obsolete.


I question the lack of dedicated loopback feature in IPv6 and I 
acknowledge that yes, you can accomplish the same with non loopback 
prefixes by essentially assigning them to loopback, but point out that 
that does not make them the same thing.


I can understand that sometimes you may explicitly not want to use the 
loopback prefix for loopback applications. In fact many times. However, 
you dont really have much options when it comes to IPv6.


And I discuss IPv6 loopback simply because of the pushback directed in a 
non-meritorious fashion from folk who apparently believe simultaneously 
that IPv6 is superior in every way to IPv4 and that any 
improvements|changes to IPv4 somehow endanger IPv6 imminent dominance.



  having a prefix
dedicated to that purpose globally vs. allowing each site that cares to choose 
their own doesn’t seem like the best
tradeoff.

Owen


But this is how it is to be done in IPv6, so lets get some lack-of-feature 
parity going with IPv4.

I’m all for IPv6 having better implementations than IPv4 rather than mere 
feature parity.



Actually I am (somewhat facetiously) suggesting that IPv4 have 
non-feature parity with IPv6 by taking away its loopback prefix.





IMHO, having additional loopbacks be assigned from either LLA or ULA space (or 
even GUA, really)
where that is needed is a superior choice vs. 127.0.0.0/8.


Anyone who wants to assign routable IPv4 to loopback is free to do so 
and there are plenty of IPv4 ranges to choose from.


The converse is not true in IPv6.


For one thing, the alternative addressing schemes (other than LLA) allow for 
routing of the
addresses off the box even though they are configured on loopback interfaces. 
There are
a number of situations where this can be a useful way to ensure that the 
addresses remain
usable regardless of the up/down state of connectivity on any particular 
non-loopback
interface on the box.

It’s one of the reasons, for example, that virtually every IBGP speaking router 
has a GUA
or ULA/1918 loopback address which is routed in the IGP and almost all IBGP 
sessions
are terminated on those loopback interfaces.

Owen

And its the fairly common way of implementing anycast services. But that 
is not what we are addressing on this thread.


I actually think that IPv6 evangelicals should welcome any all ideas 
like this, especially if they believe it will further degrade the 
overall state of IPv4, because that should only serve as stronger 
impetus for IPv6 deployment. That mode of thought has been commonly 
expressed here and other places before.


Best,

Joe

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

[Joe Maimon]

Nick Hilliard wrote:

Joe Maimon wrote on 19/11/2021 14:30:
Its very viable, since its a local support issue only. Your ISP can 
advise you that they will support you using the lowest number and you 
may then use it if you canall you may need is a single 
patched/upgraded router or firewall to get your additional static IP 
online.


That would be an entertaining support phone call with grandma.

Starting to get annoyed with ageism from tech nerds. Lots of grandma and 
grandpa computer geeks in existence these days. I think its time we 
start using great-grammy instead.


So, she gets a new CPE which issues 192.168.1.0 to her laptop and .1 
to her printer, and then her printer can no longer talk to her laptop.


So she has a datacenter cab with a cat6a multi-gig drop and the ISP 
included in the price an on-link public /30, but more is gonna cost her, 
and this is for the non-profit she is running out of her SSI.


Now she gets to use her link with two IP addresses instead of one, 
although she may have to click update firmware from the device's web 
interface, which might be harder than you think since she grew up using 
punch cards and these new fangled mouse thingies are a pain in her 
arthritic fingers, she'll take a CLI any day.


She might use that for a redundant router, or for the second 443 port 
mapping inevitably required.


Two can play the fake anecdote game.


I'm sure that the ISP would be happy to walk her through doing a 
firmware upgrade on her printer or that her day would end up better 
for having learned about DHCP assignment policies on her CPE.


They could even email her a copy of the RFC and a link to the IETF 
working group if she felt there was a problem.


Nick

ISP's may very well be inclined to advise customers that a free extra IP 
is theirs for the taking should their equipment support it.


Best,

Joe

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

[Joe Maimon]

Owen DeLong via NANOG wrote:

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



This idea gets better each time I think about it. The changes and 
support required would typically be only local to customer/vendor and it 
can be useful in multiple contexts within a single entity as well.


Or how about this one. I can add VRRP failover to every customer prefix 
with zero negative impact to them by addressing the secondary with the 
all-zero address. Only I have to upgrade since the customer doesnt use 
or refer to that address ever. Now granted, using a FHRP protocol that 
didnt require any address at all in the subnet for the non-primary would 
give the same result. And maybe maybe maybe ICMP from the secondary 
might get dropped by non-updated customer.


How about customers who like to have redundant routers now only require 
an update to do it within /30, which within vendor relationship context, 
should it be standard long enough, they may very well require, and 
should a /29 cost more, the customer may very well prefer.


Getting an extra address out of a /29 and two instead of one out of /30 
can be quite useful to each individual user and use of those prefixes.


Collectively, it may or may not extend IPv4 global resources. Probably 
not in any measurable way and possibly non existent, although it is 
conceivable that /30 would become usable enough that less /29's will be 
assigned, and the same for /29 lasting longer before requiring /28. 
Probably not much beyond that.


Its about getting more mileage from existing allocations, not really 
about making more allocations available.


And all thats needed to be done is to drop this ridiculous .0 for 
broadcast compatibility from standards.why is this even controversial?


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 false for some definitions of “in use”.


Determining the extent of this would be part of serious consideration.


In what way would the LLA or ULA above be meaningfully different from 127/8 as 
deployed?


Because 127/8 is the exact same number on every system and it is routed 
the same way on every system and every system can choose to use it how 
it and it alone wishes to.


So this make it a deterministic prefix solely in control of the local 
system without any external context to ever be taken into consideration, 
by convention and standard.


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.





Doesnt IPv6 deserve its own instead of squatting on IPv4?

I don’t see any “squatting on IPv4” here.


It means that the only deterministic loopback prefix in IPv6 larger than 
a single address is the one IPv6 inherited from IPv4.


Since, as you point out, use of the other addresses in 127.0.0.0/8 is not 
particularly widespread,


This is not my point, it is the contention of the draft standard and it 
is something I would hope is taken into serious consideration and 
researched properly/


My point is that to the extent this is true, the value of the space for 
other purposes could very well warrant re-purposing.

  having a prefix
dedicated to that purpose globally vs. allowing each site that cares to choose 
their own doesn’t seem like the best
tradeoff.

Owen


But this is how it is to be done in IPv6, so lets get some lack-of-feature 
parity going with IPv4.

Joe

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

[Joe Maimon]

Nick Hilliard wrote:

John Gilmore wrote on 19/11/2021 01:54:

Lowest address is in the most recent Linux and
FreeBSD kernels, but not yet in any OS distros.


lowest addresses will not be viable until widely supported on router 
(including CPE) platforms.  This is hard to test in the wild - ripe 
atlas will only test the transit path rather than the local 
connection. I.e. it's not clear that what you're measuring here is a 
valid way of working out whether a lowest address is generally going 
to work, because .0 has been mostly accepted in the transit path since 
the 1990s (bit alarming to see that it's still not universal).


The other risk with the lowest address proposal is that it will break 
network connectivity transitivity with no fallback or detection 
mechanism.  I.e. consider three hosts on a broadcast domain: A, B and 
C.  A uses the lowest address, B accepts a lowest address, but C does 
not.  Then A can talk to B, B can talk to C, but C cannot talk to A.  
This does not seem to be addressed in the draft.


Nick




Its very viable, since its a local support issue only. Your ISP can 
advise you that they will support you using the lowest number and you 
may then use it if you canall you may need is a single 
patched/upgraded router or firewall to get your additional static IP online.


The rest of the internet has no bearing on it.

Joe

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

[Joe Maimon]

Nick Hilliard wrote:

John Gilmore wrote on 18/11/2021 19:37:

There will be no future free-for-all that burns through 300 million
IPv4 addresses in 4 months.


this is correct not necessarily because of the reasons you state, but 
because all the RIRs have changed their ipv4 allocation policies to 
policies which assume complete or near-complete depletion of the 
available pools, rather than policies which allocate / assign on the 
basis of stated requirement.  For sure, organisations were previously 
requesting more than they needed, but if stated-requirement were 
reinstituted as a policy basis, the address space would disappear in a 
flash.


I think it more likely that organizations will treat new space like they 
do their reclaimed/returned allocations right now. We are not going 
back. IPv4 only becomes plentiful again upon obsolescence.


Need is elastic based upon general availability of supply. To say it 
differently, organizations were requesting more than than they 
absolutely required to get by. And that was ok, because there was no 
reason to require them to twist themselves into engineering pretzels 
when IPv4 was freely available.


Simple example, back in the day you could choose to deploy a T1 customer 
with a public /30 and routed /29 and that would have easily met needs 
requirements.


On the other hand, you could also deploy the same customer with 
unnumbered or private /30 and routed to loopback public /32.



The point remains that 127/8, 0/8, 240/4 are problematic to 
debogonise, and are not going to make a dramatic impact to the 
availability of ipv4 addresses in the longer term. Same with using the 
lowest ip address in a network block.  Nice idea, but 30 years late.


There's no problem implementing these ideas in code and quietly using 
the address space in private contexts.


Nick




Right or wrong, it would be nice to remove any impediment to the effort 
absent justifiable document-able and insurmountable reason why the space 
should NOT be usable.


And those impediments manifest themselves even for quietly using the 
address space in private contexts.


Also, the 30 intervening years have dramatically upped the stakes in 
terms of RoI.


I suggest considering these proposals in the light that IPv4 may be 
obsolete in a decade. And maybe not.


If it is obsolete, whats the harm?

And if it not, the benefits are clearer than ever.

Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Fred Baker wrote:

I have read through this thread, and you'll pardon me if it sounds like yet 
another rehash on yet another list. You might take a look at 
https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/,
 which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. 
I'm not sure what has changed in the past lotsa years other than which prefix 
people want to make essentially the same arguments about.


What has changed is that the intervening years have demonstrated that 
the proponents were right and the detractors were wrong. Very much so.



  My observation has been that people don't want to extend the life of IPv4 per 
se; people want to keep using it for another very short time interval and then 
blame someone else for the fact that the 32 bit integers are a finite set.



If you don't think that's a true statement, I'd be very interested to hear what 
you think might be true.

On this thread alone very thoughtful and knowledgeable sounding folk 
have made it quite clear that the efforts involved are a lot less and 
the potential benefits a lot more than the naysayers mantra.


Its time to update some assumptions.

Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Jonathan Kalbfeld via NANOG wrote:
How much runway would a single /8 give us? 
Up to 65280 /24's becoming available through registrars would be quite 
welcome to lots of small organizations or startups.



 Is it worth the headache to gain a single /8 ?


I support serious consideration be given to determine the extent of the 
headache and to answer that question.




If we’re going to do something that Majorly Breaks the Internet(tm), 
why not talk about the 240/4 space instead?


I think 240/4 is indeed a very good idea deserving of proper 
consideration. That does not mean that other ideas arent worthy as well.


But at this point 240/4 is practically a no brainer.



We can’t fight address exhaustion on the supply side.  The 
only way to fix IPv4 exhaustion is by shifting the demand curve inward 
and that is through IPV6 and aggressive reclamation of IPv4 
space.


Jonathan

Jonathan Kalbfeld

office: +1 310 317 7933 
fax: +1 310 317 7901 
home: +1 310 317 7909 
mobile: +1 310 227 1662 

ThoughtWave Technologies, Inc.
Studio City, CA 91604
https://thoughtwave.com

View our network at
https://bgp.he.net/AS54380

+1 213 984 1000

On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth > wrote:


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-00.html

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.

[ Hat tip to Lauren Weinstein, whom I stole it from ]

Cheers,
-- jra

--
Jay R. Ashworth  Baylink 
  j...@baylink.com
Designer The Things I Think 
  RFC 2100

Ashworth & Associates   http://www.bcp38.info
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 
647 1274

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

[Joe Maimon]

John R. Levine wrote:
The only effort involved on the IETF's jurisdiction was to stop 
squatting on 240/4 and perhaps maybe some other small pieces of IPv4 
that could possibly be better used elsewhere by others who may choose 
to do so.


The IETF is not the Network Police, and all IETF standards are 
entirely voluntary.


And that is exactly why they said that even though they think it might 
possibly entail similar effort to deployment of IPv6 and that IPv6 is 
supposed to obsolete IPv4 before any such effort can be realized, they 
would be amenable to reclassifying 240/4 as anything other than 
reserved, removing that barrier from those whom may voluntarily decide 
to follow that updated standard, should they find the time to squeeze in 
another project the same size and effort of IPv6 into their spare time.


Seems the IETF does indeed think it is the network police. And that they 
get to decide winners and losers.


Nothing is keeping you from persuading people to change their software 
to treat class E addresses as routable other than the detail that the 
idea is silly.


R's,
John



And indeed, they have done so. Now who looks silly?

Joe

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

[Joe Maimon]

Dave Taht wrote:
I am sad to see the most controversial of the proposals (127/16)  > first discussed here. > > Try this instead? > > 
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ 
> > >

in my mind, has the most promise for making the internet better in the
nearer term.  > > Could I get y'all to put aside the 127 proposal and read that 

over, > instead?

/30 now becomes 2 usable IP addresses for the customer.

/29 "5 static IP addresses" now becomes 6?

Doing vrrp for a customer /29 gets a bit easier.


> > ... > > It's ok, I'll wait... > > ... > > There were two other 
proposals concerning 240/4 and 0/8 also worth > reading for their 
research detail and attention to history.


Good thing they werent worried about wasting the IETF's valuable and 
precious time running the internet, because the masses cant possibly be 
trusted.


> The amount of work required to make 240/4 work in most places is now 
> very close to zero, having been essentially completed a decade ago. > 
240/4 and 0/8 checking is not present in the SDN codes we tried, and > 
we ripped the 0/8 check out of linux 3? 4? years back. Saves a few > ns. 
> > All but one iOt stack we tried worked with these, many of those > 
stacks still lack, or have poor ipv6 support. esp32 anyone? > > Just as 
ipv6 today is not globally reachable, these address spaces > may never 
be globally reachable, but defining a standard for their > potential 
sub-uses seems like a viable idea. > >


On the face of it, any of the above statements should be enough to 
silence and shameface any and all of the historical naysayers.


However it would appear they are still living in the past, as evidenced 
by continued citing of "pre-exhaustion burn rate" as if the excesses of 
the past are somehow relevant to the consumption of the future other 
than an indictment of non-prudence.


Joe

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

[Joe Maimon]

Mark Andrews wrote:
CIDR is much older than that and we still have to avoid .0 and .255 
addresses in class C space. 


I use .0 all the time.

Similarly for .0.0 and .255.255 for class B space and .0.0.0 and 
.255.255.255 for class A space. Getting everybody you want to contact 
and the path in between to be clean for 240/4 is more than just a 
replacement cycle. There is a lot of really old gear out there that 
still talks to the world and it will never work with 240/4 addresses. 
If you are selling IPv4 connectivity and your customer is given a 
240/4 address but can’t reach some place on the internet that their 
neighbour with out a 240/4 can who are they going to blame? Can you 
afford the defective product law suite. You gave then an address that 
you knew fore well would not work reliably with the Internet as a 
whole. Using 1/8 is still fraught. At least with 1/8 you are not 
fighting kernels that need to be modified for which source is not 
available. 


No address comes with any guarantees. Suppose you are 100% correct. Its 
not the IETF's role to manage the community at large resource 
expenditures, whatever their opinion may be.


The only effort involved on the IETF's jurisdiction was to stop 
squatting on 240/4 and perhaps maybe some other small pieces of IPv4 
that could possibly be better used elsewhere by others who may choose to 
do so.


Joe

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

[Joe Maimon]

John Levine wrote:

It appears that Joe Maimon  said:


For example
https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008
which fell prey to the "by the time this is usable IPv6 will have taken
over" groupthink.

Objectively wrong.

I will agree that your explanation of the reasons the IETF didn't repurpose 
240/8 is objectively wrong.

The amount of work to change every computer in the world running
TCP/IP and every IP application to treat 240/4 as unicast (or to treat
some of 127/8) is not significantly less than the work to get them to
support IPv6. So it would roughly double the work, for a 2% increase
in the address space, or for 127/8 less than 1%.  The code for IPv6
is already written, after all.
And since 2008, IPv6 related updates and patches were so few and far 
between that they could not compare with those that would have been 
required if the IETF had ordered the internet to enable 240/4.


All 240/4 needed was a decade of normal product lifecycle patching. 
Basically an afterthought. A not insignificant percentage of which has 
happened practically all by itself to date.


And you seriously suggest that "effort" FSVO is equivalent to IPv6, 
which deployment wise is pretty much in the same state as 240/4, even 
with the IETF's full backing?


Which statistic are you torturing to somehow equate the two software and 
deployment projects? Its like comparing an ant to an elephant.


And given the current sorry state of IPv6 deployment, forgive me for 
thinking that perhaps they got the numbers a teeny weeny bit wrong.

Also, while the world has run out of free IPv4 address space, there is
plenty of IPv4 if you are willing to pay for it. A 2% increase in v4
addresses would not change that.


In the decade it would have taken for 240/4 to become globally usable, 
the rate of consumption, allocation and utilization of IPv4 has changed 
to the point that yes, it would have made a big difference. In another 
decade, should IPv6 not have finally managed to obsolete IPv4, the 
appreciation of utilitarian value can only to be greater.


Its like a whole nother do-over of the final /8 give out, except twice.

Think of it in terms of /24s because thats really all any small outfit 
ever needs of IPv4 and its critical for any startup. 65k is nothing to 
sneeze at looking at it that way.





"By contrast, IPv6, despite its vastly larger pool of available address space, 
allocates only a single local loopback address (::1)

[RFC4291]. This appears to be an architectural vote of confidence in the idea 
that Internet protocols ultimately do not require millions of
distinct loopback addresses.”


IPv6 evangelicals are fond of citing the in-exhaustiveness of IPv6 in 
support of most any not particularly prudent allocation methodology or 
use of astonishingly large (in comparison to IPv4) amounts of it, but 
::1 is all that can be mustered up for loopback.


On the other hand, we must take great pause and care of doing anything 
to disturb the 1/256th of the entire address pool allocated for that 
purpose to IPv4.


In-congruent, to say the least.

Anyways, IPv6 is supposed to save us from the degrading IPv4 network, 
whats one more degradation in the form of 127/8 -> 127.0/16 ?



This is an apples-to-oranges comparison.  IPv6 has both link and site local 
addresses and an architecture to deliver packets to specific

instances of each.  This does not exist in the IPv4 world.

SO an IPv6 only system without any network interfaces can run multiple
discrete instances of the same daemon accepting connections on the same
TCP port?

Sure.

  Can I script that, can I template that with hardcoded

addresses, same as I can now for 127/8?

Sure, if you think that's a good idea which it isn't.  Use LLAs on your 
loopback interface.


Which LLA's does an IPv6 stack without any IPv6 enabled interfaces have?

Or worse, which LLA's will the IPv6 stack have with an IPv6 enabled 
interface? Depends on the hardware address?


LLA's are not a loopback range. So using them for that purpose is less 
than ideal, and unworthy of this new protocol thats supposed to take all 
the good of IPv4, discard the bad, innovate the new, usher in a renewal 
for the internet, and fail at all of that.




Personally, I take my 127/8 addresses from a configuration file since I don't 
know in advance what
other daemons might also want to run on addresses only visible on the local 
machine.


How you deal with loopbacks on your system, is by definition, local to 
your system.


All other mechanisms are not. Maybe by convention, but not definition.

Dont we appreciate standards for that very reason?


   Or, you know,
some maniac might decide that part of 127/8 isn't loopback so I have to move 
them to the part that
still is.

In IPv6 I use ULAs since that gives me the option of routing them or not.

R's,
John


ULA and registered ULA are one of those things thats hard to think about 
with a straight

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 be approved.  127/8 is in use.  It isn’t free.

There are so many things wrong with this statement that I am not even going to 
try to enumerate them.

However suffice it to say that drafts like these are concrete documentation of 
non-groupthink and essentially you are advocating for self-censorship and loss 
of historical perspective.

I’m advocating for not taking address away that have been allocated for a 
purpose.  No one knows what the impact of doing that will be.  Perhaps we 
should just take back 216.222.144.0/20?  You obviously think taking back 
address that are in use to be a good thing.  This is similar to taking back 
other address that are allocated but not advertised.


I am advocating for serious discussion on the merits, and only the 
merits, of each individual idea and proposal and to respect those 
willing to put in the effort even while likely knowing of the undeserved 
scorn bound to come their way from those who choose not do as I would 
advocate them doing.


And I think the basic contention is that the vast majority of 127/8 is 
not in use. Apples to oranges, indeed.



You can script is to the same extent that you can hard code 127/8 addresses.  
I’ve used ULA addresses but conceptually they are the same.  The lo0 interface 
also has more that 127.0.0.1 IPv4 addresses on it.

% ifconfig lo0 inet6
lo0: flags=8049 mtu 16384
options=1203
inet6 ::1 prefixlen 128 .
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet6 fd92:7065:b8e:::1 prefixlen 64

Thats twice now you have suggested that ULA and LLA are an exact 
substitute for dedicated system loopback prefix.


At the very least, it is semantically not.

Doesnt IPv6 deserve its own instead of squatting on IPv4?


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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 are so many things wrong with this statement that I am not even 
going to try to enumerate them.


However suffice it to say that drafts like these are concrete 
documentation of non-groupthink and essentially you are advocating for 
self-censorship and loss of historical perspective.


Which given the state of IPv6 transition, perhaps more of that in the 
past would have been nice.


For example 
https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008 
which fell prey to the "by the time this is usable IPv6 will have taken 
over" groupthink.


Objectively wrong.

Predictive self-fulfilling circular arguments of this sort should no 
longer be given any weight, and along your lines, should never even be 
brought up.




Lots of bad attempts to justify a bad idea.

"The IPv4 network 127/8 was first reserved by Jon Postel in 1981 [RFC0776]. 
Postel's policy was to reserve the first and last network of each class, and it does 
not appear that he had a specific plan for how to use 127/8.”

Having a space for permission-less innovation and testing is a good thing.  Jon 
understood that.


Yes its a good idea to have space that is guaranteed to be available to 
every system regardless of its networking condition and that the host 
has deterministic control over the addressing used in that space.


However, it turns out that /8 was much too large. The extreme few 
instances of its usefulness at that size pale in comparison with even 
the possibility of its usefulness to the public.


So any attempt to adjust that should be given proper attention and 
serious thought.




"By contrast, IPv6, despite its vastly larger pool of available address space, 
allocates only a single local loopback address (::1) [RFC4291]. This appears to be 
an architectural vote of confidence in the idea that Internet protocols ultimately 
do not require millions of distinct loopback addresses.”

This is an apples-to-oranges comparison.  IPv6 has both link and site local 
addresses and an architecture to deliver packets to specific instances of each. 
 This does not exist in the IPv4 world.


SO an IPv6 only system without any network interfaces can run multiple 
discrete instances of the same daemon accepting connections on the same 
TCP port? Can I script that, can I template that with hardcoded 
addresses, same as I can now for 127/8?


Good thing I can just use :::127.0.0.1/104




"In theory, having multiple local loopback addresses might be useful for 
increasing the number of distinct IPv4 sockets that can be used for inter-process 
communication within a host. The local loopback /16 network retained by this 
document will still permit billions of distinct concurrent loopback TCP connections 
within a single host, even if both the IP address and port number of one endpoint of 
each connection are fixed.”

But it doesn’t deliver millions of end points.  Sorry you simulation will not 
work because we don’t have more that 65000 end points anymore.  Sorry RFC 1918 
addresses are not always suitable.

"Reserved for " is not the same as “Reserved”.

Mark


Let them use IPv6 link local for their simulations.





On 18 Nov 2021, at 10:45, scott  wrote:



On 11/17/2021 1:29 PM, Jay R. Ashworth wrote:

This seems like a really bad idea to me; am I really the only one who noticed?




Its only a relevant idea if you still care about IPv4. In which case, it 
might be a good idea.


Joe

Re: Facebook post-mortems...

[Joe Maimon]

Mark Tinka wrote:


So I'm not worried about DNS stability when split across multiple 
physical entities.


I'm talking about the actual services being hosted on a single network 
that goes bye-bye like what we saw yesterday.


All the DNS resolution means diddly, even if it tells us that DNS is 
not the issue.


Mark.


You could put up a temp page or two. Like, the internet is not down, we 
are just having a bad day. Bear with us for a bit. Go outside and enjoy 
nature for the next few hours.


But more importantly, internal infrastructure domains, containing router 
names, bootstraps, tools, utilities, physical access control, config 
repositories, network documentations, oob-network names (who remembers 
those?) , oob-email, oob communications (messenger, conferences, voip), 
etc..


Doesnt even have to be globally registered. External DNS server in the 
resolver list of all tech laptops slaving the zone.


Rapid response requires certain amenities, or as we can see, your 
talking about hours just getting started.


Also, the oob-network needs to be used regularly or it will be 
essentially unusable when actually needed, due to bit rot (accumulation 
of unnoticed and unresolved issues) and lack of mind muscle memory.


It should be standard practice to deploy all new equipment from the 
oob-network servicing it. Install things how you want to be able to 
repair them.


Joe

Re: IPv6 woes - RFC

[Joe Maimon]

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 fine.
IPv4 was extendable, with header option as one concept that was shot 
down in favor of a new protocol.


If it was just an incremental IPv4 upgrade, than we would have been 
there already, and you could be using your extended IPv4 addresses to 
communicate with any gear over any network gear that had been upgraded 
in the past decade or two.


Its just that the internet was supposed to be able deploy a new protocol 
in the same or less time. Which didnt happen.


Joe

Re: Rack rails on network equipment

[Joe Maimon]

Andrey Khomyakov wrote:

Hi folks,
Happy Friday!


Interesting tidbit is that we actually used to manufacture custom 
rails for our Juniper EX4500 switches so the switch can be actually 
inserted from the back of the rack (you know, where most of your 
server ports are...) and not be blocked by the zero-U PDUs and all the 
cabling in the rack. Stock rails didn't work at all for us unless we 
used wider racks, which then, in turn, reduced floor capacity.



Inserting switches into the back of the rack, where its nice and hot, 
usually suggests having reverse air flow hardware. Usually not stock.


Also, since its then sucking in hot air (from the midpoint of the cab or 
so), it is still hotter than having it up front, or leaving the U open 
in front.


On the other hand, most switches are quite fine running much hotter than 
servers with their hard drives and overclocked CPU's. Or perhaps thats 
why you keep changing them.


Personally I prefer pre-wiring front-to-back with patch panels in the 
back. Works for fiber and copper RJ, not so much all-in-one cables.


Joe

Re: IPv6 woes - RFC

[Joe Maimon]

Owen DeLong wrote:



On Sep 23, 2021, at 13:26 , Joe Maimon  wrote:


I hope not, both for IPv6 sake and for the network users. We dont know how much 
longer the goal will take, there is materializing a real possibility we will 
never quite reach it, and the potholes on the way are pretty rough.

By “the only way out is through” I meant that the only way we can get back to 
anything resembling mono-stack is, in fact, to complete the transition to IPv6.


The question is how? Waiting for everyone or nearly everyone to dual 
stack, the current strategy, is awful. Like pulling gum off a shoe.





And as the trip winds on, the landscape is changing, not necessarily for the 
better.

The IPv4 landscape will continue to get worse and worse. It cannot possibly get 
better, there just aren’t enough addresses for that.


I was referring to the more general network landscape, the governance 
system, the end of p2p, balkanization, etc, all trends and shifts that 
become more likely and entrenched the longer IPv6 lags and the scarcer 
IPv4 becomes.





One more "any decade now" and another IPv4 replacement/extension might just 
happen on the scene and catch on, rendering IPv6 the most wasteful global technical 
debacle to date.

If that’s what it takes to move forward with a protocol that has enough 
addresses, then so be it. I’m not attached to IPv6 particularly, but I 
recognize that IPv4 can’t keep up. As such, IPv6 is just the best current 
candidate. If someone offers a better choice, I’m all for it.


Whose to say it would be a proper p2p system? I know you believe 
strongly in that and want it fully restored, at least on the protocol level.



  Unfortunately, the IPv6 resistant forces
are making that hard for everyone else.

Owen

You say that as if it was a surprise, when it should not have been, and you say 
that as if something can be done about it, which we should know by now cannot 
be the primary focus, since it cannot be done in any timely fashion. If at all.

It’s not a surprise, but it is a tragedy.

There are things that can be done about it, but nobody currently wants to do 
them.


So lets make the conversation revolve around what can be done to 
actually advance IPv6, and what we should know by now is that convincing 
or coercing deployment with the current state of affairs does not have 
enough horsepower to get IPv6 anywhere far anytime soon.





Its time to throw mud on the wall and see what sticks. Dual stack and wait is 
an ongoing failure slouching to disaster.

IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among 
us remain in denial about that.


Who is this "us"? Anybody even discussing IPv6 in a public forum is well 
ahead of the curve. Unfortunately. All early adopters. Real Early.


At some point, we are going to have to make a choice about how much longer we 
want to keep letting them hold us back. It will not be an easy choice, it will 
not be convenient, and it will not be simple.

The question is how much more pain an dhow much longer will it take before the 
choice becomes less difficult than the wait?

Owen

Exactly what does this choice look like? Turn off IPv4 when its fully 
functional? Only the have-nots may make the choice not to deploy IPv4 
sometime in the future, and for them, its not going to be a real choice.



Joe

Re: IPv6 woes - RFC

[Joe Maimon]

Owen DeLong via NANOG wrote:

There are real issues with dual-stack, as this thread started out with.
I don't think there is a need neither to invent IPv6 problems, nor to
promote IPv6 advantages.  What we need is a way out of dual-stack-hell.

I don’t disagree, but a reversion to IPv4-only certainly won’t do it.


For everyone who does have enough IPv4 addresses, it does. This is the 
problem in a nutshell. If that starts trending, IPv6 is done.



I think the only way out is through.


I hope not, both for IPv6 sake and for the network users. We dont know 
how much longer the goal will take, there is materializing a real 
possibility we will never quite reach it, and the potholes on the way 
are pretty rough.


And as the trip winds on, the landscape is changing, not necessarily for 
the better.


One more "any decade now" and another IPv4 replacement/extension might 
just happen on the scene and catch on, rendering IPv6 the most wasteful 
global technical debacle to date.




  Unfortunately, the IPv6 resistant forces
are making that hard for everyone else.

Owen


You say that as if it was a surprise, when it should not have been, and 
you say that as if something can be done about it, which we should know 
by now cannot be the primary focus, since it cannot be done in any 
timely fashion. If at all.


Its time to throw mud on the wall and see what sticks. Dual stack and 
wait is an ongoing failure slouching to disaster.


Joe

Re: IPv6 woes - RFC

[Joe Maimon]

Baldur Norddahl wrote:



On Mon, Sep 13, 2021 at 8:22 PM Randy Bush > wrote:


real compatibility with ipv4 was disdained.  the transition plan was
dual stack and v4 would go away in a handful of years.  the 93
transition mechanisms were desperate add-ons when v4 did not go away.
and dual stack does not scale, as it requires v4 space proportional to
deployed v6 space.


What I find most peculiar about this whole rant (not just yours but 
the whole thread) is that I may be the only one who found implementing 
IPv6 with dual stack completely trivial and a non issue? There is no 
scale issue nor any of the other rubbish.


Baldur

The essential point is that your dual stack is barely relevant until 
every stack is dual. Which is impossible without CGNAT.


It also turns out that is barely relevant how easy it may have been for you.

Joe

Re: A crazy idea

[Joe Maimon]

Owen DeLong wrote:



On Jul 29, 2021, at 14:06 , Joe Maimon  wrote:



t...@pelican.org wrote:

On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:


The allocation of IPv6 space with prefixes shorter than /64 is indeed a
consideration for bigger administrative domains like country
governments, but on the other end, SOHO customers would be happy with
/96, /104 or even /112 allocations if they could get them.  (Just how
many light bulbs, fridges, toasters, doorbells, phones,  does SOHOs
have?)  I would *not* like to see "us" make the same mistake with IPv6
that was made with IPv4, handing out large blocks of space like so many
pieces of M or Skittles candy.

Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think in terms of subnets.  
I can't stress this enough, it's the big v4 to v6 paradigm shift - don't think about "how many 
hosts on this net", think about "how many nets".

Think of how many large ISP's a /3 of ipv6 effectively holds, assuming that /48 
per customer is the norm, and /24 up to /12 assignments for those ISP's is also.

In those terms IPv6 isnt that much bigger.


Let’s say an average “large” ISP burns a /11 of IPv4 serving their ~2M 
customers with a single IPv4 address each.
IPv4 supports a maximum of 2,048 such ISPs without regard to space for 
multicast, class E, etc. (which reduce this number).

Let’s say that we give each of them enough space to issue 16M /48s (an IPv6 
/24).

That means we have 2^21 IPv6 large ISPs serving 8x as many customers with /48s.

That’s 2 million large ISPs covered in the first /3.

Since each of them is serving around 2M customers, that’s 4,000,000,000,000 
customers.
For comparison, the world population is less than8,000,000,000.

Tell me again how IPv6 is not that much larger, Joe?

Owen


I will simply point out that even by this measurement, we have reduced 
IPv6 scarcity-free longevity from mind boggingly larger into only a 2-3 
thousand times larger. Thats enough of an accomplishment that I dont 
even have to delve into the discussions and proposals, some you were 
even a part of that could have resulted in even larger allocations to 
mega ISP's being acceptable, and still might.


Continuing to operate under the belief that there isnt any way we can 
use ipv6 that can result in some form of scarcity may very well cause 
that scarcity to become a serious possibility much sooner than might 
have ever been expected, with much larger and entrenched consequences 
than we can predict today.


So lets stop saying IPv6 is infinite. We can cede enough bits to cause 
scarcity to an upcoming generation who wont thank us.


I propose that any way we decide to use IPv6 today we should be able to 
say confidently will continue to operate under any imaginable scenarios 
for the next century, minimally.


Thats a conservative number considering that it would have been nice had 
they done a quarter of that for IPv4 back when it was where ipv6 is now.


Joe

Re: A crazy idea

[Joe Maimon]

t...@pelican.org wrote:

On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:


The allocation of IPv6 space with prefixes shorter than /64 is indeed a
consideration for bigger administrative domains like country
governments, but on the other end, SOHO customers would be happy with
/96, /104 or even /112 allocations if they could get them.  (Just how
many light bulbs, fridges, toasters, doorbells, phones,  does SOHOs
have?)  I would *not* like to see "us" make the same mistake with IPv6
that was made with IPv4, handing out large blocks of space like so many
pieces of M or Skittles candy.

Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think in terms of subnets.  
I can't stress this enough, it's the big v4 to v6 paradigm shift - don't think about "how many 
hosts on this net", think about "how many nets".


Think of how many large ISP's a /3 of ipv6 effectively holds, assuming 
that /48 per customer is the norm, and /24 up to /12 assignments for 
those ISP's is also.


In those terms IPv6 isnt that much bigger.

Re: Anycast but for egress

[Joe Maimon]

Vimal wrote:

(Unsure if this is the right forum to ask this question, but here goes:)

From what I understand, IP Anycast can be used to steer traffic into a 
server that's close to the client.


I am curious if anyone here has/encountered a setup where they use 
anycast IP on their gateways... to have a predictable egress IP for 
their traffic, regardless of where they are located?


For example, a search engine crawler could in principle have the same 
IP advertised all over the world, but it looks like they don't...  I 
wonder why?


--
Vimal

Its definitely possible, but would need a layer of software (kernel 
mode) on all the anycast holders synchronizing state to ensure 
asymmetric replies/connections get forwarded/shifted to the correct host.


If the goals are worth that kind of effort is another question. And 
performance is likely to be "tricky".

Re: Looking for transit with full table bgp cloud options

[Joe Maimon]

Joe Maimon wrote:

Hey all,

I am looking for some cloud services, that would support Transit and 
full table BGP to the cloud provided vm(s).


I am specifically not referring to the various BGP private vpn 
routing/interconnect options available with the big guys.


If anyone has any suggestions or ideas I would love to hear them.

Joe


A big thank you to all who responded. Amongst welcomed suggestions, 
bgp.services spreadsheet is exactly what I was hoping to turnup. I 
suppose that is what the personal colo list morphed into.


Joe

Looking for transit with full table bgp cloud options

[Joe Maimon]

Hey all,

I am looking for some cloud services, that would support Transit and 
full table BGP to the cloud provided vm(s).


I am specifically not referring to the various BGP private vpn 
routing/interconnect options available with the big guys.


If anyone has any suggestions or ideas I would love to hear them.

Joe

Re: De-bogonising 2a10::/12

[Joe Maimon]

Baldur Norddahl wrote:

Hello

What is the purpose of null routing bogons? As it is, my network being 
default free zone, traffic to bogons will be returned to sender with 
no route to host.


The only way for me to send out traffic to bogons is if one my peers 
announces a bogon prefix. Even if I did null route bogons, manually or 
through the use of the Cymru service, a peer could still announce a 
more specific and override that.



That more specifics override could use an override.

Re: power to the internet

[Joe Maimon]

They are quite lacking in longevity and density.

Which is fine if you have enough space and adequate maintenance to 
change them out and they are only a bridge for local generation.


Remote installations do not typically have these characteristics.

Pretty much every basement mux or other RT telco installation I have 
ever seen had the original battery setup still in place and lasted 
approximately 3 seconds when the lights went off. I try to put them into 
my batteries whenever possibly.


Further, many fios/cable customer NID devices do come with batteries, 
but they are usually lead acid, often the telco charges to replace the 
battery and they are typically only there to power the POTS lines on the 
NID.


Joe


Baldur Norddahl wrote:
What is wrong with lead acid battery backup? Seems to be exceedingly 
stable from my experience. We have all our equipment on -48V DC and 
have never had a power interruption at any site.


The requirements here are 48 hours of backup by law. Telecom is 
declared to be part of emergency and defense, so they put in a 
requirement for resilience.


Regards

Baldur


tor. 26. dec. 2019 11.33 skrev Joe Maimon <mailto:jmai...@jmaimon.com>>:


Unless telecom infrastructure has been diligently changing out the
lead
acid battery approach at all their remote terminals, powered gpon,
hfc
and antennae plants will never last more than minutes. If at all.

A traditional car has between a 100-200amp alternator @12volts

How much generating capacity can you get out of a typical hybrid?

Self-isolating and re-tieing inverters. Economic household ATS
systems.
Do those exist?

Enough independent distributed capacity and now comes the ability to
create grid islands. How might that look?

Electric grid shortage is likely coming to NYC, courtesy of folk of
certain political persuasion and their love of stone age era
living. IP
decommissioning.

If you have CO loop copper, keep it.

Joe

Don Gould wrote:
> This is a very short term problem.
>
> The market is going to fill with battery storage sooner rather than
> later.
>
> Solar is just exploding.
>
> Your car will "house tie".
>
> 6G will solve your data problem.
>
> D
>
>
>
> --
> Don Gould
> 5 Cargill Place
> Richmond
> Christchurch, New Zealand
> Mobile/Telegram: + 64 21 114 0699
> www. <http://www.tusker.net.au/>bowenvale.co.nz
<http://bowenvale.co.nz>
>
>
>
>  Original message 
> From: Michael Thomas mailto:m...@mtcc.com>>
> Date: 26/12/19 2:33 PM (GMT+12:00)
> To: nanog@nanog.org <mailto:nanog@nanog.org>
> Subject: power to the internet
>
>
>
https://www.politico.com/news/2019/12/25/california-power-shutoffs-089678
>
>
> This article details some of the issues with California's "new
reality"
> of planned blackouts. One of the big things that came to light with
> these blackouts is that our network infrastructure's resilience is
> pretty lacking. While I was (surprisingly to me) ok with my DSL
> connection out in the boonies, lots and lots of people with cable
> weren't so lucky. And I'm not sure how bad the situation is with
> cellular infrastructure, but I assume it's not much better than
cable.
> And I wouldn't doubt that other DSL deployments go dark when
power is
> down. I have no clue with fiber.
>
> So I guess what I'm wondering is what can we do about this? What
should
> we do about this? These days IP access is not just convenience,
it's the
> way we go about our lives, just like electricity itself. At base, it
> seems to me that network operators should be required to keep
the lights
> on in blackouts just like POTS operators do now. If I have power to
> light my modem or charge in my phone, I should be able to get
onto the
> net. That seems like table stakes.
>
> One of the things we learned also is that the blackouts seem to last
> between 2-3 days apiece. I happen to have a generator since I'm
out in
> the boonies and our power gets cut regularly because of snow,
but not
> everyone has that luxury. I kind of want to think that my
router+modem
> use about 20 watts, so powering it up would take about 1.5kwh for 3
> days. a quick google look shows that I'd probably need to shell
out $500
> or so for a battery of that capacity, and that's doesn't include
your
> phones, laptops, tv's, etc power needs. What does that mean?
That is a
> major expense for a lot of people.
>
> On the bright side, I hear that power generator companies stocks
have
> gone through the roof.
>
> On the dark side, this is probably coming to a lot more states and
> countries due to climate change. Australia. Sigh.
>
> Mike
>

Re: power to the internet

[Joe Maimon]

Unless telecom infrastructure has been diligently changing out the lead 
acid battery approach at all their remote terminals, powered gpon, hfc 
and antennae plants will never last more than minutes. If at all.


A traditional car has between a 100-200amp alternator @12volts

How much generating capacity can you get out of a typical hybrid?

Self-isolating and re-tieing inverters. Economic household ATS systems. 
Do those exist?


Enough independent distributed capacity and now comes the ability to 
create grid islands. How might that look?


Electric grid shortage is likely coming to NYC, courtesy of folk of 
certain political persuasion and their love of stone age era living. IP 
decommissioning.


If you have CO loop copper, keep it.

Joe

Don Gould wrote:

This is a very short term problem.

The market is going to fill with battery storage sooner rather than 
later.


Solar is just exploding.

Your car will "house tie".

6G will solve your data problem.

D



--
Don Gould
5 Cargill Place
Richmond
Christchurch, New Zealand
Mobile/Telegram: + 64 21 114 0699
www. bowenvale.co.nz



 Original message 
From: Michael Thomas 
Date: 26/12/19 2:33 PM (GMT+12:00)
To: nanog@nanog.org
Subject: power to the internet


https://www.politico.com/news/2019/12/25/california-power-shutoffs-089678


This article details some of the issues with California's "new reality"
of planned blackouts. One of the big things that came to light with
these blackouts is that our network infrastructure's resilience is
pretty lacking. While I was (surprisingly to me) ok with my DSL
connection out in the boonies, lots and lots of people with cable
weren't so lucky. And I'm not sure how bad the situation is with
cellular infrastructure, but I assume it's not much better than cable.
And I wouldn't doubt that other DSL deployments go dark when power is
down. I have no clue with fiber.

So I guess what I'm wondering is what can we do about this? What should
we do about this? These days IP access is not just convenience, it's the
way we go about our lives, just like electricity itself. At base, it
seems to me that network operators should be required to keep the lights
on in blackouts just like POTS operators do now. If I have power to
light my modem or charge in my phone, I should be able to get onto the
net. That seems like table stakes.

One of the things we learned also is that the blackouts seem to last
between 2-3 days apiece. I happen to have a generator since I'm out in
the boonies and our power gets cut regularly because of snow, but not
everyone has that luxury. I kind of want to think that my router+modem
use about 20 watts, so powering it up would take about 1.5kwh for 3
days. a quick google look shows that I'd probably need to shell out $500
or so for a battery of that capacity, and that's doesn't include your
phones, laptops, tv's, etc power needs. What does that mean? That is a
major expense for a lot of people.

On the bright side, I hear that power generator companies stocks have
gone through the roof.

On the dark side, this is probably coming to a lot more states and
countries due to climate change. Australia. Sigh.

Mike

Re: Short-circuited traceroutes on FIOS

[Joe Maimon]

This is not from a verizon CPE. Its happening on their CO internet 
gateway customer facing routers.


tcptraceroute looks more legit

Joe

Nimrod Levy wrote:
Is that unique to the FiOS gateway device? I don't use their router 
and my traces go right out.



On Tue, Dec 10, 2019 at 3:08 PM Joe Maimon <mailto:jmai...@jmaimon.com>> wrote:


Apparently Verizon FIOS is a red herring, terminating ICMP
traceroutes
right on their gateways.

More internet breakage. Thanks for the information to all who
responded.

Random control test.

C:\Users\Home>tracert -d 1.4.5.6

Tracing route to 1.4.5.6 over a maximum of 30 hops

   115 ms 5 ms<1 ms  172.18.24.1
   2 3 ms23 ms24 ms  192.168.2.33
   3 3 ms 6 ms 3 ms  1.4.5.6

Trace complete.


    Joe

Joe Maimon wrote:
> Anyone have an idea why there are some destinations that on
> residential verizon fios here in NY area terminate right on first
> external hop?
>
> There seems to be a CDN common denominator here. On other networks
> with more typical BGP paths and traceroutes, users are reporting
> issues accessing these sites.
>
> C:\Users\Home>tracert www.usfoods.com <http://www.usfoods.com>
>
> Tracing route to statics.usfoods.com
<http://statics.usfoods.com> [205.132.109.90]
> over a maximum of 30 hops:
>
>   1 3 ms<1 ms<1 ms  172.18.24.1
>   2 4 ms 3 ms 3 ms  192.168.2.33
>   317 ms 6 ms 3 ms statics.usfoods.com
<http://statics.usfoods.com> [205.132.109.90]
>
> Trace complete.
>
> C:\Users\Home>tracert atworkhp.americanexpress.com
<http://atworkhp.americanexpress.com>
>
> Tracing route to atworkhp.americanexpress.com.akadns.net
<http://atworkhp.americanexpress.com.akadns.net> [139.71.19.87]
> over a maximum of 30 hops:
>
>   1 2 ms<1 ms<1 ms  172.18.24.1
>   2 3 ms 4 ms23 ms  192.168.2.33
>   321 ms11 ms 5 ms
atworkhomepage2.americanexpress.com
<http://atworkhomepage2.americanexpress.com>
> [139.71.19.87]
>
> Trace complete.
>
> C:\Users\Home>tracert portal.discover.com
<http://portal.discover.com>
>
> Tracing route to e14577.x.akamaiedge.net
<http://e14577.x.akamaiedge.net> [23.51.172.254]
> over a maximum of 30 hops:
>
>   1 3 ms 1 ms18 ms  172.18.24.1
>   221 ms 7 ms 6 ms  192.168.2.33
>   3 4 ms 2 ms 2 ms
> a23-51-172-254.deploy.static.akamaitechnologies.com
<http://a23-51-172-254.deploy.static.akamaitechnologies.com>
[23.51.172.254]
>
> Trace complete.
>
>
>

Re: Short-circuited traceroutes on FIOS

[Joe Maimon]

Apparently Verizon FIOS is a red herring, terminating ICMP traceroutes 
right on their gateways.


More internet breakage. Thanks for the information to all who responded.

Random control test.

C:\Users\Home>tracert -d 1.4.5.6

Tracing route to 1.4.5.6 over a maximum of 30 hops

  115 ms 5 ms<1 ms  172.18.24.1
  2 3 ms23 ms24 ms  192.168.2.33
  3 3 ms 6 ms 3 ms  1.4.5.6

Trace complete.


Joe

Joe Maimon wrote:
Anyone have an idea why there are some destinations that on 
residential verizon fios here in NY area terminate right on first 
external hop?


There seems to be a CDN common denominator here. On other networks 
with more typical BGP paths and traceroutes, users are reporting 
issues accessing these sites.


C:\Users\Home>tracert www.usfoods.com

Tracing route to statics.usfoods.com [205.132.109.90]
over a maximum of 30 hops:

  1 3 ms<1 ms<1 ms  172.18.24.1
  2 4 ms 3 ms 3 ms  192.168.2.33
  317 ms 6 ms 3 ms  statics.usfoods.com [205.132.109.90]

Trace complete.

C:\Users\Home>tracert atworkhp.americanexpress.com

Tracing route to atworkhp.americanexpress.com.akadns.net [139.71.19.87]
over a maximum of 30 hops:

  1 2 ms<1 ms<1 ms  172.18.24.1
  2 3 ms 4 ms23 ms  192.168.2.33
  321 ms11 ms 5 ms atworkhomepage2.americanexpress.com 
[139.71.19.87]


Trace complete.

C:\Users\Home>tracert portal.discover.com

Tracing route to e14577.x.akamaiedge.net [23.51.172.254]
over a maximum of 30 hops:

  1 3 ms 1 ms18 ms  172.18.24.1
  221 ms 7 ms 6 ms  192.168.2.33
  3 4 ms 2 ms 2 ms 
a23-51-172-254.deploy.static.akamaitechnologies.com [23.51.172.254]


Trace complete.

Short-circuited traceroutes on FIOS

[Joe Maimon]

Anyone have an idea why there are some destinations that on residential 
verizon fios here in NY area terminate right on first external hop?


There seems to be a CDN common denominator here. On other networks with 
more typical BGP paths and traceroutes, users are reporting issues 
accessing these sites.


C:\Users\Home>tracert www.usfoods.com

Tracing route to statics.usfoods.com [205.132.109.90]
over a maximum of 30 hops:

  1 3 ms<1 ms<1 ms  172.18.24.1
  2 4 ms 3 ms 3 ms  192.168.2.33
  317 ms 6 ms 3 ms  statics.usfoods.com [205.132.109.90]

Trace complete.

C:\Users\Home>tracert atworkhp.americanexpress.com

Tracing route to atworkhp.americanexpress.com.akadns.net [139.71.19.87]
over a maximum of 30 hops:

  1 2 ms<1 ms<1 ms  172.18.24.1
  2 3 ms 4 ms23 ms  192.168.2.33
  321 ms11 ms 5 ms  atworkhomepage2.americanexpress.com 
[139.71.19.87]


Trace complete.

C:\Users\Home>tracert portal.discover.com

Tracing route to e14577.x.akamaiedge.net [23.51.172.254]
over a maximum of 30 hops:

  1 3 ms 1 ms18 ms  172.18.24.1
  221 ms 7 ms 6 ms  192.168.2.33
  3 4 ms 2 ms 2 ms 
a23-51-172-254.deploy.static.akamaitechnologies.com [23.51.172.254]


Trace complete.

Re: fuzzy subnet aggregation

[Joe Maimon]

Good news, bad news.

With an inefficient bash script on an inefficient platform, 120k 
processes in less than 15minutes.


Thus far, the best I have is less than 10% reduction with barely 
acceptable aggressiveness.


The distribution is too varied or the level of aggressiveness has to be 
beyond any subtleties.


Putting this one back on the shelf.

Joe

Michel Py wrote:


I am curious to see how many prefixes aggregation saves.

Michel.