Mailing List Archive

On Wed, Feb 10, 2021 at 10:38:00AM -0800, William Herrin wrote:
> None whatsoever. You just have to be really big.

Hi Beel,

Thanks for backing me up with an example of an organization with
competent network engineering. Their ability to almost infinitely
leverage the existing rfc1918 address space to serve an appreciable
fraction of all Internet attached hosts is a real demonstration of the
possible.

Since relay,

--
. ___ ___ . . ___
. \ / |\ |\ \
. _\_ /__ |-\ |-\ \__

> On Feb 11, 2021, at 05:55 , Izaac <izaac@setec.org> wrote:
>
> On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote:
>> without creating partitioned networks.
>
> Ridiculous. Why would you establish such a criteria? The defining
> characteristic of rfc1918 networks is that they are partitioned.
>
> The ability to recognize and exploit partitions within a network,
> natural or otherwise, is the measure of competence in a network
> engineer.
>
> Stop making excuses.

Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely
addressable whether reachable by policy or not.

IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.

Stop making excuses and let’s fix the network.

Owen

On 2/11/21 16:29, Owen DeLong wrote:
> Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely
> addressable whether reachable by policy or not.
>
> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.
>
> Stop making excuses and let’s fix the network.

What amazes me about the movies is that they never seem to have IP(v4)
problems. But then again, listening to every keystroke being accompanied
by a beeping sound, or feverishly typing on a keyboard in order to zoom
into a photo when I generally move my mouse to do exactly that, doesn't
necessarily inspire real world alignment. Ah well, it's the movies...
one can depart one airport in a B737 and land at their destination in an
A380.

Also, in the movies, IP(v4) addresses can begin with 260 and end in 314.
And yet, somehow, every Internet user in the movies can be mapped to a
person, on a desk, in their bedroom, in a house on their street.

*shrugs*

In the real world, for us, I don't get why we are still fighting hard to
keep IPv4 around. When I type on my keyboard, there is no corresponding
beep with each key. Nor do I need to type 100 characters to zoom into a
picture; I just use my mouse or trackpad. The movies which make the
Internet and computers these weird objects actually rely on a working
Internet to get produced and distributed.

Let's not normalize the sustenance of IPv4 in 2021, in the real world.

Mark.

You don't, you wastefully assign a /24 to every unique thing that you think
needs an internal management IP block (even if there's 5 things that answer
pings there), and decide it's too much work to renumber things. Easy for a
big ISP that's also acquired many small/mid-sized ISPs to run out of v4
private IP space that way.



On Wed, Feb 10, 2021 at 4:05 AM Owen DeLong <owen@delong.com> wrote:

> Please explain to me how you uniquely number 40M endpoints with RFC-1918
> without running out of
> addresses and without creating partitioned networks.
>
> If you can’t, then I’m not the one making excuses.
>
> Owen
>
>
> > On Feb 9, 2021, at 15:44 , Izaac <izaac@setec.org> wrote:
> >
> > On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
> >> it is definitely possible to run out of RFC-1918 space with scale and
> no incompetence.
> >
> > No, it isn't. It's the year 2021. Stop making excuses.
> >
> > --
> > . ___ ___ . . ___
> > . \ / |\ |\ \
> > . _\_ /__ |-\ |-\ \__
>
>

On Thu, Feb 11, 2021 at 6:13 AM Izaac <izaac@setec.org> wrote:
> On Wed, Feb 10, 2021 at 10:38:00AM -0800, William Herrin wrote:
> > None whatsoever. You just have to be really big.
>
> Hi Beel,

That was unnecessary. Sorry I used an S instead of a Z.

> Thanks for backing me up with an example of an organization with
> competent network engineering. Their ability to almost infinitely
> leverage the existing rfc1918 address space to serve an appreciable
> fraction of all Internet attached hosts is a real demonstration of the
> possible.

Except they don't. One of the reasons you can't put vms in multiple
regions into the same VPC is they don't have enough IP addresses to
uniquely address the backend hosts in every region. They end up with a
squirrelly VPC peering thing they relies on multiple gateway hosts to
overcome the address partitioning from overlapping RFC1918.

In other words, it proves the exact opposite of your assertion.

Regards,
Bill Herrin



--
William Herrin
bill@herrin.us
https://bill.herrin.us/

----- On Feb 11, 2021, at 9:15 AM, Eric Kuhnke <eric.kuhnke@gmail.com> wrote:

Hi,

You're right and wrong.

> You don't, you wastefully assign a /24 to every unique thing that you think
> needs an internal management IP block (even if there's 5 things that answer
> pings there),

Reword that to: in the late 1990s, someone took an ICND course and decided
that assigned a /24 as a minimum for each subnet was fine as they would never
run out of RFC1918 space.

Today, the current network owner is stuck with that inherited problem.

> and decide it's too much work to renumber things.

Reword that to: and management decides that they are not going to fund a
renumbering project as they have other priorities. (that's how work gets
funded in every large org that I've worked for)

> Easy for a big ISP that's also acquired many small/mid-sized ISPs to run out of
> v4 private IP space that way.

Not just ISPs. Plenty of decades old enterprises.

Mark Tinka wrote:

> Let's not normalize the sustenance of IPv4 in 2021, in the real world.

Our opinions don't matter to the PHBs whos bonuses rely on features delivered.

The only time that I got some serious attention with regards to this matter was
when my manager and I took it three layers up and warned them that we were
about to run out of RFC1918 space unless drastic measures were taken. They were,
but now how we wanted: they forced other groups to return unused allocations.
Now we had half of 10/8 back, and deployment of new pods could resume...

Problem "solved".

I get really sad when people bicker on this list about who is at fault. The
purity fundamentalists complain that realists have run out of RFC1918 due to
their poor decisions, while in 99% of the cases it's a result of decisions made
long ago by their predecessors. The true enemy here is mid-level management
that refuses to prioritize deployment of IPv6.

What we should be discussing is how best to approach that problem. It's where
ops and corporate politics overlap.

Thanks,

Sabri

On 2/11/21 6:29 AM, Owen DeLong wrote:
>
>> On Feb 11, 2021, at 05:55 , Izaac <izaac@setec.org> wrote:
>>
>> On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote:
>>> without creating partitioned networks.
>> Ridiculous. Why would you establish such a criteria? The defining
>> characteristic of rfc1918 networks is that they are partitioned.
>>
>> The ability to recognize and exploit partitions within a network,
>> natural or otherwise, is the measure of competence in a network
>> engineer.
>>
>> Stop making excuses.
> Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely
> addressable whether reachable by policy or not.
>
> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.
>
> Stop making excuses and let’s fix the network.
>
> Owen

TCP/IP wasn't designed; it evolved (OK, a slight exaggeration). The
ISO-OSI protocol stack was designed. Many years ago, I taught a course
on TCP/IP networking. The course was written by someone else, I was just
being paid to present/teach it. Anyway, I vividly remember a slide with
bullet points explaining why TCP/IP was a transitional technology, and
would be rapidly phased out, replaced by the "standard", intelligently
designed ISO-OSI stack. By the time I taught the course, I had to tell
the class that every single statement on that slide was incorrect. In
the end, evolution beat out intelligent design, by a country mile.

It was probably a couple of years later -- the year definitely started
with a 1 -- that I first heard that IPv4 was being phased out, to be
replaced over the next couple of years by IPv6. We've been hearing it
ever since.

That doesn't mean that we'll be living with IPv4 forever. A peer to peer
system where each endpoint is uniquely addressable is desirable. But in
a world of virtual machines, load balancers, etc., the binding of an IP
address to a particular, physical piece of hardware has long since
become tenuous. IPv4 is evolving into a 48-bit address space for
endpoints (32-bit host + 16-bit port). That development has extended
IPv4's useful life by many years.

There is pain associated with continuing to make IPv4 work. And there is
pain associated with transitioning to IPv6. IPv6 will be adopted when
the pain of the former path is much larger than the pain of the latter
path. Saying "RFC-1918 is a bandaid for an obsolete protocol" is using a
normative, rather than empirical, definition of "obsolete". In the
empirical sense, things are obsolete when people stop using them. Tine
will tell when that happens.

Jim Shankland

> On 12 Feb 2021, at 08:11, Jim Shankland <nanog@shankland.org> wrote:
>
> On 2/11/21 6:29 AM, Owen DeLong wrote:
>>
>>> On Feb 11, 2021, at 05:55 , Izaac <izaac@setec.org> wrote:
>>>
>>> On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote:
>>>> without creating partitioned networks.
>>> Ridiculous. Why would you establish such a criteria? The defining
>>> characteristic of rfc1918 networks is that they are partitioned.
>>>
>>> The ability to recognize and exploit partitions within a network,
>>> natural or otherwise, is the measure of competence in a network
>>> engineer.
>>>
>>> Stop making excuses.
>> Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely
>> addressable whether reachable by policy or not.
>>
>> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.
>>
>> Stop making excuses and let’s fix the network.
>>
>> Owen
>
> TCP/IP wasn't designed; it evolved (OK, a slight exaggeration). The ISO-OSI protocol stack was designed. Many years ago, I taught a course on TCP/IP networking. The course was written by someone else, I was just being paid to present/teach it. Anyway, I vividly remember a slide with bullet points explaining why TCP/IP was a transitional technology, and would be rapidly phased out, replaced by the "standard", intelligently designed ISO-OSI stack. By the time I taught the course, I had to tell the class that every single statement on that slide was incorrect. In the end, evolution beat out intelligent design, by a country mile.
>
> It was probably a couple of years later -- the year definitely started with a 1 -- that I first heard that IPv4 was being phased out, to be replaced over the next couple of years by IPv6. We've been hearing it ever since.
>
> That doesn't mean that we'll be living with IPv4 forever. A peer to peer system where each endpoint is uniquely addressable is desirable. But in a world of virtual machines, load balancers, etc., the binding of an IP address to a particular, physical piece of hardware has long since become tenuous. IPv4 is evolving into a 48-bit address space for endpoints (32-bit host + 16-bit port). That development has extended IPv4's useful life by many years.
>
> There is pain associated with continuing to make IPv4 work. And there is pain associated with transitioning to IPv6. IPv6 will be adopted when the pain of the former path is much larger than the pain of the latter path. Saying "RFC-1918 is a bandaid for an obsolete protocol" is using a normative, rather than empirical, definition of "obsolete". In the empirical sense, things are obsolete when people stop using them. Tine will tell when that happens.
>
> Jim Shankland

For most networks there is almost no pain in enabling IPv6. Its reconfigure the routers to announce IPv6 prefixes and you are done. We are 20+ years into IPv6 deployment. Almost everything you buy today works with IPv6. Even the crappy $50 home router does IPv6. 100s of millions of household networks have had IPv6 enabled without the owners of those networks needing to anything other than perhaps swap out a IPv4-only router to one that supports IPv6. Hell lots of those home networks are behind IPv6-only uplinks with the CPE router translating the legacy IPv4 to IPv6 for transport over the IPv6-only uplink. The same happens with mobile phones these days. If you have a phone that was purchased in the last 10 years, give or take, you will most probably be talking to the world over a IPv6-only link. Even Telstra here in Australia is transition their network to IPv6-only, the network in South Australia is IPv6-only with the other states to come. Optus here has been shipping IPv6 capable routers for the last several years with every new install / replacement. Optus haven’t yet enabled IPv6 to the home but the installed base is becoming IPv6 capable.

The harder part is making sure every piece of kit works with IPv6 when you want to turn off IPv4 internally but even then you can put that equipment behind bi-directional NAT-64 boxes.

You have large parts of the world actively turning off as much IPv4 as they can. Connections to legacy IPv4-only services are being tunnelled over IPv6 either by encapsulation or bi-directional protocol translation.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Fri, 12 Feb 2021 09:05:51 +1100
Mark Andrews <marka@isc.org> wrote:

> Almost everything you buy today works with IPv6. Even the crappy $50 home router does IPv6.

You're testing very different gear than I am. I have not found
this to be true, and I look harder than most.

I put every new CPE I come across, high-end and low-end,
against our auto-config dual-stack setup to see how well they work with
v6. Our setup is fairly simple: dhcp v4, dhcp v6 with /56 PD
I also test with static IP configs (/30 or /31 v4, /127 v6 with routed /56 or /48)

devices seem to fall into many different categories:

* Just works. I think I have fewer than 5 tested devices that land here.
Some of them only after I reported bugs and managed to get fixes
(these are my favorite vendors).
* almost just works; minor bugs that can be worked around if you research how
* works if configured a very specific way, but not without ISP cooperation
* can be made to work if you are an expert who will go past the normal interface.
* works when static, but requires extra help and knowledge to get working with
dynamic config or just doesn't
* allows you to configure it as if it would work, but doesn't;
sometimes works at first but fails over time (I do long-term stability testing).
* doesn't even pretend to work (even if the packaging claims support)
* doesn't work. Doesn't claim to. No plans to make it work. Stop asking us.

More surprising is that having a big name or being a no-name is
no indication of what category you will fall into. Juniper SRX needs
a little help due to known bug, for example. Another nice, big-name
device starts by sending a malformed packet to my dhcpv6 server and
just fails before getting out of the gate. Ubiquiti ERx was a nice
surprise as far as functionality and configurability, but no support in
the GUI.

Support is non-existent in SMX solutions even from the biggest
names. This is often a surprise to them when I point it out.

I'm convinced most people claiming IPv6 support is common
haven't actually tried it with many devices. We support v6 one way or
another on all our Internet services, but it has been a chore, to put it
mildly. CPE hasn't even been the biggest problem.

--TimH

> On 12 Feb 2021, at 10:25, Tim Howe <tim.h@bendtel.com> wrote:
>
> On Fri, 12 Feb 2021 09:05:51 +1100
> Mark Andrews <marka@isc.org> wrote:
>
>> Almost everything you buy today works with IPv6. Even the crappy $50 home router does IPv6.
>
> You're testing very different gear than I am. I have not found
> this to be true, and I look harder than most.
>
> I put every new CPE I come across, high-end and low-end,
> against our auto-config dual-stack setup to see how well they work with
> v6. Our setup is fairly simple: dhcp v4, dhcp v6 with /56 PD
> I also test with static IP configs (/30 or /31 v4, /127 v6 with routed /56 or /48)
>
> devices seem to fall into many different categories:
>
> * Just works. I think I have fewer than 5 tested devices that land here.
> Some of them only after I reported bugs and managed to get fixes
> (these are my favorite vendors).
> * almost just works; minor bugs that can be worked around if you research how
> * works if configured a very specific way, but not without ISP cooperation
> * can be made to work if you are an expert who will go past the normal interface.
> * works when static, but requires extra help and knowledge to get working with
> dynamic config or just doesn't
> * allows you to configure it as if it would work, but doesn't;
> sometimes works at first but fails over time (I do long-term stability testing).
> * doesn't even pretend to work (even if the packaging claims support)
> * doesn't work. Doesn't claim to. No plans to make it work. Stop asking us.
>
> More surprising is that having a big name or being a no-name is
> no indication of what category you will fall into. Juniper SRX needs
> a little help due to known bug, for example. Another nice, big-name
> device starts by sending a malformed packet to my dhcpv6 server and
> just fails before getting out of the gate. Ubiquiti ERx was a nice
> surprise as far as functionality and configurability, but no support in
> the GUI.
>
> Support is non-existent in SMX solutions even from the biggest
> names. This is often a surprise to them when I point it out.
>
> I'm convinced most people claiming IPv6 support is common
> haven't actually tried it with many devices. We support v6 one way or
> another on all our Internet services, but it has been a chore, to put it
> mildly. CPE hasn't even been the biggest problem.
>
> —TimH

Well I’m glad you are testing so you don’t distribute garbage to your customers.
I wish more ISPs would do more of it.

There is also plenty of garbage on the IPv4 side as well.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

i must say i am impressed that the ipv6 must be deployed now and it
solves it all religion is still being shouted from the street corner 25
years on. it is as if the shouters think they will convince any body or
change anything. folk will deploy X when they perceive that the
cost:benefit is in X's favor. and 25 years on, we are not changing
people's perceptions. it's only been a quarter of a century; have some
patience.

randy

On Thu, Feb 11, 2021 at 06:29:42AM -0800, Owen DeLong wrote:
> Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely
> addressable whether reachable by policy or not.

I think that is a dramatic over-simplification of the IP design criteria
-- as it was already met by NCP or even a single ethernet segment.  But
that's an aside. I recommend that you read rfc1918, with a particular
focus on Section 2, because I'm about to employ its language:

When dealing at large scale, an incompetent network engineer sees a
network under their control as a single enterprise.  Whereas a competent
network engineer recognizes that they are actually operating a
federation of enterprises. They identify the seams, design an
architecture which exploits them, and allocate their scarce resources
appropriately.

> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.

So, in your mind, IPv4 was "obsolete" in 1996 -- almost three years
before IPv6 was even specified?  Fascinating. I could be in no way
mistaken for an IPv4/NAT apologist, but that one's new on me.

> Stop making excuses and let's fix the network

If you want to "fix the network," tolerate neither incompetence or sloth
from its operators. Educate the former. Encourage the latter.

--
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__

On Thu, Feb 11, 2021 at 09:53:56AM -0800, William Herrin wrote:
> In other words, it proves the exact opposite of your assertion.

Golly. Do you want to tell the 1M+ AWS customers that the services they
paid ~$280B for last year don't work, or should I?

--
. ___ ___ . . ___
. \ / |\ |\ \
. _\_ /__ |-\ |-\ \__

On 2/11/21 5:41 PM, Izaac wrote:
>
>> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.
> So, in your mind, IPv4 was "obsolete" in 1996 -- almost three years
> before IPv6 was even specified?  Fascinating. I could be in no way
> mistaken for an IPv4/NAT apologist, but that one's new on me.

ipv6 was on my radar in the early 90's. it was definitely at least 1993,
maybe earlier.

Mike

1995? https://en.m.wikipedia.org/wiki/IPv6
On Feb 11, 2021 8:51 PM, Michael Thomas <mike@mtcc.com> wrote:

&#13;
On 2/11/21 5:41 PM, Izaac wrote:&#13;
>&#13;
>> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.&#13;
> So, in your mind, IPv4 was "obsolete" in 1996 -- almost three years&#13;
> before IPv6 was even specified?&#160; Fascinating. I could be in no way&#13;
> mistaken for an IPv4/NAT apologist, but that one's new on me.&#13;
&#13;
ipv6 was on my radar in the early 90's. it was definitely at least 1993, &#13;
maybe earlier.&#13;
&#13;
Mike&#13;
&#13;

> On 12 Feb 2021, at 12:41, Izaac <izaac@setec.org> wrote:
>
> On Thu, Feb 11, 2021 at 06:29:42AM -0800, Owen DeLong wrote:
>> Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely
>> addressable whether reachable by policy or not.
>
> I think that is a dramatic over-simplification of the IP design criteria
> -- as it was already met by NCP or even a single ethernet segment. But
> that's an aside. I recommend that you read rfc1918, with a particular
> focus on Section 2, because I'm about to employ its language:
>
> When dealing at large scale, an incompetent network engineer sees a
> network under their control as a single enterprise. Whereas a competent
> network engineer recognizes that they are actually operating a
> federation of enterprises. They identify the seams, design an
> architecture which exploits them, and allocate their scarce resources
> appropriately.
>
>> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.
>
> So, in your mind, IPv4 was "obsolete" in 1996 -- almost three years
> before IPv6 was even specified? Fascinating. I could be in no way
> mistaken for an IPv4/NAT apologist, but that one's new on me.

IPv4’s address space was known to be too small well before RFC1918.

September 1994 https://tools.ietf.org/html/draft-ipng-recommendation-00 -> RFC 1752
July 1995 https://tools.ietf.org/html/draft-ietf-cidrd-private-addr-00 -> RFC 1918

RFC 1918 was deployed as a mechanism to extend the usefulness of IPv4 until
IPNG, which became IPv6, was available by reducing the address space pressure on
the registries.

I knew IPv4 didn’t have enough addresses in 1988 when I got my first IPv4 address
allocation. Anyone with a bit of common sense could see that 4B addresses was
not enough for the Earth. It was just a matter of time before it would need to
be replaced.

>> Stop making excuses and let's fix the network
>
> If you want to "fix the network," tolerate neither incompetence or sloth
> from its operators. Educate the former. Encourage the latter.
>
> --
> . ___ ___ . . ___
> . \ / |\ |\ \
> . _\_ /__ |-\ |-\ \__

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Thu, Feb 11, 2021 at 5:52 PM Izaac <izaac@setec.org> wrote:
> On Thu, Feb 11, 2021 at 09:53:56AM -0800, William Herrin wrote:
> > In other words, it proves the exact opposite of your assertion.
>
> Golly. Do you want to tell the 1M+ AWS customers that the services they
> paid ~$280B for last year don't work, or should I?

You moved the goal post there, Izaac with a z. Your original claim:

On Tue, Feb 9, 2021 at 3:46 PM Izaac <izaac@setec.org> wrote:
> On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
> > it is definitely possible to run out of RFC-1918 space with scale and no incompetence.
>
> No, it isn't.

Yes, it is. Amazon did. And you seem to agree they're competent.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/

On Jan 23, 2021, at 11:32 AM, Sabri Berisha <sabri@cluecentral.net> wrote:
>
> Personally, I would
> argue that a full implementation of IPv6 means that v4 could be phased out without
> adverse effect on the production network.

I like that definition.

Hi,

On 11/02/2021 13:00, nanog-request@nanog.org wrote:
> Date: Wed, 10 Feb 2021 09:50:56 -0800
> From: Doug Barton <dougb@dougbarton.us>
>[...] On 2/10/21 5:56 AM, Ca By wrote>
>> The 3 cellular networks in the usa, 100m subs each, use ipv6 to uniquely
>> address customers. And in the case of ims (telephony on a celluar), it
>> is ipv6-only, afaik.
> So that answers the question of how to scale networks past what can be
> done with 1918 space. Although why the phones would need to talk
> directly to each other, I can't imagine.

- P2P applications?

- (because I'm tethering,) enable customers to share a service to other
people without relying to (many) external parties? (actually, that was
the purpose of the Internet since the beginning if I'm right)

- ...

> I also reject the premise that any org, no matter how large, needs to
> uniquely number every endpoint. When I was doing IPAM for a living, not
> allowing the workstations in Tucson to talk to the printers in Singapore
> was considered a feature. I even had one customer who wanted the
> printers to all have the same (1918) IP address in every office because
> they had a lot of sales people who traveled between offices who couldn't
> handle reconfiguring every time they visited a new location. I thought
> it was a little too precious personally, but the customer is always
> right. :)

Here comes the DNS imho if it was accepted by the customer. Same result,
better management and flexibility...

> Sure, it's easier to give every endpoint a unique address, but it is not
> a requirement, and probably isn't even a good idea. Spend a little time
> designing your network so that the things that need to talk to each
> other can, and the things that don't have to, can't. I did a lot of
> large multinational corporations using this type of design and never
> even came close to exhausting 1918 space.


Here comes your firewall rules and all your ACL ... easier with IPv6 imho


--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/

On 2/12/21 02:51, Randy Bush wrote:
> i must say i am impressed that the ipv6 must be deployed now and it
> solves it all religion is still being shouted from the street corner 25
> years on. it is as if the shouters think they will convince any body or
> change anything. folk will deploy X when they perceive that the
> cost:benefit is in X's favor. and 25 years on, we are not changing
> people's perceptions. it's only been a quarter of a century; have some
> patience.

We'll carry on.

Those who want to join will join, when they join.

Mark.

>> i must say i am impressed that the ipv6 must be deployed now and it
>> solves it all religion is still being shouted from the street corner
>> 25 years on. it is as if the shouters think they will convince any
>> body or change anything. folk will deploy X when they perceive that
>> the cost:benefit is in X's favor. and 25 years on, we are not
>> changing people's perceptions. it's only been a quarter of a
>> century; have some patience.
>
> We'll carry on.
>
> Those who want to join will join, when they join.

iij joined in '97. and helped others who asked. but i'm from the rainy
pacific northwest (of the states). we don't try to push water uphill.

randy

On 2/12/21 06:41, Randy Bush wrote:

> iij joined in '97. and helped others who asked. but i'm from the rainy
> pacific northwest (of the states). we don't try to push water uphill.

As my Gambian friend would say, "Lead a horse to water, and teach it how
to fish".

My first join was in 2005. We, like you, also helped those who asked.
The momentum is now at a point where the incentive to turn on IPv6 has
to come from within.

Mark.

Eric, I’d argue that does fall within the definition of incompetence called out by Izaac.

I’m talking about how you run out of RFC-1918 space (if you choose to use it in the first place) without incompetence.

Owen


> On Feb 11, 2021, at 09:15 , Eric Kuhnke <eric.kuhnke@gmail.com> wrote:
>
> You don't, you wastefully assign a /24 to every unique thing that you think needs an internal management IP block (even if there's 5 things that answer pings there), and decide it's too much work to renumber things. Easy for a big ISP that's also acquired many small/mid-sized ISPs to run out of v4 private IP space that way.
>
>
>
> On Wed, Feb 10, 2021 at 4:05 AM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
> Please explain to me how you uniquely number 40M endpoints with RFC-1918 without running out of
> addresses and without creating partitioned networks.
>
> If you can’t, then I’m not the one making excuses.
>
> Owen
>
>
> > On Feb 9, 2021, at 15:44 , Izaac <izaac@setec.org <mailto:izaac@setec.org>> wrote:
> >
> > On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
> >> it is definitely possible to run out of RFC-1918 space with scale and no incompetence.
> >
> > No, it isn't. It's the year 2021. Stop making excuses.
> >
> > --
> > . ___ ___ . . ___
> > . \ / |\ |\ \
> > . _\_ /__ |-\ |-\ \__
>

>
> For most networks there is almost no pain in enabling IPv6.
>

A startup vendor, formed by long time industry veterans, released brand new
products inside of the last 8 years that did not yet have IPv6 support
because their software, also created by them from scratch, did not yet
support it. It does now, but one could argue that it's mind boggling this
happened in the first place.

When experienced industry individuals decide that V6 is second class enough
to chop the feature just to get the product out the door, and bolt it on to
code later (because THAT always works out well :) ), it really makes you
wonder how many more generations of engineers will be having these same
conversations.

The money always talks. As long as solutions exist to massage V4 scarcity ,
and those solutions remain cheaper, they will generally win.

On Thu, Feb 11, 2021 at 5:07 PM Mark Andrews <marka@isc.org> wrote:

>
>
> > On 12 Feb 2021, at 08:11, Jim Shankland <nanog@shankland.org> wrote:
> >
> > On 2/11/21 6:29 AM, Owen DeLong wrote:
> >>
> >>> On Feb 11, 2021, at 05:55 , Izaac <izaac@setec.org> wrote:
> >>>
> >>> On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote:
> >>>> without creating partitioned networks.
> >>> Ridiculous. Why would you establish such a criteria? The defining
> >>> characteristic of rfc1918 networks is that they are partitioned.
> >>>
> >>> The ability to recognize and exploit partitions within a network,
> >>> natural or otherwise, is the measure of competence in a network
> >>> engineer.
> >>>
> >>> Stop making excuses.
> >> Ridiculous… TCP/IP was designed to be a peer to peer system where each
> endpoint was uniquely
> >> addressable whether reachable by policy or not.
> >>
> >> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete
> protocol.
> >>
> >> Stop making excuses and let’s fix the network.
> >>
> >> Owen
> >
> > TCP/IP wasn't designed; it evolved (OK, a slight exaggeration). The
> ISO-OSI protocol stack was designed. Many years ago, I taught a course on
> TCP/IP networking. The course was written by someone else, I was just being
> paid to present/teach it. Anyway, I vividly remember a slide with bullet
> points explaining why TCP/IP was a transitional technology, and would be
> rapidly phased out, replaced by the "standard", intelligently designed
> ISO-OSI stack. By the time I taught the course, I had to tell the class
> that every single statement on that slide was incorrect. In the end,
> evolution beat out intelligent design, by a country mile.
> >
> > It was probably a couple of years later -- the year definitely started
> with a 1 -- that I first heard that IPv4 was being phased out, to be
> replaced over the next couple of years by IPv6. We've been hearing it ever
> since.
> >
> > That doesn't mean that we'll be living with IPv4 forever. A peer to peer
> system where each endpoint is uniquely addressable is desirable. But in a
> world of virtual machines, load balancers, etc., the binding of an IP
> address to a particular, physical piece of hardware has long since become
> tenuous. IPv4 is evolving into a 48-bit address space for endpoints (32-bit
> host + 16-bit port). That development has extended IPv4's useful life by
> many years.
> >
> > There is pain associated with continuing to make IPv4 work. And there is
> pain associated with transitioning to IPv6. IPv6 will be adopted when the
> pain of the former path is much larger than the pain of the latter path.
> Saying "RFC-1918 is a bandaid for an obsolete protocol" is using a
> normative, rather than empirical, definition of "obsolete". In the
> empirical sense, things are obsolete when people stop using them. Tine will
> tell when that happens.
> >
> > Jim Shankland
>
> For most networks there is almost no pain in enabling IPv6. Its
> reconfigure the routers to announce IPv6 prefixes and you are done. We are
> 20+ years into IPv6 deployment. Almost everything you buy today works with
> IPv6. Even the crappy $50 home router does IPv6. 100s of millions of
> household networks have had IPv6 enabled without the owners of those
> networks needing to anything other than perhaps swap out a IPv4-only router
> to one that supports IPv6. Hell lots of those home networks are behind
> IPv6-only uplinks with the CPE router translating the legacy IPv4 to IPv6
> for transport over the IPv6-only uplink. The same happens with mobile
> phones these days. If you have a phone that was purchased in the last 10
> years, give or take, you will most probably be talking to the world over a
> IPv6-only link. Even Telstra here in Australia is transition their network
> to IPv6-only, the network in South Australia is IPv6-only with the other
> states to come. Optus here has been shipping IPv6 capable routers for the
> last several years with every new install / replacement. Optus haven’t yet
> enabled IPv6 to the home but the installed base is becoming IPv6 capable.
>
> The harder part is making sure every piece of kit works with IPv6 when you
> want to turn off IPv4 internally but even then you can put that equipment
> behind bi-directional NAT-64 boxes.
>
> You have large parts of the world actively turning off as much IPv4 as
> they can. Connections to legacy IPv4-only services are being tunnelled
> over IPv6 either by encapsulation or bi-directional protocol translation.
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>
>

On Fri, Feb 12, 2021 at 11:30 AM Tom Beecher <beecher@beecher.cc> wrote:
>>
>> For most networks there is almost no pain in enabling IPv6.
>
>
> A startup vendor, formed by long time industry veterans, released brand new products inside of the last 8 years that did not yet have IPv6 support because their software, also created by them from scratch, did not yet support it. It does now, but one could argue that it's mind boggling this happened in the first place.
>

this happens, a lot :(

> When experienced industry individuals decide that V6 is second class enough to chop the feature just to get the product out the door, and bolt it on to code later (because THAT always works out well :) ), it really makes you wonder how many more generations of engineers will be having these same conversations.
>
> The money always talks. As long as solutions exist to massage V4 scarcity , and those solutions remain cheaper, they will generally win.
>

the problem (one problem?) in the networking space is that:
"Today's network works, why should I add risk / config-pain /
customer-problems / uncertainty when there's no driving reason to do
same?"

This is almost certainly why some residential providers still don't
offer v6 (<cough>verizon</cough>) on their residential link service.
-chris