Message-ID: <20031117113929.E2597@iprg.nokia.com>
Lars, Bob, Hank,
The problem with the registry should have been fixed.
On Mon, Nov 17, 2003 at 04:24:35PM +0100, Lars Albertsson wrote:
>
> We are operating an automated IPv6 tunnel broker service, and use the
> daily 6bone RIPE registry dump at
> ftp://whois.6bone.net/6bone/6bone.db.gz to retrieve tunnel
> configuration information for our delegated address spaces. Since a
> few days, however, the daily full dump is an empty file, and some of
> our tunnels therefore went down. One can have opinions on the decision
> to rely on the database dump for our tunnels, but it has worked well
> so far.
One little comment: this should be a fine strategy but a quick sanity
check before you accept the new dump is probably a good idea :-). It's
not only the registry that could fail, you could for example also end
up in a sitation where the ftp download doesn't complete sucessfully.
I recommend a sanity check that does the following: check whether the
file starts with a proper header, whether it ends with '# EOF' and
whether the size of the 'diff' between the current file and the old
file is acceptable (to you).
I want to apologize for the time it took to fix the problem. We do
have an escalation procedure but it clearly didn't work fast enough.
I'll see what I can do about that.
David K.
---
From dan@reeder.name Sun Nov 23 13:10:58 2003
From: dan@reeder.name (Dan Reeder)
Date: Sun, 23 Nov 2003 23:10:58 +1000
Subject: [6bone] quagga bgpd importing and advertising debian routes on the fly
Message-ID: <001701c3b1c3$3d1289b0$0200a8c0@dryad>
This is a multi-part message in MIME format.
------=_NextPart_000_0014_01C3B217.0E321120
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi guys
Here's the plan: we're in the middle of setting up a tunnel server on a =
debian box that is also running Quagga's bgp daemon that will hopefully =
be able to automatically advertise the newly made tunnel =
interfaces/networks on to its bgp peers.=20
The problem is just how to go about doing this? The process will involve =
the http server (using perl or php) to get the new prefix, create it in =
debian [this works fine so far], then tell bgpd to include it in its =
statements.=20
We'd normally just have a supernet that covers all the tunnels that =
would be created on the box and just advertise that to the peers, but =
the requirement to use just one pool of prefixes across two tunnel pops =
doing the above functions.=20
The simple answer is to just get php to edit the bgpd.conf and restart =
bgpd every time a new tunnel interface is made - but that'd wreak havoc =
with the routing table for the rest of the users.=20
Firstly is there a way to manually get the bgpd include and advertise =
new routes on the fly without interrupting other routes, and secondly =
can this be done automatically by php/perl/some other httpd-based =
function.
thanks
Dan Reeder
------=_NextPart_000_0014_01C3B217.0E321120
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi guys
Here's the plan: we're in the middle of =
setting up=20
a tunnel server on a debian box that is also running Quagga's bgp daemon =
that=20
will hopefully be able to automatically advertise the newly made tunnel=20
interfaces/networks on to its bgp peers.
The problem is just how to go about =
doing this? The=20
process will involve the http server (using perl or php) to get the new =
prefix,=20
create it in debian [this works fine so far], then tell bgpd to include =
it in=20
its statements.
We'd normally just have a supernet that =
covers all=20
the tunnels that would be created on the box and just advertise that to =
the=20
peers, but the requirement to use just one pool of prefixes =
across two=20
tunnel pops doing the above functions.
The simple answer is to just get php to =
edit the=20
bgpd.conf and restart bgpd every time a new tunnel interface is =
made - but=20
that'd wreak havoc with the routing table for the rest of the users.=20
Firstly is there a way to manually get =
the bgpd=20
include and advertise new routes on the fly without interrupting other =
routes,=20
and secondly can this be done automatically by php/perl/some other =
httpd-based=20
function.
thanks
Dan Reeder
------=_NextPart_000_0014_01C3B217.0E321120--
From haesu@towardex.com Sun Nov 23 17:51:44 2003
From: haesu@towardex.com (Haesu)
Date: Sun, 23 Nov 2003 12:51:44 -0500
Subject: [6bone] quagga bgpd importing and advertising debian routes on the fly
In-Reply-To: <001701c3b1c3$3d1289b0$0200a8c0@dryad>
References: <001701c3b1c3$3d1289b0$0200a8c0@dryad>
Message-ID: <20031123175144.GA44360@scylla.towardex.com>
Write a script that telnets into bgpd or vtysh and enter commands?
I don't suppose this is any different than writing a script that telnets into cisco routers.
-hc
--
Haesu C.
TowardEX Technologies, Inc.
Consulting, colocation, web hosting, network design and implementation
http://www.towardex.com | haesu@towardex.com
Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170
Fax: (978)263-0033 | POC: HAESU-ARIN
On Sun, Nov 23, 2003 at 11:10:58PM +1000, Dan Reeder wrote:
> Hi guys
> Here's the plan: we're in the middle of setting up a tunnel server on a debian box that is also running Quagga's bgp daemon that will hopefully be able to automatically advertise the newly made tunnel interfaces/networks on to its bgp peers.
>
> The problem is just how to go about doing this? The process will involve the http server (using perl or php) to get the new prefix, create it in debian [this works fine so far], then tell bgpd to include it in its statements.
>
> We'd normally just have a supernet that covers all the tunnels that would be created on the box and just advertise that to the peers, but the requirement to use just one pool of prefixes across two tunnel pops doing the above functions.
>
> The simple answer is to just get php to edit the bgpd.conf and restart bgpd every time a new tunnel interface is made - but that'd wreak havoc with the routing table for the rest of the users.
>
> Firstly is there a way to manually get the bgpd include and advertise new routes on the fly without interrupting other routes, and secondly can this be done automatically by php/perl/some other httpd-based function.
>
>
> thanks
> Dan Reeder
From tvo@EnterZone.Net Sun Nov 23 18:29:16 2003
From: tvo@EnterZone.Net (John Fraizer)
Date: Sun, 23 Nov 2003 13:29:16 -0500 (EST)
Subject: [6bone] quagga bgpd importing and advertising debian routes on
the fly
In-Reply-To: <20031123175144.GA44360@scylla.towardex.com>
Message-ID:
Um, there are a number of ways to achieve your goal but I wonder why you
want these long prefixes in BGP at all? Run an *IGP* in your network and
carry "connected" routes into IGP. BGP == *BORDER* Gateway Protocol.
---
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |
On Sun, 23 Nov 2003, Haesu wrote:
> Write a script that telnets into bgpd or vtysh and enter commands?
> I don't suppose this is any different than writing a script that telnets into cisco routers.
>
> -hc
>
> --
> Haesu C.
> TowardEX Technologies, Inc.
> Consulting, colocation, web hosting, network design and implementation
> http://www.towardex.com | haesu@towardex.com
> Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170
> Fax: (978)263-0033 | POC: HAESU-ARIN
>
> On Sun, Nov 23, 2003 at 11:10:58PM +1000, Dan Reeder wrote:
> > Hi guys
> > Here's the plan: we're in the middle of setting up a tunnel server on a debian box that is also running Quagga's bgp daemon that will hopefully be able to automatically advertise the newly made tunnel interfaces/networks on to its bgp peers.
> >
> > The problem is just how to go about doing this? The process will involve the http server (using perl or php) to get the new prefix, create it in debian [this works fine so far], then tell bgpd to include it in its statements.
> >
> > We'd normally just have a supernet that covers all the tunnels that would be created on the box and just advertise that to the peers, but the requirement to use just one pool of prefixes across two tunnel pops doing the above functions.
> >
> > The simple answer is to just get php to edit the bgpd.conf and restart bgpd every time a new tunnel interface is made - but that'd wreak havoc with the routing table for the rest of the users.
> >
> > Firstly is there a way to manually get the bgpd include and advertise new routes on the fly without interrupting other routes, and secondly can this be done automatically by php/perl/some other httpd-based function.
> >
> >
> > thanks
> > Dan Reeder
> _______________________________________________
> 6bone mailing list
> 6bone@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/6bone
>
From jesper@skriver.dk Sun Nov 23 18:53:02 2003
From: jesper@skriver.dk (Jesper Skriver)
Date: Sun, 23 Nov 2003 19:53:02 +0100
Subject: [6bone] quagga bgpd importing and advertising debian routes on the fly
In-Reply-To:
References: <20031123175144.GA44360@scylla.towardex.com>
Message-ID: <20031123185302.GB49414@skriver.dk>
On Sun, Nov 23, 2003 at 01:29:16PM -0500, John Fraizer wrote:
>
> Um, there are a number of ways to achieve your goal but I wonder why you
> want these long prefixes in BGP at all? Run an *IGP* in your network and
> carry "connected" routes into IGP. BGP == *BORDER* Gateway Protocol.
It's never a good idea to carry "customer" routes in your IGP, you want
your IGP to be stable, so in a sound design it's only used to carry
loopback addresses, which are used for BGP next-hop, and everything else
is carried in (internal) BGP. If it's a more specific route that should
not be advertised outside the AS, then mark it with no-export.
/Jesper
From bob@thefinks.com Mon Nov 24 21:46:35 2003
From: bob@thefinks.com (Bob Fink)
Date: Mon, 24 Nov 2003 13:46:35 -0800
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
Message-ID: <5.2.0.9.0.20031124134150.02a27d70@mail.addr.com>
T-NET has been allocated pTLA 3FFE:401C::/32 having finished its review period.
Note that it will take a short while for their pTLA inet6num entry to
appear in the 6bone registry as they have to create it themselves. However,
their registration is listed on:
[To create a reverse DNS registration in e.f.f.3.ip6.int for pTLAs, please
send the prefix allocated above, and a list of at least two authoritative
nameservers, to hostmaster@ep.net.]
[Note: The effort to startup e.f.f.3.ip6.arpa is well underway with the
draft
http://www.ietf.org/internet-drafts/draft-ymbk-6bone-arpa-delegation-01.txt
now approved by the IETF/IESG as a BCP RFC. We are in the process of
getting IANA to do the actual delegation to the 6bone ip6.arpa servers.
There will be an announcement of progress soon.]
This may be the last 6bone pTLA allocation made as the phaseout plan
specifies no new pTLA allocations after the end of this year. Thus if
anyone is expecting to request a pTLA, the request must be sent to me no
later than 5 December to allow enough review and approval time prior to 31
December.
Thanks,
Bob
From jeroen@unfix.org Tue Nov 25 00:56:24 2003
From: jeroen@unfix.org (Jeroen Massar)
Date: Tue, 25 Nov 2003 01:56:24 +0100
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
In-Reply-To: <5.2.0.9.0.20031124134150.02a27d70@mail.addr.com>
Message-ID: <002601c3b2ee$f467cdb0$210d640a@unfix.org>
-----BEGIN PGP SIGNED MESSAGE-----
Bob Fink wrote:
> T-NET has been allocated pTLA 3FFE:401C::/32 having finished
> its review period.
Inserted into http://www.sixxs.net/tools/grh/tla/6bone/
8<---------------------------------------------------
The database currently holds 143 IPv6 TLA's.
Of which 16 (11.19%) are returned to the pool,
16 (11.19%) IPv6 TLA's didn't have a routing entry.
Thus 111 (77.62%) networks are currently announced.
- --------------------------------------------------->8
Polution and Hijacking was already done :)
inet6num: 3FFE:401C::/32
netname: slaqware
descr: slaqware.net test network
country: SE
admin-c: JFA1-6BONE
tech-c: JFA1-6BONE
mnt-by: JFA1-6BONE
changed: general.snus@home.se 20030712
source: 6BONE
person: John Fredriksson Ahl
address: Garvaregatan 6
phone: +46702664258
nic-hdl: JFA1-6BONE
mnt-by: JFA1-6BONE
changed: general.snus@home.se 20030712
source: 6BONE
If wanted, I could do some cleaning in the 6bone database.
The plan for doing it and the tools are near-ready.
If this is wanted, please give a notice and I'll start working on it.
Would be a good thing to have a clean 6bone database, which then at
least would show people that it is being looked after.
> [Note: The effort to startup e.f.f.3.ip6.arpa is well underway with the draft
> http://www.ietf.org/internet-drafts/draft-ymbk-6bone-arpa-delegation-01.txt
> now approved by the IETF/IESG as a BCP RFC. We are in the process of
> getting IANA to do the actual delegation to the 6bone ip6.arpa servers.
> There will be an announcement of progress soon.]
That is great news to hear. Will munnari and y be fixed any time soon too?
dig @munnari.oz.au e.f.f.3.ip6.int soa
; <<>> DiG 9.2.3rc4 <<>> @munnari.oz.au e.f.f.3.ip6.int soa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35050
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;e.f.f.3.ip6.int. IN SOA
;; Query time: 658 msec
;; SERVER: 2001:388:c02:4000::1:21#53(munnari.oz.au)
;; WHEN: Tue Nov 25 01:53:34 2003
;; MSG SIZE rcvd: 33
Same for both the IPv4 addresses (128.250.22.2 + 128.250.1.21)
y.ip6.int isn't reachable from this side of the world:
traceroute to y.ip6.int (3ffe:50e::1) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets
1 fe0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.582 ms 0.47 ms 0.292 ms
2 se2.ams-ix.ipv6.concepts-ict.net (2001:838:0:10::1) 4.1 ms 5.647 ms 3.286 ms
3 ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1) 4.61 ms 4.172 ms 4.26 ms
4 eth10-0-0.xr1.ams1.gblx.net (2001:7f8:1::a500:3549:1) 6.03 ms 9.822 ms 5.742 ms
5 2001:450:1:1::1e (2001:450:1:1::1e) 265.618 ms 278.561 ms 272.412 ms
6 2001:450:1:1::1e (2001:450:1:1::1e) 276.038 ms !H 271.19 ms !H 292.15 ms !H
Greets,
Jeroen
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP8KorymqKFIzPnwjEQJ8mACfeQWFsMIoe8k+XjH69/+n2LJyIEgAn2xF
VB6ikMsiLM7oOfw69BFeKfmo
=b+/I
-----END PGP SIGNATURE-----
From bob@thefinks.com Tue Nov 25 01:18:13 2003
From: bob@thefinks.com (Bob Fink)
Date: Mon, 24 Nov 2003 17:18:13 -0800
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
In-Reply-To: <002601c3b2ee$f467cdb0$210d640a@unfix.org>
References: <5.2.0.9.0.20031124134150.02a27d70@mail.addr.com>
Message-ID: <5.2.0.9.0.20031124170841.02a29638@mail.addr.com>
Jeroen,
Thanks for the info.
I'll get onto this John Fredriksson about his hijacking.
As for cleaning up the 6bone db at this late date (in the life of the 6bone
that is), you should ask David Kessens to see what he thinks.
As for the reverse registry for e.f.f.3.ip6.arpa, Marc Blanchet and Hexago
are ready to go but we await the servers being officially listed.
Thanks again,
Bob
===
At 01:56 AM 11/25/2003 +0100, Jeroen Massar wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Bob Fink wrote:
>
> > T-NET has been allocated pTLA 3FFE:401C::/32 having finished
> > its review period.
>
>Inserted into http://www.sixxs.net/tools/grh/tla/6bone/
>
>8<---------------------------------------------------
>The database currently holds 143 IPv6 TLA's.
>Of which 16 (11.19%) are returned to the pool,
>16 (11.19%) IPv6 TLA's didn't have a routing entry.
>Thus 111 (77.62%) networks are currently announced.
>- --------------------------------------------------->8
>
> Polution and Hijacking was already done :)
>
>inet6num: 3FFE:401C::/32
>netname: slaqware
>descr: slaqware.net test network
>country: SE
>admin-c: JFA1-6BONE
>tech-c: JFA1-6BONE
>mnt-by: JFA1-6BONE
>changed: general.snus@home.se 20030712
>source: 6BONE
>
>person: John Fredriksson Ahl
>address: Garvaregatan 6
>phone: +46702664258
>nic-hdl: JFA1-6BONE
>mnt-by: JFA1-6BONE
>changed: general.snus@home.se 20030712
>source: 6BONE
>
>If wanted, I could do some cleaning in the 6bone database.
>The plan for doing it and the tools are near-ready.
>If this is wanted, please give a notice and I'll start working on it.
>Would be a good thing to have a clean 6bone database, which then at
>least would show people that it is being looked after.
>
> > [Note: The effort to startup e.f.f.3.ip6.arpa is well underway with the
> draft
> >
> http://www.ietf.org/internet-drafts/draft-ymbk-6bone-arpa-delegation-01.txt
> > now approved by the IETF/IESG as a BCP RFC. We are in the process of
> > getting IANA to do the actual delegation to the 6bone ip6.arpa servers.
> > There will be an announcement of progress soon.]
>
>That is great news to hear. Will munnari and y be fixed any time soon too?
>
>dig @munnari.oz.au e.f.f.3.ip6.int soa
>
>; <<>> DiG 9.2.3rc4 <<>> @munnari.oz.au e.f.f.3.ip6.int soa
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35050
>;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;e.f.f.3.ip6.int. IN SOA
>
>;; Query time: 658 msec
>;; SERVER: 2001:388:c02:4000::1:21#53(munnari.oz.au)
>;; WHEN: Tue Nov 25 01:53:34 2003
>;; MSG SIZE rcvd: 33
>
>Same for both the IPv4 addresses (128.250.22.2 + 128.250.1.21)
>
>y.ip6.int isn't reachable from this side of the world:
>
>traceroute to y.ip6.int (3ffe:50e::1) from
>2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets
> 1 fe0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.582 ms 0.47
> ms 0.292 ms
> 2 se2.ams-ix.ipv6.concepts-ict.net (2001:838:0:10::1) 4.1 ms 5.647
> ms 3.286 ms
> 3 ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1) 4.61 ms 4.172
> ms 4.26 ms
> 4 eth10-0-0.xr1.ams1.gblx.net (2001:7f8:1::a500:3549:1) 6.03 ms 9.822
> ms 5.742 ms
> 5 2001:450:1:1::1e (2001:450:1:1::1e) 265.618 ms 278.561 ms 272.412 ms
> 6 2001:450:1:1::1e (2001:450:1:1::1e) 276.038 ms !H 271.19 ms
> !H 292.15 ms !H
>
>Greets,
> Jeroen
>
>-----BEGIN PGP SIGNATURE-----
>Version: Unfix PGP for Outlook Alpha 13 Int.
>Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
>
>iQA/AwUBP8KorymqKFIzPnwjEQJ8mACfeQWFsMIoe8k+XjH69/+n2LJyIEgAn2xF
>VB6ikMsiLM7oOfw69BFeKfmo
>=b+/I
>-----END PGP SIGNATURE-----
From pim@ipng.nl Tue Nov 25 08:13:06 2003
From: pim@ipng.nl (Pim van Pelt)
Date: Tue, 25 Nov 2003 09:13:06 +0100
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
In-Reply-To: <002601c3b2ee$f467cdb0$210d640a@unfix.org>
References: <5.2.0.9.0.20031124134150.02a27d70@mail.addr.com> <002601c3b2ee$f467cdb0$210d640a@unfix.org>
Message-ID: <20031125081306.GB8639@bfib.colo.bit.nl>
Hi Jeroen,
| If wanted, I could do some cleaning in the 6bone database.
| The plan for doing it and the tools are near-ready.
| If this is wanted, please give a notice and I'll start working on it.
| Would be a good thing to have a clean 6bone database, which then at
| least would show people that it is being looked after.
I have always supported this initiative. We may be able to gain valuable
expertise and detect operational pitfalls if we clean up 'a whois
database'. Perhaps your work can be used to help clean up RIPE/ARIN
databases too at some point in time.
If you have any methodology you'd like to share with the list, please go
ahead. Or, simply copy the database, clean it up privately and present a
diff to the list.
I agree that the database is being neglected by many folks. Perhaps we
can reinstate some basic sanity....
--
---------- - - - - -+- - - - - ----------
Pim van Pelt Email: pim@ipng.nl
http://www.ipng.nl/ IPv6 Deployment
-----------------------------------------------
From todd@fries.net Tue Nov 25 14:03:23 2003
From: todd@fries.net (Todd T. Fries)
Date: Tue, 25 Nov 2003 08:03:23 -0600
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
In-Reply-To: <20031125081306.GB8639@bfib.colo.bit.nl>
References: <5.2.0.9.0.20031124134150.02a27d70@mail.addr.com> <002601c3b2ee$f467cdb0$210d640a@unfix.org> <20031125081306.GB8639@bfib.colo.bit.nl>
Message-ID: <20031125140323.GA5085@fries.net>
I apologze for going to the list on this, but my information is woefully
out of date.
Only my email address should remain correct .. and at that it may be
toddf@acm.org instead of todd@fries.net...
Do you have pointers/a short faq on those of us who input data years ago,
and have no starting point as to where to gather a cluebit to do our part?
Hopefully the answer will help out more than just me.
Thanks,
--
Todd Fries .. todd@fries.net
Free Daemon Consulting, LLC VOIP: 1.636.410.0632
http://FreeDaemonConsulting.com Land: 1.405.810.2918
"..in support of free software solutions." Mobile: 1.405.203.6124
Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
Key: http://todd.fries.net/pgp.txt
Penned by Pim van Pelt on Tue, Nov 25, 2003 at 09:13:06AM +0100, we have:
| Hi Jeroen,
|
| | If wanted, I could do some cleaning in the 6bone database.
| | The plan for doing it and the tools are near-ready.
| | If this is wanted, please give a notice and I'll start working on it.
| | Would be a good thing to have a clean 6bone database, which then at
| | least would show people that it is being looked after.
| I have always supported this initiative. We may be able to gain valuable
| expertise and detect operational pitfalls if we clean up 'a whois
| database'. Perhaps your work can be used to help clean up RIPE/ARIN
| databases too at some point in time.
|
| If you have any methodology you'd like to share with the list, please go
| ahead. Or, simply copy the database, clean it up privately and present a
| diff to the list.
|
| I agree that the database is being neglected by many folks. Perhaps we
| can reinstate some basic sanity....
|
| --
| ---------- - - - - -+- - - - - ----------
| Pim van Pelt Email: pim@ipng.nl
| http://www.ipng.nl/ IPv6 Deployment
| -----------------------------------------------
| _______________________________________________
| 6bone mailing list
| 6bone@mailman.isi.edu
| http://mailman.isi.edu/mailman/listinfo/6bone
From todd@fries.net Tue Nov 25 14:14:07 2003
From: todd@fries.net (Todd T. Fries)
Date: Tue, 25 Nov 2003 08:14:07 -0600
Subject: [6bone] Is minimum allocation /64 now?
In-Reply-To: <20031103142846.GD30954@Space.Net>
References: <008201c39a7b$e91fb4d0$210d640a@unfix.org> <0a2b01c39aec$e4f3d410$9402a8c0@consulintel.es> <003901c39b02$15602c10$0200a8c0@dryad> <20031103142846.GD30954@Space.Net>
Message-ID: <20031125141407.GB5085@fries.net>
With IPN, and its reference implementation at scps.org, IP proto 105, ..
IP has no issues with solar distances.
--
Todd Fries .. todd@fries.net
Free Daemon Consulting, LLC VOIP: 1.636.410.0632
http://FreeDaemonConsulting.com Land: 1.405.810.2918
"..in support of free software solutions." Mobile: 1.405.203.6124
Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
Key: http://todd.fries.net/pgp.txt
Penned by Gert Doering on Mon, Nov 03, 2003 at 03:28:46PM +0100, we have:
[..]
| IP is not particularily well suited for solar distances anyway.
|
| Gert Doering
| -- NetMaster
From jeroen@unfix.org Tue Nov 25 15:23:42 2003
From: jeroen@unfix.org (Jeroen Massar)
Date: Tue, 25 Nov 2003 16:23:42 +0100
Subject: Updating objects in the 6bone database (Was: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET)
In-Reply-To: <20031125140323.GA5085@fries.net>
Message-ID: <00c601c3b368$1e8f14d0$210d640a@unfix.org>
-----BEGIN PGP SIGNED MESSAGE-----
Todd T. Fries wrote:
> I apologze for going to the list on this, but my information
> is woefully out of date.
>
> Only my email address should remain correct .. and at that it may be
> toddf@acm.org instead of todd@fries.net...
>
> Do you have pointers/a short faq on those of us who input
> data years ago,
> and have no starting point as to where to gather a cluebit to
> do our part?
Wellps, it is the 6bone registry and thus it is documented at:
http://www.6bone.net which has a link to http://whois.6bone.net
containing all the information.
I personally prefer the mail interface.
But Viagenie (now Hexago) have a Webinterface at:
http://eng.hexago.com/6bone/registry/
And otherwise, just scream and shout here with the details and
there will be someone to help you out.
Greets,
Jeroen
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP8Nz/imqKFIzPnwjEQLQZQCeI0WYCeeMIGH4oLgXzVyh3kB5LjQAoMFU
o72/QiTepBa1gg3vARFjbD2P
=bzeL
-----END PGP SIGNATURE-----
From tjc@ecs.soton.ac.uk Tue Nov 25 15:35:45 2003
From: tjc@ecs.soton.ac.uk (Tim Chown)
Date: Tue, 25 Nov 2003 15:35:45 +0000
Subject: [6bone] Is minimum allocation /64 now?
In-Reply-To: <20031125141407.GB5085@fries.net>
References: <008201c39a7b$e91fb4d0$210d640a@unfix.org> <0a2b01c39aec$e4f3d410$9402a8c0@consulintel.es> <003901c39b02$15602c10$0200a8c0@dryad> <20031103142846.GD30954@Space.Net> <20031125141407.GB5085@fries.net>
Message-ID: <20031125153545.GA6598@login.ecs.soton.ac.uk>
Vint Cerf has been making some nice presentations on this topic, e.g.:
http://www.nordunet2003.is/programme.php
(first talk listed)
Tim
On Tue, Nov 25, 2003 at 08:14:07AM -0600, Todd T. Fries wrote:
> With IPN, and its reference implementation at scps.org, IP proto 105, ..
> IP has no issues with solar distances.
> --
> Todd Fries .. todd@fries.net
>
>
> Free Daemon Consulting, LLC VOIP: 1.636.410.0632
> http://FreeDaemonConsulting.com Land: 1.405.810.2918
> "..in support of free software solutions." Mobile: 1.405.203.6124
>
> Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
> Key: http://todd.fries.net/pgp.txt
>
> Penned by Gert Doering on Mon, Nov 03, 2003 at 03:28:46PM +0100, we have:
> [..]
> | IP is not particularily well suited for solar distances anyway.
> |
> | Gert Doering
> | -- NetMaster
> _______________________________________________
> 6bone mailing list
> 6bone@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/6bone
From jeroen@unfix.org Tue Nov 25 16:30:47 2003
From: jeroen@unfix.org (Jeroen Massar)
Date: Tue, 25 Nov 2003 17:30:47 +0100
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
In-Reply-To: <20031125081306.GB8639@bfib.colo.bit.nl>
Message-ID: <00df01c3b371$7c208c10$210d640a@unfix.org>
-----BEGIN PGP SIGNED MESSAGE-----
Pim van Pelt [mailto:pim@ipng.nl] wrote:
> Hi Jeroen,
>
> | If wanted, I could do some cleaning in the 6bone database.
> | The plan for doing it and the tools are near-ready.
> | If this is wanted, please give a notice and I'll start working on it.
> | Would be a good thing to have a clean 6bone database, which then at
> | least would show people that it is being looked after.
> I have always supported this initiative. We may be able to
> gain valuable
> expertise and detect operational pitfalls if we clean up 'a whois
> database'. Perhaps your work can be used to help clean up RIPE/ARIN
> databases too at some point in time.
>
> If you have any methodology you'd like to share with the
> list, please go ahead. Or, simply copy the database, clean it up privately
> and present a diff to the list.
>
> I agree that the database is being neglected by many folks. Perhaps we
> can reinstate some basic sanity....
We could take the current 6bone database and clean it up a lot
by doing at least the following things:
- check all objects for valid maintainers.
- if an object doesn't have a maintainer mail the e-mail addresses
and check them for validity.
"This is the 6bone DB Cleaning service, if you read this message
please attach a maintainer object to or remove the object
Objects that don't have a maintainer in days will receive a
default maintainer"
- purge if none of the email addresses are valid.
- add default maintainer when no response in days.
- don't allow any unmaintained objects to be inserted anymore
- notify and possibly later purge all ipv6-sites using private ASN's.
- mnt-lower support
Insert mnt-lower's for the pTLA's and the currently existing
inet6num's with the maintainers they have.
inet6num's without maintainers get the maintainer from the
level above, also allowing the real owners of the TLA to
modify them if they want.
- Removal of all old prefixes (5000::/8 or something?)
A second phase could also include checking:
- references of objects, though I am quite sure that many
objects exist for usage in remote places, eg SixXS uses
the person objects which are mostly unreferenced by the
rest of the database.
If wanted I could create a program which does all of the above
and then we could have a nice cleaning celebration the next RIPE
meeting. People are urging to clean up odd objects in the RIPEdb
also thus having a clean 6bone db seems like a good idea.
As for having a lot of maintainers, we could even create a
special "MNT-PASSWORD" which allows changing objects using a
per-object password. I envision something like:
person: Ernest. X. Ample
address: ExampleCity
e-mail: test@example.com
nic-hdl: TEST-EXAMPLE
remarks: PASSWORD: $1$19e017c9c26a8af449440dae3a6b0aad
notify: test@example.com
mnt-by: MNT-PASSWORD
changed: test@example.com 20031125
source: 6BONE
Then they can manage the object like it is theirs through
the site by sending:
person: Ernest. X. Ample
address: ExampleStreet
address: ExampleCity
e-mail: test@example.com
nic-hdl: TEST-EXAMPLE
remarks: PASSWORD: $1$19e017c9c26a8af449440dae3a6b0aad
notify: test@example.com
mnt-by: MNT-PASSWORD
changed: test@example.com 20031125
source: 6BONE
password: P455W0RD
Retrieving forgotten passwords could be handled by sending
a new "PASSWORDRECOVER" operation, which would then send
an email to the user with their new password.
Greets,
Jeroen
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP8ODtymqKFIzPnwjEQLjuACgrWLZJ6AYWLS4oxDVw/vN5Ic6k98An0+y
L/QB+yAQmo1xwoKIKC5Cz3rE
=ctG6
-----END PGP SIGNATURE-----
From Sascha Bielski Tue Nov 25 17:05:07 2003
From: Sascha Bielski (Sascha Bielski)
Date: Tue, 25 Nov 2003 18:05:07 +0100
Subject: Updating objects in the 6bone database (Was: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET)
In-Reply-To: <00c601c3b368$1e8f14d0$210d640a@unfix.org>
References: <20031125140323.GA5085@fries.net>
<00c601c3b368$1e8f14d0$210d640a@unfix.org>
Message-ID: <145483234.20031125180507@rdns.de>
Hi,
> But Viagenie (now Hexago) have a Webinterface at:
> http://eng.hexago.com/6bone/registry/
Hmm, didn't notice that. Does anybody know who's the ipv6 peering
contact there now? I mailed to the old viagenie address but didn't get
any reply yet.
Thanks for any help.
--
Best regards,
Sascha Bielski mailto:sb@rdns.de
Unix-Servers.de IPv6 Management Phone: +49 179 7475737
From jeroen@unfix.org Tue Nov 25 18:51:10 2003
From: jeroen@unfix.org (Jeroen Massar)
Date: Tue, 25 Nov 2003 19:51:10 +0100
Subject: Updating objects in the 6bone database (Was: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET)
In-Reply-To: <145483234.20031125180507@rdns.de>
Message-ID: <014d01c3b385$18824a40$210d640a@unfix.org>
-----BEGIN PGP SIGNED MESSAGE-----
Sascha Bielski wrote:
> > But Viagenie (now Hexago) have a Webinterface at:
> > http://eng.hexago.com/6bone/registry/
>
> Hmm, didn't notice that. Does anybody know who's the ipv6 peering
> contact there now? I mailed to the old viagenie address but didn't get
> any reply yet.
Marc Blanchet should be able to help you out in that front.
Greets,
Jeroen
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP8OkjymqKFIzPnwjEQJXDwCdHqMACRiqdeib6u9vhBL0uWI6viwAniIx
VMWe14KNxLi6SfAGDX8JfzfJ
=BxJp
-----END PGP SIGNATURE-----
From david@iprg.nokia.com Tue Nov 25 20:52:14 2003
From: david@iprg.nokia.com (David Kessens)
Date: Tue, 25 Nov 2003 12:52:14 -0800
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
In-Reply-To: <5.2.0.9.0.20031124170841.02a29638@mail.addr.com>; from Bob Fink on Mon, Nov 24, 2003 at 05:18:13PM -0800
References: <5.2.0.9.0.20031124134150.02a27d70@mail.addr.com> <002601c3b2ee$f467cdb0$210d640a@unfix.org> <5.2.0.9.0.20031124170841.02a29638@mail.addr.com>
Message-ID: <20031125125214.A15327@iprg.nokia.com>
Jeroen,
At 01:56 AM 11/25/2003 +0100, Jeroen Massar wrote:
>
> If wanted, I could do some cleaning in the 6bone database. The plan
> for doing it and the tools are near-ready. If this is wanted, please
> give a notice and I'll start working on it. Would be a good thing to
> have a clean 6bone database, which then at least would show people
> that it is being looked after.
I personally think that it is not worth the effort. The best way to
encourage people to use the registry is to make it easy for people to
register. This same requirement also causes it to make it easy for
people to register garbage. If you don't register a proper mail
address, people won't be able to reach you when you have a problem. If
people choose not to register, so be it - it's really their own
problem not mine. In addition, I have plenty of disk space so I really
don't mind carrying some old stale data. Also, sometimes it is still
better to find stale information than nothing at all, you can always
do a google search or whatever and there is a good chance you will be
able to find the person. The Internet is a cooperative thing and there
is no Internet police who can chase down the bad guys. We can only do
this ourselves by putting filters in our routers and refusing to peer
with phony businesses. The registry is of very little help here, one
can easily hijack address space without registering it anywhere. In
fact, I rather have those people register since you can at least send
them a mail.
I think that cleaning the data might be esthetically nice but it just
doesn't change anything in the network and isn't that helpful for the
rfc following crowd either. However, if you really want to spend time
on this, feel free to propose a well thought out plan to the list and
ask whether people think this is a good idea and I am more than happy
to give you the right kind of access in order to help you.
David K.
---
From jeroen@unfix.org Tue Nov 25 21:20:10 2003
From: jeroen@unfix.org (Jeroen Massar)
Date: Tue, 25 Nov 2003 22:20:10 +0100
Subject: [6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET
In-Reply-To: <20031125125214.A15327@iprg.nokia.com>
Message-ID: <019a01c3b399$e98d8500$210d640a@unfix.org>
-----BEGIN PGP SIGNED MESSAGE-----
David Kessens [mailto:david@iprg.nokia.com] wrote:
> Jeroen,
>
> At 01:56 AM 11/25/2003 +0100, Jeroen Massar wrote:
> >
> > If wanted, I could do some cleaning in the 6bone database. The plan
> > for doing it and the tools are near-ready. If this is wanted, please
> > give a notice and I'll start working on it. Would be a good thing to
> > have a clean 6bone database, which then at least would show people
> > that it is being looked after.
>
> I personally think that it is not worth the effort. The best way to
> encourage people to use the registry is to make it easy for people to
> register. This same requirement also causes it to make it easy for
> people to register garbage. If you don't register a proper mail
> address, people won't be able to reach you when you have a problem.
That is ofcourse true, but seeing the number of unresponsive pTLA's
that I have notified over the last year of rather odd configurations,
take Nortel's dually announced prefix for instance (3ffe:1300::/24)
and AS10318 who simply cannot be contacted, it is to differ if the
data has any value and if there is still someone active in those places.
Fortunatly many 'peerings' have been stopped, also because they could
not be reached by their peering partners. They apparently are not
following the guidelines that they signed up for when requesting the pTLA's.
It is not to harrass somebody, but to point out that there is some
fault in the system and that they should fix it making it a better place.
It could also be a software bug, if we don't find and fix it now it
will probably never be fixed or wreak havoc in a couple of years.
I suddenly do have to note that I see changed contact data for the NORTEL
ipv6-site, let's give them some mail. Something got woken there but
didn't take time to respond to this mailinglist.
Having a mnt-lower on the prefixes is thus my primary concern actually
as now anybody can register any prefix and get away with it, one can
even overwrite data without much trouble. The fun part is that you
cannot remove data. Thus if you own a pTLA anybody can insert data
lower than you and you as the owner of the pTLA can't remove it
without contacting you (David), not that it will happen much but it
may occur, for instance when a new pTLA gets allocated and the prefix
is already taken. Any announced prefixes will indeed be caught by
amongst others Merit's 6bone routing report and also by GRH so that
should not pose much of a problem.
Greets,
Jeroen
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP8PHiimqKFIzPnwjEQKJegCfY1q/vqSWkQ3sy0ViW6Tm4yX01koAn0SK
EnAnoQFZ9z/4SfQsHAi2eqVR
=Ql8G
-----END PGP SIGNATURE-----