IP header & TTL modificatie door bridges
Heren, Ik zit met het volgende, het lijkt me dat er hier wel mensen zijn met een meer of minder uitgesproken mening over het volgende, waar ik bovengemiddelde interesse heb: Feiten: ik heb hier een device wat zich gedraagt als wat ik als 'wireless bridge' zou omschrijven. Het device verstuurt over het AIR interface geen Ethernet maar alleen IPv4. Ethernet headers worden na wireless transmissie er weer aan geklust door beide kanten. Het device routeert niet, het is puur een punt-punt verbinding. Echter, het beestje is in staat om DSCP values te modificeren aan de hand van een bepaalde config. Het (imho) discutabele gedrag: het beestje verlaagt de TTL van alle passerende IP pakketjes, maar aangezien het geen router is stuurt het ook geen ICMP uit (at least, niet in de dataplane). Maar door het verlagen van de TTL en het niet uitsturen van unreachables verschijnt de het betreffende device wel in een traceroute maar geeft door het onbreken van de unreachables uiteraard verder geen info prijs. Mijn argument: het ding is geen router/host als bedoeld in rfc791 en ondanks het feit dat het kreng DSCP kan modificeren zie ik geen reden waarom ie met zn tengels aan de TTL zou moeten zitten. Heeft iemand hier iets over te zeggen, zowel pro als con is uiteraard welkom. Arjan
On Mon, 24 Sep 2007 13:00:25 +0200 Arjan van der Oest wrote:
Mijn argument: het ding is geen router/host als bedoeld in rfc791 en ondanks het feit dat het kreng DSCP kan modificeren zie ik geen reden waarom ie met zn tengels aan de TTL zou moeten zitten.
Heeft iemand hier iets over te zeggen, zowel pro als con is uiteraard welkom.
RFC791 heeft het over "every module that processes a datagram must the TTL by at least one" en er staat volgens mij niets vermeld over het MOETEN versturen van ICMP unreachables m.b.t. TTL. Als-ie dus ergens in de IP headers interpreteert kun je (zwak) beargumenteren dat hij een "module that processes a datagram". Dat gezegd hebbende, als het ding niet van zins is ICMP unreachables terug te sturen moet het m.i. van de TTL afblijven... -- Steven
Heren,
Ik zit met het volgende, het lijkt me dat er hier wel mensen zijn met een meer of minder uitgesproken mening over het volgende, waar ik bovengemiddelde interesse heb:
[knip wireless bridge, speelt met DSCP en doet ook TTL decrement]
de het betreffende device wel in een traceroute maar geeft door het onbreken van de unreachables uiteraard verder geen info prijs.
Mijn argument: het ding is geen router/host als bedoeld in rfc791 en ondanks het feit dat het kreng DSCP kan modificeren zie ik geen reden waarom ie met zn tengels aan de TTL zou moeten zitten.
Heeft iemand hier iets over te zeggen, zowel pro als con is uiteraard welkom.
Mee eens, dwz, ik vind het wel TTL decrementen, en dan niet sturen van unreachables ook verkeerd gedrag, en kan er niet echt een argument voor verzinnen waarom je het zou willen. Het enige wat me nu voor de geest komt is dat de * * * in de traceroute een indicatie geeft dat het pad tussen twee hops "bijzonder" is [radio<->ethernet] en geen gewone PtP of ether segment. (of je er wat mee kunt, een aantal opinies pro of con van nlnog, is iets anders..). Feitelijk is laag-3 manipulatie door een laag-2 device al een beetje verdacht, maar er zijn genoeg situaties waar het nodig of handig is, zoals wanneer het voor de hand liggende L3 device om technische of organistorische redenen niet zelf de L3 manipulaties kan doen. Als de bridge wel icmp unreachables moet sturen is de vraag natuurlijk met welk ip adres. Een redelijke keuze zou het IP adres van het upstream (qua richting van het ontvangen verkeer) device zijn, maar dat kan natuurlijk verwarring geven nadat de volgende hop (dat upstream device) dan hetzelfde antwoord geeft. Een "eigen" ip adres gebruiken is ook moeilijk te verdedigen voor een apparaat wat verder op L2 moet blijven. Anyway, in dit geval is dus geen TTL decrement m.i. de betere keuze. (wel zou het ding spanning-tree moeten [kunnen] doen... ). Boudewijn
Arjan _______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog
On Mon, 24 Sep 2007, Arjan van der Oest wrote:
Het (imho) discutabele gedrag: het beestje verlaagt de TTL van alle passerende IP pakketjes, maar aangezien het geen router is stuurt het ook geen ICMP uit (at least, niet in de dataplane). Maar door het verlagen van de TTL en het niet uitsturen van unreachables verschijnt de het betreffende device wel in een traceroute maar geeft door het onbreken van de unreachables uiteraard verder geen info prijs.
Mijn argument: het ding is geen router/host als bedoeld in rfc791 en ondanks het feit dat het kreng DSCP kan modificeren zie ik geen reden waarom ie met zn tengels aan de TTL zou moeten zitten.
Ik ben het met je eens. Lijkt me als ik dat zo lees niet de bedoeling. Afgezien daarvan vraag ik me af *waarom* hij dat doet, daar ben ik eigenlijk best benieuwd naar :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
participants (4)
-
alex＠bit.nl -
arjan＠vanderoest.net -
bvisser-nlnog＠xs4all.nl -
steven.bakker＠ams-ix.net