6bone Routing Registry

[David Lee]

> Err, Looking at your proposal, I don't understand how this gives any
> information about a native IPv6 subnet.  It seems to be more appropriate
> for a host/router rather than a subnet.  This may be a useful attribute in
> it's own right but I'm not sure it does what you said you wanted.  Surely,
> something along the following lines would prove more useful... 

Right now I almost pretty much don't care as long as there's something 
workable.  I got this damned qualifing exam looming overhead... :)
 
> native: [prefix] [rtr-id] [sn-name] [net-type] [rp-type] [status] {type}
> 
> ...where...
> 
> [prefix]	is the routed IPv6 subnet (which may be covered in the 
> 		global routing tables by a larger announcement)
> [rtr-id]	is the id (ipv6|ipv4|hostname?) of the inbound i/f of 
> 		the router via which this subnet can be reached.  I think
> 		given that this is native IPv6, my choice would be the
> 		IPv6 address of the i/f.

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.  

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.  

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

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.

> [rp-type]	is the routing protocol (ripng|idrpv6|static|....)
> [status] 	is the link status as described by David
> {type} 		is the link type as described by David.  On multicast 
> 		type media, this may need to be extensible to cover 
> 		several 'peering' types (e.g. you may run IPv6 across
> 		an ethernet on which you have peerings to transit
> 		sites, leaf nodes, to upstream nodes and to downstream
> 		nodes - I'm thinking of something like a NAP here)
>
> > 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.  On another 
thought, I would assume that each on-link prefix then receives its 
own entry.  

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