Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RFC1918-Adressen filtern
36 views
Skip to first unread message
Sven Lanoster
Jul 26, 2012, 1:26:52 PM7/26/12
to
Moin, moin.
Ich war heute in einer nicht so großen Firma und benutzte einen der
Arbeitsplätze. Der Arbeitsplatz hatte die IP 192.168.1.xxx.
Als ich in einer Doku las, dass ein Server unter 192.168.5.55
erreichbar sein soll, probierte ich ihn anzupingen:
Ping wird ausgeführt für 192.168.5.55 mit 32 Bytes Daten:
Antwort von 84.xx.yy.70: Die Gültigkeitsdauer wurde bei der Übertragung
überschritten.
Nanu, wieso antwortet da denn eine öffentliche IP?
C:\Users\sla>tracert 84.xx.yy.70
Routenverfolgung zu b6.routing.<ISP>.de [84.xx.yy.70] über maximal 30
Abschnitte:
1 <1 ms 1 ms <1 ms 192.168.1.1
2 10 ms 9 ms 9 ms a1.routing.<ISP>.de [aa.xx.yy.bb]
3 1 ms 1 ms 1 ms b4.routing.<ISP>.de [84.xx.yy.2]
4 1 ms 1 ms 1 ms b6.routing.<ISP>.de [84.xx.yy.70]
Ablaufverfolgung beendet.
Also hat mein Ping das LAN verlassen und ist dann noch munter drei
große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
werden die mehrere HOPs weit geroutet?
Sieht jemand ein Risiko irgendwo, wenn die Adressen nicht an der
Netzwerkgrenze gefiltert werden? Also stört das irgendwen? Oder ist
sogar das LAN gefährdet? Können dadurch Informationen aus dem LAN ins
Internet gelangen, die sonst nicht (so einfach) zu bekommen wären?
MfG,
Sven.
--
Nmap done: 1 IP address (1 host up) scanned in 2.26 seconds
Ich war heute in einer nicht so großen Firma und benutzte einen der
Arbeitsplätze. Der Arbeitsplatz hatte die IP 192.168.1.xxx.
Als ich in einer Doku las, dass ein Server unter 192.168.5.55
erreichbar sein soll, probierte ich ihn anzupingen:
Ping wird ausgeführt für 192.168.5.55 mit 32 Bytes Daten:
Antwort von 84.xx.yy.70: Die Gültigkeitsdauer wurde bei der Übertragung
überschritten.
Nanu, wieso antwortet da denn eine öffentliche IP?
C:\Users\sla>tracert 84.xx.yy.70
Routenverfolgung zu b6.routing.<ISP>.de [84.xx.yy.70] über maximal 30
Abschnitte:
1 <1 ms 1 ms <1 ms 192.168.1.1
2 10 ms 9 ms 9 ms a1.routing.<ISP>.de [aa.xx.yy.bb]
3 1 ms 1 ms 1 ms b4.routing.<ISP>.de [84.xx.yy.2]
4 1 ms 1 ms 1 ms b6.routing.<ISP>.de [84.xx.yy.70]
Ablaufverfolgung beendet.
Also hat mein Ping das LAN verlassen und ist dann noch munter drei
große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
werden die mehrere HOPs weit geroutet?
Sieht jemand ein Risiko irgendwo, wenn die Adressen nicht an der
Netzwerkgrenze gefiltert werden? Also stört das irgendwen? Oder ist
sogar das LAN gefährdet? Können dadurch Informationen aus dem LAN ins
Internet gelangen, die sonst nicht (so einfach) zu bekommen wären?
MfG,
Sven.
--
Nmap done: 1 IP address (1 host up) scanned in 2.26 seconds
Bernd Eckenfels
Jul 26, 2012, 2:40:11 PM7/26/12
to
Sven Lanoster <SvenLa...@gmx.de> wrote:
> große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
> werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
> werden die mehrere HOPs weit geroutet?
Das kann entweder Absicht sein (weil der ISP mit der Firma zusammenarbeitet)
> große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
> werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
> werden die mehrere HOPs weit geroutet?
oder eine Konfiguration die nicht der BCP "Egress(Firmenseite)"- oder
Ingress(ISP Seite)"filtering entspricht. "Nicht gerouted" heisst nicht
"nicht weitergegeben" sondern nur "kommen nicht unbedingt an".
> Sieht jemand ein Risiko irgendwo, wenn die Adressen nicht an der
> Netzwerkgrenze gefiltert werden? Also stört das irgendwen?
besteht oder midnestens aber Informationen nach aussen leaken können. Es ist
auch ein Risiko für das Image des ISP.
> Oder ist
> sogar das LAN gefährdet? Können dadurch Informationen aus dem LAN ins
> Internet gelangen, die sonst nicht (so einfach) zu bekommen wären?
sind. Allerdings würde ich aus deinem gekürtzten Tracedump das jetzt nicht
sicher ableiten wollen, wie gesagt, der ISP könnte das ja auch absichtlich
in Absprache mit der Firma tun.
Gruss
Bernd
Juergen Ilse
Jul 26, 2012, 2:51:31 PM7/26/12
to
Hallo,
Sven Lanoster <SvenLa...@gmx.de> wrote:
> Ich war heute in einer nicht so groï¿œen Firma und benutzte einen der
> Arbeitsplï¿œtze. Der Arbeitsplatz hatte die IP 192.168.1.xxx.
> Antwort von 84.xx.yy.70: Die Gï¿œltigkeitsdauer wurde bei der ï¿œbertragung
> ï¿œberschritten.
> Nanu, wieso antwortet da denn eine ï¿œffentliche IP?
Weil die Pakete fuer 192.168.5.55 in Richtung irgendwelcher Geraete
mit oeffentlichen IP-Adressen geroutet wird, und dann vermutlich
irgendwelche Router mit den Paketen Ping-Pong spielen. Ist die TTL
abgelaufen, kommt ein "ICMP Time Exceeded" zurueck, dass diese
Meldung produziert (und das Paket wird in das private Netz zurueck-
geschickt, weil der ICMP-Echo-Request hinter der offiziellen IP-Adresse
desInternetrouters genattet wird und bei der Antwort wieder auf die
urspruengliche 192.168.1.x Adresse zurueckuebersetzt wird ...).
> C:\Users\sla>tracert 84.xx.yy.70
>
> Routenverfolgung zu b6.routing.<ISP>.de [84.xx.yy.70] ï¿œber maximal 30
Adresse abhaengt, und ausserdem weil die Pakete genattet werden (es
werden die Quelladressen der ausgehenden Pakete auf die externe Adresse
des Internetrouters umgeschrieben).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Sven Lanoster <SvenLa...@gmx.de> wrote:
> Ich war heute in einer nicht so groï¿œen Firma und benutzte einen der
> Arbeitsplï¿œtze. Der Arbeitsplatz hatte die IP 192.168.1.xxx.
> Als ich in einer Doku las, dass ein Server unter 192.168.5.55
> erreichbar sein soll, probierte ich ihn anzupingen:
> Ping wird ausgefï¿œhrt fï¿œr 192.168.5.55 mit 32 Bytes Daten:
> erreichbar sein soll, probierte ich ihn anzupingen:
> Antwort von 84.xx.yy.70: Die Gï¿œltigkeitsdauer wurde bei der ï¿œbertragung
> ï¿œberschritten.
> Nanu, wieso antwortet da denn eine ï¿œffentliche IP?
Weil die Pakete fuer 192.168.5.55 in Richtung irgendwelcher Geraete
mit oeffentlichen IP-Adressen geroutet wird, und dann vermutlich
irgendwelche Router mit den Paketen Ping-Pong spielen. Ist die TTL
abgelaufen, kommt ein "ICMP Time Exceeded" zurueck, dass diese
Meldung produziert (und das Paket wird in das private Netz zurueck-
geschickt, weil der ICMP-Echo-Request hinter der offiziellen IP-Adresse
desInternetrouters genattet wird und bei der Antwort wieder auf die
urspruengliche 192.168.1.x Adresse zurueckuebersetzt wird ...).
> C:\Users\sla>tracert 84.xx.yy.70
>
> Abschnitte:
>
> 1 <1 ms 1 ms <1 ms 192.168.1.1
> 2 10 ms 9 ms 9 ms a1.routing.<ISP>.de [aa.xx.yy.bb]
> 3 1 ms 1 ms 1 ms b4.routing.<ISP>.de [84.xx.yy.2]
> 4 1 ms 1 ms 1 ms b6.routing.<ISP>.de [84.xx.yy.70]
>
> Ablaufverfolgung beendet.
>
> Also hat mein Ping das LAN verlassen und ist dann noch munter drei
> groï¿œe Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
>
> 1 <1 ms 1 ms <1 ms 192.168.1.1
> 2 10 ms 9 ms 9 ms a1.routing.<ISP>.de [aa.xx.yy.bb]
> 3 1 ms 1 ms 1 ms b4.routing.<ISP>.de [84.xx.yy.2]
> 4 1 ms 1 ms 1 ms b6.routing.<ISP>.de [84.xx.yy.70]
>
> Ablaufverfolgung beendet.
>
> Also hat mein Ping das LAN verlassen und ist dann noch munter drei
> werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
> werden die mehrere HOPs weit geroutet?
Weil die Route erst einmal nicht von der Quell- sondern von der Ziel-
> werden die mehrere HOPs weit geroutet?
Adresse abhaengt, und ausserdem weil die Pakete genattet werden (es
werden die Quelladressen der ausgehenden Pakete auf die externe Adresse
des Internetrouters umgeschrieben).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Sven Lanoster
Jul 26, 2012, 3:57:39 PM7/26/12
to
Bernd Eckenfels schrieb:
versicherte mir jedenfalls grade, dass er in Zukunft auch ohne meine
Hinweise klar kommt. Spricht für Deine Theorie.
MfG,
Sven.
--
> Mein Lieblingsspruch: Es gibt keine 100% Sicherheit :)
Es gibt 100% Sicherheit, aber die Restmenge der immer noch angreifbaren
Szenarien ist typischerweise dabei überabzählbar unendlich.
(Lutz Donnerhacke in de.comp.security.misc)
> Sven Lanoster <SvenLa...@gmx.de> wrote:
> > große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
> > werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
> > werden die mehrere HOPs weit geroutet?
>
> Das kann entweder Absicht sein (weil der ISP mit der Firma
> zusammenarbeitet) oder eine Konfiguration die nicht der BCP
> "Egress(Firmenseite)"- oder Ingress(ISP Seite)"filtering entspricht.
> "Nicht gerouted" heisst nicht "nicht weitergegeben" sondern nur
> "kommen nicht unbedingt an".
Ah, verstehe. Das ist gut möglich. Der zuständige Netzwerkadmin
> > große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
> > werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
> > werden die mehrere HOPs weit geroutet?
>
> Das kann entweder Absicht sein (weil der ISP mit der Firma
> zusammenarbeitet) oder eine Konfiguration die nicht der BCP
> "Egress(Firmenseite)"- oder Ingress(ISP Seite)"filtering entspricht.
> "Nicht gerouted" heisst nicht "nicht weitergegeben" sondern nur
> "kommen nicht unbedingt an".
versicherte mir jedenfalls grade, dass er in Zukunft auch ohne meine
Hinweise klar kommt. Spricht für Deine Theorie.
MfG,
Sven.
--
> Mein Lieblingsspruch: Es gibt keine 100% Sicherheit :)
Es gibt 100% Sicherheit, aber die Restmenge der immer noch angreifbaren
Szenarien ist typischerweise dabei überabzählbar unendlich.
(Lutz Donnerhacke in de.comp.security.misc)
Sven Lanoster
Jul 26, 2012, 4:13:32 PM7/26/12
to
Juergen Ilse schrieb:
> Weil die Route erst einmal nicht von der Quell- sondern von der Ziel-
> Adresse abhaengt, und ausserdem weil die Pakete genattet werden
Ja, war bekannt aber danke.
Hättest du nicht gestutzt, wenn auf einen RFC1918-ping eine öffentliche
IP antwortet?
Der Weg der Antwort zurück durchs NAT ist klar, aber wieso kam das
Paket überhaupt soweit, dass NAT benutzt wird?
Und wo das schon versagt hat, wieso wirft dann nicht gleich der erste
Router beim ISP das Paket weg? Das hat im Internet ja schließlich nix
zu suchen. Also ich fand das merkwürdig.
Der zuständige Admin findet das Verhalten nach Nachfrage meinerseits
normal und damit verlassen wir dann den konkreten Fall.
> Weil die Route erst einmal nicht von der Quell- sondern von der Ziel-
> Adresse abhaengt, und ausserdem weil die Pakete genattet werden
Hättest du nicht gestutzt, wenn auf einen RFC1918-ping eine öffentliche
IP antwortet?
Der Weg der Antwort zurück durchs NAT ist klar, aber wieso kam das
Paket überhaupt soweit, dass NAT benutzt wird?
Und wo das schon versagt hat, wieso wirft dann nicht gleich der erste
Router beim ISP das Paket weg? Das hat im Internet ja schließlich nix
zu suchen. Also ich fand das merkwürdig.
Der zuständige Admin findet das Verhalten nach Nachfrage meinerseits
normal und damit verlassen wir dann den konkreten Fall.
Florian Weimer
Jul 26, 2012, 5:38:32 PM7/26/12
to
* Sven Lanoster:
> Also hat mein Ping das LAN verlassen und ist dann noch munter drei
> große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
> werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
> werden die mehrere HOPs weit geroutet?
Es kann sein, der ISP eine entsprechende Route über die globale
Tabelle erhalten hat und nicht wegfilterte. Oder die ersten Router
haben keine vollständige Routingtabelle, aus der hervorgeht, daß es
sich nicht um eine gültige Adresse handelt, sondern sie leiten solche
Pakete ungeprüft weiter.
> Also hat mein Ping das LAN verlassen und ist dann noch munter drei
> große Router im Internet weit gekommen. Ich dachte, RFC1918-Adressen
> werden im Internet gar nicht geroutet. Offenbar irre ich mich. Warum
> werden die mehrere HOPs weit geroutet?
Tabelle erhalten hat und nicht wegfilterte. Oder die ersten Router
haben keine vollständige Routingtabelle, aus der hervorgeht, daß es
sich nicht um eine gültige Adresse handelt, sondern sie leiten solche
Pakete ungeprüft weiter.
Bernd Eckenfels
Jul 26, 2012, 6:53:25 PM7/26/12
to
Sven Lanoster <SvenLa...@gmx.de> wrote:
> Der Weg der Antwort zurï¿œck durchs NAT ist klar, aber wieso kam das
> Paket ï¿œberhaupt soweit, dass NAT benutzt wird?
Da muss kein NAT im Spiel sein, wenn Router 1 das interne Netz und Router 2
kennt, dabei eine interne und eine externe ip hat, und ein 2. router nur mit
externen ips, dann wird dessen antwort eine offizielle IP als absender haben
(und ï¿œber den ersten Router die Antwort wieder zurï¿œcksenden).
Gruss
Bernd
> Der Weg der Antwort zurï¿œck durchs NAT ist klar, aber wieso kam das
> Paket ï¿œberhaupt soweit, dass NAT benutzt wird?
Da muss kein NAT im Spiel sein, wenn Router 1 das interne Netz und Router 2
kennt, dabei eine interne und eine externe ip hat, und ein 2. router nur mit
externen ips, dann wird dessen antwort eine offizielle IP als absender haben
(und ï¿œber den ersten Router die Antwort wieder zurï¿œcksenden).
Gruss
Bernd
Juergen Ilse
Jul 26, 2012, 7:27:59 PM7/26/12
to
> Juergen Ilse schrieb:
>> Weil die Route erst einmal nicht von der Quell- sondern von der Ziel-
>> Adresse abhaengt, und ausserdem weil die Pakete genattet werden
> Ja, war bekannt aber danke.
> Hättest du nicht gestutzt, wenn auf einen RFC1918-ping eine öffentliche
> IP antwortet?
Nein, nicht unbedingt. Eher dann schon, wenn die *Quelladresse* RFC1918
>> Weil die Route erst einmal nicht von der Quell- sondern von der Ziel-
>> Adresse abhaengt, und ausserdem weil die Pakete genattet werden
> Ja, war bekannt aber danke.
> Hättest du nicht gestutzt, wenn auf einen RFC1918-ping eine öffentliche
> IP antwortet?
ist und *kein* NAT im Spiel waere (dann wuerde ich mich wundern, ueberhaupt
eine Antwort aus Richtung des ISP zu bwkommwn).
> Der Weg der Antwort zurück durchs NAT ist klar, aber wieso kam das
> Paket überhaupt soweit, dass NAT benutzt wird?
> Und wo das schon versagt hat, wieso wirft dann nicht gleich der erste
> Router beim ISP das Paket weg?
> Das hat im Internet ja schließlich nix zu suchen.
> Also ich fand das merkwürdig.
> Der zuständige Admin findet das Verhalten nach Nachfrage meinerseits
> normal und damit verlassen wir dann den konkreten Fall.
du zuerst einmal diese ausgehenden Pakete filtern. Der Provider
koennte dann noch Filter gegen IP-SPoofung konfigurieren, bei denen
dann ggfs. die RFC1918-Fukter quasi als Anfallprodukt mitenthalten
sind ...
Marc Haber
Aug 19, 2012, 4:19:22 AM8/19/12
to
"Sven Lanoster" <SvenLa...@gmx.de> wrote:
>Bernd Eckenfels schrieb:
Superspezialexperte ist und keinesfalls in Betracht zöge, es hier mit
Fehlkonfiguration oder schlechtem Design zu tun zu haben. Dass er Dir
außer "das gehört so" keine verstehbare Erklärung geliefert hat,
spricht für meine Vermutung.
Grüße
Marc, der von derartigen Superspezialexperten schon genug in seiner
Liste stehen hat
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
>Bernd Eckenfels schrieb:
>> Das kann entweder Absicht sein (weil der ISP mit der Firma
>> zusammenarbeitet) oder eine Konfiguration die nicht der BCP
>> "Egress(Firmenseite)"- oder Ingress(ISP Seite)"filtering entspricht.
>> "Nicht gerouted" heisst nicht "nicht weitergegeben" sondern nur
>> "kommen nicht unbedingt an".
>
>Ah, verstehe. Das ist gut möglich. Der zuständige Netzwerkadmin
>versicherte mir jedenfalls grade, dass er in Zukunft auch ohne meine
>Hinweise klar kommt. Spricht für Deine Theorie.
Das könnte auch dafür sprechen, dass der zuständige Netzwerkadmin
>> zusammenarbeitet) oder eine Konfiguration die nicht der BCP
>> "Egress(Firmenseite)"- oder Ingress(ISP Seite)"filtering entspricht.
>> "Nicht gerouted" heisst nicht "nicht weitergegeben" sondern nur
>> "kommen nicht unbedingt an".
>
>Ah, verstehe. Das ist gut möglich. Der zuständige Netzwerkadmin
>versicherte mir jedenfalls grade, dass er in Zukunft auch ohne meine
>Hinweise klar kommt. Spricht für Deine Theorie.
Superspezialexperte ist und keinesfalls in Betracht zöge, es hier mit
Fehlkonfiguration oder schlechtem Design zu tun zu haben. Dass er Dir
außer "das gehört so" keine verstehbare Erklärung geliefert hat,
spricht für meine Vermutung.
Grüße
Marc, der von derartigen Superspezialexperten schon genug in seiner
Liste stehen hat
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Sven Lanoster
Aug 19, 2012, 4:09:31 PM8/19/12
to
Marc Haber schrieb:
> "Sven Lanoster" <SvenLa...@gmx.de> wrote:
> > Bernd Eckenfels schrieb:
> >> Das kann entweder Absicht sein (weil der ISP mit der Firma
> >> zusammenarbeitet) oder eine Konfiguration die nicht der BCP
> >> "Egress(Firmenseite)"- oder Ingress(ISP Seite)"filtering
> entspricht. >> "Nicht gerouted" heisst nicht "nicht weitergegeben"
> sondern nur >> "kommen nicht unbedingt an".
> > Ah, verstehe. Das ist gut möglich. Der zuständige Netzwerkadmin
> > versicherte mir jedenfalls grade, dass er in Zukunft auch ohne meine
> > Hinweise klar kommt. Spricht für Deine Theorie.
> Das könnte auch dafür sprechen, dass der zuständige Netzwerkadmin
> Superspezialexperte ist und keinesfalls in Betracht zöge, es hier mit
> Fehlkonfiguration oder schlechtem Design zu tun zu haben. Dass er Dir
> außer "das gehört so" keine verstehbare Erklärung geliefert hat,
> spricht für meine Vermutung.
Auch eine plausible Vermutung.
Eine seiner letzten E-Mails meinten sarkastisch "Ja, klar. Die Firewall
ist aus und die internen Pakete sind an die externe Schnittstelle
gebunden!". Und ich Dummerle dachte, ich hätte genau das gezeigt...
> Marc, der von derartigen Superspezialexperten schon genug in seiner
> Liste stehen hat
Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
Netzwerkgrenze gefiltert werden sollte. Damit qualifiziere ich mich
offenbar auch zum Superspezialexperten, ohne mich selbst auch nur als
Netzwerker bezeichnen zu wollen.
MfG,
Sven.
--
"Dies soll sicherstellen, dass mit Freunden geteilte Bilder nicht
an Dritte weitergereicht werden. Versucht jemand, den Bildschirm
mit einer Kamera abzufotografieren, springt ein McAfee-
Sicherheitsteufel aus dem Computer und frisst die Speicherkarte."
http://www.heise.de/security/meldung/McAfee-will-Facebook-Fotos-per-App-
schuetzen-1669943.html
> "Sven Lanoster" <SvenLa...@gmx.de> wrote:
> > Bernd Eckenfels schrieb:
> >> Das kann entweder Absicht sein (weil der ISP mit der Firma
> >> zusammenarbeitet) oder eine Konfiguration die nicht der BCP
> >> "Egress(Firmenseite)"- oder Ingress(ISP Seite)"filtering
> entspricht. >> "Nicht gerouted" heisst nicht "nicht weitergegeben"
> sondern nur >> "kommen nicht unbedingt an".
> > Ah, verstehe. Das ist gut möglich. Der zuständige Netzwerkadmin
> > versicherte mir jedenfalls grade, dass er in Zukunft auch ohne meine
> > Hinweise klar kommt. Spricht für Deine Theorie.
> Das könnte auch dafür sprechen, dass der zuständige Netzwerkadmin
> Superspezialexperte ist und keinesfalls in Betracht zöge, es hier mit
> Fehlkonfiguration oder schlechtem Design zu tun zu haben. Dass er Dir
> außer "das gehört so" keine verstehbare Erklärung geliefert hat,
> spricht für meine Vermutung.
Eine seiner letzten E-Mails meinten sarkastisch "Ja, klar. Die Firewall
ist aus und die internen Pakete sind an die externe Schnittstelle
gebunden!". Und ich Dummerle dachte, ich hätte genau das gezeigt...
> Marc, der von derartigen Superspezialexperten schon genug in seiner
> Liste stehen hat
Netzwerkgrenze gefiltert werden sollte. Damit qualifiziere ich mich
offenbar auch zum Superspezialexperten, ohne mich selbst auch nur als
Netzwerker bezeichnen zu wollen.
MfG,
Sven.
--
"Dies soll sicherstellen, dass mit Freunden geteilte Bilder nicht
an Dritte weitergereicht werden. Versucht jemand, den Bildschirm
mit einer Kamera abzufotografieren, springt ein McAfee-
Sicherheitsteufel aus dem Computer und frisst die Speicherkarte."
http://www.heise.de/security/meldung/McAfee-will-Facebook-Fotos-per-App-
schuetzen-1669943.html
Juergen Ilse
Aug 21, 2012, 2:44:10 AM8/21/12
to
> Marc Haber schrieb:
Manche Filter lassen sich auf manchen Geraeten auch nicht ohne
deutlichen Performance-Impact realisieren. Und wer schon einmal
Spass damit hatte, dass ICMP-unreachable-Meldungen dank etwas
Unbedachtheit bei der Planung des Netzes (RFC1918-Transfernetze)
mit privaten Source-Adressen unterwegs waren und dann dank solcher
Filter ploetzlich vor disfunktionaler PMTU stand, wird manche
Forderung evt. auch zumindest mit etwas gemischten Gefuehlen
betrachten ...
In einer idealen Welt wuerden die Filter niemals schaden (in einer
idealen Welt haetten wir auch keine RFC1918-Adressen noetig, weil
public unique IP-Adresses fuer alle genuegend da waeren), nur leider
ist diese Welt in dieser Hinsicht nicht ideal ...
>> Marc, der von derartigen Superspezialexperten schon genug in seiner
>> Liste stehen hat
> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
> Netzwerkgrenze gefiltert werden sollte.
Als Source-Adresse? Als Destination-Adresse? Oder beides?
>> Liste stehen hat
> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
> Netzwerkgrenze gefiltert werden sollte.
Manche Filter lassen sich auf manchen Geraeten auch nicht ohne
deutlichen Performance-Impact realisieren. Und wer schon einmal
Spass damit hatte, dass ICMP-unreachable-Meldungen dank etwas
Unbedachtheit bei der Planung des Netzes (RFC1918-Transfernetze)
mit privaten Source-Adressen unterwegs waren und dann dank solcher
Filter ploetzlich vor disfunktionaler PMTU stand, wird manche
Forderung evt. auch zumindest mit etwas gemischten Gefuehlen
betrachten ...
In einer idealen Welt wuerden die Filter niemals schaden (in einer
idealen Welt haetten wir auch keine RFC1918-Adressen noetig, weil
public unique IP-Adresses fuer alle genuegend da waeren), nur leider
ist diese Welt in dieser Hinsicht nicht ideal ...
Juergen P. Meier
Aug 23, 2012, 12:47:54 AM8/23/12
to
Juergen Ilse <jue...@usenet-verwaltung.de>:
> Manche Filter lassen sich auf manchen Geraeten auch nicht ohne
> deutlichen Performance-Impact realisieren. Und wer schon einmal
Dann hat man das falsche Geraet fuer dieses Geschaeft.
> Spass damit hatte, dass ICMP-unreachable-Meldungen dank etwas
> Unbedachtheit bei der Planung des Netzes (RFC1918-Transfernetze)
> mit privaten Source-Adressen unterwegs waren und dann dank solcher
> Filter ploetzlich vor disfunktionaler PMTU stand, wird manche
> Forderung evt. auch zumindest mit etwas gemischten Gefuehlen
> betrachten ...
Wer RFC 1918 in oeffentlichen Netzen (und Transfernetze fuer
oeffentlichen Datenverkehr *SIND* oeffentliche Netze) einsetzt, den
sollte man mit der PMTUD-Keule so lange verpruegeln, bis er
Tokenring-Tokens sieht.
> In einer idealen Welt wuerden die Filter niemals schaden (in einer
> idealen Welt haetten wir auch keine RFC1918-Adressen noetig, weil
> public unique IP-Adresses fuer alle genuegend da waeren), nur leider
> ist diese Welt in dieser Hinsicht nicht ideal ...
Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
Routern niemandem, der es nicht verdient hat.
Juergen
--
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)
> Hallo,
>
> Sven Lanoster <SvenLa...@gmx.de> wrote:
>> Marc Haber schrieb:
>>> Marc, der von derartigen Superspezialexperten schon genug in seiner
>>> Liste stehen hat
>> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
>> Netzwerkgrenze gefiltert werden sollte.
>
> Als Source-Adresse? Als Destination-Adresse? Oder beides?
Mittels RPF und blackhole-routing ist beides technisch trivial.
>
> Sven Lanoster <SvenLa...@gmx.de> wrote:
>> Marc Haber schrieb:
>>> Marc, der von derartigen Superspezialexperten schon genug in seiner
>>> Liste stehen hat
>> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
>> Netzwerkgrenze gefiltert werden sollte.
>
> Als Source-Adresse? Als Destination-Adresse? Oder beides?
> Manche Filter lassen sich auf manchen Geraeten auch nicht ohne
> deutlichen Performance-Impact realisieren. Und wer schon einmal
> Spass damit hatte, dass ICMP-unreachable-Meldungen dank etwas
> Unbedachtheit bei der Planung des Netzes (RFC1918-Transfernetze)
> mit privaten Source-Adressen unterwegs waren und dann dank solcher
> Filter ploetzlich vor disfunktionaler PMTU stand, wird manche
> Forderung evt. auch zumindest mit etwas gemischten Gefuehlen
> betrachten ...
oeffentlichen Datenverkehr *SIND* oeffentliche Netze) einsetzt, den
sollte man mit der PMTUD-Keule so lange verpruegeln, bis er
Tokenring-Tokens sieht.
> In einer idealen Welt wuerden die Filter niemals schaden (in einer
> idealen Welt haetten wir auch keine RFC1918-Adressen noetig, weil
> public unique IP-Adresses fuer alle genuegend da waeren), nur leider
> ist diese Welt in dieser Hinsicht nicht ideal ...
Routern niemandem, der es nicht verdient hat.
Juergen
--
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)
Juergen Ilse
Aug 23, 2012, 2:57:59 AM8/23/12
to
Hallo,
Juergen P. Meier <nospa...@jors.net> wrote:
> Juergen Ilse <jue...@usenet-verwaltung.de>:
nur um das eigene AS geht) nicht mehr anwendbar. blackhole-routing ist
ohne Source-Adressbased Routing wirkungslos was die source-Adressen
betrifft.
> Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
> Routern niemandem, der es nicht verdient hat.
Man hat nicht alles unter Kontrolle, was den Traffic *durch* das eigene
Netz angeht. Und in der realen Welt setzt nicht jeder an allen "Endkunden-
Anschluessen" auch RPF ein, man kann als ueber Transit doch RFC1918-Schrott
hereinbekommen. Und den dann *erst* *im* *eigenen* *Netz* auszufiltern (weil
andere Ihre Hausaufgaben nicht gemacht haben) kann schon einmal an die
Grenzen des zumutbaren gehen ...
Juergen P. Meier <nospa...@jors.net> wrote:
> Juergen Ilse <jue...@usenet-verwaltung.de>:
>> Sven Lanoster <SvenLa...@gmx.de> wrote:
>>> Marc Haber schrieb:
>>>> Marc, der von derartigen Superspezialexperten schon genug in seiner
>>>> Liste stehen hat
>>> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
>>> Netzwerkgrenze gefiltert werden sollte.
>> Als Source-Adresse? Als Destination-Adresse? Oder beides?
> Mittels RPF und blackhole-routing ist beides technisch trivial.
RPF ist bei asymmetrischem Routing (der Normalfall, wenn es nicht mehr
>>> Marc Haber schrieb:
>>>> Marc, der von derartigen Superspezialexperten schon genug in seiner
>>>> Liste stehen hat
>>> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
>>> Netzwerkgrenze gefiltert werden sollte.
>> Als Source-Adresse? Als Destination-Adresse? Oder beides?
> Mittels RPF und blackhole-routing ist beides technisch trivial.
nur um das eigene AS geht) nicht mehr anwendbar. blackhole-routing ist
ohne Source-Adressbased Routing wirkungslos was die source-Adressen
betrifft.
> Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
> Routern niemandem, der es nicht verdient hat.
Netz angeht. Und in der realen Welt setzt nicht jeder an allen "Endkunden-
Anschluessen" auch RPF ein, man kann als ueber Transit doch RFC1918-Schrott
hereinbekommen. Und den dann *erst* *im* *eigenen* *Netz* auszufiltern (weil
andere Ihre Hausaufgaben nicht gemacht haben) kann schon einmal an die
Grenzen des zumutbaren gehen ...
Juergen P. Meier
Aug 24, 2012, 1:32:35 AM8/24/12
to
Juergen Ilse <jue...@usenet-verwaltung.de>:
anbindet, der muss auch fuer geeignete Filtertechnologien sorge
tragen.
> ohne Source-Adressbased Routing wirkungslos was die source-Adressen
> betrifft.
Man filtert dort, wo man CPE fuer PA-Kunden aggregiert. (oder wenn
man das Management der CPEs im Griff hat, am CPE)
Dort reicht ein RPF. Und wenn man keine Default-route hat, und zu den
CPEs hin sauber seine eigenen RFC1918 prefixe rausfiltert, gelangen
auch keine Pakete mit solchen Zieladdressen ins Netz.
>> Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
>> Routern niemandem, der es nicht verdient hat.
>
> Man hat nicht alles unter Kontrolle, was den Traffic *durch* das eigene
Als ISP der PA kunden anbindet, schon. Ansonsten sollte man sterben
und von jemandem aufgekauft werden, der was vom Geschaeft versteht.
> Netz angeht. Und in der realen Welt setzt nicht jeder an allen "Endkunden-
> Anschluessen" auch RPF ein, man kann als ueber Transit doch RFC1918-Schrott
Leider, ja. Weil das Aufwand bedeutet, und Aufwand = Geld.
> hereinbekommen. Und den dann *erst* *im* *eigenen* *Netz* auszufiltern (weil
> andere Ihre Hausaufgaben nicht gemacht haben) kann schon einmal an die
> Grenzen des zumutbaren gehen ...
Das Filtern ganz abzulehnen, weil man nicht 100% filtern kann, ist aber
auch eine reichlich daemliche Argumentation.
Sorry, aber man sollte tun was moeglich wo es moeglich ist - denn nur
so reduziert man solchen Muell signifikant.
> Juergen P. Meier <nospa...@jors.net> wrote:
>> Juergen Ilse <jue...@usenet-verwaltung.de>:
>>> Sven Lanoster <SvenLa...@gmx.de> wrote:
>>>> Marc Haber schrieb:
>>>>> Marc, der von derartigen Superspezialexperten schon genug in seiner
>>>>> Liste stehen hat
>>>> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
>>>> Netzwerkgrenze gefiltert werden sollte.
>>> Als Source-Adresse? Als Destination-Adresse? Oder beides?
>> Mittels RPF und blackhole-routing ist beides technisch trivial.
>
> RPF ist bei asymmetrischem Routing (der Normalfall, wenn es nicht mehr
> nur um das eigene AS geht) nicht mehr anwendbar. blackhole-routing ist
Es geht hier immernoch um PA Anschluesse. Wer seine PA asymmetrisch
>> Juergen Ilse <jue...@usenet-verwaltung.de>:
>>> Sven Lanoster <SvenLa...@gmx.de> wrote:
>>>> Marc Haber schrieb:
>>>>> Marc, der von derartigen Superspezialexperten schon genug in seiner
>>>>> Liste stehen hat
>>>> Schreib mich dazu. Ich finde immernoch, dass RFC1918 an der
>>>> Netzwerkgrenze gefiltert werden sollte.
>>> Als Source-Adresse? Als Destination-Adresse? Oder beides?
>> Mittels RPF und blackhole-routing ist beides technisch trivial.
>
> RPF ist bei asymmetrischem Routing (der Normalfall, wenn es nicht mehr
> nur um das eigene AS geht) nicht mehr anwendbar. blackhole-routing ist
anbindet, der muss auch fuer geeignete Filtertechnologien sorge
tragen.
> ohne Source-Adressbased Routing wirkungslos was die source-Adressen
> betrifft.
man das Management der CPEs im Griff hat, am CPE)
Dort reicht ein RPF. Und wenn man keine Default-route hat, und zu den
CPEs hin sauber seine eigenen RFC1918 prefixe rausfiltert, gelangen
auch keine Pakete mit solchen Zieladdressen ins Netz.
>> Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
>> Routern niemandem, der es nicht verdient hat.
>
> Man hat nicht alles unter Kontrolle, was den Traffic *durch* das eigene
und von jemandem aufgekauft werden, der was vom Geschaeft versteht.
> Netz angeht. Und in der realen Welt setzt nicht jeder an allen "Endkunden-
> Anschluessen" auch RPF ein, man kann als ueber Transit doch RFC1918-Schrott
> hereinbekommen. Und den dann *erst* *im* *eigenen* *Netz* auszufiltern (weil
> andere Ihre Hausaufgaben nicht gemacht haben) kann schon einmal an die
> Grenzen des zumutbaren gehen ...
auch eine reichlich daemliche Argumentation.
Sorry, aber man sollte tun was moeglich wo es moeglich ist - denn nur
so reduziert man solchen Muell signifikant.
Juergen Ilse
Aug 24, 2012, 2:47:31 AM8/24/12
to
Hallo,
vielleicht. Als anderer ISP: Nein.
>> Netz angeht. Und in der realen Welt setzt nicht jeder an allen "Endkunden-
>> Anschluessen" auch RPF ein, man kann als ueber Transit doch RFC1918-Schrott
> Leider, ja. Weil das Aufwand bedeutet, und Aufwand = Geld.
Man muss mit der Situation leben, wie sie nun einmal ist. Und in der
realen Welt hat man im Gegensatz zu irgendwelchen idealistischen Vor-
stellungen eben weit weniger des Netzes unter Kontrolle als man sich
vielleicht wuenscht. Ich habe sogar mal (vor Jahren) gesehen, dass
ein BGP-Peer in einem Internet-Exchange versuchte, meinem Broetchen-
geber RFC1918-Prefixe per BGP zu announcen (was dank entsprechender
Filter nicht angenommen wurde), und in diesem Fall hat der Kollege
vom anderen ISP dieses Fehlverhalten nach einem entsprechenden Hin-
weis sogar abgestellt ...
>> hereinbekommen. Und den dann *erst* *im* *eigenen* *Netz* auszufiltern (weil
>> andere Ihre Hausaufgaben nicht gemacht haben) kann schon einmal an die
>> Grenzen des zumutbaren gehen ...
> Das Filtern ganz abzulehnen, weil man nicht 100% filtern kann, ist aber
> auch eine reichlich daemliche Argumentation.
Ich lehne das Filtern (dort wo es praktikabel ist) ja nicht ganz ab.
Ich weise nur darauf hin, dass man (zumindest als jemand mit multi-
homed Anbindung, wie es mit eigenem AS eben ueblich ist) nicht immer
so trivial ist, weil man dann eben manchen Schrott auch ueber Wege
hereinbekommt, wo filtern eben *nicht* praktikabel ist ...
Wo Filtern praktikabel ist, wird es bei meinem Broetchengeber auch
durchgefuehrt, aber das ist eben nicht ueberall der Fall.
>> Man hat nicht alles unter Kontrolle, was den Traffic *durch* das eigene
> Als ISP der PA kunden anbindet, schon.
Als kleiner Krauter ohne redundante Uplinks und ohne Transitkunden
> Als ISP der PA kunden anbindet, schon.
vielleicht. Als anderer ISP: Nein.
>> Netz angeht. Und in der realen Welt setzt nicht jeder an allen "Endkunden-
>> Anschluessen" auch RPF ein, man kann als ueber Transit doch RFC1918-Schrott
> Leider, ja. Weil das Aufwand bedeutet, und Aufwand = Geld.
realen Welt hat man im Gegensatz zu irgendwelchen idealistischen Vor-
stellungen eben weit weniger des Netzes unter Kontrolle als man sich
vielleicht wuenscht. Ich habe sogar mal (vor Jahren) gesehen, dass
ein BGP-Peer in einem Internet-Exchange versuchte, meinem Broetchen-
geber RFC1918-Prefixe per BGP zu announcen (was dank entsprechender
Filter nicht angenommen wurde), und in diesem Fall hat der Kollege
vom anderen ISP dieses Fehlverhalten nach einem entsprechenden Hin-
weis sogar abgestellt ...
>> hereinbekommen. Und den dann *erst* *im* *eigenen* *Netz* auszufiltern (weil
>> andere Ihre Hausaufgaben nicht gemacht haben) kann schon einmal an die
>> Grenzen des zumutbaren gehen ...
> Das Filtern ganz abzulehnen, weil man nicht 100% filtern kann, ist aber
> auch eine reichlich daemliche Argumentation.
Ich weise nur darauf hin, dass man (zumindest als jemand mit multi-
homed Anbindung, wie es mit eigenem AS eben ueblich ist) nicht immer
so trivial ist, weil man dann eben manchen Schrott auch ueber Wege
hereinbekommt, wo filtern eben *nicht* praktikabel ist ...
Wo Filtern praktikabel ist, wird es bei meinem Broetchengeber auch
durchgefuehrt, aber das ist eben nicht ueberall der Fall.
Paul Muster
Aug 25, 2012, 4:15:19 AM8/25/12
to
On 24.08.2012 08:47, Juergen Ilse wrote:
> Ich habe sogar mal (vor Jahren) gesehen, dass
> ein BGP-Peer in einem Internet-Exchange versuchte, meinem Broetchen-
> geber RFC1918-Prefixe per BGP zu announcen
"accounce connected" oder so ähnlich. Ist doch bequem. ;-)
> Ich habe sogar mal (vor Jahren) gesehen, dass
> ein BGP-Peer in einem Internet-Exchange versuchte, meinem Broetchen-
> geber RFC1918-Prefixe per BGP zu announcen
mfG Paul
Marc Haber
Oct 28, 2012, 3:49:54 AM10/28/12
to
"Juergen P. Meier" <nospa...@jors.net> wrote:
>Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
>Routern niemandem, der es nicht verdient hat.
Also jemandem, der gerne zwischen zwei IPv6-ISPs migrieren möchte, und
>Routern niemandem, der es nicht verdient hat.
sich auf die Marketingaussage der IPv6-Fans verlassen hat, dass
Renumbern ohne Sauereien und einfach möglich ist?
Grüße
Marc
P.S.: Sorry für die späte Antwort, aber diese Vorlage war einfach _zu_
steil.
Message has been deleted
Marc Haber
Oct 30, 2012, 4:00:58 PM10/30/12
to
"Oliver Sch@d"
<spam.entfernen.und.bring...@oschad.de> wrote:
>IPv6-Fans gesagt haben. Ist das Feature nicht eigentlich auch bei IPv4
>implementiert worden? Ja ich weiß, zwischen Implementierung und Standard
>ist ein kleiner semantischer Unterschied.
>
>Ich verstehe allerdings nicht, wie jetzt Filter beim Provider was
>versauen, solange du an deinem Gateway den Traffic mit einer
>entsprechenden Source-Route verschiebst an deine Provider.
Eine Source-Route empfinde ich schon als Sauerei. So richtig einfach
ist das nur, wenn mir alle meine ISPs erlauben, outgoing alle meine
zugeteilten Prefixe zu verwenden. Früher war das einfach, weil alle
daran interessiert waren, dass ich meinen Traffic bei ihnen abkippe
und nicht woanders, aber inzwischen, in der Zeit von Flatrates...
Grüße
Marc
<spam.entfernen.und.bring...@oschad.de> wrote:
>Marc Haber wrote:
>> "Juergen P. Meier" <nospa...@jors.net> wrote:
>>>Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
>>>Routern niemandem, der es nicht verdient hat.
>>
>> Also jemandem, der gerne zwischen zwei IPv6-ISPs migrieren möchte, und
>> sich auf die Marketingaussage der IPv6-Fans verlassen hat, dass
>> Renumbern ohne Sauereien und einfach möglich ist?
>
>Äh - ich hoffe inständig, dass das eigentlich "einfacher" war, was diese
>> "Juergen P. Meier" <nospa...@jors.net> wrote:
>>>Auch in einer Realen Welt schaden RPF an PA-Kunden-Downstreams/Access
>>>Routern niemandem, der es nicht verdient hat.
>>
>> Also jemandem, der gerne zwischen zwei IPv6-ISPs migrieren möchte, und
>> sich auf die Marketingaussage der IPv6-Fans verlassen hat, dass
>> Renumbern ohne Sauereien und einfach möglich ist?
>
>IPv6-Fans gesagt haben. Ist das Feature nicht eigentlich auch bei IPv4
>implementiert worden? Ja ich weiß, zwischen Implementierung und Standard
>ist ein kleiner semantischer Unterschied.
>
>Ich verstehe allerdings nicht, wie jetzt Filter beim Provider was
>versauen, solange du an deinem Gateway den Traffic mit einer
>entsprechenden Source-Route verschiebst an deine Provider.
Eine Source-Route empfinde ich schon als Sauerei. So richtig einfach
ist das nur, wenn mir alle meine ISPs erlauben, outgoing alle meine
zugeteilten Prefixe zu verwenden. Früher war das einfach, weil alle
daran interessiert waren, dass ich meinen Traffic bei ihnen abkippe
und nicht woanders, aber inzwischen, in der Zeit von Flatrates...
Grüße
Marc
Message has been deleted
Marc Haber
Nov 3, 2012, 6:37:47 PM11/3/12
to
"Oliver Sch@d"
<spam.entfernen.und.bring...@oschad.de> wrote:
>Ich sehe ja ein, dass bei IPv6 sicher nicht alles Gold ist, was glänzt,
>aber der absolute Müll ist es nun auch wieder nicht.
Das hat ja auch niemand behauptet.
>Wie verhalten sich eigentlich UDP-Anwendungen bei Adress-Migration
>zwischen zwei IPv6-Präfixen? Schonmal probiert? Mmh, ich muss mal einen
>Teststand aufbauen.
Ich würde erwarten, dass bei Anwendungen, die einfach ::0 binden,
dieselbe <zensiert> entsteht wie bei IPv4, nämlich dass die Antwort
mit der IP-Adresse rausgeht, die das System für ausgehende Pakete ohne
Kontext verwendet, und dass das nicht notwendigerweise die Adresse
ist, an die die Anfrage gestellt wurde.
<spam.entfernen.und.bring...@oschad.de> wrote:
>Ich sehe ja ein, dass bei IPv6 sicher nicht alles Gold ist, was glänzt,
>aber der absolute Müll ist es nun auch wieder nicht.
Das hat ja auch niemand behauptet.
>Wie verhalten sich eigentlich UDP-Anwendungen bei Adress-Migration
>zwischen zwei IPv6-Präfixen? Schonmal probiert? Mmh, ich muss mal einen
>Teststand aufbauen.
Ich würde erwarten, dass bei Anwendungen, die einfach ::0 binden,
dieselbe <zensiert> entsteht wie bei IPv4, nämlich dass die Antwort
mit der IP-Adresse rausgeht, die das System für ausgehende Pakete ohne
Kontext verwendet, und dass das nicht notwendigerweise die Adresse
ist, an die die Anfrage gestellt wurde.
0 new messages