[ipv6-tf] Linux i problem z privacy extensions

[Adam Osuchowski]

Witam,

mam następujący problem. Jest sobie Linux, który jest podłączony do
segmentu sieci w którym router rozgłasza prefix za pomocą pakietów router
advertisement. Jeżeli odpowiednim sysctlem włączę sobie autokonfigurację,
to oczywiście system skonfiguruje mi adres dynamiczny na podstawie
rozgłaszanego prefiksu od routera i adresu MAC interfejsu (EUI-64)
i wszystko jest zgodne z teorią:

# ip a l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state UP 
    link/ether 18:a9:05:47:c0:56 brd ff:ff:ff:ff:ff:ff
    inet6 2001:db8:1:1:1aa9:5ff:fe47:c056/64 scope global dynamic 
       valid_lft 2591999sec preferred_lft 604799sec
    inet6 fe80::1aa9:5ff:fe47:c056/64 scope link 
       valid_lft forever preferred_lft forever

Jeżeli jednak włączę sobie privacy extensions przez ustawienie sysctla
use_tempaddr na wartość dodatnią, teoretycznie powinienem uzyskać dynamiczne
adresy nie bazujące wprost na adresach MAC. Jednakże, oprócz takiego adresu
system ustawia też drugi, bazujący na MAC, dokładnie tak jak z wyłączonym
privacy extensions:

# ip a l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state UP 
    link/ether 18:a9:05:47:c0:56 brd ff:ff:ff:ff:ff:ff
    inet6 2001:db8:1:1:d906:d599:49d6:aadd/64 scope global temporary dynamic
       valid_lft 604725sec preferred_lft 85725sec
    inet6 2001:db8:1:1:1aa9:5ff:fe47:c056/64 scope global dynamic 
       valid_lft 2591997sec preferred_lft 604797sec
    inet6 fe80::1aa9:5ff:fe47:c056/64 scope link 
       valid_lft forever preferred_lft forever

Próby kładzenia i stawiania interfejsu oraz różne kombinacje kolejności
ustawień nie wpłynęły na wynik ogólny. Nawet jeśli usunę z palca ten adres,
to za chwilę znów się dołoży i dodatkowo zostanie skonfigurowany kolejny
tymczasowy adres:

# ip a l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state UP 
    link/ether 18:a9:05:47:c0:56 brd ff:ff:ff:ff:ff:ff
    inet6 2001:db8:1:1:684a:b9c5:1631:46aa/64 scope global temporary dynamic
       valid_lft 604795sec preferred_lft 85795sec
    inet6 2001:db8:1:1:1aa9:5ff:fe47:c056/64 scope global dynamic 
       valid_lft 2591995sec preferred_lft 604795sec
    inet6 2001:db8:1:1:d906:d599:49d6:aadd/64 scope global temporary dynamic
       valid_lft 604721sec preferred_lft 85721sec
    inet6 fe80::1aa9:5ff:fe47:c056/64 scope link 
       valid_lft forever preferred_lft forever

Jest to o tyle niemiłe, że nawet przy use_tempaddr == 2, który wymusza
adres źródłowy połączeń wychodzących na ten tymczasowy, wciąż maszyna jest
dostępna z sieci pod tym adresem z EUI-64.

Czy to jest właściwe zachowanie? IMHO, coś tu jest nie tak, tylko nie wiem
co. Czy ja coś źle robię, czy jest bug w kernelu linuksowym czy jeszcze coś
innego? Jak zmusić go, żeby w ramach autokonfiguracji nie ustawiał w ogóle
adresów z EUI-64?

Pozdrowienia.

-- 
##  Adam Osuchowski                            Adam.Osuchowski w polsl.pl
##  Silesian University of Technology, Computer Centre, Gliwice, Poland