Jak tymczasowo wyłączyć IPv6 dla całej sieci?

Mamy średnią sieć z IPv4 i IPv6, a nasz poprzedni dostawca sprawia, że ​​IPv6 odchodzi na dwa tygodnie, podczas gdy robią ... coś. (Jest „eksperymentalny” i nie płacimy za to, ale był stabilny przez lata, więc włączyliśmy go we wszystkie strony).

W naszej sieci znajduje się 150 hostów z co najmniej tuzinem różnych systemów operacyjnych, a także sieć bezprzewodowa dla telefonów i laptopów ludzi, więc wyłączenie IPv6 na wszystkich naszych urządzeniach nie uruchamia się.

Chciałbym uniknąć zbyt wiele klasycznego zepsutego zachowania IPv6 z długimi limitami czasu przed przełączeniem awaryjnym na IPv4 i zastanawiam się, jaki jest najlepszy sposób.

• Czy powinienem blokować wychodzące pakiety IPv6 na granicy i zwracać nieosiągalny komunikat, czy może to oznaczać, że hosty będą oznaczone jako nieosiągalne bez powrotu do IPv4?
• Czy wyłączenie rozdzielczości AAAA przez nasz serwer nazw BIND jest możliwe (a jeśli tak, to w jaki sposób), a jeśli tak, to czy jest to uzasadnione?
• Alternatywnie, czy wyłączenie RADVD wykona zadanie? Używamy konfiguracji statycznej na niektórych naszych serwerach, ale jest ich wystarczająco mało, aby wykonać je ręcznie.

Chciałbym wyłączyć RA i ręcznie wyłączyć statycznie skonfigurowanych hostów. Konfigurowanie tunelu jest również możliwe, ale dwukrotna ponowna numeracja będzie wymagać więcej pracy niż tymczasowe wyłączenie.

Jeśli reklamujesz osiąganie IPv6 w DNS (publikujesz rekordy AAAA), powinieneś je również tymczasowo usunąć. Nie zapominaj, że mogą one być buforowane przez użytkowników, więc zostaw wystarczająco dużo czasu między usunięciem rekordów AAAA a wyłączeniem IPv6.

Najłatwiejszy na twoich klientach będzie przejście przez tunel ipv6. Jeśli możesz zaktualizować routing, aby podsieci przechodziły przez tunel, byłoby to niesamowite, ale być może będziesz musiał przejść do metody NAT 1: 1 z podsieciami podanymi przez dostawcę tunelu do mapowania do istniejących. Skonfigurujesz swój rdzeń routingu, aby wysyłał ruch v6 przez tunele v6, aby wszystko, co na nim polegało, nadal działało, chociaż być może nieco wolniej niż wcześniej, ale przynajmniej szybciej niż powrót po awarii v4. Podsieci, które są całkowicie dynamicznie przypisywane, prawdopodobnie nie potrzebowałyby NAT 1: 1, ale prawdopodobnie wszystko ze statycznymi przypisaniami prawdopodobnie by tego potrzebowało.