Mailing List Archive

Hi,

On lun. 4 nov. 10:55:47 2019, Chris Knipe wrote:
> Hi Guys,
>
> Except for the email on ARIN's details, does anyone else have a contact for
> the DoD?
>
> We are experiencing a situation with a 3rd party (direct peer), wanting to
> advertise DoD address space to us, and we need to confirm whether they are
> allowed to do so or not.
>
> Range in question is the 22.0.0.0/8 network, which according to ARIN is
> actively assigned to the DoD (US).

There is no route inside this /8:
bird> show route primary where net ~ [ 22.0.0.0/8+ ]
bird>

Regards,
--
Alarig

maybe a typo, start from 23/8 not 22/8

________________________________
From: NANOG <nanog-bounces@nanog.org> on behalf of Chris Knipe <savage@savage.za.org>
Sent: Monday, November 4, 2019 4:55:47 PM
To: nanog list <nanog@nanog.org>
Subject: DoD IP Space

Hi Guys,

Except for the email on ARIN's details, does anyone else have a contact for the DoD?

We are experiencing a situation with a 3rd party (direct peer), wanting to advertise DoD address space to us, and we need to confirm whether they are allowed to do so or not.

Range in question is the 22.0.0.0/8<http://22.0.0.0/8> network, which according to ARIN is actively assigned to the DoD (US).

--

Regards,
Chris Knipe

On Mon, Nov 4, 2019 at 11:20 AM Alarig Le Lay <alarig@swordarmor.fr> wrote:

>
> There is no route inside this /8:
> bird> show route primary where net ~ [ 22.0.0.0/8+ ]
> bird>
>
> Regards,
> --
> Alarig
>


I know that much - but just because it's not advertised, doesn't mean
you're allowed to use it?

It's not a typo either - the net in question is 22/8 -
https://whois.arin.net/rest/net/NET-22-0-0-0-1/pft?s=22.0.0.0%2F8

It's directly assigned space, I can't find any reference anywhere about
subnets within that space that has been re-assigned, or that is in use by
anyone else.

--

Regards,
Chris Knipe

On 04/11/2019 10:23, Chris Knipe wrote:
> I know that much - but just because it's not advertised, doesn't mean
> you're allowed to use it?  

It means that you’re not supposed to advertise it to your peers, at least.

The usage of public-but-not-used space inside networks isn’t really my
problem as long as it’s not mine (and I never did something like this).

--
Alarig

On Mon, Nov 04, 2019 at 10:55:47AM +0200,
Chris Knipe <savage@savage.za.org> wrote
a message of 35 lines which said:

> We are experiencing a situation with a 3rd party (direct peer),
> wanting to advertise DoD address space to us, and we need to confirm
> whether they are allowed to do so or not.

The US military lacks money and sold parts of 22/8, like the radio
amateurs? :-) Apparently, no part of it ever appeared on the Internet.

22/8 is actively used by DoD, just not publicly. It would be in your best
interest to not accept routes for it.

if you need something more official, contact the DoD NIC directly at the
email address specified in WHOIS.

On Mon, Nov 4, 2019 at 3:32 AM Stephane Bortzmeyer <bortzmeyer@nic.fr>
wrote:

> On Mon, Nov 04, 2019 at 10:55:47AM +0200,
> Chris Knipe <savage@savage.za.org> wrote
> a message of 35 lines which said:
>
> > We are experiencing a situation with a 3rd party (direct peer),
> > wanting to advertise DoD address space to us, and we need to confirm
> > whether they are allowed to do so or not.
>
> The US military lacks money and sold parts of 22/8, like the radio
> amateurs? :-) Apparently, no part of it ever appeared on the Internet.
>


--
Jason

On Mon, Nov 4, 2019 at 3:13 PM Jason Biel <jason@biel-tech.com> wrote:

> 22/8 is actively used by DoD, just not publicly. It would be in your best
> interest to not accept routes for it.
>
> if you need something more official, contact the DoD NIC directly at the
> email address specified in WHOIS.
>
>
Precisely what I was afraid off. I have contacted the DoD NIC, am waiting
for a response from them.

Thank you Jason,

Chris.

On 2019-11-04 13:33, Chris Knipe wrote:
> On Mon, Nov 4, 2019 at 3:13 PM Jason Biel <jason@biel-tech.com> wrote:
>
>> 22/8 is actively used by DoD, just not publicly. It would be in your
>> best interest to not accept routes for it.
>>
>> if you need something more official, contact the DoD NIC directly at
>> the email address specified in WHOIS.
>
> Precisely what I was afraid off. I have contacted the DoD NIC, am
> waiting for a response from them.
>
> Thank you Jason,
>
> Chris.

On the off chance that they read this thread, I'm curious if they are
aware of 7.7.7.0/24.

https://stat.ripe.net/7.7.7.0%2F24#tabId=routing

Rob

Yeah, check with the DoD NIC 100% of the time. Probably a pretty safe bet
that unless they are a US government agency, they're not authorized.

For anyone who did not attend NANOG last week, representatives from NCIS
and the FBI reminded the audience in no uncertain terms that "industry
standard squat space" does not exist. If you're 'borrowing' DoD space, hope
you don't get caught doing so. :)

On Mon, Nov 4, 2019 at 8:35 AM Chris Knipe <savage@savage.za.org> wrote:

>
>
> On Mon, Nov 4, 2019 at 3:13 PM Jason Biel <jason@biel-tech.com> wrote:
>
>> 22/8 is actively used by DoD, just not publicly. It would be in your best
>> interest to not accept routes for it.
>>
>> if you need something more official, contact the DoD NIC directly at the
>> email address specified in WHOIS.
>>
>>
> Precisely what I was afraid off. I have contacted the DoD NIC, am waiting
> for a response from them.
>
> Thank you Jason,
>
> Chris.
>
>

On Mon, Nov 04, 2019 at 10:55:47AM +0200, Chris Knipe wrote:
> Hi Guys,
>
> Except for the email on ARIN's details, does anyone else have a contact for
> the DoD?
>
> We are experiencing a situation with a 3rd party (direct peer), wanting to
> advertise DoD address space to us, and we need to confirm whether they are
> allowed to do so or not.

A signed ROA would be strong attestation. Anything else is
suspect.

> Range in question is the 22.0.0.0/8 network, which according to ARIN is
> actively assigned to the DoD (US).

Of timely reference was this presentation from last Monday
by some USG folks who have a keen interest in address
hijacking. Unfortunatelky not recorded, but slide 11 has
some interested parties and points of contact.

https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf

Cheers,

Joe

--
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling

Hi Everyone,

Thank you very much for all the information, suggestions, and feedback.

We have been contacted by the NCIS now, and will be discussing the matter
further with them.

I don't think I'm comfortable, or feel it is justified, to discuss this
matter further publicly. I now find myself in the absolute last situation
where I wanted to be in.

Regards,
Chris.


On Mon, Nov 4, 2019 at 4:44 PM Joe Provo <nanog-post@rsuc.gweep.net> wrote:

> On Mon, Nov 04, 2019 at 10:55:47AM +0200, Chris Knipe wrote:
> > Hi Guys,
> >
> > Except for the email on ARIN's details, does anyone else have a contact
> for
> > the DoD?
> >
> > We are experiencing a situation with a 3rd party (direct peer), wanting
> to
> > advertise DoD address space to us, and we need to confirm whether they
> are
> > allowed to do so or not.
>
> A signed ROA would be strong attestation. Anything else is
> suspect.
>
> > Range in question is the 22.0.0.0/8 network, which according to ARIN is
> > actively assigned to the DoD (US).
>
> Of timely reference was this presentation from last Monday
> by some USG folks who have a keen interest in address
> hijacking. Unfortunatelky not recorded, but slide 11 has
> some interested parties and points of contact.
>
>
> https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf
>
> Cheers,
>
> Joe
>
> --
> Posted from my personal account - see X-Disclaimer header.
> Joe Provo / Gweep / Earthling
>


--

Regards,
Chris Knipe

On 11/4/19 1:55 AM, Chris Knipe wrote:
> We are experiencing a situation with a 3rd party (direct peer), wanting
> to advertise DoD address space to us, and we need to confirm whether
> they are allowed to do so or not.

That sounds like someone is squatting on DoD IP space, likely for
something like CGN and (hopefully inadvertently) wanting to advertise it
to you.

This thread got me to wondering, is there any legitimate reason to see
22/8 on the public Internet? Or would it be okay to treat 22/8 like a
Bogon and drop it at the network edge?



--
Grant. . . .
unix || die

On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG <nanog@nanog.org> wrote:
> This thread got me to wondering, is there any legitimate reason to see 22/8 on the public Internet? Or would it be okay to treat 22/8 like a Bogon and drop it at the network edge?

Given the transfer market for IPv4 addresses, the spot price for IPv4 addresses, and the need of even governments to find “free” (as in unconstrained) money, I’d think treating any legacy /8 as a bogon would not be prudent.

Regards,
-drc

Peace,

On Tue, Nov 5, 2019, 4:55 PM David Conrad <drc@virtualized.org> wrote:
> On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG <nanog@nanog.org> wrote:
>> This thread got me to wondering, is there any
>> legitimate reason to see 22/8 on the public
>> Internet? Or would it be okay to treat 22/8
>> like a Bogon and drop it at the network edge?
>
> Given the transfer market for IPv4 addresses,
> the spot price for IPv4 addresses, and the need
> of even governments to find “free” (as in
> unconstrained) money, I’d think treating any
> legacy /8 as a bogon would not be prudent.

It has been said before in this thread that the DoD actively uses this
network internally. I believe if the DoD were to cut costs, they
would be able to do it much more effectively in many other areas, and
their IPv4 networks would be about the last thing they would think of
(along with switching off ACs Bernard Ebbers-style). With that in
mind, treating the DoD networks as bogons now makes total sense to me.

--
Töma

Using the generally accepted definition of a bogon ( RFC 1918 / 5735 /
6598 + netblock not allocated by an RiR ), 22/8 is not a bogon and
shouldn't be treated as one.

The DoD does not announce it to the DFZ, as is their choice, but nothing
says they may not change that position tomorrow. There are plenty of
subnets out there that are properly allocated by an RiR, but the assignees
do not send them to the DFZ because of $reasons.

In my opinion, creating bogon lists that include allocated but not
advertised prefixes is poor practice that is likely to end up biting an
operator at one point or another.

On Tue, Nov 5, 2019 at 9:45 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:

> Peace,
>
> On Tue, Nov 5, 2019, 4:55 PM David Conrad <drc@virtualized.org> wrote:
> > On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG <nanog@nanog.org>
> wrote:
> >> This thread got me to wondering, is there any
> >> legitimate reason to see 22/8 on the public
> >> Internet? Or would it be okay to treat 22/8
> >> like a Bogon and drop it at the network edge?
> >
> > Given the transfer market for IPv4 addresses,
> > the spot price for IPv4 addresses, and the need
> > of even governments to find “free” (as in
> > unconstrained) money, I’d think treating any
> > legacy /8 as a bogon would not be prudent.
>
> It has been said before in this thread that the DoD actively uses this
> network internally. I believe if the DoD were to cut costs, they
> would be able to do it much more effectively in many other areas, and
> their IPv4 networks would be about the last thing they would think of
> (along with switching off ACs Bernard Ebbers-style). With that in
> mind, treating the DoD networks as bogons now makes total sense to me.
>
> --
> Töma
>

Tom –

Most definitely: lack of routing history is not at all a reliable indicator of the potential for valid routing of a given IPv4 block in the future, so best practice suggest that allocated address space should not be blocked by others without specific cause.

Doing otherwise opens one up to unexpected surprises when issued space suddenly becomes more active in routing and is yet is inexplicably unreachable for some destinations.

/John

> On Nov 5, 2019, at 10:38 AM, Tom Beecher <beecher@beecher.cc> wrote:
>
>
> Using the generally accepted definition of a bogon ( RFC 1918 / 5735 / 6598 + netblock not allocated by an RiR ), 22/8 is not a bogon and shouldn't be treated as one.
>
> The DoD does not announce it to the DFZ, as is their choice, but nothing says they may not change that position tomorrow. There are plenty of subnets out there that are properly allocated by an RiR, but the assignees do not send them to the DFZ because of $reasons.
>
> In my opinion, creating bogon lists that include allocated but not advertised prefixes is poor practice that is likely to end up biting an operator at one point or another.
>
>> On Tue, Nov 5, 2019 at 9:45 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:
>> Peace,
>>
>> On Tue, Nov 5, 2019, 4:55 PM David Conrad <drc@virtualized.org> wrote:
>> > On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG <nanog@nanog.org> wrote:
>> >> This thread got me to wondering, is there any
>> >> legitimate reason to see 22/8 on the public
>> >> Internet? Or would it be okay to treat 22/8
>> >> like a Bogon and drop it at the network edge?
>> >
>> > Given the transfer market for IPv4 addresses,
>> > the spot price for IPv4 addresses, and the need
>> > of even governments to find “free” (as in
>> > unconstrained) money, I’d think treating any
>> > legacy /8 as a bogon would not be prudent.
>>
>> It has been said before in this thread that the DoD actively uses this
>> network internally. I believe if the DoD were to cut costs, they
>> would be able to do it much more effectively in many other areas, and
>> their IPv4 networks would be about the last thing they would think of
>> (along with switching off ACs Bernard Ebbers-style). With that in
>> mind, treating the DoD networks as bogons now makes total sense to me.
>>
>> --
>> Töma

