<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 23, 2021, at 12:28 AM, Masataka Ohta <<a href="mailto:mohta@necom830.hpcl.titech.ac.jp" class="">mohta@necom830.hpcl.titech.ac.jp</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Owen DeLong wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">The number of routing table entries is growing exponentially, not<br class="">because of increase of the number of ISPs, but because of multihoming.<br class=""></blockquote>Again, wrong. The number is growing exponentially primarily because<br class="">of the fragmentation that comes from recycling addresses.<br class=""></blockquote><br class="">Such fragmentation only occurs when address ranges are rent to<br class="">others for multihoming but later recycled for internal use,<br class="">which means it is caused by multihoming.<br class=""></div></div></blockquote><div><br class=""></div>Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a class A</div><div>as smaller prefixes to various other purchasers.</div><div><br class=""></div><div>It happens when /16s are sold off to multiple purchasers in pieces.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">Anyway, such cases are quite unlikely and negligible.<br class=""></div></div></blockquote><div><br class=""></div>ROFLMAO you are demonstrating your extreme detachment from reality:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://ipv4marketgroup.com" class="">http://ipv4marketgroup.com</a></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://ipv4auctions.com" class="">http://ipv4auctions.com</a></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>etc.</div><div><br class=""></div><div>There are multiple businesses that do almost nothing outside of these types of transactions.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">There are actually ways to do IPv6 multihoming that don’t require<br class="">using the same prefix with both providers.<br class=""></blockquote><br class="">That's what I proposed 20 years ago both with IPv4 and IPv6 in:<br class=""><br class=""> <a href="https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt" class="">https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt</a><br class=""></div></div></blockquote><div><br class=""></div>THat’s not one of the alternatives I was talking about.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">Yes, there are tradeoffs,<br class="">but these mechanisms aren't even practical in IPv4,<br class=""></blockquote><br class="">Wrong. As is specified by rfc2821:<br class=""><br class=""> When the lookup succeeds, the mapping can result in a list of<br class=""> alternative delivery addresses rather than a single address, because<br class=""> of multiple MX records, multihoming, or both. To provide reliable<br class=""> mail transmission, the SMTP client MUST be able to try (and retry)<br class=""> each of the relevant addresses in this list in order, until a<br class=""> delivery attempt succeeds. However, there MAY also be a configurable<br class=""><br class="">the idea of end to end multihoming is widely deployed by SMTP at<br class="">the application layer, though wider deployment require TCP<br class="">modification as I wrote in my draft.<br class=""></div></div></blockquote><div><br class=""></div>Again, NOT what I was talking about. I was talking about the fact that in IPv6, you can multi-home by applying a prefix from each provider to each subnet. If the upstream connection goes away, deprecate the RA for that prefix and/or mark it as no longer on-link.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Similar specification is also found in section 7.2 of rfc1035.<br class=""></div></div></blockquote><div><br class=""></div>You are talking about pomegranate seeds, I’m talking about Apples. They are not the same, so your statements about my remarks are inherently flawed.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">but have been<br class="">sufficiently widely implemented in IPv6 to say that they are viable<br class="">in some cases.<br class=""></blockquote><br class="">You are just wrong. IP layer has very little to do with it.<br class=""></div></div></blockquote><div><br class=""></div>No, you’re just talking about a form of multihoming that has absolutely nothing to do with the forms I was referring to.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">LISP is garbage.<br class=""></div></div></blockquote></div><br class=""><div class="">Somewhat agree, though the concept wasn’t entirely wrong. Separating Locators from IDs is something we will eventually need to do in order to scale internet routing. LISP is definitely</div><div class="">not the ideal way to do it, but was a valiant attempt if one assumes the constraints of having to operate in an existing IPv6 environment. If one is willing to modify the packet header, then there are better options.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div></body></html>