[85773] in North American Network Operators' Group
Re: IPv6 news
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Mon Oct 17 08:19:18 2005
From: Jeroen Massar <jeroen@unfix.org>
To: Michael.Dillon@btradianz.com
Cc: nanog@merit.edu
In-Reply-To: <OF593F273C.740A0754-ON8025709D.00388652-8025709D.003A8E01@btradianz.com>
Date: Mon, 17 Oct 2005 14:18:47 +0200
Errors-To: owner-nanog@merit.edu
--=-0kozoqupB2PRrxroW+Zb
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Mon, 2005-10-17 at 11:39 +0100, Michael.Dillon@btradianz.com wrote:
> > Another alternative is to force-align allocation and topology in some=20
> > way /other/ than by "Providers" (geographical allocation in whatever=20
> > hierarchy, IX allocation, whatever), such that networks were easily=20
> > aggregatable. Lots of objections though (the "providers and geography=20
> > don't align" one though is ultimately slightly bogus, because with=20
> > non-provider-aligned allocation policies in place it would be in=20
> > providers interests to align their peering to match the allocation=20
> > policy).
>=20
> I think we need a researcher to sit down and=20
> figure out exactly what this would look like
> in a sample city and a sample national provider.
There has been quite some research on it, there where ideas, there was
even talk of a vendor going to implement it, but it never happened. It
won't work because of cash reasons (read: telco/transit don't want it)
For your 'city data' check:
http://unstats.un.org/unsd/demographic/default.htm
or for pre-processed files:
http://arneill-py.sacramento.ca.us/ipv6mh/ under "Geographical data".
especially:
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt
will be quite of your liking.
8<---------------------
Allocation: IANA   block =3D 2346::/16
Ratio in use: one /48 site for 4 persons
Allocation: 6bone   block =3D 3FFE:FB00::/24
Ratio in use: one /48 site for 1024 persons
-------------------->8
Which indeed seems quite reasonable. The problem with this is:
 'who is paying for which traffic and to whom'
One solution is an overlay network....
Notez bien, though this solves multihoming, it doesn't solve relocation,
thus if your company moves it has to renumber, and renumbering is no fun,
then again, you can most likely start from mostly scratch in the new locati=
on
and you might be able to tunnel (parts of) the old allocation to the new si=
te
depending on which subnets/hosts one has moved already.
Greets,
 Jeroen
--=-0kozoqupB2PRrxroW+Zb
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/
iD8DBQBDU5anKaooUjM+fCMRAsy5AJ0bNyMpJcmCbj6tx5ysvnNaL9cYkgCgt+hP
lhKMt9tPDIy014RqHBxNDiU=
=86jM
-----END PGP SIGNATURE-----
--=-0kozoqupB2PRrxroW+Zb--