Hoe forward Linux packets precies?

[Verwijderd]

Wie kan mij naar een document wijzen wat precies beschrijft hoe Linux packets forward?

Ik probeer te onderzoeken wat er nodig is om de IPv4 routing table (/proc/net/route) zo aan te passen dat het mogelijk is om een IPv4 destination te bereiken over een IPv6 next hop. Hiermee wil ik kijken of we dus een IPv4 packet over een IPv6 eiland kunnen versturen zonder een tunnel. Dit zou in theorie kunnen werken aangezien het uiteindelijke pakketje op de lijn niet veranderd, alleen de dest L2 address in de frame welke we dus moeten zien uit te vinden.

Mooie theorie, maar in de praktijk natuurlijk iets moeilijker aangezien de IPv4 en IPv6 tabellen meestal totaal gescheiden zijn, in een OS waar dit niet het geval zou dit waarschijnlijk zo moeten te implementeren zijn. (iemand een idee of er een OS bestaat die de IPv4 en IPv6 tabel al in 1 heeft geschoven?)

Ik zou graag het volgende willen weten.
Is de routing table en forwarding methode onderdeel van de Linux kernel of distro afhankelijk?
Hoe en waar wordt de routing tabel /proc/net/route aangemaakt?
Hoe en waar wordt de main FIB aangemaakt?
Als er een packet op een link binnen komt, kijkt de netwerk driver in de FIB en verstuurd hij die door, of verstuurd de netwerk driver de packet naar een intern Linux programma die in de FIB kijkt en de packet naar de volgende interface stuurt?

Een link naar documentatie en/of uitleg zou heel erg welkom zijn!

[Kees]

Verwijderd schreef op donderdag 08 maart 2012 @ 12:01:
Wie kan mij naar een document wijzen wat precies beschrijft hoe Linux packets forward?

Ik probeer te onderzoeken wat er nodig is om de IPv4 routing table (/proc/net/route) zo aan te passen dat het mogelijk is om een IPv4 destination te bereiken over een IPv6 next hop. Hiermee wil ik kijken of we dus een IPv4 packet over een IPv6 eiland kunnen versturen zonder een tunnel. Dit zou in theorie kunnen werken aangezien het uiteindelijke pakketje op de lijn niet veranderd, alleen de dest L2 address in de frame welke we dus moeten zien uit te vinden.

Er zijn wel meer veranderingen in de packet structuur, zie wikipedia. Dat gaat je dus niet lukken zonder het packet volledig te rewriten. Het zijn twee verschillende protocollen.

Verder:

Is de routing table en forwarding methode onderdeel van de Linux kernel of distro afhankelijk?
Hoe en waar wordt de routing tabel /proc/net/route aangemaakt?
Hoe en waar wordt de main FIB aangemaakt?
Als er een packet op een link binnen komt, kijkt de netwerk driver in de FIB en verstuurd hij die door, of verstuurd de netwerk driver de packet naar een intern Linux programma die in de FIB kijkt en de packet naar de volgende interface stuurt?

Linux kernel op alle vragen. grep die maar eens om te zien waar het precies aangemaakt wordt en volg die code

[Verwijderd]

Kees schreef op donderdag 08 maart 2012 @ 22:09:
[...]
Er zijn wel meer veranderingen in de packet structuur, zie wikipedia. Dat gaat je dus niet lukken zonder het packet volledig te rewriten. Het zijn twee verschillende protocollen.

Verder:

[...]
Linux kernel op alle vragen. grep die maar eens om te zien waar het precies aangemaakt wordt en volg die code

Op de netwerk kabel zal de packet niet anders zijn dan tussen elke andere hop, (anders dan TTL en header checksum). alleen de L2 frame die de L3 packet encapsulate moet een L2 address krijgen die ipv in de ARP tabel te vinden is (IPv4) in de neighbor table (IPv6) staat.

Als er dus een manier is om in het IPv4 route tabel een IPv6 adress als next hop te hebben met misschien een Flag wat aangeeft dat hij voor het bijbehoorende L2 address in de IPv6 neighbor tabel i.p.v. de IPv4 ARP tabel moet zoeken. in de Frame zal nog steeds staan dat het hier om een IPv4 packet gaat (want dat is het natuurlijk gewoon) waardoor de ontvangende kant het pakket gewoon als een IPv4 pakket verder zal door routen.

Op deze manier zou je dus tussen 2 IPv4 netwerken een eiland kunnen bouwen wat IPv6 gebruikt.
Maar waarom zou je dit willen?

