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

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

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

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

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

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_Elverso... for details.)

FYI, /John

John Curran President and CEO American Registry for Internet Numbers

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.

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

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

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

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

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

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

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

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.

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.

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

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

...

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

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

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

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

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 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 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. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

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 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. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

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.

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

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

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

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

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

...

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

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

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

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

...

addressable whether reachable by policy or not.

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

endpoint was uniquely 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 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. -- . ___ ___  .   .  ___ .  \    /  |\  |\ \ .  _\_ /__ |-\ |-\ \__

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

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

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.

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

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.

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

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 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? -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

Two questions... 1. How many on this list already have dual-stack or IPv6 only in operation? 2. If you are running IPv4 only, and a major service was to switch to IPv6 only,.. a. How fast would you move to a dual-stack of IPv6 only? b. What would it impact your customers? c. How would it impact your business? 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, Feb 11, 2021 at 12:56 PM William Herrin <bill@herrin.us> wrote:

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/

As noted - https://www.washingtonpost.com/technology/2021/04/24/pentagon-internet-addre... FYI, /John John Curran President and CEO American Registry for Internet Numbers On Jan 20, 2021, at 8:35 AM, 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<mailto:ximaera@gmail.com>> wrote: Peace, On Tue, Nov 5, 2019, 4:55 PM David Conrad <drc@virtualized.org<mailto:drc@virtualized.org>> wrote:

On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG <nanog@nanog.org<mailto: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

Huh? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "John Curran" <jcurran@arin.net> Cc: nanog@nanog.org Sent: Saturday, April 24, 2021 10:24:45 AM Subject: Re: DoD IP Space This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us. -mel On Apr 24, 2021, at 8:05 AM, John Curran <jcurran@arin.net> wrote: <blockquote> As noted - https://www.washingtonpost.com/technology/2021/04/24/pentagon-internet-addre... FYI, /John John Curran President and CEO American Registry for Internet Numbers <blockquote> On Jan 20, 2021, at 8:35 AM, John Curran <jcurran@istaff.org> wrote: </blockquote> <blockquote> 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 <blockquote> On Nov 5, 2019, at 10:38 AM, Tom Beecher <beecher@beecher.cc> wrote: </blockquote> <blockquote> 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: <blockquote> 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 </blockquote> </blockquote> </blockquote> </blockquote>

"proven-malicious IP space owner" The DoD? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org, "John Curran" <jcurran@arin.net> Sent: Saturday, April 24, 2021 10:37:42 AM Subject: Re: DoD IP Space I will not permit traffic into my network whose proven-malicious IP space owner is devious about its purpose. You can, if you want. -mel On Apr 24, 2021, at 8:28 AM, Mike Hammett <nanog@ics-il.net> wrote: <blockquote> Huh? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "John Curran" <jcurran@arin.net> Cc: nanog@nanog.org Sent: Saturday, April 24, 2021 10:24:45 AM Subject: Re: DoD IP Space This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us. -mel <blockquote> On Apr 24, 2021, at 8:05 AM, John Curran <jcurran@arin.net> wrote: </blockquote> <blockquote> As noted - https://www.washingtonpost.com/technology/2021/04/24/pentagon-internet-addre... FYI, /John John Curran President and CEO American Registry for Internet Numbers <blockquote> On Jan 20, 2021, at 8:35 AM, John Curran <jcurran@istaff.org> wrote: </blockquote> <blockquote> 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 <blockquote> On Nov 5, 2019, at 10:38 AM, Tom Beecher <beecher@beecher.cc> wrote: </blockquote> <blockquote> 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: <blockquote> 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 </blockquote> </blockquote> </blockquote> </blockquote> </blockquote>

