On Tue, 24 Jan 2023, William Herrin wrote:

On Tue, Jan 24, 2023 at 10:19 AM Justin Wilson (Lists) <lists@mtin.net> wrote:

...

Have there been talks about the best practices to accept things smaller than a /24?

Hi Justin,

The short version is: it could happen but it won't. There's no technical obstacle. It's purely administrative. Tens of thousands of organizations would have to agree to accept smaller prefixes.That would only happen if there was something in it for them to start doing so, something major. And even then it would be a hard lift. There isn't. Some of those organizations run BGP set up by the last guy, the current gut doesn't really grok it, and he certainly doesn't subscribe to any information channels where it's discussed. So it's not going to happen.

The "other problem" is, every day more gear receiving full routes gets closer to (or farther past) the point where the resources to hold either the FIB or RIB just aren't there. For those using these devices, lowering the bar and bringing in another 100k or so routes in short order just isn't an option. /24 has been the de facto threshold for routes in the v4 table long enough that I wouldn't want to be dependent on that changing. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

On Tue, 24 Jan 2023, William Herrin wrote:

On Tue, Jan 24, 2023 at 11:04 AM Jon Lewis <jlewis@lewis.org> wrote:

...

The "other problem" is, every day more gear receiving full routes gets closer to (or farther past) the point where the resources to hold either the FIB or RIB just aren't there. For those using these devices, lowering the bar and bringing in another 100k or so routes in short order just isn't an option.

Yeah, but in another couple years we'll breach the 1M mark and everybody will have fresh routers with lots of TCAM for a while. If that were the only issue, it'd be a matter of timing the change well.

Everybody will need them. Not all will get (or be able to get) them. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

It appears that Chris J. Ruschmann <chris@scsalaska.net> said:

-=-=-=-=-=- How do you plan on getting rid of all the filters that don’t accept anything less than a /24?

In all seriousness If I have these, I’d imagine everyone else does too.

Right. Since the Internet has no settlements, there is no way to persuade a network of whom you are not a customer to accept your announcements if they don't want to, and even for the largest networks, that is 99% of the other networks in the world. So no, they're not going to accept your /25 no matter how deeply you believe that they should. I'm kind of surprised that we haven't seen pushback against sloppily disaggregated announcements. It is my impression that the route table would be appreciably smaller if a few networks combined adjacent a bunch of /24's into larger blocks. R's, John

We performed some high-level analyses on these hyper-specific prefixes about a year ago and pushed some insights into a blog post [1] and a paper [2]. While not many ASes redistribute these prefixes, some accept and use them for their internal routing (e.g., NTT's IPv4 filtering policy [3]). Rob already pointed out that this is often sufficient for many traffic engineering tasks. In the remaining scenarios, announcing a covering /24 and hyper-specific prefixes may result in some traffic engineering, even if the predictability of the routing impact is closer to path prepending than usual more-specific announcements. In contrast to John's claim, some transit ASes explicitly enabled redistributions of up to /28s for their customers upon request (at least, they told us so during interviews). Accepting and globally redistributing all hyper-specifics increases the routing table size by >100K routes (according to what route collectors see). There are also about 2-4 de-aggregation events every year in which some origin (accidentally) leaks some large number of hyper-specifics to its neighbours for a short time. Best regards, Lars [1] https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-w... [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916 [3] https://www.gin.ntt.net/support-center/policies-procedures/routing/ On 25.01.23 05:12, Forrest Christian (List Account) wrote:

I have two thoughts in relation to this:

1) It's amazing how many threads end up ending in the (correct) summary that making an even minor global change to the way the internet works and/or is configured to enable some potentially useful feature isn't likely to happen.

2) I'd really like to be able to tag a BGP announcement with "only use this announcement as an absolute last resort" so I don't have to break my prefixes in half in those cases where I have a backup path that needs to only be used as a last resort.  (Today each prefix I have to do this with results in 3 prefixes in the table where one would do).

And yes. I know #2 is precluded from actually ever happening because of #1.   The irony is not lost on me.

On Tue, Jan 24, 2023, 7:54 PM John Levine <johnl@iecc.com> wrote:

It appears that Chris J. Ruschmann <chris@scsalaska.net> said: >-=-=-=-=-=- >How do you plan on getting rid of all the filters that don’t accept anything less than a /24? > >In all seriousness If I have these, I’d imagine everyone else does too.

Right. Since the Internet has no settlements, there is no way to persuade a network of whom you are not a customer to accept your announcements if they don't want to, and even for the largest networks, that is 99% of the other networks in the world. So no, they're not going to accept your /25 no matter how deeply you believe that they should.

I'm kind of surprised that we haven't seen pushback against sloppily disaggregated announcements.  It is my impression that the route table would be appreciably smaller if a few networks combined adjacent a bunch of /24's into larger blocks.

R's, John

On Fri, Jan 27, 2023 at 9:49 PM Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

That multihomed sites are relying on the entire Internet for computation of the best ways to reach them is not healthy way of multihoming.

This was studied in the IRTF RRG about a decade ago. There aren't any other workable ways of multihoming compatible with the TCP protocol, not even in theory. Every other mechanism imagined failed some basic system constraint, usually the requirement that packets have administrative permission to cross an intermediate network. So, another way of multihoming critically depends on replacing the layer-4 protocols with something that doesn't intermingle the IP address with the connection identifier. For clarity: TCP's connection identifier consists of the source and destination IP addresses plus the source and destination ports. Those four elements, unique when combined, identify exactly one ongoing TCP connection. Because of this, the connection must fail if the source or destination IP addresses are no longer available to the source or destination hosts. From this fact, we get the requirement that the entire Internet learn when a particular IP address has changed its position within the network. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

On Sat, Jan 28, 2023 at 10:15 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

Use Multipath TCP https://datatracker.ietf.org/group/mptcp/documents/

Doesn't work well. Has security problems (mismatch between reported IP addresses used and actual addresses in use) and it can't reacquire the opposing endpoint if an address is lost before a new one is communicated. MPTCP has been complete for years. The adoption rate is very low. QUIC is better, but it still leaves finding the server's new IP address as an exercise for a process outside of the protocol. I haven't kept my ear to the ground for the last year or two but I haven't heard about it making the expected inroads versus HTTP 1.1 over TCP. Unfortunately, QUIC is a very complex protocol that's very hard to troubleshoot. The complexity comes from a slew of mandatory security components which should have been optional. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

William Herrin wrote:

...

Use Multipath TCP https://datatracker.ietf.org/group/mptcp/documents/

Doesn't work well. Has security problems (mismatch between reported IP addresses used and actual addresses in use) and it can't reacquire the opposing endpoint if an address is lost before a new one is communicated.

It merely means MPTCP is wrongly architected. Dynamically changing IP addresses is for mobility (if you don't mind location privacy), not for multihoming. The following way in my ID: The easiest way for applications know all the addresses of the destination is to use DNS. With DNS reverse, followed by forward, lookup, applications can get a list of all the addresses of the destination from an address of the destination. does not have any such problem and should be as safe as happy eyeball for two or more IPv4/IPv6 addresses. As for (long lasting) TCP, my ID says: With TCP, applications must be able to pass multiple addresses to transport layer (e.g. BSD socket). which implies addresses are supplied from applications by DNS look up. Though a client may, at the time TCP connection is established, send a list of its IP addresses to a server, which may have some security complications, it is simpler to let the server just rely on DNS: With DNS reverse, followed by forward, lookup, applications can get a list of all the addresses of the destination from an address of the destination. As I pointed out in the previous mail, DNS already supports end to end multihoming at the application layer to try all the addresses of name servers, on which other applications can safely rely. Masataka Ohta

William Herrin wrote:

...

The easiest way for applications know all the addresses of the destination is to use DNS. With DNS reverse, followed by forward, lookup, applications can get a list of all the addresses of the destination from an address of the destination.

The DNS provides no such guarantee.

Guarantee for what? Remember that we have been enjoying secure confirmation that certain IP address belongs to certain hostname by DNS reverse look up without any guarantee.

Moreover, the DNS does guarantee its information to be correct until the TTL expires, making it unsuitable for communicating address information which may change sooner.

I'm afraid you know very little about DNS operation. See rfc1034: If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change. which is the way to operate DNS when host addresses are changing, for example, by multihoming configuration changes. In addition, when a dual homed site with end to end multihoming changes one of its ISP, it is a good idea to offer all the three addresses by DNS during the change. Make before break.

...

With TCP, applications must be able to pass multiple addresses to transport layer (e.g. BSD socket).

which implies addresses are supplied from applications by DNS look up.

Which is a bit of hand-waving since the protocol can't do anything with that information regardless of whether you expand the API to provide it.

Read my draft, which explains how TCP should be modified. Masataka Ohta

William Herrin wrote:

...

That multihomed sites are relying on the entire Internet for computation of the best ways to reach them is not healthy way of multihoming.

This was studied in the IRTF RRG about a decade ago. There aren't any other workable ways of multihoming compatible with the TCP protocol, not even in theory.

A decade? The problem and the solution was thoroughly studied by me long ago and the first ID was available already in 2000. The 5th version is here: https://datatracker.ietf.org/doc/html/draft-ohta-e2e-multihoming-05.txt I've found that you can access the first one by "Compare versions" feature of the web page.

So, another way of multihoming critically depends on replacing the layer-4 protocols with something that doesn't intermingle the IP address with the connection identifier.

Wrong. As is stated in my ID that: On the other hand, with end to end multihoming, multihoming is supported by transport (TCP) or application layer (UDP etc.) of end systems and does not introduce any problem in the network and works as long as there is some connectivity between the end systems. end to end multihoming may be supported at the application layer by trying all the available addresses, which is what DNS and SMTP are actually doing. TCP modification is just an option useful for long lasting TCP connections. Masataka Ohta

Thanks to Lars for this interesting input and results (which I wasn't familiar with). I want to mention another concern with the possible use of hyper-specific IP prefixes, i.e., longer than /24, which I haven't seen discussed in the thread (maybe I missed it?). Namely, if you allow say /28 announcements, then what would be the impact of ROV? Seems this can cause few problems: - If origin, say AS 10, makes a ROA for the /28, this would allow an attacker, e.g., AS 666, to do origin-hijack (announce path 666-10 to the /28), and attract traffic for the /28 from anybody accepting /28 announcements (that didn't receive the legit announcement). Plus, of course, you get more overhead in ROA distribution and validation. - If origin makes a ROA only for covering prefix (say /24) then the /28 announcement would be considered invalid by ROV and (even more likely) dropped. Also you get more instances of `invalid' announcements, making adoption of ROVs and ROAs harder. Just a thought... Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:

We performed some high-level analyses on these hyper-specific prefixes about a year ago and pushed some insights into a blog post [1] and a paper [2].

While not many ASes redistribute these prefixes, some accept and use them for their internal routing (e.g., NTT's IPv4 filtering policy [3]). Rob already pointed out that this is often sufficient for many traffic engineering tasks. In the remaining scenarios, announcing a covering /24 and hyper-specific prefixes may result in some traffic engineering, even if the predictability of the routing impact is closer to path prepending than usual more-specific announcements. In contrast to John's claim, some transit ASes explicitly enabled redistributions of up to /28s for their customers upon request (at least, they told us so during interviews).

Accepting and globally redistributing all hyper-specifics increases the routing table size by >100K routes (according to what route collectors see). There are also about 2-4 de-aggregation events every year in which some origin (accidentally) leaks some large number of hyper-specifics to its neighbours for a short time.

Best regards, Lars

[1] https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-w... [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916 [3] https://www.gin.ntt.net/support-center/policies-procedures/routing/

On 25.01.23 05:12, Forrest Christian (List Account) wrote:

I have two thoughts in relation to this:

1) It's amazing how many threads end up ending in the (correct) summary that making an even minor global change to the way the internet works and/or is configured to enable some potentially useful feature isn't likely to happen.

2) I'd really like to be able to tag a BGP announcement with "only use this announcement as an absolute last resort" so I don't have to break my prefixes in half in those cases where I have a backup path that needs to only be used as a last resort. (Today each prefix I have to do this with results in 3 prefixes in the table where one would do).

And yes. I know #2 is precluded from actually ever happening because of #1. The irony is not lost on me.

On Tue, Jan 24, 2023, 7:54 PM John Levine <johnl@iecc.com> wrote:

...

It appears that Chris J. Ruschmann <chris@scsalaska.net> said:

...

-=-=-=-=-=- How do you plan on getting rid of all the filters that don’t accept anything less than a /24?

In all seriousness If I have these, I’d imagine everyone else does too.

Right. Since the Internet has no settlements, there is no way to persuade a network of whom you are not a customer to accept your announcements if they don't want to, and even for the largest networks, that is 99% of the other networks in the world. So no, they're not going to accept your /25 no matter how deeply you believe that they should.

I'm kind of surprised that we haven't seen pushback against sloppily disaggregated announcements. It is my impression that the route table would be appreciably smaller if a few networks combined adjacent a bunch of /24's into larger blocks.

R's, John

Tom, thanks. I forget to mention the problem of this case ( AS 10 creates an ROA for X.X.X.X/24 , maxLength 28). Security-wise, this may actually be the worst solution: - An attacker can abuse this ROA to perform origin-hijack of the /28 subprefix, just like the origin hijack if AS 10 publishes ROA for the /28 - The max-length also allows similar origin-hijack of `intermediate prefixes' (e.g., /25), which may be allowed by ASes which will not allow /28, so there may be an even higher chance for the attacker to succeed in attracting traffic. Of course, this is basically what is discussed in the `maxlength considered harmful' paper and RFC (RFC 9319), nothing really new here. Best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Mon, Jan 30, 2023 at 9:39 AM Tom Beecher <beecher@beecher.cc> wrote:

- If origin makes a ROA only for covering prefix (say /24) then the /28

...

announcement would be considered invalid by ROV and (even more likely) dropped. Also you get more instances of `invalid' announcements, making adoption of ROVs and ROAs harder.

AS 10 creates an ROA for X.X.X.X/24 , maxLength 28. This means AS10 can announce any /28 in that /24, and any validator should return valid. (This ignores if the longer than /24s would be accepted by policy or not. )

On Mon, Jan 30, 2023 at 9:19 AM Amir Herzberg <amir.lists@gmail.com> wrote:

...

Thanks to Lars for this interesting input and results (which I wasn't familiar with).

I want to mention another concern with the possible use of hyper-specific IP prefixes, i.e., longer than /24, which I haven't seen discussed in the thread (maybe I missed it?). Namely, if you allow say /28 announcements, then what would be the impact of ROV? Seems this can cause few problems:

- If origin, say AS 10, makes a ROA for the /28, this would allow an attacker, e.g., AS 666, to do origin-hijack (announce path 666-10 to the /28), and attract traffic for the /28 from anybody accepting /28 announcements (that didn't receive the legit announcement). Plus, of course, you get more overhead in ROA distribution and validation.

- If origin makes a ROA only for covering prefix (say /24) then the /28 announcement would be considered invalid by ROV and (even more likely) dropped. Also you get more instances of `invalid' announcements, making adoption of ROVs and ROAs harder.

Just a thought... Amir -- Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity

On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:

...

We performed some high-level analyses on these hyper-specific prefixes about a year ago and pushed some insights into a blog post [1] and a paper [2].

While not many ASes redistribute these prefixes, some accept and use them for their internal routing (e.g., NTT's IPv4 filtering policy [3]). Rob already pointed out that this is often sufficient for many traffic engineering tasks. In the remaining scenarios, announcing a covering /24 and hyper-specific prefixes may result in some traffic engineering, even if the predictability of the routing impact is closer to path prepending than usual more-specific announcements. In contrast to John's claim, some transit ASes explicitly enabled redistributions of up to /28s for their customers upon request (at least, they told us so during interviews).

Accepting and globally redistributing all hyper-specifics increases the routing table size by >100K routes (according to what route collectors see). There are also about 2-4 de-aggregation events every year in which some origin (accidentally) leaks some large number of hyper-specifics to its neighbours for a short time.

Best regards, Lars

[1] https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-w... [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916 [3] https://www.gin.ntt.net/support-center/policies-procedures/routing/

On 25.01.23 05:12, Forrest Christian (List Account) wrote:

I have two thoughts in relation to this:

1) It's amazing how many threads end up ending in the (correct) summary that making an even minor global change to the way the internet works and/or is configured to enable some potentially useful feature isn't likely to happen.

2) I'd really like to be able to tag a BGP announcement with "only use this announcement as an absolute last resort" so I don't have to break my prefixes in half in those cases where I have a backup path that needs to only be used as a last resort. (Today each prefix I have to do this with results in 3 prefixes in the table where one would do).

And yes. I know #2 is precluded from actually ever happening because of #1. The irony is not lost on me.

On Tue, Jan 24, 2023, 7:54 PM John Levine <johnl@iecc.com> wrote:

...

It appears that Chris J. Ruschmann <chris@scsalaska.net> said:

...

-=-=-=-=-=- How do you plan on getting rid of all the filters that don’t accept anything less than a /24?

In all seriousness If I have these, I’d imagine everyone else does too.

Right. Since the Internet has no settlements, there is no way to persuade a network of whom you are not a customer to accept your announcements if they don't want to, and even for the largest networks, that is 99% of the other networks in the world. So no, they're not going to accept your /25 no matter how deeply you believe that they should.

I'm kind of surprised that we haven't seen pushback against sloppily disaggregated announcements. It is my impression that the route table would be appreciably smaller if a few networks combined adjacent a bunch of /24's into larger blocks.

R's, John

On Tue, 24 Jan 2023, Forrest Christian (List Account) wrote:

I have two thoughts in relation to this:

1) It's amazing how many threads end up ending in the (correct) summary that making an even minor global change to the way the internet works and/or is configured to enable some potentially useful feature isn't likely to happen.

2) I'd really like to be able to tag a BGP announcement with "only use this announcement as an absolute last resort" so I don't have to break my prefixes in half in those cases where I have a backup path that needs to only be used as a last resort.  (Today each prefix I have to do this with results in 3 prefixes in the table where one would do).

And yes. I know #2 is precluded from actually ever happening because of #1.   The irony is not lost on me.

With good upstreams (providing useful BGP communities support), you can do this without cluttering the global table. Say you have multiple upstreams, and you want provider A to treat a.b.c/23 as a "don't use this unless you have no other path" route. They should support a community that allows you to cause them to set localpref lower than their "peer default" (or transit if they admit to buying transit). Then, when you advertise a.b.c/23 to both/all your providers, provider A won't use the direct route unless they're not receiving it from any other source. i.e. You don't have to advertise the /23 to A and a pair of /24s to B, C, etc. to make sure A doesn't use the direct customer route. I don't know that all "tier 1's" support it...but for example, Tata, GTT, Cogent, and NTT do: Tata: Request for Local Preference Adjustment In AS6453 the default local preference (LOCAL_PREF) value for customer-routes is 100, and for peer-routes it is 90. Along the lines of RFC1998, a Tata Communications customer may request other than thedefault local preference: Adjust Local Preference community action 6453:n, n={70, 80, 90, 110} assign local preferencen in AS6453 GTT: 3.2.2 Local Preference Value Description 3257:1980 give routes localpref below normal customer route. 3257:1970 give routes localpref below normal peer route. Cogent: Local Preference All customer routes announced to Cogent will have a local pref of 130. The customer can control the local preference for their announcements by using a community string that is passed to Cogent in the BGP session. The following table lists the community strings and the corresponding local preference that will be set when they are used. Community String Local Pref Effect 174:10 10 Set customer route local preference to 10 (below everything-least preferred) 174:70 70 Set customer route local preference to 70 (below peers) 174:120 120 Set customer route local preference to 120 (below customer default) 174:125 125 Set customer route local preference to 125 (below customer default) 174:135 135 Set customer route local preference to 135 (above customer default) 174:140 140 Set customer route local preference to 140 (above customer default) You get the idea. Everyone likely does it "their own way", so you need to find the BGP community support info for the upstream with which you want non-default behavior / localpref. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

Implementing v6 is important, but unrelated to allowing smaller v4 prefixes. Not taking a position either way if smaller v4 prefixes is good or bad. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Chris" <chris@noskillz.com> To: "Justin Wilson (Lists)" <lists@mtin.net> Cc: nanog@nanog.org Sent: Wednesday, January 25, 2023 2:24:29 PM Subject: Re: Smaller than a /24 for BGP? I would suggest that this is trying to solve the wrong problem. To me this is pressure to migrate to v6, not alter routing rules. Kind Regards, Chris Haun On Tue, Jan 24, 2023 at 12:21 PM Justin Wilson (Lists) < lists@mtin.net > wrote: Have there been talks about the best practices to accept things smaller than a /24? I qm seeing more and more scenarios where folks need to participate in BGP but they do not need a full /24 of space. Seems wasteful. I know this would bloat the routing table immensely. I know of several folks who could split their /24 into /25s across a few regions and still have plenty of IP space. Justin Wilson j2sw@j2sw.com — https://blog.j2sw.com - Podcast and Blog https://www.fd-ix.com

I suspect the initial question was related to scarcity and not traffic engineering. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Michael Bolton <mbolton@holmeselectricsecurity.com> To: Mike Hammett <nanog@ics-il.net>, Chris <chris@noskillz.com> Cc: nanog@nanog.org Sent: Sat, 04 Feb 2023 19:50:07 -0600 (CST) Subject: RE: Smaller than a /24 for BGP? I’m late to the conversation, but I would have to agree with most. Below a /24 route advertisement shouldn’t happen. I have a /24 that I would love to advertise as 2 /25’s, but the affects on everyone else is just too much. I take full routes from 4 providers, and I certainly don’t want to add over 100K. Carriers and enterprises have to pay a lot for our edge routers doing bgp and most don’t want to upgrade. We would benefit from advertising /25’s but it hurt’s more than it helps. I’m in the alarm industry and they still haven’t started adopting IPv6. If we allow /25 subnets, some industries will never change. In a sense, we have to “force” them to change. Mike From: NANOG <nanog-bounces+mbolton=holmeselectricsecurity.com@nanog.org> On Behalf Of Mike Hammett Sent: Thursday, January 26, 2023 8:52 AM To: Chris <chris@noskillz.com> Cc: nanog@nanog.org Subject: Re: Smaller than a /24 for BGP? CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Implementing v6 is important, but unrelated to allowing smaller v4 prefixes. Not taking a position either way if smaller v4 prefixes is good or bad. ----- Mike Hammett Intelligent Computing Solutions<http://www.ics-il.com/> [http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/ICSIL>[http://www.ics-il.com/images/googleicon.png]<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/intelligent-computing-solutions>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/ICSIL> Midwest Internet Exchange<http://www.midwest-ix.com/> [http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/mdwestix>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/midwest-internet-exchange>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/mdwestix> The Brothers WISP<http://www.thebrotherswisp.com/> [http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/thebrotherswisp>[http://www.ics-il.com/images/youtubeicon.png]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> ________________________________ From: "Chris" <chris@noskillz.com<mailto:chris@noskillz.com>> To: "Justin Wilson (Lists)" <lists@mtin.net<mailto:lists@mtin.net>> Cc: nanog@nanog.org<mailto:nanog@nanog.org> Sent: Wednesday, January 25, 2023 2:24:29 PM Subject: Re: Smaller than a /24 for BGP? I would suggest that this is trying to solve the wrong problem. To me this is pressure to migrate to v6, not alter routing rules. Kind Regards, Chris Haun On Tue, Jan 24, 2023 at 12:21 PM Justin Wilson (Lists) <lists@mtin.net<mailto:lists@mtin.net>> wrote: Have there been talks about the best practices to accept things smaller than a /24? I qm seeing more and more scenarios where folks need to participate in BGP but they do not need a full /24 of space. Seems wasteful. I know this would bloat the routing table immensely. I know of several folks who could split their /24 into /25s across a few regions and still have plenty of IP space. Justin Wilson j2sw@j2sw.com<mailto:j2sw@j2sw.com> — https://blog.j2sw.com - Podcast and Blog https://www.fd-ix.com IMPORTANT NOTICE: This e-mail message is intended to be received only by persons entitled to receive the confidential information it may contain. E-mail messages to clients of Holmes Security Systems may contain information that is confidential and legally privileged. Please do not read, copy, forward, or store this message unless you are an intended recipient of it. If you have received this message in error, please forward it to the sender and delete it completely from your computer system.