Michael Bolton via NANOG wrote:
> We would benefit from advertising /25's but it hurt's more
> than it helps.
That is, IPv6 really hurts.
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
industries will never change. In a sense, we have to
“force” them to change.
Mike
From: NANOG On
Behalf Of Mike Hammett
Sent: Thursday, January 26, 2023 8:52 AM
To: Chris
Cc: nanog@nanog.org
Subject: Re: Smaller than a /24 for BGP?
CAUTION: This email originated from outside
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
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
>
> - 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
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
I wrote:
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
On Sat, Jan 28, 2023 at 11:06 PM Masataka Ohta
wrote:
> William Herrin wrote:
> > 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
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
On Sat, Jan 28, 2023 at 5:48 PM Masataka Ohta
wrote:
> 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
>
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
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
On Sat, Jan 28, 2023 at 11:24 AM William Herrin wrote:
> QUIC is better, but it still leaves finding the server's new IP
> address as an exercise for a process outside of the protocol.
Gah, brain spat out the wrong info. Bad brain.
QUIC doesn't allow the server to change its IP address; only
On Sat, Jan 28, 2023 at 10:15 AM Donald Eastlake 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
Use Multipath TCP
https://datatracker.ietf.org/group/mptcp/documents/
Thanks,
Donald
===
Donald E. Eastlake 3rd
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Sat, Jan 28, 2023 at 10:07 AM William Herrin wrote:
> On Fri, Jan 27, 2023 at 9:49 PM
On Fri, Jan 27, 2023 at 9:49 PM Masataka Ohta
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
Lars Prehn wrote:
Accepting and globally redistributing all hyper-specifics increases
the routing table size by >100K routes (according to what route
collectors see).
That figure is guaranteed minimum but there should be 10 or
100 times more desire for hyper-specifics suppressed by
the
: "Chris"
To: "Justin Wilson (Lists)"
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 ru
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
> 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.
My biggest take-away from this is that software and network
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)
wrote:
> Have there been talks about the best practices to accept things smaller
>
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]).
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
It appears that Chris J. Ruschmann 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
Jon Lewis wrote:
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.
On 2023-01-25 00:10, Chris J. Ruschmann wrote:
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.
Allow someone to advertise a covering /24 (and route onward to the
longer
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.
Have there been talks about the best practices to accept things smaller than a
/24? I qm seeing more and more
On Tue, 24 Jan 2023, William Herrin wrote:
On Tue, Jan 24, 2023 at 11:04 AM Jon Lewis 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
On Tue, Jan 24, 2023 at 11:04 AM Jon Lewis 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
On Tue, 24 Jan 2023, William Herrin wrote:
On Tue, Jan 24, 2023 at 10:19 AM Justin Wilson (Lists) 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
On Tue, Jan 24, 2023 at 10:19 AM Justin Wilson (Lists) 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
Hi,
On Tue, 24 Jan 2023, at 6:19 PM, Justin Wilson (Lists) 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.
Yes, I think one of
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
33 matches
Mail list logo
