Skip to content

IP-Adress-Geo-Information

Ich weiß nicht, ob das hier so schlau gewählt ist :thinking:
(Ping-Zeiten der Lesbarkeit wegen entfernt)

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Horst

Das ist DIE Idee, ich nenne meinen Host jetzt timbuktu.example.com.
Nur um eine falsche Fährte zu legen!

Anton

Macht die DTAG doch schon lange:

(...)
6 b-ec2-i.B.DE.NET.DTAG.DE (217.5.72.198)
7 87.186.245.233 (87.186.245.233)
(...)

Adrian

Bin leider kein Admin daher erkenne ich den Fehler nicht :-/ kann das hier jemand erklären?

Vielen Dank!

Peter

Die meisten Provider haben zumindest Abkürzungen der geographischen Standorte im Hostname drin. Ob es nun so geschickt und sinnvoll ist den ganzen Namen reinzunehmen ist allerdings zweifelhaft. Level3 macht das aber glaube ich auch soweit ich weiß?

Adrian

Ah verstehe - der letzte Hop ist nicht im MG?

Peter

doch ich denke schon, wie kommst du darauf?

Timo

Das vermeintliche Problem erschließt sich mir hier auch noch nicht.

Einer meinte

Es geht - vermute ich - darum, ob man einem Aussenstehenden soviel Information über den internen Netzaufbau geben möchte.

Dies ist meiner Meinung nach eine Abwägung. Klar kann ich das Netz des Providers jetzt mappen und schauen wo er eventuell Engpässe hat und eventuell auch bestimmen in welcher Stadt ein Endkunde sitzt. Aber ein Angreifer hat meistens Mittel und Wege das herauszubekommen, auch ohne eindeutige Hostnamen.

Auf der anderen Seite erspart man sich so im Fehlerfall das aufwändige suchen in Listen, welcher Link nun betroffen ist und an welchem Port an welchem Router das Kabel wackelt, wenn das peering wegbricht.

Es ist in der Regel einfacher den Kollegen in $stadt dann direkt anrufen zu können und mit ihm die Portnamen der Interdaces abzugleichen, zu denen man noch durchkommt.

just my 2¢

Manuel Schmitt (manitu)

Es ging mir weniger um die Informationen über das Netz als den Endkunden. Der Vergleich zur DTAG hinkt deshalb, weil die nur wirklich sehr große Regionen im DNS einbetten (F, B, M).

Hier sind die Informationen aber IMHO zu detailliert. Im Prinzip kann ich den Besucher der Seite hier sehr stark regional einordnen, z.B. für regionale Werbung oder auch für die Bewertung der Kreditwürdigkeit.

Timo

Die Frage ist, welcher Seitenbetreiber möchte sich den Aufriss leisten für jeden Netzbetreiber solche Mappings zu bauen. Der eine Provider schreibt vielleicht xyz.dortmund.example.com der nächste schreibt xyz.do.example.com und der dritte schreib dortm.xyz.example.com. Einzig "richtig" wäre in meinen Augen die Verwendung des UN/LOCODE, aber das ist für jeden irgendwie eine Entscheidung nach persönlichem Gusto.

Nick

Wie bewertet man denn die Kreditwürdigkeit anhand der Stadt?

Peter

z.B. anhand der Arbeitslosigkeit in der Region
http://www.pub.arbeitsagentur.de/hst/services/statistik/000000/html/start/karten/aloq_kreis.html

Bayern vs. Mecklenburg ist doch schon extrem

Ingo

Und das hilft nun wie? Kreditwürdigkeit ist allgemein nur ein Thema, wenn's um Geschäfte geht. Da hat man die Adresse, da braucht man keine IP. Und Betrugshäufigkeit ist meines Wissens innerhalb Deutschlands nicht erforscht, da geht's nur um Länder / Kontinente. Da das ganze aber nicht so hoch auflöst, dass man sagen kann, ob der Besucher aus München im Villen- oder Hochhausviertel wohnt, ist das ziemlich unsinnig, daraus irgendwas abzuleiten. Dafür eignen sich das Nutzungsverhalten und die Suchanfragen, die der User stellt, sehr viel mehr.
Angst vor der Pseudolokalisierung durch Webserver sollte man nun wirklich nicht haben.
Zumal kommerzielle Dienste das, wie erwähnt wurde, sehr genau und unabhängig von den hostnamen der Provier machen.

Nick

So sehe ich das auch.
Wenn man wirklich anfängt die Kreditwürdigkeit anhand der Stadt zu beurteilen, dann sollte man vielleicht doch überlegen, ob die Schufa nicht der bessere Ansprechpartner ist.

Anonym

Nein, Big-T weist die Pools allen 74 (BB)PoPs zu - das ist regional kaum weniger.

Aktuell sieht die Liste wie folgt aus:

A Augsburg
AC Aachen
B Berlin
BI Bielefeld
BN Bonn
BO Bochum
BRB Brandenburg
BS Braunschweig
BT Bayreuth
BZ Bautzen
CB Cottbus
C Chemnitz
DA Darmstadt
DD Dresden
D Düsseldorf
DO Dortmund
DU Duisburg
E Essen
EF Erfurt
EL Meppen
FD Fulda
FF Frankfurt
F Frankfurt
FL Flensburg
FR Freiburg
G Gera
GI Gießen
GOE Göttingen
HAL Halle
HB Bremen
HBH Bremerhaven
HGW Greifswald
H Hannover
HH Hamburg
HL Lübeck
HN Heilbronn
HO Hof
HRO Rostock
KA Karlsruhe
KE Kempten
KI Kiel
K Köln
KL Kaiserslautern
KN Konstanz
KO Koblenz
KR Krefeld
KS Kassel
LER Leer
L Leipzig
MA Mannheim
MD Magdeburg
MES Meschede
M München
MS Münster
MZ Mainz
NB Neubrandenburg
N Nürnberg
OG Offenburg
OL Oldenburg
OS Osnabrück
PA Passau
PB Paderborn
R Regensburg
RW Rottweil
SB Saarbrücken
SI Siegen
SN Schwerin
S Stuttgart
TR Trier
TS Traunstein
ULM Ulm
WES Wesel
WUE Würzburg
W Wuppertal

In dem Zusammenhang evtl. lesenswert:
http://jjaf.de/pppoe/ac/


Bissel misstrauisch macht mich aber dein einwand, dass du Besucher dieser Seite damit beurteilen kannst - da rechts steht doch dick und fett, dass ihr nicht speichert (so wie es die Datenschutzbauftragten auch fordern - siehe beispielsweise hier:
http://www.daten-speicherung.de/index.php/datenschutzbeauftragte-protokollierung-von-ip-adressen-ist-unzulaessig/ ).


Last but not least - einem Angreifer sind die Infos eh egal - Atts auf Routerinterfaces habe ich persönlich äußerst selten erlebt; die tumben Bauerntölpel atten das Ziel direkt (und können kaum nachregeln), die etwas clevereren[tm] suchen sich was lohnenswerteres, wichtiges und etwas, dass auch umfällt (die Nameserver zB).

Manuel Schmitt (manitu)

Es geht ja nicht um uns, sondern allgemein um die Möglichkeit, regionale Informationen zu erhalten. Damit wollte ich es grundsätzlich an den Pranger stellen.

Ad DTAG: Da hast Du recht. Offenbar sehe ich meistens hier nur F und B.

Karl Rannseier

QUOTE:
(...) sondern allgemein um die Möglichkeit, regionale Informationen zu erhalten. Damit wollte ich es grundsätzlich an den Pranger stellen.


Achso - ja, da ist schon was drann; ich hab das Argument der einfacheren[tm] lokalisierung im NOC durch den Hostname eh nie verstanden - vorallem in MPLS-Zeiten ist traceroute nicht das Mittel der Wahl (IMNSHO wars das auch vorher nicht - aber anderes Thema).
Auf der anderen Seite sind die Lokalisierungsdienste heute genau genug, um die dialup-pools der großen sehr genau zuzuordnen, auch wenn keinerlei Infos übers DNS ersichtlich sind - so gesehen sind die Infos dann wieder völlig unkritisch...

Vielleicht wird mit IPv6 ja alles besser :)

Peter

Wieso sollte es mit v6 besser werden? Damit haben Provider doch noch bessere Möglichkeiten den Standorten statische Prefixe zu geben die die nie wieder anfassen müssen. Dadurch wird die Lokalisierung eher noch zuverlässiger.

Karl Rannseier

Das wird ja auch passieren - Big-T plant aktuell, jedem Kunden ein /56 zuzuweisen, dass quasi-statisch ist (also Cisco-default, so wie jetzt auch bei pppoe in v4 - da muss man das Blech anfassen, wenn man dem Kunden nach nem Reconnect ein anderes Prefix bzw. eine einzelne IP zuweisen will - per default gibts nach nem schnellen reconnect die gleiche IP wieder). Machen AFAIK die Kabelnetzbetreiber auch - da muss man sich schon anstrengen, wenn man eine andere IP will.

Darum geht es aber auch -soweit ich das verstanden habe- gar nicht; es ist ja auch vernünftig, oder besser gesagt gar nicht sinnvoll anders machbar, dass man größere Netze auf die PoPs verteilt (wenn man sich auf nanog oder der ripe-ml da manche merkbefreite Kommentare durchliest, dass alle Router explodieren aufgrund der riesigen BGP-Tables, was soll da erst intern passieren, wenn man da jedes /56 einzeln announced ;)). Der Nachteil ist dabei halt, dass du recht genau lokalisiert werden kannst.

Manuel ging es -wenn ichs richtig verstanden habe- eher darum, dass man erst gar keine externen Dienste bemühen muss, da man alleine aus den Hostnamen den Standort recht genau ablesen kann.

Vielleicht lassen die ISPs bei den Pointern in IPv6 ja was weniger..."ausdrucksstarkes" einfallen? ;)

Andreas

So in etwa? ;-)
1412A-MX960-02-ae0.21.sternstrasse.krefeld.unity-media.net

Karl Rannseier

YMMD :)
Du musst zugeben - einem Externen sagt so ein Hostname doch kaum was; 1412A-MX960-02-ae0 ist doch voll verschlüsselt und so :p

Andreas (ein anderer)

Bei einem österreichischen Kabelnetzbetreiber habe ich das tatsächlich schon mal gesehen. Leider ist mir der Name des Providers entfallen..

Jürgen Jaritsch

Die UPC macht das unter anderem so ;).

4 91-118-86-89.static.inode.at (91.118.86.89)
5 vie1-vl-00-952.shuttle.vien.inode.at (62.99.170.189)
6 vie5-po-50-000.shuttle.vien.inode.at (62.99.170.150)
7 lac2-viech5.inode.at (213.229.45.6)

Shuttle ist in dem Fall die Shuttleworth-Str. in Wien.

Manuel Schmitt (manitu)

ACK!

Peter

Das gibts auch in ähnlicher Form bei QSC und Telefonica. Ich hab da in letzter Zeit mal Daten gesammelt und werde die demnächst in meinem Blog auch veröffentlichen.

L.E.

Also was mir bei solchen Routen noch vielmehr Angst macht, dass die über zig interne Hops geleitet werden. Was bringt das großartig? Außer natürlich die Standorte der Kunden möglichst engmaschig aufzuschlüsseln und möglichst lange zu kontrollieren.

Das rosa "T" z.B. zeigt es doch, dass das auch anders geht. Klar, das ist ein Tier2-Provider. Aber trozdem...

Oder habe ich da jetzt einen grundsätzlichen Denkfehler? Ich lass mich gerne eines "Besseren" belehren. ;)

Jürgen Jaritsch

Ob das jetzt Hops sind, die du siehst oder nicht, ist im Bereich von Access-Leitungen egal.

MPLS

Die DTAG hat vermutlich genauso viele lokale Hops, die versteckt die nur in einem MPLS-Netz...
Und keiner baut Router aus Spaß ein, dafür kosten die zuviel ;)

Claus

...aktuell eher nicht. Bis zum Client sieht man doch jeden Hop.

Allenfalls zwischen den ganzen PE's (ea,eb,ec,ed) hängen noch P Router a la (sa,sb) und die kann man durch einen Traceroute auf z.B. einen ea,eb,c,ed auch sehen.

L.E.

Ich hätte nie gedacht, dass ich hier soviel Neues lernen würde. Kaum denkt man, man hätte das Routing verstanden und dann wird man wenig später wird ganz an den Anfang geworfen.^^

Eine Frage noch, was ich dazu schon immer gerne gewusst hätte: Was haben eigentlich diese "ea,eb,..." oder "xae" o.ä. Abkürzungen für eine Bedeutung? Ist das einfach nur die Geräteabkürzung oder die der VLANs?

Karl rannseier

