[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RIR bashing, was: Routing table size?

On zondag, okt 12, 2003, at 17:02 Europe/Amsterdam, Jeroen Massar wrote:

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.

Not so obvious... They need one address. What are the other 79228162514264337593543950335 for?

It's a shame really that people as a rule still don't get it. In the old days, the root servers had an address, and we used the named.root file (wasn't it called something else back then or am I confused with named.boot?) to find them. But we're doing so many routing tricks with these addresses now that it makes much more sense to group all the address blocks for all the roots together in a special range. Bonus: we get to hardcode the root addresses now too, as we're now no longer modifying the root addresses when something changes, but keep the addresses and change the routing.

(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. 

gw#trace
Protocol [ip]: ipv6
Target IPv6 address: 3ffe:8114:2000:240:290:27ff:fe24:c19f

  1 2001:888:1DDE:1:204:27FF:FEFE:249F 4 msec 4 msec 4 msec
  2 2001:888:0:3::4242 36 msec 36 msec 48 msec
[...]

And:

gw#trace
Protocol [ip]:
Target IP address: www.unfix.org

  1 loopback.rhadamanthus.pine.nl (213.156.3.144) 12 msec 12 msec 8 msec
  2 fa0-0.rtr0002.asmr.pine.nl (213.156.0.29) 12 msec 12 msec 12 msec
  3 fa3-0-4-asd8ro2.enertel.nl (195.7.144.85) 16 msec 16 msec 16 msec
  4 fa0-0-0-asd8ro1.enertel.nl (195.7.144.149) 12 msec 12 msec 20 msec
  5 po11-1-0-asd7ro1.enertel.nl (195.7.144.2) 16 msec 12 msec 16 msec
  6 ams-ix.intouch.net (195.69.144.93) 16 msec 12 msec 20 msec
  7 217.8.101.250 16 msec 12 msec 16 msec

But this is a bit confusing as this router connects to ISP#1, which is also where its IPv4 default points to but its IPv6 default points to the router that connects to ISP#2, which has both its v4 and v6 defaults point to ISP#2 (I also have box that has a full v6 table but never mind (and I gave this router a 6bone address that belongs to the tunnel over ISP#1 to see if RIPng works if two routers don't share a subnet)):

hpromatem#trace
Protocol [ip]:
Target IP address: www.unfix.org

1 195.190.241.114 188 msec 96 msec 116 msec
2 32.ge-0-0-0.xr2.pbw.xs4all.net (194.109.5.201) 20 msec 160 msec 28 msec
3 0.ge-1-3-0.xr1.tc2.xs4all.net (194.109.5.6) 36 msec 12 msec 120 msec
4 telecity.ams-ix.intouch.net (195.69.144.175) 300 msec 276 msec 236 msec
5 217.8.101.250 244 msec 116 msec 156 msec

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

Nope. One is over a "dark copper" pair with "vooroorlogse" 144 kbps baseband modems, the other over ADSL.

and are being tunneled.

Yup, in both cases the router terminating the line at the other side doesn't grok v6.

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.

That's my current setup for my box in the colo room at ISP#1. It has a tunnel over the regular ISP#1 v4 connectivity (which is of course multihomed in its own right) and one to my house and then to ISP#2 over ADSL.

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.

Actually for incoming traffic this wouldn't be a huge problem as clients retry until they hit a working address (this actually works fairly well today). The trouble is the source address selection, and in the case of tunnels, seeing which one works and which one doesn't. And even when all of this works it still breaks existing connections.

Conclusion we need a way of notifying with
some trust/authentication that the IP of a certain host changed.

Actually that's not the hard part. Finding out the new address (assuming the internet protocol remains the same...) in such a way that an attacker can't get in the middle is harder.

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.

Hm, yes, not so simple...