Re: Introducing : Brand-new Internet Protocol "Five Fields"

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

 



Hey Alexey,

> Because IPv6 is hard to use, and I wanted to keep look & feel similar
> to IPv4. Problem with IPv6, is that those addresses are very hard for
> humans to remember, compare and visualize topologies in human brain.
> IPv4 has great look & feel, but it is exhausted. So I wrote a new
> replacement for IP.

Evolution does not not end up having best solution popularised, but
first good enough.
I'm not biggest IPv6 fan, but I believe it to be good enough.

> I did it, because I don't like to work with something long like this:
>   2001:db8:2e1:1a73:149f:88ff:fe81:6116

Binary number presentation preference is quite poor argument for all
new protocol.
But I see that you have other, more compelling arguments as well.

> -Mobile TCP, allows moving Mobile Nodes between subnets, without
> losing connectivity. A replacement for Mobile IP. An order of
> magnitude simpler, and requires no access to routers and
> configuration-free.

Good goal. But I prefer L4 solution like MinimaLT and QUIC, where IP
is just low level
routing detail, not identity. Identity being PKI based, IP can change
arbitrarily without any
signalling.

> -IP-VRF header extension, allows doing VRF-VPN without MPLS (and
> without dot1q VLANs)

I can see use cases. But personally, I'd just update MPLS labels
slightly (MPLSv2) and make that
part of IP spec.

> -No IP header checksums (done at layer 4)

I think this was huge mistake in IPv6, instead of removing header
checksum from L3, they should have
added proper polynomial function like ethernet.
Routers and switches today do not guarantee data integrity, they can
mangle data and calculate working
IP checksum and ethernet CRC on mangled data. In IPv4 we would usually
notice this in egress PE,
in IPv6 we have no way of knowing it is happening.
Correct solution would be to have CRC on IP, which does not change and
is not allowed to be recalculated
to the packet on transit.
But this is again problem proper L4, like MinimaLT and QUIC addresses.

> -No autoconfiguration/SLAAC (this belongs to DHCP territory)

Fully agreed.

> -No Layer2 resolution. ARP-free protocol.

This is really cute, I like it. But probably rustles someone's
jimmies, how they rely on MAC not changing.

> I believe, that it is superior to both IPv4 and IPv6, simpler than
> both, and intended as a replacement for both. Substantial improvement
> on both.

Even if it would be superior, unfortunately deployability is not
function of protocols 'goodness'. But great
work and some really nice ideas.

I'd be more conservative and just axe bunch of useless crap from IPv6,
add some point-to-point (i.e host-switch) routing-protocol as
mandatory (a'la ES-IS) instead of ARP, mandate that implementation
includes new PKI based L4 protocol (something along lines of MinimaLT
and QUIC) and mandate that addresses are published in DNS in something
like SVCINFO (think SRV, but correctly:)

Anyhow great work, fun to read.
-- 
  ++ytti




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