Re: On consistency and 192.0.0.0/24

[borg]

From what I looked at IANA Special Registry, this whole range looks
like some service IPs. I mean, they provide specific service within AS.
From me then, it looks like bogon. You should not receive routing for those
addresses from other AS. (PNI is out of scope here).


-- Original message --

From: Tom Beecher 
To: "Jakob Heitz (jheitz)" 
Cc: "nanog@nanog.org" 
Subject: Re: On consistency and 192.0.0.0/24
Date: Tue, 14 May 2024 13:24:47 -0400

>
> That means that some IP addresses in the block 192.0.0.0/24 may be
> routable.
>
> So, I would not make this a bogon.
>

This ignores note 2 on the IANA definitions page, next to 192.0.0.0/24 :

> [2]
>
> Not useable unless by virtue of a more specific reservation.
>
>  Which then lists the more specific reservations, of which SOME are
forwardable , and some are not.

The categorization as 'bogon' or not would really be determined by
individual operator use cases, and where/how such a bogon filter is
applied.



On Tue, May 14, 2024 at 12:23˙˙PM Jakob Heitz (jheitz) via NANOG <
nanog@nanog.org> wrote:

> RFC 5736 was obsoleted by RFC 6890.
>
> It says in part:
>
>
>
> 2.2.1.  Information Requirements
>
>
>
>The IPv4 and IPv6 Special-Purpose Address Registries maintain the
>
>following information regarding each entry:
>
> ˙˙
>
>o  Forwardable - A boolean value indicating whether a router may
>
>   forward an IP datagram whose destination address is drawn from the
>
>   allocated special-purpose address block between external
>
>   interfaces.
>
> ˙˙
>
>
>
> That means that some IP addresses in the block 192.0.0.0/24 may be
> routable.
>
> So, I would not make this a bogon.
>
>
>
> A better way to filter IP routes is by policy, for example based upon
>
> IRR and RPKI records.
>
>
>
> Kind Regards,
>
> Jakob
>
>
>
> -- Original message --
>
> Date: Tue, 14 May 2024 12:00:15 +0200 (CEST)
> From: b...@uu3.net
>
>
> [10] 192.0.0.0/24 reserved for IANA IPv4 Special Purpose Address Registry
> [RFC5736]. Complete registration details for 192.0.0.0/24 are found in
> [IANA registry iana-ipv4-special-registry].
>
> Was RFC5736 obsoleted? I think not, so I would treat it as bogon.
>
> Its a nice tiny subnet for special purposes. I personaly use it
> as my Internal VM Net on my desktop for example.
>
>
> -- Original message --
>
> From: John Kristoff 
> To: NANOG 
> Subject: On consistency and 192.0.0.0/24
> Date: Mon, 13 May 2024 16:18:47 -0500
>
> As one to never let a good academic question go unasked... what is it
> about 192.0.0.0/24 that is or isn't a bogon. This doesn't seem so
> straightforward an answer to me, at least in theory.  Although in
> practice it may already be decided whether one likes the answer or not.
>
> 192.0.0.0/24 was originally assigned to IANA for "protocol assignments"
> in IETF RFC 5736, and later added to the list of reserved / special use
> addresses in IETF RFC 6890 (aka BCP 153).   There is a corresponding
> IPv6 block (2001::/23), but it has a significantly different history.
>
> Team Cymru's bogon list includes the v4 prefix.  NLNOG's bogon
> filtering guide does not.  When I asked Job about NLNOG's position he
> said:
>
>   "I was unsure what this prefix??s future plans would be and erred on
>   the side of caution and didn??t include this prefix in the NLNOG bogon
>   list recommendations."
>
> The /24 as specified is not for "global" use, but some of the more
> specific assignments are or can be.  See:
> <
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
> >.
>
> From my cursory examination I can't find cases where the v4 prefix or
> more specifics have been publicly announced to any significant degree.
> This however is not the case for the IPv6 prefix (e.g., the AS112
> project, Teredo).
>
> Maybe you'd say the /24 should be filtered, but not the more specifics
> that are deemed available for global use.  That might be reasonable,
> except many reasonable people will filter small prefixes.
>
> IANA's language may have put any "do not filter" camp in a relatively
> weak position:
>
>   "Address prefixes listed in the Special-Purpose Address Registry are
>   not guaranteed routability in any particular local or global context."
>
> I can't remember hearing anyone complaining about bogon-related
> reachability problems with the aggregate IANA prefixes generally.  Is
> there a strong case to make that ops should not bogon filter any
> addresses in these prefixes?  At least with IPv4?  What about for IPv6?
>
> John
>
>

Re: On consistency and 192.0.0.0/24

[borg]

No, I am not confusing those two. Actually, Im using 192.0.2.0 as well
here, for server's internal SNAT.

Okey, I checked that registry and there is nothing I care about.
It seems the choice to using 192.0.0.0/24 internally at desktop
was smart enough ;)

Thx for info.


-- Original message --

From: John Kristoff 
To: nanog@nanog.org
Subject: Re: On consistency and 192.0.0.0/24
Date: Tue, 14 May 2024 07:29:54 -0500

On Tue, 14 May 2024 12:00:15 +0200 (CEST)
b...@uu3.net wrote:

> Was RFC5736 obsoleted?

No.

> Its a nice tiny subnet for special purposes. I personaly use it

Are you confusing this with 192.0.2.0/24?  192.0.0.0/24 is occasionally
updated with new assignments drawn from it.  Just be aware you're
potentially colliding with some other, new use in that range.

John

Re: On consistency and 192.0.0.0/24

[borg]

[10] 192.0.0.0/24 reserved for IANA IPv4 Special Purpose Address Registry
[RFC5736]. Complete registration details for 192.0.0.0/24 are found in
[IANA registry iana-ipv4-special-registry].

Was RFC5736 obsoleted? I think not, so I would treat it as bogon.

Its a nice tiny subnet for special purposes. I personaly use it
as my Internal VM Net on my desktop for example.


-- Original message --

From: John Kristoff 
To: NANOG 
Subject: On consistency and 192.0.0.0/24
Date: Mon, 13 May 2024 16:18:47 -0500

As one to never let a good academic question go unasked... what is it
about 192.0.0.0/24 that is or isn't a bogon. This doesn't seem so
straightforward an answer to me, at least in theory.  Although in
practice it may already be decided whether one likes the answer or not.

192.0.0.0/24 was originally assigned to IANA for "protocol assignments"
in IETF RFC 5736, and later added to the list of reserved / special use
addresses in IETF RFC 6890 (aka BCP 153).   There is a corresponding
IPv6 block (2001::/23), but it has a significantly different history.

Team Cymru's bogon list includes the v4 prefix.  NLNOG's bogon
filtering guide does not.  When I asked Job about NLNOG's position he
said:

  "I was unsure what this prefix˙˙s future plans would be and erred on
  the side of caution and didn˙˙t include this prefix in the NLNOG bogon
  list recommendations."

The /24 as specified is not for "global" use, but some of the more
specific assignments are or can be.  See:
.

From my cursory examination I can't find cases where the v4 prefix or
more specifics have been publicly announced to any significant degree.
This however is not the case for the IPv6 prefix (e.g., the AS112
project, Teredo).

Maybe you'd say the /24 should be filtered, but not the more specifics
that are deemed available for global use.  That might be reasonable,
except many reasonable people will filter small prefixes.

IANA's language may have put any "do not filter" camp in a relatively
weak position:

  "Address prefixes listed in the Special-Purpose Address Registry are
  not guaranteed routability in any particular local or global context."

I can't remember hearing anyone complaining about bogon-related
reachability problems with the aggregate IANA prefixes generally.  Is
there a strong case to make that ops should not bogon filter any
addresses in these prefixes?  At least with IPv4?  What about for IPv6?

John

Re: constant FEC errors juniper mpc10e 400g

[borg]

Erm, WAN-PHY did not extend into 40G because there was not much
of those STM-256 deployment? (or customers didnt wanted to pay for those).

WAN-PHY was designed so people could encapsulate Ethernet frames
right into STM-64. Once world moved out of SDH/SONET stuff, there was
no more need for WAN-PHY anymore.


-- Original message --

From: Mark Tinka 
To: Dave Cohen 
Cc: nanog@nanog.org
Subject: Re: constant FEC errors juniper mpc10e 400g
Date: Sat, 20 Apr 2024 17:50:04 +0200


WAN-PHY did not extend to 40G or 100G, which can explain one of the reasons it
lost favour. For 10G, its availability also depended on the type of device, its
NOS, line card and/or pluggable at the time, which made it hard to find a
standard around this if you built multi-vendor networks or purchased backhaul
services from 3rd party providers that had non-standard support for
WAN-PHY/OTN/G.709. In other words, LAN-PHY (and plain Ethernet) became the
lowest common denominator in the majority of cases for customers.

Mark.

Re: puck not responding

[borg]

Yeah, thats cool. It reminds me good old internet from 90's and early 2000.

Anyway, if that list is so importand, maybe its time to run
it with redundancy of 1+N (master-slave topology)? Its all MTAs
so its pretty easy, all you need to sync data from master to slaves
via push (best, because its nearly instant). Slave down? Nothing really
happened. Master down? next Slave takes over and bring Master online or
nominate any of those slaves as new Master.


-- Original message --

From: Jared Mauch 
To: Jay Acuna 
Cc: nanog@nanog.org
Subject: Re: puck not responding
Date: Thu, 29 Feb 2024 10:58:17 -0500



> On Feb 29, 2024, at 10:56˙˙AM, Jay Acuna  wrote:
> 
> On Thu, Feb 29, 2024 at 9:22˙˙AM Jared Mauch  wrote:
>> 
> 
> Apparently some of the most important email lists, Outages, etc, are
> being kept online by 1 person's  Unix/Linux server.
> 

There˙˙s other people who have access etc, but when it comes to hardware that 
is quite old, last substantive refresh was in 2011, it˙˙s served its purpose 
well.

Obligatory xkcd https://xkcd.com/2347/

