maximum ipv4 bgp prefix length of /24 ?

Fri Sep 29 17:13:10 UTC 2023

Let me see if I can summarize, tell me where I’m wrong…

You: Give me this for free, give me that for free, sponsor me, why isn’t HE giving me something for free, everyone else should spend money to upgrade infrastructure to handle my request for /27, but I shouldn’t have to pay for anything…

Jason

From: NANOG <nanog-bounces+jasonbaugher=adamstel.com at nanog.org> On Behalf Of VOLKAN SALIH
Sent: Friday, September 29, 2023 2:45 AM
To: Vasilenko Eduard <vasilenko.eduard at huawei.com>; Owen DeLong <owen at delong.com>
Cc: nanog at nanog.org
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

CAUTION: This email is from OUTSIDE our organization.
Please do not open/download any attachment or click any link unless you know it's safe.

Many people from big companies/networks are either member of NANOG or following/reading NANOG from archives.

I was also going to ask if anyone / any company can sponsor (feeless) IPv4 /24 prefix for my educational research network? (as209395)

We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI records and check RPKI of BGP peers.

We also consider to have BGP session with HE.net and CogentCo in the future, so we can re-announce their single-homed prefixes to each other, as charity. For the good of everyone on the internet..

Mr. M.Leber from He.net also stopped feeless BGP tunnel service, as he has not seen financial benefit, while still talking about community-give-back?! And he still seeks feeless peering from CogentCo, you get what you give.whatever goes around comes around

Thanks for reading, best regards and wishes

29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:
Well, it depends.
The question below was evidently related to business.
IPv6 does not have yet a normal way of multihoming for PA prefixes.
If IETF (and some OTTs) would win blocking NAT66,
Then /48 propoisiton is the proposition for PA (to support multihoming).
Unfortunately, it is at least a 10M global routing table as it has been shown by Brian Carpenter.
Reminder, The IPv6 scale on all routers is 2x smaller (if people would use DHCP and longer than/64 then the scale would drop 2x additionally).
Hence, /48 proposition may become 20x worse for scale than proposed initially in this thread.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com at nanog.org] On Behalf Of Owen DeLong via NANOG
Sent: Friday, September 29, 2023 7:11 AM
To: VOLKAN SALİH <volkan.salih.06 at gmail.com><mailto:volkan.salih.06 at gmail.com>
Cc: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need?

Owen

On Sep 28, 2023, at 14:25, VOLKAN SALİH <volkan.salih.06 at gmail.com<mailto:volkan.salih.06 at gmail.com>> wrote:

hello,

I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient for most of the small and medium sized organizations and also home office workers like youtubers, and professional gamers and webmasters!

It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world.

What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM? those would probably handle /27s and while small networks mostly use default routing, it should be reasonable to allow /25-/27?

Thanks for reading, regards..

Jason Baugher, Network Operations Manager
405 Emminga Road | PO Box 217 | Golden, IL 62339-0217
P (217) 696-4411 | F (217) 696-4811 | www.adams.net<http://www.adams.net/>
[Adams-Logo]<http://adams.net/>
________________________________
The information contained in this email message is PRIVILEGED AND CONFIDENTIAL, and is intended for the use of the addressee and no one else. If you are not the intended recipient, please do not read, distribute, reproduce or use this email message (or the attachments) and notify the sender of the mistaken transmission. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230929/20bd2497/attachment.html>