Mailing List Archive

multihoming
On Mon, Nov 22, 2021 at 2:49 AM Masataka Ohta
<mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Mans Nilsson wrote:
>
> > Not everyone are Apple, "hp"[0] or MIT, where initial
> > allocation still is mostly sufficient.
>
> The number of routing table entries is growing exponentially,
> not because of increase of the number of ISPs, but because of
> multihoming.
>
> As such, if entities requiring IPv4 multihoming will also
> require IPv6 multihoming, the numbers of routing table
> entries will be same.
>
> The proper solution is to have end to end multihoming:
>
> https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

I'd never read that. We'd made openwrt in particular use "source
specific routing" for ipv6 by default,
many years ago, but I don't know to what extent that facility is used.

ip route from a:b:c:d:/64 via dev A
ip route from a:b:d:d:/64 via dev B


> > Your reasoning is correct, but the size of the math matters more.
>
> Indeed, with the current operational practice. global IPv4
> routing table size is bounded below 16M. OTOH, that for
> IPv6 is unbounded.
>
> Masataka Ohta
>


--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
Re: multihoming [ In reply to ]
Dave Taht wrote:

>> The proper solution is to have end to end multihoming:
>>
>> https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt
>
> I'd never read that. We'd made openwrt in particular use "source
> specific routing" for ipv6 by default,
> many years ago, but I don't know to what extent that facility is used.

Considering that most, if not all, multihomed sites should have
rich (maybe full) routing table in some part (at least) of the
sites between exit routers to balance load between the routers,
I can't see why source specific routing was considered necessary
only to cause routing loops.

For multihoming with PA address ranges with plain TCP/UDP,
what is necessary for ISP failure is to have routing
protocols to carry proper source address ranges for each
routing table entry and to modify end systems to listen to
routing protocol and choose proper source address, which
is against the poor architecture of IPv6/ND to assume
intelligent routers and dumb hosts.

But, even with that, if some ISP fails, TCP/UDP through
the ISP will fail and must be restarted with new source
address, which is not very useful. Moreover, if destination
is also inside another multihomed site with PA address ranges,
all the destination addresses must be tried.

So, as modifying end systems is inevitable, there is
no reason not to support full end to end multihoming
including modifications to support multiple addresses
by TCP and some applications.

Masataka Ohta
Re: multihoming [ In reply to ]
On Wed, 24 Nov 2021 at 08:16, Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

> So, as modifying end systems is inevitable, there is
> no reason not to support full end to end multihoming
> including modifications to support multiple addresses
> by TCP and some applications.
>
> Masataka Ohta
>

Are you proposing SCTP? There is sadly not much more hope for widespread
adoption of that as of IPv6.

Regards,

Baldur
Re: multihoming [ In reply to ]
On Wed, 24 Nov 2021 at 16:16, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

> Are you proposing SCTP? There is sadly not much more hope for widespread adoption of that as of IPv6.

If you use Apple, you use MP-TCP, for better UX while using both
mobile and wifi.

SCTP is no good, because you cannot transition between two
connections, they have to overlap for a period, there is no separation
of identity and location. QUIC actually can do that, in that identity
is PKI and location is IP address, so you could roam from one IP to
another IP without having overlapping connectivity.

--
++ytti
Re: multihoming [ In reply to ]
On Wed, Nov 24, 2021 at 9:12 AM Baldur Norddahl <baldur.norddahl@gmail.com>
wrote:

>
>
> On Wed, 24 Nov 2021 at 08:16, Masataka Ohta <
> mohta@necom830.hpcl.titech.ac.jp> wrote:
>
>> So, as modifying end systems is inevitable, there is
>> no reason not to support full end to end multihoming
>> including modifications to support multiple addresses
>> by TCP and some applications.
>>
>> Masataka Ohta
>>
>
> Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
>
>
or perhaps MP-TCP? :) or shim6?
Re: multihoming [ In reply to ]
> On 25 Nov 2021, at 7:57 am, Christopher Morrow <morrowc.lists@gmail.com> wrote:
>
> Are you proposing SCTP? There is sadly not much more hope for widespread adoption of that as of IPv6.
>
> or perhaps MP-TCP? :) or shim6?

Shim6 died a comprehensive death many yers ago. I recall NANOG played a role in it's untimely demise. :-)

Geoff
Re: multihoming [ In reply to ]
On Wed, Nov 24, 2021 at 5:12 PM Geoff Huston <gih@apnic.net> wrote:

>
>
> > On 25 Nov 2021, at 7:57 am, Christopher Morrow <morrowc.lists@gmail.com>
> wrote:
> >
> > Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
> >
> > or perhaps MP-TCP? :) or shim6?
>
> Shim6 died a comprehensive death many yers ago. I recall NANOG played a
> role in it's untimely demise. :-)
>
>
oh, darn! :)

reading the ID that masataka referenced, it sounded very much like shim6
about ~4 yrs prior to shim6's "invention".
I also don't recall seeing the draft referenced during the shim6
conversations.

Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
nor IPSEC nor GRE nor...
unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!

Talk about layer violations! talk about fun!

-chris
Re: multihoming [ In reply to ]
Baldur Norddahl wrote:

> Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.

My ID describes the architectural framework both for IPv4 and IPv6.

Modification to TCP is discussed, for example, in:

https://datatracker.ietf.org/doc/html/draft-arifumi-tcp-mh-00

I still think something like that is necessary before IPv4 global
routing table size become 16M (ignoring loopback/multicast/ClassE).


Christopher Morrow wrote:

> reading the ID that masataka referenced, it sounded very much like
> shim6 about ~4 yrs prior to shim6's "invention".

No, not at all.

> I also don't recall
> seeing the draft referenced during the shim6 conversations.

Despite my ID saying:

All the other processing can be
performed by transport layer (typically in kernel) using
default or application specific timing of TCP.

Without TCP, applications must be able to detect loss of
connectivity in application dependent way

shim6 is wrongly architected to address the issue at the
*connectionless* IP layer, where there is no proper period
for timeout. Also, transport/application layer information
such as TCP sequence numbers may offer proper security.

Notion of connection (including half one such as DNS
query/reply at the application layer) is essential
for proper state maintenance.

Similar layering violation also occurred to network
layer PMTUD, which is why it is rather harmful than
useful.

Masataka Ohta
Re: multihoming [ In reply to ]
Christopher Morrow <morrowc.lists@gmail.com> writes:

> Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
> nor IPSEC nor GRE nor...
> unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!

IP over DNS has been a thing forever. IP over DoH should work just
fine.

> Talk about layer violations! talk about fun!

Yes, fun...


Bjørn
Re: multihoming [ In reply to ]
On 11/25/21 11:54 AM, Bjørn Mork wrote:
> Christopher Morrow <morrowc.lists@gmail.com> writes:
>
>> Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
>> nor IPSEC nor GRE nor...
>> unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!
> IP over DNS has been a thing forever. IP over DoH should work just
> fine.
>
>> Talk about layer violations! talk about fun!
> Yes, fun...
>
Feh. I've written transistors over http. Beat that.

Mike
Re: multihoming [ In reply to ]
> On Nov 25, 2021, at 12:06 , Michael Thomas <mike@mtcc.com> wrote:
>
>
> On 11/25/21 11:54 AM, Bjørn Mork wrote:
>> Christopher Morrow <morrowc.lists@gmail.com> writes:
>>
>>> Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
>>> nor IPSEC nor GRE nor...
>>> unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!
>> IP over DNS has been a thing forever. IP over DoH should work just
>> fine.
>>
>>> Talk about layer violations! talk about fun!
>> Yes, fun...
>>
> Feh. I've written transistors over http. Beat that.
>
> Mike

I think the only thing I know of that is sillier than that would be Avi Freedman’s BGP4 implementation
on a palm pilot.

Owen