Re: starlink ixp peering progress

[borg]

Well, for some basic overview you can use CAIDA AS rank.

You can use it directly, or you may try my (more user friendly)
frontend for it: http://as-rank.uu3.net/?as=14593


-- Original message --

From: Dave Taht 
To: NANOG 
Subject: starlink ixp peering progress
Date: Tue, 27 Feb 2024 02:54:44 -0500

One of the things I learned today was that starlink has published an
extensive guide as to how existing BGP AS holders can peer with them
to get better service.

https://starlink-enterprise-guide.readme.io/docs/peering-with-starlink

I am curious if there is a way to see how many have peered already,
how many they could actually peer with?, and progress over time since
inception what would be the right tools for that? This is pretty
impressive for peering so far:

https://www.peeringdb.com/net/18747

Is there a better email list to discuss ixp stuff?


-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[borg]

I could NOT agree more. Even tho, I am IPv6 phobic, let IPv4 go away.
At least, make it go away from mainstream commercial Internet.
90% users do NOT care about it. They want to browse web, watch movies
or play games. They can do it using IPv6.
I cant wait :) more IPv4 address space for people like me and our projects.


-- Original message --

From: Owen DeLong via NANOG 
To: Abraham Y. Chen 
Cc: "Chen, Abraham Y." , nanog@nanog.org
Subject: Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address
block
Date: Fri, 12 Jan 2024 08:45:22 -0800

Frankly, I care less. No matter how you use whatever IPv4 space you
attempt to cajole into whatever new form of degraded service, the simple
fact remains. IPv4 is a degraded technology that only continues to get
worse over time. NAT was bad. CGNAT is even worse (and tragically does
nothing to eliminate consumer NAT, just layers more disaster on top of
the existing mess). 

The only currently available end to end peer to peer technology, for
better or worse, is IPv6. Despite its naysayers, it is a proven
technology that has been shouldering a significant fraction of internet
traffic for many years now and that fraction continues to grow.

You simply can˙˙t make IPv4 adequate and more hackers to extend its life
merely expands the amount of pain and suffering we must endure before it
is finally retired. 

Owen


  On Jan 12, 2024, at 03:46, Abraham Y. Chen
   wrote:

  ˙˙ Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement
IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
  Abraham,

You're arguing semantics instead of the actual
point. Residential customers want Internet access, not
intranet access. Again, VRFs are plentiful and so are CG-NAT
firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG  on
behalf of Abraham Y. Chen 
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 
Cc: nanog@nanog.org 
Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4
address block


Caution: This is an external email and may be malicious.
Please take care when clicking links or opening attachments.

Hi, Michael:

1)" ... While you may be able to get packets from point A
to B in a private setting, using them might also be .. a
challenge. ...   ":

EzIP uses 240/4 netblock only within the RAN (Regional
Area Network) as "Private" address, not "publicly" routable,
according to the conventional Internet definition. This is
actually the same as how 100.64/10 is used within CG-NAT. 

2)However, this might be where the confusion comes from.
With the geographical area coverage so much bigger, an RAN is
effectively a public network. To mesh the two for
consistency, we defined everything related to 240/4 as
"Semi-Public" to distinguish this new layer of networking
facility from the current public / private separation. That
is, the CG-NAT routers will become SPRs (Semi-Public Routers)
in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,


Abe (2024-01-11 12:21)
 


On 2024-01-10 10:45, Michael Butler via NANOG wrote:
  On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice,
and understand the full context.

240/4 is still classified as RESERVED
space. While you would certainly be
able to use it on internal networks
if your equipment supports it, you
cannot use it as publicly routable
space. There have been many proposals
over the years to reclassify 240/4,
but that has not happened, and is
unlikely to at any point in the
foreseeable future.


  While you may be able to get packets from point A
  to B in a private setting, using them might also
  be .. a challenge.

  There's a whole bunch of software out there that
  makes certain assumptions about allowable ranges.
  That is, they've been compiled with a header that
  defines ..

  #define IN_BADCLASS(i)(((in_addr_t)(i) &
  0xf000) == 0xf000)

  Michael



[icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
Virus-free.www.avast.com

Re: ipv6 address management - documentation

[borg]

I use my own console/terminal based stuff.
Its composed of 2 main scripts called blgrep for searching
and bldiff to display differences between revision/files.
Backend is SVN to keep stuff in sync and allow multiple people
to work on data.

Works pretty well for small/medium DC/NOC. I guess it wont scale much tho.

We used to have Excel files for those too years ago and it was madness.


-- Original message --

From: Aaron Gould 
To: nanog@nanog.org
Subject: ipv6 address management - documentation
Date: Thu, 16 Nov 2023 12:02:36 -0600

For years I've used an MS Excel spreadsheet to manage my IPv4 addresses.  IPv6
is going to be maddening to manage in a spreadsheet.  What does everyone use for
their IPv6 address prefix management and documentation?  Are there open source
tools/apps for this?

-- 
-Aaron

Re: .US Harbors Prolific Malicious Link Shortening Service

[borg]

Yeah. I wonder why this cannot be reversed really?
First domain registration should cost more.. 50 USD maybe? Dunno.
And then, when you want to extend the domain, price should be
around 5 times lower?

Those who want to use it for legal activity will chew that little CAPEX.


-- Original message --

From: Eric Kuhnke 
To: goe...@sasami.anime.net
Cc: NANOG list 
Subject: Re: .US Harbors Prolific Malicious Link Shortening Service
Date: Thu, 2 Nov 2023 20:39:17 -0700

Not specific to .US really

Pretty much every new gTLD that can be registered on "promotional" first
year prices below .com/.net/.org harbors a large than usual proportion of
phishing domains and suspicious things, because one of the sole operational
criteria for phishers registering disposable domains that might have useful
lives of only hours or a few days, in bulk, is the cost per unit.


".us" is in much the same situation because I am seeing promotional prices
of $4.50 to $5 per domain for the first year.





On Thu, Nov 2, 2023 at 1:31˙˙PM goemon--- via NANOG  wrote:

>
> https://krebsonsecurity.com/2023/10/us-harbors-prolific-malicious-link-shortening-service/
>
> "The NTIA recently published a proposal that would allow registrars to
> redact all registrant data from WHOIS registration records for .US
> domains. A broad array of industry groups have filed comments opposing the
> proposed changes, saying they threaten to remove the last vestiges of
> accountability for a top-level domain that is already overrun with
> cybercrime activity."
>
> What hope is there when registrars are actively aiding and abeting
> criminal enterprises?
>
> Are there any legitimate services running solely on .us domain names?
>
> -Dan
>

Re: maximum ipv4 bgp prefix length of /24 ?

[borg]

Well, I think the sane solution would be to push customers/clients
into IPv6 and keep services IPv4. Then start moving services to dualstack.

Most of todays customers/clients are consumers. They just connect to server
to get data, watch movies, listen to music. Gaming is similar. That way,
ISPs could do NAT64 thingie to provide IPv6 -> IPv4 bridges. More IPv4
addresses would be freed for power users. After decade, IPv4 could be nearly 
gone.

If only IPv6 would suck so badly... ;)


-- Original message --

From: Delong.com via NANOG 
To: Matthew Petach 
Cc: Geoff Huston , Delong.com via NANOG 
Subject: Re: maximum ipv4 bgp prefix length of /24 ?
Date: Tue, 10 Oct 2023 15:43:28 -0700

Im not sure that we never acknowledged it, but we did fail to address it,
largely because I think we basically determined that its too hard.

Theres really no way for a machine with a >32 bit address to
feasibly/reliably talk to a machine that only understands 32-bit addresses
short of involving some sort of intermediate proxy host doing some form of
address translation. Weve actually got LOTS of those solutions deployed with
varying levels of success/failure/idiosyncrasies. Ive spent a fair amount of
time thinking about alternatives and admit that I, myself am stumped as to
how one would go about this.

Do you have a proposal for how this problem could have been/could be solved?

Re: ARIN email address (was cogent spamming directly from ARIN records?)

[borg]

This is not the outcome of internet ecosystem, this is outcome
of commercialization, where money is what is all cared, not good
product, ethical behavior, etc.

This is also because good guys do NOT fight back strong enough.
Cogent start to give you hard time? Start to filter they whole
prefixes? Maybe depeer them?

I know this sound extreme, but.. everything else seems to fail..


-- Original message --

From: Christopher Morrow 
To: nanog@nanog.org
Subject: Re: ARIN email address (was cogent spamming directly from ARIN
records?)
Date: Tue, 3 Oct 2023 15:48:11 -0400

i agree this is a sad outcome of the internet ecosystem.

> We keep discussing it because we care about keeping the internet
> running. It's similar to why we keep looking for new security holes in
> existing software: we don't stop because inevitably we'll find more so
> it's a lost cause, we keep looking because inevitably we'll find more
> so the product becomes more secure.

those are a bit of a false equivalence... but... ok.
I think: "Oh look, more spam, delete"
is basically how this sort of problem (email from randos trying to
sell me ED pills or 10Gs) should be treated.
I don't know that it's helpful to keep re-litigating that end state :(

I'm sure telling dave shaeffer: "Hey, your sales droids are being
rude" is going to end as well as sending him ED pill emails.

Re: Dodgy AS327933 ...?

[borg]

Haha :) you are right.
I just checked Caida AS ranking:
http://as-rank.uu3.net/?as=2

A lot of "providers" for UDEL-DCN. Yeah right..
They all indeed probably try to prepend their AS 2 times
ending up having ASN 2 in path.


-- Original message --

From: Mike Davis 
To: nanog@nanog.org
Subject: Re: Dodgy AS327933 ...?
Date: Thu, 10 Aug 2023 09:24:32 -0400

AS2 is the most hijacked prefix in the world.  Yes UD still owns it,
but since different router vendors use different methods of prepending
AS numbers, many folks try to prepend twice and end up announcing
on AS2..

thanks
mike

On 8/10/23 9:02 AM, Mark Tinka wrote:
> 
> 
> On 8/10/23 11:38, Frank Habicht wrote:
> 
> > 
> > from a 2019 DB snapshot:
> > 
> > aut-num:    AS327933
> > as-name:    GROUPE-TELECOM-SPRL
> > descr:  GROUPE TELECOM SPRL
> > status: ASSIGNED
> > org:    ORG-GTS2-AFRINIC
> > admin-c:    YM8-AFRINIC
> > tech-c: YM9-AFRINIC
> > notify: ***@gtl-rdcongo.com
> > mnt-lower:  GTS2-MNT
> > mnt-routes: GTS2-MNT
> > mnt-by: AFRINIC-HM-MNT
> > changed:    ***@afrinic.net 20150917
> > source: AFRINIC
> > 
> > I think the most common way to get out of this DB is to not pay something.
> > 
> > I'd guess that
> > 
> > aut-num:    AS37451
> > as-name:    CongoTelecom
> > descr:  CONGO TELECOM
> > 
> > has a relationship with them and AS327933 wanted to prepend 2x [1] to their
> > sole provider.  (AS37451)
> 
> We are seeing some weird routing from them, and the AS2 they are attached to
> (University of Delaware) seems odd.
> 
> Not sure if any of the American folk on this list can verify AS2 is really
> part of the University of Delaware...
> 
> Mark.

-- 
 Mike Davis
 Lead Network Architect
 University of Delaware - 302.831.8756
 Newark, DE 19716Email da...@udel.edu

Re: malware warning

[borg]

Thats not it.. But I finally found it:
https://blog.apnic.net/2018/07/12/shutting-down-the-bgp-hijack-factory/


-- Original message --

From: Niels Bakker 
To: nanog@nanog.org
Subject: Re: malware warning
Date: Sat, 22 Jul 2023 19:42:58 +0200

* b...@uu3.net (b...@uu3.net) [Sat 22 Jul 2023, 10:24 CEST]:
> The only interesting action I ever saw was:
> "Shutting down email spam factory"; where some network was depeered from
> internet completly. Well done.
> (Somehow I cannot find post about that anymore).

AGIS: https://en.wikipedia.org/wiki/Apex_Global_Internet_Services


-- Niels.

Re: malware warning

[borg]

Oh, just dont bother. The battle is over and we lost it, because
good people are too soft.

The only interesting action I ever saw was:
"Shutting down email spam factory"; where some network was depeered
from internet completly. Well done.
(Somehow I cannot find post about that anymore).

The only sane action I see is go virtual. I mean, create overlay
virtual network, make VPN PoPs and put services there.
Looks kinda over kill maybe, but at least, we get back the control.


-- Original message --

From: Bryan Fields 
To: nanog@nanog.org
Subject: Re: malware warning
Date: Fri, 21 Jul 2023 22:49:18 -0400

On 7/18/23 9:14 PM, Randy Bush wrote:
> i did not think i was special, and assumed everybody is getting them.
> but i figured that if i kept one or three people from falling for the
> trap it was worth the pollution.

I've done quite a bit of looking into this, tying to prevent it.  It's not
being pulled from the archives.

The basic premise of it:

1. send email only to direct posters to the list, never through the list.
2. subscribe using a gmail account as a normal member for harvesting
3. scrape the new posts and use email in from: header to send spam to
4. wait some $TIME after the post and send the spam
5. The spam will never be able to be linked to the subscribed account

I've been able to track these "ingestion" accounts and kill them when found,
but it's impossible to do it without false positives.  VERP is used for the
list emails, but short of a bounce, that doesn't really help.

About the only supported option that would mitigate this is wrapping all posts
through the list as from the list.  This still would expose the email
addresses in the email, and we could rewrite them, but it breaks more than it
fixes.

I've seen proposals where all messages get wrapped and each individual email
address found in the message is re-written to a unique address via a mail
forwarding domain, but i can't see this working with such a diverse list.
This also would break after some time.  This is also not something supported
off the shelf in most mailman or other MLMs.

I'd love to kill this spam, but the openness of the email discussion list
format makes it hard to do.  If anyone has ideas on how we can kill this I'd
love to shut it down.

-- 
Bryan Fields

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

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[borg]

Heh, its kinda sad that noone mentions space environment impact at all.
How that 40k sats will pollute already decently pulluted orbit.

I wonder if decommision process will be clean (burn in atmosphere).
If there will be failure rate, we will end up w/ dead sats at orbit.

I really wonder if thats really necessary. I think that money could be
better spent building earth infra reaching those under-serviced places.
Cheaper, easy maintenance, less centralization.

We also need orbit for more importand sats out there than internet.
GPS, earth monitoring infra, space telescopes, R&D.


-- Original message --

From: Tom Beecher 
To: Dave Taht 
Cc: nanog@nanog.org
Subject: Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps
Date: Sat, 17 Jun 2023 21:11:53 -0400

>
> The principal barriers to another launch are a successful test of the
> new water deluge system, and qualifying a more advanced flight
> termination system.
>

The fact that not only they tested WITHOUT a water deluge system the first
time, OR a flame trench, is why the Cult of Musk will continue to hold them
back. It's fascinating to me to watch him 'discover' solutions to problems
solved 50 years ago that he chose to ignore.

The environmental impact was far less than believed. An analysis of
> the dust spread across town was shown to just be sand, not vaporised
> fondag,
> as thought.
>

The easily predictable environmental damage around the launch area still
exists and is significant, and will take them months to clean up via the
terms of their contract with the state of Texas.

There is really massive construction going on, replacing the existing
> megabay, the damaged tanks are being replaced rapidly, the launch site
> has been dug out and partially repaired,  and a new launch license was
> issued for the next 6 months last week.
>

Also here, the fact that they even have LOX and CH4 thanks THAT CLOSE to
the pad itself is borderline negligent, but still absolutely mind
boggling.


On Sat, Jun 17, 2023 at 8:04˙˙PM Dave Taht  wrote:

> On Sat, Jun 17, 2023 at 5:16˙˙PM Tom Beecher  wrote:
> >>
> >> Also: they plan to use Starship when it's available which has 10x more
> capacity. If it really is fully reusable as advertised, that is going to
> really drive down the launch cost.
> >
> >
> > Starship is years away from being flight ready. The most recent test
> launch from Texas was not a 'successful failure' as widely portrayed in the
> media.  Reputable people who have been working in this field for decades
> have pointed out tons of massive problems that are not quick fixes.
>
> 1) I agree that they are years from flight ready, however the
> improvements in the queue for the next launch are already impressive.
> A lot of nay-saying concerns have been addressed since the launch.
>
> The environmental impact was far less than believed. An analysis of
> the dust spread across town was shown to just be sand, not vaporised
> fondag,
> as thought.
>
> While the everyday astronaut and starbase_csi can be thought of as
> fanbois, they are also producing the most quality reporting and
> analysis that exists:
>
> https://twitter.com/Erdayastronaut
> https://twitter.com/CSI_Starbase
>
> They are good folk to track.
>
> Eric Burger is a more conventional tech journalist covering all of space:
>
> https://twitter.com/SciGuySpace
>
> https://arstechnica.com/author/ericberger/
>
> There are an amazing number of individuals reporting on daily
> progress, with live video feeds.
>
> There is really massive construction going on, replacing the existing
> megabay, the damaged tanks are being replaced rapidly, the launch site
> has been dug out and partially repaired,  and a new launch license was
> issued for the next 6 months last week.
>
> The principal barriers to another launch are a successful test of the
> new water deluge system, and qualifying a more advanced flight
> termination system. The next ship and booster will possibly be tested
> next month, and these have replaced the hydrolic controls with
> electric and have better motor shielding in general.
>
> Yes, an utterly amazing amount of things need to go right to launch a
> spaceship, but ... my best bet for another launch of starship would be
> early september.
>
>
> >
> > On Sat, Jun 17, 2023 at 6:56˙˙PM Michael Thomas  wrote:
> >>
> >> Whether or not it makes business sense isn't really what I was talking
> about. I was talking about the home dish costing $1k. That sounds like it
> could easily be reduced significantly unless there is some underlying tech
> reason.
> >>
> >> Also: they plan to use Starship when it's available which has 10x more
> capacity. If it really is fully reusable as advertised, that is going to
> really drive down the launch cost.
> >>
> >> But your calculations don't take into account that they are not at
> anywhere close to a full constellation: they are only at 4k out of the 40k
> they need so they literally can't support higher numbers. Th

Re: G root servers unreachable via ICMP(v6)

[borg]

So, DoD does NOT have capacity to answer those little ICMP echo
request packets? Heh.. Anyway, this is IMO terrible practice.
Many many times I have to deal w/ "products" that do exacly the same
because its so much "secure" to not respond to ping.
Any basic network security researcher know that they are various
more effective methods to poking around endpoint to check if its online.

Cutting PING means you are hurting your basic troubleshooting.
Is that thing even plugged in? Maybe Firewall misconfiguration?

If you are just user internet endpoint not serving anything, that
method might be useful, but you need to drop pretty much anything.


-- Original message --

From: Willy Manga 
To: nanog@nanog.org
Subject: G root servers unreachable via ICMP(v6)
Date: Tue, 16 May 2023 07:38:24 +0400

Hi,

DNS speaking, I can query G root servers; at least, that's the most important.

However, from several sites, either on IPv4 or IPv6, I cannot ping(6) them. Is
it by design, or it's an issue?

Side question: even if it was by design, is it a good practice to completely
restrict ICMP(v6)?

Thanks.


P.S: I sent the same email to dns-operati...@lists.dns-oarc.net since 12 May
2023 but it's still in moderation.. If one admin is around .. :)

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

Re: Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509)

[borg]

Yeah, ARDC sold part of it to Amazon. I doubt they even had right to do
so due to 44/8 was an legacy IP range.. ARIN allowed it.. All too shady.

Anyway, according to AMPRnet that range was unallocated, so no active
radio ham networks were at that range, so I doubt it was someone
from AMPRnet. Getting parts of 44/8 reannounced by different gw
than ucsd.edu is not that easy after all.

-- Original message --

From: Ellenor Agnes Bjornsdottir 
To: nanog@nanog.org
Subject: Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards
AS16509)
Date: Tue, 30 Aug 2022 04:13:24 +

Wasn't 44/8 the space for AMPRNet?

I looked it up and they sold part of it to Amazon. Ok. Got it.

Possible that a potential highjack could be a good faith radio ham who
hasn't somehow been updated on the sale of that space? Or more likely to
be a malicious highjack?

On 8/23/22 02:05, Siyuan Miao wrote:
> Amazon was only announcing 44.224.0.0/11  at first.
> 
> https://bgp.tools/prefix/44.235.216.0/24
> 
> On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette
>  wrote:
> 
> In message
> ,
> Siyuan Miao  wrote:
> 
> >Hjacking didn't last too long. AWS started announcing a more specific
> >announcement to prevent hijacking around 3 hours later. Kudos to
> Amazon's
> >security team :-)
> 
> Sorry.  I'm missing something here.  If the hijack was of
> 44.235.216.0/24 , then
> how did AWS propagate a "more specific" than that?
> 
> 
> Regards,
> rfg
> 
> --
> 
> To unsubscribe from this mailing list, get a password reminder, or
> change your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
> 

Re: BGP Javascript Map/Visualization

[borg]

You were close... I think you mean this one?
https://as2914.net/

-- Original message --

From: Brian Johnson 
To: nanog@nanog.org
Subject: BGP Javascript Map/Visualization
Date: Thu, 26 May 2022 20:07:51 +

Hey all,

Sorry for the noise.  Years ago someone here built and shared a javascript
visualization of what their routers saw for the state of BGP and paths to
get to various ASs. One could use WSAD and other keys to fly around and
examine various other ASs.  I thought it was as2814.net, but that seems to
not be a thing anymore.  Can someone refresh my memory where that might be?
Or did it get taken down?

Thanks in advance,
- brian

Re: V6 still not supported

[borg]

I know its the same, but from UX standpoints looks different.
Anyway, that was just one example.

As for IPv6 -> IPv4 (note the arrow) its pretty much easy.
IPv6 have much bigger address space, so it can embed IPv4 addresses
in special interop subnets that are routed to special NAT GW
that handle IPv6 -> IPv4 translation. Thats right, its one way.
IPv4 -> IPv6 is pretty much impossible. But do we need one?
Todays internet is centralized, a lot of traffic goes into cloud, not 
between users. Also, transition is not 0 -> 1, its gradual. Same about 
users. Some even dont really understand what they are using, happy that 
netflix or facebook opens. There are of course power users, so they will
go different transition path. Dont put everyone into same bucket.

As for content providers (servers) they can stay for IPv4 for a while,
become dual stack or even (once a traffic level shifts) provide
IPv4 -> IPv6 balancers to handle leftovers of IPv4 traffic.

Also, not all services can work via proxying/balacing. Some services
needs to be dual stack from the start.

As for RFC1918, because why not? Why are you forcing me to run my networks
your way? Its mine network and I want to set it up the way I see fit.
Not everyone is going to ask RIPE/LIR was address space for his small 
network. Isnt that too much burden?


-- Original message --

From: Owen DeLong 
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: V6 still not supported
Date: Fri, 18 Mar 2022 13:44:13 -0700


This shows a fundamental lack of understanding˙˙ Netmask and Prefixlen/CIDR are 
just
Different ways of representing the exact same thing. While it˙˙s true that 
prior to CIDR, one
COULD implement discontiguous net masks, this was rare in actual practice and 
had no
real use, so nothing was lost in eliminating that capability.

Internal to the operating system, regardless of whether presentation is as a 
CIDR length
or a netmask, it˙˙s still stored and compared against addresses as a bitfield.

Client A has a 128 bit address.
Client B has a 32 bit address and does not understand packets with 128-bit 
addresses.

Please explain how these two clients interoperate.

That is literally what you are asking for here. Math says it doesn˙˙t work.

Why? Why does RFC-1918 space need to exist at all? Why not simply use 
transparent addressing and stop mutilating packet headers?

However, if you really think this is important, I will refer you to what is 
called ULA in IPv6. It˙˙s pretty much all the same problems of RFC1918 minus 
the high probability of collision when merging two networks.

I think you have over-valued it.

Owen

Re: V6 still not supported

[borg]

While Im dont like IPv6, I see it as a bad idea.
>From my knowledge I dont see a way of extending IPv4 without making it
a new protocol. It was not designed that way.

What I would LOVE to see that someone will pop in with new IP protocol
that is much more similar to IPv4, just extends address space and fixes
some well know issues. (for example remove netmask and use prefixlen/CIDR).

Other importand aspect is some kind of IPvX -> IPv4 interop, so you can
quickly put clients into new protocol and they have access to entire IPv4
internet out of the box.

Also, we need to please enterprises so we need largish RFC1918 space too.

Just my 2 cents again ;)


-- Original message --

From: Matt Hoppes 
To: Joe Maimon , b...@theworld.com,
Tom Beecher 
Cc: NANOG 
Subject: Re: V6 still not supported
Date: Thu, 17 Mar 2022 23:34:19 -0500

At this point I would *love* to see IPv4 get extended, a software patch applied
to devices, and IPv6 die a quick painless death.

> 
> Its not impossible to envision that IPv4 does not ever go away but actually
> gets extended in such a way that it obsoletes IPv6. The longer this drags out
> the less implausible it seems.
> 
> Joe
> 
> 

Re: V6 still not supported

[borg]

Yes, you are right. And gradually IPv4 was improved and fixed.
We learned how to defend L2. CIDR was added (with should be thing
from the begining instead of netmasks, but who could forsee...)

And in case of IPv6 it seems that all that experience was throwed out
of window. Design was much different that IPv4, adding new issues.
I have feeling that IPv6 was made by people who were NOT running networks.

The big question is, what we can do that to fix IPv6 problem.
I have no clue at all.. Im personally biased against IPv6.


-- Original message --

From: Michael Thomas 
To: nanog@nanog.org
Subject: Re: V6 still not supported
Date: Thu, 17 Mar 2022 18:52:32 -0700


On 3/17/22 3:30 AM, b...@uu3.net wrote:
> It seems team developing IPv6 had ONE way of doing things,
> with is actually recipe for disaster. Why? Because they were building an IP
> protocol. Something that will be using globally by ALL networks around.
> Not some local IOT (useless) shit used here and there.
> Thats why such IP protocol should be follow KISS concept and flexibility.
> Some people have different vision how to run network. And because
> Inter-net is an AS to AS network they should have right to do so.
As somebody who designed IoT things back when v6 was being designed, my only
question was whether it would get deployed, not whether it was too complex. It
was honestly a lot easier than a completely new protocol stack like appletalk or
netware.
> 
> In my opinion all that crypto stuff should be put layer upper because
> crypto is hard, very hard and can get obsolete quickly.
I don't see what the OS layer has to do with anything. An operating system that
doesn't get patches is even worse than app level code that doesn't.
> 
> Its same about other weird things embedded into IPv6 that probably
> should go layer up. And now people wonder why IPv6 adoption is crap and
> there is high resistance. IPv4 made mistakes too, but hell, it was the first.
> 
> It seems all the market needed was IPv4 with bigger address space.
> Instead of delivering it, some contraption has been created trying to solve
> non-existant (or already fixed) problems.

There were tons of things that were slapped onto IP that were basically
experimental like ARP and bootp. CIDR didn't even exist back then.

Also: security, for example, was not an already fixed problem. Far from it.

Mike

RE: V6 still not supported

[borg]

Ohh sorry if I misunderstood orginal message a bit.
I am all on your side about it indeed.

I am el-cheapo dual-homed at home, and this setup is impossible
to do without NAT. I can add/del ISP connections at any time with
minimal reconf. Have static IPs in LAN and overlay network.
Life is good.

When NAT appeard we kinda hated it.
Now it seems life is hard without it ;)


-- Original message --

From: Matthew Huff 
To: Tom Beecher , "b...@uu3.net" 
Cc: "nanog@nanog.org" 
Subject: RE: V6 still not supported
Date: Thu, 17 Mar 2022 12:00:59 +

Did you read his email? He was saying that what a lot of people wanted was IPv4 
+ bigger address space, and not any other changes. Speaking for myself, other 
than the bigger address space, for a corporate/enterprise environment I have 
yet to see any advantages of IPv6 and many, many issues.

Information hiding, aka NAT is very important in the financial world.

For example, we have a directly peered connection with our clearing partner at 
our co-location. Both sides use NAT. This way either side can make a network 
change without having to involve the other partner.

Here is what happens without NAT (circa 2008), and yes, this really happened:


  1.  We needed to separate out process and move to a different server. The 
existing server IP couldn˙˙t change since other partners had it in their access 
list.
  2.  It took 9 weeks and:
 *   3 conference calls including one with 30 participants from the 
clearing company
 *   2 approvals by committees at the clearing company



You can say that this was absurd and should be changed. Yes, but it won˙˙t and 
we have no control over them.



With NAT we can change internal IP addresses at any time as long as we update 
the NAT tables.



This is not something important at ISP or hosting providers, but it˙˙s many 
issues like this in the corporate world that prevent IPv6 adoption. Things like 
static addressing, consistent behavior of IPv6 across different operating 
systems including disabling SLAAC,  privacy addressing and others.



Based on my experience and people on tech mailing list that are oriented toward 
enterprises, I would bet that IPv6 deployment (with global addresses) is 
significantly less than 10% nor is it on their horizon.



Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mh...@ox.com | www.ox.com
...

From: NANOG  On Behalf Of Tom Beecher
Sent: Thursday, March 17, 2022 7:41 AM
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: V6 still not supported

˙˙It seems all the market needed was IPv4 with bigger address space.
Instead of delivering it, some contraption has been created trying to solve
non-existant (or already fixed) problems.˙˙

your argument against IPv6 is that they should have created a new version of 
IPv4, but bigger?

So˙˙ IPv6?

On Thu, Mar 17, 2022 at 06:32 mailto:b...@uu3.net>> wrote:
It seems team developing IPv6 had ONE way of doing things,
with is actually recipe for disaster. Why? Because they were building an IP
protocol. Something that will be using globally by ALL networks around.
Not some local IOT (useless) shit used here and there.
Thats why such IP protocol should be follow KISS concept and flexibility.
Some people have different vision how to run network. And because
Inter-net is an AS to AS network they should have right to do so.

In my opinion all that crypto stuff should be put layer upper because
crypto is hard, very hard and can get obsolete quickly.

Its same about other weird things embedded into IPv6 that probably
should go layer up. And now people wonder why IPv6 adoption is crap and
there is high resistance. IPv4 made mistakes too, but hell, it was the first.

It seems all the market needed was IPv4 with bigger address space.
Instead of delivering it, some contraption has been created trying to solve
non-existant (or already fixed) problems.

Just my 2 cents...


-- Original message --

From: William Allen Simpson 
mailto:william.allen.simp...@gmail.com>>
To: NANOG mailto:nanog@nanog.org>>
Subject: Re: V6 still not supported
Date: Wed, 16 Mar 2022 22:24:14 -0400

I'd wanted to clearly distinguish this from the old methods:

   This is intended to replace ARP, ICMP Router Advertisement, ICMP
   Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6]
   environment. There are also elements of the OSI ES-IS and IS-IS Hello.

We were forward looking to deployments of thousands of systems per link, rather
than the 30 maximum under then current ethernet standards.  We needed fewer
announcements, less chatty traffic, and more specific traffic designation.

We also prioritized network security.  Moreover requiring addresses be
ephemeral,
such that applications would not be able to tie authentication/au

Re: V6 still not supported

[borg]

Yes, IPv6.. but for example 64bit address space but with a much
closer ties to IPv4 imo. So network people would be much more
confortable with it.

I already said how my ideal IPv6 should look like. Many people
disagree with that ok. Its very hard to please everyone indeed, hence
KISS concept should be followed.

Also, the whole dual stack thing should be required only on
content providers, so client should be moved to IPv6, freeing
more space from IPv4 with could be moved to content/hosting.
Once there is enough critical mass of clients on IPv6, IPv4 could be
dropped gradually. This avoids chicken and egg problem.

Lets stop that E2E myth, we do NOT have e2e connectivity on client side
from loong time (users NATs, CGNATs). And you know what? Its not that
needed these days due to how internet is centralized today.
Its good moment for change imo, but we blowed it.


-- Original message --

From: Tom Beecher 
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: V6 still not supported
Date: Thu, 17 Mar 2022 07:40:32 -0400

˙˙It seems all the market needed was IPv4 with bigger address space.
Instead of delivering it, some contraption has been created trying to solve
non-existant (or already fixed) problems.˙˙

your argument against IPv6 is that they should have created a new version
of IPv4, but bigger?

So˙˙ IPv6?

On Thu, Mar 17, 2022 at 06:32  wrote:

> It seems team developing IPv6 had ONE way of doing things,
> with is actually recipe for disaster. Why? Because they were building an IP
> protocol. Something that will be using globally by ALL networks around.
> Not some local IOT (useless) shit used here and there.
> Thats why such IP protocol should be follow KISS concept and flexibility.
> Some people have different vision how to run network. And because
> Inter-net is an AS to AS network they should have right to do so.
>
> In my opinion all that crypto stuff should be put layer upper because
> crypto is hard, very hard and can get obsolete quickly.
>
> Its same about other weird things embedded into IPv6 that probably
> should go layer up. And now people wonder why IPv6 adoption is crap and
> there is high resistance. IPv4 made mistakes too, but hell, it was the
> first.
>
> It seems all the market needed was IPv4 with bigger address space.
> Instead of delivering it, some contraption has been created trying to solve
> non-existant (or already fixed) problems.
>
> Just my 2 cents...
>
>
> -- Original message --
>
> From: William Allen Simpson 
> To: NANOG 
> Subject: Re: V6 still not supported
> Date: Wed, 16 Mar 2022 22:24:14 -0400
>
> I'd wanted to clearly distinguish this from the old methods:
>
>This is intended to replace ARP, ICMP Router Advertisement, ICMP
>Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6]
>environment. There are also elements of the OSI ES-IS and IS-IS Hello.
>
> We were forward looking to deployments of thousands of systems per link,
> rather
> than the 30 maximum under then current ethernet standards.  We needed fewer
> announcements, less chatty traffic, and more specific traffic designation.
>
> We also prioritized network security.  Moreover requiring addresses be
> ephemeral,
> such that applications would not be able to tie
> authentication/authorization to
> an
> IPv6 address and would be motivated to use cryptographic security.
>
> Unfortunately, later committees decided that rather than a single simpler
> secured
> address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6.
> Three ways to do the same thing are always a recipe for disaster.
>
> Reminder: I was an operator and one of the original NANOG members.
>
> We spent a lot of time considering human factors.  I'd pioneered the
> "Operational Considerations" section of the original draft RFCs.
>
> IPv6 is a case study of what happens with committee-itis.
>
> The small design team worked well.
>

Re: V6 still not supported

[borg]

It seems team developing IPv6 had ONE way of doing things, 
with is actually recipe for disaster. Why? Because they were building an IP
protocol. Something that will be using globally by ALL networks around.
Not some local IOT (useless) shit used here and there.
Thats why such IP protocol should be follow KISS concept and flexibility.
Some people have different vision how to run network. And because
Inter-net is an AS to AS network they should have right to do so.

In my opinion all that crypto stuff should be put layer upper because
crypto is hard, very hard and can get obsolete quickly.

Its same about other weird things embedded into IPv6 that probably
should go layer up. And now people wonder why IPv6 adoption is crap and 
there is high resistance. IPv4 made mistakes too, but hell, it was the first.

It seems all the market needed was IPv4 with bigger address space.
Instead of delivering it, some contraption has been created trying to solve
non-existant (or already fixed) problems.

Just my 2 cents...


-- Original message --

From: William Allen Simpson 
To: NANOG 
Subject: Re: V6 still not supported
Date: Wed, 16 Mar 2022 22:24:14 -0400

I'd wanted to clearly distinguish this from the old methods:

   This is intended to replace ARP, ICMP Router Advertisement, ICMP
   Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6]
   environment. There are also elements of the OSI ES-IS and IS-IS Hello.

We were forward looking to deployments of thousands of systems per link, rather
than the 30 maximum under then current ethernet standards.  We needed fewer
announcements, less chatty traffic, and more specific traffic designation.

We also prioritized network security.  Moreover requiring addresses be
ephemeral,
such that applications would not be able to tie authentication/authorization to
an
IPv6 address and would be motivated to use cryptographic security.

Unfortunately, later committees decided that rather than a single simpler
secured
address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6.
Three ways to do the same thing are always a recipe for disaster.

Reminder: I was an operator and one of the original NANOG members.

We spent a lot of time considering human factors.  I'd pioneered the
"Operational Considerations" section of the original draft RFCs.

IPv6 is a case study of what happens with committee-itis.

The small design team worked well.

Re: Redploying most of 127/8 as unicast public

[borg]

No, you are not alone. This just gets kinda pathetic.
It also shows how an IPv6 is a failure.
(No please, leave me alone all you IPv6 zealots).

I think its time to go back to design board and start
working on IPv8 ;) so we finnaly get rid of IPv4...

-- Original message --

From: Jay R. Ashworth 
To: nanog 
Subject: Redploying most of 127/8 as unicast public
Date: Wed, 17 Nov 2021 23:29:49 + (UTC)

This seems like a really bad idea to me; am I really the only one who noticed?

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

That's over a week old and I don't see 3000 comments on it, so maybe it's just
me.  So many things are just me.

[ Hat tip to Lauren Weinstein, whom I stole it from ]

Cheers,
-- jra

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: IPv6 woes - RFC

[borg]

Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?

Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
routing and NATing however I want..


-- Original message --

From: Mark Andrews 
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Wed, 29 Sep 2021 00:28:40 +1000



> On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
> 
> Heh, NAT is not that evil after all. Do you expect that all the home
> people will get routable public IPs for all they toys inside house?

Yes! Remember routable does not mean that it is reachable from outside.

> And if they change ISP they will get new range?

Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
has only been specified for 18 years now.  The IPv6 address ranges ISP
get for RIRs are based on handing out multiple /64 to every customer.

> Doesnt sounds nice to me.. But I guess I its just me

It sounds like you need to do some reading about IPv6, then actually
use it.  100s of millions of home customers are get routable IPv6 prefixes
today around the world.  It's not scary.  Things don˙˙t blow up.

