Mailing List Archive

1 2 3 4 5 6 7 8 9  View All
Re: DoD IP Space [ In reply to ]
--- sabri@cluecentral.net wrote:
From: Sabri Berisha <sabri@cluecentral.net>

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


100% agreed! Been whining about that here many times. I have been
trying to get IPv6 going for a long time, but the above stopped my
plans. One thing I mentioned recently, though, is we just got a
$BIGCUSTOMER and their requirement was we do IPv6. So keep your IPv6
deployment plans ready. In my case they said a 'we need it right now'
kind of thing. That could happen to anyone here.

scott
Re: DoD IP Space [ In reply to ]
On 2/12/21 21:56, scott wrote:

>
>
> 100% agreed!  Been whining about that here many times.  I have been
> trying to get IPv6 going for a long time, but the above stopped my
> plans.  One thing I mentioned recently, though, is we just got a
> $BIGCUSTOMER and their requirement was we do IPv6.  So keep your IPv6
> deployment plans ready.  In my case they said a 'we need it right now'
> kind of thing.  That could happen to anyone here.

How about just doing it and then asking for forgiveness later :-)?

That's what I did in 2005, but fair point, the network was only 2
routers big and in just one city :-).

Mark.
Re: DoD IP Space [ In reply to ]
On 2/12/2021 8:39 PM, Mark Tinka wrote:
> On 2/12/21 21:56, scott wrote:
>>
>> 100% agreed!  Been whining about that here many times.  I have been
>> trying to get IPv6 going for a long time, but the above stopped my
>> plans.  One thing I mentioned recently, though, is we just got a
>> $BIGCUSTOMER and their requirement was we do IPv6. So keep your IPv6
>> deployment plans ready.  In my case they said a 'we need it right
>> now' kind of thing.  That could happen to anyone here.
>
> How about just doing it and then asking for forgiveness later :-)?
>
> That's what I did in 2005, but fair point, the network was only 2
> routers big and in just one city :-).
> ----------------------------------------------------------------------------------------


I would be looking for a new job and it is a much larger network than 2
routers is a big city.  :)    Sabri Berisha was correct: "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."   What I always
heard when I bring it up and they don't want to talk about it was
"What's the business case?" They know there isn't one.

scott
RE: DoD IP Space [ In reply to ]
Apologies for the top-post to a bottom-thread; I blame Outlook.

I was going to comment that in a couple of corporate network engineering roles I've had, the lack of the business case has always been to highlight that all the things we want to reach on the Internet can be accessed by IPv4.

So the business case will be the 'killer app' or perhaps 'killer service' that's IPv6-only and that'll provide a business reason.

But chicken and egg.. who wants to run a service that's IPv6-only and miss out on such a big userbase?

What remains is sliding IPv6 in as a minimal-cost service upgrade when you lifecycle your equipment. And when it's not minimal-cost (due to perhaps, complex firewall/nat arrangements), it's still a hard ask.

I don't have the answer to this yet, but occasionally a tech-savvy executive buys-in on the need to future-proof things.

Mark.

-----Original Message-----
From: NANOG <nanog-bounces+blakjak=blakjak.net@nanog.org> On Behalf Of scott
Sent: Sunday, 14 February 2021 1:01 pm
To: nanog@nanog.org
Subject: Re: DoD IP Space


On 2/12/2021 8:39 PM, Mark Tinka wrote:
> On 2/12/21 21:56, scott wrote:
>>
>> 100% agreed! Been whining about that here many times. I have been
>> trying to get IPv6 going for a long time, but the above stopped my
>> plans. One thing I mentioned recently, though, is we just got a
>> $BIGCUSTOMER and their requirement was we do IPv6. So keep your IPv6
>> deployment plans ready. In my case they said a 'we need it right
>> now' kind of thing. That could happen to anyone here.
>
> How about just doing it and then asking for forgiveness later :-)?
>
> That's what I did in 2005, but fair point, the network was only 2
> routers big and in just one city :-).
> ----------------------------------------------------------------------
> ------------------


