Dotaz: Preklad IPv4 a IPv6 adries na MAC adresy

[kisko]

Otazocka.

Akym sposobom sa vykonava preklad adries IPv4 a IPv6 na MAC adresy ?

Dakujem za info

---

---

Odpovědi

[Oskar]

ARP, NDP..

NN

[kisko]

ARP moze byt.

NDP (Neighbor Discovery Protocol) pri IPv6 ? .... otazka je polozena takto:

Akym sposobom sa vykonava preklad sietovych adries (IPv4, IPv6) na hardverove (MAC) adresy v sieti s implementovaným protokolom IPv4 a v sieti s protokolom IPv6.

Viem, ze pri IPv6 sa vyuziva identifikator rozhrania eui-64 a ten vyuziva MAC adresu ako identifikator rozhrania pre PC v sieti. Medzi treti a stvrty bajt MAC sa vklada 16 bitov fffe.

NDP protokol je tym mysleny? podla Vas NN ?

[xHire]

Jde o to, co přesně myslíš. Čisté přiřazení určité IPv6 adrese skutečnou MAC adresu počítače zařizuje NDP paket Neighbor Solicitation (a odpověď na něj je Neighbor Advertisement). Funguje v podstatě velice podobně jako ARP v IPv4.

To s vyráběním IPv6 adresy z MAC adresy síťové karty sice také funguje přes NDP (v případě autokonfigurace na síti), ale nesouvisí s výše uvedeným. Pak je ještě linková IPv6 adresa, kterou si vyrábí samotný operační systém (z MAC adresy) a NDP se u toho nevyužívá (není důvod).

Princip: odešle se multicastem NDP NS paket s otázkou, kdo má danou IPv6 adresu, a přijde odpověď NDP NA od dotyčného počítače, která v sobě má onu MAC adresu, takže je možné poslat původně zamýšlený paket již přímo (unicastem).

[petr_p]

Překlad z IPv6 na linkovou adresu se vždy provádí protokolem NDP. Nikdo totiž nemůže vědět, jak daná IPv6 adresa vznikla, a především se na to nemůže spoléhat.

I link-scope adresy se překládájí. Stačí se podívat do vyrovnávací paměti:

$ /sbin/ip -6 ne
fe80::20e:2eff:fec8:c5b3 dev eth0 lladdr 00:0e:2e:c8:c5:b3 router REACHABLE

[pht]

Výpis záznamu z neighbor cache není důkaz, že tento záznam vznikl pomocí NDP. Přinejmenším ho tam mohl někdo dát ručně.

Nejsem si jist, jestli u fe80:: se nepoužije nějaká zkratka. Výpis z tcpdumpu by to možná doložil jasněji.

[petr_p]

Důkaz to není, ale přesvědčivé to je. Pokud se bavíme o Linuxu, tak Linux v současnosti neumí ručně měnit cache NDP.

Jestli ale trváte na tcpdumpu, tak tady je (ping na neexistující link-scope adresu):

$ ping6 -I eth0 fe80::20e:2eff:fec8:c5b4
PING fe80::20e:2eff:fec8:c5b4(fe80::20e:2eff:fec8:c5b4) from fe80::4e00:10ff:fe60:7ca6 eth0: 56 data bytes
From fe80::4e00:10ff:fe60:7ca6 icmp_seq=1 Destination unreachable: Address unreachable
From fe80::4e00:10ff:fe60:7ca6 icmp_seq=2 Destination unreachable: Address unreachable
From fe80::4e00:10ff:fe60:7ca6 icmp_seq=3 Destination unreachable: Address unreachable
^C
--- fe80::20e:2eff:fec8:c5b4 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3012ms

# tcpdump -i eth0 -e -np icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:03:22.496517 4c:00:10:60:7c:a6 > 33:33:ff:c8:c5:b4, ethertype IPv6 (0x86dd), length 86: fe80::4e00:10ff:fe60:7ca6 > ff02::1:ffc8:c5b4: ICMP6, neighbor solicitation, who has fe80::20e:2eff:fec8:c5b4, length 32
09:03:23.496571 4c:00:10:60:7c:a6 > 33:33:ff:c8:c5:b4, ethertype IPv6 (0x86dd), length 86: fe80::4e00:10ff:fe60:7ca6 > ff02::1:ffc8:c5b4: ICMP6, neighbor solicitation, who has fe80::20e:2eff:fec8:c5b4, length 32
09:03:24.493650 4c:00:10:60:7c:a6 > 33:33:ff:c8:c5:b4, ethertype IPv6 (0x86dd), length 86: fe80::4e00:10ff:fe60:7ca6 > ff02::1:ffc8:c5b4: ICMP6, neighbor solicitation, who has fe80::20e:2eff:fec8:c5b4, length 32
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Takže máte pravdu, že při překladu link-scope adresy, která je odvozena z ethernetové, se dotaz posílá přímo na danou ethernetovou adresu. Ale NDP se dělá i tak.

Takhle to vypadá na existující adresu, které chybí záznam v cache:

# tcpdump -i eth0 -e -np icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:02:11.548090 4c:00:10:60:7c:a6 > 33:33:ff:c8:c5:b3, ethertype IPv6 (0x86dd), length 86: fe80::4e00:10ff:fe60:7ca6 > ff02::1:ffc8:c5b3: ICMP6, neighbor solicitation, who has fe80::20e:2eff:fec8:c5b3, length 32
09:02:11.548549 00:0e:2e:c8:c5:b3 > 4c:00:10:60:7c:a6, ethertype IPv6 (0x86dd), length 86: fe80::20e:2eff:fec8:c5b3 > fe80::4e00:10ff:fe60:7ca6: ICMP6, neighbor advertisement, tgt is fe80::20e:2eff:fec8:c5b3, length 32
09:02:11.548625 4c:00:10:60:7c:a6 > 00:0e:2e:c8:c5:b3, ethertype IPv6 (0x86dd), length 118: fe80::4e00:10ff:fe60:7ca6 > fe80::20e:2eff:fec8:c5b3: ICMP6, echo request, seq 1, length 64
09:02:11.548944 00:0e:2e:c8:c5:b3 > 4c:00:10:60:7c:a6, ethertype IPv6 (0x86dd), length 118: fe80::20e:2eff:fec8:c5b3 > fe80::4e00:10ff:fe60:7ca6: ICMP6, echo reply, seq 1, length 64

[pht]

Takže máte pravdu, že při překladu link-scope adresy, která je odvozena z ethernetové, se dotaz posílá přímo na danou ethernetovou adresu. Ale NDP se dělá i tak.

Spíš to vypadá, že NDP se pošle jen na multicast odvozený z té lokální adresy...

[petr_p]

Vizte linkovou adresu.

[petr_p]

Beru zpět. To je tak, když se člověk soustředí jen na konec adresy.

[kisko]

Tak z toho vsetkeho vyplyva ze pri IPv4 je to protokol ARP, pri preklade IPv6 na MAC adresu je to NDP. Nemusi sa to jednat z pohladu Linuxu, len tak vseobecne by mal(alebo moze)vykonavat preklad.. spravne ?