Thema: RFC diverses ...

[SiLæncer]

Alle .de-Domains sind auf der "schwarzen Liste" von RFC-Ignorant.org gelandet. Nach Ansicht der Organisation, die sich selbst als Clearinghaus für "Sites, die der Ansicht sind, die Regeln des Internet gälten für sie nicht" bezeichnet, verletzt der von der zentralen Registrierungsstelle DeNIC für alle .de-Domains betriebene Whois-Dienst die technischen Regeln des Internet, wie sie in den RFCs festgeschrieben sind. Das Whois-Verzeichnis soll Auskunft darüber erteilen, wer eine bestimmte Domain registriert hat und wer sie administriert. Das Listing führt bei einigen Mailservern in aller Welt dazu, dass E-Mails aus dem .de-Raum mit höherer Wahrscheinlichkeit als Spam eingestuft werden. Das DeNIC selbst meint, die Buchstaben des einschlägigen RFC 3912 (Whois Protocol Specification) zu erfüllen und sieht die Schuld bei RFC-Ignorant.org.

Die Site listet Domains auf, deren Inhaber RFCs nicht einhalten. Sie funktioniert ähnlich wie RBL (Realtime Blackhole Lists), welche Server auflisten, die Spammer für ihre Aktivitäten nutzen. Einige Mailserverbetreiber setzen die Liste von RFC-Ignorant.org auch entsprechend zur Spamabwehr ein. Obwohl nur wenige Administratoren auf Grund eines Listings bereits alle Mails mit .de-Absender zurückweisen dürften, erhöht der Eintrag doch in vielen Spamfiltern den Punktwert von .de-Mails. Überschreitet der aus verschiedenen Parametern errechnete Wert eine bestimmte Grenze, wird die Nachricht als Spam eingestuft und entsprechend gekennzeichnet oder gleich gar nicht weitergeleitet. Als Konsequenz landen möglicherweise legitime Mails ungelesen im digitalen Rundordner.

RFC 3912 sieht unter anderem vor, dass Whois-Abfragen über TCP-Verbindungen an Port 43 durchgeführt werden können. Whois.denic.de liefert bei normalen Abfragen keine Informationen über Domaininhaber oder -Administratoren, ein lapidares "status: connect" ist die einzige Reaktion. Tatsächlich enthält RFC 3912 keine näheren Angaben darüber, welche Informationen ausgeworfen werden sollten. Üblich sind allerdings Daten über die Domain, Admin-C, Tech-C und Zone-C. Ein endgültiger Schutz gegen unerwünschte Datenschnüffler ist die restriktive Beauskunftung von whois.denic.de durch die Registry nicht, sie erschwert aber möglicherweise die Automatisierung von Abfragen: Durch Voranstellen der Option -T dn,ace können alle üblichen Daten erfragt werden.

"Unser WHOIS für .de ist komplett konform zu RFC 3912", meint DeNIC-Betriebsleiter Joachim Strohbach in einer Stellungnahme auf der öffentlichen DeNIC-Mailingliste. Es sei der Registrierungsstelle aber nicht gelungen, RFC-ignorant.org von dieser Ansicht zu überzeugen. "Es spricht ja schon für sich und von Ignoranz, deswegen die weltweit zweitgrößte Top Level Domain in eine Blackliste für Mails aufzunehmen und diese dann öffentlich zur Verfügung zu stellen. Vor allem auch dann, wenn die 'Kritik' sich auf einen ganz anderen Service bezieht." Strohbach zeigt keine Bereitschaft, die Funktionsweise von whois.denic.de anzupassen. Vielmehr möchte er, dass Mailserverbetreiber in aller Welt RFC-Ignorant.org ignorieren.

Um den Umgang mit den Daten über Inhaber von Domains und IP-Adressen sowie die technischen Administratoren im Whois wird seit einiger Zeit gestritten. Seit mehreren Jahren versucht eine Whois-Arbeitsgruppe innerhalb der ICANN das Dilemma zwischen Datenschutzanforderungen und den Wünschen der Strafverfolger und der Markenschützer zu lösen. Während beispielsweise die Strafverfolger freien Zugang zu allen im Whois hinterlegten Daten für sich selbst fordern, wird der in vielen Fällen freie und automatisiert mögliche Zugang zu allen persönlichen Daten etwa von Domain-Inhabern von Datenschützern scharf kritisiert. Das DeNIC hat daher beispielsweise eingeführt, dass keine automatische Abfrage der Inhaber-Daten zu einer Domain über die Webseite mehr möglich ist, sondern eine Zustimmung zu Datenschutzbestimmungen notwendig wird. Damit soll unter anderem Spammern die Arbeit erschwert werden: "Die in der whois-Abfrage ersichtlichen Domaindaten sind rechtlich geschützt. Sie dürfen nur zum Zwecke der technischen oder administrativen Notwendigkeiten des Internetbetriebs oder zur Kontaktaufnahme mit dem Domaininhaber bei rechtlichen Problemen genutzt und ohne ausdrückliche schriftliche Erlaubnis der DENIC eG weder elektronisch noch in anderer Art gespeichert werden. Insbesondere die Nutzung zu Werbe- oder ähnlichen Zwecken ist ausdrücklich untersagt", heißt es in den Nutzungsbestimmungen des DeNIC.

Quelle und Links : http://www.heise.de/newsticker/meldung/62780

[SiLæncer]

 Vor 40 Jahren, am 7. April 1969, erschien der erste Request For Comments. Im RFC 1 beschrieb Steve Crocker die Software-Architektur des gerade entstehenden ARPANET. Ursprünglich fungierten die RFCs tatsächlich als Diskussionsbeitrag der sehr überschaubaren "Network Working Group" (RFC 2 ist eine direkte Antwort auf RFC 1). Da die Gruppe noch daran arbeitete, das ARPANET aufzubauen, wurden die ersten RFCs auf Papier per Post ausgetauscht.

Im Laufe der Zeit entwickelten sich die RFCs dann zu den Standarddokumenten des ARPANET und später des daraus entstehenden Internets. Das Wachstum des Netzes zeigt sich ganz direkt im Output an RFCs: Nach einer Phase intensiver Diskussionen parallel zum Aufbau des ARPANET folgte eine Ruhephase, in der das Netz selbst weniger Aufmerksamkeit brauchte. Doch Ende der 70er-Jahre kam wieder Schwung in die Technik, und spätestens seit der Einführung von TCP/IP wachsen Netz und RFCs im Gleichschritt. So befasste sich der 2555ste RFC mit den ersten 30 Jahren RFC-Geschichte. In den zehn Jahren seitdem sind fast 3000 Texte hinzugekommen.

Doch nicht nur die Zahl wuchs, sondern auch die Länge der einzelnen Standards. So umfasst die Definition des Post Office Protocol (POP3) von 1985 schlanke 24 Seiten, die ein halbwegs begabter Programmierer sofort in Server und Client umsetzen kann. Mit dem zugegebenermaßen mächtigeren IMAP befassen sich seit 1994 183 RFCs mit unzähligen Seiten. Das liegt nicht nur an der größeren Leistungsfähigkeit moderner Protokolle und dem Wandel des Internets von einem Forschungsprojekt zum globalen Kommunikationsnetz. Vielmehr spielen auch immer häufiger wirtschaftliche und politische Interessen bei den technischen Entscheidungen eine Rolle. Das lässt sich unter anderem daran ablesen, dass die einzelnen RFCs im Durchschnitt mehr Autoren haben und diese inzwischen fast alle nicht mehr in Universitäten arbeiten, sondern in Wirtschaftsunternehmen.

Mehr Text trägt übrigens nicht immer zu mehr Klarheit bei. Die Flame-Wars zwischen den Programmierern von IMAP-Servern und der RFC-Gruppe über Details des Protokolls sind legendär.

Die Legende Jon Postel

Eine Legende ist auch Jon Postel, der seit 1970 an den RFCs mitarbeitete und bis zu seinem Tod 1998 der rfc-editor war, also der Herausgeber der RFCs. Natürlich veröffentlichte Vint Cerf – ein anderes Internet-Urgestein – seinen Nachruf als RFC.