Denk aan grote knooppunten op het Internet waar iedereen een uniek IP address nodig heeft om BGP routes met elkaar te kunnen uitwisselen. Op dit moment moet je via IPv4 peeren om IPv4 routes uit te kunnen wisselen. IPv4 addressen raken op zoals iedereen wel weet. Als we de IPv4 routes zouden kunnen uitwisselen die als next hop een IPv6 gebruiken dan zouden we helemaal geen IPv4 addressen meer nodig hebben op deze knooppunten waardoor het aantal IPv4 BGP neigbors in de toekomst door kunnen blijven groeien.
De manier van IPv4 BGP routes uitwisselen met een IPv6 next hop wordt beschreven in RFC 5549.
Maar voordat dit kan werken moeten we natuurlijk wel eerst mogelijk maken dat we de IPv6 next hop kunnen gaan gebruiken voor een IPv4 pakket.

Ik heb uitgevonden dat wanneer een netwerk kaart bits binnen krijgt hij deze doorstuurt naar de Linux kernel via de netif_rx() functie. de kernel bekijkt dan wat voor pakket het is (IPv4, IPv6, etc.) en stuurt het dan door naar de juiste protocol stack om afgehandeld te worden. het IPv4 routing tabel lijkt een struct te zijn maar ik ben dit nog aan het uitzoeken, ik ga er op dit moment van uit dat het nog niet kan.

Ik denk op dit moment aan 2 theoretische oplossingen om deze hop mogelijk te maken.
1. In de Linux kernel de IPv4 protocol stack aanpassen zodat er ruimte in het IPv4 tabel is om een IPv6 next hop te hebben, misschien met een flag er voor die dit aangeeft.

2. Als router schrijver kun je ook direct op driver niveau gaan zitten en de gehele kernel bypassen door niet de netif_rx() functie te gebruiken maar een functie die naar je eigen software direct zodat je je eigen routing tabel kan gebruiken.

Ik ga weer even verder modderen, bedankt voor de reactie!

[army]

Verwijderd schreef op vrijdag 09 maart 2012 @ 10:29:
[...]


Op de netwerk kabel zal de packet niet anders zijn dan tussen elke andere hop, (anders dan TTL en header checksum). alleen de L2 frame die de L3 packet encapsulate moet een L2 address krijgen die ipv in de ARP tabel te vinden is (IPv4) in de neighbor table (IPv6) staat.

Dit is niet geheel waar aangezien het EtherType field van IPv4 naar IPv6 gaat. Door dat het een ander EtherType is zal de kans heel klein zijn (lees nihil) dat het ooit een enkele routing table gaat worden gelukkig. Als je tussen verschillende protocollen wilt routeren zal je daar een gateway voor moeten hebben/bouwen. Er zijn wel een aantal oplossingen, maar elke keer komt dual IP stack als de meest bruikbare oplossing uit de bus. Er zijn wel een paar grote sites die IPv6-verkeer omzetten naar IPv4 voor intern gebruik, maar eigenlijk is dat geen oplossing voor thuisgebruik.

[Verwijderd]

army schreef op zondag 18 maart 2012 @ 13:08:
[...]


Dit is niet geheel waar aangezien het EtherType field van IPv4 naar IPv6 gaat. Door dat het een ander EtherType is zal de kans heel klein zijn (lees nihil) dat het ooit een enkele routing table gaat worden gelukkig. Als je tussen verschillende protocollen wilt routeren zal je daar een gateway voor moeten hebben/bouwen. Er zijn wel een aantal oplossingen, maar elke keer komt dual IP stack als de meest bruikbare oplossing uit de bus. Er zijn wel een paar grote sites die IPv6-verkeer omzetten naar IPv4 voor intern gebruik, maar eigenlijk is dat geen oplossing voor thuisgebruik.

De EtherType zal gewoon IPv4 blijven. het is ook helemaal niet nodig om hier een IPv6 van te maken. het pakket is en blijft immers gewoon een IPv4 pakket. Het enige wat de router doet wanneer een pakket binnen komt is de frame er af strippen, zoek de next hop (oh IPv6? kijk in de NDP table ipv ARP voor L2 next hop), maak een nieuwe frame aan met de DST MAC die ik net heb gevonden en stuur!

Nergens wordt het IPv4 pakket aangepast, afgezien van de TTL en checksum nogmaals.

De ontvangende kant (de next hop) zal ook in het pakket zelf niet kunnen zien dat het naar een IPv6 address next hop is verstuurd. dit staat namelijk helemaal niet in een IP pakket. alleen de uiteindelijke DST en de originele SRC aan het begin en het einde van de gehele reis.

Een mooie test om te bewijzen dat er op de kabel niet naar het IP address wordt gekeken is door een static route aan te maken die als next hop een bogus IP address heeft, zolang je in je ARP tabel maar verteld dat dat IP address wel naar de juiste MAC wijst van de next hop zal de route gewoon werken.