6bone Registry

davidk@ISI.EDU davidk@ISI.EDU
Mon, 23 Sep 1996 14:15:53 -0700 (PDT)


Hi Andrew,

> Andrew J. Hoag writes :
> 
> That was my initial reasoning for the "src" keyword or at least listing the
> source IP first. Then you could switch them around:
> 
> site:	NAS
> tunnel: IPv6 in IPv6 dst 192.xxx.xxx.xxx Cisco src 129.99.236.71 NAS
> 
> without worrying about it. But since this will go eventually into a database, I
> would argue for requiring the "local" endpoint first.

Yes, but the dst/src keyword addition has one advantage:

The software can never find out which IP address is at which point of the
tunnel and thus is syntax checking less reliable. Also, the software can
automatically rearrange the order to have the src IP address listed first
in the attribute line.

The only possible check without the src/dst keywords is the check if the
tunnel in the other object (if already existing) is defined in opposite
order. My personal opinion is that this check is enough.

> > And one step further:
> >
> > tunnel: IPv6 in IPv4 129.99.236.71 <-> 192.xxx.xxx.xxx
> >
> > The IP addresses already determines where the tunnel is going to. The
> > database software is capable enough of finding the site names that have
> > tunnels with a certain IP address on run time. This also avoids data
> > duplication problems which is usually not a bad idea in database design ...
> 
> Yes, you are right again. I was looking at this from the human-readable form
> (e.g. source files) but that does not have to be the ending user interface.
> 
> > tunnel: IPv6 in IPv4 129.99.236.71 NAS <-> 192.xxx.xxx.xxx Cisco
> 
> I like the database parsing the tunnel endpoints, but what would this require
> from the data-side? Would the database be able to grok Cisco's entry and search
> for NAS's IP address on the right (remote) side and then backfill the record
> accordingly?

Yes, with one exception:

If the other object (Cisco) is not updated yet with the new tunnel.
However, this might be a good feature, a tunnel is regarded as
working when both ends have updated their objects.

Other question is:

Do you want to use IP addresses of both end points and/or is the DNS host
name instead of an IP address more flexible ?!?

Allowing the <IP/DNS> possibility makes the backfill more difficult and
error-prone but is certainly not impossible (<IP> or <DNS> only is
easiest).

David K.
---