I encourage my competition to make equally arbitrary routing decisions. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org, "John Curran" <jcurran@arin.net> Sent: Saturday, April 24, 2021 10:53:26 AM Subject: Re: DoD IP Space In this specific case the group of self-described DOD network cowboys who, due to lack of transparency and public oversight, could be doing all manner of nefarious things with this IP space. It can’t help to let it in, and it can definitely hurt. But you know that. So why are you playing dumb? -mel On Apr 24, 2021, at 8:44 AM, Mike Hammett <nanog@ics-il.net> wrote: <blockquote> "proven-malicious IP space owner" The DoD? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org, "John Curran" <jcurran@arin.net> Sent: Saturday, April 24, 2021 10:37:42 AM Subject: Re: DoD IP Space I will not permit traffic into my network whose proven-malicious IP space owner is devious about its purpose. You can, if you want. -mel <blockquote> On Apr 24, 2021, at 8:28 AM, Mike Hammett <nanog@ics-il.net> wrote: </blockquote> <blockquote> Huh? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" <mel@beckman.org> To: "John Curran" <jcurran@arin.net> Cc: nanog@nanog.org Sent: Saturday, April 24, 2021 10:24:45 AM Subject: Re: DoD IP Space This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us. -mel <blockquote> On Apr 24, 2021, at 8:05 AM, John Curran <jcurran@arin.net> wrote: </blockquote> <blockquote> As noted - https://www.washingtonpost.com/technology/2021/04/24/pentagon-internet-addre... FYI, /John John Curran President and CEO American Registry for Internet Numbers <blockquote> On Jan 20, 2021, at 8:35 AM, John Curran <jcurran@istaff.org> wrote: </blockquote> <blockquote> 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 <blockquote> On Nov 5, 2019, at 10:38 AM, Tom Beecher <beecher@beecher.cc> wrote: </blockquote> <blockquote> 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: <blockquote> 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 </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote>

Bill, It’s the INTERNET that is civilian, not the IP space. As long as that IP space was isolated to the .mil network, it was private space, as far as the Internet was concerned. Now DoD has moved it into the civilian Internet, and I treat them as potentially malicious as I do any other organization that lies, cheats, and steals the public trust. -mel

On Apr 24, 2021, at 3:45 PM, William Herrin <bill@herrin.us> wrote:

On Sat, Apr 24, 2021 at 8:26 AM Mel Beckman <mel@beckman.org> wrote:

...

This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum.

You do understand that the addresses in question are not and have never been "civilian." They came into DoD's possession when this was all still a military project funded by what's now DARPA.

Personally, I think we may have an all time record for the largest honeypot ever constructed. I'd love to be a fly on that wall.

Regards, Bill Herrin

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

Jason, The government subsidizes farms, too. That doesn’t mean we let them be militarized. Logic. :) -mel On Apr 24, 2021, at 4:35 PM, Jason Biel <jason@biel-tech.com> wrote:  The internet that is subsidized by that same Government.... Logic. On Sat, Apr 24, 2021 at 18:19 Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: Bill, It’s the INTERNET that is civilian, not the IP space. As long as that IP space was isolated to the .mil network, it was private space, as far as the Internet was concerned. Now DoD has moved it into the civilian Internet, and I treat them as potentially malicious as I do any other organization that lies, cheats, and steals the public trust. -mel

On Apr 24, 2021, at 3:45 PM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote:

On Sat, Apr 24, 2021 at 8:26 AM Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote:

...

This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum.

You do understand that the addresses in question are not and have never been "civilian." They came into DoD's possession when this was all still a military project funded by what's now DARPA.

Personally, I think we may have an all time record for the largest honeypot ever constructed. I'd love to be a fly on that wall.

Regards, Bill Herrin

-- William Herrin bill@herrin.us<mailto:bill@herrin.us> https://bill.herrin.us/

-- Jason

Owen, Well, no. The Internet — meaning the ISPs and customers that comprise it — get substantial subsidies to this day. But that’s no call for the government to be obtuse with the purposes of its IP space. https://www.nasdaq.com/articles/more-than-300-companies-participate-in-inter... -mel

On Apr 26, 2021, at 11:05 AM, Owen DeLong <owen@delong.com> wrote:

...

On Apr 24, 2021, at 16:34 , Jason Biel <jason@biel-tech.com> wrote:

The internet that is subsidized by that same Government….

Uh, s/is/was/

There’s really no subsidy any more.

Owen

Carlos, It’s true even though the Internet is comprised of more than American providers and customers. A subsidy is a subsidy. It doesn’t have to go to everyone to “be true”. :) -mel

On Apr 26, 2021, at 12:44 PM, Carlos M. Martinez <carlosm3011@gmail.com> wrote:

That would be true if “the Internet” was still fully comprised of American providers and customers. That hasn’t been the case for a long, long time.

On 26 Apr 2021, at 16:27, Mel Beckman wrote:

...

Owen,

Well, no. The Internet — meaning the ISPs and customers that comprise it — get substantial subsidies to this day. But that’s no call for the government to be obtuse with the purposes of its IP space.

https://www.nasdaq.com/articles/more-than-300-companies-participate-in-inter...

-mel

...

On Apr 26, 2021, at 11:05 AM, Owen DeLong <owen@delong.com> wrote:

...

On Apr 24, 2021, at 16:34 , Jason Biel <jason@biel-tech.com> wrote:

The internet that is subsidized by that same Government….

Uh, s/is/was/

There’s really no subsidy any more.

Owen

On Mon, Apr 26, 2021 at 10:18 PM Randy Bush <randy@psg.com> wrote:

anyone seeing roas in 11/8? i am not.

am not either, I would be curious to know if the RPKI discussion came up for the prefixes in the run up to turning up this new service. I'd also love to know if they are planning to publish ROA :) it'd be handy in telling the rest of the world: "Hey, the owners of the space authorize ASNFOO/BAR/BAZ that the announcement(s) you see are ok by them" it might also have closed down some of the initial 'WUT?' conversation about these prefixes. -chris

Mel, I hope you're not implementing this in an ISP network, it's not net neutral if a carrier is making a (political) route/filtering decision. (Points to The Great Firewall of China) Ryan -----Original Message----- From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> On Behalf Of Mel Beckman Sent: Saturday, April 24, 2021 4:17 PM To: William Herrin <bill@herrin.us> Cc: nanog@nanog.org Subject: Re: DoD IP Space Bill, It’s the INTERNET that is civilian, not the IP space. As long as that IP space was isolated to the .mil network, it was private space, as far as the Internet was concerned. Now DoD has moved it into the civilian Internet, and I treat them as potentially malicious as I do any other organization that lies, cheats, and steals the public trust. -mel

On Apr 24, 2021, at 3:45 PM, William Herrin <bill@herrin.us> wrote:

On Sat, Apr 24, 2021 at 8:26 AM Mel Beckman <mel@beckman.org> wrote:

...

This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum.

You do understand that the addresses in question are not and have never been "civilian." They came into DoD's possession when this was all still a military project funded by what's now DARPA.

Personally, I think we may have an all time record for the largest honeypot ever constructed. I'd love to be a fly on that wall.

Regards, Bill Herrin

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

As long as that IP space was isolated to the .mil network, it was private space, as far as the Internet was concerned.

The DoD allocation of 11/8 predates the concept of 'private network space'. 11/8 was first assigned to the DoD in RFC 943 in April of 1985. The concept of IPv4 space for private networks was first defined in RFC 1597, March 1994. (Which eventually would become RFC1918. ) The fact that certain parties decided on their own that space not present in the global routing table was 'fair game' or 'private' doesn't make them correct, it simply makes them ill informed. On Sat, Apr 24, 2021 at 7:18 PM Mel Beckman <mel@beckman.org> wrote:

Bill,

It’s the INTERNET that is civilian, not the IP space. As long as that IP space was isolated to the .mil network, it was private space, as far as the Internet was concerned. Now DoD has moved it into the civilian Internet, and I treat them as potentially malicious as I do any other organization that lies, cheats, and steals the public trust.

-mel

...

On Apr 24, 2021, at 3:45 PM, William Herrin <bill@herrin.us> wrote:

On Sat, Apr 24, 2021 at 8:26 AM Mel Beckman <mel@beckman.org> wrote:

...

This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum.

You do understand that the addresses in question are not and have never been "civilian." They came into DoD's possession when this was all still a military project funded by what's now DARPA.

Personally, I think we may have an all time record for the largest honeypot ever constructed. I'd love to be a fly on that wall.

Regards, Bill Herrin

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

On 26 Apr 2021, at 9:59 AM, Ca By <cb.list6@gmail.com> wrote:

... The fact that certain parties decided on their own that space not present in the global routing table was 'fair game' or 'private' doesn't make them correct, it simply makes them ill informed.

My reading of this thread is that the space is now permanently bogon’d for some honeypot. so yeah, it is fair game. Enjoy the public goods all !

