Natuurlijk weet ik dat je op sommige plekken moet filteren, maar we zien de laatste tijd nogal veel packets met een source-address van 127.0.0.1 en source-port 80 door ons netwerk heen komen, zijn allemaal 40 bytes packets met het reset vlaggetje aan. Zien andere mensen dit ook en heeft iemand een idee wat dit kan veroorzaken, het gaat niet over een paar pakketjes...heb er de laatste 3 uur al 2088053 voorbij zien komen en dat zijn dan alleen onze dsl klantjes. We zitten dezelfde te denken aan brakke modem software, die een syn naar port 80 beantwoord met een reset vanaf localhost, maar het zou evengoed een nieuw type vuurmuur kunnen zijn. Grtx, MarcoH
On Mon, 13 Oct 2003, MarcoH wrote:
Natuurlijk weet ik dat je op sommige plekken moet filteren, maar we zien de laatste tijd nogal veel packets met een source-address van 127.0.0.1 en source-port 80 door ons netwerk heen komen, zijn allemaal 40 bytes packets met het reset vlaggetje aan.
Time of Log: 2003-10-13 16:40:53 CEST, Filter: pfe, Filter action: discard, Name of interface: fe-0/0/0.0 Name of protocol: TCP, Packet Length: 40, Source address: 127.0.0.1:80, Destination address: 81.4.xx.xx:1268 Zelfde hier, op alle interfaces, naar willekeurige adressen binnen ons netwerk. Blijf het raar vinden dat er isp's zijn die geen RFC1918 filteren. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
On Mon, 13 Oct 2003, ProServe - Peter Batenburg wrote:
Zelfde hier, op alle interfaces, naar willekeurige adressen binnen ons netwerk. Blijf het raar vinden dat er isp's zijn die geen RFC1918 filteren.
127.0.0.0/8 != RFC1918. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 13 Oct 2003, Alex Bik wrote:
Zelfde hier, op alle interfaces, naar willekeurige adressen binnen ons netwerk. Blijf het raar vinden dat er isp's zijn die geen RFC1918 filteren.
127.0.0.0/8 != RFC1918.
Hm, dan moet ik de naam van me prefix list maar eens aan gaan passen dan :) Buiten 127.0.0.0/8 komt er sowieso belachelijk veel rfc1918 zooi ook binnen hier, wat niet zou moeten naar mijn idee. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
On Mon, Oct 13, 2003 at 04:47:39PM +0200, ProServe - Peter Batenburg wrote:
Zelfde hier, op alle interfaces, naar willekeurige adressen binnen ons netwerk. Blijf het raar vinden dat er isp's zijn die geen RFC1918 filteren.
127.0.0.0/8 != RFC1918.
Hm, dan moet ik de naam van me prefix list maar eens aan gaan passen dan :) Buiten 127.0.0.0/8 komt er sowieso belachelijk veel rfc1918 zooi ook binnen hier, wat niet zou moeten naar mijn idee.
Zolang je icmp maar doorlaat. Ja want er zijn mensen die dat soort adressen gebruiken voor hun router interface en ja als je alle rfc1918 weg pleurt kan je dingen slopen. MarcoH
On Mon, 13 Oct 2003, MarcoH wrote:
On Mon, Oct 13, 2003 at 04:47:39PM +0200, ProServe - Peter Batenburg wrote:
Buiten 127.0.0.0/8 komt er sowieso belachelijk veel rfc1918 zooi ook binnen hier, wat niet zou moeten naar mijn idee.
Zolang je icmp maar doorlaat. Ja want er zijn mensen die dat soort adressen gebruiken voor hun router interface en ja als je alle rfc1918 weg pleurt kan je dingen slopen.
term 1 { from { prefix-list { rfc1918; } } then { discard; } } In alle filters, op alle uplink interfaces, zowel in als uit. En voor zover ik weet gaat er hier vrij weinig stuk. Ook bij DSL gebruikers. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
On Mon, 13 Oct 2003, MarcoH wrote:
On Mon, Oct 13, 2003 at 04:47:39PM +0200, ProServe - Peter Batenburg wrote:
Buiten 127.0.0.0/8 komt er sowieso belachelijk veel rfc1918 zooi ook binnen hier, wat niet zou moeten naar mijn idee.
Zolang je icmp maar doorlaat. Ja want er zijn mensen die dat soort adressen gebruiken voor hun router interface en ja als je alle rfc1918 weg pleurt kan je dingen slopen.
term 1 { from { prefix-list { rfc1918; } } then { discard; } }
In alle filters, op alle uplink interfaces, zowel in als uit.
En voor zover ik weet gaat er hier vrij weinig stuk. Ook bij DSL gebruikers.
Het volgende kan stuk gaan : AS-CLUELESS gebruikt rfc1918 adressen op de interne links tussen hun routers. Die hebben ook nog een kleine(re) MTU dan de rest van het pad tussen jouw bezoekers en content achter/in hun netwerk. De PMTU discovery die door jou gedaan wordt, krijgt dan niet de icmp message die gestuurd wordt door hun router, met een source adres uit rfc1918 . Niks aan doen, het blijft een probleem van AS-CLUELESS. Ik geloof overigens niet dat dit probleem (netwerken met rfc1918 op interne links) veel voorkomt. Firewall nitwits, die zelf alle ICMP droppen, hebben ook zo'n probleem. En buiten PMTU discovery een vervelende timeout, wanneer ze de netwerk unreachable message van de eerste router die default-free is droppen. Overigens zou het beter zijn om uitgaand alles wat NOT Jouw_space is te droppen, ipv van alleen rfc1918+localhost oid . (of doe je dat al in overige filters) (En evt inkomend alles waarvoor geen route bestaat). Boudewijn
On Mon, 13 Oct 2003, Boudewijn Visser wrote:
Niks aan doen, het blijft een probleem van AS-CLUELESS. Ik geloof overigens niet dat dit probleem (netwerken met rfc1918 op interne links) veel voorkomt.
Ik ben wel eens wat RFC1918 space tegengekomen in traceroutes, maar ik ben het met je eens als je zegt dat dat het probleem van AS-CLUELESS is. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 13 Oct 2003, Boudewijn Visser wrote:
En voor zover ik weet gaat er hier vrij weinig stuk. Ook bij DSL gebruikers. Het volgende kan stuk gaan :
==KNIP== Nog nooit klachten gehoord in deze richting, dus wat mij betreft blijven deze filtertjes lekker staan.
Overigens zou het beter zijn om uitgaand alles wat NOT Jouw_space is te droppen, ipv van alleen rfc1918+localhost oid . (of doe je dat al in overige filters) (En evt inkomend alles waarvoor geen route bestaat).
Deze term was eigenlijk alleen voor het loggen. Zie hiervoor: http://www.pro-noc.nl/public/routers.m[10,5,5-2]/filters/ Verder allow ik alleen uitgaand wat een source adres heeft uit onze ranges, en inkomend alleen wat destination in 1 van die ranges heeft. Dat lijkt nog vrij lastig voor veel ISPs, helaas. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
On Mon, Oct 13, 2003 at 05:52:04PM +0200, Boudewijn Visser wrote:
(En evt inkomend alles waarvoor geen route bestaat).
Ook dat wil je niet. Je hebt immers nog steeds van die clueloze rukkers die menen dat bijv. IX ip-space niet globally routable hoeft te zijn. -- Sabri Berisha "I route, therefore you are" "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
Hi,
On Mon, Oct 13, 2003 at 05:52:04PM +0200, Boudewijn Visser wrote:
(En evt inkomend alles waarvoor geen route bestaat).
Ook dat wil je niet. Je hebt immers nog steeds van die clueloze rukkers die menen dat bijv. IX ip-space niet globally routable hoeft te zijn.
Met name RIPE. RIPE vindt dat IX space niet persee globally routable hoeft te zijn. Nieuwe IX'en krijgen dus nomaal gesproken een klein blokje PI space, kleiner dan een Class C. Een nieuwe IX moet wel van hele goede huize komen om te kunnen aantonen dat hij meteen 256 IP adressen moet hebben omdat het wel duidelijk is dat hij onmiddelijk 64 en binnen een jaar 128 deelnemers heeft. RIPE denkt ook niet dat omnummeren voor een IX een grote issue is dan omnummeren voor een 'gewone' address space aanvrager. Verder zou een voordeel van het niet announcen van IX space kunnen zijn dat DDOS attacks op exchange IP adressen (dus op de exchange interface van peering routers) en eventuele andere hack-pogingen in ieder geval niet meer vanuit de rest van de wereld kunnen komen: alleen gebruikers en klanten van IX deelnemers kunnen dat dan nog doen, en dat is iets makkelijker te traceren en iets makkelijker maatregelen nemen. Een groot nadeel is natuurlijk dat debuggen (traceroute en ping) van partijen die niet zelf directly-connected op de exchange zijn een stuk moeilijker wordt. Groeten, Jan. -- Jan Hoogenboom jan at openpeering.nl Open Peering Initiative http://www.openpeering.nl +31 (0)70 363 16 61
On Tue, Oct 14, 2003 at 11:17:16AM +0200, Jan Hoogenboom wrote:
Een groot nadeel is natuurlijk dat debuggen (traceroute en ping) van partijen die niet zelf directly-connected op de exchange zijn een stuk moeilijker wordt.
traceroute zou er geen last van moeten hebben... MarcoH
Hoi,
traceroute zou er geen last van moeten hebben...
Klopt. Maar wanneer je problemen hebt (bijvoorbeeld packetloss of bepaalde packetsizes die er niet doorheen komen) en wilt traceren op welke hop of link in de route die beginnen dan wil je een traceroute doen en vervolgens ieder hop individueel pingen (wat 'mtr' ook doet). Dat kan dus niet als de address space van een hop net geroute wordt. Groeten, Jan. -- Jan Hoogenboom jan at openpeering.nl Open Peering Initiative http://www.openpeering.nl +31 (0)70 363 16 61
On Tue, 14 Oct 2003, Jan Hoogenboom wrote:
Klopt. Maar wanneer je problemen hebt (bijvoorbeeld packetloss of bepaalde packetsizes die er niet doorheen komen) en wilt traceren op welke hop of link in de route die beginnen dan wil je een traceroute doen en vervolgens ieder hop individueel pingen (wat 'mtr' ook doet). Dat kan dus niet als de address space van een hop net geroute wordt.
Je kunt met een lagere TTL pingen naar de hop erachter. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
Hoi,
traceroute zou er geen last van moeten hebben...
Klopt. Maar wanneer je problemen hebt (bijvoorbeeld packetloss of bepaalde packetsizes die er niet doorheen komen) en wilt traceren op welke hop of link in de route die beginnen dan wil je een traceroute doen en vervolgens ieder hop individueel pingen (wat 'mtr' ook doet). Dat kan dus niet als de address space van een hop net geroute wordt.
nitpickje : mtr gebruikt al geruime tijd 'alleen' de traceroute-methode, icmp echo naar de opgegeven bestemming met verschillende TTL's, en haalt daar de RTT's van de tussenliggende hops uit. Het is geen traceroute naar bestemming en expliciete pings naar de hops ertussen meer. De manpage ervan is pas veel later aangepast aan de werkwijze. Boudewijn
Hoi, | nitpickje : mtr gebruikt al geruime tijd 'alleen' de traceroute-methode, | icmp echo naar de opgegeven bestemming met verschillende TTL's, en | haalt daar de RTT's van de tussenliggende hops uit. Omdat ik hierover al eens een keertje een opmerking heb gemaakt her en der, voeg ik 'm hier ook even in ;-) Traceroute (het standaard ding) gebruikt geen ICMP maar UDP packets met ophogende TTL. Er wordt door de client dus enkel UDP packets gestuurd, door de intermediaire routers ICMP ttl-exceeded foutmelding terug naar de client. De reden dat traceroute nog setuid moet zijn is dat hij een raw socket moet binden om deze ICMP foutmeldingen te ontvangen, dus niet (wat erg veel mensen denken) om ICMP echo's te sturen naar de remote-host met ophogende TTL. -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
Hoi,
| nitpickje : mtr gebruikt al geruime tijd 'alleen' de traceroute-methode, | icmp echo naar de opgegeven bestemming met verschillende TTL's, en | haalt daar de RTT's van de tussenliggende hops uit. Omdat ik hierover al eens een keertje een opmerking heb gemaakt her en der, voeg ik 'm hier ook even in ;-)
Traceroute (het standaard ding) gebruikt geen ICMP maar UDP packets met ophogende TTL. Er wordt door de client dus enkel UDP packets gestuurd, door de intermediaire routers ICMP ttl-exceeded foutmelding terug naar de client.
Dat weet ik (natuurlijk ;-) ) wel, maar ik schreef dan ook methode, refererend aan het concept van ophogende TTL en het afvangen van de TTL exceeded message. Inderdaad gebruikt de klassieke (default unixen, cisco) traceroute een trits UDP poorten; Hoe weinig ik ook moet hebben van Microsoft (de bekendste gebruiker van icmp echo gebaseerde traceroute), die berg UDP poorten is een vrij lelijke oplossing. De reden dat Van Jacobson koos voor UDP was dat in die tijd (1988) een voldoende groot aantal router IP stack schrijvers heel erg strikt waren in de RFC interpretatie dat er geen ICMP message gestuurd mocht worden naar aanleiding van een ICMP message. (bedoeld om loops van errors op errors te voorkomen), en de eerste traceroute versie (met icmp echo) dus niet werkte. Dat probleem is inmiddels toch wel verholpen ; Met de natte vinger schat ik dat met de opkomst van firewalls een icmp-echo gebaseerde traceroute een ietwat betere kans heeft om doorgelaten te worden dan een udp variant. (heb wel eens een klacht gehad van iemand wiens IDS een UDP poortscan gezien had, poort 3343x e.v. , source was een router.... ) [..] Boudewijn
On Tue, 14 Oct 2003, Jan Hoogenboom wrote:
Met name RIPE. RIPE vindt dat IX space niet persee globally routable hoeft te zijn. Nieuwe IX'en krijgen dus nomaal gesproken een klein blokje PI space, kleiner dan een Class C. Een nieuwe IX moet wel van hele goede huize komen om te kunnen aantonen dat hij meteen 256 IP adressen moet hebben omdat het wel duidelijk is dat hij onmiddelijk 64 en binnen een jaar 128 deelnemers heeft. RIPE denkt ook niet dat omnummeren voor een IX een grote issue is dan omnummeren voor een 'gewone' address space aanvrager.
Wat overigens op AMS-IX laatst is aangetoond.
Verder zou een voordeel van het niet announcen van IX space kunnen zijn dat DDOS attacks op exchange IP adressen (dus op de exchange interface van peering routers) en eventuele andere hack-pogingen in ieder geval niet meer vanuit de rest van de wereld kunnen komen: alleen gebruikers en klanten van IX deelnemers kunnen dat dan nog doen, en dat is iets makkelijker te traceren en iets makkelijker maatregelen nemen.
Wat IMHO een non-argument is, want die routers hebben nog meer interfaces, waarvan de IP adressen meestal niet al te moeilijk te achterhalen zijn. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Tue, 2003-10-14 at 11:56, Alex Bik wrote:
RIPE denkt ook niet dat omnummeren voor een IX een grote issue is dan omnummeren voor een 'gewone' address space aanvrager.
Wat overigens op AMS-IX laatst is aangetoond.
Oh? Er zaten weliswaar wat haken en ogen aan, maar over het algemeen was 't niet slecht. En we hebben een hoop geleerd voor een volgende keer: oefening baart kunst, nietwaar? We dachten er zelf over om voortaan tijdens elke RIPE meeting de AMS-IX te hernummeren. Is wel zo gezellig (met name een zekere MD te L. was zeer te spreken over de hands-on-neck support van ons aller Niels ;-) en ik vermoed dat we dan over een paar jaar onze hand niet meer omdraaien voor een hernummerinkje op een willekeurige IX... Toch? Nee, niets te danken, dit doen wij graag voor de algehele educatie van de gemeenschap. :-) Groeten, Steven -- Steven Bakker tel: +31 (20) 514 1719 Amsterdam Internet Exchange mobile: +31 6 518 36 409 http://www.ams-ix.net e-mail: Steven.Bakker at ams-ix.net
On Tue, 14 Oct 2003, Steven Bakker wrote:
RIPE denkt ook niet dat omnummeren voor een IX een grote issue is dan omnummeren voor een 'gewone' address space aanvrager.
Wat overigens op AMS-IX laatst is aangetoond.
Oh? Er zaten weliswaar wat haken en ogen aan, maar over het algemeen was 't niet slecht.
RIPE denkt _NIET_ dat het omnummeren voor een IX een grote issue is. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Tue, 2003-10-14 at 12:43, Alex Bik wrote:
Oh? Er zaten weliswaar wat haken en ogen aan, maar over het algemeen was 't niet slecht.
RIPE denkt _NIET_ dat het omnummeren voor een IX een grote issue is.
Mmmh, ik dacht dat het "Wat ... op AMS-IX ... is aangetoond" sloeg op een ontkenning van het idee van RIPE. Misschien verkeerd gelezen... anyway... Maar goed, om het expliciet te maken: omnummeren is natuurlijk helemaal geen grote issue: als we maar vaak genoeg oefenen, wordt het vanzelf een ingesleten routine handeling. Oh, en om de ironie expliciet te maken: ;-) -- </s>
On Tue, Oct 14, 2003 at 12:23:46PM +0200, Steven Bakker wrote:
We dachten er zelf over om voortaan tijdens elke RIPE meeting de AMS-IX te hernummeren. Is wel zo gezellig (met name een zekere MD te L. was zeer te spreken over de hands-on-neck support van ons aller Niels ;-) en ik vermoed dat we dan over een paar jaar onze hand niet meer omdraaien voor een hernummerinkje op een willekeurige IX... Toch? Nee, niets te danken, dit doen wij graag voor de algehele educatie van de gemeenschap.
Moeten we nog wel even wat mensen uitleggen hoe ssh werkt en hoe je dan vanaf de ripe meeting je omnummer actie kan doen :) MarcoH
-----BEGIN PGP SIGNED MESSAGE----- MarcoH wrote:
On Tue, Oct 14, 2003 at 12:23:46PM +0200, Steven Bakker wrote:
We dachten er zelf over om voortaan tijdens elke RIPE meeting de AMS-IX te hernummeren. Is wel zo gezellig (met name een zekere MD te L. was zeer te spreken over de hands-on-neck support van ons aller Niels ;-) en ik vermoed dat we dan over een paar jaar onze hand niet meer omdraaien voor een hernummerinkje op een willekeurige IX... Toch? Nee, niets te danken, dit doen wij graag voor de algehele educatie van de gemeenschap.
Moeten we nog wel even wat mensen uitleggen hoe ssh werkt en hoe je dan vanaf de ripe meeting je omnummer actie kan doen :)
PuTTY is niet zo moeilijk toch? :) En zowiezo die commandline van OpenSSH doet het ook best. Anders moeten we ze gewoon uitleggen hoe het openbaar vervoer in Amsterdam werkt, loop naar CS, trein naar .... :) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP4vjqSmqKFIzPnwjEQKIXQCffmCzsyT19ory+aictkm0yUuQirwAnRia FhozyMYu7Z5EdLKji0fjQYm8 =yKXD -----END PGP SIGNATURE-----
On Mon, Oct 13, 2003 at 05:52:04PM +0200, Boudewijn Visser wrote:
(En evt inkomend alles waarvoor geen route bestaat).
Ook dat wil je niet. Je hebt immers nog steeds van die clueloze rukkers die menen dat bijv. IX ip-space niet globally routable hoeft te zijn.
Mww. Dat is een afweging. Het (non-routed IX ip space) is, wat PMTU discovery betreft, alleen een probleem als : 1 : de IX space niet (ook niet als aggregate) in de global routing table zit 2 : de MTU van de IX de kleinste is op het pad tussen client en server 3 : Client of server wel over de IX communiceren, maar tenminste 1 van beiden niet in een direct aan die IX aangesloten netwerk zit. Ik verwacht dat de combinatie van deze drie zaken toch wel erg zeldzaam zal zijn. en uRPF gebruiken om alle "mag niet voorkomen" source adressen meteen te droppen is wel heel aantrekkelijk. Het maakt inderdaad troubleshooten met ping & trace van problemen op de exchange voor verder weg gelegen partijen (niet connected) wel lastiger. Boudewijn
On Mon, Oct 13, 2003 at 04:47:39PM +0200, ProServe - Peter Batenburg wrote:
Zelfde hier, op alle interfaces, naar willekeurige adressen binnen ons netwerk. Blijf het raar vinden dat er isp's zijn die geen RFC1918 filteren.
127.0.0.0/8 != RFC1918.
Hm, dan moet ik de naam van me prefix list maar eens aan gaan passen dan :) Buiten 127.0.0.0/8 komt er sowieso belachelijk veel rfc1918 zooi ook binnen hier, wat niet zou moeten naar mijn idee.
Zolang je icmp maar doorlaat. Ja want er zijn mensen die dat soort adressen gebruiken voor hun router interface en ja als je alle rfc1918 weg pleurt kan je dingen slopen.
Ik vind het een slecht idee om 'obviously invalid' source addressen te accepteren omdat er idioten zijn die zulke adressen ergens (zichtbaar) gebruiken. Er zijn (hopelijk..) genoeg netwerken die onderweg rfc1918 droppen, zodat de kans vrij reeel is dat een netwerk dat ze gebruikt toch problematisch is voor heel veel bezoekers. (te verwachten probleem : hinderlijke timeout vanwege het missen van host/netwerk unknown, en breken van path mtu discovery ) Overigens, als het 127.0.0.1 pakket zoveel gezien wordt, moet het voor wat mensen hier die hun access laag zelf beheren en daar anti-spoofing op aan hebben staan toch wel lukken om een paar bronnen te betrappen ? Boudewijn
MarcoH _______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog
On Mon, Oct 13, 2003 at 05:19:47PM +0200, Boudewijn Visser wrote:
Overigens, als het 127.0.0.1 pakket zoveel gezien wordt, moet het voor wat mensen hier die hun access laag zelf beheren en daar anti-spoofing op aan hebben staan toch wel lukken om een paar bronnen te betrappen ?
Om terug te komen op de orginele vraagstelling, daar was ik dus in wezen naar op zoek. Ik kan het terugvinden tot het niveau van "ergens tussn paar duizend dsl klanten", maar heb geen clue of het een probleem is wat specifiek geldt voor ons/bbned of dat andere mensen het ook zien en dat misschien terug weten te brengen naar iets specifiekere apparatuur/software. Zoals ik al schreef we verdenken de modems, maar nog geen spoor van welke het zijn, hoewel de firma zyxell een redelijke kans maakt aangezien die in grote aantallen verstuurd zijn/worden. MarcoH
-----BEGIN PGP SIGNED MESSAGE----- MarcoH wrote: <SNIP>
Buiten 127.0.0.0/8 komt er sowieso belachelijk veel rfc1918 zooi ook binnen hier, wat niet zou moeten naar mijn idee.
Zolang je icmp maar doorlaat. Ja want er zijn mensen die dat soort adressen gebruiken voor hun router interface en ja als je alle rfc1918 weg pleurt kan je dingen slopen.
Path MTU gaat dan idd stuk als je icmp's dropped. Maar ik denk dat je dat beter stuk kan laten gaan want dan merken die mensen misschien eens dat ze eigenlijk hele erge stukke apparatuur/instellingen hebben die rfc1918 over het publieke internet sturen. Gerelateerd iets; hoeveel folks hier doen mee met het AS112 project, aka om reverse query's af te vangen? Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP4rFgSmqKFIzPnwjEQK3vQCeLfUyii3s8dLJNOoKCkbl9wZpFeQAoMAw 55tyMF12Dg/d+Kr8mrpTqiuE =Y8JY -----END PGP SIGNATURE-----
On Mon, 13 Oct 2003, ProServe - Peter Batenburg wrote:
127.0.0.0/8 != RFC1918.
Hm, dan moet ik de naam van me prefix list maar eens aan gaan passen dan :)
Als die pl naast 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16 ook 127.0.0.0/8 bevat wel ja :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
participants (9)
-
alex＠bit.nl -
bvisser-nlnog＠xs4all.nl -
jan＠openpeering.nl -
jeroen＠unfix.org -
marcoh＠marcoh.net -
peter＠proserve.nl -
pim＠bit.nl -
sabri＠cluecentral.net -
steven.bakker＠ams-ix.net