I believe the DoD space might be a bit of a difficult one, because (correct
me if I am wrong here) due to it being so massive and unused for so long,
certain large corporations that have run out of RFC1918, etc. space
have started using it internally.

So my take on it is, don't consider it as a bogon from your upstreams, but
maybe have some questions if your downstream is attempting to announce it
as they are somewhat unlikely to be the DoD.
But if you do this, make sure you keep track of where you might have put
policies like this in, in case the DoD sells some the space or whatever in
the future.

-Cynthia


On Wed, Jan 20, 2021 at 2:39 PM John Curran <jcurran@istaff.org> wrote:

> Tom –
>
> Most definitely: lack of routing history is not at all a reliable
> indicator of the potential for valid routing of a given IPv4 block in the
> future, so best practice suggest that allocated address space should not be
> blocked by others without specific cause.
>
> Doing otherwise opens one up to unexpected surprises when issued space
> suddenly becomes more active in routing and is yet is inexplicably
> unreachable for some destinations.
>
> /John
>
> On Nov 5, 2019, at 10:38 AM, Tom Beecher <beecher@beecher.cc> wrote:
>
>
> Using the generally accepted definition of a bogon ( RFC 1918 / 5735 /
> 6598 + netblock not allocated by an RiR ), 22/8 is not a bogon and
> shouldn't be treated as one.
>
> The DoD does not announce it to the DFZ, as is their choice, but nothing
> says they may not change that position tomorrow. There are plenty of
> subnets out there that are properly allocated by an RiR, but the assignees
> do not send them to the DFZ because of $reasons.
>
> In my opinion, creating bogon lists that include allocated but not
> advertised prefixes is poor practice that is likely to end up biting an
> operator at one point or another.
>
> On Tue, Nov 5, 2019 at 9:45 AM Töma Gavrichenkov <ximaera@gmail.com>
> wrote:
>
>> Peace,
>>
>> On Tue, Nov 5, 2019, 4:55 PM David Conrad <drc@virtualized.org> wrote:
>> > On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG <nanog@nanog.org>
>> wrote:
>> >> This thread got me to wondering, is there any
>> >> legitimate reason to see 22/8 on the public
>> >> Internet? Or would it be okay to treat 22/8
>> >> like a Bogon and drop it at the network edge?
>> >
>> > Given the transfer market for IPv4 addresses,
>> > the spot price for IPv4 addresses, and the need
>> > of even governments to find “free” (as in
>> > unconstrained) money, I’d think treating any
>> > legacy /8 as a bogon would not be prudent.
>>
>> It has been said before in this thread that the DoD actively uses this
>> network internally. I believe if the DoD were to cut costs, they
>> would be able to do it much more effectively in many other areas, and
>> their IPv4 networks would be about the last thing they would think of
>> (along with switching off ACs Bernard Ebbers-style). With that in
>> mind, treating the DoD networks as bogons now makes total sense to me.
>>
>> --
>> Töma
>>
>

Indeed.
/John

> On Jan 20, 2021, at 8:47 AM, Cynthia Revström <me@cynthia.re> wrote:
>
> But if you do this, make sure you keep track of where you might have put policies like this in, in case the DoD sells some the space or whatever in the future.

My question becomes, what level of risk are these companies taking on by
using the DoD ranges on their internal networks? And have they
quantified the costs of this outage against moving to IPv6?

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 Wed, Jan 20, 2021 at 9:06 AM John Curran <jcurran@istaff.org> wrote:

> Indeed.
> /John
>
> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström <me@cynthia.re> wrote:
> >
> > But if you do this, make sure you keep track of where you might have put
> policies like this in, in case the DoD sells some the space or whatever in
> the future.
>
>

I am aware of some companies that have used parts of a DoD /8 internally to
address devices in the field that are too old to ever support IPV6. Those
devices also never interact with the public internet, and never will, so
for them, I guess the only risk would be that some other internal system
that wants to talk to those devices would not also be able to talk to any
endpoint on the public internet that wound up using space allocated from
that block, some time in the future. Is that about right or am I missing
some key failure point?

On Wed, Jan 20, 2021 at 9:59 AM j k <jsklein@gmail.com> wrote:

> My question becomes, what level of risk are these companies taking on by
> using the DoD ranges on their internal networks? And have they
> quantified the costs of this outage against moving to IPv6?
>
> 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 Wed, Jan 20, 2021 at 9:06 AM John Curran <jcurran@istaff.org> wrote:
>
>> Indeed.
>> /John
>>
>> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström <me@cynthia.re> wrote:
>> >
>> > But if you do this, make sure you keep track of where you might have
>> put policies like this in, in case the DoD sells some the space or whatever
>> in the future.
>>
>>

On 1/20/21 9:58 AM, j k wrote:
> My question becomes, what level of risk are these companies taking on by
> using the DoD ranges on their internal networks? And have they
> quantified the costs of this outage against moving to IPv6?

Honestly I can't think of much unless maybe they're a defense contractor
that would potentially end up with DoD ranges (non-isolated/classified
networks) in their view of the global routing table. Appropriately
treating it like "my networks" and/or RFC1918 in your routing policies
(not exporting it, not accepting routes for it, etc.) would be required
to properly ensure network stability of course.

Some OSes treat RFC1918 space as inherently "special" (extra trusted,
etc.) and wouldn't treat the DoD ranges as such, but those behaviors are
typically undesirable or at least not relied on on a network of that
scale, anyway.

Not that I'd recommend it.
--
Brandon Martin

Yeah, definitely talking about use that is deep behind multiple layers of
firewalls, or maybe even air-gapped with respect to routable protocols. I
won't say what sort of industry runs large piles of ancient gear, but you
could probably guess...

On Wed, Jan 20, 2021 at 10:13 AM Brandon Martin <lists.nanog@monmotha.net>
wrote:

> On 1/20/21 9:58 AM, j k wrote:
> > My question becomes, what level of risk are these companies taking on by
> > using the DoD ranges on their internal networks? And have they
> > quantified the costs of this outage against moving to IPv6?
>
> Honestly I can't think of much unless maybe they're a defense contractor
> that would potentially end up with DoD ranges (non-isolated/classified
> networks) in their view of the global routing table. Appropriately
> treating it like "my networks" and/or RFC1918 in your routing policies
> (not exporting it, not accepting routes for it, etc.) would be required
> to properly ensure network stability of course.
>
> Some OSes treat RFC1918 space as inherently "special" (extra trusted,
> etc.) and wouldn't treat the DoD ranges as such, but those behaviors are
> typically undesirable or at least not relied on on a network of that
> scale, anyway.
>
> Not that I'd recommend it.
> --
> Brandon Martin
>

I recently had a discussion with an Asian ISP that was asking the IETF to PLEASE re-declare DoD space to be private space so that they could use it. This particular ISP uses IPv6 extensively (a lot of their services are in fact IPv6-only) but has trouble with its enterprise customers. Frankly, enterprise use of IPv6 is a problem; they seem to push back pretty hard against using IPv6.

I find this thread highly appropriate.

> On Jan 20, 2021, at 6:58 AM, j k <jsklein@gmail.com> wrote:
>
> My question becomes, what level of risk are these companies taking on by using the DoD ranges on their internal networks? And have they quantified the costs of this outage against moving to IPv6?
>
> 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 Wed, Jan 20, 2021 at 9:06 AM John Curran <jcurran@istaff.org> wrote:
> Indeed.
> /John
>
> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström <me@cynthia.re> wrote:
> >
> > But if you do this, make sure you keep track of where you might have put policies like this in, in case the DoD sells some the space or whatever in the future.
>

On 1/20/21 10:05 AM, Dorn Hetzel wrote:
> I am aware of some companies that have used parts of a DoD /8 internally to
> address devices in the field that are too old to ever support IPV6. Those
> devices also never interact with the public internet, and never will, so
> for them, I guess the only risk would be that some other internal system
> that wants to talk to those devices would not also be able to talk to any
> endpoint on the public internet that wound up using space allocated from
> that block, some time in the future. Is that about right or am I missing
> some key failure point?

You're free to use any IP space you want internally, no one is going to tell
you what to do inside your network. Most providers will not route it for you
though. There are some exceptions to this, the GRX being one, but that's it's
own VPN and separate network from the global Internet. IIRC, here was some
VPN provider using 5/8 before that was assigned.

AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
network.
--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

On 20 Jan 2021, at 12:17 PM, Bryan Fields <Bryan@bryanfields.net<mailto:Bryan@bryanfields.net>> wrote:

AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
network.

<chuckle> While route hijacking isn't necessarily an ARIN issue, I will note that several US law enforcement agencies (FBI & NCIS Cybercrime units) are quite interested in such events and do investigate them looking for criminal activity.

(See https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf for details.)

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers

On 1/20/21 12:52 PM, John Curran wrote:
>
> <chuckle>  While route hijacking isn't necessarily an ARIN issue, I will note that several US law enforcement agencies (FBI & NCIS Cybercrime units) are quite interested in such events and do investigate them looking for criminal activity.   
>
> (See https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf for details.) 
>

I think the difference is semantic but a very important one nonetheless.

Announcing a netblock that isn't yours and that you don't have authorization to use to others under the same terms and assumptions as you announce those to which you do hold legitimate rights or otherwise purporting to be a legitimate user of them on what we know as the "public Internet", that is the Internet where numbers are managed by IANA and the relevant RIRs is a "big deal".

Using numbers in a manner contrary to how they are assigned on the "public Internet" within a more limited scope where everybody agrees that the use of such numbers may be contrary to IANA and relevant RIR assignments is more along the lines of "you operate your network however you want".

Other things would fall under the same purview. For example "alternate root" DNS hierarchies with extra TLDs or even TLDs used in contrast to ICANN recommendations would have similar considerations.
--
Brandon Martin

Brandon -

Agreed – the key phrase being "within a more limited scope” …

/John

> On 20 Jan 2021, at 1:26 PM, Brandon Martin <lists.nanog@monmotha.net> wrote:
>
> On 1/20/21 12:52 PM, John Curran wrote:
>>
>> <chuckle> While route hijacking isn't necessarily an ARIN issue, I will note that several US law enforcement agencies (FBI & NCIS Cybercrime units) are quite interested in such events and do investigate them looking for criminal activity.
>>
>> (See https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf for details.)
>>
>
> I think the difference is semantic but a very important one nonetheless.
>
> Announcing a netblock that isn't yours and that you don't have authorization to use to others under the same terms and assumptions as you announce those to which you do hold legitimate rights or otherwise purporting to be a legitimate user of them on what we know as the "public Internet", that is the Internet where numbers are managed by IANA and the relevant RIRs is a "big deal".
>
> Using numbers in a manner contrary to how they are assigned on the "public Internet" within a more limited scope where everybody agrees that the use of such numbers may be contrary to IANA and relevant RIR assignments is more along the lines of "you operate your network however you want".
>
> Other things would fall under the same purview. For example "alternate root" DNS hierarchies with extra TLDs or even TLDs used in contrast to ICANN recommendations would have similar considerations.
> --
> Brandon Martin

> On Jan 20, 2021, at 07:11 , Brandon Martin <lists.nanog@monmotha.net> wrote:
>
> On 1/20/21 9:58 AM, j k wrote:
>> My question becomes, what level of risk are these companies taking on by using the DoD ranges on their internal networks? And have they quantified the costs of this outage against moving to IPv6?
>
> Honestly I can't think of much unless maybe they're a defense contractor that would potentially end up with DoD ranges (non-isolated/classified networks) in their view of the global routing table. Appropriately treating it like "my networks" and/or RFC1918 in your routing policies (not exporting it, not accepting routes for it, etc.) would be required to properly ensure network stability of course.

Do you think this still holds true if DoD were to (e.g.) sell that space to $CLOUD_PROVIDER or $ISP or $SUPPLIER or…?

I don’t have any knowledge of any events surrounding this space currently, but I do know that press releases and congress have discussed that possibility, so it cannot be ruled out.

Owen

On 1/20/21 1:48 PM, Owen DeLong wrote:
> Do you think this still holds true if DoD were to (e.g.) sell that space to $CLOUD_PROVIDER or $ISP or $SUPPLIER or…?
>
> I don’t have any knowledge of any events surrounding this space currently, but I do know that press releases and congress have discussed that possibility, so it cannot be ruled out.

This is a risk you take when using squad space of any form. DoD space
is somewhat uniquely "safe" in this regard but not immune to such things.

Honestly I'd be just about as worried as a potential legitimate non-DoD
public Internet user of that space about reachability issues as I would
as someone squatting on it internally within my network about it
becoming a part of the common global routing table.

I also suspect your typical large corporate environment cares less about
broad, global reachability than other Internet users in many cases.
--
Brandon Martin

