Re: multihoming
> On Nov 25, 2021, at 12:06 , Michael Thomas wrote: > > > On 11/25/21 11:54 AM, Bjørn Mork wrote: >> Christopher Morrow 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
Re: multihoming
On 11/25/21 11:54 AM, Bjørn Mork wrote: Christopher Morrow 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
Christopher Morrow 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
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
On Wed, Nov 24, 2021 at 5:12 PM Geoff Huston wrote: > > > > On 25 Nov 2021, at 7:57 am, Christopher Morrow > 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
> On 25 Nov 2021, at 7:57 am, Christopher Morrow > 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
On Wed, Nov 24, 2021 at 9:12 AM Baldur Norddahl wrote: > > > On Wed, 24 Nov 2021 at 08:16, Masataka Ohta < > mo...@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
On Wed, 24 Nov 2021 at 16:16, Baldur Norddahl 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
On Wed, 24 Nov 2021 at 08:16, Masataka Ohta < mo...@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
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