6bone Routing Registry

[David Lee]

> Hmm, we're starting to get to the point where it's not more attributes we
> need but more objects.  I can see a good justification for an inetnum6
> object (which would probably be almost directly copied from the inetnum
> object), an ipv6-site object (which is basically the current site object
> in ip6rr), an ipv6-host or ipv6-rtr object which can give details of
> mappings between ipv6 and ipv4 on a single interface _and_ and ipv6-subnet
> (equivalent to my native proposal).  There's far too much useful info to
> realistically fit onto a single attribute line.
> 
> Somebody tell me if you all think I'm running ahead of myself!

To some extent, these items could be and/or are handled by DNS... no
need to build a new system.  The question, IMHO, is what useful information
should be contained in the ip6rr for initial testing, deployment, and 
marketing phase (e.g., now).  For the future, Bill (Manning's) comment
on rolling this into DNS makes sense...

> Sure, it's likely that most will be ipv4/ipv6 capable, but we need to take
> into account the possibility of single protocol networks reachable only
> via tunnels.  I'd far rather think about the most flexible way to record
> these details now than in a years time when people are used to the other
> system. 

Again, I guess we're differing on how long we expect this to be used.  To
some extend, the long-range approach may be better (since there are people
in this world who still use DOS V1.0 ... :)  However, when we go to real
IPv6 addresses, I would suspect that the routing databases will be redone
with what we know to be true at that point.  Or, if it doesn't work, we'll
change it in the future ;)

-- 
David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu
PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall
Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111