> On Wednesday, January 20, 2021 13:48, Owen DeLong <...> wrote:
>
> Do you think this still holds true if DoD were to (e.g.) sell that space
> to $CLOUD_PROVIDER or $ISP or $SUPPLIER or??
>
> I don?t have any knowledge of any events surrounding this space
> currently, but I do know that press releases and congress have
> discussed that possibility, so it cannot be ruled out.

There's this old blog post from 2010: T-Mobile: Clever or Insane?

https://blog.wireshark.org/2010/04/t-mobile-clever-or-insane/

Best regards,

Jim Y.

----- On Jan 20, 2021, at 6:58 AM, j k <jsklein@gmail.com> wrote:

Hi,

> My question becomes, what level of risk are these companies taking on by using
> the DoD ranges on their internal networks? And have they quantified the costs
> of this outage against moving to IPv6?

Not so long ago, while working for a large enterprise, my team was considering
the use of non-advertised public IP space when we realized we were close to
running out of RFC1918 space. Eventually we decided against it as we had enough
options to reclaim unused RFC1918 from within the company. However, we had a
number of arguments against the use of public ranges:

- The risk of owners deciding to advertise their space. If so, since we operated
a popular ecommerce site, there would be a huge risk of users encountering
issues.
- The risk of inadvertent security issues. People using RFC1918 space, even the
most network-illiterate dev, know that RFC1918 space is not accessible from
the big bad internet. This (perceived) safety is absent when using public
IP space.
- The risk of misconfiguring firewalls. Obviously, most of the policies cover
RFC1918 space. Introducing non-RFC1918 space encourages human error.
- The risk of looking like fools if we would accidentally leak. Let's be honest.
There are two groups of people on this list. Those who have accidentally leaked
and those who will. I learned from my mistake(s).

As for IPv6: I know I sound like a broken record but one does not simply walk
into Mordor and migrate to IPv6. In a large enterprise, especially with one
using a lot of old code to support a highly popular webapp, it is easier to
move a mountain than it is to get all nosed aligned. The network group(s),
corp, lab, DC, backbone, may all be ready, but that does not mean that your
cloud, kubernetes, frontend, backend, operations, and billing groups are
ready. Migrating to IPv6 is a cost, as there is no ROI. It is a cost center,
not an investment. Surely, we all on this list know that it is a mandatory
expense to ensure future delivery of services, but explain that to a VP with
limited budgets. Are they going for the short term win of new features, or for
the long term "win" of retaining revenue? We all know what their bonuses are
based on.

And don't get me wrong. I'm not advocating against v6. I'm merely explaining how
difficult it can be to migrate. In most large companies, the network is like
PG&E (the power utility California). If it works, nobody says well done. But if
the power is out, everyone gets angry and asks why we have fools operating the
power grid.

Thanks,

Sabri

Organizations that I have seen doing as you describe, because they ran out
of RFC1918 IP space, are also often using their existing private IP space
wastefully in the first place. Rather than using DoD /8s internally, if
they absolutely need to support v4-only equipment on their internal
management networks, they might be better served by considering that maybe
every POP doesn't need its own /24.

I'm talking about things I've seen where all of the management/monitoring
IPs of the equipment at a site might fit very comfortably in a v4 /27. But
that would be a labor intensive IP space and management address auditing
process of renumbering things, fixing internal DNS and rDNS, and updating
any myriad of things that might have the direct IP addresses of stuff
hardcoded into configuration files.

Rather than doing all of the above, they simply go "hey here's a /8 that's
highly unlikely our management network will ever need to talk to it in a
global routing table", and continue on with their /24 plan per tiny POP.



On Wed, Jan 20, 2021 at 8:38 AM Dorn Hetzel <dorn@hetzel.org> wrote:

> I am aware of some companies that have used parts of a DoD /8 internally
> to address devices in the field that are too old to ever support IPV6.
> Those devices also never interact with the public internet, and never will,
> so for them, I guess the only risk would be that some other internal system
> that wants to talk to those devices would not also be able to talk to any
> endpoint on the public internet that wound up using space allocated from
> that block, some time in the future. Is that about right or am I missing
> some key failure point?
>
> On Wed, Jan 20, 2021 at 9:59 AM j k <jsklein@gmail.com> wrote:
>
>> My question becomes, what level of risk are these companies taking on by
>> using the DoD ranges on their internal networks? And have they
>> quantified the costs of this outage against moving to IPv6?
>>
>> 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 Wed, Jan 20, 2021 at 9:06 AM John Curran <jcurran@istaff.org> wrote:
>>
>>> Indeed.
>>> /John
>>>
>>> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström <me@cynthia.re> wrote:
>>> >
>>> > But if you do this, make sure you keep track of where you might have
>>> put policies like this in, in case the DoD sells some the space or whatever
>>> in the future.
>>>
>>>

Additionally, examples of impersonating a corporate entity to acquire
unused IP space (Erie Forge and Steel's /16, anyone?) undoubtedly fall
under existing, pre-internet interstate commerce fraud laws...

http://web.mit.edu/net-security/Camp/2003/DBowie_IP_Hijacking.pdf

https://www.wired.com/images_blogs/threatlevel/files/edited-iphd-2.ppt



On Wed, Jan 20, 2021 at 9:54 AM John Curran <jcurran@arin.net> wrote:

> On 20 Jan 2021, at 12:17 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
>
>
> AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
> network.
>
>
> <chuckle> While route hijacking isn't necessarily an ARIN issue, I will
> note that several US law enforcement agencies (FBI & NCIS Cybercrime units)
> are quite interested in such events and do investigate them looking for
> criminal activity.
>
> (See
> https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf for
> details.)
>
> FYI,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>

On 1/20/21 12:52 PM, John Curran wrote:
> On 20 Jan 2021, at 12:17 PM, Bryan Fields <Bryan@bryanfields.net<mailto:Bryan@bryanfields.net>> wrote:
>>
>> AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
>> network.
>
> <chuckle> While route hijacking isn't necessarily an ARIN issue, I will note that several US law enforcement agencies (FBI & NCIS Cybercrime units) are quite interested in such events and do investigate them looking for criminal activity.
>
> (See https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf for details.)

Can you ensure quoting is done properly? I don't want more confusion between
what I wrote and the reply.

Nowhere did I state this was used to be for criminal or less than above board
use. As soon as an entity decides to engage in criminal activities we're
beyond the question of what numbers they can run on their network. I can't
think of a worse entity to hijack space from than the DOD. Very few other
AS's have the ability to make it rain fire over a hijacker's NOC :-)

My comment was in terms of what a private network can do inside their own
network, or as part of a multi-entity network that is separate from the
"Internet". The bigger question is, should you do this? The answer is no for
a host of reasons, as networks rarely stay private. Even the GRX went through
a big cleanup relating to this, and as of the last 6 years (maybe more)
requires space used to be allocated via the RIR's and not RFC1918 space. IIRC
they still allow private ASN's.

--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

> And don't get me wrong. I'm not advocating against v6. I'm merely explaining how
> difficult it can be to migrate. In most large companies, the network is like
> PG&E (the power utility California). If it works, nobody says well done. But if
> the power is out, everyone gets angry and asks why we have fools operating the
> power grid.

Indeed… It will be interesting to see how these CxOs with limited budges react
when backbones finally start turning off IPv4 and they discover that their network
is burning down because of years neglecting the IPv6 brush growing all around
them.

Owen

> due to it being so massive and unused for so long, certain large
> corporations that have run out of RFC1918, etc. space have started
> using it internally.

i first saw that on a traceroute from my hotel at ripe bologna in 2001.
i was told i was loooong late to finding it.

randy

I used to help large companies rearchitect their addressing, implement
IPv6, etc. for a living, so no one is more sympathetic than I am about
how difficult it can be to make these changes. However, I have to ask,
how far backwards do we want to bend for those that refuse to migrate?

There have already been at least two lines in the sand that the IETF has
backed down from. Is it even useful for us to keep saying "IPv6 is the
way forward" any more?


On 1/20/21 7:26 AM, Fred Baker wrote:
> I recently had a discussion with an Asian ISP that was asking the IETF to PLEASE re-declare DoD space to be private space so that they could use it. This particular ISP uses IPv6 extensively (a lot of their services are in fact IPv6-only) but has trouble with its enterprise customers. Frankly, enterprise use of IPv6 is a problem; they seem to push back pretty hard against using IPv6.
>
> I find this thread highly appropriate.

It is the DISA DOD NIC at:

https://disa.mil/About/Contact

Which will give you the DISA help desk phone number.

John Lee

On Mon, Nov 4, 2019 at 3:57 AM Chris Knipe <savage@savage.za.org> wrote:

> Hi Guys,
>
> Except for the email on ARIN's details, does anyone else have a contact
> for the DoD?
>
> We are experiencing a situation with a 3rd party (direct peer), wanting to
> advertise DoD address space to us, and we need to confirm whether they are
> allowed to do so or not.
>
> Range in question is the 22.0.0.0/8 network, which according to ARIN is
> actively assigned to the DoD (US).
>
> --
>
> Regards,
> Chris Knipe
>

Oh, no worries.. It will never happen ;)
There is reason why everyone stick to IPv4...

Also, there was also nice space that could be used safely on private
networks [14.0.0.0/8]. Unfortunately money needs to flow, so it was
converted to normal space. Shame.

Same with recent shady action w/ 44.0.0.0/8 is sad as well..
IPv4 will stay with us for very long....


---------- Original message ----------

From: Owen DeLong <owen@delong.com>
To: Sabri Berisha <sabri@cluecentral.net>
Cc: nanog <nanog@nanog.org>, Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: DoD IP Space
Date: Wed, 20 Jan 2021 13:15:32 -0800

Indeed It will be interesting to see how these CxOs with limited budges
react when backbones finally start turning off IPv4 and they discover that
their network is burning down because of years neglecting the IPv6 brush
growing all around them.

Owen

Chris -

https://search.arin.net/rdap/?query=22.0.0.0 will provide a valid phone number for technical & abuse matters.

/John

John Curran
President and CEO
American Registry for Internet Numbers

On 21 Jan 2021, at 12:11 AM, John Lee <jllee9753@gmail.com<mailto:jllee9753@gmail.com>> wrote:

It is the DISA DOD NIC at:

https://disa.mil/About/Contact

Which will give you the DISA help desk phone number.

John Lee

On Mon, Nov 4, 2019 at 3:57 AM Chris Knipe <savage@savage.za.org<mailto:savage@savage.za.org>> wrote:
Hi Guys,

Except for the email on ARIN's details, does anyone else have a contact for the DoD?

We are experiencing a situation with a 3rd party (direct peer), wanting to advertise DoD address space to us, and we need to confirm whether they are allowed to do so or not.

Range in question is the 22.0.0.0/8<http://22.0.0.0/8> network, which according to ARIN is actively assigned to the DoD (US).

--

Regards,
Chris Knipe

> On Jan 20, 2021, at 11:10 PM, Doug Barton <dougb@dougbarton.us> wrote:
>
> There have already been at least two lines in the sand that the IETF has backed down from. Is it even useful for us to keep saying "IPv6 is the way forward" any more?


Oh, I could not agree more. We need IETF or other powers-that-be to stop the line-in-the-sand stuff and instead go with a line in the wet concrete.

I’m sure we all remember Y2k (well, most of us, there could be some young-uns on the list). That day was happening whether we wanted it to or not. It was an unchangeable, unmovable deadline.

THAT is what we need for IPv6 implementation. Will it happen? Probably not, sadly.

I’d love to see a line in the concrete of, say, January 1, 2025, whereby IPv6 will be the default.


----
Andy Ringsmuth
5609 Harding Drive
Lincoln, NE 68521-5831
(402) 304-0083
andy@andyring.com

“Better even die free, than to live slaves.” - Frederick Douglas, 1863

----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com wrote:

Hi,

> I’m sure we all remember Y2k

Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I upgraded many
bioses in many office buildings in the months leading up to it...

> I’d love to see a line in the concrete of, say, January 1, 2025, whereby IPv6
> will be the default.

The challenge with that is the market. Y2K was a problem that was existed. It was
a brick wall that we would hit no matter what. The faulty code was released years
before the date.

We, IETF, or even the UN could come up with 1/1/25 as the date where we switch off
IPv4, and you will still find networks that run IPv4 for the simple reason that
the people who own those networks have a choice. With Y2K there was no choice.

The best way to have IPv6 implemented worldwide is by having an incentive for the
executives that make the decisions. From experience, as I've said on this list a
few times before, I can tell you that decision makers with a limited budget that
have to choose between a new revenue generating feature, or a company-wide
implementation of IPv6, will choose the one that's best for their own short-term
interests.

On that note, I did have a perhaps silly idea: One way to create the demand could
be to have browser makers add a warning to the URL bar, similar to the HTTPS
warnings we see today. If a site is IPv4 only, warn that the site is using
deprecated technology.

Financial incentives also work. Perhaps we can convince Mr. Biden to give a .5%
tax cut to corporations that fully implement v6. That will create some bonus
targets.

Thanks,

Sabri

That's a good one. Perhaps you don't live/work in the US and can be
excused for not knowing that US corporations don't pay taxes. In many
cases we subsidize them by giving tax credits to the point that the money
is flowing in the opposite direction entirely. It would be hard to give
them any more of a break ;)