Ein LSR kann gar keine echoe-replies senden, da er unterhalb von IP arbeitet.
Cisco-default ist, dass der erste LER die echoe-replies für alle folgenden LSR sendet, was aber aktuell kein mir bekannter carrier mehr macht.

Anfangs hat es Big-T gemacht, dann sahen traceroutes für den Laien sehr komisch aus - pseudobeispiel:

1. AC 6ms
2. SLR (LER) 8ms
3. LSR 9ms
4. LSR 8ms
5. LSR 8ms
6. LSR 7ms
(...)
10. LER 19ms
(...)

Vorallem dann, wenn man über den großen Teich ging, und der vorletzte Hop (innerhalb von AS3200) in New York, und der LER in Chicago oder so stand - dann sahs so aus, als ob man in

Karl Rannseier

Ein LSR kann gar keine echoe-replies senden, da er unterhalb von IP arbeitet.
Cisco-default ist, dass der erste LER die echoe-replies für alle folgenden LSR sendet, was aber aktuell kein mir bekannter carrier mehr macht.

Anfangs hat es Big-T gemacht, dann sahen traceroutes für den Laien sehr komisch aus - pseudobeispiel:

1. AC 6ms
2. SLR (LER) 8ms
3. LSR 9ms
4. LSR 8ms
5. LSR 8ms
6. LSR 7ms
(...)
10. LER 19ms
(...)

Vorallem dann, wenn man über den großen Teich ging, und der vorletzte Hop (innerhalb von AS3200) in NewYork, und der LER in Chicago oder so stand - dann sahs so aus, als ob man in unter 12ms in NY, und erst nach 250ms in Chicago wäre.


Seitdem sieht es bei Big-T (wie bei allen anderen großen Carrier, die ein MPLS-netz nutzen) so aus:

1. AC
2. SLR (LER)
3. LER
4. Border
5. $UPSTREM/$PEERING BR

Es ist natürlich unsinnig zu glauben, dass bei Big-T alle LER mit allen anderen direkt e konnektivität hätten ;)


PS:
Aha, das kleiner-zeichen darf man also nicht verwenden...

Claus

.... zum Thema LSR und ICMP sei z.B. auf RfC4950 verwiesen.

Dein 2. Pseudo traceroute stimmt nicht, denn der "End" LER erscheint dann verständlicherweise nicht.

Btw. das ASN von Big-T ist AS3320 und nicht AS3200 ! :-)

Karl Rannseier

Hier gehts nicht um Fehlermeldungen. Hier geht es darum, dass die LSR eben eher switchen denn routen, also unterhalb von IP arbeiten und deshalb eben (Fehler ausgenommen) über kein IP-Protokoll kommunizieren; sie schauen sich das IP-Paket nichteinmal an, sondern arbeiten nach dem dranngepappten Label.

In quasi allen mir bekannten Umgebungen wird der Schalter mpls ip propagate-ttl ( http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1013846 ) gesetzt, wodurch es zu folgendem Effekt kommt:
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008020a42a.shtml



Ansonsten hast du natürlich recht - sowohl was das AS von Big-T anbelangt als auch meine Aussage zu echo-replies (und UDP völlig außen vor gelassen habe - zu meiner Verteidigung - zumeist kommen Anfragen aus der Ecke, dass Leute meinen ihr Routing sei kap0t, weil sie nen vermeintlich sprunghaften Anstieg zwischen zwei örtlich sehr eng aneinanderliegenden Orten im traceroute festzustellen glauben, was aber eben an den gar nicht von den LSR produzierten Antworten liegt, und sie deshalb alle Orte wie verrückt anpingen und die RTT messen).

Ich weiß schon, weshalb ich mich hinter wechselnden Pseudonymen verstecke, wenn ich mal eben schnell was in einem Blog abkippe :p

Lars

Hey,

ist das IPv6 hier kaputt?

PING hostblogger.de(apu.manitu.net) 56 data bytes
From 2a00:1828:1000:1001::8 icmp_seq=1 Destination unreachable: No route
From 2a00:1828:1000:1001::8 icmp_seq=2 Destination unreachable: No route
From 2a00:1828:1000:1001::8 icmp_seq=3 Destination unreachable: No route
From 2a00:1828:1000:1001::8 icmp_seq=4 Destination unreachable: No route
From 2a00:1828:1000:1001::8 icmp_seq=5 Destination unreachable: No route


Gruß,
Lars

Christoph

Telefonica macht das in den Mediaways Netzen ebenfalls so

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen