is ipv6 fast, was silly Redeploying

Owen DeLong owen at delong.com
Tue Nov 23 23:29:55 UTC 2021



> On Nov 23, 2021, at 12:28 AM, Masataka Ohta <mohta at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211123/a7aec41a/attachment.html>


More information about the NANOG mailing list