Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ip6tables: fragments?

45 views
Skip to first unread message

Joerg Schumacher

unread,
Oct 5, 2010, 10:20:01 AM10/5/10
to
Hi!

Kann es sein, dass dem ip6tables die zum "--fragment" des iptables
analoge Funktionalitaet fehlt?

TIA,
Joerg

Jan Völkers

unread,
Oct 5, 2010, 2:32:48 PM10/5/10
to
Joerg Schumacher schrub:

> Kann es sein, dass dem ip6tables die zum "--fragment" des iptables
> analoge Funktionalitaet fehlt?>

Ja. Bei ipv6 ist Fragmentierung verboten. Darum muss man zwingend ICMPv6
Typ2 erlauben. Teilweise ist in RFC 4890 sogar bei ipv6 ICMPv6
verbieten verboten. Wowereit.

Jan

http://tools.ietf.org/html/rfc4890#page-14

Jan Völkers

unread,
Oct 5, 2010, 2:39:33 PM10/5/10
to
> Ja. Bei ipv6 ist Fragmentierung verboten. Darum muss man zwingend ICMPv6
Ups. Ganz richtig ist das nicht: Es ist für Router verboten. Der Sender
darf schon fragmentieren und muss einen zusätzlichen fragmentation Header
einsetzen.

Ist das ein workaround für kaputte Software?

Jan

Juergen Ilse

unread,
Oct 5, 2010, 4:03:31 PM10/5/10
to
Hallo,

Jan Völkers <use...@voelkers.org> wrote:
> Joerg Schumacher schrub:
>> Kann es sein, dass dem ip6tables die zum "--fragment" des iptables
>> analoge Funktionalitaet fehlt?>
> Ja. Bei ipv6 ist Fragmentierung verboten.

Falsch. Bei IPv6 ist "Fragmentierung auf dem Weg" verboten. Der Sender
kann durchaus fragmentieren. Wenn bei IPv6 fragmentiert wird, dann *aus-
schliesslich* beim Sender, denn PMTUD ist (im Gegensatz zur Situation
bei IPv4) nicht mehr optional sondern zwingend. Eine "Fragmentierung
durch die Router die die Pakete weiter transportieren" gibt es nicht,
Der urspruengliche Sender darf aber sehr wohl fragmnentieren.

> Darum muss man zwingend ICMPv6 Typ2 erlauben.

ICMPv6 zu filtern ist eine ganz miserable Idee, wenn man nicht wirklich
ganz genau weiss, was man tut (also am besten von der ICMPv6-Filterei
die Finger von lassen). ICMP filtern war schon bei IPv4 keine unein-
geschraenkt gute Idee, bei IPv6 ist so etwas eine sichere Moeglichkeit
sich der Connectivity zu berauben (selbst die "Neighbor Discovery" die
das "arp" bei IPv4 ersetzt, laeuft ueber ICMPv6).

> Teilweise ist in RFC 4890 sogar bei ipv6 ICMPv6
> verbieten verboten. Wowereit.

Das waere sinnvoll, ja.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Juergen Ilse

unread,
Oct 5, 2010, 4:05:14 PM10/5/10
to
Hallo,

Nein, das ist die einzige Moeglichkeit, z.B. UDP-Pakete zu senden, die
groesser als die PATH.MTU sind (was z.B. bei DNS und EDNS0 notwendig
werden kann ...).

Jan Völkers

unread,
Oct 5, 2010, 4:08:46 PM10/5/10
to
Juergen Ilse schrub:

> Falsch. Bei IPv6 ist "Fragmentierung auf dem Weg" verboten. Der Sender

Hab ich auch eben gemerkt - mein Reputationsrettungspost ist aber irnkwie
beim gleichzeitigen $ANDERESZEUCHSMACHEN verlorengegangen.
Wiedemauchsei: Ist das ein workaround für kaputte Software oder gibt es
zwingende Gründe?

Jan

Juergen Ilse

unread,
Oct 5, 2010, 4:14:47 PM10/5/10
to
Hallo,

Ich hatte bereits welche genannt: Bei DNS und ENDS0 (was sehr sinnvoll
ist, wenn man z.B. DNSSEC machen will) koennen DNS-Antworten durchaus
deutlich groesser als die "historischen 512 Byte" sein. Wenn die groesser
als die PATH-MTU werden, muss zwingens fragmentiert werden (oder es muss
ein Fallback auf TCP geben, was die DNS-Server nur unnoetig zusaetzlich
belastet). Es gibt sicherlich auch noch andere UDP-basierte Protokolle,
bei denen eine zwingende Beschraenkung auf "maximal so gross wie die PMTU"
eher unpraktisch waere. Bei TCP waere es i.d.R. aber sinnvoller, dann
nicht zufragmentieren.

Jan Völkers

unread,
Oct 5, 2010, 4:15:55 PM10/5/10
to
Juergen Ilse schrub:

> Nein, das ist die einzige Moeglichkeit, z.B. UDP-Pakete zu senden, die
> groesser als die PATH.MTU sind (was z.B. bei DNS und EDNS0 notwendig
> werden kann ...).

Was spricht dagegen, die UDP Pakete schon vom resolver kleiner zu machen?

Gruß Jan

Jan Völkers

unread,
Oct 5, 2010, 4:29:02 PM10/5/10
to
Juergen Ilse schrub:

[IPv6 UDP]

Danke, wieder was gelernt. :-)

Jan

Juergen Ilse

unread,
Oct 5, 2010, 5:18:18 PM10/5/10
to
Hallo,

Eine UDP-Antwort wird laut DNS-Spezifikation immer in einem UDP-Paket
geliefert. Passt sie nicht hinein, gibt es eine unvollstaendige Antwort
(die auch als unvollstaendig erkennbar ist). Moechte der Fragsteller eine
vollstaendige Antwort, muss er dann noch einmal per TCP nachfragen, was
inbesondere fuer die DNS-Server eine erhebliche Mehrbelastung ist. Aus
diesem Grunde (und weil kuenftig bei DNSSEC eine erhebliche Anzahl von
DNS-Antworten fuer die hisher ueblichen maximal 512 Byte grossen UDP-
Antworten zu gross sein werden) hat man sich eine Erweiterung des Stnadards
namens "EDNS0 ausgedacht, die UDP-Antworten bis zu 4 KB Groesse erlaubt
(wobei IIRC der Fragesteller die MAximalgroesse die er verarbeiten kann
in dem "Fragepaket" mitteilt). Damit kann man aber durchaus de oefteren
auch bei Antworten landen, die groesser als die PMTU sind (von der der
Fragesteller vor einer Anfrage schlimmstenfalls noch nicht einmal weiss,
wie gross sie ist). Um (zur Entlastung der DNS-Server) die Anzahl an
TCP-Anfragen klein zu halten, ist es sinnvoll, auch "fragmentierte DNS-
Antworten" zuzulassen, um mit der MAximalgroesse der UDP-Antwort nicht
auf die PMTU beschraenkt zu sein.

DNS-Antworten lassen sich nicht sinnvoll auf mehrere verschiedene UDP-
Pakete aufteilen, das gibt das (DNS-)Protokoll nicht her.

Juergen P. Meier

unread,
Oct 6, 2010, 2:14:21 AM10/6/10
to
Joerg Schumacher <sch...@kenny.gaertner.de>:

> Kann es sein, dass dem ip6tables die zum "--fragment" des iptables
> analoge Funktionalitaet fehlt?

Ja.

IPv6 kennt keine IP-Fragmentierung mehr, also waere eine solche Option
reichlich Sinnfrei.

Juergen Ilse

unread,
Oct 6, 2010, 2:38:18 AM10/6/10
to
Hallo,

Obwohl ich im ersten Moment geneigt war, etwas aehnliches zu antworten,
ist mir noch aufgefallen, dass es nicht stimmt. Auch IPv6 kennt Fragmen-
tierung, nur darf bei IPv6 kein Router beim weiterleiten von Paketen
diese fragmentieren (da PMTUD, die bei IPv4 noch optional war, bei IPv6
zwingend vorhanden ist). Allerdings kann der Sender sehr wohl Pakete
fragmentieren und diese bereits fragmentiert auf die Reise schicken.
Die Aussage "bei IPv6 gibt es keine Fragmentierung" ist also in dieser
Allgemeinheit falsch.

Jens Link

unread,
Oct 6, 2010, 3:36:13 AM10/6/10
to
Juergen Ilse <jue...@usenet-verwaltung.de> writes:

