[94305] in North American Network Operators' Group
Re: IPv6 section of ARIN Number Resource Policy (Sec 6.5.1.1.c)
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Wed Jan 17 14:46:14 2007
Date: Wed, 17 Jan 2007 19:32:46 +0000
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>
Cc: nantoniello@antel.net.uy, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.64.0701171903020.14543@netcore.fi>
Errors-To: owner-nanog@merit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig10F9C288C0ABA539EABC03A8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Pekka Savola wrote:
> On Wed, 17 Jan 2007, Nicol=E1s Antoniello wrote:
>> A /28 prefix may have a lot of incoming traffic associated to it, so I=
>> believe the dissagregation (subnets) of the prefix should be allowed
>> by the policy.
I guess you are talking about 2800:a0::/28 which was allocated by
LACNIC, and not ARIN, 2 days ago and is not in the routing tables yet:
http://www.sixxs.net/tools/grh/dfp/all/?country=3Duy
Funnily 2001:13c0::/32 is also allocated to the same organization.
Which was allocated 2005-08-10 and was seen already a week later.
Thus either you figured out that the /32 was too small or you are trying
to have two prefixes and announce them both ;) I assume the first, but
the question then is, will you return it.
Also folks: please register route6 objects in either RIPE or RADB
(ARIN/APNIC/LACNIC don't where possible, that makes it much easier to
determine if the correct ASN are originating the correct prefix.
>> What do you think? Do you have a similar problem?
>=20
> Please achieve inbound load balancing on other, less network-stressful,=
> ways. At least one way to do so to examine what can be done to
> influence your upstreams' (and recursively if applicable) route
> preferences (e.g., using communities).
Indeed. That is how it should be done. These issues should be handled by
the routing protocol.
Also:
* ISP's are already de-aggregating their prefixes
See http://www.sixxs.net/tools/grh/lg/?show=3Dbogons&prefix=3D::/0
(Only run that query when you have the time to wait it is huge and
it will make your firefox think it hangs ;)
With loads of /35's, /40's and /48's which can easily be aggregated
as they are coming from the same ASN, thus clearly they are not
multihoming examples.
But note that due to filtering some prefixes get really bad
connectivity. As they will be filtered by the fast and speedy transits,
while being accepted by the slow ones. The slow ones do announce it,
thus in the end your packets will take the slow route.
* What business has a RIR telling one how to do routing?
RIR's should give out address space to organizations that need it
and that is it. Note that Address Space !=3D Routing.
That a RIR recommends to not de-aggregate is VERY good hint from
them though. But requirement is something else. For that matter,
they can't stop you anyway. But other ISP's can and those are the
ones one talks with and pays cash to to carry the prefixes(*).
Do also note that the RIR's are community driven, as such the
community makes up the rules, vote with your words if you need to.
That said, ISP's that don't want de-aggregates can filter them out
Examples here: http://www.space.net/~gert/RIPE/ipv6-filters.html
On another note here, when S-BGP gets introduced, are the RIR's going to
give certificates away which allow announcing de-aggregates of
allocations? :) If they don't then that will solve this de-aggregate
problem in one go.
"be conservative in what you send, be liberal in what you receive" :)
Greets,
Jeroen
* =3D Networking 101 for Evil Internet Beings: if you don't want to use
the RIR's one can always setup his/her own RIR and simply pay ISP's to
accept your prefix. Cash also works for creating .xxx TLD's and a lot of
other things. And that is still the cool thing with the Internet, if you
have enough force (cash, politics etc) or followers then at a certain
point your part of the internet becomes important enough that people
require it's use.
--------------enig10F9C288C0ABA539EABC03A8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/
iHUEARECADUFAkWued4uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy
b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I9B0AJ4oDZDzechT196brov23VLSgW9B
zQCfTkDPOVmToMCkxV0A0aKsuNqtNYM=
=lzMr
-----END PGP SIGNATURE-----
--------------enig10F9C288C0ABA539EABC03A8--
