1904 lines
64 KiB
XML
1904 lines
64 KiB
XML
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
The FreeBSD German Documentation Project
|
|
|
|
$FreeBSD$
|
|
$FreeBSDde: de-docproj/books/developers-handbook/ipv6/chapter.sgml,v 1.8 2010/12/15 19:03:49 bcr Exp $
|
|
basiert auf: 1.19
|
|
-->
|
|
|
|
<chapter id="ipv6">
|
|
<title>IPv6 Internals</title>
|
|
|
|
<sect1 id="ipv6-implementation">
|
|
<sect1info>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Yoshinobu</firstname>
|
|
<surname>Inoue</surname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
<!-- March 2000 -->
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Michelle</firstname>
|
|
<surname>Wechter</surname>
|
|
<contrib>Übersetzt von </contrib>
|
|
</author>
|
|
<author>
|
|
<firstname>Jürgen</firstname>
|
|
<surname>Dankoweit</surname>
|
|
</author>
|
|
</authorgroup>
|
|
</sect1info>
|
|
|
|
<title>IPv6/IPsec-Implementierung</title>
|
|
|
|
<para>Dieser Abschnitt erklärt die von der IPv6- und
|
|
IPsec-Implementierung abhängigen Internas. Die
|
|
Funktionalitäten wurden vom <ulink
|
|
url="http://www.kame.net/">KAME-Projekt</ulink>
|
|
abgeleitet</para>
|
|
|
|
<sect2 id="ipv6details">
|
|
<title>IPv6</title>
|
|
|
|
<sect3>
|
|
<title>Konformität</title>
|
|
|
|
<para>Die IPv6 abhängigen Funktionen richten sich nach,
|
|
oder versuchen sich nach den neuesten IPv6-Spezifikationen
|
|
zu richten. (<emphasis>Achtung</emphasis>: Dies ist keine
|
|
vollständige Liste - es wäre zu aufwändig,
|
|
diese zu pflegen...).</para>
|
|
|
|
<para>Für weitere Details beachten sie bitte die
|
|
entsprechenden Kapitel, RFCs, manual pages, oder Kommentare
|
|
in den Quelltexten.</para>
|
|
|
|
<para>Konformitätsprüfungen wurden basierend auf
|
|
KAME-STABLE-Kit des TAHI-Projekts durchgeführt. Die
|
|
Ergebnisse können unter <ulink
|
|
url="http://www.tahi.org/report/KAME/"></ulink> eingesehen
|
|
werden. In der Vergangenheit begleiteten wir auch Tests mit
|
|
unseren älteren "Snapshots" an der Univ. of New
|
|
Hampshire IOL (<ulink
|
|
url="http://www.iol.unh.edu/"></ulink>).</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>RFC1639: FTP Operation Over Big Address Records
|
|
(FOOBAR)</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>RFC2428 wird gegenüber RFC1639 bevorzugt.
|
|
FTP-Clients versuchen zuerst RFC2428, dann im
|
|
Fehlerfall RFC1639.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC1886: DNS Extensions to support IPv6</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC1933: Transition Mechanisms for IPv6 Hosts and
|
|
Routers</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>IPv4 kompatible Adressen werden nicht
|
|
unterstützt.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Automatisches Tunneln (beschrieben in 4.3 dieses
|
|
RFC) wird nicht unterstützt.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Die &man.gif.4;-Schnittstelle implementiert
|
|
einen IPv[46]-over-IPv[46] Tunnel in einer
|
|
allgemeinen Art und Weise und es umfaßt
|
|
"configured tunnel" wie in der Spezifikation
|
|
beschrieben. Siehe auch <link
|
|
linkend="gif">23.5.1.5</link> in diese Dokument
|
|
für weitere Details.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC1981: Path MTU Discovery for IPv6</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2080: RIPng for IPv6</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>usr.sbin/route6d unterstützt dies.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2292: Advanced Sockets API for IPv6</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Unterstützte Bibliotheksfunktionen bzw.
|
|
Kernel-APIs, siehe auch
|
|
<filename>sys/netinet6/ADVAPI</filename>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2362: Protocol Independent Multicast-Sparse
|
|
Mode (PIM-SM)</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>RFC2362 definiert Paketformate für PIM-SM.
|
|
<filename>draft-ietf-pim-ipv6-01.txt</filename>
|
|
wurde basierend auf diesem RFC verfaßt.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2373: IPv6 Addressing Architecture</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Unterstützt vom Knoten erforderliche
|
|
Adressen und richtet sich nach den Erfordernissen
|
|
des Bereichs.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2374: An IPv6 Aggregatable Global Unicast Address
|
|
Format</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Unterstützt die 64-Bit-Breite einer
|
|
Interface ID.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2375: IPv6 Multicast Address Assignments</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Userland-Applikationen nutzen die bekannten
|
|
Adressen, die in den RFC festgelegt sind.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2428: FTP Extensions for IPv6 and NATs</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>RFC2428 wird gegenüber RFC1639 bevorzugt.
|
|
FTP-Clients versuchen zuerst RFC2428, dann im
|
|
Fehlerfall RFC1639.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2460: IPv6 specification</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2461: Neighbor discovery for IPv6</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Siehe auch <link
|
|
linkend="neighbor-discovery">23.5.1.2</link> in
|
|
diesem Dokument für weitere Details.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2462: IPv6 Stateless Address
|
|
Autoconfiguration</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Siehe auch <link
|
|
linkend="ipv6-pnp">23.5.1.4</link> in diesem
|
|
Dokument für weitere Details.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2463: ICMPv6 for IPv6 specification</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Siehe auch <link
|
|
linkend="icmpv6">23.5.1.9</link> in diesem Dokument
|
|
für weitere Details.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2464: Transmission of IPv6 Packets over Ethernet
|
|
Networks</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2465: MIB for IPv6: Textual Conventions and
|
|
General Group</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Notwendige Statistiken werden vom Kernel
|
|
gesammelt. Die aktuelle
|
|
IPv6-MIB-Unterstützung wird als Patch-Sammlung
|
|
für ucd-snmp bereitgestellt.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2466: MIB for IPv6: ICMPv6 group</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Notwendige Statistiken werden vom Kernel
|
|
gesammelt. Die aktuelle IPv6-MIB-Unterstützung
|
|
wird als Patch-Sammlung für ucd-snmp
|
|
bereitgestellt.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2467: Transmission of IPv6 Packets over FDDI
|
|
Networks</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2497: Transmission of IPv6 packet over ARCnet
|
|
Networks</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2553: Basic Socket Interface Extensions for
|
|
IPv6</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>IPv4 mapped address (3.7) and special behavior
|
|
of IPv6 wildcard bind socket (3.8) are supported.
|
|
See <link
|
|
linkend="ipv6-wildcard-socket">23.5.1.12</link> in
|
|
this document for details.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2675: IPv6 Jumbogramms</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Siehe auch <link
|
|
linkend="ipv6-jumbo">23.5.1.7</link> in diesem
|
|
Dokument für weitere Details.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2710: Multicast Listener Discovery for
|
|
IPv6</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2711: IPv6 router alert option</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>draft-ietf-ipngwg-router-renum-08</filename>:
|
|
Router renumbering for IPv6</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>draft-ietf-ipngwg-icmp-namelookups-02</filename>:
|
|
IPv6 Name Lookups Through ICMP</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>draft-ietf-ipngwg-icmp-name-lookups-03</filename>:
|
|
IPv6 Name Lookups Through ICMP</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>draft-ietf-pim-ipv6-01.txt</filename>:
|
|
PIM for IPv6</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>&man.pim6dd.8; implementiert dense mode.
|
|
&man.pim6sd.8; implementiert sparse mode.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>draft-itojun-ipv6-tcp-to-anycast-00</filename>:
|
|
Unterbrechen einer TCP-Verbindung toward IPv6 anycast
|
|
address</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>draft-yamamoto-wideipv6-comm-model-00</filename></para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Beachte <link linkend="ipv6-sas">23.5.1.6</link>
|
|
in deisem Dokument für weitere Deatils.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>draft-ietf-ipngwg-scopedaddr-format-00.txt
|
|
</filename>: Eine Erweiterung des Format for IPv6 Scoped
|
|
Addresses</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect3>
|
|
|
|
<sect3 id="neighbor-discovery">
|
|
<title>Neighbor Discovery</title>
|
|
|
|
<para>Neighbor Discovery ist weitestgehend stabil. Zur Zeit
|
|
werden Addressauflösung, Duplicated Address Detection
|
|
(DAD), und Neighbor Unreachability Detection (NUD)
|
|
unterstützt. In der näheren Zukunft werden wir
|
|
Proxy Neighbor Advertisement Unterstützung in den
|
|
Kernel einbauen und Unsolicited Neighbor Advertisement
|
|
Übertragungskommandos als Verwaltungsprogramm zur
|
|
Verfügung stellen.</para>
|
|
|
|
<para>Falls DAD versagt, wird die Adresse als "duplicated"
|
|
markiert und eine Nachricht wird erzeugt, die an Syslog
|
|
gesandt wird (und für gewöhnlich an die Konsole).
|
|
Die "duplicated"-Markierung kann mit &man.ifconfig.8;
|
|
überprüft werden. Es liegt in der Verantwortung
|
|
des Administrators, auf DAD-Fehler zu achten und diese zu
|
|
beheben. Dieses Verhalten sollte in der näheren Zukunft
|
|
verbessert werden.</para>
|
|
|
|
<para>Manche Netzwerktreiber verbinden Multicast-Pakete mit
|
|
sich selbst, sogar, wenn es vorgeschrieben ist, es nicht zu
|
|
tun (vor allem im Promiscuous-Modus). In solchen Fällen
|
|
könnte DAD versagen, weil die DAD-Steuerung ein inbound
|
|
NS packet sieht (eigentlich vom Knoten selber) und
|
|
betrachtet es als ein Duplikat. Sie könnten sich die
|
|
#if-Bedingung ansehen, die in
|
|
sys/netinet6/nd6_nbr.c:nd6_dad_timer() als "Workaround" mit
|
|
"heuristics" markiert ist (Beachte, dass das Kodefragment im
|
|
Abschnitt "heuristics" nicht der Spezifikation
|
|
entspricht).</para>
|
|
|
|
<para>Neighbor Discovery specification (RFC2461)
|
|
kommuniziert in den folgenden Fällen nicht über
|
|
neighbor cache handling:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Der Knoten empfing ein unverlangtes
|
|
RS/NS/NA/redirect-Paket ohne Link-Layer-Adresse, wenn
|
|
kein neighbor cache-Eintrag vorhanden ist.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>neighbor cache handling bei Geräten ohne
|
|
Link-Layer-Adresse (wir benötigen einen neighbor
|
|
cache Eintrag für das IsRouter-Bit)</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Im ersten Fall implemenierten wir einen Workaround
|
|
basierend auf Diskussionen in der IETF-Ipngwg-Mailing-Liste.
|
|
Für weitere Details beachten Sie die Kommentare im
|
|
Quelltext und im Email-Thread, der bei (IPng 7155) mit dem
|
|
Datum vom 6. Feb 1999 gestartet wurde.</para>
|
|
|
|
<para>IPv6 on-link Erkennungsregel (RFC2461) ist recht
|
|
unterschiedlich zu Übernahmen im BSD-Netzwerkkode. Zur
|
|
Zeit wird keine on-link Erkennungsregel unterstützt,
|
|
bei der die Defaultrouter-Liste leer ist (RFC2461, Abschnitt
|
|
5.2, letzter Satz im zweiten Absatz - beachte, dass die
|
|
Spezifikation das Wort "host" und "Knoten" an mehreren
|
|
Stellen im Abschnitt mißbraucht).</para>
|
|
|
|
<para>Um mögliche DoS-Attacken und unendliche Schleifen
|
|
zu verhindern, werden bis jetzt nur 10 Optionen bei
|
|
ND-Paketen akzeptiert. Deshalb werden nur die ersten 10
|
|
Präfixe berücksichtigt, wenn man
|
|
20-Präfixoptionen zu RA hinzugefügt hat. Falls
|
|
das zu Schwierigkeiten führen sollte, dann sollte in
|
|
der FREEBSD-CURRENT-Mailing-Liste gefragt werden und/oder
|
|
die Variable nd6_maxndopt in
|
|
<filename>sys/netinet6/nd6.c</filename> modifizieren. Falls
|
|
die Nachfrage groß genug ist, könnte man einen
|
|
sysctl-Knopf für die Variable vorsehen.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="ipv6-scope-index">
|
|
<title>Bereichsindex</title>
|
|
|
|
<para>IPv6 benutzt Adressbereiche (Scoped Addresses).
|
|
Deshalb ist es sehr wichtig, mit einer IPv6-Adresse einen
|
|
Bereichsindex anzugeben (Schnittstellenindex für
|
|
link-local-Adresse, oder einen Lageindex für
|
|
site-local-Adressen). Ohne einen Bereichsindex ist ein
|
|
IPv6-Adressbereich für den Kernel zweideutig und dem
|
|
Kernel ist es nicht möglich, die Ausgabeschnittstelle
|
|
für ein Paket festzustellen.</para>
|
|
|
|
<para>Gewöhnliche Userland-Anwendungen sollten die
|
|
erweiterte Programmierschnittstelle (RFC2292) benutzen, um
|
|
den Bereichsindex oder Schnittstellenindex festzulegen.
|
|
Für ähnliche Zwecke wurde in RFC2553 sin6_scope_id
|
|
member in der sockaddr_in6-Struktur definiert. Wie auch
|
|
immer, die Semantik für sin6_scope_id ist ziemlich
|
|
wage. Wenn man auf Portierbarkeit der Anwendung
|
|
achten muß, dann schlagen wir vor, die erweiterte
|
|
Programmierschnittstelle anstelle von sin6_scope_id zu
|
|
benutzen.</para>
|
|
|
|
<para>Im Kernel ist ein Schnittstellenindex für
|
|
link-local scoped-Adressen in das zweite 16bit-Wort (drittes
|
|
und viertes Byte) der IPv6-Adresse eingebettet. Zum
|
|
Beispiel sieht man folgendes</para>
|
|
|
|
<screen> fe80:1::200:f8ff:fe01:6317</screen>
|
|
|
|
<para>in der Routing-Tabelle und in der
|
|
Schnittstellenadress-Struktur (structin6_ifaddr). Oben
|
|
genannte Adresse ist eine "link-local unicast address" die
|
|
zu einer Netzwerkschnittstelle gehört, deren
|
|
Schnittstellenbezeichner 1 (eins) ist. Der
|
|
eingebettete Index ermöglicht es, IPv6 link
|
|
local-Adressen über mehrere Schnittstellen hinweg
|
|
effektiv und mit wenig Änderungen am Kode zu
|
|
identifizieren.</para>
|
|
|
|
<para>Routing-Dämonen und Konfigurationsprogramme wie
|
|
&man.route6d.8; und &man.ifconfig.8; werden den
|
|
"eingebetteten" Bereichsindex verändern müssen.
|
|
Diese Programme benutzen routing sockets und ioctls (wie
|
|
SIOCGIFADDR_IN6) und die Kernel-Programmierschnittstelle
|
|
wird IPv6-Adressen, dessen zweites 16-Bit-Word gesetzt ist,
|
|
zurückgeben. Diese Programmierschnittstellen dienen
|
|
zur Änderung der Kernel-internen Struktur. Programme,
|
|
die diese Programmierschnittstellen benutzen, müssen
|
|
ohnehin auf Unterschiede in den Kerneln vorbereitet
|
|
sein.</para>
|
|
|
|
<para>Wenn man einen Adressbereich in der Kommandozeile
|
|
angibt, schreibt man niemals die eingebettete Form (so etwas
|
|
wie ff02:1::1 or fe80:2::fedc). Man erwartet nicht, dass es
|
|
funktioniert. Man benutzt immer die Standardform wie
|
|
ff02::1 oder fe80::fedc, zusammen mit der
|
|
Kommandozeilenoption, die die Schnittstelle festlegt (wie
|
|
<command>ping6 -I ne0 ff02::1</command>). Allgemein gilt,
|
|
wenn ein Kommando keine Kommandozeilenoption hat, um die
|
|
Ausgabeschnittstelle zu definieren, ist dieses Kommando noch
|
|
nicht für Adressbereiche bereit. Dies scheint der
|
|
Prämisse von IPv6 entgegenzustehen. Wir glauben, dass
|
|
die Spezifikationen einige Verbesserungen
|
|
benötigen.</para>
|
|
|
|
<para>Einige der Userland-Werkzeuge unterstützen die
|
|
erweiterte numerische IPv6-Syntax wie sie in
|
|
<filename>draft-ietf-ipngwg-scopedaddr-format-00.txt</filename>
|
|
beschrieben ist. Man kann die ausgehende Verbindung
|
|
angeben, indem man den Namen der ausgehenden Schnittstelle
|
|
wie folgt benutzt: "fe80::1%ne0". Auf diese Art und Weise
|
|
ist man in der Lage, eine link-local scoped Adresse ohne
|
|
viele Schwierigkeiten anzugeben.</para>
|
|
|
|
<para>Um die Erweiterungen im eigenen Programm zu nutzen,
|
|
muss man &man.getaddrinfo.3; und &man.getnameinfo.3; mit
|
|
NI_WITHSCOPEID verwenden. Die Implementierung setzt im
|
|
Moment eine 1-zu-1 Beziehung zwischen einer Verbindung und
|
|
einer Schnittstelle voraus, die stärker ist, als es die
|
|
Spezifikationen beschreiben.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="ipv6-pnp">
|
|
<title>Plug and Play</title>
|
|
|
|
<para>Der grösste Teil der statuslosen
|
|
IPv6-Adress-Autokonfiguration ist im Kernel implementiert.
|
|
Neighbor-Discovery-Funktionen sind als ganzes im Kernel
|
|
implementiert. Router-Advertisement (RA) Eingabe für
|
|
Hosts ist im Kernel implementiert. Router-Solicitation (RS)
|
|
Ausgabe für Hosts, RS-Eingabe für Router und
|
|
RA-Ausgabe für Router ist im Userland
|
|
implementiert.</para>
|
|
|
|
<sect4>
|
|
<title>Zuweisung von link-local und speziellen
|
|
Adressen</title>
|
|
|
|
<para>Die IPv6 link-local-Adresse wird aus einer
|
|
IEEE802-Adresse (Ethernet MAC address) erzeugt. Jeder
|
|
Schnittstelle wird automatisch eine IPv6
|
|
link-local-Adresse zugewiesen, sobald die Schnittstelle
|
|
aktiv ist (IFF_UP). Ebenso wird eine direkte Route
|
|
für die link-local-Adresse zur Routing-Tabelle
|
|
hinzugefügt.</para>
|
|
|
|
<para>Hier ist eine Ausgabe des netstat-Kommandos:</para>
|
|
|
|
<screen>Internet6:
|
|
Destination Gateway Flags Netif Expire
|
|
fe80:1::%ed0/64 link#1 UC ed0
|
|
fe80:2::%ep0/64 link#2 UC ep0</screen>
|
|
|
|
<para>Schnittstellen, die keine IEEE802-Adresse haben
|
|
(Pseudo-Schnittstellen wie Tunnel-Schnittstellen oder
|
|
ppp-Schnittstellen), borgen sich eine IEEE802-Adresse von
|
|
anderen Schnittstellen wie Ethernet-Schnittstellen aus,
|
|
wann immer das möglich ist. Wenn keine
|
|
IEEE802-Geräte eingebaut sind, wird als letzte
|
|
Möglichkeit eine Pseudo-Zufallszahl - MD5(hostname) -
|
|
als Quelle für eine link-local-Adresse benutzt.
|
|
Falls diese für den Einsatz nicht geeignet sein
|
|
sollte, dann muss man eine link-local-Adresse manuell
|
|
konfigurieren.</para>
|
|
|
|
<para>Falls eine Schnittstelle nicht imstande ist,
|
|
IPv6-Adressen zu handhaben (wie fehlende
|
|
Unterstützung des multicast), wird keine
|
|
link-local-Adresse der Schnittstelle zugewiesen. Siehe
|
|
Abschnitt 2 für weitere Details.</para>
|
|
|
|
<para>Jede Schnittstelle verbindet die solicited multicast
|
|
Adresse und link-local all-nodes multicast-Adressen (z.B.
|
|
fe80::1:ff01:6317 und ff02::1, jeweils zu der Verbindung,
|
|
an die die Schnittstelle verbunden ist). zusätzlich
|
|
zu einer link-local-Adresse wird eine loopback-Adresse
|
|
(::1) einer loopback-Schnittstelle zugewiesen.
|
|
Außerdem werden ::1/128 und ff01::/32 automatisch
|
|
zur Routing-Tabelle hinzugefügt und die
|
|
loopback-Schnittstelle verbindet sich mit der node-local
|
|
multicast Gruppe ff01::1.</para>
|
|
</sect4>
|
|
|
|
<sect4>
|
|
<title>Stateless address autoconfiguration beim Host</title>
|
|
|
|
<para>In der IPv6-Spezifikation werden Knoten in zwei
|
|
Kategorien unterteilt: <emphasis>Router</emphasis> und
|
|
<emphasis>Hosts</emphasis>. Router leiten Pakete, die an
|
|
andere adressiert sind, weiter, Hosts leiten Pakete nicht
|
|
weiter. net.inet6.ip6.forwarding definiert, ob dieser
|
|
Knoten ein Router oder ein Host ist (Router falls es 1
|
|
ist, Host, falls es 0 ist).</para>
|
|
|
|
<para>Sobald ein Host ein Router-Advertisement vom Router
|
|
hört, kann er sich selbst mit statusloser
|
|
automatischer Adressen konfigurieren. Dieses Verhalten
|
|
kann mit net.inet6.ip6.accept_rtadv (der Host konfiguriert
|
|
sich selber, wenn es auf 1 gesetzt ist) beeinflusst
|
|
werden. Bei einer automatischen Konfiguration wird das
|
|
Netzwerkadresspräfix für die empfangende
|
|
Schnittstelle (für gewöhnlich das globale
|
|
Adresspräfix) hinzugefügt. Die Standard-Route
|
|
wird ebenso konfiguriert. Router erzeugen periodisch
|
|
Router-Advertisement-Pakete. Um einen benachbarten Router
|
|
aufzufordern, ein RA-Paket zu erzeugen, kann eine
|
|
Host-Router-Solicitation übertragen werden. Um
|
|
jederzeit ein RS-Paket zu erzeugen, benutzt man das
|
|
<emphasis>rtsol</emphasis>-Kommando. Ein
|
|
&man.rtsold.8;-Dämon ist ebenso verfügbar.
|
|
&man.rtsold.8; erzeugt Router-Solicitation, wann immer es
|
|
notwendig ist und es funktioniert großartig "bei
|
|
normadischem Einsatz" (Notebooks/Laptops). Falls jemand
|
|
Router-Advertisements zu ignorieren wünscht, setzt man
|
|
mit sysctl et.inet6.ip6.accept_rtadv auf 0.</para>
|
|
|
|
<para>Um Router-Advertisement von einem Router aus zu
|
|
erzeugen, benutzt man den
|
|
&man.rtadvd.8;-Dämon.</para>
|
|
|
|
<para>Beachte, dass die IPv6-Spezifikation von folgenden
|
|
Punkte ausgeht und nicht konforme Fälle werden als
|
|
nicht spezifiziert ausgelassen:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Nur Hosts hören auf Router-Angebote</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Hosts haben eine einzige Netzwerk-Schnittstelle
|
|
(außer loopback)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Deshalb ist es unklug, net.inet6.ip6.accept_rtadv
|
|
bei Routern oder bei Hosts mit mehreren Schnittstellen
|
|
einzuschalten. Ein falsch konfigurierter Knoten kann sich
|
|
seltsam verhalten (nicht konforme Konfiguration ist
|
|
für diejenigen erlaubt, die Experimente
|
|
durchführen möchten).</para>
|
|
|
|
<para>Eine Zusammenfassung des sysctl-Angaben:</para>
|
|
|
|
<screen> accept_rtadv forwarding Rolle des Knotens
|
|
--- --- ---
|
|
0 0 Host (wird manuell konfiguriert)
|
|
0 1 Router
|
|
1 0 automatisch konfigurierter Host
|
|
(Die Spezifikation setzt voraus, dass der Host nur eine einzelne Schnittstelle hat, ein automatisch konfigurierter Host mit mehreren Schnittstellen ist außerhalb der Betrachtung)
|
|
1 1 ungültig, oder für Experimentierzwecke (außerhalb der Spezifikation)</screen>
|
|
|
|
<para>RFC2462 hat eine Überprüfungsregel gegen
|
|
eingehende RA-prefix-information-option, in 5.5.3 (e).
|
|
Dies dient zum Schutz des Hosts vor schlecht oder falsch
|
|
konfigurierten Routern, die eine sehr kurze
|
|
Präfixlebenszeit ankündigen. Es gab
|
|
Aktualisierungen von Jim Bound in der ipngwg-Mailing-Liste
|
|
(suche nach "(ipng 6712)" im Archive) und es wurde Jims
|
|
Aktualisierung implementiert.</para>
|
|
|
|
<para>Siehe auch <link
|
|
linkend="neighbor-discovery">23.5.1.2</link> im Dokument
|
|
für das Verhältnis zwischen DAD und
|
|
autoconfiguration.</para>
|
|
</sect4>
|
|
</sect3>
|
|
|
|
<sect3 id="gif">
|
|
<title>Generische Tunnel-Schnittstelle</title>
|
|
|
|
<para>GIF (Generische Schnittstelle) ist eine
|
|
Pseudoschnittstelle für konfigurierte Tunnel. Details
|
|
sind in &man.gif.4; beschrieben. Im Moment sind</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>v6 in v6</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>v6 in v4</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>v4 in v6</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>v4 in v4</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>verfügbar. Benutze &man.gifconfig.8;, um die
|
|
physikalische (außerhalb liegende) Quelle und die
|
|
Zieladresse den gif-Schnittstellen zuzuweisen. Eine
|
|
Konfiguration, die die selbe Adressfamilie für innere und
|
|
äußere IP-Header (v4 in v4, oder v6 in v6) benutzt, ist
|
|
gefährlich. Es ist sehr leicht, Schnittstellen und
|
|
Routing-Tabellen so zu konfigurieren, dass eine unendliche
|
|
Ebene von Tunneln ausgeführt wird. <emphasis>Seien Sie
|
|
also gewarnt</emphasis>.</para>
|
|
|
|
<para>gif kann ECN-freundlich konfiguriert werden. Beachte
|
|
<link linkend="ipsec-ecn">23.5.4.5</link> für eine
|
|
ECN-Freundlichkeit von Tunneln und &man.gif.4; wie man sie
|
|
konfiguriert.</para>
|
|
|
|
<para>Falls man einen IPv4-in-IPv6-Tunnel mit einer
|
|
gif-Schnittstelle konfigurieren möchte, sollte man
|
|
&man.gif.4; sorgfältig lesen. Man muss die IPv6
|
|
link-local Adresse, die automatisch der gif-Schnittstelle
|
|
zugewiesen wird, entfernen.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="ipv6-sas">
|
|
<title>Source Address Selection</title>
|
|
|
|
<para>Im Moment ist die Regel zur Auswahl der Quelle
|
|
bereichsorientiert (es gibt einige Ausnahmen - siehe unten).
|
|
Für ein gegebenes Ziel wird eine Quell-IPv6-Adresse
|
|
durch folgende Regel ausgewählt:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Falls die Quelladresse explizit durch den Benutzer
|
|
angegeben ist (z.B. über das erweiterte API), dann
|
|
wird die angegebene Adresse benutzt.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Falls eine Adresse der ausgehenden Schnittstelle
|
|
zugewiesen wird, die den selben Bereich wie die
|
|
Zieladresse hat (was normalerweise durch einen Blick in
|
|
die Routing-Tabelle festgestellt werden kann), dann wird
|
|
diese Adresse benutzt.</para>
|
|
|
|
<para>Dies ist ein typischer Fall.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Falls keine Adresse der obigen Bedingung
|
|
genügt, dann wählt man eine globale Adresse,
|
|
die einer der Schnittstellen des sendenden Knotens
|
|
zugewiesen ist.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Falls keine Adresse der obigen Bedingung
|
|
genügt und die Zieladresse ist im site
|
|
local-Bereich, dann wählt man eine eine site
|
|
local-Adresse, die einer der Schnittstellen des
|
|
sendenden Knotens zugewiesen ist.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Falls keine Adresse der obigen Bedingung
|
|
genügt, dann wählt man eine Adresse, die mit
|
|
einem Eintrag in der Routing-Tabelle für das Ziel
|
|
verbunden ist. Dies ist die letzte Möglichkeit,
|
|
die eine Bereichsverletzung verursachen
|
|
könnte.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Zum Beispiel, ::1 ist ausgewählt für
|
|
ff01::1, fe80:1::200:f8ff:fe01:6317 für
|
|
fe80:1::2a0:24ff:feab:839b (beachte den eingebetteten
|
|
Schnittstelleindex - beschrieben in <link
|
|
linkend="ipv6-scope-index">23.5.1.3</link> - er hilft uns,
|
|
die richtige Quelladresse auszuwählen. Diese
|
|
eingebetteten Indexe werden nicht übertragen). Falls
|
|
die ausgehende Schnittstelle mehrere Adressen für einen
|
|
Bereich hat, wird die Quelle gewählt, die die breiteste
|
|
passende Basis hat (Regel 3). Angenommen
|
|
2001:0DB8:808:1:200:f8ff:fe01:6317 und
|
|
2001:0DB8:9:124:200:f8ff:fe01:6317 sind einer ausgehenden
|
|
Schnittstelle zugewiesen.
|
|
2001:0DB8:808:1:200:f8ff:fe01:6317 wird als Quelle für
|
|
das Ziel 2001:0DB8:800::1 ausgewählt.</para>
|
|
|
|
<para>Beachte, dass obige Regel nicht in der
|
|
IPv6-Spezifikation dokumentiert ist. Es wird als "up to
|
|
implementation"-Punkt betrachtet. Es gibt einige Fälle,
|
|
bei denen die obige Regel nicht benutzt werden soll. Ein
|
|
Beispiel ist die verbundene TCP-Sitzung und man benutzt die
|
|
Adresse, die in tcb als Quelle gehalten wird. Ein anderes
|
|
Beispiel ist die Quelladresse für Neighbor
|
|
Advertisement. Laut Spezifikation (RFC2461 7.2.2) sollte
|
|
die Quelle des NA die Zieladresse des korrespondierenden
|
|
Ziel des NS sein. In diesem Fall folgen wir eher der
|
|
Spezifikation, als der obigen longest-match-Regel.</para>
|
|
|
|
<para>Für neue Verbindungen werden (wenn Regel eins
|
|
nicht zutrifft) abgelehnte Adressen (Adressen mit
|
|
bevorzugter Lebenszeit = 0) nicht ausgewählt, wenn
|
|
andere Auswahlmöglichkeiten bestehen. Wenn keine
|
|
anderen Auswahlmöglichkeiten bestehen, werden
|
|
abgelehnte Adressen als letzte Möglichkeit benutzt.
|
|
Falls mehrere Auswahlmöglichkeiten für abgelehnte
|
|
Adressen bestehen, dann wird ogige Regel verwendet, um aus
|
|
diesen abgelehnten Adressen auszuwählen. Falls man aus
|
|
bestimmten Gründen die Benutzung abgelehnter Adressen
|
|
unterbinden möchte, dann setzt man
|
|
net.inet6.ip6.use_deprecated auf 0. Der Punkt
|
|
bezüglich der abgelehnten Adressen ist in RFC2462 5.5.4
|
|
beschrieben (Beachte: Im Moment wird in der IETF ipngwg
|
|
darüber debatiert, wie angelehnte Adressen benutzt
|
|
werden sollen).</para>
|
|
</sect3>
|
|
|
|
<sect3 id="ipv6-jumbo">
|
|
<title>Jumbo Payload</title>
|
|
|
|
<para>Die Jumbo-Payload hop-by-hop-Option ist implementiert
|
|
und kann benutzt werden, um IPv6-Pakete mit Datenpaketen
|
|
größer als 65.535 Oktette. Aber im Moment wird
|
|
keine physikalische Schnittstelle unterstützt, deren MTU
|
|
größer ist als 65.536, so dass diese Datenpakete
|
|
nur bei den loopback-Schnittstellen zu finden sind (z.B.
|
|
lo0).</para>
|
|
|
|
<para>Falls man die Jumbo Payloads testen möchte, muss
|
|
man zunächst den Kernel rekonfigurieren, so dass die
|
|
MTU der loopback-Schnittstelle grösser 65.535 Bytes
|
|
sein kann. Füge folgende Zeile zur Kernel-Konfiguration
|
|
hinzu:</para>
|
|
|
|
<para><literal>
|
|
options "LARGE_LOMTU" #Um Jumbo Payload zu testen
|
|
</literal></para>
|
|
|
|
<para>und dann kompiliere den Kernel neu.</para>
|
|
|
|
<para>Dann kann man die Jumbo-Payloads mittels
|
|
&man.ping6.8;-Kommando mit den Optionen -b und -s testen.
|
|
Die Option -b muss angegeben werden, um die Größe
|
|
des Socket-Puffers zu erhön, und die Option -s gibt die
|
|
Größe des Pakets an, die größer als
|
|
65.535 sein sollte. Beispielsweise gibt man folgendes
|
|
ein:</para>
|
|
|
|
<screen>&prompt.user; <userinput>ping6 -b 70000 -s 68000 ::1</userinput></screen>
|
|
|
|
<para>Die IPv6-Spezifikation verlangt, dass die
|
|
Jumbo-Payload-Option nicht in einem Paket verwendet werden
|
|
darf, das einen fragmentierten Header hat. Falls diese
|
|
Bedingung nicht zutrifft, dann muss eine
|
|
ICMPv6-Parameter-Problem-Nachricht an den Absender
|
|
geschickt werden. Die Spezifikation ist befolgt, aber man
|
|
kann normalerweise nicht einen ICMPv6-Fehler sehen, der
|
|
durch diese Forderung hervorgerufen wird.</para>
|
|
|
|
<para>Wenn ein IPv6-Paket empfangen wird, dann wird die
|
|
Rahmenlänge geprüft und sie wird mit der
|
|
Größe verglichen, die im Datenfeld für die
|
|
Paketgröße des IPv6-Headers oder im Wert für
|
|
die Jumbo-Payload-Option angegeben ist, sofern vorhanden.
|
|
Falls ersterer kleiner als letzterer ist, dann wird das
|
|
Paket abgelehnt und die Statistiken werden erhöht. Man
|
|
kann die Statistik als Ausgabe des &man.netstat.8;-Kommandos
|
|
mit der `-s -p ip6'-Option sehen:</para>
|
|
|
|
<screen>&prompt.user; <userinput>netstat -s -p ip6</userinput>
|
|
ip6:
|
|
(snip)
|
|
1 with data size < data length</screen>
|
|
|
|
<para>So, der Kernel sendet keinen ICMPv6-Fehler,
|
|
außer das fehlerhafte Paket ist ein aktuelles
|
|
Jumbo-Payload, dessen Paketgröße
|
|
größer als 65,535 Bytes ist. Wie oben
|
|
beschrieben, gibt es momentan keine physikalische
|
|
Schnittstelle, die eine so riesige MTU unterstützt,
|
|
daher gibt es so selten einen ICMPv6-Fehler.</para>
|
|
|
|
<para>TCP/UDP over Jumbogramm wird im Moment nicht
|
|
unterstützt. Dies kommt daher, weil wir kein Medium
|
|
(außer loopback) haben, dies zu testen. Melden Sie
|
|
sich, falls Sie es benötigen.</para>
|
|
|
|
<para>IPsec funktioniert nicht mit Jumbogramm. Dies ist
|
|
bedingt durch einige Änderungen an der Spezifikation,
|
|
welche die Unterstützung von AH mit Jumbogramm
|
|
betrifft (AH-Header-Größe beeinflusst die
|
|
Länge des Datenpakets und das macht es richtig
|
|
schwierig, ein eingehendes Paket mit Jumbo-Payload-Option so
|
|
gut zu authentifizieren wie ein AH).</para>
|
|
|
|
<para>Es gibt grundlegende Punkte in der
|
|
*BSD-Unterstützung für Jumbogramms. Wir
|
|
würden jene gerne ansprechen, aber wir benötigen
|
|
mehr Zeit diese fertig zu stellen. Um ein paar zu
|
|
benennen:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>mbuf pkthdr.len-Feld ist in 4.4BSD typisiert als
|
|
"int", so dass es kein Jumbogramm mit len > 2G bei
|
|
32Bit-Architekturen aufnehmen kann. Wenn wir
|
|
Jumbogramme geeignet unterstützen wollten, dann
|
|
muss das Feld erweitert werden, damit es 4G +
|
|
IPv6-Header + link-layer-Header aufnehmen kann. Deshalb
|
|
muss es schließlich auf int64_t (u_int32_t ist
|
|
NICHT genug) erweitert werden.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Irrigerweise benutzen wir "int" an vielen Stellen,
|
|
um die Paketlänge aufzunehmen. Wir müssen sie
|
|
in einen größeren ganzzahligen Typ
|
|
konvertieren. Es braucht große Vorsicht, weil wir
|
|
sonst einen Überlauf während der Berechnung
|
|
der Paketlänge erleben können.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Irrigerweise prüfen wir das ip6_plen-Feld des
|
|
IPv6-Header für packet payload length an
|
|
verschiedenen Stellen. Wir sollten mbuf pkthdr.len
|
|
stattdessen prüfen. ip6_input() wird bei der
|
|
Eingabe eine Prüfung der Jumbo -Payload-Option
|
|
durchführen und wir können danach mbuf
|
|
pkthdr.len sicher benutzen.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Natürlich braucht der TCP-Kode an einigen
|
|
Stellen eine sorgfältige Aktualisierung.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Verhindern von Schleifen beim Verarbeiten von
|
|
Headern</title>
|
|
|
|
<para>Die IPv6-Spezifikation erlaubt eine willkürliche
|
|
Zahl von Erweiterungs-Headern, die in einem Paket platziert
|
|
werden können. Wenn wir IPv6-Kode für die
|
|
Paketverarbeitung auf die Art und Weise implementieren wie
|
|
wir es beim BSD-IPv4-Kode geschehen ist, dann würde
|
|
wegen einer lange Kette von Funktionsaufrufen der
|
|
Kernel-Stack überlaufen. sys/netinet6-Kode ist
|
|
behutsam entwickelt wurden, um einen Überlauf des
|
|
Kernel-Stacks zu verhindern. Deswegen definiert der
|
|
sys/netinet6-Kode seine eigene Protocol-Switch-Struktur
|
|
"struct ip6protosw" (siehe auch
|
|
<filename>netinet6/ip6protosw.h</filename>). Aus
|
|
Gründen der Kompatibilität gibt es keine solche
|
|
Aktualisierung im IPv4-Teil (sys/netinet), aber eine kleine
|
|
Änderung ist zum pr_input()-Prototyp hinzugefügt
|
|
worden. So ist "struct ipprotosw" ebenso definiert.
|
|
Deswegen kann der Kernel-Stack sich aufblähen, wenn man
|
|
ein IPsec-over-IPv4-Paket mit einer massiven Zahl von
|
|
IPSec-Header empfängt. IPsec-over-IPv6 ist in Ordnung.
|
|
(Natürlich muss für all diese zu verarbeitenden
|
|
IPSec-Header jeder einzelne IPSec-Header jede
|
|
IPSec-Prüfung durchlaufen. So wird es einem anonymen
|
|
Angreifer unmöglich gemacht eine Attacke
|
|
durchzuführen.)</para>
|
|
</sect3>
|
|
|
|
<sect3 id="icmpv6">
|
|
<title>ICMPv6</title>
|
|
|
|
<para>Nachdem RFC2463 veröffentlicht worden war, hat
|
|
die IETF-ipngwg beschlossen ICMPv6-Fehler-Pakete gegen
|
|
ICMPv6 umzuleiten, um einen ICMPv6-Sturm auf einem
|
|
Netzwerkmedium zu unterbinden. Dies ist bereits im Kernel
|
|
implementiert.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Anwendungen</title>
|
|
|
|
<para>Für Programmierung des Userland unterstützen
|
|
wir das IPv6-Socket-API wie es in RFC2553, RFC2292 und in
|
|
aufkommenden Internet-Konzepten beschrieben ist.</para>
|
|
|
|
<para>TCP/UDP über IPv6 ist verfügbar und ziemlich
|
|
stabil. Man kann sich an &man.telnet.1;, &man.ftp.1;,
|
|
&man.rlogin.1;, &man.rsh.1;, &man.ssh.1;, usw. erfreuen.
|
|
Diese Anwendungen sind unabhängig vom Protokoll. Das
|
|
liegt daran, weil diese Programme automatisch IPv4 oder IPv6
|
|
entsprechend des DNS auswählen.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Kernel Interna</title>
|
|
|
|
<para>Während ip_forward() ip_output() aufruft, ruft
|
|
ip6_forward() direkt if_output() auf, da Router IPv6-Pakete
|
|
nicht in Fragmente teilen dürfen.</para>
|
|
|
|
<para>ICMPv6 sollte das original Paket so lang wie
|
|
möglich bis maximal 1280 halten. UDP6/IP6 port
|
|
unreach, zum Beispiel, sollte alle Erweiterungs-Header und
|
|
die unveränderten UDP6- und IP6-Header enthalten. Um
|
|
das originale Paket zu erhalten, konvertieren alle
|
|
IP6-Funktionen außer TCP niemals Network-Byte-Order in
|
|
Host-Byte-Order.</para>
|
|
|
|
<para>tcp_input(), udp6_input() und icmp6_input()
|
|
können nicht voraussetzen, dass der IP6-Header vor dem
|
|
Transport-Header, der zum Extension-Header gehört,
|
|
kommt. Deshalb wurde in6_cksum() implementiert, um Pakete,
|
|
deren IP6-Header und Transport-Header nicht fortlaufend ist,
|
|
zu behandeln. Weder TCP/IP6- noch
|
|
UDP6/IP6-Header-Strukturen existieren, um eine Prüsumme
|
|
zu bilden.</para>
|
|
|
|
<para>Um IP6-Header, Extension-Header und Transport-Headers
|
|
leichter verarbeiten zu können, werden nun
|
|
Netzwerktreiber benötigt, die Pakete in einem internen
|
|
mbuf oder in einem oder mehreren externen mbuf speichern
|
|
können. Ein typischer alter Treiber legt zwei interne
|
|
mbuf für 96 - 204 Bytes an Daten an, wie auch immer
|
|
wird ein solches Paket jetzt in einem externen mbuf
|
|
gespeichert.</para>
|
|
|
|
<para><command>netstat -s -p ip6</command> ermittelt, ob der
|
|
Treiber sich nach solchen Erfordernissen richtet, oder
|
|
nicht. Im folgenden Beispiel verletzt "cce0" dies
|
|
Erfordernisse (Für weitere Informationen, siehe
|
|
Abschnitt 2.).</para>
|
|
|
|
<screen>Mbuf statistics:
|
|
317 one mbuf
|
|
two or more mbuf::
|
|
lo0 = 8
|
|
cce0 = 10
|
|
3282 one ext mbuf
|
|
0 two or more ext mbuf</screen>
|
|
|
|
<para>Jede Eingabefunktion ruft IP6_EXTHDR_CHECK am Anfang
|
|
auf, um zu prüfen, ob der Bereich zwischen IP6 und
|
|
seinen Header durchgehend ist. IP6_EXTHDR_CHECK ruft
|
|
m_pullup() nur dann auf, wenn mbuf das M_LOOP-Flag gestzt
|
|
hat, weil das Paket von der Loopback-Schnittstelle kommt.
|
|
m_pullup() wird niemals aufgerufen, wenn Pakete von
|
|
physikalischen Netzwerkschnittstellen kommen.</para>
|
|
|
|
<para>IP- und IP6-Reassemble-Funktionen rufen niemals
|
|
m_pullup() auf.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="ipv6-wildcard-socket">
|
|
<title>IPv4-Mapped-Address und IPv6-Wildcard-Socket</title>
|
|
|
|
<para>RFC2553 beschreibt IPv4-Mapped-Address (3.7) und die
|
|
spezielle Verhaltensweise des IPv6-Wildcard-Bind-Socket
|
|
(3.8). Die Spezifikation gestattet es:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>IPv4-Verbindungen von AF_INET6-Wildcard-Bind-Socket
|
|
zu erlauben.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>IPv4-Pakete über AF_INET6-Socket zu
|
|
transportieren, indem eine spezielle Form der Adresse
|
|
wie ::ffff:10.1.1.1 benutzt wird.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Aber die Spezifikation ist sehr kompliziert und
|
|
spezifiziert nicht, wie der Socket-Layer sich verhalten
|
|
soll. Darauf Bezug nehmend nennen wir hier ersteren
|
|
"hörende Seite" und letzteren "beginnende
|
|
Seite".</para>
|
|
|
|
<para>Man kann einen Wildcard-Bind auf demselben Port bei
|
|
beiden Adressfamilien durchführen.</para>
|
|
|
|
<para>Die folgende Tabelle zeigt das Verhalten von FreeBSD
|
|
4.x.</para>
|
|
|
|
<screen>Hörende Seite Beginnende Seite
|
|
(AF_INET6-Wildcard- (Verbindung zu ::ffff:10.1.1.1)
|
|
Socket erreicht IPv4 Verb.)
|
|
--- ---
|
|
FreeBSD 4.x Konfigurierbar unterstützt
|
|
Standard: erlaubt</screen>
|
|
|
|
<para>Die folgende Abschnitte zeigen mehr Details und wie
|
|
man das Verhalten konfigurieren kann.</para>
|
|
|
|
<para>Kommentare auf der hörenden Seite:</para>
|
|
|
|
<para>Es sieht so aus, dass RFC2553 zu wenig zu den Punkten
|
|
über Wildcard-Bind erläutert, speziell zum
|
|
Punkt über Port-Space, Fehler-Modus und Beziehung
|
|
zwischen AF_INET/INET6 wildcard bind. Es kann mehrere
|
|
unterschiedliche Interpretationen zu diesem RFC geben, die
|
|
sich nach diesen richten, aber sich unterschiedlich
|
|
verhalten. Um eine portable Anwendung zu implementieren,
|
|
sollte man deshalb nicht ein bestimmtes Verhalten des
|
|
Kernels voraussetzen. Der Einsatz von &man.getaddrinfo.3;
|
|
ist der sicherste Weg. Port number space und wildcard bind
|
|
issues wurden Mitte Mai 1999 detailliert in der
|
|
Ipv6imp-Mailing-Liste diskutiert und es sieht so aus, als ob
|
|
es keinen konkreten Konsens gab (means, up to implementers).
|
|
Vielleicht sollte man die Archive der Mailing-Liste
|
|
prüfen.</para>
|
|
|
|
<para>Wenn eine Server-Anwendung IPv4- und IPv6-Verbindungen
|
|
annehmen möchte, dann gibt es zwei Alternativen.</para>
|
|
|
|
<para>Eine benutzt AF_INET- und AF_INET6-Socket (man
|
|
benötigt zwei Sockets). Benutze &man.getaddrinfo.3;
|
|
mit gesetztem AI_PASSIVE-Bit in ai_flags, &man.socket.2; und
|
|
&man.bind.2; für alle zurückgegebenen Adressen.
|
|
Mit dem öffnen mehrerer Sockets kann man Verbindungen
|
|
an dem Socket mit der richtigen Adressfamilie annehmen.
|
|
IPv4-Verbindungen werden vom AF_INET-Socket und
|
|
IPv6-Verbindungen vom AF_INET6-Socket angenommen.</para>
|
|
|
|
<para>Ein anderer Weg ist einen AF_INET6 wildcard
|
|
bind-Socket zu verwenden. Man benutzt &man.getaddrinfo.3;
|
|
mit AI_PASSIVE in ai_flags, mit AF_INET6 in ai_family, man
|
|
setzt das erste Argument hostname auf NULL, &man.socket.2;
|
|
und &man.bind.2; auf die zurückgegebene Adresse (es
|
|
sollte eine unspezifizierte IPv6-Adresse sein). Man kann
|
|
IPv4- und IPv6-Paket über diesen Socket
|
|
annehmen.</para>
|
|
|
|
<para>Um nur IPv6-Datenverkehr portabel an AF_INET6 wildcard
|
|
gebundenen Socket zu unterstützen, prüft man,
|
|
sobald die Verbindung Zustande gekommen ist, immer die
|
|
Peer-Adresse gegen den hörenden AF_INET6-Socket. Wenn
|
|
die Adresse eine IPv4-Mapped-Adresse ist, dann sollte man
|
|
die Verbindung zurückweisen. Man kann die Bedingung
|
|
mit dem IN6_IS_ADDR_V4MAPPED()-Makro prüfen.</para>
|
|
|
|
<para>Um diesen Punkt leichter lösen zu können,
|
|
gibt es für &man.setsockopt.2; die System
|
|
abhängige Option IPV6_BINDV6ONLY, die wie folgt benutzt
|
|
wird.</para>
|
|
|
|
<screen> int on;
|
|
|
|
setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY,
|
|
(char *)&on, sizeof (on)) < 0));</screen>
|
|
|
|
<para>Wenn der Aufruf erfolgreich ist, dann empfängt
|
|
dieser Socket nur IPv6-Pakete.</para>
|
|
|
|
<para>Kommentare zur sendenden Seite:</para>
|
|
|
|
<para>Ratschlag an Anwendungsentwickler: um eine portable
|
|
IPv6-Anwendung zu implementieren (die mit verschiedenen
|
|
IPv6-Kerneln funktioniert), ist das Folgende der
|
|
Schlüssel zum Erfolg wie wir glauben:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>NIEMALS AF_INET oder AF_INET6 hart kodieren.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Benutze &man.getaddrinfo.3; und
|
|
&man.getnameinfo.3; überall im System. Benutze
|
|
niemals gethostby*(), getaddrby*(), inet_*() oder
|
|
getipnodeby*() (Um bestehende Applikationen leicht IPv6
|
|
fähig zu machen, wird getipnodeby*() manchmal
|
|
nützlich sein. Falss es aber möglich sein
|
|
sollte, versuche den Kode neu zu schreiben und
|
|
&man.getaddrinfo.3; und &man.getnameinfo.3; zu
|
|
benutzen)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Wenn man sich an ein Ziel verbinden möchte,
|
|
benutze &man.getaddrinfo.3; und versuche alle
|
|
zurückgegebenen Ziele, wie &man.telnet.1; es
|
|
macht.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Einige IPv6-Stacks sind mit fehlerhafter
|
|
&man.getaddrinfo.3; verschickt worden. Man verschickt
|
|
als letzte Möglichkeit eine minimal arbeitende
|
|
Version der Anwendung.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Wenn man einen AF_INET6-Socket für jeweils eine
|
|
ausgehende IPv4- und IPv6-Verbingung benutzen möchte,
|
|
dann muss man &man.getipnodebyname.3; benutzen. Wenn man
|
|
seine existierende Anwendung mit wenig Aufwand
|
|
IPv6-fähig machen möchte, dann sollte dieser
|
|
Versuch gewählt werden. Aber beachte bitte, dass dies
|
|
eine temporäre Lösung ist, weil
|
|
&man.getipnodebyname.3; selber noch zu empfehlen ist, da es
|
|
noch keine Adressbereiche verarbeitet. Für eine
|
|
IPv6-NAmensauflösung ist &man.getaddrinfo.3; das
|
|
bevorzugte API. Deshalb sollte man seine Anwendung so
|
|
umschreiben, dass &man.getaddrinfo.3; benutzt wird, wann man
|
|
Zeit dazu hat.</para>
|
|
|
|
<para>Wenn man Anwendungen schreibt, die ausgehende
|
|
Verbindungen herstellen, wird die Geschichte viel einfacher,
|
|
wenn man AF_INET und AF_INET6 als total getrennte
|
|
Adressfamilien behandelt. {set,get}sockopt funktioniert
|
|
viel einfacher, DNS-Angelegenheiten werden einfacher
|
|
gemacht. Wir empfehlen sich nicht auf IPv4-Mapped-Adressen
|
|
zu verlassen.</para>
|
|
|
|
<sect4>
|
|
<title>Einheitlicher TCP-und INPCB-Kode</title>
|
|
|
|
<para>FreeBSD 4.x benutzt shared TCP-Kode zwischen IPv4
|
|
und IPv6 (von sys/netinet/tcp*) und separaten udp4/6-Kode.
|
|
Es benutzt eine vereinheitlichte inpcb-Struktur.</para>
|
|
|
|
<para>Die Plattform kann für eine Unterstützung
|
|
von IPv4-mapped-Adressen konfiguriert werden. Die
|
|
Kernel-Konfiguration läßt sich wie folgt
|
|
zusammenfassen:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>By default, AF_INET6 socket will grab IPv4
|
|
connections in certain condition, and can initiate
|
|
connection to IPv4 destination embedded in IPv4 mapped
|
|
IPv6 address.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Man kann es wie unten beschrieben
|
|
abschalten.</para>
|
|
|
|
<para><command>sysctl
|
|
net.inet6.ip6.mapped_addr=0</command></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<sect5>
|
|
<title>Hörende Seite</title>
|
|
|
|
<para>Jeder Socket kann für eine Unterstützung
|
|
eines speziellen AF_INET6 wildcard bind
|
|
(Standardmäßig eingeschaltet) konfiguriert
|
|
werden. Man kann es auf Socket-Basis mit
|
|
&man.setsockopt.2; wie unten beschrieben
|
|
abschalten.</para>
|
|
|
|
<screen> int on;
|
|
|
|
setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY,
|
|
(char *)&on, sizeof (on)) < 0));</screen>
|
|
|
|
<para>Wildcard-AF_INET6-Socket schnappt sich die
|
|
IPv4-Verbindung, wenn, und nur wenn folgende Bedingungen
|
|
erfüllt sind::</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Es gibt keinen AF_INET-Socket, der zu einer
|
|
IPv4-Verbindung passt</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Der AF_INET6-Socket ist so konfiguriert, dass er
|
|
IPv4-Datenverkehr akzeptiert, z.B. gibt
|
|
getsockopt(IPV6_BINDV6ONLY) 0 zurück.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Es gibt kein Problem mit der
|
|
Öffnen/Schließen-Reihenfolge.</para>
|
|
</sect5>
|
|
|
|
<sect5>
|
|
<title>initiating side</title>
|
|
|
|
<para>FreeBSD 4.x unterstützt ausgehende
|
|
Verbindungen zu IPv4 mapped Adressen (::ffff:10.1.1.1),
|
|
falls der Knoten so konfiguriert ist, dass er IPv4
|
|
mapped Adressen unterstützt.</para>
|
|
</sect5>
|
|
</sect4>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>sockaddr_storage</title>
|
|
|
|
<para>Als RFC2553 kurz vor der Vollendung stand, gab es eine
|
|
Diskussion, wie struct sockaddr_storage Mitglieder benannt
|
|
werden sollten. Ein Vorschlag war "__" den Mitgliedern (wie
|
|
"__ss_len") voranzustellen und es sollten sie nicht
|
|
verändert werden. Der andere Vorschlag war, nichts
|
|
voranzustellen (wie "ss_len") also mußten wir solche
|
|
Mitglieder direkt verändern. Es gab keinen klaren
|
|
Konsens.</para>
|
|
|
|
<para>Als Ergebnis definiert RFC2553 die Struktur
|
|
sockaddr_storage wie folgt:</para>
|
|
|
|
<screen> struct sockaddr_storage {
|
|
u_char __ss_len; /* address length */
|
|
u_char __ss_family; /* address family */
|
|
/* and bunch of padding */
|
|
};</screen>
|
|
|
|
<para>Im Gegensatz dazu definiert der XNET-Entwurf die
|
|
Struktur wie folgt:</para>
|
|
|
|
<screen> struct sockaddr_storage {
|
|
u_char ss_len; /* address length */
|
|
u_char ss_family; /* address family */
|
|
/* and bunch of padding */
|
|
};</screen>
|
|
|
|
<para>Im Dezember 1999 kam man überein, dass RFC2553bis
|
|
letztere Definition (XNET) aufnehmen sollte.</para>
|
|
|
|
<para>Die aktuelle Implementierung ist konform zur
|
|
XNET-Definition basierend auf der RFC2553bis
|
|
Diskussion.</para>
|
|
|
|
<para>Wenn man mehrere IPv6-Implementierungen betrachtet, wird
|
|
man beide Definitionen sehen. Für Userland-Programmierer
|
|
ist der folgende Weg der meist portable um damit
|
|
umzugehen:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Man versichert sich, dass ss_family und/oder
|
|
ss_len für die Plattform verfügbar sind, indem
|
|
man GNU autoconf verwendet,</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Man benutzet -Dss_family=__ss_family um alle
|
|
Vorkommen (einschließlich der Header-Files) zu
|
|
__ss_family zu vereinheitlichen, oder</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Man benutzt niemals __ss_family. Man führe
|
|
einen Typecast nach sockaddr * durch und verwendet
|
|
sa_family wie folgt:</para>
|
|
|
|
<screen> struct sockaddr_storage ss;
|
|
family = ((struct sockaddr *)&ss)->sa_family</screen>
|
|
</listitem>
|
|
</orderedlist>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Netzwerktreiber</title>
|
|
|
|
<para>Die beiden folgenden Dinge müssen zwingend von
|
|
Standardtreibern unterstützt werden:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Mbuf-Clustering-Erfordernis. In diesem stabilen
|
|
Release haben wir für alle Betriebssystem MINCLSIZE
|
|
in MHLEN+1 geändert, damit sich alle Treiber wie
|
|
erwartet verhalten.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Multicast. Falls &man.ifmcstat.8; keine
|
|
Multicast-Gruppe für die Schnittstelle liefert, dann muss
|
|
diese Schnittstelle überarbeitet werden.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Falls keiner der Treiber die Erfordernisse erfüllt,
|
|
dann können die Treiber nicht für
|
|
IPv6/IPSec-Kommunikation verwendet werden. Falls man ein
|
|
Problem beim Einsatz von IPv6/IPSec mit seiner Karte hat, dann
|
|
melde es bitte bei &a.bugs;.</para>
|
|
|
|
<para>(Beachte: In der Vergangenheit haben wir gefordert, dass
|
|
alle PCMCIA-Treiber einen Aufruf nach in6_ifattach() haben.
|
|
Inzwischen haben wir keine solche Forderung mehr)</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Translator</title>
|
|
|
|
<para>Wir kategorisieren einen IPv4/IPv6-Translator in 4
|
|
Typen:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis>Translator A</emphasis> --- Er wird im
|
|
frühen Stadium des Übergangs benutzt um es zu
|
|
ermöglichen, dass eine Verbindung von einem IPv6-Host
|
|
auf einer IPv6-Insel zu einem IPv4-Host im IPv4-Ozean
|
|
hergestellt wird.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Translator B</emphasis> --- Er wird im
|
|
frühen Stadium des Übergangs benutzt um es zu
|
|
ermöglichen, dass eine Verbindung von einem IPv4-Host
|
|
im IPv4-Ozean zu einem IPv6-Host auf einer IPv6-Insel
|
|
hergestellt wird.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Translator C</emphasis> --- Er wird im
|
|
frühen Stadium des Übergangs benutzt um es zu
|
|
ermöglichen, dass eine Verbindung von einem IPv4-Host
|
|
auf einer IPv4-Insel zu einem IPv6-Host im IPv6-Ozean
|
|
hergestellt wird.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Translator D</emphasis> --- Er wird im
|
|
frühen Stadium des Übergangs benutzt um es zu
|
|
ermöglichen, dass eine Verbindung von einem IPv6-Host
|
|
im IPv6-Ozean zu einem IPv4-Host auf einer IPv4-Insel
|
|
hergestellt wird.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Ein TCP-Relay-Translator der Kategorie A wird
|
|
unterstützt. Er wird "FAITH" genannt. Wir stellen
|
|
ebenso einen IP-Header-Translator der Kataegorie A zur
|
|
Verfügung (Letzterer ist noch nicht in FreeBSD 4.x
|
|
übernommen).</para>
|
|
|
|
<sect3>
|
|
<title>FAITH TCP-Relay-Translator</title>
|
|
|
|
<para>Das FAITH-System benutzt mit Hilfe des Kernels den
|
|
&man.faithd.8; genannten TCP-Relay-Daemon. FAITH wird einen
|
|
IPv6-Adress-Präfix reservieren und eine
|
|
TCP-Verbindungen an diesen Präfix zum IPv4-Ziel
|
|
weiterleiten.</para>
|
|
|
|
<para>Wenn beispielsweise der IPv6-Präfix
|
|
2001:0DB8:0200:ffff:: ist und das IPv6-Ziel für
|
|
TCP-Verbindungen 2001:0DB8:0200:ffff::163.221.202.12 ist,
|
|
dann wird die Verbindung an das IPv4-Ziel 163.221.202.12
|
|
weitergeleitet.</para>
|
|
|
|
<screen> IPv4-Ziel-Knoten (163.221.202.12)
|
|
^
|
|
| IPv4 tcp toward 163.221.202.12
|
|
FAITH-relay dual stack node
|
|
^
|
|
| IPv6 TCP toward 2001:0DB8:0200:ffff::163.221.202.12
|
|
source IPv6 node</screen>
|
|
|
|
<para>&man.faithd.8; muss auf FAITH-relay dual stack node
|
|
aufgerufen werden.</para>
|
|
|
|
<para>Für weitere Details siehe
|
|
<filename>src/usr.sbin/faithd/README</filename></para>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2 id="ipsec-implementation">
|
|
<title>IPsec</title>
|
|
|
|
<para>IPsec besteht hauptsächlich aus drei
|
|
Komponenten.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Policy Management</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Key Management</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>AH und ESP Behandlung</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<sect3>
|
|
<title>Regel Management</title>
|
|
|
|
<para>Im Kernel ist experimenteller Kode für
|
|
Regel-Management implementiert. Es gibt zwei Wege eine
|
|
Sicherheitsregel zu handhaben. Einer ist eine Regel
|
|
für jeden Socket mithilfe von &man.setsockopt.2; zu
|
|
konfigurieren. Für diesen Fall ist die Konfiguration
|
|
der Regel in &man.ipsec.set.policy.3; beschrieben. Der
|
|
andere Weg ist eine auf einem Kernel-Packet-Filter
|
|
basierende Regel mithilfe der PF_KEY-Schnittstelle mittels
|
|
&man.setkey.8; zu konfigurieren.</para>
|
|
|
|
<para>Der Regeleintrag mit seinen Indices wird nicht
|
|
sortiert, so dass es sehr wichtig ist, wann ein Eintrag
|
|
hinzugefügt wird.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Key Management</title>
|
|
|
|
<para>Der in dieser Bibliothek (sys/netkey) implementierte
|
|
Kode für das key management ist eine Eigenentwicklung
|
|
der PFKEYv2-Implementierung.
|
|
Er ist konform zu RFC2367.</para>
|
|
|
|
<para>Die Eigenentwicklung des IKE-Daemons "racoon" ist in
|
|
der Bibliothek (kame/kame/racoon) implementiert.
|
|
Grundsätzlich muss man racoon als Dämonprozess
|
|
laufen lassen, dann setzt man eine Regel auf, die
|
|
Schlüssel erwartet (ähnlich wie <command>ping -P
|
|
'out ipsec esp/transport//use'</command>). Der Kernel wird
|
|
den racoon-Dämon wegen des notwendigen Austauschs der
|
|
Schlüssel kontaktieren.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>AH- und ESP-Handhabung</title>
|
|
|
|
<para>Das IPsec-Modul ist als "hook" in die
|
|
Standard-IPv4/IPv6-Verarbeitung implementiert. Sobald ein
|
|
Paket gesendet wird, prüft ip{,6_output(), ob eine
|
|
ESP/AH-Verarbeitung notwendig ist. Es findet eine
|
|
Überprüfung statt, ob eine passende SPD (Security
|
|
Policy Database) gefunden wurde. Wenn ESP/AH benötigt
|
|
wird, dann wird {esp,ah}{4,6}_output() aufgerufen und mbuf
|
|
wird folglich aktualisiert. Wenn ein Paket empfangen wird,
|
|
dann wird {esp,ah}4_input() basierend auf der Protokollnummer
|
|
aufgerufen, z.B. (*inetsw[proto])(). {esp,ah}4_input()
|
|
entschlüsselt/prüft die Authentizität des
|
|
Pakets und entfernt den daisy-chained-Header und das Padding
|
|
des ESP/AH. Es ist sicherer den ESP/AH-Header beim Empfang
|
|
zu entfernen, weil man das empfangene Paket niemals so wie
|
|
es ist benutzt.</para>
|
|
|
|
<para>Mit der Verwendung von ESP/AH wird die effektive
|
|
TCP4/6-Datensegmentgröße durch weitere von ESP/AH
|
|
eingefügte Daisy-chained-Headers beeinflußt.
|
|
Unser Kode berücksichtigt dies.</para>
|
|
|
|
<para>Grundlegende Crypto-Funktionen sind im Verzeichnis
|
|
"sys/crypto" zu finden. ESP/AH-Umformungen sind zusammen mit
|
|
den Wrapper-Funktionen in {esp,ah}_core.c gelistet. Wenn
|
|
man einige Algorithmen hinzufügen möchte, dann
|
|
fügt man in {esp,ah}_core.c eine Wrapper-Funktion hinzu
|
|
und trägt seinen Crypto-Algorithmus in sys/crypto
|
|
ein.</para>
|
|
|
|
<para>Der Tunnel-Modus wird in diesem Release teilweise mit
|
|
den folgenden Restriktionen unterstützt:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Der IPsec-Tunnel ist nicht mit der generischen
|
|
Tunnelschnittstelle kombiniert. Man muss sehr
|
|
vorsichtig sein, weil man sonst eine Endlosschleife
|
|
zwischen ip_output() und tunnelifp->if_output()
|
|
aufbaut. Die Meinungen gehen auseinander, ob es besser
|
|
ist dies zu vereinheitlichen, oder nicht.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Die Betrachtung von MTU und des "Don't
|
|
Fragment"-Bits (IPv4) müssen mehr geprüft
|
|
werden, aber grundsätzlichen arbeiten sie
|
|
gut.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Das Authentifizierungsmodel für einen
|
|
AH-Tunnel muss überarbeitet werden. Man muss
|
|
eventuell die "policy management engine"
|
|
überarbeiten.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Konformität zu RFCs und IDs</title>
|
|
|
|
<para>Der IPsec-Kode im Kernel ist konform (oder versucht
|
|
konform zu sein) zu den folgenden Standards:</para>
|
|
|
|
<para>Die "alte IPsec"-Spezifikation, die in
|
|
<filename>rfc182[5-9].txt</filename> dokumentiert ist</para>
|
|
|
|
<para>Die "neue IPsec"-Spezifikation, die
|
|
<filename>rfc240[1-6].txt</filename>,
|
|
<filename>rfc241[01].txt</filename>,
|
|
<filename>rfc2451.txt</filename> und
|
|
<filename>draft-mcdonald-simple-ipsec-api-01.txt</filename>
|
|
(Der Entwurf ist erloschen, aber man kann ihn sich von
|
|
<ulink url="ftp://ftp.kame.net/pub/internet-drafts/">
|
|
ftp://ftp.kame.net/pub/internet -drafts/</ulink> holen)
|
|
dokumentiert ist (Beachte: Die IKE-Spezifikationen
|
|
<filename>rfc241[7-9].txt</filename> sind im Userland als
|
|
"racoon"-IKE-Daemon implementiert).</para>
|
|
|
|
<para>Aktuell werden folgende Algorithmen
|
|
unterstützt:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>altes IPsec-AH</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>null crypto Prüfsumme (Kein Dokument, nur
|
|
für Debug-Zwecke)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>keyed MD5 mit 128bit crypto Prüfsumme
|
|
(<filename>rfc1828.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>keyed SHA1 mit 128bit crypto Prüfsumme
|
|
(kein Document)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>HMAC MD5 mit 128bit crypto Prüfsumme
|
|
(<filename>rfc2085.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>HMAC SHA1 mit 128bit crypto Prüfsumme (kein
|
|
Dokument)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>altes IPsec-ESP</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>null encryption (kein Dokument, ähnlich zu
|
|
<filename>rfc2410.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>DES-CBC-Modus
|
|
(<filename>rfc1829.txt</filename>)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>neues IPsec-AH</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>null crypto Prüfsumme (kein Dokument, nur
|
|
für Debug-Zwecke)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>keyed MD5 mit 96bit crypto Prüfsumme (kein
|
|
Dokument)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>keyed SHA1 mit 96bit crypto Prüfsumme (kein
|
|
Dokument)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>HMAC MD5 mit 96bit crypto Prüfsumme
|
|
(<filename>rfc2403.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>HMAC SHA1 mit 96bit crypto Prüfsumme
|
|
(<filename>rfc2404.txt</filename>)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>neues IPsec-ESP</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>null encryption
|
|
(<filename>rfc2410.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>DES-CBC mit abgeleiteter IV
|
|
(<filename>draft-ietf-ipsec-ciph-des-derived-01.txt</filename>,
|
|
Entwurf abgelaufen)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>DES-CBC mit expliziter IV
|
|
(<filename>rfc2405.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>3DES-CBC mit expliziter IV
|
|
(<filename>rfc2451.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>BLOWFISH CBC
|
|
(<filename>rfc2451.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>CAST128 CBC
|
|
(<filename>rfc2451.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RC5 CBC
|
|
(<filename>rfc2451.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Jeder Algorithmus kann kombiniert werden
|
|
mit:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>ESP-Beglaubigung mit HMAC-MD5(96bit)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ESP-Beglaubigung mit HMAC-SHA1(96bit)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Die folgenden Algorithmen werden NICHT
|
|
unterstützt:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>altes IPsec-AH</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>HMAC MD5 mit 128bit crypto Prüfsumme +
|
|
64bit replay prevention
|
|
(<filename>rfc2085.txt</filename>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>keyed SHA1 mit 160bit crypto Prüfsumme +
|
|
32bit padding
|
|
(<filename>rfc1852.txt</filename>)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>IPsec (im Kernel) und IKE (im Userland als "racoon")
|
|
wurden bei unterschiedlichen Interoperabilitätstests
|
|
geprüft und es ist bekannt, dass es mit vielen anderen
|
|
Implementierungen gut zusammenarbeitet. Außerdem
|
|
wurde die IPsec-Implementierung sowie die breite Abdeckung
|
|
mit IPsec-Crypto-Algorithmen, die in den RFCs dokumentiert
|
|
sind, geprüft (es werden nur Algorithmen ohne
|
|
intellektuelle Besitzansprüche behandelt).</para>
|
|
</sect3>
|
|
|
|
<sect3 id="ipsec-ecn">
|
|
<title>ECN-Betrachtung von IPsec-Tunneln</title>
|
|
|
|
<para>ECN-freundliche IPsec-Tunnel werden unterstützt wie
|
|
es in <filename>draft-ipsec-ecn-00.txt</filename>
|
|
beschrieben ist.</para>
|
|
|
|
<para>Normale IPsec-Tunnel sind in RFC2401 beschrieben.
|
|
Für eine Kapselung wird das IPv4-TOS-Feld (oder das
|
|
IPv6-Traffic-Class-Feld) vom inneren in den
|
|
äußeren IP-Header kopiert. Für eine
|
|
Entkapselung wird der ässere IP-Header einfach
|
|
verworfen. Die Entkapselungsregel ist nicht mit ECN
|
|
kompatibel, sobald das ECN-Bit im äußeren
|
|
IP-TOS/Traffic-Class-Feld verloren geht.</para>
|
|
|
|
<para>Um einen IPsec-Tunnel ECN-freundlich zu machen, sollte
|
|
man die Kapselungs- und Entkapselungsprozeduren
|
|
modifizieren. Dies ist in <ulink
|
|
url="http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt">
|
|
http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt</ulink>,
|
|
Kapitel 3, beschrieben.</para>
|
|
|
|
<para>Die IPsec-Tunnel-Implementierung kann drei
|
|
Zustände annehmen, indem man net.inet.ipsec.ecn (oder
|
|
net.inet6.ipsec6.ecn) auf diese Werte setzt:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>RFC2401: Keine Betrachtung von ECN (Sysctl-Wert
|
|
-1)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ECN verboten (Sysctl-Wert 0)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ECN erlaubt (Sysctl-Wert 1)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Beachte, dass dieses Verhalten per-node konfigurierbar
|
|
ist und nicht per-SA (draft-ipsec-ecn-00 möchte per-SA
|
|
Konfiguration).</para>
|
|
|
|
<para>Das Verhalten ist wie folgt zusammengefaßt (man
|
|
beachte auch den Quelltext für weitere
|
|
Details):</para>
|
|
|
|
<screen> encapsulate decapsulate
|
|
--- ---
|
|
RFC2401 kopiere alle TOS-Bits lösche TOS-Bits im äußeren
|
|
von innen nach außen. (benutze innere TOS-Bits so wie sie sind)
|
|
|
|
ECN verboten kopiere TOS-Bits außer für ECN lösche TOS-Bits im äußeren
|
|
(maskiert mit 0xfc) von innen (benutze innere TOS-Bits so wie sie sind)
|
|
nach außen. Setze ECN-Bits auf 0.
|
|
|
|
ECN erlaubt kopiere TOS-Bits außer für ECN benutze innere TOS-Bits mit einigen Änderungen.
|
|
CE (maskiert mit 0xfe) von Wenn das äußere ECN-CE-Bit 1 ist,
|
|
innen nach außen. setze das ECN-CE-Bit im
|
|
Setze ECN-CE-Bit auf 0. Inneren.</screen>
|
|
|
|
<para>Allgemeine Strategie zur Konfiguration:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Wenn beide IPsec-Tunnel-Endpunkte ein
|
|
ECN-freundliches Verhalten beherrschen, dann sollte man
|
|
besser beide Endpunkte auf <quote>ECN allowed</quote>
|
|
(Sysctl-Wert 1) setzen.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Wenn das andere Ende das TOS-Bit sehr strikt
|
|
handhabt, dann benutzt man "RFC2401" (Sysctl-Wert
|
|
-1).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>in den anderen Fällen benutzt man "ECN
|
|
verboten" (Sysctl-Wert 0).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Der Standard ist "ECN verboten" (Sysctl-Wert 0).</para>
|
|
|
|
<para>Für weitere Informationen siehe auch:</para>
|
|
|
|
<para><ulink
|
|
url="http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt">
|
|
http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt</ulink>,
|
|
RFC2481 (Explicit Congestion Notification),
|
|
src/sys/netinet6/{ah,esp}_input.c</para>
|
|
|
|
<para>(Dank gebührt Kenjiro Cho
|
|
<email>kjc@csl.sony.co.jp</email> für seine detailliert
|
|
Analyse)</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Interoperabilität</title>
|
|
|
|
<para>Hier sind einige Plattformen angegeben, die in der
|
|
Vergangenheit die IPsec/IKE-Interoperabilität mit dem
|
|
KAME-Kode getestet haben. Beachte, dass beide Enden
|
|
vielleicht ihre Implementierung verändert haben,
|
|
deshalb sollte man folgende Liste nur für
|
|
Referenzzwecke benutzen.</para>
|
|
|
|
<para>Altiga, Ashley-laurent (vpcom.com), Data Fellows
|
|
(F-Secure), Ericsson ACC, FreeS/WAN, HITACHI, IBM &aix;,
|
|
IIJ, Intel, µsoft; &windowsnt;, NIST (linux IPsec +
|
|
plutoplus), Netscreen, OpenBSD, RedCreek, Routerware, SSH,
|
|
Secure Computing, Soliton, Toshiba, VPNet, Yamaha
|
|
RT100i</para>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|