> ICMPv6 zu filtern ist eine ganz miserable Idee, wenn man nicht wirklich
> ganz genau weiss, was man tut (also am besten von der ICMPv6-Filterei
> die Finger von lassen).

"Recommendations for Filtering ICMPv6 Messages in Firewalls" (RFC4890) sei
als Lektüre empfohlen.

Jens
--
jabber je...@jabber.quux.de
BLOG http://blog.quux.de
sage@guug Berlin http://www.guug.de/lokal/berlin/index.html
sage@guug Nuernberg http://www.guug.de/lokal/nuernberg/index.html

Juergen P. Meier

unread,
Oct 6, 2010, 2:55:25 AM10/6/10
to
Juergen Ilse <jue...@usenet-verwaltung.de>:

> Hallo,
>
> Juergen P. Meier <nospa...@jors.net> wrote:
>> Joerg Schumacher <sch...@kenny.gaertner.de>:
>>> Kann es sein, dass dem ip6tables die zum "--fragment" des iptables
>>> analoge Funktionalitaet fehlt?
>> Ja.
>> IPv6 kennt keine IP-Fragmentierung mehr, also waere eine solche Option
>> reichlich Sinnfrei.
>
> Obwohl ich im ersten Moment geneigt war, etwas aehnliches zu antworten,
> ist mir noch aufgefallen, dass es nicht stimmt. Auch IPv6 kennt Fragmen-
> tierung, nur darf bei IPv6 kein Router beim weiterleiten von Paketen
> diese fragmentieren (da PMTUD, die bei IPv4 noch optional war, bei IPv6
> zwingend vorhanden ist). Allerdings kann der Sender sehr wohl Pakete
> fragmentieren und diese bereits fragmentiert auf die Reise schicken.
> Die Aussage "bei IPv6 gibt es keine Fragmentierung" ist also in dieser
> Allgemeinheit falsch.

Falls du auf den "Fragment header" ansprichst, das ist kein
inhaerentes Feature von IPv6. IPv6 selbst kennt keine Fragmentierung.
IPv6 kennt auch kein Source-Routing oder sonst irgendwelche Optionen.

IPv6 kennt aber Erweiterungen (extension headers), mit denen sich
in IPv6 fehlende Funktionen fuer Endpunkte nachruesten/implementieren lassen.
(Mit Ausnahme [sigh] einer Extension werden diese aber von Routern ignoriert)

Jueregn
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Joerg Schumacher

unread,
Oct 6, 2010, 12:57:36 PM10/6/10
to

Das erzaehl mal lieber nicht den Nameservern, die ihre Antworten per
socket option IPV6_USE_MIN_MTU (RFC 3542) durch den Schredder jagen lassen.
Nachher glauben die das noch :-;

Das ip6tables kann ja durchaus mit Fragmenten umgehen:

--fragfirst
Matches on the first fragment.
--fragmore
Matches if there are more fragments.
--fraglast
Matches if this is the last fragment.

Mir fehlt da nur irgendwie eine Option fuer "nicht das erste Fragment",
also das zweite und alle weiteren.

Ciao,
Joerg

Florian Weimer

unread,
Oct 8, 2010, 12:10:40 PM10/8/10
to
* Juergen Ilse:

> Falsch. Bei IPv6 ist "Fragmentierung auf dem Weg" verboten. Der Sender
> kann durchaus fragmentieren. Wenn bei IPv6 fragmentiert wird, dann *aus-
> schliesslich* beim Sender, denn PMTUD ist (im Gegensatz zur Situation
> bei IPv4) nicht mehr optional sondern zwingend.

Ganz richtig ist auch das nicht. Man kann die Pakete einfach mit der
Minimal-MTU losschicken, dann ist es nicht sichtbar, ob man PMTUD
macht oder nicht. Für aus Stack-Sicht verbindungslose Protokolle geht
das sowieso nicht anders, weil die BSD-Sockets-API keinen wirklich
guten Zugriff auf die ICMP-Nachrichten gestattet.

Bei IPv4 geht das eher nicht, weil dort die Minimal-MTU deutlich unter
100 Bytes liegt. Dort kann man allerdings seine Pakete mit DF=0
losschicken, womit man sich nur um die anfängliche Fragmentierung
kümmern muß.

0 new messages