RE: RIR bashing, was: Routing table size?

["Jeroen Massar" <jeroen@unfix.org>]

-----BEGIN PGP SIGNED MESSAGE-----

Iljitsch van Beijnum [mailto:iljitsch@muada.com] wrote:

> > -----BEGIN PGP SIGNED MESSAGE-----
>
> Signature still doesn't work...

[OT] They fixed it in gpg, so apparently it wasn't my prob afterall :)
But gpg also has problems with multiple subkeys which have been
fixed in the latest tree too...

> > If you want to be 'visible' with a smaller block you are an
> > enduser
> 
> Or a root nameserver...

Which get /32's too but for an obvious reason.
But that is critical infra and I don't think (m)any
people will argue against rootservers being crititical.
TLD servers though can do with upstream IP's

> > and at the moment you are out of luck. But then again
> > I don't know any enduser type people having the connectivity
> > nor the need for their own routing. That's why I pay my upstreams
> > so they can handle all that stuff for me and I can sleep fine :)
> 
> Ok then we can terminate this working group.
> 
> Actually you do know such an enduser: me. I have two lines 
> coming into  my home and I run IPv6 over both of them.
> In fact the server that is colocated with one ISP is reachable
> (over IPv6) through the other ISP, my home network and the
> link to the colo ISP. (Do some traces for www.bgpexpert.com.)

traceroute6 2001:888:1DDE:2:0:0:0:1

 7  ipv6tb.xs4all.nl (2001:888:0:3::4242)  11.033 ms  10.373 ms  10.962 ms
 8  tunnel3550.ipv6.xs4all.nl (2001:888:10:dde::2)  35.457 ms  43.098 ms  35.897 ms
 9  3ffe:2500:310:1:200:cff:fe3e:6052 (3ffe:2500:310:1:200:cff:fe3e:6052)  36.448 ms  35.899 ms *
10  sequoia.muada.com (2001:888:1dde:2::1)  57.616 ms  50.246 ms  56.188 ms

I wonder where hop 9's packets came from and how the flow to me.

 3  ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1)  5.099 ms  4.124 ms  4.654 ms
 4  e0.6b2.ams7.alter.net (2001:7f8:1::a501:2702:1)  6.661 ms *  4.357 ms
 5  sequoia.muada.com (2001:888:1dde:2::1)  50.087 ms  48.297 ms  39.151 ms
 6  3ffe:2500:310:1:200:cff:fe3e:6052 (3ffe:2500:310:1:200:cff:fe3e:6052)  39.342 ms *  42.977 ms

But indeed this is a case of multiple independent links
even though they are going over the same physical IPv4 path
and are being tunneled.

I personally see the situation where I would get two
independent ISP's, eg a cable and ADSL provider. They don't
have to know anything about eachother. The only thing they do
is that they each route a prefix from and to me as delegated out
of their TLA. My boxes thus would get 2 prefixes. For routing
packets they will pick either prefix and send out packets.
Now if one link goes down TCP connections terminate. If there
would be a server type application on the box it would then
not be reachable. Conclusion we need a way of notifying with
some trust/authentication that the IP of a certain host changed.
IMHO the best solution would be a id/loc seperation thus only
using the ISP's prefixes in transit, the hosts would use the
ID prefixes and never know anything about the routing prefixes.

But that probably all has been told and documented a lot of
times already... if someone has space for an intern to dive
into this I volunteer myself to take that place and implement
such a scheme...

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/

iQA/AwUBP4ls+imqKFIzPnwjEQJKbgCfQIzIcYf98Alq67lP8KhWVYBWG1EAoKCI
+Wju+fhgVCnWPQiLluUJ3xED
=mzBp
-----END PGP SIGNATURE-----