RE: (multi6) requirements draft comments

[smd@ebone.net (Sean Doran)]

| Deploying the router and host mechansims which would implement topology
| based renumbering is hard enough, but replacing all the applications
| with ones that ignore those changes is a fantasy which would have to
| happen before the infrastructure based renumbering could even begin.

8+8-type proposals rely upon the host and/or router to deliberately
hide the upper octets ("routing goop") from the applications,
which see all-zeros or the like.

Some people (I am wary of identifying them without permission) had
begun to enumerate the various places one would have to change
host implementations, such as in in-stack checksumming code, 
but I have not heard of this being finished.

| Fold in the fact that even if you got those to things done, the topology
| shift renumbering would create a DNS update spike that would take out
| all name services, and one wonders why the approach is still getting any
| attention.

The hosts could remember <magic-cookie>/<8-or-10-or-whatever-bytes-of-identity>
in their DNS caches; there are techniques learned from NAT that make
handling this quite simple.

For instance, if you couple an IPv4 NAT or a routing-goop-rewriter
with what appears to be a caching DNS server, you can have a different
view of the "outside"'s DNS from that known on the "inside".

This is not "classical 8+8", which indeed would require hosts
to learn that routing-goop-value-x has just become routing-goop-value-y,
in order to continue talking with the parties who changed RG values,
or in waiting for them to learn that themselves from the DNS,
or from a mechanism along the lines discussed in the review
of Ohta-san's draft.

There are connectivity-debugging implications associated
with all of these approaches, however, as many people have
pointed out.   The question is, how should such implications
be addressed (pardon the pun) in the requirements draft?

	Sean.