>
>
> Financial incentives also work. Perhaps we can convince Mr. Biden to give
> a .5%
> tax cut to corporations that fully implement v6. That will create some
> bonus
> targets.
>
> Thanks,
>
> Sabri
>

Organizations I have worked with for IPv6 transition, reduced CAPex and
OPex by leveraging the IT refresh cycle, and by ensuring there investment
included leveraging the USGv6 (
https://www.nist.gov/programs-projects/usgv6-program) or IPv6Ready (
https://www.ipv6ready.org/) to mitigate the "We sell IPv6 products, and
want to you to pay for the debugging costs".

Can I assume other organizations don't leverage the IT refresh cycle?

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 Thu, Jan 21, 2021 at 2:34 PM Brandon Svec <bsvec@teamonesolutions.com>
wrote:

> That's a good one. Perhaps you don't live/work in the US and can be
> excused for not knowing that US corporations don't pay taxes. In many
> cases we subsidize them by giving tax credits to the point that the money
> is flowing in the opposite direction entirely. It would be hard to give
> them any more of a break ;)
>
>>
>>
>> Financial incentives also work. Perhaps we can convince Mr. Biden to give
>> a .5%
>> tax cut to corporations that fully implement v6. That will create some
>> bonus
>> targets.
>>
>> Thanks,
>>
>> Sabri
>>
>

> I?m sure we all remember Y2k (well, most of us, there could be some
> young-uns on the list). That day was happening whether we wanted it to
> or not. It was an unchangeable, unmovable deadline.

but i thought 3gpp was gong to force ipv6 adoption

>> I?m sure we all remember Y2k (well, most of us, there could be some
>> young-uns on the list). That day was happening whether we wanted it to
>> or not. It was an unchangeable, unmovable deadline.
>
> but i thought 3gpp was gong to force ipv6 adoption

let me try it a different way

why should i care whether you deploy ipv6, move to dual stack, cgnat,
...? you will do whatever makes sense to the pointy heads in your c
suite. why should i give them or some tech religion free rent in my
mind when i already have too much real work to do?

randy

IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming.
Every data set says the same thing. It may not be coming as fast as a lot
of us would want or actually think is reasonable as ISP’s are currently
being forced to deploy CGNs (NAT44 and NAT64) because there are laggards
that are not doing their part.

If you offer a service over the Internet then it should be available over
IPv6 otherwise you are costing your customers more to reach you. CGNs are
not free.

Mark

> On 22 Jan 2021, at 06:07, Sabri Berisha <sabri@cluecentral.net> wrote:
>
> ----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com wrote:
>
> Hi,
>
>> I’m sure we all remember Y2k
>
> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I upgraded many
> bioses in many office buildings in the months leading up to it...
>
>> I’d love to see a line in the concrete of, say, January 1, 2025, whereby IPv6
>> will be the default.
>
> The challenge with that is the market. Y2K was a problem that was existed. It was
> a brick wall that we would hit no matter what. The faulty code was released years
> before the date.
>
> We, IETF, or even the UN could come up with 1/1/25 as the date where we switch off
> IPv4, and you will still find networks that run IPv4 for the simple reason that
> the people who own those networks have a choice. With Y2K there was no choice.
>
> The best way to have IPv6 implemented worldwide is by having an incentive for the
> executives that make the decisions. From experience, as I've said on this list a
> few times before, I can tell you that decision makers with a limited budget that
> have to choose between a new revenue generating feature, or a company-wide
> implementation of IPv6, will choose the one that's best for their own short-term
> interests.
>
> On that note, I did have a perhaps silly idea: One way to create the demand could
> be to have browser makers add a warning to the URL bar, similar to the HTTPS
> warnings we see today. If a site is IPv4 only, warn that the site is using
> deprecated technology.
>
> Financial incentives also work. Perhaps we can convince Mr. Biden to give a .5%
> tax cut to corporations that fully implement v6. That will create some bonus
> targets.
>
> Thanks,
>
> Sabri

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

What's all your opinion when company's such as Disney actively recommend disabling IPv6? They are presenting it as IPv6 is blocking their app. We all know that isn’t possible. Several people have issues with their app and Amazon firesticks. I use my phone and a chromecast and I see the issues when IPv6 is enabled. We are in the testing phase on rolling out IPv6 on our network. All the scripts are ready, just trying to work through the few issues like this one.

https://help.disneyplus.com/csp?id=csp_article_content&sys_kb_id=c91af021dbe46850b03cc58a139619ed

Thank you
Travis



-----Original Message-----
From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Mark Andrews
Sent: Thursday, January 21, 2021 7:45 PM
To: Sabri Berisha <sabri@cluecentral.net>
Cc: nanog <nanog@nanog.org>
Subject: Re: DoD IP Space

IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming.
Every data set says the same thing. It may not be coming as fast as a lot of us would want or actually think is reasonable as ISP’s are currently being forced to deploy CGNs (NAT44 and NAT64) because there are laggards that are not doing their part.

If you offer a service over the Internet then it should be available over
IPv6 otherwise you are costing your customers more to reach you. CGNs are not free.

Mark

> On 22 Jan 2021, at 06:07, Sabri Berisha <sabri@cluecentral.net> wrote:
>
> ----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com wrote:
>
> Hi,
>
>> I’m sure we all remember Y2k
>
> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I
> upgraded many bioses in many office buildings in the months leading up to it...
>
>> I’d love to see a line in the concrete of, say, January 1, 2025,
>> whereby IPv6 will be the default.
>
> The challenge with that is the market. Y2K was a problem that was
> existed. It was a brick wall that we would hit no matter what. The
> faulty code was released years before the date.
>
> We, IETF, or even the UN could come up with 1/1/25 as the date where
> we switch off IPv4, and you will still find networks that run IPv4 for
> the simple reason that the people who own those networks have a choice. With Y2K there was no choice.
>
> The best way to have IPv6 implemented worldwide is by having an
> incentive for the executives that make the decisions. From experience,
> as I've said on this list a few times before, I can tell you that
> decision makers with a limited budget that have to choose between a
> new revenue generating feature, or a company-wide implementation of
> IPv6, will choose the one that's best for their own short-term interests.
>
> On that note, I did have a perhaps silly idea: One way to create the
> demand could be to have browser makers add a warning to the URL bar,
> similar to the HTTPS warnings we see today. If a site is IPv4 only,
> warn that the site is using deprecated technology.
>
> Financial incentives also work. Perhaps we can convince Mr. Biden to
> give a .5% tax cut to corporations that fully implement v6. That will
> create some bonus targets.
>
> Thanks,
>
> Sabri

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

My opinion is that such recommendations are short sighted, and simply
creating tech debt and future support issues for themselves, and in some
cases, intermediaries. That example you linked though is pretty specific to
one "smart" TV OS ; it's possible that there is a V6 specific issue with
that TV OS, and it's just worded that way because it's simpler.

Randy nailed it a couple messages ago though. V6 Adoption always is, and
always will be, metered by time, money and resources. Everybody kicks the
can on things like this until they can't anymore. And that's honestly not
even major criticism; everybody has a list of 1000 things to do, and enough
time/money/resources to reasonably do 250 of them. Triage happens, we all
do it.

On Fri, Jan 22, 2021 at 9:30 AM Travis Garrison <tgarrison@netviscom.com>
wrote:

> What's all your opinion when company's such as Disney actively recommend
> disabling IPv6? They are presenting it as IPv6 is blocking their app. We
> all know that isn’t possible. Several people have issues with their app and
> Amazon firesticks. I use my phone and a chromecast and I see the issues
> when IPv6 is enabled. We are in the testing phase on rolling out IPv6 on
> our network. All the scripts are ready, just trying to work through the few
> issues like this one.
>
>
> https://help.disneyplus.com/csp?id=csp_article_content&sys_kb_id=c91af021dbe46850b03cc58a139619ed
>
> Thank you
> Travis
>
>
>
> -----Original Message-----
> From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf
> Of Mark Andrews
> Sent: Thursday, January 21, 2021 7:45 PM
> To: Sabri Berisha <sabri@cluecentral.net>
> Cc: nanog <nanog@nanog.org>
> Subject: Re: DoD IP Space
>
> IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming.
> Every data set says the same thing. It may not be coming as fast as a lot
> of us would want or actually think is reasonable as ISP’s are currently
> being forced to deploy CGNs (NAT44 and NAT64) because there are laggards
> that are not doing their part.
>
> If you offer a service over the Internet then it should be available over
> IPv6 otherwise you are costing your customers more to reach you. CGNs are
> not free.
>
> Mark
>
> > On 22 Jan 2021, at 06:07, Sabri Berisha <sabri@cluecentral.net> wrote:
> >
> > ----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com
> wrote:
> >
> > Hi,
> >
> >> I’m sure we all remember Y2k
> >
> > Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I
> > upgraded many bioses in many office buildings in the months leading up
> to it...
> >
> >> I’d love to see a line in the concrete of, say, January 1, 2025,
> >> whereby IPv6 will be the default.
> >
> > The challenge with that is the market. Y2K was a problem that was
> > existed. It was a brick wall that we would hit no matter what. The
> > faulty code was released years before the date.
> >
> > We, IETF, or even the UN could come up with 1/1/25 as the date where
> > we switch off IPv4, and you will still find networks that run IPv4 for
> > the simple reason that the people who own those networks have a choice.
> With Y2K there was no choice.
> >
> > The best way to have IPv6 implemented worldwide is by having an
> > incentive for the executives that make the decisions. From experience,
> > as I've said on this list a few times before, I can tell you that
> > decision makers with a limited budget that have to choose between a
> > new revenue generating feature, or a company-wide implementation of
> > IPv6, will choose the one that's best for their own short-term interests.
> >
> > On that note, I did have a perhaps silly idea: One way to create the
> > demand could be to have browser makers add a warning to the URL bar,
> > similar to the HTTPS warnings we see today. If a site is IPv4 only,
> > warn that the site is using deprecated technology.
> >
> > Financial incentives also work. Perhaps we can convince Mr. Biden to
> > give a .5% tax cut to corporations that fully implement v6. That will
> > create some bonus targets.
> >
> > Thanks,
> >
> > Sabri
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>
>

Randy,

In one sense I agree with you, but what I was reacting to was the idea
of an ISP begging IETF to reassign 22/8 as private space because their
customers won't migrate to IPv6. That's problematic for many reasons,
and causes the folks who aren't getting with the program to inflict the
pain caused by their inaction on the rest of the network.

At the same time, I sympathize with the ISP because if they can't meet
their customer's needs (however dumb those needs are) then the customers
will leave.

I agree that we don't need a flag day for IPv6, but we have to stop
creating new accommodations, and we need to be more creative about
keeping the pain (aka cost) of not moving forward isolated to the folks
who are creating the problems.

Doug


On 1/21/21 2:22 PM, Randy Bush wrote:
>>> I?m sure we all remember Y2k (well, most of us, there could be some
>>> young-uns on the list). That day was happening whether we wanted it to
>>> or not. It was an unchangeable, unmovable deadline.
>>
>> but i thought 3gpp was gong to force ipv6 adoption
>
> let me try it a different way
>
> why should i care whether you deploy ipv6, move to dual stack, cgnat,
> ...? you will do whatever makes sense to the pointy heads in your c
> suite. why should i give them or some tech religion free rent in my
> mind when i already have too much real work to do?
>
> randy
>

Joe,

I haven't done that kind of work for a few years now, but I assume the
answer to your question in terms of hardware is still yes.

By and large the problem isn't hardware, it's finding the institutional
will to actually do the thing. That requires a lot of education,
creating or buying resources that can do the architecture, and
ultimately the rollout, etc. etc.

And before all of that you have to overcome the fear of things that are
new and different, and even 20 years later that's still a tough hill to
climb.

Doug


