Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Collider]

While I agree with the thrust of what Sabri is saying, let's not delude 
ourselves - this is not a freedom of speech/"1st amdt." issue. The freedom of 
the press does not mean the government is obligated not to favour given presses 
(to include its own). That one's religion - freedom of religion means the 
government cannot (dis)favour any religion to be practiced by any given person 
(except, in many European countries, the King).

This is primarily a disability rights or equal protection issue (a disabled 
person should be able to choose some aspects of an emergency alert e.g. 
strobing their lights rather than firing a siren, or doing neither if their 
response to the startle response would train them to hit dismiss w/o reading, 
by which point the alert isn't saved as a notification). Disability rights 
frankly are not widely recognized by governments, even where laws exist.

There's also the risk that this could create false alarm over non-alarming 
circumstances used spuriously by parties with alerting access.

Le 5 octobre 2023 15:31:00 UTC, Grant Taylor via NANOG  a 
écrit :
>On 10/4/23 6:15 PM, Sabri Berisha wrote:
>> If this is true, and I will take your word for it, that is outrageous.
>
>Why is this outrageous?
>
>> My wife is a teacher who works with special needs kids, and her phone went 
>> of twice (the second time 15 minutes after the first). This was very 
>> disruptive as you can imagine.
>
>I can understand and appreciate the situation.
>
>> Obviously, I made sure all of the emergency notifications were set to OFF on 
>> her phone. If setting this nonsense to OFF is not working, why even have the 
>> menu option?
>
>Because the menu options apply to -- let's go with -- lesser priority / lower 
>authority alerts.
>
>> The government has no right to disrupt the day of 350 million people, 
>> however much the self-appointed emergency communication "professionals" like 
>> to think so.
>
>I can't speak to the government's right to do something or not.
>
>But I can see why governments would want the ability for one person, or their 
>proxies, to have the technical capability to send an alert to all devices in 
>their territory.
>
>I think this is a case of where four nines of alerts can be suppressed in 
>software, but the fifth nine deliberately can't be suppressed.
>
>> Furthermore, it's simply unnecessary. It is incredibly easy to add a one-bit 
>> flag indicating whether or not it's a test to such alerts.
>
>There is a test flag.
>
>My phone shows an option to ignore tests.
>
>My phone does ignore weekly tests without any problem.
>
>It seems to be that the powers that be decided to send this test without the 
>test bit set.  --  Or perhaps the presidential indicator is mutually exclusive 
>to the test bit.
>
>> This whole test was a display of poor engineering and disrespect for 
>> people's first amendment rights.
>
>I disagree.  But I digress.
>
>> Thanks,
>
>:-)
>
>
>
>-- 
>Grant. . . .
>unix || die
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Using RFC1918 on Global table as Loopbacks

[Saku Ytti]

On Thu, 5 Oct 2023 at 20:45, Niels Bakker  wrote:

> The recommendation is to make Router-IDs globally unique. They're used
> in collision detection. What if you and a peer pick the same non
> globally unique address? Any session will never come up.

https://datatracker.ietf.org/doc/html/rfc6286

  If the BGP Identifiers of the peers involved in the connection
  collision are identical, then the connection initiated by the BGP
  speaker with the larger AS number is preserved

-- 
  ++ytti

APRICOT 2024: Call for Programme Committee Volunteers

[Mark Tinka]

Hi everyone.

The APRICOT 2024 Organising Committee would like to welcome everyone to 
join us in Bangkok, Thailand, from 21st February to 1st March 2024.


The APRICOT 2024 Programme Committee is responsible for the solicitation 
and selection of suitable presentation and tutorial content for the 
APRICOT 2024 conference (https://2024.apricot.net/).


We are now seeking nominations from the community to join the APRICOT 
2024 PC to assist with the development of the programme for APRICOT 2024.


Eligible PC candidates must have attended recent APRICOT events, have 
broad technical knowledge of Internet operations, and have good 
familiarity with the format of APRICOT. Having constructive opinions and 
ideas about how the programme content might be improved is of high value 
too. PC members are expected to work actively to solicit content and 
review submissions for technical merit. The PC meets by conference call, 
weekly in frequency during the three months prior to APRICOT.


If you are interested in joining the PC and meet the above eligibility 
criteria, please send a brief note to "pc-chairs at apricot.net". The 
note must include affiliation (if any) and a brief description about why 
you would make a good addition to the PC.


The PC Chairs will accept nominations received by 17:00 UTC+8 on Friday 
20th October 2023, and will announce the new PC shortly thereafter.


Many thanks!

Mark Tinka & Mark Duffell
For the APRICOT 2024 Organising Committee
--

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Wed, Oct 4, 2023 at 11:33 PM Mark Tinka  wrote:

>
>
> On 10/5/23 08:24, Geoff Huston wrote:
>
> The IPv6 FIB is under the same pressure from more specifics. Its taken 20
> years to get there, but the IPv6 FIB is now looking stable at 60% opf the
> total FIB size [2]. For me, thats a very surprising outcome in an
> essentially unmanaged system.
>
>
> Were you expecting it to be lower than IPv4?
>
> Mark.
>

I've dug through the mailman mirror on nanog.org, and there's currently no
post by Geoff Huston saying that:

https://community.nanog.org/search?q=geoff%20huston%20order%3Alatest

But I'll play along.

There's significantly less pressure to deaggregate IPv6 space right now,
because we don't see many attacks on IPv6 number resources.
Once we start to see v6 prefix hijackings, /48s being announced over /32
prefixes to pull traffic, then I think we'll see IPv6 deaggregation
completely swamp IPv4 deaggregation.
Either that, or content sites will simply turn off IPv6  records during
periods of attack, and let the traffic shift back to IPv4 instead.

When your IPv4 space gets hijacked, there's no fallback; you announce /24s,
because that's all you *can* do.
When your IPv6 space gets hijacked, there's always IPv4 as the fallback, so
there's less pressure to announce /48s for all your space, just in case
someone tries to hijack itl.
Otherwise, we would already be seeing the IPv6 deaggregation completely
overwhelming the IPv4 deaggregation.

Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Geoff Huston]

> On 6 Oct 2023, at 6:13 am, Owen DeLong  wrote:
> 
> Ratio of FIB to RIB is only part of the equation.
> 
> IPv6 is NOT under the disaggregation pressure that IPv4 is under because 
> there is no pressure (other than perhaps scarcity mentality from those that 
> don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize 
> IPv6 allocations.
> 
> Look at the difference in prefixes per ASN across the two tables and that 
> tells a much grimmer story for IPv4 in terms of RIB growth vs. IPv6.


hmm - IPv4 is at [1], IPv6 is at [2]

Now I’m trying to understand what your grimmer story for IPv4 might be here 
Owen. Since 2005 the number of IPv4 FIB entries per origin AS has increased 
fropm 8 to 12 in the past 20 years - or a 50% increase. Over ther same period 
the number of IPv6  prefix advertisements per origin AS has increased from 1.5 
to 6, or a fourfold increase. If anything, the IPv6 story appears to me to be a 
far greater cause for concern, but you may have a different interpretation of 
this data.

Geoff



[1] 
https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2%2e0%2fbgp%2dentries%2das%2etxt=Average%20entries%20per%20origin%20AS=Average%20entries%20per%20origin%20AS=step@%82%966%88U

[2] 
https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2%2e0%2fbgp%2dentries%2das%2etxt=Average%20entries%20per%20origin%20AS=Average%20entries%20per%20origin%20AS=step

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Thu, Oct 5, 2023 at 12:11 PM Owen DeLong via NANOG  wrote:
> So far, that seems to be largely the case, with more than 50% of ASNs 
> represented in the DFZ in IPv6, we see
> roughly 191884 unique destinations in IPv6 and 942750 unique destinations in 
> IPv4 (admittedly an instantaneous
> snapshot a few moments ago from a single DFZ router, YMMV).

When you realize that an IPv6 address takes 4 times the space as an
IPv4 address that picture isn't so rosy any more. The impact on
critical-path router resources isn't quite 4x of course, but as you
say: only 50% of the ASes are represented.

Regards,
Bill Herrin


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

Re: Using RFC1918 on Global table as Loopbacks

[William Herrin]

On Thu, Oct 5, 2023 at 9:42 AM Javier Gutierrez
 wrote:
> the loopback of the core network devices is being set from RFC1918
> while on the global routing table. I'm sure this is not a major issue but
> I have mostly seen that ISPs use global IPs for loopbacks on devices
> that would and hold global routing.

Hi Javier,

It depends.

If the loopback is used as the address source for unnumbered
interfaces and any of the router's interfaces have differing MTUs then
you have a red-alarm fire: you've broken path MTU discovery which
breaks TCP. The problem is that the router will originate ICMP
destination unreachable, fragmentation needed messages from that
address. Those packets will then be filtered entering other networks.
Without those messages, the client TCP stack doesn't know to reduce
its packet size. It fails with the symptom that the initial connection
succeeds but then the first large data stream immediately times out
and the connection aborts after a couple minutes.

Even if you have the same MTU on all interfaces, you've still broken
traceroute since the TTL exceeded messages don't get through.

On the other hand, if the loopback is only used to anchor BGP, you
select the BGP router ID from a different address and all your
network-facing interfaces have global IP addresses then everything
should work fine. As you change the configuration over time you'll
have to be mindful that you're riding a knife edge, but nothing will
actually break.

Regards,
Bill Herrin



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

Re: Using RFC1918 on Global table as Loopbacks

[Randy Bush]

> I have recently encountered some operational differences at my new
> organization that are not what I have been exposed to before, where
> the loopback of the core network devices is being set from RFC1918
> while on the global routing table. I'm sure this is not a major issue
> but I have mostly seen that ISPs use global IPs for loopbacks on
> devices that would and hold global routing.
>
> My question is, what is the most used or recommended way to do this,
> if I continue to use RFC1918 I will save some very much desired public
> address space, but would this come back to bite me in the future?

loopback addressing does not have to be used for router ids.  so
decouple that consideraton.  make up router ids; 1, 42, 3, 4, ...
whatever.  they just need to be unique within the AS.

< corner case >

you may want to have your loopbacks in real global space for routers
which are on an IX.  i have been having fun where an IX router is
sourcing packets from the IX interface, and responses can not come
back because the IX space is not announced globally.  so one wants
to tell the protocol originating those packets (ntp, dns, whatever)
to source from the loopback.  and, for replies to get back to that
loopback, it needs to be in real global space.

randy

Re: Using RFC1918 on Global table as Loopbacks

[Aaron1]

I carry public Internet routing in a vrf, and my loopback and internal IGP 
interfaces are in the master/default vrf

Aaron

> On Oct 5, 2023, at 12:24 PM, Javier Gutierrez  
> wrote:
> 
> 
> Hi, 
> I have recently encountered some operational differences at my new 
> organization that are not what I have been exposed to before, where the 
> loopback of the core network devices is being set from RFC1918 while on the 
> global routing table. I'm sure this is not a major issue but I have mostly 
> seen that ISPs use global IPs for loopbacks on devices that would and hold 
> global routing.
> My question is, what is the most used or recommended way to do this, if I 
> continue to use RFC1918 I will save some very much desired public address 
> space, but would this come back to bite me in the future?
> 
> 
> Kind regards,
> 
>  
> 
> Javier Gutierrez,
> 
>  
> 
>  

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

Ratio of FIB to RIB is only part of the equation.

IPv6 is NOT under the disaggregation pressure that IPv4 is under because there 
is no pressure (other than perhaps scarcity mentality from those that don’t 
properly understand IPv6) to dense-pack IPv6 assignments or undersize IPv6 
allocations.

Look at the difference in prefixes per ASN across the two tables and that tells 
a much grimmer story for IPv4 in terms of RIB growth vs. IPv6.

Owen


> On Oct 4, 2023, at 23:30, Mark Tinka  wrote:
> 
> 
> 
> On 10/5/23 08:24, Geoff Huston wrote:
> 
> 
>> The IPv6 FIB is under the same pressure from more specifics. Its taken 20 
>> years to get there, but the IPv6 FIB is now looking stable at 60% opf the 
>> total FIB size [2]. For me, thats a very surprising outcome in an 
>> essentially unmanaged system. 
> 
> Were you expecting it to be lower than IPv4?
> 
> Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

I think it needs to be slightly more nuanced than that…

Because IPv4 is driven to dense-packing and tight allocations, I think 
disaggregation of IPv4 will only increase over time.

The hope is that by issuing larger than needed blocks of IPv6, less 
disaggregation becomes necessary over time.

So far, that seems to be largely the case, with more than 50% of ASNs 
represented in the DFZ in IPv6, we see
roughly 191884 unique destinations in IPv6 and 942750 unique destinations in 
IPv4 (admittedly an instantaneous
snapshot a few moments ago from a single DFZ router, YMMV).

Even if we double the IPv6 prefix count or even quadruple it, we’re still 
looking at a much smaller level of disaggregation
in IPv6 than IPv4 in the current state.

Owen


> On Oct 4, 2023, at 22:49, Crist Clark  wrote:
> 
> Been resisting adding to this thread...
> 
> But if the assumption is that networks will always eventually totally 
> deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be 
> nothing. The current practice of accepting /48s could swell to about 2^(48 - 
> 3) = 2^45 = 35184372088832.
> 
> What will prevent unrestricted growth of the IPv6 table if operators push 
> everything out to /48 "to counter hijacks" or other misguided reasons?
> 
> On Wed, Oct 4, 2023 at 8:14 AM Owen DeLong via NANOG  > wrote:
>> If you maximally disaggregate to /24, you end up with about 12M fib entries. 
>> At /25 this doubles and you double it again for every bit you move right. 
>> 
>> At /24, we are on borrowed time without walking right. Also, the CPU in most 
>> routers won’t handle the churn of a 10M prefix RIB. 
>> 
>> Owen
>> 
>> 
>> > On Oct 4, 2023, at 03:15, Mark Tinka  wrote:
>> > 
>> > 
>> > 
>> >> On 10/4/23 12:11, Musa Stephen Honlue wrote:
>> >> 
>> >> Which one is easier,
>> >> 
>> >> 1. Convincing the tens of thousands of network operators and equipment 
>> >> vendors to modify configs and code to accept more specifics than /24, or
>> > 
>> > Equipment vendors can already support 10 million entries in FIB. They just 
>> > ask for a little bit of cash for it.
>> > 
>> > Mark.
>> 
>> 

Autoresponders gone wild - edg.io (or Meta), make it stop

[Jon Lewis]

I'm on my last full day at StackPath, and a couple of autoresponders are 
making my work email even less usable than usual.  It would seem G-Core 
Labs S.A. (ASN 199524) sent a peering request cc'd to every address they 
could find relevant to @INEX LAN1 Dublin, and the various autoresponders 
have been duking it out since about 5:49am Eastern.


The only one still emailing everyone several times/minute is 
supp...@edg.io.  If anyone knows someone at edg.io who can make this stop, 
please suggest they do so asap.


It would appear n...@meta.com is also involved, but at least Meta's 
autoresponder has the good sense/programming to not spam the entire 
recipient list...but it likely playing ping pong with supp...@edg.io.


Date: Thu, 5 Oct 2023 11:41:41 -0700 (PDT)
From: Edgio Support 
Reply-To: supp...@edg.io
To: [long list removed]
Message-ID: 
<10724763.48851.1696531301...@app137049.phx101.service-now.com>

Subject: Incident INC1751177 -- You are on the watchlist for ticket
 PTKT3218420 -- comments added
...
Comments:
2023-10-05 11:45:29 PDT - Guest (Additional comments (client notes))
Reply from: n...@meta.com


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Using RFC1918 on Global table as Loopbacks

[Niels Bakker]

* gutierr...@westmancom.com (Javier Gutierrez) [Thu 05 Oct 2023, 19:25 CEST]:
I have recently encountered some operational differences at my new 
organization that are not what I have been exposed to before, where 
the loopback of the core network devices is being set from RFC1918 
while on the global routing table. I'm sure this is not a major 
issue but I have mostly seen that ISPs use global IPs for loopbacks 
on devices that would and hold global routing.


My question is, what is the most used or recommended way to do this, 
if I continue to use RFC1918 I will save some very much desired 
public address space, but would this come back to bite me in the 
future?


The recommendation is to make Router-IDs globally unique. They're used 
in collision detection. What if you and a peer pick the same non 
globally unique address? Any session will never come up.


You need globally unique IP addresses on routers anyway, to send ICMP 
error packets from.



-- Niels.

Using RFC1918 on Global table as Loopbacks

[Javier Gutierrez]

Hi,
I have recently encountered some operational differences at my new organization 
that are not what I have been exposed to before, where the loopback of the core 
network devices is being set from RFC1918 while on the global routing table. 
I'm sure this is not a major issue but I have mostly seen that ISPs use global 
IPs for loopbacks on devices that would and hold global routing.
My question is, what is the most used or recommended way to do this, if I 
continue to use RFC1918 I will save some very much desired public address 
space, but would this come back to bite me in the future?



Kind regards,


Javier Gutierrez,

Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Grant Taylor via NANOG]

On 10/4/23 6:15 PM, Sabri Berisha wrote:

If this is true, and I will take your word for it, that is outrageous.


Why is this outrageous?

My wife is a teacher who works with special needs kids, and her phone 
went of twice (the second time 15 minutes after the first). This was 
very disruptive as you can imagine.


I can understand and appreciate the situation.

Obviously, I made sure all of the emergency notifications were set 
to OFF on her phone. If setting this nonsense to OFF is not working, 
why even have the menu option?


Because the menu options apply to -- let's go with -- lesser priority / 
lower authority alerts.


The government has no right to disrupt the day of 350 million people, 
however much the self-appointed emergency communication "professionals" 
like to think so.


I can't speak to the government's right to do something or not.

But I can see why governments would want the ability for one person, or 
their proxies, to have the technical capability to send an alert to all 
devices in their territory.


I think this is a case of where four nines of alerts can be suppressed 
in software, but the fifth nine deliberately can't be suppressed.


Furthermore, it's simply unnecessary. It is incredibly easy to add a 
one-bit flag indicating whether or not it's a test to such alerts.


There is a test flag.

My phone shows an option to ignore tests.

My phone does ignore weekly tests without any problem.

It seems to be that the powers that be decided to send this test without 
the test bit set.  --  Or perhaps the presidential indicator is mutually 
exclusive to the test bit.


This whole test was a display of poor engineering and disrespect for 
people's first amendment rights.


I disagree.  But I digress.


Thanks,


:-)



--
Grant. . . .
unix || die

N89 Keynote + Taste the Best of San Diego Without Ever Leaving Conference + More

[Nanog News]

*   Introducing N89 Keynote Speakers! *
* Don't Miss Out — Sync Your Calendars Now *

* Monday Keynote:* The Expanding Landscape of Internet Governance: Why
Network
 Operators Need a Global View w/ President and CEO of ARIN, John Curran.

* Tuesday Keynote:* Fireside Chat with COO of Arista Networks, Anshul
Sadana + NANOG
  Producer Elizabeth Drolet. Get to know the man behind the tech and
learn more about how
  to stay successful in today's rapidly changing environment.


* LEARN MORE  *


*   Taste the Best of San Diego Without Ever Leaving Conference*
*N89 Venue Offers Activities + Award-Winning Dining On-Site*

 Surrounded by the remarkable San Diego skyline and secluded by the
breathtaking bay
 waters, Loews Coronado Bay Resort is known as a “private oasis.”

 It is additionally a hot spot for endless activities and award-winning
local dining. There is
 something for everyone, from sailboat excursions, gondola rides, bike
paths, scenic
 beach strolls to an ocean-inspired spa.

* READ MORE
*

*Coming to the NANOG 89 Stage*
*View Full Agenda Now*

 + The Return of NANOG Jeopardy! w/ Charles Rumford
 + The History and Future of Ethernet - 50th Anniversary w/ Mikaell Holmberg
 + Pushing Nx400G Further w/ Filipe Correia
 + Bringing True Load Balancing to Your On-Premises Kubernetes Cluster w/
Mauricio
Rojas
 + DScope: A Cloud-Native Internet Telescope w/ Eric Pauley

 + Much, Much, More!

 *VIEW AGENDA* 

*NANOG 89 Meeting Floor Plans*
*On-Site Map for Various Locations at Conference*

Did you know that meeting floor plans for the NANOG 89 conference venue are
available?

Map out your speaker + networking schedule today. Go to the NANOG 89 Agenda
page and scroll to the bottom to enlarge any floor plan.




*VIEW NOW  Still Time
to Register Virtually!*
*Can't Make it San Diego? Join Us virtually!*

Stream live presentations, participate in real-time chat forums, enjoy 360
views of General Session + more.





*REGISTER NOW  *

[NANOG-announce] N89 Keynote + Taste the Best of San Diego Without Ever Leaving Conference + More

[Nanog News]

*   Introducing N89 Keynote Speakers! *
* Don't Miss Out — Sync Your Calendars Now *

* Monday Keynote:* The Expanding Landscape of Internet Governance: Why
Network
 Operators Need a Global View w/ President and CEO of ARIN, John Curran.

* Tuesday Keynote:* Fireside Chat with COO of Arista Networks, Anshul
Sadana + NANOG
  Producer Elizabeth Drolet. Get to know the man behind the tech and
learn more about how
  to stay successful in today's rapidly changing environment.


* LEARN MORE  *


*   Taste the Best of San Diego Without Ever Leaving Conference*
*N89 Venue Offers Activities + Award-Winning Dining On-Site*

 Surrounded by the remarkable San Diego skyline and secluded by the
breathtaking bay
 waters, Loews Coronado Bay Resort is known as a “private oasis.”

 It is additionally a hot spot for endless activities and award-winning
local dining. There is
 something for everyone, from sailboat excursions, gondola rides, bike
paths, scenic
 beach strolls to an ocean-inspired spa.

* READ MORE
*

*Coming to the NANOG 89 Stage*
*View Full Agenda Now*

 + The Return of NANOG Jeopardy! w/ Charles Rumford
 + The History and Future of Ethernet - 50th Anniversary w/ Mikaell Holmberg
 + Pushing Nx400G Further w/ Filipe Correia
 + Bringing True Load Balancing to Your On-Premises Kubernetes Cluster w/
Mauricio
Rojas
 + DScope: A Cloud-Native Internet Telescope w/ Eric Pauley

 + Much, Much, More!

 *VIEW AGENDA* 

*NANOG 89 Meeting Floor Plans*
*On-Site Map for Various Locations at Conference*

Did you know that meeting floor plans for the NANOG 89 conference venue are
available?

Map out your speaker + networking schedule today. Go to the NANOG 89 Agenda
page and scroll to the bottom to enlarge any floor plan.




*VIEW NOW  Still Time
to Register Virtually!*
*Can't Make it San Diego? Join Us virtually!*

Stream live presentations, participate in real-time chat forums, enjoy 360
views of General Session + more.





*REGISTER NOW  *
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Sam Mulvey]

On 10/4/23 12:14, Grant Taylor via NANOG wrote:
I was kinda surprised that none of my NOAA weather radios went off. I 
sorta assumed they'd be tied into the whole "national" alert setup.


That surprises me.

Did the newer alert not get bridged into the same system that NOAA 
radios use?


Is this by chance a Specific Area Message Encoding (S.A.M.E.) 
filtering / lack of data issue?


Can anyone corroborate NOAA weather radios not alerting? 



I was told this was intentional, as the intent was to test IPAWS and 
associated technologies vs. the NPT chain.   I work at a few small radio 
stations, so this was most of my day.


The FCC is mandating (very shortly) that broadcasters start weighting 
the digital alerts over the messages received from other radio stations, 
which is an upgrade that's going to cost us a bit.


-Sam

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 10/5/23 08:32, Geoff Huston wrote:


Not really.

The stability of number in IPv4 as compared to the monotonic rise in IPv6 is 
what I find to be curious.


I think the fact that RIR's allocate very large IPv6 address space to 
their members may well be what is driving this.


Historically, network operators do enjoy de-aggregating address space. 
One can get significantly more /48's out of a /32 (or shorter) than they 
would /24's out of any IPv4 allocation they acquired.


One way to control this escalation is to shorten the maximum prefix 
length that all operators are willing to accept into the DFZ. The other 
way would be to get RIR's to lengthen the minimum allocation they can 
make to their members. Neither of these solutions is likely to be 
popular, but nor is having to pay large sums of money for more FIB.


Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 10/5/23 08:24, Geoff Huston wrote:

The IPv6 FIB is under the same pressure from more specifics. Its taken 
20 years to get there, but the IPv6 FIB is now looking stable at 60% 
opf the total FIB size [2]. For me, thats a very surprising outcome in 
an essentially unmanaged system. 


Were you expecting it to be lower than IPv4?

Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 10/5/23 07:49, Crist Clark wrote:

But if the assumption is that networks will always eventually totally 
deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be 
nothing. The current practice of accepting /48s could swell to about 
2^(48 - 3) = 2^45 = 35184372088832.


What will prevent unrestricted growth of the IPv6 table if operators 
push everything out to /48 "to counter hijacks" or other misguided 
reasons?


Expecting that the Internet would ever operate at maximum de-aggregation 
is unrealistic. There are too many checkpoints to make that a feasible 
possibility.


It's not an outcome I would spend any brain cycles on, unless as an 
academic exercise.


Mark.