6bone Routing Registry

[Guy Davies]

On Tue, 18 Mar 1997, David Lee wrote:

> Additionally, I'm expecting to get some native IPv6 routed subnets up for 
> testing and there appears to be no way to designate this in the current RIPE 
> registry format.  First off, there is some question of whether or not to even 
> designate this.  Assuming that we want to designate it, which I would think 
> that we would, then, I would think that the format needs to be the same as the 
> tunnel designation.  Thus, I would proposed the following.
> 
> native:   [iif addr] [oif addr] [other site] [rp type] [status] {type}
> 
> where:
> 
> iif ipv4 - Address of the routed subnet for the router's input interface address
> oif ipv4 - Address of the routed subnet for the outgoing interface
>     site - Outgoing interface site name
>  rp type - Routing protocol type.  RIPng, static, etc.
>   status - One of the following:
>            oper/u "operational" status and link up
>            oper/d "operational" status (or was ;) and link down
>            expr/u "experimental" status and link up
>            expr/d "experimental" status and link down
>     type - Optional field of the format XY, where X is one of:
>            u - feed to a upstream site
>            d - feed to a downstream site (which may or may not be a leaf)
>            t - feed to a "lateral" transit site (e.g., other backbone)
>            l - feed to a downstream leaf site
>
>            And Y is a number from 1 to 9, where 1 designates a primary
>            feed, 2 designates a secondary feed, and so forth. 
> 
> An example of a machine with two interfaces would be:
> 
> native:	128.173.88.118 128.173.89.100 VT-EE-NETLAB RIPng expr/u l1

Hi David,

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

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.
[sn-name] 	is the subnet name formed as described below by David
[net-type] 	is the underlying network type (eth|ppp|tr|atm|....)
[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)

This would give a better idea of the propagation of native IPv6 subnets
and far more info about the subnet (possible number of connected hosts,
use of particular network types, routing protocol used, etc)

This, IMHO, maps more closely onto the tunnel attribute already defined in
the ip6rr object and represents the subnet.

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

> I would 
> also advocate that internal sites/nodes be listing according to the format 
> 
> 	[registry entry]-[internal name]

Definitely.  This is a very good idea and kind of maps onto the concept of
OSPFs areas around area0.

> I would note that if we start to match the production IPv4 network, then
> we'll have many of these native entries.  When (and not if ;) we get to that 
> point, I would propose that we only list the border router(s) for the native 
> routed site.  One of the justifications for having native routed nodes listed 
> now is for people to see how many of these we actually have.  This gives us an
> idea of penetration and can also be used on a marketing side.  When we
> have a significant amount of sites that are native routed, the technical
> information need is reduced and we also have a much different and stronger 
> selling point on IPv6 rollout.
> 
> The only thing that differs from standard practice is the feed type.  
> I believe that the feed type information will help people get a better 
> understanding of how a site is connected.
> 
> I would, naturally, advocate that the tunnel registry information 
> (http://www-cnr.lbl.gov/6bone/6bone-register.html) be changed to 
> 1) reflect standard convention and 2) include the proposed feed type
> information.  Thus, the format should be:
> 
> tunnel:   [source addr] [dest iaddr] [site] [rp type] [status] {type}



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