Mailing List Archive

1 2 3  View All
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
Just replying to Joe's post here to add a little more context to at least one of the problems that will certainly appear if this would come about.

FreeBSD operators have been using this space for quite a long time for many NAT'ing reasons including firewalls and other services behind them for jail routing and such.

https://dan.langille.org/2013/12/29/freebsd-jails-on-non-routable-ip-addresses/

That's just one example that I've seen repeated in multiple other ways. One of which a jail operator with about 250 addresses out of that range that enabled his jail routed services.

Of course that can be changed but really for just this small of a influx of addresses ? Seems really wasteful to me.

--
J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

> On Nov 20, 2021, at 23:54, Joe Maimon <jmaimon@jmaimon.com> wrote:
> ?
>
> 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: is ipv6 fast, was silly Redeploying [ In reply to ]
Owen DeLong wrote:

> Uh, no. It is so because on average IPv4 is so fragmented that most
> providers of any size are advertising 8+ prefixes compared to a more
> realistic IPv6 average of 1-3.

Mergers of entities having an IP address range is a primary reason
of entities having multiple address ranges. As IPv6 was
developed a lot later than IPv4, it has not suffered from
mergers so much yet.

Masataka Ohta
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
Subject: Re: is ipv6 fast, was silly Redeploying Date: Mon, Nov 22, 2021 at 02:04:55AM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):

> Mergers of entities having an IP address range is a primary reason
> of entities having multiple address ranges. As IPv6 was
> developed a lot later than IPv4, it has not suffered from
> mergers so much yet.

Yes. You are completely correct. But, those entities usually have
one v6 prefix each. And multiple v4 ones. Because they've required
more addresses. Not everyone are Apple, "hp"[0] or MIT, where initial
allocation still is mostly sufficient. (I believe MIT handed some back
too) Instead they had to ask repeated times for smaller and smaller
chunks of addresses. (Now they're buying them for prices that may well
be motivating people to come up with crazy schemes of reusing reserved
addresses.. )

In contrast, the v6 allocations are mostly sufficient. Even for sprawling
businesses. In the end, if they merge with another company, each merger
brings one (1) more net, not a flock of v4 /24's.

Your reasoning is correct, but the size of the math matters more.
--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Content: 80% POLYESTER, 20% DACRONi ... The waitress's UNIFORM sheds
TARTAR SAUCE like an 8" by 10" GLOSSY ...

[0] The real Hewlett-Packard made test equipment. What calls itself "hp"
today is just another IT company.
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
On 11/20/21 9:29 PM, 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.

At some level I think there's a good chance that they'd just work. I
wrote a significant amount of the Lantronix terminal server code and it
never occurred to me that I should enforce rules about 127.0.0.0 or
Class D or Class E. It really didn't have much bearing on a terminal
server or the other host-like things we built. If you typed it in, it
would work, if you  listened on a port it wouldn't care what the address
was. I would imagine that lots of stacks from back in the day were just
like that.

Mike
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
On November 20, 2021 at 21:29 jay@west.net (Jay Hennigan) wrote:
> > 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?

# date; lscpu

Sun Nov 21 20:14:44 EST 2021
Architecture: i686
CPU op-mode(s): 32-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 8
Model name: Pentium III (Coppermine)
Stepping: 3
CPU MHz: 933.075
BogoMIPS: 1866.25

(Ok it runs a somewhat newer opensuse.)

--
-Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
> On Nov 21, 2021, at 09:04 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Owen DeLong wrote:
>
>> Uh, no. It is so because on average IPv4 is so fragmented that most
>> providers of any size are advertising 8+ prefixes compared to a more
>> realistic IPv6 average of 1-3.
>
> Mergers of entities having an IP address range is a primary reason
> of entities having multiple address ranges. As IPv6 was
> developed a lot later than IPv4, it has not suffered from
> mergers so much yet.

No, it is not. Slow start and other RIR policies around scarcity and fairness of
distribution of the last crumbs are the primary contributor, with traffic engineering
a somewhat distant second. Mergers are actually somewhere around 10th on the list last
time I looked.

Owen
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
Mans Nilsson wrote:

> Not everyone are Apple, "hp"[0] or MIT, where initial
> allocation still is mostly sufficient.

The number of routing table entries is growing exponentially,
not because of increase of the number of ISPs, but because of
multihoming.

As such, if entities requiring IPv4 multihoming will also
require IPv6 multihoming, the numbers of routing table
entries will be same.

The proper solution is to have end to end multihoming:

https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

> Your reasoning is correct, but the size of the math matters more.

Indeed, with the current operational practice. global IPv4
routing table size is bounded below 16M. OTOH, that for
IPv6 is unbounded.

Masataka Ohta
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
On Thu, Nov 18, 2021 at 1:21 PM John Gilmore <gnu@toad.com> wrote:

> We have found no ASIC IP implementations that
> hardwire in assumptions about specific IP address ranges. If you know
> of any, please let us know, otherwise, let's let that strawman rest.
>

There's at least one. Marvell PresteriaCX (its either PresteriaCX or DX,
forget which). It is in Juniper EX4500, among others.
Hardware-based bogon filter when L3 routing that cannot be disabled.


cheers,

lincoln.
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
> On Nov 22, 2021, at 02:45 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Mans Nilsson wrote:
>
> > Not everyone are Apple, "hp"[0] or MIT, where initial
> > allocation still is mostly sufficient.
>
> The number of routing table entries is growing exponentially,
> not because of increase of the number of ISPs, but because of
> multihoming.

Again, wrong. The number is growing exponentially primarily because of the
fragmentation that comes from recycling addresses.

> As such, if entities requiring IPv4 multihoming will also
> require IPv6 multihoming, the numbers of routing table
> entries will be same.

There are actually ways to do IPv6 multihoming that don’t require using the
same prefix with both providers. Yes, there are tradeoffs, but these mechanisms
aren’t even practical in IPv4, but have been sufficiently widely implemented in
IPv6 to say that they are viable in some cases.

Nonetheless, multihoming isn’t creating 8-16 prefixes per ASN. Fragmentation
is.

>> Your reasoning is correct, but the size of the math matters more.
>
> Indeed, with the current operational practice. global IPv4
> routing table size is bounded below 16M. OTOH, that for
> IPv6 is unbounded.

Only by virtue of the lack of addresses available in IPv4. The other tradeoffs
associated with that limitation are rather unpalatable at best.

Owen
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
Owen DeLong wrote:

>> The number of routing table entries is growing exponentially, not
>> because of increase of the number of ISPs, but because of
>> multihoming.
>
> Again, wrong. The number is growing exponentially primarily because
> of the fragmentation that comes from recycling addresses.

Such fragmentation only occurs when address ranges are rent to
others for multihoming but later recycled for internal use,
which means it is caused by multihoming.

Anyway, such cases are quite unlikely and negligible.

> There are actually ways to do IPv6 multihoming that don’t require
> using the same prefix with both providers.

That's what I proposed 20 years ago both with IPv4 and IPv6 in:

https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

> Yes, there are tradeoffs,
> but these mechanisms aren't even practical in IPv4,

Wrong. As is specified by rfc2821:

When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable

the idea of end to end multihoming is widely deployed by SMTP at
the application layer, though wider deployment require TCP
modification as I wrote in my draft.

Similar specification is also found in section 7.2 of rfc1035.

> but have been
> sufficiently widely implemented in IPv6 to say that they are viable
> in some cases.

You are just wrong. IP layer has very little to do with it.

Masataka Ohta

PS

LISP is garbage.
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
> On Nov 23, 2021, at 12:28 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Owen DeLong wrote:
>
>>> The number of routing table entries is growing exponentially, not
>>> because of increase of the number of ISPs, but because of multihoming.
>> Again, wrong. The number is growing exponentially primarily because
>> of the fragmentation that comes from recycling addresses.
>
> Such fragmentation only occurs when address ranges are rent to
> others for multihoming but later recycled for internal use,
> which means it is caused by multihoming.

Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a class A
as smaller prefixes to various other purchasers.

It happens when /16s are sold off to multiple purchasers in pieces.

> Anyway, such cases are quite unlikely and negligible.

ROFLMAO you are demonstrating your extreme detachment from reality:

http://ipv4marketgroup.com <http://ipv4marketgroup.com/>
http://ipv4auctions.com <http://ipv4auctions.com/>
etc.

There are multiple businesses that do almost nothing outside of these types of transactions.

>> There are actually ways to do IPv6 multihoming that don’t require
>> using the same prefix with both providers.
>
> That's what I proposed 20 years ago both with IPv4 and IPv6 in:
>
> https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

THat’s not one of the alternatives I was talking about.

>> Yes, there are tradeoffs,
>> but these mechanisms aren't even practical in IPv4,
>
> Wrong. As is specified by rfc2821:
>
> When the lookup succeeds, the mapping can result in a list of
> alternative delivery addresses rather than a single address, because
> of multiple MX records, multihoming, or both. To provide reliable
> mail transmission, the SMTP client MUST be able to try (and retry)
> each of the relevant addresses in this list in order, until a
> delivery attempt succeeds. However, there MAY also be a configurable
>
> the idea of end to end multihoming is widely deployed by SMTP at
> the application layer, though wider deployment require TCP
> modification as I wrote in my draft.

Again, NOT what I was talking about. I was talking about the fact that in IPv6, you can multi-home by applying a prefix from each provider to each subnet. If the upstream connection goes away, deprecate the RA for that prefix and/or mark it as no longer on-link.

> Similar specification is also found in section 7.2 of rfc1035.

You are talking about pomegranate seeds, I’m talking about Apples. They are not the same, so your statements about my remarks are inherently flawed.

>> but have been
>> sufficiently widely implemented in IPv6 to say that they are viable
>> in some cases.
>
> You are just wrong. IP layer has very little to do with it.

No, you’re just talking about a form of multihoming that has absolutely nothing to do with the forms I was referring to.

> LISP is garbage.

Somewhat agree, though the concept wasn’t entirely wrong. Separating Locators from IDs is something we will eventually need to do in order to scale internet routing. LISP is definitely
not the ideal way to do it, but was a valiant attempt if one assumes the constraints of having to operate in an existing IPv6 environment. If one is willing to modify the packet header, then there are better options.

Owen
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
When considering the IPv6 product, I would suggest you read
USGv6-Revision-1 (1) to define the specification you need for the product.
Then go to the USGv6 Registry (2), select the features and read the
Supplier Declaration of Conformity (SDOC) to ensure that the product meets
your requirements. Do this prior to having the discussion with the vendor
sales.

Also, ask for documents which provide details on performance and security
testing. It will save you hours of troubleshooting problems and patching
vulnerability.

Lessons learned from implementing IPv6 products.

(1) https://www.nist.gov/programs-projects/usgv6-program/usgv6-revision-1
(2) https://www.iol.unh.edu/registry/usgv6

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Sat, Nov 20, 2021 at 2:36 AM John Lee <jllee9753@gmail.com> wrote:

> Cisco and Juniper routers have had v6 functionality for over 10 years.
> Lucent/Nokia, and others. Check UNL list at
> https://www.iol.unh.edu/registry/usgv6 for v6 compliant routers and
> switches.
>
> John Lee
>
> On Fri, Nov 19, 2021 at 5:48 PM John Levine <johnl@iecc.com> wrote:
>
>> It appears that Michael Thomas <mike@mtcc.com> said:
>> >And just as impossible since it would pop it out of the fast path. Does
>> >big iron support ipv6 these days?
>>
>> My research associate Ms. Google advises me that Juniper does:
>>
>>
>> https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/ipv6-technology-overview.html
>>
>> As does Cisco:
>>
>>
>> https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9600-series-switches/nb-06-cat9600-ser-sup-eng-data-sheet-cte-en.pdf
>>
>> R's,
>> John
>>
>
Re: is ipv6 fast, was silly Redeploying [ In reply to ]
Owen DeLong wrote:

>>> Again, wrong. The number is growing exponentially primarily
>>> because of the fragmentation that comes from recycling
>>> addresses.

> Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a
> class A as smaller prefixes to various other purchasers.

That, by no means, is not recycling. Moreover, most, if not
all, entities purchasing address ranges use them with multihoming.

> ROFLMAO you are demonstrating your extreme detachment from reality:

So, you have never thought about the reason why people buy
IP addresses.

>> https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt
>
> THat's not one of the alternatives I was talking about.

That you haven't mentioned any alternative and have talked
about nothing is your problem.

Masataka Ohta
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
On Fri, Nov 19, 2021 at 09:43:26AM -0800, Michael Thomas wrote:
>
> On 11/19/21 8:27 AM, Randy Bush wrote:
> > these measurements would be great if there could be a full research-
> > style paper, with methodology artifacts, and reproducible results.
> > otherwise it disappears in the gossip stream of mailimg lists.
> >
> Maybe an experimental rfc making it a rfc 1918-like subnet and implementing
> it on openwrt or something like that to see what happens. how many ip
> cameras and the like roll over and die? same for class E addresses too, I
> suppose. The question with anything that asks about legacy is how long the
> long tail actually is.
>
> Mike, not that have any position on whether this is a good idea or not

I can tell you it's observable out there and if i use my home network
to follow default i can tell it is working through those devices at
least.

I agree with Randy it would be good if someone did this, it shouldn't be
too hard with ripe atlas and a provider deciding to announce something
like 240.2.3.0/24 to see if it can be reached.

That's at least a decent measurement and report, but the client
side OS will still be a variable that is difficult to digest. Not sure
how many people are running very old IP stacks. This is another hard to
measure problem.

- Jared

--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
On Thu, Nov 25, 2021 at 8:25 AM Jared Mauch <jared@puck.nether.net> wrote:
>
> On Fri, Nov 19, 2021 at 09:43:26AM -0800, Michael Thomas wrote:
> >
> > On 11/19/21 8:27 AM, Randy Bush wrote:
> > > these measurements would be great if there could be a full research-
> > > style paper, with methodology artifacts, and reproducible results.
> > > otherwise it disappears in the gossip stream of mailimg lists.
> > >
> > Maybe an experimental rfc making it a rfc 1918-like subnet and implementing
> > it on openwrt or something like that to see what happens. how many ip
> > cameras and the like roll over and die? same for class E addresses too, I
> > suppose. The question with anything that asks about legacy is how long the
> > long tail actually is.
> >
> > Mike, not that have any position on whether this is a good idea or not
>
> I can tell you it's observable out there and if i use my home network
> to follow default i can tell it is working through those devices at
> least.
>
> I agree with Randy it would be good if someone did this, it shouldn't be
> too hard with ripe atlas and a provider deciding to announce something

the atlas is good stuff, I am curious (OT) if they have added a
videoconferencing-like test to it?

> like 240.2.3.0/24 to see if it can be reached.

I very much would like a study of 240/4. In particular, announcing
255.255/16 might pick up a lot
of misconfigured routers out there.

Tests of the DNS would also be useful. This test setup has been
working for years now...

$ host postel.taht.net
postel.taht.net has address 85.90.246.167
postel.taht.net has address 255.255.255.254 # wireguard vpn presently
postel.taht.net has address 0.0.0.1 # wireguard vpn
postel.taht.net has IPv6 address 2a01:7e01:e001:28:f3ee:d002:0:beef #
ironically the ipv6 address is down and I hadn't noticed!

>
> That's at least a decent measurement and report, but the client
> side OS will still be a variable that is difficult to digest. Not sure
> how many people are running very old IP stacks. This is another hard to
> measure problem.
>
> - Jared
>
> --
> Jared Mauch | pgp key available via finger from jared@puck.nether.net
> clue++; | http://puck.nether.net/~jared/ My statements are only mine.



--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

1 2 3  View All