RIPE object proposal

[Andrew J. Hoag]

> On Nov 22,  3:05pm, davidk@ISI.EDU wrote:
> > Andrew J. Hoag writes :
...
> > It also would be helpful to require some sort of "Location:" string
describing
> > the above lat-long... Since many people don't know their lat-long, they
could
> > alternatively provide the location.
>
> This is a good one. I would say that we could also add the (optional)
> 'country:' attribute (will not help much in the US/Russia though ...).

I can understand trying to limit free text attributes. I think as much
"standardization" that we can achieve as possible would be helpful. Somebody
feel free to chime in here, but what about specifying the Internet country-code
for the location, as well as a one-line string describing the specific
population center. (i.e. city, township, ...etc.) Sounds like it might be
helpful for most countries if there is a State / Province code somewhere
involved as well.

> > Is it assumed that this is for IPv6 applications? Would a version/protocol
> > field here be useful?
>
> Yes. I didn't add it since the whole object is IPv6 specific but if you
> think that it is useful ...

That's probably a good place to save information. I was looking at a more
generic use rather than an IPv6 specific one.

> > We discussed this earlier and you pointed out that the database can look up
the
> > IP address, however with some of these tunnels moving around, the IP
addresses
> > for all records don't get change when the tunnel endpoint changes, so we
have
> > some records pointed to the old and some to the new. Would you be able to
> > automatically move all references to the old IP to the new?
>
> This would be difficult since it would mean touching other people's
> objects.
>
> My idea was to do this referencing dynamically at lookup time. However,
> it might be better to start with user supplied site information in the
> object since this part of the implementation is a kind of trikey and
> would delay deployment.
>
> > >   Note for discussion:
> > >
> > >   It is may be better to use DNS domain names here instead of the raw IP
> > >   addresses.
> >
> > If DNS is broken it may be hard to resolve hostname to addresses... I'd
rather
> > just do the reverse lookup (at my own risk) if I need the hostname. OTOH,
we do
> > use DNS for a reason and using host names may cure some of the problems I
> > mention in the paragraph above. My vote would be for hostnames with the
caveat
> > that everyone would have to have DNS configured to tunnel (for the IPv4
> > endpoints at least).
>
> Agreed.

So should hostnames be the norm? That should clear up our problem with moving
tunnels noted above.


I cross-referenced Alain's comments re: "evolution of the 6-bone"
(http://www.ipv6.nas.nasa.gov/6bone/0506.html) and it looks like most of the
issues are taken care of. Alain discusses the desire to have the prefix
information (prefix: field) and the IPv6 address of the tunnelling router,
which could be a AAAA lookup on the hostname above.


-- 
| Andrew Hoag      | MS 258-6                | Voice: (415) 604-4972 |
| Network Engineer | Moffett Field, CA 94035 |   Fax: (415) 604-4377 |
| High-Speed LAN   +------------------------+---+--------------------+
| NAS Facility     | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov |
--