6bone Routing Registry

[Guy Davies]

On Tue, 25 Mar 1997, David Lee wrote:

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

Hi David,

OK, to simplify all my ideas, the information I'd like to see (whatever
the source) is...

IPv6 Site (we know the details available here)
IPv6 native net
	- IPv6 prefix in use on this net
	- IPv6 router via which the net can be reached
	- Codified subnet name
	- Network type (eth|atm|tr|fr|ppp|....)
	- Routing Protocols running on this subnet (ripng|static|idrpv6|....)
	- Operational Status (operational|experimental)
	- Peer relationships on this net (see David's previous emails)
IPv6 router
	- Router name
	- Each IPv6 interface (shows which nets are connected by this rtr)
	- Each IPv4 interface (shows how IPv6 overlays IPv4)

This kind of detail would allow me to decide which route I would expect to
take and which routers I would expect to traverse in order to reach
another site.  If my traceroute failed, I would be able to see where
either unexpected routing was happening or the packets stopped.

That's what I need to know when doing problem solving on a network at the
level we'll be able to do ourselves before contacting the site in question
for assistance.

I don't intend that this information should be used as a means by which to
apportion blame when things break, more that it would allow me to more
accurately direct my requests for help when I need it rather than using
the current scattergun approach ;-)  Clearly, the provision of this info,
like the involvement in 6bone itself, is optional.  Some of the details
can be discovered from the dns and the current ip6rr but there are
certainly details which cannot easily be obtained from either.

> > 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 ;)

Agreed, and this would be the realm of the various working groups at RIPE
and the other Regional IP Registries to decide.

Regards,

Guy

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