Smaller than a /24 for BGP?

Mon Jan 30 06:31:02 UTC 2023

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
>     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.

To my surprise, I've found that the current (2017) happy eyeball
already does so as is stated in rfc8305:

: Appendix A.  Differences from RFC 6555
:    o  how to handle multiple addresses from each address family

So, we are ready for end to end multihoming for which multiple
PA addresses are enough and /24 is not necessary. Though
not all the application protocols may support it, DNS, SMTP
and HTTP(S) should be good enough as a starter.

It should be noted that happy eyeball strongly depends on
DNS, even though someone might think DNS not guaranteed.

Your web server is multihomed if you assign it PA
addresses assigned from multiple ISPs and register
the addresses to DNS. You don't have to manage BGP.

> TCP modification is just an option useful for long lasting
> TCP connections.

A major obstacle for it, as most of you can see, is that there
are people who can't distinguish IP address changes by mobility
and by multihoming. Such people will keep reinventing MPTCP.

						Masataka Ohta