Re: No, SMTP is IPv4, Was: SMTP and IPv6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dr. Neal Krawetz wrote:

   - Complexity: IPv6 is more complicated than IPv4.

So true, which is why many ISPs. whose major cost is suffered at
the IP layer, are avoiding IPv6.

Though companies such as GAFA and equipment venders are mostly
working at the application layer and their cost to support IPv6
at the internetworking layer is negligible, that argument is
not applicable to ISPs.

   - Startup time:

That is a problem of ND timeout seconds. That is, lost ND messages
can not be resent unless some time out periods have past.

Worse, the periods was specified with tens of seconds or minuets
assuming mostly immobile hosts, even though people developing IPv6
at that time was already using laptop computers.

- Speed: (This is the easiest problem to solve since it's just a
perception issues.) People think "IPv6 is bigger than IPV4 so it must
be slower." Nope, IPv6 is faster because the packets are saner to
parse.

Totally wrong.

IPv4 route look up at the backbone for /24 is to just access a 16M
entry SRAM and is fast, which is impossible even with mostly unused
IPv6 address space.

Worse, with the indefinitely lengthy chain of IP options, IPv6 is
totally broken and is hopeless.

Even without IP options, complexities of IPv4 and IPv6 are not so
different (or, IPv6 is more complex because of removal of fragmentation
en route), though, with same MTU, length of IPv6 header makes it
less efficient to carry payload.

> The next hard part is convincing them to increase the MTU for
> better throughput. ("But everyone uses 1500!" Nope, try 9000 for
> jumbo packets.)

Not. Given header lengths of Ethernet/Wifi/IPv4/IPv6, making MTU
larger than 1.5K is not so meaningful.

Worse, higher layer off loading by channel processors has been common
at least with IBM 7090 as channel I/O, which means jumbograms of IPv6 totally useless:

	https://en.wikipedia.org/wiki/Channel_I/O
	Channel architecture avoids this problem by processing some or
	all of the I/O task without the aid of the CPU by offloading
	the work to dedicated logic.

TLO and DPU are not new ideas, at all.

						Masataka Ohta




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux