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....@nanog.org> On Behalf Of 
VOLKAN SALIH
Sent: Friday, September 29, 2023 2:45 AM
To: Vasilenko Eduard <vasilenko.edu...@huawei.com>; Owen DeLong 
<o...@delong.com>
Cc: nanog@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....@nanog.org] On 
Behalf Of Owen DeLong via NANOG
Sent: Friday, September 29, 2023 7:11 AM
To: VOLKAN SALİH <volkan.salih...@gmail.com><mailto:volkan.salih...@gmail.com>
Cc: nanog@nanog.org<mailto:nanog@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...@gmail.com<mailto:volkan.salih...@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.

Reply via email to