> Yeah I am aware of putting additional aliases on loopback.
> 
> No futher comment about ND and DHCP.
> 
> Well, at a time when TCP/IP was invented, 32bit address space looked
> pretty much big... I dont blame them than they didnt predicted future..
> Unfortunately, cant say the same about IPv6 R&D taskforce ;)
> 
> Hah, multicast... Ill skip it.
> 
> Followed change to support CIDR, Internet was still small and considered
> R&D field...
> 
> Okey, I think its no need to futher pollute NANOG list with this.
> I said at the begining that this is just my subjective opinion.
> This will not help IPv6 case at all.
> 
> At least from my (2) standpoint it would be really cool that IPv6
> would be finally addopted.
> 
> I just wanted to share my toughts about why im not big fan of IPv6.
> I also wanted to hear other opinions what they dislike about it, no
> list of how cool IPv6 is and how everyone should use it right away.
> 
> 
> -- Original message --
> 
> From: Owen DeLong 
> To: b...@uu3.net
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Sat, 25 Sep 2021 12:01:22 -0700
> 
> 
> 
>> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
>> 
>> Well, I think we should not compare IPX to IPv4 because those protocols
>> were made to handle completly different networks?
>> 
>> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> 
>> Well, Industry seems to addapt things quickly when they are good enough.
>> Better things replace worse. Of course its not always the case, sometimes
>> things are being forced here.. And thats how I feel about IPv6..
> 
> Sometimes worse things replace better. NAT, for example was definitely not
> an improvement to IPv4. It was a necessary evil intended to be a temporary
> fix.
> 
>> 
>> IPv4 Lookback is 127.0.0.1/8
>> You can use bind IPs within range by applications. Handy
>> In IPv6 its not the case.
> 
> You are free to assign any additional IPv6 addresses you like to the loopback
> interface and then bind them to applications. Personally, I haven˙˙t found a
> particularly good use for this, but it is possible.
> 
> It does mean that instead of wasting 1/256th of the entire address space
> in every context on loopbacks, you have to assign what you need there,
> but you can easily assign a /64 prefix to a loopback interface and have
> applications bind within range.
> 
>> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> Tables overflows, attacks and DDoS.. Why to repeat history again?
> 
> Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
> 
> Mostly this has been solved in software by managing table discards more
> effectively.
> 
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
> 
> I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any 
> significant
> problems with it other than some minor inconveniences introduced by the 
> ability
> to have different DUID types and vendors doing semi-obnoxious things along 
> that
> line.
> 
>> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
>> think about some external IPv4 interop.. Internet was exploding at 1997..
>> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
>> could happen if IPv6 wasnt so alien ;)
> 
> It was thought about˙˙ It was considered. It was long pondered. Problem was,
> nobody could come up w

Re: IPv6 woes - RFC

[borg]

Heh, NAT is not that evil after all. Do you expect that all the home
people will get routable public IPs for all they toys inside house?
And if they change ISP they will get new range?
Doesnt sounds nice to me.. But I guess I its just me

Yeah I am aware of putting additional aliases on loopback.

No futher comment about ND and DHCP.

Well, at a time when TCP/IP was invented, 32bit address space looked
pretty much big... I dont blame them than they didnt predicted future..
Unfortunately, cant say the same about IPv6 R&D taskforce ;)

Hah, multicast... Ill skip it.

Followed change to support CIDR, Internet was still small and considered
R&D field...

Okey, I think its no need to futher pollute NANOG list with this.
I said at the begining that this is just my subjective opinion.
This will not help IPv6 case at all.

At least from my (2) standpoint it would be really cool that IPv6
would be finally addopted.

I just wanted to share my toughts about why im not big fan of IPv6.
I also wanted to hear other opinions what they dislike about it, no
list of how cool IPv6 is and how everyone should use it right away.


-- Original message --

From: Owen DeLong 
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Sat, 25 Sep 2021 12:01:22 -0700



> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
> 
> Well, I think we should not compare IPX to IPv4 because those protocols
> were made to handle completly different networks?
> 
> Yeah, IPv6 is new, but its more like revolution instead of evolution.
> 
> Well, Industry seems to addapt things quickly when they are good enough.
> Better things replace worse. Of course its not always the case, sometimes
> things are being forced here.. And thats how I feel about IPv6..

Sometimes worse things replace better. NAT, for example was definitely not
an improvement to IPv4. It was a necessary evil intended to be a temporary
fix.

> 
> IPv4 Lookback is 127.0.0.1/8
> You can use bind IPs within range by applications. Handy
> In IPv6 its not the case.

You are free to assign any additional IPv6 addresses you like to the loopback
interface and then bind them to applications. Personally, I haven˙˙t found a
particularly good use for this, but it is possible.

It does mean that instead of wasting 1/256th of the entire address space
in every context on loopbacks, you have to assign what you need there,
but you can easily assign a /64 prefix to a loopback interface and have
applications bind within range.

> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
> Tables overflows, attacks and DDoS.. Why to repeat history again?

Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
ARP. Table overflows are (not really an issue in my experience) the
result of a larger address space than the memory available for the L2
forwarding table on switches or the ND table on hosts. This isn˙˙t due
to a difference in ND vs. ARP. It is due to the fact that there are no
64-bit networks in IPv4, but they are commonplace in IPv6.

Mostly this has been solved in software by managing table discards more
effectively.

> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
> issues. If this is not the case, im sorry. Its been a while when I last time
> played with IPv6...

I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant
problems with it other than some minor inconveniences introduced by the ability
to have different DUID types and vendors doing semi-obnoxious things along that
line.

> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
> think about some external IPv4 interop.. Internet was exploding at 1997..
> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
> could happen if IPv6 wasnt so alien ;)

It was thought about˙˙ It was considered. It was long pondered. Problem was,
nobody could come up with a way to overcome the fact that you can˙˙t put
128 bits of data in a 32 bit field without loss.

IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes
necessary to implement IPv6 were significantly bigger than CIDR and IPv6
affected applications, not just network. There was no way around these
two facts. The IPv6 network stack did get adopted and implemented nearly
as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support
for quite some time now at the network stack level. It is applications and
content providers that are lagging and they never did anything for CIDR.

> As for IPv4 vs IPv6 complexity, again, why repeat history.

What complexity?

> Biggest IPv4
> mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.

No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been
inconvenient in hardware at the time, but it would have made IPv4 much more
scalable and would have allowed it to last significantly longer.

> (Another big mistake was class E reservation..

Re: IPv6 woes - RFC

[borg]

Because IPv4 loopback is 127.0.0.1/8 and its usefull?

0:0:1-:0/32 means you generate addreses from
that range and not necessary using /32 prefix..
It just range thats reserved for LL.

Same about RFC1918 aka space.. its a range reserved for local addreses.

The whole rationale is:
- shorter prefix wins (so no overlap?)
- you can use nice short addreses like ::1234 for loopback
  or ::1: for LL or ::1:0:1234 for RFC1918 like

Whole ::1 short format should be used only to cut leading zeros
not "more zeroes whatnever they appear".

ND is new thing and it requires new things to protect it from attacks?

While all the hate towards NAT, after years of using it I see it as cool
thing now. Yeah it breaks E2E, and thats why its place is only at CPE.
The true tragedy is CGN.

Yeah, services make money so they should addapt new protocol, so users
can access those services. In my opinion, due to IPv4 exhaustion, this
is right adoption scheme. You move users to IPv6 and free IPv4 addresses
for more services. It means internet can still grow and noone is really cut
off. Once IPv6 mass is big enough, you can start to fade IPv4 services.

Prototype yeah... if only this would be 1997 again... ;)


-- Original message --

From: Owen DeLong 
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Fri, 24 Sep 2021 17:24:29 -0700



> On Sep 24, 2021, at 2:01 AM, b...@uu3.net wrote:
> 
> Oh yeah, it would be very funny if this will really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.
> 
> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
>  more is not always better

Perhaps, but the benefits of a 128 bit address space with a convenient
near universal network/host boundary has benefits. What would be the
perceived benefit of 64-bit addressing over 128?

> - loopback 0:0:0:1/48

Why dedicate a /48 to loopback?

> - soft LL 0:0:1-:0/32 (Link Local)

Having trouble understanding that expression˙˙ Wouldn˙˙t it overlap loopback, 
since
0:0::/32 and 0:0:0::/48 would be overlapping prefixes?

> - RFC1918 address space 0:1-:0:0/16

Why repeat this mistake?

> - keep ARPs, ND wasnt great idea after all?

I don˙˙t see a significant difference (pro or con) to ND vs. ARP.

> - NAT support (because its everywhere these days)

That˙˙s a tragedy of IPv4, I don˙˙t see a benefit to inflicting it on a new 
protocol.

> - IPv6 -> IPv4 interop (oneway)
>  we can put customers on IPv6, while keeping services dualstack

That requires the services to be dual stack which is kind of the problem we have
with IPv6 today˙˙ Enough services that matter aren˙˙t dual stack.

> - correct DHCP support (SLAAC wasnt great idea after all?)
>  I think its already in IPv6, but was an issue at the begining

Depends on your definition of ˙˙correct˙˙. I disagree about SLAAC not being a 
great
idea. It might not fit every need, but it˙˙s certainly a low-overhead highly 
useful
mechanism in a lot of deployments.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.
> 
> And that IPv6 I would love to see and addapt right away :)

Well.. Present your working prototype on at least two different systems. ;-)

Owen

> 
> 
> -- Original message --
> 
> From: Joe Maimon 
> To: Owen DeLong , Bjrn Mork 
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Thu, 23 Sep 2021 16:26:17 -0400
> 
> 
> 
> Owen DeLong via NANOG wrote:
>>> There are real issues with dual-stack, as this thread started out with.
>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
>> I dont disagree, but a reversion to IPv4-only certainly wont do it.
> 
> For everyone who does have enough IPv4 addresses, it does. This is the problem
> in a nutshell. If that starts trending, IPv6 is done.
> 
>> I think the only way out is through.
> 
> I hope not, both for IPv6 sake and for the network users. We dont know how 
> much
> longer the goal will take, there is materializing a real possibility we will
> never quite reach it, and the potholes on the way are pretty rough.
> 
> And as the trip winds on, the landscape is changing, not necessarily for the
> better.
> 
> One more "any decade now" and another IPv4 replacement/extension might just
> happen on the scene and catch on, rendering IPv6 the most wasteful global
> technical debacle to date.
> 
> 
>>  Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
> 
> You say that as if it was a surprise, when it should not have been, and you 
> say
> that as if something can be done about it, which we should know by now cannot 
> be
> the primary focus, since it cannot be done in any timely fashion. If at all.
> 
> Its time to throw mud on the wall and see what sticks. Dual stack and wait is

Re: IPv6 woes - RFC

[borg]

Well, I think we should not compare IPX to IPv4 because those protocols
were made to handle completly different networks?

Yeah, IPv6 is new, but its more like revolution instead of evolution.

Well, Industry seems to addapt things quickly when they are good enough.
Better things replace worse. Of course its not always the case, sometimes
things are being forced here.. And thats how I feel about IPv6..

IPv4 Lookback is 127.0.0.1/8
You can use bind IPs within range by applications. Handy
In IPv6 its not the case.

IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
Tables overflows, attacks and DDoS.. Why to repeat history again?

IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
issues. If this is not the case, im sorry. Its been a while when I last time
played with IPv6...

IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
think about some external IPv4 interop.. Internet was exploding at 1997..
Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
could happen if IPv6 wasnt so alien ;)

As for IPv4 vs IPv6 complexity, again, why repeat history. Biggest IPv4
mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
(Another big mistake was class E reservation...)
Internet was tiny at that time so everyone followed.
Image something like this today? Same about IPv6.. it brings
forced network::endpoint probably due to IoT, sacrificing flexibility.

Again, I dont want to really defend my standpoint here. Its too late for 
that. I kinda regret now dropping into discussion...


-- Original message --

From: Grant Taylor via NANOG 
To: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Fri, 24 Sep 2021 14:26:27 -0600

On 9/24/21 11:53 AM, b...@uu3.net wrote:
> Well, I see IPv6 as double failure really.

I still feel like you are combining / conflating two distinct issues into one
generalization.

> First, IPv6 itself is too different from IPv4.

Is it?  Is it really?  Is the delta between IPv4 and IPv6 greater than the delta
between IPv4 and IPX?

If anything, I think the delta between IPv4 and IPv6 is too small. Small enough
that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction
between the multiple personalities therein.  I also think that the grouping of
IPv4 and IPv6 as one protocol is part of the downfall.

More over if you think of IPv4 and IPv6 dual stack as analogous to the
multi-protocol networks of the '90s, and treat them as disparate protocols that
serve similar purposes in (completely) different ways, a lot of the friction
seems to make sense and as such becomes less friction through understanding and
having reasonable expectations for the disparate protocols.

> What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely
> 64bit). Of course we could not extend IPv4, so having new protocol is fine.

I don't think you truly mean that having a new protocol is fine. Because if you
did, I think you would treat IPv6 as a completely different protocol from IPv4.
E.g. AppleTalk vs DECnet.  After all, we effectively do have a new protocol;
IPv6.

IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98.  Or
"different" in place of "similar".

> It should just fix problem (do we have other problems I am not aware of with
> IPv4?) of address space and thats it.  Im happy with IPv4, after 30+ years of
> usage we pretty much fixed all problems we had.

I disagree.

> The second failure is adoption. Even if my IPv6 hate is not rational, adoption
> of IPv6 is crap. If adoption would be much better, more IPv4 could be used for
> legacy networks ;) So stuborn guys like me could be happy too ;)

I blame the industry, not the IPv6 protocol, for the lackluster adoption of
IPv6.

> As for details, that list is just my dream IPv6 protocol ;)
> 
> But lets talk about details:
> - Loopback on IPv6 is ::1/128
>I have setups where I need more addresses there that are local only.
>Yeah I know, we can put extra aliases on interfaces etc.. but its extra
>work and not w/o problems

How does IPv6 differ from IPv4 in this context?

> - IPv6 Link Local is forced.
>I mean, its always on interface, nevermind you assign static IP.
>LL is still there and gets in the way (OSPFv3... hell yeah)

I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do
on a network.  But I don't see a technical problem with this in and of itself.
--  I can't speak to OSPFv3 issues.

> - ULA space, well.. its like RFC1918 but there are some issues with it
>(or at least was? maybe its fixed) like source IP selection on with
>multiple addresses.

I consider this to be implementation issues and not a problem with the protocol
itself.

> - Neighbor Discovery protocol... quite a bit problems it created.

Please elaborate.

>What was wrong w/ good old ARP? I tought we fixed all those problems
>already like ARP poisoning via port security.. etc

Re: IPv6 woes - RFC

[borg]

Well, I see IPv6 as double failure really. First, IPv6 itself is too
different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with
bigger address space, likely 64bit). Of course we could not extend IPv4,
so having new protocol is fine. It should just fix problem (do we have other
problems I am not aware of with IPv4?) of address space and thats it.
Im happy with IPv4, after 30+ years of usage we pretty much fixed all 
problems we had.

The second failure is adoption. Even if my IPv6 hate is not rational,
adoption of IPv6 is crap. If adoption would be much better, more IPv4
could be used for legacy networks ;) So stuborn guys like me could be happy 
too ;)

As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details:
- Loopback on IPv6 is ::1/128
  I have setups where I need more addresses there that are local only.
  Yeah I know, we can put extra aliases on interfaces etc.. but its extra
  work and not w/o problems
- IPv6 Link Local is forced.
  I mean, its always on interface, nevermind you assign static IP.
  LL is still there and gets in the way (OSPFv3... hell yeah)
- ULA space, well.. its like RFC1918 but there are some issues with it
  (or at least was? maybe its fixed) like source IP selection on with 
  multiple addresses.
- Neighbor Discovery protocol... quite a bit problems it created.
  What was wrong w/ good old ARP? I tought we fixed all those problems
  already like ARP poisoning via port security.. etc
- NAT is there in IPv6 so no futher comments
- DHCP start to get working on IPv6.. but it still pain sometimes

And biggest problem, interop w/ IPv4 was completly failure.
Currently we have best Internet to migrate to new protocol.
Why? Because how internet become centralized. Eyeball networks
just want to reach content. E2E communication is not that much needed.
We have games and enhusiast, but those can pay extra for public IPv4.
Or get VPN/VPS.

And end comment. I do NOT want to start some kind of flame war here.
Yeah I know, Im biased toward IPv4. If something new popups, I want it 
better than previous thingie (a lot) and easier or at least same level of 
complications, but IPv6 just solves one thing and brings a lot of 
complexity.

The fact is, IPv6 failed. There are probably multiple reasons for it.
Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4
works for me for now.


-- Original message --

From: Grant Taylor via NANOG 
To: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Fri, 24 Sep 2021 10:17:42 -0600

On 9/24/21 3:01 AM, b...@uu3.net wrote:
> Oh yeah, it would be very funny if this will really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.

Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction
with the deployment / adoption of the IPv6 protocol?

I think that it's a very critical distinction.  Much like DoH as a protocol vs
how some companies have chosen to utilize it.  Similar to IBM's computers vs
what they were used for in the 1940's.

> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
>more is not always better
> - loopback 0:0:0:1/48
> - soft LL 0:0:1-:0/32 (Link Local)
> - RFC1918 address space 0:1-:0:0/16
> - keep ARPs, ND wasnt great idea after all?
> - NAT support (because its everywhere these days)
> - IPv6 -> IPv4 interop (oneway)
>we can put customers on IPv6, while keeping services dualstack
> - correct DHCP support (SLAAC wasnt great idea after all?)
>I think its already in IPv6, but was an issue at the begining

I'm probably showing my ignorance, but I believe that the IPv6 that we have
today effectively does all of those things.  At least functionality, perhaps
with different values.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.

How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems
to me that most of the problems with IPv6 that I'm aware of are at other layers,
significantly higher in, or on top of, the stack.

> And that IPv6 I would love to see and addapt right away :)

I'm of the opinion that IPv6 has worked quite well dual stack from about
2005-2015.  It's only been in the last 5 or so years that I'm starting to see
more problems with IPv6.  And all of the problems that I'm seeing are companies
making business level decisions, way above layer 7, that negatively impact IPv6.
Reluctance to run an MX on IPv6 for business level decisions is definitely not a
protocol, much less L3, problem.



-- 
Grant. . . .
unix || die

Re: IPv6 woes - RFC

[borg]

Oh yeah, it would be very funny if this will really happen (new protocol).
Im not happy with IPv6, and it seems many others too.

This is short list how my ideal IPv6 proto looks like:
- 64bit address space
  more is not always better
- loopback 0:0:0:1/48
- soft LL 0:0:1-:0/32 (Link Local)
- RFC1918 address space 0:1-:0:0/16
- keep ARPs, ND wasnt great idea after all?
- NAT support (because its everywhere these days)
- IPv6 -> IPv4 interop (oneway)
  we can put customers on IPv6, while keeping services dualstack
- correct DHCP support (SLAAC wasnt great idea after all?)
  I think its already in IPv6, but was an issue at the begining

If there are some weird requirements from others, put them into layer up.
L3 needs to be simple (KISS concept), so its easy to implement and less
prone to bugs.

And that IPv6 I would love to see and addapt right away :)


-- Original message --

From: Joe Maimon 
To: Owen DeLong , Bjrn Mork 
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Thu, 23 Sep 2021 16:26:17 -0400



Owen DeLong via NANOG wrote:
> > There are real issues with dual-stack, as this thread started out with.
> > I don't think there is a need neither to invent IPv6 problems, nor to
> > promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
> I dont disagree, but a reversion to IPv4-only certainly wont do it.

For everyone who does have enough IPv4 addresses, it does. This is the problem
in a nutshell. If that starts trending, IPv6 is done.

> I think the only way out is through.

I hope not, both for IPv6 sake and for the network users. We dont know how much
longer the goal will take, there is materializing a real possibility we will
never quite reach it, and the potholes on the way are pretty rough.

And as the trip winds on, the landscape is changing, not necessarily for the
better.

One more "any decade now" and another IPv4 replacement/extension might just
happen on the scene and catch on, rendering IPv6 the most wasteful global
technical debacle to date.


>   Unfortunately, the IPv6 resistant forces
> are making that hard for everyone else.
> 
> Owen

You say that as if it was a surprise, when it should not have been, and you say
that as if something can be done about it, which we should know by now cannot be
the primary focus, since it cannot be done in any timely fashion. If at all.

Its time to throw mud on the wall and see what sticks. Dual stack and wait is an
ongoing failure slouching to disaster.

Joe

Re: 10 years from now... (was: internet futures)

[borg]

So, I assume you have PI IPv6 space and doing BGP with HE?
In other case, if anything will happen to HE (they close they
tunnelbroker service) you will have to renumber.


-- Original message --

From: Javier J 
To: b...@uu3.net
Cc: nanog 
Subject: Re: 10 years from now... (was: internet futures)
Date: Mon, 29 Mar 2021 13:57:20 -0400

I've had an IPV6 tunnel from Hurricane Electric for 10+ years I think.
IPv4 will probably live as it does now in my network, mostly for management
/ interserver coms for legacy hardware/software that doesn't support ipv6.


On Fri, Mar 26, 2021 at 5:31 PM  wrote:

> Oh, sorry to disappoint you, but they are not missing anything..
> Internet become a consumer product where data is provided by
> large corporations similary to TV now. Your avarage Joe consumer
> does NOT care about NAT and that he cant run services or he does NOT
> have full e2e communication.
>
> Yes, you are right, NAT was a second class internet for a while but
> now it seems that we cannot live without it anymore :)
> I dont really see other way how I can connect LAN to internet now.
> Using public IPs? Thats so terrible idea. How can I be el-cheappo
> dual-homed then?
>
>
> -- Original message --
>
> From: Mark Andrews 
> To: Andy Ringsmuth 
> Cc: Grant Taylor via NANOG 
> Subject: Re: 10 years from now... (was: internet futures)
> Date: Sat, 27 Mar 2021 08:00:38 +1100
>
> There are more smart phones in use in the world today the world than can
> be
> addressed by IPv4. Complaining about lack of IPv6 deployment has been
> legitimate for a long time. Telcos shouldn˙˙t have to deploy NATs. Homes
> shouldn˙˙t have to deploy NATs. Businesses shouldn˙˙t have to deploy NATs.
>
> NATs produce a second class Internet.  We have had to lived with a second
> class Internet for so long that most don˙˙t know what they are missing. --
> Mark Andrews
>

Re: 10 years from now... (was: internet futures)

[borg]

Oh, sorry to disappoint you, but they are not missing anything..
Internet become a consumer product where data is provided by
large corporations similary to TV now. Your avarage Joe consumer
does NOT care about NAT and that he cant run services or he does NOT
have full e2e communication.

Yes, you are right, NAT was a second class internet for a while but
now it seems that we cannot live without it anymore :)
I dont really see other way how I can connect LAN to internet now.
Using public IPs? Thats so terrible idea. How can I be el-cheappo
dual-homed then?


-- Original message --

From: Mark Andrews 
To: Andy Ringsmuth 
Cc: Grant Taylor via NANOG 
Subject: Re: 10 years from now... (was: internet futures)
Date: Sat, 27 Mar 2021 08:00:38 +1100

There are more smart phones in use in the world today the world than can be 
addressed by IPv4. Complaining about lack of IPv6 deployment has been 
legitimate for a long time. Telcos shouldn˙˙t have to deploy NATs. Homes 
shouldn˙˙t have to deploy NATs. Businesses shouldn˙˙t have to deploy NATs.

NATs produce a second class Internet.  We have had to lived with a second 
class Internet for so long that most don˙˙t know what they are missing. -- 
Mark Andrews

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[borg]

Hmm right... Somehow I tought that having that special Null MX
will silently discard message... I dont know why...

So, RFC 7505 is pretty much even pointless in my opinion.
You have to do more.. to pretty much achieve the same..
Its just easier to not having MX on subdomains that does not serve
as email destinations.. Less records in DNS..


-- Original message --

From: Grant Taylor via NANOG 
To: nanog@nanog.org
Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 12:03:37 -0700

On 2/26/21 11:46 AM, b...@uu3.net wrote:
> Well, I bet my legacy system will bounce it for example...

What specifically is the bounce?

I thought the purpose of the Null MX was to do two things:

1)  Provide as an MX that can't be connected to.
2)  Serve as a signal to things that know how to interpret it that no mail is to
be expected.

I would expect that some server, if not the MSA, /would/ generate a bounce
/because/ the email to the domain is undeliverables.

> I cant speak about Sendmail, qmail, Exim.. when they started supporting it.

My Sendmail boxes have been dealing with the Null MX just fine.  The
aforementioned bounce is /expected/ to tell the sender that the destination
address is bad.

> So, In my opinion changing already working standards in a way
> that they arent full compat with old systems is imo bad aproach.

IMHO there is little, if any, effective difference between the Null MX and an MX
pointing to an unresolvable name or an non-routed IP.  They cause a hard / fast
failure in an early upstream MTA thus induce a bounce.

Depending on the MSA, the delivery problem may even be presented to the user as
they are submitting the message to the MSA.



-- 
Grant. . . .
unix || die

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[borg]

Well, I bet my legacy system will bounce it for example...

Postfix 3.0: RFC 7505 ("Null MX" No Service Resource Record), Earlier 
Postfix versions will bounce mail because of a "Malformed DNS server reply". 

I cant speak about Sendmail, qmail, Exim.. when they started supporting it.

So, In my opinion changing already working standards in a way
that they arent full compat with old systems is imo bad aproach.

-- Original message --

From: Suresh Ramasubramanian 
To: "b...@uu3.net" , "nanog@nanog.org" 
Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 17:43:17 +

OK. In your experience, which legacy system is going to misinterpret this 
record?

The current RFC is from 2014-15 but the original idea from Mark Delany (then at 
Yahoo now at Apple) has been kicking around from 2006 or so. I remember 
contributing some text to the original draft RFC but can?t find any trace of it 
online right now.

It worked just fine even back then, I assure you. So if there is any legacy MTA 
that still doesn?t accept it, it probably relies on UUCP domain maps or similar.

--srs

From: NANOG  on behalf of 
b...@uu3.net 
Date: Friday, 26 February 2021 at 10:51 PM
To: nanog@nanog.org 
Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Thats cute, but remember that there are gazylion of legacy systems
on Internet as well. They might have no clue what do do with it..
Also remember that MTA is supposed to accept email to [ip] too.

On my opinion, its best to just have no MX record at all.
While MTA can fallback and try to do delivery by IN A record, I think
its not that big problem. You need to specify for what domains you
accept email anyway. And spammers will not care at all...


-- Original message --

From: Pirawat WATANAPONGSE via NANOG 
To: nanog@nanog.org
Subject: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 17:19:41 +0700

Dear all,


I put the ˙˙Null MX˙˙ Record (RFC 7505) into one of my domains yesterday,
then those online mail diagnostic tools out there start getting me worried:

It looks like most of those tools do not recognize the Null MX as a special
case; they just complain that they cannot find the mail server at ˙˙.˙˙
[Sarcasm: as if the root servers are going to provide mail service to a
mere mortal like me!]

Among a few shining exceptions (in a good way) is the good ol˙˙
https://bgp.he.net/ which does not show that domain as having any MX record.
[maybe it is also wrong, in the other direction?]

I fear that the MTAs are going to behave that same way, treating my Null MX
as a ˙˙misconfigured mail server name˙˙ and that my record will mean
unnecessary extra queries to the root servers. [well, minus cache hit]

So, here comes the questions:
1. Is there anyone actively using this Null MX? If so, may I please see
that actual record line (in BIND zone file format) just to satisfy myself
that I wrote mine correctly?
2. Which one makes more sense from the practical point-of-view: having a
Null MX Record for the no-mail domain, or having no MX record at all?


Thanks in advance for all advices,

--

Pirawat.

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[borg]

Thats cute, but remember that there are gazylion of legacy systems
on Internet as well. They might have no clue what do do with it..
Also remember that MTA is supposed to accept email to [ip] too.

On my opinion, its best to just have no MX record at all.
While MTA can fallback and try to do delivery by IN A record, I think
its not that big problem. You need to specify for what domains you
accept email anyway. And spammers will not care at all...


-- Original message --

From: Pirawat WATANAPONGSE via NANOG 
To: nanog@nanog.org
Subject: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 17:19:41 +0700

Dear all,


I put the ˙˙Null MX˙˙ Record (RFC 7505) into one of my domains yesterday,
then those online mail diagnostic tools out there start getting me worried:

It looks like most of those tools do not recognize the Null MX as a special
case; they just complain that they cannot find the mail server at ˙˙.˙˙
[Sarcasm: as if the root servers are going to provide mail service to a
mere mortal like me!]

Among a few shining exceptions (in a good way) is the good ol˙˙
https://bgp.he.net/ which does not show that domain as having any MX record.
[maybe it is also wrong, in the other direction?]

I fear that the MTAs are going to behave that same way, treating my Null MX
as a ˙˙misconfigured mail server name˙˙ and that my record will mean
unnecessary extra queries to the root servers. [well, minus cache hit]

So, here comes the questions:
1. Is there anyone actively using this Null MX? If so, may I please see
that actual record line (in BIND zone file format) just to satisfy myself
that I wrote mine correctly?
2. Which one makes more sense from the practical point-of-view: having a
Null MX Record for the no-mail domain, or having no MX record at all?


Thanks in advance for all advices,

--

Pirawat.

Re: Texas internet connectivity declining due to blackouts

[borg]

Hold on.. Math doesnt add-up here.
Are you telling me that a gallon propane tank (3.8l) can last
24 hours for about 1000W power generation. Are you sure?
I could belive for 6 hours... maybe 8.. not 24 hours.
So either you are using up 200-300W.. or you have superior power
generator. Can you share what are you using?

-- Original message --

From: Michael Thomas 
To: nanog@nanog.org
Subject: Re: Texas internet connectivity declining due to blackouts
Date: Wed, 17 Feb 2021 09:56:06 -0800

We just run extension cords and don't have a transfer switch. It's pretty
surprising what you can run on about a kw. A gallon propane tank lasts close to
24 for us.

Mike

Re: DoD IP Space

[borg]

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 
To: Sabri Berisha 
Cc: nanog , Grant Taylor 
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

Re: Fiber Bypass Switch

[Jakob Borg]

There's also for example
http://www.silicom-usa.com/Intelligent_Bypass_Switches/IBS10G-Intelligent_10G_Bypass_Switch_33

//jb

2014-01-27 Keyser, Philip :
> Does anyone have any recommendations for a fiber bypass switch? I am looking 
> for something capable of 10G that when there is a power hit will fail over to 
> route traffic out the network ports and away from that site's with the 
> customer handoff.
>
> Thanks,
> Phil Keyser
>