<chuckle> While each network operator is free to make their own decisions on how they configure their routers, I’d personally suggest that folks think twice before considering another parties IP address blocks to be available for private use. Just as no one expected to ever see many of these networks be publicly announced, it would not surprise me in the least to see production applications on these blocks at some point in the near future… /John

This is true and very interesting, but the opposite is also true. They are now reachable from probably nearly anywhere and therefore open for business. 😊 Let's see what will slowly appear in shodan.io and shadowserver.org Jean -----Original Message----- From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of William Herrin Sent: April 24, 2021 6:46 PM To: Mel Beckman <mel@beckman.org> Cc: nanog@nanog.org Subject: Re: DoD IP Space On Sat, Apr 24, 2021 at 8:26 AM Mel Beckman <mel@beckman.org> wrote:

This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum.

You do understand that the addresses in question are not and have never been "civilian." They came into DoD's possession when this was all still a military project funded by what's now DARPA. Personally, I think we may have an all time record for the largest honeypot ever constructed. I'd love to be a fly on that wall. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On 24 Apr 2021, at 6:45 PM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote: On Sat, Apr 24, 2021 at 8:26 AM Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. You do understand that the addresses in question are not and have never been "civilian." They came into DoD's possession when this was all still a military project funded by what's now DARPA. Personally, I think we may have an all time record for the largest honeypot ever constructed. I'd love to be a fly on that wall. Bill - That’s actually a possibility - just join DDS… https://apnews.com/article/technology-business-government-and-politics-b26ab... ‘ "The big Pentagon internet mystery now partially solved” …. After weeks of wonder by the networking community, the Pentagon has now provided a very terse explanation for what it’s doing. But it has not answered many basic questions, beginning with why it chose to entrust management of the address space to a company that seems not to have existed until September. The military hopes to “assess, evaluate and prevent unauthorized use of DoD IP address space,” said a statement issued Friday by Brett Goldstein, chief of the Pentagon’s Defense Digital Service<https://www.defense.gov/Explore/News/Article/Article/1858615/defense-digital-service-delivers-mission-aligned-tech-for-dod/>, which is running the project. It also hopes to “identify potential vulnerabilities” as part of efforts to defend against cyber-intrusions by global adversaries, who are consistently infiltrating U.S. networks, sometimes operating from unused internet address blocks. ' FYI, /John John Curran President and CEO American Registry for Internet Numbers

On 25/04/2021 3:24 am, Mel Beckman wrote:

This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us.

 -mel

Why does anyone on the Internet need to publish to your arbitrary standards, what they intend to do with their IP address ranges? Failure to advertise the IP address space to the Internet (until now, perhaps) doesn't make the address space any less legitimate, and though I'd expect the DoD to generally comply with all of the expected norms around BGP arrangements and published whois details, at the end of the day, they can nominate who should originate it from their AS and as long as we can see who owns it.... it's just not our business. Any organisation who's used DoD space in a way that's likely to conflict with, well, the DoD, gambled and lost. Mark.

On Apr 25, 2021, at 9:40 AM, Mel Beckman <mel@beckman.org> wrote: It’s a direct militarization of a civilian utility.

I think I’d characterize it, rather, as a possible privatization of public property. If someone builds a house in the middle of a public park, it’s not _what they’re doing in the house_ that concerns me. -Bill

----- On Apr 25, 2021, at 2:24 AM, Bill Woodcock woody@pch.net wrote: Hi,

I think I’d characterize it, rather, as a possible privatization of public property.

This comment sparked my curiosity. Does ARIN consider IP space to be property? One could argue both ways: 1. Whomever "owns" a netblock simply owns the right to use and advertise it as long as it's being used for the purposes under which it was assigned by a number registry. This would be similar to "apartment rights" in a condominium complex. OR; 2. IP space comes with property rights such as selling and leasing as one wishes. But, that would also imply that IP space can be stolen. I'd be curious to hear what ARIN's position is on this. Thanks, Sabri

Hi Mel, I'd expect ARIN to hold them to account for complying with ARIN rules, if they are subject.  In years gone by, I have been able to contact US DoD organisations using published contact methods to address technical issues. So even if there's technical non-compliance (which i'd agree should be addressed), it could be a lot worse. As for the DoD's accountability via your system of government, my view would be that instead of bogon-filtering addresses legitimately appearing in your BGP, with the justification being "they havn't before!", you could consider asking them via channels. Like https://open.defense.gov/transparency/foia.aspx for example.  But i'm not a citizen of the United States, so will happily plead ignorance as to whether this is likely to lead you to what you want to know or not. In my country the government is also accountable to the people. But that doesn't mean I would expect an Internet Service Provider to deliberately sabotage the network access of their customers, either. Starts to feel like a net neutrality argument again. Mark. PS: If DoD make use of IP address space that they legitimately hold, i'm not sure you can call it a civilian resource, despite it interacting with civilian counterparts.  Any consumable held by a military organisation is a military resource and they'll make use of it based on their operational requirements. The best comparison I could think of, would be fuel (gasoline/petroleum/diesel/Jet-A1), all of which has both military and civilian application. On 25/04/2021 7:40 pm, Mel Beckman wrote:

Mark,

ARIN rules require every IP space holder to publish accurate — and effective — Admin, Tech, and Abuse POCs. The DOD hasn’t done this, as I pointed out, and as you can test for yourself. Your expectation that the DOD will “generally comply with all of the expected norms” is sorely naive, and already disproven.

As far as “why does anyone on the Internet need to publish to your arbitrary standards”, you seem to forget that in the U.S., the government is accountable to the People. Where a private company may not have to explain its purposes, the government most certainly does in the private sector. With these IP spaces being thrust into the civilian realm, yes, they owe the citizenry an explanation of their actions, just as they would if they had started mounting missile launchers on highway overpasses. It’s a direct militarization of a civilian utility.

Keep in mind that the U.S. Government — under all administrations — has shown that it will abuse every technical advantage it can, as long as it can do so in secret. Perhaps you’ve forgotten James Clapper, the former director of national intelligence, who falsely testified to Congress that the government does “not wittingly” collect the telephone records of millions of Americans. And he was just the tip of the iceberg. Before Clapper under Obama there was the Bush administration’s Stellar Wind" warrantless surveillance program. The list of government abuse of civilian resources is colossal .

Fighting against that isn’t political. It’s patriotic.

-mel

...

On Apr 25, 2021, at 12:02 AM, Mark Foster <blakjak@blakjak.net> wrote:



...

On 25/04/2021 3:24 am, Mel Beckman wrote: This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us.

-mel

Why does anyone on the Internet need to publish to your arbitrary standards, what they intend to do with their IP address ranges?

Failure to advertise the IP address space to the Internet (until now, perhaps) doesn't make the address space any less legitimate, and though I'd expect the DoD to generally comply with all of the expected norms around BGP arrangements and published whois details, at the end of the day, they can nominate who should originate it from their AS and as long as we can see who owns it.... it's just not our business.

Any organisation who's used DoD space in a way that's likely to conflict with, well, the DoD, gambled and lost.

Mark.

Except these DoD blocks don’t fall under ARIM justification, as they predate ARIN. It is very likely that the DoD has never and will never sign any sort of ARIN agreement. Sent from my iPhone

On Apr 25, 2021, at 3:40 AM, Mel Beckman <mel@beckman.org> wrote:

Mark,

ARIN rules require every IP space holder to publish accurate — and effective — Admin, Tech, and Abuse POCs. The DOD hasn’t done this, as I pointed out, and as you can test for yourself. Your expectation that the DOD will “generally comply with all of the expected norms” is sorely naive, and already disproven.

As far as “why does anyone on the Internet need to publish to your arbitrary standards”, you seem to forget that in the U.S., the government is accountable to the People. Where a private company may not have to explain its purposes, the government most certainly does in the private sector. With these IP spaces being thrust into the civilian realm, yes, they owe the citizenry an explanation of their actions, just as they would if they had started mounting missile launchers on highway overpasses. It’s a direct militarization of a civilian utility.

Keep in mind that the U.S. Government — under all administrations — has shown that it will abuse every technical advantage it can, as long as it can do so in secret. Perhaps you’ve forgotten James Clapper, the former director of national intelligence, who falsely testified to Congress that the government does “not wittingly” collect the telephone records of millions of Americans. And he was just the tip of the iceberg. Before Clapper under Obama there was the Bush administration’s Stellar Wind" warrantless surveillance program. The list of government abuse of civilian resources is colossal .

Fighting against that isn’t political. It’s patriotic.

-mel

...

On Apr 25, 2021, at 12:02 AM, Mark Foster <blakjak@blakjak.net> wrote:



...

...

On 25/04/2021 3:24 am, Mel Beckman wrote: This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us.

-mel

Why does anyone on the Internet need to publish to your arbitrary standards, what they intend to do with their IP address ranges?

Failure to advertise the IP address space to the Internet (until now, perhaps) doesn't make the address space any less legitimate, and though I'd expect the DoD to generally comply with all of the expected norms around BGP arrangements and published whois details, at the end of the day, they can nominate who should originate it from their AS and as long as we can see who owns it.... it's just not our business.

Any organisation who's used DoD space in a way that's likely to conflict with, well, the DoD, gambled and lost.

Mark.

So you are claiming that ARIN has jurisdiction over DoD IP space? Sent from my iPhone

On Apr 25, 2021, at 9:13 AM, John Curran <jcurran@arin.net> wrote:

 Sronan -

I’d suggest asking rather than making assertions when it comes to ARIN, as this will avoid propagating existing misinformation in the community.

Many US government agencies, including the US Department of Defense, have signed registration services agreements with ARIN.

From https://account.arin.net/public/member-list -

United States Department of Defense (DoD) USDDD

Thanks! /John

John Curran President and CEO American Registry for Internet Numbers

...

...

On 25 Apr 2021, at 8:54 AM, sronan@ronan-online.com wrote:

Except these DoD blocks don’t fall under ARIM justification, as they predate ARIN. It is very likely that the DoD has never and will never sign any sort of ARIN agreement.

Sent from my iPhone

On Apr 25, 2021, at 3:40 AM, Mel Beckman <mel@beckman.org> wrote:

Mark,

ARIN rules require every IP space holder to publish accurate — and effective — Admin, Tech, and Abuse POCs. The DOD hasn’t done this, as I pointed out, and as you can test for yourself. Your expectation that the DOD will “generally comply with all of the expected norms” is sorely naive, and already disproven.

As far as “why does anyone on the Internet need to publish to your arbitrary standards”, you seem to forget that in the U.S., the government is accountable to the People. Where a private company may not have to explain its purposes, the government most certainly does in the private sector. With these IP spaces being thrust into the civilian realm, yes, they owe the citizenry an explanation of their actions, just as they would if they had started mounting missile launchers on highway overpasses. It’s a direct militarization of a civilian utility.

Keep in mind that the U.S. Government — under all administrations — has shown that it will abuse every technical advantage it can, as long as it can do so in secret. Perhaps you’ve forgotten James Clapper, the former director of national intelligence, who falsely testified to Congress that the government does “not wittingly” collect the telephone records of millions of Americans. And he was just the tip of the iceberg. Before Clapper under Obama there was the Bush administration’s Stellar Wind" warrantless surveillance program. The list of government abuse of civilian resources is colossal .

Fighting against that isn’t political. It’s patriotic.

-mel

...

On Apr 25, 2021, at 12:02 AM, Mark Foster <blakjak@blakjak.net> wrote:



...

...

On 25/04/2021 3:24 am, Mel Beckman wrote: This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us.

-mel

Why does anyone on the Internet need to publish to your arbitrary standards, what they intend to do with their IP address ranges?

Failure to advertise the IP address space to the Internet (until now, perhaps) doesn't make the address space any less legitimate, and though I'd expect the DoD to generally comply with all of the expected norms around BGP arrangements and published whois details, at the end of the day, they can nominate who should originate it from their AS and as long as we can see who owns it.... it's just not our business.

Any organisation who's used DoD space in a way that's likely to conflict with, well, the DoD, gambled and lost.

Mark.

In the positive side of things, guess we will see IPv6 usage. Joe Klein On Sun, Apr 25, 2021, 6:11 PM John Curran <jcurran@arin.net> wrote:

Sronan -

I made no claims other than pointing out that IP address blocks in the ARIN registry are subject to ARIN policies.

ARIN was formed specifically so that the Internet community could engage in self-regulation for IP number resources; to wit: "Creation of ARIN will give the users of IP numbers (mostly Internet service providers, corporations and other large institutions) a voice in the policies by which they are managed and allocated within the North American region” [1] – thus ARIN's policies for management of the registry apply to all resources in the registry because that was inherent to the purpose to which ARIN was formed.

This includes having ARIN "assume full responsibility for Internet Protocol (IP) number assignments and related administrative tasks previously handled by NSI.”, whereby ARIN formally became the successor registry operator for organizational assignments in a long chain that includes USC/ISI, SRI, GSI, and NSI.

The community wanted self-governance, and that’s exactly what it got… the result is a fairly important reason to participate in ARIN policy development and/or governance if you feel strongly about these matters.

Thanks! /John

John Curran President and CEO American Registry for Internet Numbers

[1] https://www.nsf.gov/news/news_summ.jsp?cntn_id=102819 - "Internet Moves Toward Privatization / IP numbers handled by non-profit”

On Apr 25, 2021, at 11:38 AM, sronan@ronan-online.com wrote:

 So you are claiming that ARIN has jurisdiction over DoD IP space?

Sent from my iPhone

On Apr 25, 2021, at 9:13 AM, John Curran <jcurran@arin.net> wrote:

 Sronan -

I’d suggest asking rather than making assertions when it comes to ARIN, as this will avoid propagating existing misinformation in the community.

Many US government agencies, including the US Department of Defense, have signed registration services agreements with ARIN.

From https://account.arin.net/public/member-list -

United States Department of Defense (DoD)

USDDD <https://search.arin.net/rdap?query=USDDD&searchFilter=entity>

Thanks! /John

John Curran President and CEO American Registry for Internet Numbers

On 25 Apr 2021, at 8:54 AM, sronan@ronan-online.com wrote:

Except these DoD blocks don’t fall under ARIM justification, as they predate ARIN. It is very likely that the DoD has never and will never sign any sort of ARIN agreement.

Sent from my iPhone

On Apr 25, 2021, at 3:40 AM, Mel Beckman <mel@beckman.org> wrote:

Mark,

ARIN rules require every IP space holder to publish accurate — and effective — Admin, Tech, and Abuse POCs. The DOD hasn’t done this, as I pointed out, and as you can test for yourself. Your expectation that the DOD will “generally comply with all of the expected norms” is sorely naive, and already disproven.

As far as “why does anyone on the Internet need to publish to your arbitrary standards”, you seem to forget that in the U.S., the government is accountable to the People. Where a private company may not have to explain its purposes, the government most certainly does in the private sector. With these IP spaces being thrust into the civilian realm, yes, they owe the citizenry an explanation of their actions, just as they would if they had started mounting missile launchers on highway overpasses. It’s a direct militarization of a civilian utility.

Keep in mind that the U.S. Government — under all administrations — has shown that it will abuse every technical advantage it can, as long as it can do so in secret. Perhaps you’ve forgotten James Clapper, the former director of national intelligence, who falsely testified to Congress that the government does “not wittingly” collect the telephone records of millions of Americans. And he was just the tip of the iceberg. Before Clapper under Obama there was the Bush administration’s Stellar Wind" warrantless surveillance program. The list of government abuse of civilian resources is colossal .

Fighting against that isn’t political. It’s patriotic.

-mel

On Apr 25, 2021, at 12:02 AM, Mark Foster <blakjak@blakjak.net> wrote:



On 25/04/2021 3:24 am, Mel Beckman wrote:

This doesn’t sound good, no matter how you slice it. The lack of transparency with a civilian resource is troubling at a minimum. I’m going to bogon this space as a defensive measure, until its real — and detailed — purpose can be known. The secret places of our government have proven themselves untrustworthy in the protection of citizens’ data and networks. They tend to think they know “what’s good for” us.

-mel

Why does anyone on the Internet need to publish to your arbitrary standards, what they intend to do with their IP address ranges?

Failure to advertise the IP address space to the Internet (until now, perhaps) doesn't make the address space any less legitimate, and though I'd expect the DoD to generally comply with all of the expected norms around BGP arrangements and published whois details, at the end of the day, they can nominate who should originate it from their AS and as long as we can see who owns it.... it's just not our business.

Any organisation who's used DoD space in a way that's likely to conflict with, well, the DoD, gambled and lost.

Mark.