[6bone] Meeting agenda in Atlanta

[Jeroen Massar]

Robert J. Rockell wrote:

<SNIP>
> -Michel presents thoughts on state of 6bone (10 minutes)

See below :)

> referenced drafts for your pre-reading:
> 
> 6bone-Mess:
>
http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt

> 2772 re-write:
> http://www.6bone.net/misc/draft-ietf-rockell-6bone-ops-guide-00.txt
> 
> Note: 2772 re-write may be Ipv4 accessible only (not my server,
complaints
> to admin of www.6bone.net :) ).

With respect to the 'state' of the 6bone, this would really mean it is
quite unstable.
Fortunatly a fetch on IPv4 only fixes it but that is quite bad don't you
think ? :)

Just a quick 'fix':
by IP (fortunatly it's either the default vhost or there are no others)
http://131.243.129.43/misc/draft-ietf-rockell-6bone-ops-guide-00.txt

Working over IPv4 + IPv6 and it is the same box:
http://www.ipng.nl/~jeroen/draft-ietf-rockell-6bone-ops-guide-00.txt

Some relevant comments:
 - There is mention of the multi6 group, but not to the ipv6mh group.
   They will be conducting experiments soon too (Michel Py has more
info)
   Ofcourse they are not a 'official' ietf working group.

 - 7.1.c:
   "Fully maintained DNS forward (AAAA) and reverse (ip6.int and
ip6.arpa)
    entries for all of the Applicant's router(s)."

   I've added ip6.arpa there to push the RIR's to delegate it, we might
   let all pTLA's create working ip6.arpa reverses already so that when
   the reverse gets delegated it all starts working in one go without
   further ado. I've added "all ... routers" just to make it more clear.
   I've also removed the "at least one host" part as that's something
   most people will do by them selves and doesn't really make it more
   visible or stable to whom the addresses belong.

   Notez bien that one can easily setup a wildcard reverse catch so that
   a complete block is handled in one go eg:
   *.0.c.e.f.ip6.arpa. PTR unassigned.example.net.
   Though one has to wonder where the use is for such a catch'em-all.

 - 7.1.d:
   "A fully maintained, and reliable, IPv6-accessible system providing,
    at a mimimum, one or more web pages, describing the Applicant's IPv6
    services. This server must be IPv6 pingable. This pingable host
should
    be entered into the whois object for this site under all the
relevant
    'application' lines. This website must also list correct and working
    contact addresses for technical problems. These must match the
records
    in the whois database. The site should have a looking glass
available
    allowing checkups of reachability and ghost route control."

   The last sentence will hopefully force people to enter those records
into
   the database thus allowing the many automatic ping scripts to work
much
   better, currently about 90% of those "application: ping <host>" lines
are
   non-working (dns fallout, non-existing hosts, you name it).

   The lookingglass part is actually quite important as it gives many
operators
   an insight into the routing tables and their issues at a remote site.
   And this might at least give a view onto the problem where numberous
   ghostroutes have been seen but couldn't be tracked down because the
site's
   operators where not available. LG's are 24x7, people are not.

One will probably want to split up the additions if one takes them into
account :)

Greets,
 Jeroen