Kuriositäten

Solche nicht-technischen RFCs gibt es weiterhin. Am bekanntesten sind wohl die seit 20 Jahren fast regelmäßig zum 1. April erscheinenden Scherz-RFCs. Diese Texte sind oft satirische Spitzen gegen aktuelle technische Entwicklungen, wie etwas das Protokoll BLOAT von 2002, das IP-Adressen, UDP- und TCP-Ports durch XML ersetzen will. Erstaunlicherweise fehlt ausgerechnet im Jahr 2006, in dem besonders viele RFCs veröffentlicht wurden, ein 1.-April-RFC. Sollten die RFC-Redakteure vor lauter Arbeit vergessen haben, einen April-Scherz zu bringen? Jedenfalls gibt es in der Liste der im April 2006 veröffentlichten RFCs keinen offensichtlichen Kandidaten.

Eine andere Kuriosität ist RFC 31, der angeblich über ein Jahr älter ist als RFC 1, nämlich vom Februar 1968 stammen soll. Sowohl die Daten von RFC 30 und RFC 32 als auch der Inhalt sprechen aber eher für das Jahr 1970. 1968 entstand wahrscheinlich als Zifferndreher aus dem Jahr 1998, in dem Dave Bachmann die Online-Version bearbeitete.

Der kürzeste veröffentlichte Text ist der heute unbedeutende [RFC 18, der längste 4949, ein Glossar von Sicherheitsbegriffen. Wer sich für solche Statistiken interessiert, findet weitere online generierte auf den Seiten des RFC-Autors Jari Arkko.

Offene Standards

Die RFCs waren von Anfang an eine offene Diskussionsplattform. Schon RFC 3 befasst sich mit Form und Verteilung der Notizen und stellt dabei ausdrücklich fest, dass die Network Working Group weiteren Mitglieder offensteht. Als das Netzwerk die nötigen Dienste anbieten konnte, war der logische Schritt, die RFCs online zu sammeln. So beruhte das ARPANET (und das daraus hervorgegangene Internet) von vornherein auf offenen Standards. Das eher zufällig entstandene Prinzip der RFCs war einer der wichtigsten Erfolgsfaktoren beim Entstehen dessen, was wir heute als Internet kennen. Anderswo in der entstehenden IT-Industrie war es dagegen üblich, Entwicklungen als Erfindungen zu betrachten, mit Patenten zu schützen und erst viel später zu veröffentlichen.

Quelle : www.heise.de

[SiLæncer]

Das von Michelle Cotton und Leo Vegoda (beide ICANN) verfasste RFC 5735 ordnet die reservierten IPv4-Adressen neu und hebt Reservierungen für die Adressbereiche 14.0.0.0/8, 128.0.0.0/16, 191.255.0.0/16 und 223.255.255.0./24 auf. Zusätzlich wird der Bereich 24.0.0.0/8 nicht mehr als durch die ARIN verwaltet gelistet, ähnliches gilt für die Adressen im Bereich 39.0.0.0/8. Die regionalen Internet Registries (RIPs) können diese nun in gewohnter Weise vergeben.

Zu dem bislang für Dokumentationszwecke freigegebenen Bereich 192.0.2.0/24 kommen die Adressen aus 198.51.100.0/24 sowie 203.0.113.0/24 hinzu (TEST-NET-1/2/3). Eine Übersicht über die nun reservierten Bereiche findet sich auf der Seite Reservierte IPv4-Adressen bei heise Netze. Glaubt man den Berechnungen des IPv4 Exhaustion Counters sowie den Vorhersagen der Experten reicht der Vorrat an freien IPv4-Adressen noch knapp 600 Tage — also etwa bis etwa Mitte September 2011.

Quelle : www.heise.de

[SiLæncer]

Bereits Ende 2007 hatte der französische Provider Free seinen 1,5 Millionen Breitbandkunden das Angebot gemacht, auch über IPv6 kommunizieren zu können. Dabei setzt er auf ein vom Rémi Després entwickeltes Verfahren  namens  "IPv6 Rapid Deployment in IPv4 Infrastructures" (6RD), das die IETF am gestrigen Sonntag als RFC 5569 veröffentlicht hat.

6RD benötigt per Software angepasste Modems respketive Router beim Endkunden (CPE) sowie Relays beim Provider. Der Provider Free hat die nötigen Umbauten innerhalb von fünf Wochen realisiert.

Ähnlich wie die Tunneltechnik 6to4 transportiert 6RD die IPv6-Daten über Netzwerke, die ansonsten nur IPv4 sprechen. 6RD nutzt dabei jedoch nicht feste Präfixe (2002::/16 bei 6to4 gemäß RFC 3056 ) als Netzwerkkennung sondern frei wählbare wie etwa 2a01:0e00:::/26, die das RIPE zuordnet. 6to4 hat jedoch weitere Eigenschaften, die die Nutzung erschweren: So stellen 6to4-Gateways zwar sicher, dass ausgehenden IPv6-Pakete das IPv6-Internet und andere 6to4-Anschlüsse erreichen.

Allerdings lässt sich nicht garantieren, dass Pakete von echten IPv6-Adressen zu den 6to4-Tunnelendpunkte gelangen. Dazu müssten sie auf jeden Fall einen 6to4-Router durchqueren, was allerdings nicht sichergestellt ist. Weitere Probleme bereiten 6to4-Pakete, die nicht an die eigenen Tunnelendpunkte gerichtet sind. 6RD will diese Schwierigkeiten beheben.

Quelle : www.heise.de

[SiLæncer]

Mit dem soeben veröffentlichten RFC 6540 (Request for Comments) fordern die Autoren, dass IPv6 nicht länger als optional anzusehen sei. Der inzwischen erschöpfte IPv4-Adressraum und die Beschränkungen der Übergangstechniken wie NAT erfordern es, dass IPv6 eine notwendige Voraussetzung für Internet-taugliche Geräte und Software ist. Außerdem führe der in vielen Internet-Dokumenten verwendete Begriff "IP" (Internet Protocol) zunehmend zu Missverständnissen: Je nach Kontext bedeutet er dort IPv4 und IPv6, nur IPv6 oder nur IPv4.

Als Beispiel für solche unscharfen Beschreibungen nennen die RFC-Autoren das RFC 1812, das beispielsweise im Abschnitt 4.2 beschreibt, wie Netzwerkrouter IP unterstützen müssen. Um welche Protokollversion es sich dabei handelt, lässt sich dort nicht eindeutig ablesen. Daher werden auch heute noch Geräte besonders an Privatkunden verkauft, die zwar das Label "IP fähig" oder "Internet-tauglich" tragen, aber trotzdem kein IPv6 beherrschen. Gewinnt IPv6 allerdings weiter an Bedeutung, was zu erwarten ist, dürften solche Geräte jedoch kaum noch im Internet funktionieren. Theoretisch lässt sich das Problem zwar per Firmware-Update lösen, doch stellen bislang nur wenige Hersteller Aktualisierungen bereit.

Gerade dieser Umstand ist für Internet Service Provider ein großes Problem, da Netzbetreiber sehr oft keinen Zugriff auf die Endgeräte der Kunden hätten, schreiben die Autoren, die zum Teil beim Kabelnetzanbieter Time Warner tätig sind. Solche nur IPv4-tauglichen Geräte erschwerten die IPv6-Einführung erheblich, denn sie erfordern die umständlichen und teuren Übergangstechniken, beklagen sie die aktuelle Situation. "Je eher der Großteil der Geräte auch IPv6 beherrscht, umso schneller verlaufe die Umstellung."

Daher fordern die Autoren, dass neue Software und Geräte (Implementations) IPv6 unterstützen müssen, Aktualisierungen für bereits vorhandene Programme und Geräte sollten IPv6 nachrüsten. Hersteller sollten dabei den Fokus auf den parallelen Betrieb beider Protokollversionen legen (Dual-Stack) und die Qualität der IPv6-Unterstützung muss dabei wenigsten der des IPv4-Stacks entsprechen. Außerdem sollen Hersteller ermuntert werden, ihre Produkte für IPv6 fit zu machen.

Quelle : www.heise.de