I would be looking for a new job and it is a much larger network than 2 routers is a big city. :) Sabri Berisha was correct: "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." What I always heard when I bring it up and they don't want to talk about it was "What's the business case?" They know there isn't one.

scott
Re: DoD IP Space [ In reply to ]
On 2/14/21 02:00, scott wrote:

>
> I would be looking for a new job and it is a much larger network than
> 2 routers is a big city.  :)    Sabri Berisha was correct: "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."   What I always heard when I bring it up and they don't want
> to talk about it was "What's the business case?" They know there isn't
> one.

You've just answered yourself, which is the sad (but true) reality.

It will always come down to numbers, especially if you need to expend
money on kit or use limited human resources that are already tied up
with money-making projects.

If you can show that further delaying IPv6 deployment will have a direct
impact on loss of revenue (particularly in the immediate), then you'll
have a better chance of getting the deployment approved. The problem is
any relationship between IPv6 and the going concern of the business is
most likely to be indirect, which will make your task even that much harder.

Perhaps appealing to your management's sense of "something else", that
when combined with (loss of) revenue, gives them a minute to pause and
think. I wouldn't know what that "something else" as it pertains to your
specific business, but maybe you do.

Mark.
Re: DoD IP Space [ In reply to ]
On 2/14/21 04:24, Mark Foster wrote:

> So the business case will be the 'killer app' or perhaps 'killer service' that's IPv6-only and that'll provide a business reason.
>
> But chicken and egg.. who wants to run a service that's IPv6-only and miss out on such a big userbase?

Perhaps it's time that we made good friends with the folk accelerating
pr0n, and did a deal with them where someone's fetish was only available
over IPv6. Small enough that it does not bother their existing cash cow,
but large enough that it starts to get some notice, where eyeballs can
put pressure on their service providers to get them access.

I'm not kidding. Because sitting back and hoping "things just happen" is
kind of like throwing a switch into a building and putting the words
"IXP" outside, and hoping the right people will come knocking. We know
IXP's are obvious, but a lot of their growth comes from their operators
running around and actually getting patronage going.

IPv6 is obvious. But I think it requires a lot more non-technical agency
to get it adopted.

Mark.
Re: DoD IP Space [ In reply to ]
> Perhaps it's time that we made good friends with the folk accelerating
> pr0n, and did a deal with them where someone's fetish was only
> available over IPv6.

hint: that idea is from the late '90s. the next bright idea for what
would help ipv6 take over the internet was 3gpp. it's been a long line
of things which would make ipv6 take off. and at least ten million
messages on mailing lists such as this. and the adoption rate has
crawled up slowly; the first derivative remaining fairly flat.

of course, if you measure it at the right place, it can have steep
points. when goog tured it up for youtube, the proportion of their v6
traffic went up nicely; no surprise. but when i want to measure a real
rate of change, i like a mid-stream sample at some isps' borders or ixp,
away from eyeballs or eye candy.

if we all spent as much time deploying, or helping others deploy as
opposed to screaming at them that they must do it asap, we might get
that first derivative up a wee bit. but i fear that, at this point,
patience is what is most useful.

randy
Re: DoD IP Space [ In reply to ]
On 2/14/21 21:56, Randy Bush wrote:

> hint: that idea is from the late '90s. the next bright idea for what
> would help ipv6 take over the internet was 3gpp. it's been a long line
> of things which would make ipv6 take off. and at least ten million
> messages on mailing lists such as this. and the adoption rate has
> crawled up slowly; the first derivative remaining fairly flat.
>
> of course, if you measure it at the right place, it can have steep
> points. when goog tured it up for youtube, the proportion of their v6
> traffic went up nicely; no surprise. but when i want to measure a real
> rate of change, i like a mid-stream sample at some isps' borders or ixp,
> away from eyeballs or eye candy.
>
> if we all spent as much time deploying, or helping others deploy as
> opposed to screaming at them that they must do it asap, we might get
> that first derivative up a wee bit. but i fear that, at this point,
> patience is what is most useful.

Like I was saying to someone privately, by pr0n I really meant whatever
app or service makes the most sense at the time. It could be gaming, it
could be Clubhouse, it could a crossword puzzle. Something, anything. We
know how to build online services that ordinary people see value in.
Extending that to have it delivered mostly over IPv6 is not a huge leap,
if all sides understood that the impetus was to promote IPv6 adoption.

But yes, short of that, patience is the only hope.

Mark.
Re: DoD IP Space [ In reply to ]
----- On Feb 14, 2021, at 11:56 AM, Randy Bush randy@psg.com wrote:

Hi,

> hint: that idea is from the late '90s. the next bright idea for what
> would help ipv6 take over the internet was 3gpp. it's been a long line
> of things which would make ipv6 take off.

You are 100% Correct. Perhaps we can get Jeff Bezos to give 25% extra off
at the next Cyber Monday event to those accessing amazon.com via IPv6.

That will not only drive IPv6 deployment at eyeball networks, it's a
feasible plan as well. IF good ol' Jeff wants to cooperate :)

Thanks,

Sabri
Re: DoD IP Space [ In reply to ]
On 2/14/21 22:34, Sabri Berisha wrote:

> You are 100% Correct. Perhaps we can get Jeff Bezos to give 25% extra off
> at the next Cyber Monday event to those accessing amazon.com via IPv6.
>
> That will not only drive IPv6 deployment at eyeball networks, it's a
> feasible plan as well. IF good ol' Jeff wants to cooperate :)

Dropping a few feet from cloud nine, there, really, is no other thing
that will facilitate or hold back the adoption of IPv6, like money.

It will distill down into who is willing to spend it, make it or lose it.

All (other) discussions about IPv6's adoption (or lack thereof) are just
recycled revolutions around this reality. I mean, there's a reason that
in 2021, PS4 still does not support IPv6.

Mark.
Re: DoD IP Space [ In reply to ]
On Sun, Feb 14, 2021 at 8:27 PM Mark Tinka <mark@tinka.africa> wrote:
> Dropping a few feet from cloud nine, there, really, is no other thing
> that will facilitate or hold back the adoption of IPv6, like money.

Well actually, that's not entirely true. One thing holding back IPv6
is the unfortunately routine need to turn it off in order to get one
or another IPv4 thing back working again. Like the disney thing
earlier in this thread. Or like my experience yesterday where I had to
disable IPv6 to fetch files on a particular server because SLAAC was
serving up invalid addresses but the app insisted on trying all 8 IPv6
addresses before it would attempt any of the IPv4 addresses. And of
course I can't call my ISP and say: you're causing my Linux box to
pick up bad IPv6 addresses. Front line support can barely handle IPv4
and Windows.

I stuck with it for a couple hours and figured out how to disable
SLAAC without disabling DHCP-PD so that I could turn IPv6 back on with
addresses which worked. But really, how many people are going to do
that? Most tick the IPv6 checkbox to off and are done with it.

This particular problem could be quickly resolved if the OSes still
getting updates were updated to default name resolution to prioritize
the IPv4 addresses instead. That would allow broken IPv6
configurations to exist without breaking the user's entire Internet
experience. Which would allow them to leave it turned on so that it
resumes working when the error is eventually found and fixed.

Prioritizing IPv6 over IPv4 for newly initiated connections is one of
the trifecta of critical design errors that have been killing IPv6 for
two decades. One of the two that if key folks weren't being so
bull-headed about it, it would be trivial to fix.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: DoD IP Space [ In reply to ]
On 2/15/21 08:25, William Herrin wrote:

> Well actually, that's not entirely true. One thing holding back IPv6
> is the unfortunately routine need to turn it off in order to get one
> or another IPv4 thing back working again. Like the disney thing
> earlier in this thread. Or like my experience yesterday where I had to
> disable IPv6 to fetch files on a particular server because SLAAC was
> serving up invalid addresses but the app insisted on trying all 8 IPv6
> addresses before it would attempt any of the IPv4 addresses. And of
> course I can't call my ISP and say: you're causing my Linux box to
> pick up bad IPv6 addresses. Front line support can barely handle IPv4
> and Windows.
>
> I stuck with it for a couple hours and figured out how to disable
> SLAAC without disabling DHCP-PD so that I could turn IPv6 back on with
> addresses which worked. But really, how many people are going to do
> that? Most tick the IPv6 checkbox to off and are done with it.
>
> This particular problem could be quickly resolved if the OSes still
> getting updates were updated to default name resolution to prioritize
> the IPv4 addresses instead. That would allow broken IPv6
> configurations to exist without breaking the user's entire Internet
> experience. Which would allow them to leave it turned on so that it
> resumes working when the error is eventually found and fixed.
>
> Prioritizing IPv6 over IPv4 for newly initiated connections is one of
> the trifecta of critical design errors that have been killing IPv6 for
> two decades. One of the two that if key folks weren't being so
> bull-headed about it, it would be trivial to fix.

This is not unique to IPv6. Almost every protocol (including IPv4) has
some inherent design problem that keeps lists like this alive with
swaths of advice and solutions.

But at its core, if money is going to stand in the way of IPv6 gaining
global interest, the issues you, me and others face with SLAAC and other
technical IPv6 annoyances will never receive the attention they need to
get resolved.

Why fix something nobody wants to use in the first place?

Mark.
Re: DoD IP Space [ In reply to ]
> On 15 Feb 2021, at 17:25, William Herrin <bill@herrin.us> wrote:
>
> On Sun, Feb 14, 2021 at 8:27 PM Mark Tinka <mark@tinka.africa> wrote:
>> Dropping a few feet from cloud nine, there, really, is no other thing
>> that will facilitate or hold back the adoption of IPv6, like money.
>
> Well actually, that's not entirely true. One thing holding back IPv6
> is the unfortunately routine need to turn it off in order to get one
> or another IPv4 thing back working again. Like the disney thing
> earlier in this thread. Or like my experience yesterday where I had to
> disable IPv6 to fetch files on a particular server because SLAAC was
> serving up invalid addresses but the app insisted on trying all 8 IPv6
> addresses before it would attempt any of the IPv4 addresses. And of
> course I can't call my ISP and say: you're causing my Linux box to
> pick up bad IPv6 addresses. Front line support can barely handle IPv4
> and Windows.
>
> I stuck with it for a couple hours and figured out how to disable
> SLAAC without disabling DHCP-PD so that I could turn IPv6 back on with
> addresses which worked. But really, how many people are going to do
> that? Most tick the IPv6 checkbox to off and are done with it.
>
> This particular problem could be quickly resolved if the OSes still
> getting updates were updated to default name resolution to prioritize
> the IPv4 addresses instead. That would allow broken IPv6
> configurations to exist without breaking the user's entire Internet
> experience. Which would allow them to leave it turned on so that it
> resumes working when the error is eventually found and fixed.
>
> Prioritizing IPv6 over IPv4 for newly initiated connections is one of
> the trifecta of critical design errors that have been killing IPv6 for
> two decades. One of the two that if key folks weren't being so
> bull-headed about it, it would be trivial to fix.

Complain to your vendors about not implementing RFC 8305, RFC 6724, and
RFC 7078. RFC 8305 or RFC6724 + RFC 7078 would fix your issue.

Thats Happy Eyeballs and tuneable address selection rules.

You don’t have to perform the naive connection from getaddrinfo() man page.

struct addrinfo hints, *res, *res0;
int error;
int s;
const char *cause = NULL;

memset(&hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo("www.kame.net", "http", &hints, &res0);
if (error) {
errx(1, "%s", gai_strerror(error));
/*NOTREACHED*/
}
s = -1;
for (res = res0; res; res = res->ai_next) {
s = socket(res->ai_family, res->ai_socktype,
res->ai_protocol);
if (s < 0) {
cause = "socket";
continue;
}

if (connect(s, res->ai_addr, res->ai_addrlen) < 0) {
cause = "connect";
close(s);
s = -1;
continue;
}

break; /* okay we got one */
}
if (s < 0) {
err(1, "%s", cause);
/*NOTREACHED*/
}
freeaddrinfo(res0);

You could actually use something a little more sophisticated like

int
connect_to_host(struct addrinfo *res0) {
struct addrinfo *res;
int fd = -1, n, i, j, flags, count;
struct pollfd *fds;
int timeout = TIMEOUT;

/*
* Work out how many possible descriptors we could use.
*/
for (res = res0, count = 0; res; res = res->ai_next)
count++;
fds = calloc(count, sizeof(*fds));
if (fds == NULL) {
perror("calloc");
goto cleanup;
}

for (res = res0, i = 0, count = 0; res; res = res->ai_next) {
fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
if (fd == -1) {
/*
* If AI_ADDRCONFIG is not supported we will get
* EAFNOSUPPORT returned. Behave as if the address
* was not there.
*/
if (errno != EAFNOSUPPORT)
perror("socket");
else if (res->ai_next != NULL)
continue;
} else if ((flags = fcntl(fd, F_GETFL)) == -1) {
perror("fcntl");
close(fd);
} else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
perror("fcntl");
close(fd);
} else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) {
if (errno != EINPROGRESS) {
perror("connect");
close(fd);
} else {
/*
* Record the information for this descriptor.
*/
fds[i].fd = fd;
fds[i].events = POLLERR | POLLHUP |
POLLIN | POLLOUT;
count++;
i++;
}
} else {
/*
* We connected without blocking.
*/
goto done;
}

if (count == 0)
continue;

do {
if (res->ai_next == NULL)
timeout = -1;

n = poll(fds, i, timeout);
if (n == 0) {
timeout >>= 1;
break;
}
if (n < 0) {
if (errno == EAGAIN || errno == EINTR)
continue;
perror("poll");
fd = -1;
goto done;
}
for (j = 0; j < i; j++) {
if (fds[j].fd == -1 || fds[j].events == 0 ||
fds[j].revents == 0)
continue;
fd = fds[j].fd;
if (fds[j].revents & POLLHUP) {
close(fd);
fds[j].fd = -1;
fds[j].events = 0;
count--;
continue;
}
/* Connect succeeded. */
goto done;
}
} while (timeout == -1 && count != 0);
}

/* We failed to connect. */
fd = -1;

done:
/* Close all other descriptors we have created. */
for (j = 0; j < i; j++)
if (fds[j].fd != fd && fds[j].fd != -1) {
close(fds[j].fd);
}

if (fd != -1) {
/* Restore default blocking behaviour. */
if ((flags = fcntl(fd, F_GETFL)) != -1) {
flags &= ~O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) == -1)
perror("fcntl");
} else
perror("fcntl");
}

cleanup:
/* Free everything. */
if (fds != NULL) free(fds);

return (fd);
}

See https://users.isc.org/~marka/

Mark

> Regards,
> Bill Herrin
>
> --
> William Herrin
> bill@herrin.us
> https://bill.herrin.us/

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Re: DoD IP Space [ In reply to ]
Yet both ps5 and xbox series x have ipv6 support

A console released in 2013 do not, but its successor released in 2020
have it

How wild is this, I wonder why ?

On 2/15/21 5:25 AM, Mark Tinka wrote:
> I mean, there's a reason that
> in 2021, PS4 still does not support IPv6.
>
> Mark.
Re: DoD IP Space [ In reply to ]
On Sun, Feb 14, 2021 at 11:01 PM Mark Andrews <marka@isc.org> wrote:
> Complain to your vendors about not implementing RFC 8305, RFC 6724, and
> RFC 7078. RFC 8305 or RFC6724 + RFC 7078 would fix your issue.
>
> Thats Happy Eyeballs and tuneable address selection rules.
>
> You don’t have to perform the naive connection from getaddrinfo() man page.

Hi Mark,

When I said bull-headed, this is exactly what I had in mind. Happy
eyeballs and things like
https://bill.herrin.us/freebies/libeasyv6-0.1/ aren't first-class
citizens in the APIs. Their code has to be independently added to each
application individually. Getaddrinfo() is core standard. Fix the
problem in the place that fixes it in every place or else it's never
really fixed.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: DoD IP Space [ In reply to ]
On 2/15/21 09:59, nanog@jack.fr.eu.org wrote:

> Yet both ps5 and xbox series x have ipv6 support
>
> A console released in 2013 do not, but its successor released in 2020
> have it
>
> How wild is this, I wonder why ?

IPv6 also runs on hardware that was shipped as far back as 2003, if not
earlier.

Mark.
Re: DoD IP Space [ In reply to ]
On Feb 11, 2021, at 9:01 PM, Kenneth J. Dupuis <ken@kjtd.net> wrote:
>
> 1995? https://en.m.wikipedia.org/wiki/IPv6
>
> On Feb 11, 2021 8:51 PM, Michael Thomas <mike@mtcc.com> wrote:
>
> 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
>
Back then some thought it would be more like DECnet Phase V.
Re: DoD IP Space [ In reply to ]
On 15 Feb 2021, at 2:01 AM, Mark Andrews <marka@isc.org> wrote:
> ...
> Complain to your vendors about not implementing RFC 8305, RFC 6724, and
> RFC 7078. RFC 8305 or RFC6724 + RFC 7078 would fix your issue.
>
> Thats Happy Eyeballs and tuneable address selection rules.

Mark -

You’ve properly pointed out IPv6 can indeed be readily & safely deployed today using modern equipment that supports a reasonable transition approach… full agreement there.

Interestingly enough, you’ve also pointed out the not-so-secret reason why it's taken so long to get sizable deployment of IPv6 – that is, despite us knowing that we needed "a straightforward transition plan” on day one that documented how to move from IPv4 to IPng (aka IPv6), we opted in 1995 to select a next generation protocol which lacked any meaningful transition plan and instead left that nasty transition topic as an exercise for the reader and/or addressed by postulated outputs from newly-defined working groups… thus the underlying reason for the lost decades of creative engineering efforts in gap-filling by those who came after and had to actually build working networks and applications using IPv6.

For what it’s worth, I do think we’re finally 98 or 99% of the way there, but it has resulted some very real costs - rampant industry confusion, loss of standards credibility, etc. There’s some real lessons to be had here – as one who was in the IP Directorate at the time (and thus sharing in the blame), I know I would have done quite a bit differently, but it’s unclear if there’s been any systematic look-back or institutional learning coming out of the entire experience.

FYI,
/John
Re: DoD IP Space [ In reply to ]
On Sun, 14 Feb 2021 22:25:56 -0800, William Herrin said:

> This particular problem could be quickly resolved if the OSes still
> getting updates were updated to default name resolution to prioritize
> the IPv4 addresses instead. That would allow broken IPv6
> configurations to exist without breaking the user's entire Internet
> experience. Which would allow them to leave it turned on so that it
> resumes working when the error is eventually found and fixed.

Oh, come on Bill. This ain't your first rodeo. You know damned well
that if we do that, the errors are in fact *not* eventually found and fixed.

In addition, if you do that, even once the error is fixed, the box will
not know about that and will continue to use the IPv4 addresses.
Re: DoD IP Space [ In reply to ]
On Mon, Feb 15, 2021 at 7:49 AM Valdis Kl?tnieks
<valdis.kletnieks@vt.edu> wrote:
> On Sun, 14 Feb 2021 22:25:56 -0800, William Herrin said:
> > This particular problem could be quickly resolved if the OSes still
> > getting updates were updated to default name resolution to prioritize
> > the IPv4 addresses instead. That would allow broken IPv6
> > configurations to exist without breaking the user's entire Internet
> > experience. Which would allow them to leave it turned on so that it
> > resumes working when the error is eventually found and fixed.
>
> Oh, come on Bill. This ain't your first rodeo. You know damned well
> that if we do that, the errors are in fact *not* eventually found and fixed.

I don't know that and neither do you. That remains an untested theory.
What I do know, with the perfection of 20/20 hindsight, is that
v6-first has impeded deployment for two decades by routinely giving
folks a reason to turn IPv6 back off.

Hard headed.

Regards,
Bill Herrin




--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: DoD IP Space [ In reply to ]
LOL! Well, Mike says “definitely at least 1993”, whereas Wikipedia itself says that Wikipedia cannot be trusted. Mike, to my knowledge, has never admitted being wrong. So I’m going with Mike :)

I think it was Al Gore who first proposed IPv6, right Mike? :)

-mel beckman

On Feb 15, 2021, at 6:36 AM, Kenneth J. Dupuis <ken@kjtd.net> wrote:

?
1995? https://en.m.wikipedia.org/wiki/IPv6

On Feb 11, 2021 8:51 PM, Michael Thomas <mike@mtcc.com> wrote:

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
Re: DoD IP Space [ In reply to ]
----- On Feb 15, 2021, at 9:28 AM, mel <mel@beckman.org> wrote:

Hi,

> LOL! Well, Mike says “definitely at least 1993”, whereas Wikipedia itself says
> that Wikipedia cannot be trusted. Mike, to my knowledge, has never admitted
> being wrong. So I’m going with Mike :)

Well, considering this RIPE article that talked about IPv7 already..

https://lists.ripe.net/pipermail/ripe-org-closed/1993/msg00024.html

I'd say: myth plausible.

> I think it was Al Gore who first proposed IPv6, right Mike? :)

Myth busted. He invented the internet. IPv6 was invented by his intern.

Thanks,

Sabri
Re: DoD IP Space [ In reply to ]
Actually John - IPng started out being called IPv7, but we caught the
mistake and renamed it IPv6.  Whew :-)

Geoff


On 2/15/21 8:33 AM, John Curran wrote:
> On 15 Feb 2021, at 2:01 AM, Mark Andrews <marka@isc.org
> <mailto:marka@isc.org>> wrote:
>> ...
>> Complain to your vendors about not implementing RFC 8305, RFC 6724, and
>> RFC 7078.  RFC 8305 or RFC6724 + RFC 7078 would fix your issue.
>>
>> Thats Happy Eyeballs and tuneable address selection rules.
>
> Mark -
>
> You’ve properly pointed out IPv6 can indeed be readily & safely
> deployed today using modern equipment that supports a reasonable
> transition approach… full agreement there.
>
> Interestingly enough, you’ve also pointed out the not-so-secret reason
> why it's taken so long to get sizable deployment of IPv6 – that is,
> despite us knowing that we needed "a straightforward transition plan”
> on day one that documented how to move from IPv4 to IPng (aka IPv6),
> we opted in 1995 to select a next generation protocol which lacked any
> meaningful transition plan and instead left that nasty transition
> topic as an exercise for the reader and/or addressed by postulated
> outputs from newly-defined working groups…  thus the underlying reason
> for the lost decades of creative engineering efforts in gap-filling by
> those who came after and had to actually build working networks and
> applications using IPv6.
>
> For what it’s worth, I do think we’re finally 98 or 99% of the way
> there, but it has resulted some very real costs - rampant industry
> confusion, loss of standards credibility, etc.  There’s some real
> lessons to be had here – as one who was in the IP Directorate at the
> time (and thus sharing in the blame), I know I would have done quite a
> bit differently, but it’s unclear if there’s been any systematic
> look-back or institutional learning coming out of the entire experience.
>
> FYI,
> /John
>
>
Re: DoD IP Space [ In reply to ]
On Mon, 15 Feb 2021 10:51:51 -0800, Sabri Berisha said:

> Well, considering this RIPE article that talked about IPv7 already..
>
> https://lists.ripe.net/pipermail/ripe-org-closed/1993/msg00024.html

Bonus points for those who remember/know where v5 and v8 were from :)
Re: DoD IP Space [ In reply to ]
It’s Dead, Jim — Speaking of V8. I’m glad Outlook had a Delete button.

> On Feb 15, 2021, at 3:39 PM, Valdis Kl?tnieks <valdis.kletnieks@vt.edu> wrote:
>
> On Mon, 15 Feb 2021 10:51:51 -0800, Sabri Berisha said:
>
>> Well, considering this RIPE article that talked about IPv7 already..
>>
>> https://lists.ripe.net/pipermail/ripe-org-closed/1993/msg00024.html
>
> Bonus points for those who remember/know where v5 and v8 were from :)

1 2 3 4 5 6 7 8 9  View All