The end of the beginning is in sight

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> We should start a list of the things that need fixing/changing [in IPv5].
> 
> Maybe a file in devel/ ?

Reasonable.

> There is one quirk that comes up occasionally.  The RefID only has room for 
> an IPv4 address.  IPv6 addresses need hashing.  That's not a serious problem 
> and you may want to hide it anyway for security reasons.

According to NTF, refid hash collisions have been observed in the wild.

I think the solution for this is obvious.  We define an extension
type the contents of which, if it exists, SHOULD be used as the refid.
Implementations that don't know about that extension will be no worse
off than before.

> I think all the security proposals will fit into extensions.  But there have 
> been a lot of troubles with extensions in the past.  I wouldn't be all that 
> surprised if we needed a change that required a new version.

Can you be more specific about the past troubles?

Somebody mentioned on the Signal channel that some routers truncate NTP
packets to their 48-byte headers in order to avoid DoS attacks.  If that's
a widespread practice, it pretty much blocks the easy path forward -
we'll need a new protocol number and a new protocol.

Fortunately, that is *right* in my wheelhouse.  I've done
wire-protocol designs myself before and I've studied a lot of others.
I know how to fit a wire-protocol design to different relative values for
extensibility, interpretation speed, bit density, and
eyeball-friendliness.

I'm already sketching a couple of possibilities for NTPv5 in my
head. Both are based on the PNG model of self-describing chunks (which
I've heard it iherited from TIFF). One uses binary chunks, like PNG
itself. The other uses textual chunks.  I could detail-spec either in
a couple days' work.

This is not even a *hard* problem if you know the protocol-design
space - NTP's ontology is not complicated enough to make it
difficult. Said ontology is simpler than GPSD's, for sure (which is
one reason I'm not instantly reaching for JSON as a metaprotocol).

Though I find the thought alluring, I think the best path forward will
be a more conservative one. We do what is in effect v4.5 heavily using
the extensions mechanism. If that flies in reality, well and good.  If it
doesn't, we set me loose on a real v5 design - and I will deliver, oh
yes I will.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>