Re: (multi6) requirements draft comments

["Jim Fleming" <jfleming@anet.com>]

Since 2002 is almost here, you might want to consider running IPv4 in 2002 Mode.

2002:<IPv4>:0000....

This may help...
http://www.dot-biz.com/IPv4/Tutorial/
http://www.RepliGate.net

The Netfilter Project: Packet Mangling for Linux 2.4
http://netfilter.samba.org

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!


----- Original Message ----- 
From: "Sean Doran" <smd@ebone.net>
To: <alh-ietf@tndh.net>; <brian@hursley.ibm.com>; <randy@psg.com>; <smd@ebone.net>
Cc: <multi6@ops.ietf.org>
Sent: Tuesday, December 18, 2001 1:40 PM
Subject: RE: (multi6) requirements draft comments


> | 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.
> 
>