Subject: (ngtrans) 2002, 2003, 2911...YMDD....etc.

From: "Jim Fleming" <[email-masked]>
Date: Mon, 2 Sep 2002 18:29:08 -0500

> 2002 is a really good value...next year, 2003 may be better...
> 
> There is also the 2911 and 3911  approach...YMDD....
> 
> Setting the MTU via the 128-bit DNS may catch on if the bits are not all used...
> ...in theory, one could take the 128 bits and blindly drop them into the 160-bit IPv4 header...
> ...it is handy to have 16 of the bits to set the UDP|TCP Port # which is not in that header...
> ...that only leaves 112 bits left...maybe the popular MTU sizes could be selected from a table of values...
> 

For Next Generation (NG) transitions...the notion of versions or "generations" in software can
come into play....the left-most 16-bits of the 128-bit DNS are a useful place to express this
information....with IPv4 and IPv4++ only 4-bits are encoded in the header with the fixed value
of 0100 (4)...that can not easily be changed because all of the routers and servers check for that
and set that to 4...also, having a 16-bit version field would likely be over-kill for packet headers
but it is useful to have some space in the NG transition 128-bit DNS for version and/or time-stamp
information....this can be used to select the right software version to use, especially in object-oriented
systems where there may be several versions of an object class still active in the system at one time...

Given that...the YMDD encoding style shows that this is really a 16 year rotating version field...
some may view that as a sliding window of versions....and the assumption could be made that
software developers will have put a version behind them that is 15 years or more old...with that
it does not both people to roll the Y field over every 16 years...in other words, in the year 20016
the Y field would once again become 0 with 2017 becoming 1, etc.....the M field can of course
range from 1 to C with December being C and the other values can be used to trigger other tricks
that do not need the version/date form of the 128-bit DNS value....

With the 2002: value followed by 2003...there would be 99 years before 2100 comes into play
and then 9 more years before 2110 starts to collide with the YMDD encoding...that provides
over another century of "versions" and/or "transitions"...with many values not used in the gaps...
...since the persistent bits are in the right-side of the 128-bit DNS field (not the left) an ISP does
not have to worry about renumbering for a long long time....with the 32-bit Dynamice Address
field, there is a lot of time to allow things to change...DNS allows for what is called late-binding
in other words, rather than make rigid decisions now....the DNS allows for those decisions to be
deferred or a place planned for them when the time arrives...

Time is an important dimension because some people would like to have packets marked in
archives with some date value to place them in context for 4-dimensional webs for example where
one can look at the state of a web or network at a point in time...with respect to 128-bit DNS
some people also would like to have not only the expire time but also a date to start using the
data or stop using the data, depending on what is arranged with the application...given that, one
could say an address like 2002:[IPv4]:* actually says during the year 2002 (NOW) use the following
32-bit legacy Internet site-id for encapsulating all IPv4++ packets in vanilla IPv4 packets with
that address to allow for a smooth transition...in 2003 a different site-id can be used...one could
also use the 2002 as the transition technique "version"...and each year there can be a new version
(to sell)...2003 may define more of the bits...with the right-most bits remaining constant with the
persistent address to avoid re-numbering...with the 2002:[IPv4] format only 32 of the bits in the
IPv4 field are considered useful....as the IPv4 legacy core transitions to an IPv4++ core using
the 11 additional bits that can be used without changing any of the routers then one has a 43 bit
core (non-QoS) transport and therefore, 2003:[IPv4++] could really cover 16+43 bits to use
the entire IPv4++ core transport address space as a site prefix...which is a total of 59 bits of the
64 bits on the left-side of the 128-bit DNS field...that leaves 6 bits (0-63) to encode preferred MTU
or other values...if there were 16 popular MTUs that would take 4 bits and that leaves 2 bits (0-3)
for other values...4 popular TTL (Hop Count) values could be selected...thus, next year 2003
the 43-bit core transport could be used with a 43-bit growth layer plus the 4 QoS bits and of
course the 16-bits for Port values which is the real win in the 128-bit DNS...

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.org
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt