This is a discussion on Re: IP protocol version 4.5 - TCP-IP ; On 2008-08-23 12:49:58 -0400, Look@dawnon.com said: > IP protocol version 4.5 > > This is not an official release of Internet Protocol specification. > But it is some cultural proposition. Thank you for having the courage to toss in your ...
On 2008-08-23 12:49:58 -0400, Look@dawnon.com said:
> IP protocol version 4.5
> This is not an official release of Internet Protocol specification.
> But it is some cultural proposition.
Thank you for having the courage to toss in your ideas into the ring. I
think technologists & folks that aren't so directly involved with the
technology behind IPv4 networking can agree that the IPv4 protocol and
the technologies bundled it have become an integral and important part
of human life. We can't rip it out now - we can come up with spot
examples of how we could do without, but those are impractical on a
world economy that depends on IPv4 continually working, so having
cultural input and non-technological input might be foreign to us
techies, but it's a good step to have people from "outside" the regular
engineering concerns to have a look in - I have a practical example of
this that taught me long ago to seek and include this type of input,
especially in interface engineering. An art student who had a bit of a
mathematics background gave us techies a lesson in how painters use
perspective to draw your attention to certain details in their art. We
included this in interface design for real-time packet flows and
watched, with bemused amazement, how people looked where we wanted them
to and could fine-tune that for themselves.
Anyway, back to IPv4, and "IPv4.5".
My only two cents here is that we need to look at history for a
reasonable approximation of success, here's some examples:
- Nature branches off many evolutionary trees, like experiments. What's
needed and successful survives, not what's "technically correct". As
engineers / scientists, we should be striving to combine what's needed
with what's technically correct to the extent possible - we all have
"no go" points where we understand making fundamental change would
cause too many issues. However, using forward progress as a "re-write"
tool rarely, if ever, works.
- Look at things that "stuck" - SSH stuck, and its adoption rate was
pretty quick eliminating TELNET out there as the default login utility.
There were years of groaning, but a combination of what was needed
(secure access, less hacking) with what was technically correct
(encrypted logins), succeeded. The *BSD folks I think were the first in
pushing the edge by removing TELNET from default distributions, etc.
- SPF, DKIM and other anti-spam attempts haven't been so successful so
far. They are partially what's needed, and the argument over whether
they are technically correct rages on. Many people want an SMTP /
e-mail "re-write". Unless there's some stellar new feature that can be
offered over e-mail everyone wants creating the need for everyone to
re-write RFC821, not going to happen. DKIM using DNS, might be an
answer since it doesn't require a re-write, and with SPF, you know
e-mail should come from (x) address and can be signed with (y) key. I'm
not adovcating anything, just showing an example of how things don't
work out sometimes.
I'm not convinced we need IPv6 today, I'm just not. I know we'll need
more IP addresses eventually, I like some new features of, but it's
been around for almost 10 years now too without huge traction, maybe
something will push it over, maybe the Japanese fervor for it at the
ISP level will spill over. Maybe the US is the last bastion of IPv4,
refusing to change, and for good business reason. Regardless, it's
nature's step - evolutionary - we'll see if the new DNA people are
We need to be good stewards, like Jon Postel was. I think us old-school
techies are good at choosing things that are technically correct, but I
think we all could pay attention a bit more to what's needed, seeing
the reward for that as potential faster adoption of "fixes" or
"fundamentals" we keep groaning about over beer.
_ __ _
__| |_ __ / _| |_ 01100100 01101101
/ _` | ' \| _| ' \ 01100110 01101000
\__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx