Re: is ipv6 fast, was silly Redeploying

[Owen DeLong via NANOG <nanog () nanog org>]

> On Nov 23, 2021, at 12:28 AM, Masataka Ohta <mohta () necom830 hpcl titech ac jp> wrote:
>
> Owen DeLong wrote:
>
> > > The number of routing table entries is growing exponentially, not
> > > because of increase of the number of ISPs, but because of multihoming.
> > Again, wrong. The number is growing exponentially primarily because
> > of the fragmentation that comes from recycling addresses.
>
> Such fragmentation only occurs when address ranges are rent to
> others for multihoming but later recycled for internal use,
> which means it is caused by multihoming.

Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a class A
as smaller prefixes to various other purchasers.

It happens when /16s are sold off to multiple purchasers in pieces.

> Anyway, such cases are quite unlikely and negligible.

ROFLMAO you are demonstrating your extreme detachment from reality:

        http://ipv4marketgroup.com <http://ipv4marketgroup.com/>
        http://ipv4auctions.com <http://ipv4auctions.com/>
        etc.

There are multiple businesses that do almost nothing outside of these types of transactions.

> > There are actually ways to do IPv6 multihoming that don’t require
> > using the same prefix with both providers.
>
> That's what I proposed 20 years ago both with IPv4 and IPv6 in:
>
>    https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

THat’s not one of the alternatives I was talking about.

> > Yes, there are tradeoffs,
> > but these mechanisms aren't even practical in IPv4,
>
> Wrong. As is specified by rfc2821:
>
>   When the lookup succeeds, the mapping can result in a list of
>   alternative delivery addresses rather than a single address, because
>   of multiple MX records, multihoming, or both.  To provide reliable
>   mail transmission, the SMTP client MUST be able to try (and retry)
>   each of the relevant addresses in this list in order, until a
>   delivery attempt succeeds.  However, there MAY also be a configurable
>
> the idea of end to end multihoming is widely deployed by SMTP at
> the application layer, though wider deployment require TCP
> modification as I wrote in my draft.

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.

> Similar specification is also found in section 7.2 of rfc1035.

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.

> > but have been
> > sufficiently widely implemented in IPv6 to say that they are viable
> > in some cases.
>
> You are just wrong. IP layer has very little to do with it.

No, you’re just talking about a form of multihoming that has absolutely nothing to do with the forms I was referring to.

> LISP is garbage.

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

Owen