On 1/21/21 1:01 PM, j k wrote:
> Organizations I have worked with for IPv6 transition, reduced CAPex and
> OPex by leveraging the IT refresh cycle, and by ensuring there
> investment included leveraging the USGv6
> (https://www.nist.gov/programs-projects/usgv6-program) or IPv6Ready
> (https://www.ipv6ready.org/) to mitigate the "We sell IPv6 products, and
> want to you to pay for the debugging costs".
>
> Can I assume other organizations don't leverage the IT refresh cycle?
>
> Joe Klein

On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revstr?m via NANOG wrote:
> certain large corporations that have run out of RFC1918, etc. space

At what level of incompetence must an organization operate to squander
roughly 70,000 /24 networks?

Or to do so and then decide, "You know what we really need to do? Let's
stomp on someone else's address space instead of deploying IPv6 a decade
late.

"And not just anyone's -- the US Military's! Because there's no
possible future in which an emergency might arise and see a need for
this global network built for resiliency to carry defense related
traffic."

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

On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revstr?m via NANOG wrote:
> certain large corporations that have run out of RFC1918, etc. space

At what level of incompetence must an organization operate to squander
roughly 70,000 /24 networks?

Or to do so and then decide, "You know what we really need to do? Let's
stomp on someone else's address space instead of deploying IPv6 a decade
late.

"And not just anyone's -- the US Military's! Because there's no
possible future in which an emergency might arise and see a need for
this global network built for resiliency to carry defense related
traffic."

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

On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revstr?m via NANOG wrote:
> certain large corporations that have run out of RFC1918, etc. space

At what level of incompetence must an organization operate to squander
roughly 70,000 /24 networks?

Or to do so and then decide, "You know what we really need to do? Let's
stomp on someone else's address space instead of deploying IPv6 a decade
late.

"And not just anyone's -- the US Military's! Because there's no
possible future in which an emergency might arise and see a need for
this global network built for resiliency to carry defense related
traffic."

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

Disney should hire some proper developers and QA team.

RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.

QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.
--
Mark Andrews

> On 23 Jan 2021, at 01:28, Travis Garrison <tgarrison@netviscom.com> wrote:
>
> ?What's all your opinion when company's such as Disney actively recommend disabling IPv6? They are presenting it as IPv6 is blocking their app. We all know that isn’t possible. Several people have issues with their app and Amazon firesticks. I use my phone and a chromecast and I see the issues when IPv6 is enabled. We are in the testing phase on rolling out IPv6 on our network. All the scripts are ready, just trying to work through the few issues like this one.
>
> https://help.disneyplus.com/csp?id=csp_article_content&sys_kb_id=c91af021dbe46850b03cc58a139619ed
>
> Thank you
> Travis
>
>
>
> -----Original Message-----
> From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Mark Andrews
> Sent: Thursday, January 21, 2021 7:45 PM
> To: Sabri Berisha <sabri@cluecentral.net>
> Cc: nanog <nanog@nanog.org>
> Subject: Re: DoD IP Space
>
> IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming.
> Every data set says the same thing. It may not be coming as fast as a lot of us would want or actually think is reasonable as ISP’s are currently being forced to deploy CGNs (NAT44 and NAT64) because there are laggards that are not doing their part.
>
> If you offer a service over the Internet then it should be available over
> IPv6 otherwise you are costing your customers more to reach you. CGNs are not free.
>
> Mark
>
>> On 22 Jan 2021, at 06:07, Sabri Berisha <sabri@cluecentral.net> wrote:
>>
>> ----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com wrote:
>>
>> Hi,
>>
>>> I’m sure we all remember Y2k
>>
>> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I
>> upgraded many bioses in many office buildings in the months leading up to it...
>>
>>> I’d love to see a line in the concrete of, say, January 1, 2025,
>>> whereby IPv6 will be the default.
>>
>> The challenge with that is the market. Y2K was a problem that was
>> existed. It was a brick wall that we would hit no matter what. The
>> faulty code was released years before the date.
>>
>> We, IETF, or even the UN could come up with 1/1/25 as the date where
>> we switch off IPv4, and you will still find networks that run IPv4 for
>> the simple reason that the people who own those networks have a choice. With Y2K there was no choice.
>>
>> The best way to have IPv6 implemented worldwide is by having an
>> incentive for the executives that make the decisions. From experience,
>> as I've said on this list a few times before, I can tell you that
>> decision makers with a limited budget that have to choose between a
>> new revenue generating feature, or a company-wide implementation of
>> IPv6, will choose the one that's best for their own short-term interests.
>>
>> On that note, I did have a perhaps silly idea: One way to create the
>> demand could be to have browser makers add a warning to the URL bar,
>> similar to the HTTPS warnings we see today. If a site is IPv4 only,
>> warn that the site is using deprecated technology.
>>
>> Financial incentives also work. Perhaps we can convince Mr. Biden to
>> give a .5% tax cut to corporations that fully implement v6. That will
>> create some bonus targets.
>>
>> Thanks,
>>
>> Sabri
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>

You mean like Rogers?

https://communityforums.rogers.com/t5/Internet/Why-is-my-first-hop-on-a-trace-route-to-the-United-States/td-p/30382



At 03:28 PM 22/01/2021, Izaac wrote:
>On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revstr?m via NANOG wrote:
> > certain large corporations that have run out of RFC1918, etc. space
>
>At what level of incompetence must an organization operate to squander
>roughly 70,000 /24 networks?
>
>Or to do so and then decide, "You know what we really need to do? Let's
>stomp on someone else's address space instead of deploying IPv6 a decade
>late.
>
>"And not just anyone's -- the US Military's! Because there's no
>possible future in which an emergency might arise and see a need for
>this global network built for resiliency to carry defense related
>traffic."
>
>--
>. ___ ___ . . ___
>. \ / |\ |\ \
>. _\_ /__ |-\ |-\ \__

--

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Big networks do run out of IPv4 space. It doesn’t require incompetence just lots of devices. That said if the devices where purchased in the last 2 decades they should support IPv6.

How many devices do you think a large car manufacture has on the shop floor? Remember some run their own bus services to move staff around the factory.

--
Mark Andrews

> On 23 Jan 2021, at 07:42, Mark Andrews <marka@isc.org> wrote:
>
> ?Disney should hire some proper developers and QA team.
>
> RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.
>
> QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.
> --
> Mark Andrews
>
>> On 23 Jan 2021, at 01:28, Travis Garrison <tgarrison@netviscom.com> wrote:
>>
>> ?What's all your opinion when company's such as Disney actively recommend disabling IPv6? They are presenting it as IPv6 is blocking their app. We all know that isn’t possible. Several people have issues with their app and Amazon firesticks. I use my phone and a chromecast and I see the issues when IPv6 is enabled. We are in the testing phase on rolling out IPv6 on our network. All the scripts are ready, just trying to work through the few issues like this one.
>>
>> https://help.disneyplus.com/csp?id=csp_article_content&sys_kb_id=c91af021dbe46850b03cc58a139619ed
>>
>> Thank you
>> Travis
>>
>>
>>
>> -----Original Message-----
>> From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Mark Andrews
>> Sent: Thursday, January 21, 2021 7:45 PM
>> To: Sabri Berisha <sabri@cluecentral.net>
>> Cc: nanog <nanog@nanog.org>
>> Subject: Re: DoD IP Space
>>
>> IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming.
>> Every data set says the same thing. It may not be coming as fast as a lot of us would want or actually think is reasonable as ISP’s are currently being forced to deploy CGNs (NAT44 and NAT64) because there are laggards that are not doing their part.
>>
>> If you offer a service over the Internet then it should be available over
>> IPv6 otherwise you are costing your customers more to reach you. CGNs are not free.
>>
>> Mark
>>
>>>> On 22 Jan 2021, at 06:07, Sabri Berisha <sabri@cluecentral.net> wrote:
>>>
>>> ----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com wrote:
>>>
>>> Hi,
>>>
>>>> I’m sure we all remember Y2k
>>>
>>> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I
>>> upgraded many bioses in many office buildings in the months leading up to it...
>>>
>>>> I’d love to see a line in the concrete of, say, January 1, 2025,
>>>> whereby IPv6 will be the default.
>>>
>>> The challenge with that is the market. Y2K was a problem that was
>>> existed. It was a brick wall that we would hit no matter what. The
>>> faulty code was released years before the date.
>>>
>>> We, IETF, or even the UN could come up with 1/1/25 as the date where
>>> we switch off IPv4, and you will still find networks that run IPv4 for
>>> the simple reason that the people who own those networks have a choice. With Y2K there was no choice.
>>>
>>> The best way to have IPv6 implemented worldwide is by having an
>>> incentive for the executives that make the decisions. From experience,
>>> as I've said on this list a few times before, I can tell you that
>>> decision makers with a limited budget that have to choose between a
>>> new revenue generating feature, or a company-wide implementation of
>>> IPv6, will choose the one that's best for their own short-term interests.
>>>
>>> On that note, I did have a perhaps silly idea: One way to create the
>>> demand could be to have browser makers add a warning to the URL bar,
>>> similar to the HTTPS warnings we see today. If a site is IPv4 only,
>>> warn that the site is using deprecated technology.
>>>
>>> Financial incentives also work. Perhaps we can convince Mr. Biden to
>>> give a .5% tax cut to corporations that fully implement v6. That will
>>> create some bonus targets.
>>>
>>> Thanks,
>>>
>>> Sabri
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>>

On Fri, Jan 22, 2021 at 03:44:34PM -0500, Clayton Zekelman wrote:
> You mean like Rogers?

Smashing example. They've got fewer than 4 million subscribers (only
about a million of them being Internet), and yet they have somehow gone
through over 17 million addresses?

"Ohh no! Quick! Let's abandon fundamental principles of Internet
architecture to get these poor souls more addresses right away!"

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

On Fri, Jan 22, 2021 at 03:44:34PM -0500, Clayton Zekelman wrote:
> You mean like Rogers?

Smashing example. They've got fewer than 4 million subscribers (only
about a million of them being Internet), and yet they have somehow gone
through over 17 million addresses?

"Ohh no! Quick! Let's abandon fundamental principles of Internet
architecture to get these poor souls more addresses right away!"

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

On 1/21/21 4:29 PM, Travis Garrison wrote:
> What's all your opinion when company's such as Disney actively recommend disabling IPv6? They are presenting it as IPv6 is blocking their app.
>
> https://help.disneyplus.com/csp?id=csp_article_content&sys_kb_id=c91af021dbe46850b03cc58a139619ed
--------------------------------------------------


Where it asked 'was this article helpful' I clicked 'no', selected 'other'
and wrote:

"IPv6 cannot block an app.  Disney uses only legacy IPv4 and does
not want to come onto the 21st century internet by using IPv6.  This
article is disinformation."

It won't help, but I feel better!  >:-)     <= evil grin

scott

----- On Jan 22, 2021, at 12:28 PM, Izaac izaac@setec.org wrote:

Hi,

> On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revström via NANOG wrote:
>> certain large corporations that have run out of RFC1918, etc. space
>
> At what level of incompetence must an organization operate to squander
> roughly 70,000 /24 networks?

Or, at what level of scale.

Or, a combination of both.

Let me give you an example. This example is not hypothetical.

Acme Inc operates a popular social media site. This requires a lot of
compute power, and storage space. Acme owns multiple datacenters around
the world, and all must be connected.

Acme divides its data centers in "Availability Zones". Each AZ contains
a limited amount of equipment. A typical AZ is made up of multiple pods,
and each pod contains anywhere between 40 and 48 racks. Each rack contains
up to 72 servers. Each server can contain many VMs or containers.

In order to scale, each AZ and pod are designed according to blueprints. This
obviously means that tradeoffs must be made. For example, each rack will be
assigned a /25, since a /26 means that not all 72 servers can have an IP.

Just to accommodate a single IP per server, we already need a /19. Most
servers will have different NICs for different purposes. For example, it is
not uncommon to have a separate storage network, and a management network.

Now we already need 3 /19s (32 /24s per pod, and we haven't even started to
assign IPs to VMs or containers yet.

Let's start to assign IPs to VMs and containers. Within one of my previous
employers, there were different groups that worked on VMs (cloud), and
containers (k8s). Both groups had automated scripts to assign IPs, but these
(obviously) did not communicate. Which means that each group had their own
vlan, with their own IRB (or BVI, or VLAN interface, however you want to
name it). On average, each group started with a /22 per tor (later on,
we limited them to a /24). So now we need 48*2*4=384 /24s per pod extra.

So, with 384+32 = 416 /24s per pod, you are looking at a maximum of 157 pods.

Now, granted, there is a lot of waste in this, hence the change from a /22 to
a /24, with a realization that the cloud and k8s group really needed to work
together to avoid more waste.

I will tell you that this is not at all hypothetical, I have personally
created spreadsheets of every /16 in 10/8 and how they were allocated. It's
amazing how much space was wasted in the early days at said employer, and
how much I was able to reclaim simply by checking if the allocations were
still valid. Hint: when companies split up, a lot of space gets freed up.

This the way that we avoided using DoD IP space to complement 10/8.

But, you were asking how it's possible to run out of 10/8, and here is your
answer :)

TL;DR: a combination of scale and incompetence means you can run out of 10/8
really quick.

Thanks,

Sabri

On 1/22/21 6:09 AM, Tom Beecher wrote:
> V6 Adoption always is, and always will be, metered by time, money and
> resources. Everybody kicks the can on things like this until they
> can't anymore.
---------------------------------

I have always said the management chooses this.  It's a cost-only
thing and they want to chase the sales, so IPv6 rollout loses every
time.  However, I now see a new ok-you-can-roll-out-ipv6-now
motivator for them.  "We can make $BIGSALE, but it requires IPv6
to be rolled out.  Hurry up and do it!"

Moral of the story...  Have your IPv6 rollout plan in place and as
ready to go as you can because it may be similar: Hurry up!

scott

On Fri, Jan 22, 2021 at 01:03:15PM -0800, Sabri Berisha wrote:
> TL;DR: a combination of scale and incompetence means you can run out of 10/8
> really quick.

Indeed. Thank you for providing a demonstration of my point.

I'd question the importance of having an console on target in Singapore
be able to directly address an BMC controller in Phoenix (wait for it),
but I'm sure that's a mission requirement.

But just in case you'd like to reconsider, can I interest you in NAT?
Like nutmeg, a little will add some spice to your recipe -- but too much
will cause nausea and hallucinations. It's entirely possible to put an
entire 192.168.0.0/16 network behind every single 172.16.0.0/12 address.

So, you've already "not at all hypothetical'd" entire racks completely
full of 1U hosts that are supporting lots of VMs in their beefy memory
on their two processors and also doing SAN into another universe. Let's
just magic a rack controller to handle the NAT. We can just cram it
into the extra-dimensional space where the switches live.

A standard port mapping configuration to match your "blueprint" ought to
be straight-foward. But let's elide the details and learn by
demonstration by just using it!

If the Singapore AZ were assigned 172.18.0.0/16.
And the 7th pod were 172.18.7.0/24.
And the 12th rack were 172.18.7.12/32.
We can SSH to the 39th host at: 172.18.7.11:2239
Which NATs to 192.168.0.39:22 on the 192.168.0.0/24 standard net.

If the Phoenix AZ (payoff!) were assigned 172.22.0.0/16.
And the 9th pod were 172.22.9.0/24
And the 33rd rack were 172.22.9.33/32.
We can VNC to the BMC of the 27th host at: 172.22.9.33:5927.
Which NATs to 192.168.1.27:5900 on the 192.168.1.0/24 management net.

Let's see. We've met all our requirements, left unused more than 50% of
the 172.16/12 space by being very generous to our AZs, left unused 98%
of the 192.168/16 space in each rack, threw every zero-network to the
wolves for our human counting from 1, and still haven't even touched
10/8. And all less than an hour's chin pulling.

Good for us.

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

The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."

Doug

(not speaking for any employers, current or former)


On 1/22/21 12:42 PM, Mark Andrews wrote:
> Disney should hire some proper developers and QA team.
>
> RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.
>
> QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.
>

----- On Jan 22, 2021, at 2:42 PM, Izaac izaac@setec.org wrote:

Hi,

> On Fri, Jan 22, 2021 at 01:03:15PM -0800, Sabri Berisha wrote:
>> TL;DR: a combination of scale and incompetence means you can run out of 10/8
>> really quick.
>
> Indeed. Thank you for providing a demonstration of my point.
>
> I'd question the importance of having an console on target in Singapore
> be able to directly address an BMC controller in Phoenix (wait for it),
> but I'm sure that's a mission requirement.

No, but the NOC that sits in between does need to access both. Sure, you can
use jumphosts, but now you're delaying troubleshooting of a potentially costly
outage.

> But just in case you'd like to reconsider, can I interest you in NAT?
> Like nutmeg, a little will add some spice to your recipe -- but too much
> will cause nausea and hallucinations.

NAT'ing RFC1918 to other RFC1918 space inside the same datacenter, or even
company, is a nightmare. If you've ever been on call for any decently sized
network, you'll know that.

> Let's just magic a rack controller to handle the NAT. We can just cram it
> into the extra-dimensional space where the switches live.

> And all less than an hour's chin pulling.

We both know that this is

A. An operational nightmare, and
B. Simply not the way things work in the real world.

The people who designed most of the legacy networks I've ever worked on did
not plan for the networks to grow to the size they became. Just like we would
never run out of the 640k of memory, people thought they would never run out
of RFC1918 space. Until they did.

And when that James May moment arrives, people start looking at a quick fix
(i.e., let's use unannounced public space), rather than redesigning and
reimplementing networks that have been in use for a long long time.

TL;DR: in theory, I agree with you 100%. In practice, that stuff just doesn't
work.

Thanks,

Sabri

An embarrassing mistake. I'm not a computer and don't count from zero. It is, of course, at 172.18.7.12:2239 and not 11.

Jan 22, 2021 18:01:15 Izaac <izaac@setec.org>:

> We can SSH to the 39th host at: 172.18.7.11:2239

An embarrassing mistake. I'm not a computer and don't count from zero. It is, of course, at 172.18.7.12:2239 and not 11.

Jan 22, 2021 18:01:15 Izaac <izaac@setec.org>:

> We can SSH to the 39th host at: 172.18.7.11:2239

On Fri, Jan 22, 2021 at 03:43:43PM -0800, Sabri Berisha wrote:
> No, but the NOC that sits in between does need to access both. Sure, you can

A single NOC sitting in the middle of a single address space. I believe
I'm detecting an architectural paradigm on the order of "bouncy castle."

Tell me, do you also permit customer A's secondary DNS server to reach
out and touch customer B's tertiary MongoDB replica in some other AZ for
a particular reason? Or are these networks segregated in some
meaningful way -- a way which might, say, completely vacate the entire
point of having a completely de-conflicted 1918 address space?

> use jumphosts, but now you're delaying troubleshooting of a potentially costly
> outage.

Who's using jumphosts? I very deliberately employed one of my least
favorite networking "technologies" in order to give you direct
connections. I just had to break a different fundamental networking
principle to steal the bits from another header. No biggie. You won't
even miss the lack of ICMP or the squished MTU. Honest.

It's just "your" stuff anyway. The customers have all that delicious
10/8 to use. Imagine how nice troubleshooting that would be, where
anything that's 172.16/12 is "yours" and anything 10/8 is "theirs."

> NAT'ing RFC1918 to other RFC1918 space inside the same datacenter, or even
> company, is a nightmare. If you've ever been on call for any decently sized
> network, you'll know that.

And that's different than NATing non-1918 addresses to a 1918 address
space how? Four bytes is four bytes, no? Or are 1918 addresses magic
when it comes to the mechanical process of address translation?

As far as being on call and troubleshooting, I'd think that identically
configured rack-based networks would be ideal, no? In the context of
the rack, everything is very familiar. That 192.168.0.1 is always the
gateway for the rack hosts. That 192.168.3.254 is always the iSCSI
target on the SAN. (Or is it more correctly NAS, since any random PDU
in Wallawalla WA can hit my disks in Perth via its unique address on a
machine which lives "not at all hypothetically" under the raised floor
or something. Maybe sitting in the 76-80th RU.)

Maybe I should investigate these "jumphosts" of which you speak, too.
They might have some advantages.

But I'm sure using your spreadsheets to look up everything all the time
works even better. Especially when you start having to slice your
networks thinner and thinner and renumber stuff. But I'm sure no
customer would ever say they needed more address space than was
initially allocated to them. It should be trivial to throw them
another /24 from elsewhere in the 10 space, get it all routed and
filtered and troubleshoot that on call. Much easier than handing them
very own 10/8.

> We both know that this is
>
> A. An operational nightmare, and
> B. Simply not the way things work in the real world.

Right. What would I know about the real world? What madman would ever
deploy a system in a way other than the flat, star pattern in which you
suggest. Who even approaches that scale and scope?

> not plan for the networks to grow to the size they became. Just like we would
> never run out of the 640k of memory, people thought they would never run out
> of RFC1918 space. Until they did.

Yes. Whoever could have seen that coming. If only we had developed
mechanisms for extending the existing IPv4 address space. Maybe by
making multiple hosts share a single address by using some kind of "proxy"
or committing a horrible sin and stealing bits from a different layer.

Or perhaps we could even deploy a different protocol with an even larger
address space. It could be done in parallel, even. Well. I can dream,
can't I?

> And when that James May moment arrives, people start looking at a quick fix
> (i.e., let's use unannounced public space), rather than redesigning and
> reimplementing networks that have been in use for a long long time.

A long long time indeed. Why, I remember back in the late 1990s when
the cloud wars started. They were saying Microsoft would have to divest
Azure. Barnes and Noble had just started selling MMX-optimized instances for
machine learning. The enormous web farms at Geocities were really
pushing the envelope of the possible when it came to high availability
concurrent web connections by leveraging CDNs. Very little has changed
since then. We've hardly had the opportunity to look at these networks,
let alone consider rebuilding them. Who has the time or opportunity?
That Cisco 2600 may be dusty, but it's been holding the fort all this
time.

> TL;DR: in theory, I agree with you 100%. In practice, that stuff just doesn't
> work.

Well thanks for sharing. I think we've all learned a lot.

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

On Fri, Jan 22, 2021 at 03:43:43PM -0800, Sabri Berisha wrote:
> No, but the NOC that sits in between does need to access both. Sure, you can

A single NOC sitting in the middle of a single address space. I believe
I'm detecting an architectural paradigm on the order of "bouncy castle."

Tell me, do you also permit customer A's secondary DNS server to reach
out and touch customer B's tertiary MongoDB replica in some other AZ for
a particular reason? Or are these networks segregated in some
meaningful way -- a way which might, say, completely vacate the entire
point of having a completely de-conflicted 1918 address space?

> use jumphosts, but now you're delaying troubleshooting of a potentially costly
> outage.

Who's using jumphosts? I very deliberately employed one of my least
favorite networking "technologies" in order to give you direct
connections. I just had to break a different fundamental networking
principle to steal the bits from another header. No biggie. You won't
even miss the lack of ICMP or the squished MTU. Honest.

It's just "your" stuff anyway. The customers have all that delicious
10/8 to use. Imagine how nice troubleshooting that would be, where
anything that's 172.16/12 is "yours" and anything 10/8 is "theirs."

> NAT'ing RFC1918 to other RFC1918 space inside the same datacenter, or even
> company, is a nightmare. If you've ever been on call for any decently sized
> network, you'll know that.

And that's different than NATing non-1918 addresses to a 1918 address
space how? Four bytes is four bytes, no? Or are 1918 addresses magic
when it comes to the mechanical process of address translation?

As far as being on call and troubleshooting, I'd think that identically
configured rack-based networks would be ideal, no? In the context of
the rack, everything is very familiar. That 192.168.0.1 is always the
gateway for the rack hosts. That 192.168.3.254 is always the iSCSI
target on the SAN. (Or is it more correctly NAS, since any random PDU
in Wallawalla WA can hit my disks in Perth via its unique address on a
machine which lives "not at all hypothetically" under the raised floor
or something. Maybe sitting in the 76-80th RU.)

Maybe I should investigate these "jumphosts" of which you speak, too.
They might have some advantages.

But I'm sure using your spreadsheets to look up everything all the time
works even better. Especially when you start having to slice your
networks thinner and thinner and renumber stuff. But I'm sure no
customer would ever say they needed more address space than was
initially allocated to them. It should be trivial to throw them
another /24 from elsewhere in the 10 space, get it all routed and
filtered and troubleshoot that on call. Much easier than handing them
very own 10/8.

> We both know that this is
>
> A. An operational nightmare, and
> B. Simply not the way things work in the real world.

Right. What would I know about the real world? What madman would ever
deploy a system in a way other than the flat, star pattern in which you
suggest. Who even approaches that scale and scope?

> not plan for the networks to grow to the size they became. Just like we would
> never run out of the 640k of memory, people thought they would never run out
> of RFC1918 space. Until they did.

Yes. Whoever could have seen that coming. If only we had developed
mechanisms for extending the existing IPv4 address space. Maybe by
making multiple hosts share a single address by using some kind of "proxy"
or committing a horrible sin and stealing bits from a different layer.

Or perhaps we could even deploy a different protocol with an even larger
address space. It could be done in parallel, even. Well. I can dream,
can't I?

> And when that James May moment arrives, people start looking at a quick fix
> (i.e., let's use unannounced public space), rather than redesigning and
> reimplementing networks that have been in use for a long long time.

A long long time indeed. Why, I remember back in the late 1990s when
the cloud wars started. They were saying Microsoft would have to divest
Azure. Barnes and Noble had just started selling MMX-optimized instances for
machine learning. The enormous web farms at Geocities were really
pushing the envelope of the possible when it came to high availability
concurrent web connections by leveraging CDNs. Very little has changed
since then. We've hardly had the opportunity to look at these networks,
let alone consider rebuilding them. Who has the time or opportunity?
That Cisco 2600 may be dusty, but it's been holding the fort all this
time.

> TL;DR: in theory, I agree with you 100%. In practice, that stuff just doesn't
> work.

Well thanks for sharing. I think we've all learned a lot.

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

On Thu, 21 Jan 2021 11:07:42 -0800, Sabri Berisha said:
> Financial incentives also work. Perhaps we can convince Mr. Biden to give a .5%
> tax cut to corporations that fully implement v6. That will create some bonus
> targets.

And how would you define "fully implement v6", anyhow?

Case in point: I helped deploy v6 at my employer *last century*, and the
entire network was (last I knew) totally v6 ready, and large segments were
v6-only. Yet Google *still* says that only 80% or so traffic to them are via
v6.

The other 20% being end-user devices that aren't using v6 for one reason or
another - I'm pretty sure that a lot of those are because companies have told
the user to "turn off ipv6" to solve connection problems, and I know that a lot
of them are gaming consoles from a vendor that had a brief shining chance to
Get It Right on the last iteration(*) but failed to do so....

And when I retired, I had several clusters of file servers that weren't doing
IPv6 because a certain 3-letter vendor who *really* should have been more on
the ball didn't have v6 support in the relevant software.

Even more problematic: What do you do with a company that's fully v6-ready, but
still has several major interconnects to other companies that *aren't* ready,
and thus still using v4?

(*) The PS4 has ipv6 support in the OS - it will dhcpv6 and answer pings from
on and off subnet. However, they didn't include ipv6 support in the development
software toolkit, so nothing actually uses it. They appear to have fixed this in the PS5,
but that still hits the "other company isn't ready" issue.

----- On Jan 22, 2021, at 4:50 PM, Izaac izaac@setec.org wrote:

Hi,

> On Fri, Jan 22, 2021 at 03:43:43PM -0800, Sabri Berisha wrote:

>> TL;DR: in theory, I agree with you 100%. In practice, that stuff just doesn't
>> work.
>
> Well thanks for sharing. I think we've all learned a lot.

You don't need to patronize me. I'm merely explaining the real life realities of
working in a large enterprise.

And the key takeaway here is: we can come up with the most efficient solutions,
in the end it's all about budgets and stakeholder requirements.

Thanks,

Sabri

----- On Jan 22, 2021, at 10:28 PM, Valdis Kl?tnieks valdis.kletnieks@vt.edu wrote:

Hi,

> On Thu, 21 Jan 2021 11:07:42 -0800, Sabri Berisha said:
>> Financial incentives also work. Perhaps we can convince Mr. Biden to give a .5%
>> tax cut to corporations that fully implement v6. That will create some bonus
>> targets.
>
> And how would you define "fully implement v6", anyhow?

Fair point. I'm sure the a commission appointed by the appropriate legislators
will be happy to spend a few millions debating that issue. Personally, I would
argue that a full implementation of IPv6 means that v4 could be phased out without
adverse effect on the production network.

But of course, how would we define "adverse effect on the production network"? :)

> Even more problematic: What do you do with a company that's fully v6-ready, but
> still has several major interconnects to other companies that *aren't* ready,
> and thus still using v4?

I totally agree with everything you wrote. It proves the point that having v6 ready
technologies in "the network", does not mean a network, or even a company is fully
v6 ready. Way too many stakeholders and outside dependencies.

To me, it means that "we", as in network professionals, should be ready to save
the day when company leaders finally realize they have no option and need v6 to
be implemented fast.

And secretly, I've been hoping for that moment. "Well, sir, the network has been
IPv6 ready for years, but the software groups and their leadership have so far
blatantly refused to update their code and support it".

I guess that I'll join you in retirement before that moment comes.

Thanks,

Sabri

On Sat, Jan 23, 2021 at 11:20:47AM -0800, Sabri Berisha wrote:
> You don't need to patronize me. I'm merely explaining the real life realities of
> working in a large enterprise.

Patronize you? Ohh, heavens no! I fully intend to use your replies as
educational material. Why, I've passed them to colleagues of mine
already. It's not every day that an off-handed comment made in
frustration at the state of the industry is so immediately and
thoroughly expanded upon.

I think patronizing would look more like: assuming a position of great
authority and noteworthy insight on a list full of professionals by
vaguely citing a situation which they were once exposed to as some kind
of instructive lab of how the "real world" works -- perhaps going
farther to summarizing each of the lessons into a one-line takeaway for
those who were either unable or unwilling to understand their point.

> And the key takeaway here is: we can come up with the most efficient solutions,
> in the end it's all about budgets and stakeholder requirements.

Ahh, I see! Thanks. I'll put that with the rest of my notes.

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

I have personally seen the issue with streaming from a Samsung cell phone and the Disney+ app to a Google chrome cast and a regular not-smart TV.

Travis

-----Original Message-----
From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Doug Barton
Sent: Friday, January 22, 2021 5:30 PM
To: nanog@nanog.org
Subject: Re: DoD IP Space

The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."

Doug

(not speaking for any employers, current or former)


On 1/22/21 12:42 PM, Mark Andrews wrote:
> Disney should hire some proper developers and QA team.
>
> RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.
>
> QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.
>

There's no error code. Customer only sees the message "DRM license resquest failed" on LG TV WebOS 3.8 or above.

Translation “I use a broken GEOIP database that doesn’t handle IPv6 correctly. If you turn off IPv6 then the request will use IPv4 and it may work.”.

Mark

> On 25 Jan 2021, at 01:03, Travis Garrison <tgarrison@netviscom.com> wrote:
>
> I have personally seen the issue with streaming from a Samsung cell phone and the Disney+ app to a Google chrome cast and a regular not-smart TV.
>
> Travis
>
> -----Original Message-----
> From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Doug Barton
> Sent: Friday, January 22, 2021 5:30 PM
> To: nanog@nanog.org
> Subject: Re: DoD IP Space
>
> The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."
>
> Doug
>
> (not speaking for any employers, current or former)
>
>
> On 1/22/21 12:42 PM, Mark Andrews wrote:
>> Disney should hire some proper developers and QA team.
>>
>> RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.
>>
>> QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.
>>

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

> On Jan 21, 2021, at 14:22 , Randy Bush <randy@psg.com> wrote:
>
>>> I’m sure we all remember Y2k (well, most of us, there could be some
>>> young-uns on the list). That day was happening whether we wanted it to
>>> or not. It was an unchangeable, unmovable deadline.
>>
>> but i thought 3gpp was gong to force ipv6 adoption
>
> let me try it a different way
>
> why should i care whether you deploy ipv6, move to dual stack, cgnat,
> ...? you will do whatever makes sense to the pointy heads in your c
> suite. why should i give them or some tech religion free rent in my
> mind when i already have too much real work to do?
>

Presumably because you have reason to connect to the internet.

Presumably you intend that connection to the internet to be able to reach
a variety of third parties.

As such, there is some reasonable basis for the idea that how third parties
choose to manage their network impacts decisions you need to make about
your own network.

E.G. Facebook has decided to go almost entirely IPv6, yet they maintain an
IPv4 presence on their front-end in order to support users that are victims of
IPv4-only networks and devices. Facebook faces a cost in having to maintain
those services to reach those customers. That cost could be reduced by the
providers in question (and in some cases the device manufacturers) providing
robust IPv6 implementations in their products and services.

Unfortunately, NAT, CGNAT, and IPv4 in general are an unrecognized cost
inflicted on people who are not involved in the decision to implement those
processes vs. deploying IPv6, thus creating. a situation where those who
have deployed IPv6 yet wish to maintain connectivity to those who have not
are essentially subsidizing those who have not in order to maintain that
connectivity.

Now, if the true cost of that were more transparent and the organizations
not deploying IPv6 could be made more aware of the risks of what happens
when a variety of organizations choose to put an end to that subsidy,
it might get more attention at the CxO level. Unfortunately, the perverse
incentives of the market (providers that are willing to offer legacy services
are more likely to retain customers than providers that aren’t) prevent
those paying the subsidy from opting out (at least for now) because the
critical mass of customers still clinging to their legacy networks presumably
comes with a value that exceeds the cost of that subsidy.

There was actually some excellent work done to try and quantify this
in terms of Per User Per Year costs to an average ISP by
Lee Howard: https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf

Owen

At the bottom of that page, there is a question “Was this answer helpful.” I clicked NO. It gave me a free form text box to explain why I felt it was not helpful… Here’s what I typed:

The advice is just bad and the facts are incorrect.
IPv6 is not blocking the Disney application. Either IPv6 is broken in the users environment (in which case, the user should work with their network administrator to resolve this) or Disney has failed to implement IPv6 correctly on their DRM platform.

IPv6 cannot "Block" an application.

Turning off IPv6 will degrade several other services and cause additional problems. This is simply very bad advice and shame on Disney for issuing it.

Hopefully if enough people follow suit, Disney will get the idea.

Owen

> On Jan 21, 2021, at 18:29 , Travis Garrison <tgarrison@netviscom.com> wrote:
>
> What's all your opinion when company's such as Disney actively recommend disabling IPv6? They are presenting it as IPv6 is blocking their app. We all know that isn’t possible. Several people have issues with their app and Amazon firesticks. I use my phone and a chromecast and I see the issues when IPv6 is enabled. We are in the testing phase on rolling out IPv6 on our network. All the scripts are ready, just trying to work through the few issues like this one.
>
> https://help.disneyplus.com/csp?id=csp_article_content&sys_kb_id=c91af021dbe46850b03cc58a139619ed
>
> Thank you
> Travis
>
>
>
> -----Original Message-----
> From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Mark Andrews
> Sent: Thursday, January 21, 2021 7:45 PM
> To: Sabri Berisha <sabri@cluecentral.net>
> Cc: nanog <nanog@nanog.org>
> Subject: Re: DoD IP Space
>
> IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming.
> Every data set says the same thing. It may not be coming as fast as a lot of us would want or actually think is reasonable as ISP’s are currently being forced to deploy CGNs (NAT44 and NAT64) because there are laggards that are not doing their part.
>
> If you offer a service over the Internet then it should be available over
> IPv6 otherwise you are costing your customers more to reach you. CGNs are not free.
>
> Mark
>
>> On 22 Jan 2021, at 06:07, Sabri Berisha <sabri@cluecentral.net> wrote:
>>
>> ----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com wrote:
>>
>> Hi,
>>
>>> I’m sure we all remember Y2k
>>
>> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I
>> upgraded many bioses in many office buildings in the months leading up to it...
>>
>>> I’d love to see a line in the concrete of, say, January 1, 2025,
>>> whereby IPv6 will be the default.
>>
>> The challenge with that is the market. Y2K was a problem that was
>> existed. It was a brick wall that we would hit no matter what. The
>> faulty code was released years before the date.
>>
>> We, IETF, or even the UN could come up with 1/1/25 as the date where
>> we switch off IPv4, and you will still find networks that run IPv4 for
>> the simple reason that the people who own those networks have a choice. With Y2K there was no choice.
>>
>> The best way to have IPv6 implemented worldwide is by having an
>> incentive for the executives that make the decisions. From experience,
>> as I've said on this list a few times before, I can tell you that
>> decision makers with a limited budget that have to choose between a
>> new revenue generating feature, or a company-wide implementation of
>> IPv6, will choose the one that's best for their own short-term interests.
>>
>> On that note, I did have a perhaps silly idea: One way to create the
>> demand could be to have browser makers add a warning to the URL bar,
>> similar to the HTTPS warnings we see today. If a site is IPv4 only,
>> warn that the site is using deprecated technology.
>>
>> Financial incentives also work. Perhaps we can convince Mr. Biden to
>> give a .5% tax cut to corporations that fully implement v6. That will
>> create some bonus targets.
>>
>> Thanks,
>>
>> Sabri
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>

His example may have included incompetence. However, it takes longer, but
it is definitely possible to run out of RFC-1918 space with scale and no incompetence.

No rational network will ever be able to put every single /32 endpoint on a host, but
I know of several networks that have come darn close and still run multiple partitioned
RFC-1918 “zones” because RFC-1918 just isn’t enough for them.

The good news is that IPv6 has plenty of addresses available for all of these applications
and there’s absolutely no need for separate private addressing unless you really want it.

Owen


> On Jan 22, 2021, at 14:42 , Izaac <izaac@setec.org> wrote:
>
> On Fri, Jan 22, 2021 at 01:03:15PM -0800, Sabri Berisha wrote:
>> TL;DR: a combination of scale and incompetence means you can run out of 10/8
>> really quick.
>
> Indeed. Thank you for providing a demonstration of my point.
>
> I'd question the importance of having an console on target in Singapore
> be able to directly address an BMC controller in Phoenix (wait for it),
> but I'm sure that's a mission requirement.
>
> But just in case you'd like to reconsider, can I interest you in NAT?
> Like nutmeg, a little will add some spice to your recipe -- but too much
> will cause nausea and hallucinations. It's entirely possible to put an
> entire 192.168.0.0/16 network behind every single 172.16.0.0/12 address.
>
> So, you've already "not at all hypothetical'd" entire racks completely
> full of 1U hosts that are supporting lots of VMs in their beefy memory
> on their two processors and also doing SAN into another universe. Let's
> just magic a rack controller to handle the NAT. We can just cram it
> into the extra-dimensional space where the switches live.
>
> A standard port mapping configuration to match your "blueprint" ought to
> be straight-foward. But let's elide the details and learn by
> demonstration by just using it!
>
> If the Singapore AZ were assigned 172.18.0.0/16.
> And the 7th pod were 172.18.7.0/24.
> And the 12th rack were 172.18.7.12/32.
> We can SSH to the 39th host at: 172.18.7.11:2239
> Which NATs to 192.168.0.39:22 on the 192.168.0.0/24 standard net.
>
> If the Phoenix AZ (payoff!) were assigned 172.22.0.0/16.
> And the 9th pod were 172.22.9.0/24
> And the 33rd rack were 172.22.9.33/32.
> We can VNC to the BMC of the 27th host at: 172.22.9.33:5927.
> Which NATs to 192.168.1.27:5900 on the 192.168.1.0/24 management net.
>
> Let's see. We've met all our requirements, left unused more than 50% of
> the 172.16/12 space by being very generous to our AZs, left unused 98%
> of the 192.168/16 space in each rack, threw every zero-network to the
> wolves for our human counting from 1, and still haven't even touched
> 10/8. And all less than an hour's chin pulling.
>
> Good for us.
>
> --
> . ___ ___ . . ___
> . \ / |\ |\ \
> . _\_ /__ |-\ |-\ \__

WebOS implemented IPv6 in 3.8 IIRC.

Owen


> On Jan 22, 2021, at 15:30 , Doug Barton <dougb@dougbarton.us> wrote:
>
> The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."
>
> Doug
>
> (not speaking for any employers, current or former)
>
>
> On 1/22/21 12:42 PM, Mark Andrews wrote:
>> Disney should hire some proper developers and QA team.
>> RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.
>> QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.

ROTFL! I’m sorry, but the imagery of people paying rent for a piece of Randy’s mind is just too much :)

> On Jan 21, 2021, at 14:22 , Randy Bush <randy@psg.com> wrote:
>
>>> I’m sure we all remember Y2k (well, most of us, there could be some
>>> young-uns on the list). That day was happening whether we wanted it to
>>> or not. It was an unchangeable, unmovable deadline.
>>
>> but i thought 3gpp was gong to force ipv6 adoption
>
> let me try it a different way
>
> why should i care whether you deploy ipv6, move to dual stack, cgnat,
> ...? you will do whatever makes sense to the pointy heads in your c
> suite. why should i give them or some tech religion free rent in my
> mind when i already have too much real work to do?
>

Owen,

I am genuinely curious, how would you explain the problem, and describe
a solution, to an almost exclusively non-technical audience who just
wants to get the bits flowing again?

Doug
(still not speaking for anyone other than myself)


On 2/5/21 2:25 PM, Owen DeLong wrote:
> At the bottom of that page, there is a question “Was this answer
> helpful.” I clicked NO. It gave me a free form text box to explain why I
> felt it was not helpful… Here’s what I typed:
>
> The advice is just bad and the facts are incorrect.
> IPv6 is not blocking the Disney application. Either IPv6 is broken
> in the users environment (in which case, the user should work with
> their network administrator to resolve this) or Disney has failed to
> implement IPv6 correctly on their DRM platform.
>
> IPv6 cannot "Block" an application.
>
> Turning off IPv6 will degrade several other services and cause
> additional problems. This is simply very bad advice and shame on
> Disney for issuing it.
>
>
> Hopefully if enough people follow suit, Disney will get the idea.
>
> Owen

On Fri, 05 Feb 2021 17:25:34 -0800, Doug Barton said:
> I am genuinely curious, how would you explain the problem, and describe
> a solution, to an almost exclusively non-technical audience who just
> wants to get the bits flowing again?

"The people who did Disney's software wrote it for the Internet protocols
of last century, so it fails with this century's Internet. Adding insult to injury,
the reason you even notice a problem is because it reacts badly to the failure,
because it doesn't even include *last* century's well-known methods of
error recovery".

> On Jan 22, 2021, at 10:28 PM, Valdis Kl?tnieks <valdis.kletnieks@vt.edu> wrote:
>
> And how would you define "fully implement v6", anyhow?

I would define it this way: if something can be done using IPv4, it has an obvious IPv6 counterpart that is usable by the same community to the extent that the community is itself able to use such. Web sites, mail, bandwidth, routing, ROAs, firewalls with appropriate rules, and so on. The problem with my suggested wording is that if one turns IPv4 off, by implication someone turns IPv6 off, and I don't intend that. So reword to make IPv6 the surviving service in some way, and I think you're pretty much there.

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.

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

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 Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
> Please explain to me how you uniquely number 40M endpoints with RFC-1918 without running out of
> addresses and without creating partitioned networks.

OK.. I'll bite. What network design needs 40M endpoints and can't tolerate
partitioned networks? There's eyeball networks out there that have that many
endpoints, but they end up partitioned behind multiple NAT boxes.

On Wed, Feb 10, 2021 at 4:32 AM Valdis Kl?tnieks <valdis.kletnieks@vt.edu>
wrote:

> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
> > Please explain to me how you uniquely number 40M endpoints with RFC-1918
> without running out of
> > addresses and without creating partitioned networks.
>
> OK.. I'll bite. What network design needs 40M endpoints and can't tolerate
> partitioned networks? There's eyeball networks out there that have that
> many
> endpoints, but they end up partitioned behind multiple NAT boxes.
>
>
Why would you assume partitioning is an acceptable design constraint ?

I don’t think the cellular networks in the USA, each with over a 100M
subscribers, wants their customers partitioned, and that is why the IMS /
SIP on each modern phone is exclusively ipv6, afaik

Owen DeLong <owen@delong.com> writes:

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


You added "without ..." and did not explain why. This does look a bit
like an excuse to me. But there is probably some explanation I don't
see.

Why would you not partition the network?


Bjørn

Ca By <cb.list6@gmail.com> writes:

> On Wed, Feb 10, 2021 at 4:32 AM Valdis Kl?tnieks <valdis.kletnieks@vt.edu>
> wrote:
>
>> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
>> > Please explain to me how you uniquely number 40M endpoints with RFC-1918
>> without running out of
>> > addresses and without creating partitioned networks.
>>
>> OK.. I'll bite. What network design needs 40M endpoints and can't tolerate
>> partitioned networks? There's eyeball networks out there that have that
>> many
>> endpoints, but they end up partitioned behind multiple NAT boxes.
>>
>>
> Why would you assume partitioning is an acceptable design constraint ?
>
> I don’t think the cellular networks in the USA, each with over a 100M
> subscribers, wants their customers partitioned, and that is why the IMS /
> SIP on each modern phone is exclusively ipv6, afaik

You don't need to partition the customers to partition the network.
It's not like any single network entity scales to a 100M sessions in any
case. You will need more than one SIP server.

You'll have multiple instances of "that user with 10.10.10.10", but
that's easily addressed that by including the associated network
segment. So you have "that user with 10.10.10.10 in segment A" and
"that user with 10.10.10.10 in segment B". They can both be part of the
same customer database or whatever


Bjørn

On Wed, Feb 10, 2021 at 5:50 AM Bjørn Mork <bjorn@mork.no> wrote:

> Ca By <cb.list6@gmail.com> writes:
>
> > On Wed, Feb 10, 2021 at 4:32 AM Valdis Kl?tnieks <
> valdis.kletnieks@vt.edu>
> > wrote:
> >
> >> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
> >> > Please explain to me how you uniquely number 40M endpoints with
> RFC-1918
> >> without running out of
> >> > addresses and without creating partitioned networks.
> >>
> >> OK.. I'll bite. What network design needs 40M endpoints and can't
> tolerate
> >> partitioned networks? There's eyeball networks out there that have that
> >> many
> >> endpoints, but they end up partitioned behind multiple NAT boxes.
> >>
> >>
> > Why would you assume partitioning is an acceptable design constraint ?
> >
> > I don’t think the cellular networks in the USA, each with over a 100M
> > subscribers, wants their customers partitioned, and that is why the IMS /
> > SIP on each modern phone is exclusively ipv6, afaik
>
> You don't need to partition the customers to partition the network.
> It's not like any single network entity scales to a 100M sessions in any
> case. You will need more than one SIP server.
>
> You'll have multiple instances of "that user with 10.10.10.10", but
> that's easily addressed that by including the associated network
> segment. So you have "that user with 10.10.10.10 in segment A" and
> "that user with 10.10.10.10 in segment B". They can both be part of the
> same customer database or whatever
>
>
> Bjørn


I understand you think it could work that way

I am sharing with you that the gymnastics to make such a kludge work was
reject years ago

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.

I believe you will find similar cases for hyper-scalers like google, fb,
...

CB


>

Ca By <cb.list6@gmail.com> writes:

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

I certainly agree that this is easier and makes more sense. I just
don't buy the "can't be done" wrt using rfc1918.


Bjørn

On Wed, Feb 10, 2021 at 6:11 AM Bjørn Mork <bjorn@mork.no> wrote:

> Ca By <cb.list6@gmail.com> writes:
>
> > 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.
>
> I certainly agree that this is easier and makes more sense. I just
> don't buy the "can't be done" wrt using rfc1918.
>

Well, it is not rfc1918 that is best invoked here.

May i point you to rfc1925 section 2.3, regarding pigs flying with
sufficient thrust. IPv4 is the pig, and a steam engined fueled by dollars
is the source of thrust

https://tools.ietf.org/html/rfc1925


>
> Bjørn
>

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.

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

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.

Doug

On Fri, Jan 22, 2021 at 12:30 PM Izaac <izaac@setec.org> wrote:
> On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revström via NANOG wrote:
> > certain large corporations that have run out of RFC1918, etc. space
>
> At what level of incompetence must an organization operate to squander
> roughly 70,000 /24 networks?

Hi Isaac,

None whatsoever. You just have to be really big.

Imagine you're Amazon. You have this insanely large deployment of
servers. Your customers have this virtual concept you've presented
them called a "VPC" but there are no wires or routers. The subnets
only exist as bits in memory. The Virtual Private Cloud is a ruleset
in the network adapter of every physical machine running one of the
VMs that participate in the VPC. A big, flat network where every one
of these servers has a need to talk to every other server that could
possibly be tasked to run a VM in that VPC.

Regards,
Bill Herrin

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

On 2/10/21 19:50, Doug Barton wrote:

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

Preventing communication exchange between devices does not have to be
driven by their IP addressing.


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

It's 2021 - Bonjour. You're welcome :-).

Mark.

> On Feb 10, 2021, at 04:29 , Valdis Kl?tnieks <valdis.kletnieks@vt.edu> wrote:
>
> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
>> Please explain to me how you uniquely number 40M endpoints with RFC-1918 without running out of
>> addresses and without creating partitioned networks.
>
> OK.. I'll bite. What network design needs 40M endpoints and can't tolerate
> partitioned networks? There's eyeball networks out there that have that many
> endpoints, but they end up partitioned behind multiple NAT boxes.

The ability to tolerate pain is not a criteria for competence.

Partitioning (e.g.) the set-top box management network for a major cable provider is, in fact, pain and costly vs.
being able to have a contiguous network with unique addressing. IPv6 is the right answer in this case (and virtually
any other), but the addition of arbitrary pain thresholds doesn’t meet the criteria of whether or not one can run
out of RFC-1918 without incompetence.

Owen

> On Feb 10, 2021, at 06:11 , Bjørn Mork <bjorn@mork.no> wrote:
>
> Ca By <cb.list6@gmail.com> writes:
>
>> 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.
>
> I certainly agree that this is easier and makes more sense. I just
> don't buy the "can't be done" wrt using rfc1918.
>
>
> Bjørn

The argument was that you can’t run out of RFC-1918 without incompetence.

You don’t have to be incompetent to decide that partitioning your network is a bad idea for
multiple (I would think obvious) reasons.

Trying to allow arbitrary phone calls between 100M subscribers (5+ copies of RFC-1918 space)
where any endpoint may need to reach any other endpoint involves some mapping gymnastics
that would make SS7 look like child’s play.

Cable providers did, in some cases go with partitioned networks for set-top management,
but I don’t know anyone who was involved in building or maintaining or troubleshooting those
systems that doesn’t curse them.

Owen

> On Feb 10, 2021, at 09:50 , Doug Barton <dougb@dougbarton.us> wrote:
>
> 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.

Ideally SIP does the call setup and registration of the phone’s DIDN to to IP mapping, but once call setup is completed, ideal is a pair of RTP streams between the phones directly (modulo annoying CALEA provisions getting in the way).

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

Unique numbering doesn’t mean connectivity, it means the possibility of allowing connectivity.

There’s. also the transitive issue… If A needs to talk to B and B needs to talk to C, then having A and C in the same address space is a problem, even if A doesn’t need to talk to C.

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

It’s absolutely a good idea. Using address overloading to avoid the possibility of permitting connectivity is just bad design any way you slice it.

Oh, and no network design survives contact with the real world. The set of things that need to talk today are not the same set of things that will need to talk in 1 year, 5 years, 10 years, etc.

The accounting department will NEVER talk directly to the sales department until they do.

Owen

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.

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

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

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

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.

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

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

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.

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.

> 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

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.

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

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.

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/

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.

> 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

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.

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/

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.

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.

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

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.

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/

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

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

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

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 :)

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 :)

Streams Transport and PIP.

Good grief. V7 was Robert Ullman’s CATNIP. He wanted to sell hardware to everyone, and V7 was the interchange protocol between IPv4, IPX, and CLNS.

Sent using a machine that autocorrects in interesting ways...

> On Feb 15, 2021, at 12:41 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 :)

V5 was

V8!  heh ... wow hadn't thought of that for a while ...

On 2/15/2021 3:39 PM, Valdis Kl?tnieks 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 :)

On Mon, Feb 15, 2021 at 9:36 PM Joe Loiacono <jloiacon@gmail.com> wrote:

> V8! heh ... wow hadn't thought of that for a while ...

... Slaps forehead and says: "Wow, I could've had a V8!"

1993 matches my recollections as well.

Network Working Group S. Bradner
Internet draft Harvard University
A. Mankin
NRL
September 1994



The Recommendation for the IP Next Generation Protocol


<draft-ipng-recommendation-00.txt>



> On 16 Feb 2021, at 04:28, Mel Beckman <mel@beckman.org> wrote:
>
> 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
>>
>>

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

> it?s unclear if there?s been any systematic look-back or institutional
> learning coming out of the entire experience.

i am always impressed by optimism in the face of cold reality