6bone Routing Registry

[Guy Davies]

On Wed, 19 Mar 1997, David Lee wrote:

[snip]

> The question is that in order to diagnose problems, is the IPv6 address
> sufficient (at this stage in the game)?  On another note, I would guess
> that most routed subnets would also have also have a tunnel connection.
> Mapping the native object to the tunnel object/end-point would be easier if
> we used the IPv4 address.  

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!

> My line of thought was to map the IPv6 network ontop of the IPv4 network.
> Thus, the IPv4 source/destination network ID's (I was originally trying
> to figure out how to specify the subnet without supplying a subnet mask...
> perhaps something like 128.173.88.118/58 would be better).  True, an IPv6 
> routed subnet doesn't (shouldn't? :) imply a one-to-one mapping to an 
> IPv4 network, but 1) I find that easier to keep track of if we look at 
> things in terms of the IPv4 network and 2) I would also expect that all 
> networks (for the forseeable future) would be dual IPv4/IPv6 networks.  

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. 

> One could modify the ping line to provide a mapping between IPv4 and IPv6
> addresses --
> 
> ping:  128.173.88.118  5f05:2000:80ad:5800::1

This could form part of an ipv6-host object.  Obviously, these are
host/interface addresses which have no direct association with a
particular net.

> If the machine only has a IPv6 address, then that's the only thing that
> shows up.  And add the requirement that all router nodes on the record must 
> have a ping entry (of the above format), that would solve both problems.  Given
> that, it would seem that we have a workable solution.
> 
> > [sn-name] 	is the subnet name formed as described below by David
> > [net-type] 	is the underlying network type (eth|ppp|tr|atm|....)
> 
> Good idea -- this would be useful to know.

Heh! We agree on something ;-)

[snip]

> > > I was also thinking of including the routed subnet's IPv6 prefix but I think
> > > that's unnecessary information.  The going assumption is that the routed
> > > subnet's prefix is some portion of the destination site's prefix.  
> > 
> > This is most likely true but (in the case of an organisation with multiple
> > ASes) is not guaranteed.  There is, as stated above, some useful info in
> > the prefix.
> 
> One could envision that multiple ASes mean that they would have multiple
> ip6rr entries.  In which the site name rule still would work.  

Hmm, possibly but I know that several ISPs (particularly in the US) have
_lots_ of ASes.  Would they want to represent themselves as a single
entity or lots of different ones?

> On another 
> thought, I would assume that each on-link prefix then receives its 
> own entry.

Well, either that or prefix becomes mandatory/multiple.

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