VPN ಮೇಲೆ IPv6 link-local ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ: fe80 ಲಿಂಕ್ನಲ್ಲಿ ಏಕೆ ನಿಲ್ಲುತ್ತದೆ
fe80:: ವಿಳಾಸಕ್ಕೆ ಒಂದೇ ಲಿಂಕ್ನಲ್ಲಿ ಮಾತ್ರ ಅರ್ಥವಿದೆ. ರೂಟೆಡ್ VPN ಅದನ್ನು ಏಕೆ ಸಾಗಿಸಲಾರದು, ವೈಫಲ್ಯ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಬದಲಿಗೆ ಯಾವ ವಿಳಾಸ ಬಳಸಬೇಕು ಎಂಬುದನ್ನು ನೋಡಿ.
ನೀವು ಟನಲ್ ಮೇಲೆತ್ತಿ, ಟನಲ್ ಅನ್ನು ಮೂಲ ಇಂಟರ್ಫೇಸ್ ಆಗಿ ಬಳಸಿ fe80::1 ಗೆ ping ಮಾಡುತ್ತೀರಿ, ಆದರೆ ಏನೂ ಹಿಂತಿರುಗುವುದಿಲ್ಲ. ಇದು ನೀವು ಮರೆತ firewall ನಿಯಮವಲ್ಲ. Link-local ವಿಳಾಸವು ಅದು ರೂಪುಗೊಂಡ ಒಂದೇ ಲಿಂಕ್ನಲ್ಲಿ ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣವಾಗಿರುತ್ತದೆ, ಮತ್ತು ರೂಟೆಡ್ VPN ಆ ಲಿಂಕ್ ಅಲ್ಲ. ದೂರದ ರೌಟರ್ನ fe80::1 ದೂರದ LAN ವಿಭಾಗದಲ್ಲಿದೆ; ನೀವು ಬೇರೆ ವಿಭಾಗದಲ್ಲಿ ಒಂದು ಹಾಪ್ ದೂರದಲ್ಲಿದ್ದೀರಿ, ಮತ್ತು ರೌಟರ್ link-local ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಯಾವುದೇ ಕಾರ್ಯವಿಧಾನ IPv6 ಗೆ ಇಲ್ಲ.
fe80 ಪೂರ್ವಪ್ರತ್ಯಯವು ವ್ಯಾಪ್ತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಶ್ರೇಣಿಯನ್ನಲ್ಲ
Link-local unicast ಎಂದರೆ fe80::/10, ಮತ್ತು ವ್ಯಾಖ್ಯಾನಿಸುವ ಗುಣ ಸಂಖ್ಯೆಯಲ್ಲ, ವ್ಯಾಪ್ತಿ. ವಿಳಾಸವು ಒಂದೇ ಲಿಂಕ್ನಲ್ಲಿ ಮಾತ್ರ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ ತನ್ನದೇ ಗುರುತಿನಿಂದ ಒಂದನ್ನು ರೂಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡು ಸಂಬಂಧವಿಲ್ಲದ ಜಾಲಗಳಲ್ಲಿನ ಎರಡು ಸಂಬಂಧವಿಲ್ಲದ ಯಂತ್ರಗಳು ಸ್ವಲ್ಪವೂ ಘರ್ಷಣೆಯಿಲ್ಲದೆ fe80::1 ಗೆ ಉತ್ತರಿಸಬಹುದು. ಪೂರ್ವಪ್ರತ್ಯಯವು ಮೂಲತಃ “ಯಾವುದೋ ಲಿಂಕ್ನಲ್ಲಿ” ಎಂದು ಹೇಳುತ್ತದೆ; ಲಿಂಕ್ ಸ್ವತಃ ಸಂದರ್ಭದಿಂದ ಬರುತ್ತದೆ.
ಹೋಸ್ಟ್ನಲ್ಲಿ ಆ ಸಂದರ್ಭವು ಶೇಕಡಾ ಚಿಹ್ನೆಯ ನಂತರ ಸೇರಿಸುವ ವಲಯ, ಅಂದರೆ scope ID: Linux ನಲ್ಲಿ fe80::1%eth0, Windows ನಲ್ಲಿ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಸೂಚ್ಯಂಕಗಳನ್ನು ತೋರಿಸುವ ಪರಿಕರಗಳಲ್ಲಿ fe80::1%3 ಅಥವಾ fe80::1%12. ಕರ್ನಲ್ ವಿಳಾಸವನ್ನು ಇಂಟರ್ಫೇಸ್ ಸೂಚ್ಯಂಕದೊಂದಿಗೆ ಪರಿಹರಿಸಿ ನಂತರ ಕಳುಹಿಸುತ್ತದೆ. ವಲಯವನ್ನು ತೆಗೆದರೆ ಗಮ್ಯಸ್ಥಾನ ಅಸ್ಪಷ್ಟವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಟ್ಯಾಕ್ಗೆ ವಿಭಾಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ದಾರಿಯಿಲ್ಲ.
ರೂಟೆಡ್ ಟನಲ್ ಅದನ್ನು ಏಕೆ ತಲುಪಿಸಲಾರದು
ರೂಟೆಡ್ VPN ಒಂದು ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಇಂಟರ್ಫೇಸ್ ಆಗಿದ್ದು ತನ್ನದೇ ವಿಳಾಸಗಳನ್ನು ಹೊತ್ತಿರುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಟನಲ್ನೊಳಗಿನ unique-local ಅಥವಾ ಖಾಸಗಿ IPv6 ಜಾಗದ /64. ದೂರದ LAN ಪ್ರತ್ಯೇಕ ಲಿಂಕ್ ಆಗಿದ್ದು, ಟನಲ್ ಎಂಡ್ಪಾಯಿಂಟ್ ನಿಮ್ಮ ಪರವಾಗಿ ರೂಟಿಂಗ್ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾಡಿ ಅದನ್ನು ತಲುಪುತ್ತದೆ. ಇವು ಎರಡು ವಿಭಿನ್ನ ವಿಭಾಗಗಳು, ಆದ್ದರಿಂದ ಒಂದರ ವಿಳಾಸ ಇನ್ನೊಂದರಲ್ಲಿ ಮಾನ್ಯ ಗಮ್ಯಸ್ಥಾನವಲ್ಲ.
ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ನ ವಿಚಿತ್ರತೆಯಲ್ಲ, ಮಾನಕದಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿದೆ: ರೌಟರ್ಗಳು link-local ಮೂಲ ಅಥವಾ ಗಮ್ಯಸ್ಥಾನವಿರುವ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ರೂಟ್ ಕೋಷ್ಟಕ ಸರಿಯಾಗಿ ಕಾಣುತ್ತಿದ್ದರೂ ಪ್ಯಾಕೆಟ್ ಸಾಯುತ್ತದೆ. fe80::/64 ಗೆ ಟನಲ್ನ ಕಡೆಗೆ ರೂಟ್ ಸೇರಿಸಿದರೆ, ಅನುಸರಣೀಯ ಸ್ಟ್ಯಾಕ್ ಅದನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಅಥವಾ ಸ್ವೀಕರಿಸಿ ಹೊಂದುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬಿಡುತ್ತದೆ: ಗಮ್ಯಸ್ಥಾನದ ವ್ಯಾಪ್ತಿ “ಈ ಲಿಂಕ್ ಮಾತ್ರ” ಎನ್ನುತ್ತದೆ, ಮತ್ತು ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ ಆ ಲಿಂಕ್ ಅಲ್ಲ.
ನೆರೆ ಪತ್ತೆ ಅದೇ ಗಡಿಯನ್ನು ಬಲಪಡಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ಗಳು link-local ಮುಂದಿನ ಹಾಪ್ಗಳನ್ನು 255 ಹಾಪ್ ಮಿತಿಯೊಂದಿಗೆ ಲಿಂಕ್ ವ್ಯಾಪ್ತಿಯ multicast ಗೆ ಕಳುಹಿಸುವ ನೆರೆ ವಿನಂತಿಯಿಂದ ಪರಿಹರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ರೌಟರ್ಗಳು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಯಾವುದನ್ನಾದರೂ ತಿರಸ್ಕರಿಸಬಹುದು. ಅದನ್ನು ಟನಲ್ ಮೂಲಕ ಕೆಲಸ ಮಾಡಿಸುವುದೆಂದರೆ ದೂರದ ವಿಭಾಗಕ್ಕೆ ಪತ್ತೆಯನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುವುದು, ಅದು ಬೇರೆ ಟೋಪಿ ಹಾಕಿದ Layer 2 ಸೇತುವೆ.
ಎರಡನೇ, ಹೆಚ್ಚು ನಿಶ್ಶಬ್ದ ವೈಫಲ್ಯವಿದೆ, ಮತ್ತು ಅದು ರೂಟ್ ಅನ್ನು ಬಲವಂತಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುವವರನ್ನು ಹಿಡಿಯುತ್ತದೆ: ವಲಯ. ನೀವು ಸ್ಥಳೀಯವಾಗಿ ಟೈಪ್ ಮಾಡುವ ಯಾವುದೇ ವಲಯವು ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಆದರೆ ನೀವು ಬಯಸುವ ವಿಳಾಸ ದೂರದ LAN ಇಂಟರ್ಫೇಸ್ಗೆ ಬದ್ಧವಾಗಿದೆ. ಎರಡೂ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ದೂರದ ತುದಿಯಲ್ಲಿ ಸರಿಯಾದ ಇಂಟರ್ಫೇಸ್ಗೆ ತಿರುಗಿಸಲಾಗದು.
ಪ್ರಾಯೋಗಿಕವಾಗಿ ವೈಫಲ್ಯ ಹೇಗೆ ಕಾಣುತ್ತದೆ
ವ್ಯಾಪ್ತಿ ತಪ್ಪಿಗೆ ಪರಿಕರದ ಔಟ್ಪುಟ್ ರೂಟಿಂಗ್ ಅಥವಾ firewall ದೋಷದಂತೆ ಓದುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಜನರು ತಪ್ಪು ಪದರದಲ್ಲಿ ಮಧ್ಯಾಹ್ನ ಕಳೆಯುತ್ತಾರೆ.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
ಮೂರನೇ ಸಾಲು ಅತಿ ಹೆಚ್ಚು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಔಟ್ಪುಟ್ ಇಲ್ಲದ ssh ಕ್ಲೈಂಟ್ ಕೇಳುತ್ತಿರುವ ಸೇವೆಯ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಒಳಗೆ ಬರಲು ಯಾವುದೇ ದಾರಿ ಇದ್ದರೆ, ದೂರದ ಭಾಗವನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು sshd ಎಲ್ಲಾ ವಿಳಾಸಗಳಿಗೆ ಬದ್ಧವಾಗಿದೆಯೇ ಅಥವಾ ಒಂದಕ್ಕೆ ಮಾತ್ರ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ರೂಟ್ ಆಗಲು ಉದ್ದೇಶಿಸಿದ ವಿಳಾಸವನ್ನು ಬಳಸಿ
ಟನಲ್ ಮೂಲಕ ತಲುಪಬೇಕಾದ ಯಾವುದಕ್ಕೂ, ಸೇವೆಗೆ ಆ ಉದ್ದೇಶಕ್ಕಾಗಿಯೇ ನೀಡಿದ ವಿಳಾಸವನ್ನು ಬಳಸಿ: ಜಾಗತಿಕ unicast ವಿಳಾಸ, ಅಥವಾ fc00::/7 ನಿಂದ unique-local ವಿಳಾಸ, ಸರಿಯಾಗಿ ಈ ಆಂತರಿಕ ಸಂದರ್ಭಕ್ಕೆ ಕಾಯ್ದಿರಿಸಿದ ಶ್ರೇಣಿ. ಕೇಳುಗನು ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಬಂಧಿಸಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಹಾಗೂ ಹೋಸ್ಟ್ನ ಯಾವುದೇ firewall ನಿಯಮವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಊಹಿಸುವ ಬದಲು ದೂರದ ಹೋಸ್ಟ್ ಅನ್ನು ನೋಡಿ. ip -6 addr show ಇರುವ ವಿಳಾಸಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ss -6 -ltn ಡೀಮನ್ ಯಾವುದನ್ನು ಕೇಳುತ್ತಿದೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. fe80:: ಗೆ ಮಾತ್ರ ಬದ್ಧವಾದ ಸೇವೆ ತನ್ನ ವಿಭಾಗದಿಂದ ಮಾತ್ರ ತಲುಪಬಹುದು, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಯಾರೂ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡದ ಡೀಫಾಲ್ಟ್ ಆಗಿದ್ದು ನಿರ್ವಾಹಕರ ಒಪ್ಪಿಗೆಯಿಂದ ಬದಲಾಯಿಸಬಹುದು.
ಸೇವೆಯನ್ನು ನಿಜವಾಗಿಯೂ ಮರುಬಂಧಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಿದ್ದಾಗ, ಸೇತುವೆಯನ್ನು ನೆಟ್ವರ್ಕ್ ಪದರದ ಬದಲು ಅಪ್ಲಿಕೇಶನ್ ಪದರಕ್ಕೆ ಮೇಲಕ್ಕೆ ಸರಿಸಿ. ದೂರದ ಹೋಸ್ಟ್ನಲ್ಲಿ ರೂಟ್ ಮಾಡಬಹುದಾದ ವಿಳಾಸದಲ್ಲಿ ಕೇಳುವ ಮತ್ತು link-local ಗೆ ಸಂಪರ್ಕಿಸುವ ರಿಲೇ ಯಾವುದೇ ವಿಭಾಗವನ್ನು ವಿಸ್ತರಿಸದೆ ಸಮಸ್ಯೆಯನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80ಇಲ್ಲಿ ವಲಯ ಸರಿಯಾದ ಬದಿಯಲ್ಲಿದೆ, ಆ ಲಿಂಕ್ನಲ್ಲಿ ನಿಜವಾಗಿಯೂ eth0 ಇರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ fd00:1:2::10 ನೊಂದಿಗೆ ಮಾತನಾಡುತ್ತದೆ, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ರೂಟ್ ಆಗುತ್ತದೆ, ಮತ್ತು ರಿಲೇ link-local ಹಾಪ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಮಾಡುತ್ತದೆ. ಅದೇ ಉಪಾಯ ಸಾಧನದ ವೆಬ್ UI ಅಥವಾ link-local ವಿಳಾಸವನ್ನು ಮಾತ್ರ ಜಾಹೀರಾತು ಮಾಡುವ ಹಳೆಯ BMC ಗೆ ಸಹ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಸೇತುವೆ ನಿಜವಾಗಿಯೂ ಉತ್ತರವಾದಾಗ, ಮತ್ತು ಏನನ್ನು ಪರಿಶೀಲಿಸಬೇಕು
ಕೆಲವು ನಿಯೋಜನೆಗಳಿಗೆ ನಿಜವಾಗಿಯೂ ಒಂದು ಹಂಚಿದ ವಿಭಾಗ ಬೇಕು: link-local ಪತ್ತೆಯನ್ನು ಮಾತ್ರ ಮಾತನಾಡುವ ಸಾಧನ, multicast ಅನ್ನು ಅವಲಂಬಿಸಿರುವ ಉಪಕರಣ, ಸಮತಟ್ಟಾದ LAN ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವ ಪ್ರಯೋಗಾಲಯ. ಅದು Layer 2 ಸಮಸ್ಯೆ ಮತ್ತು ಅದಕ್ಕೆ Layer 2 ಉತ್ತರ ಬೇಕು, ಉದಾಹರಣೆಗೆ ದೂರದ ಇಂಟರ್ಫೇಸ್ಗೆ ಸೇತುವೆಯಾದ tap ಸಾಧನ ಅಥವಾ ಸ್ಪಷ್ಟ ಸೇತುವೆ ಮೋಡ್ ಇರುವ ಕ್ಲೈಂಟ್ ಉತ್ಪನ್ನ. ಅದಕ್ಕೆ ಟನಲ್ ದಾಟುವ broadcast ಮತ್ತು multicast ಸಂಚಾರ ಮತ್ತು ತುದಿಯಿಂದ ತುದಿಗೆ ಕೆಲಸ ಮಾಡಬೇಕಾದ ನೆರೆ ಪತ್ತೆ ವೆಚ್ಚವಾಗುತ್ತದೆ.
ರೂಟೆಡ್ ಪ್ರೊಫೈಲ್ಗೆ fe80::/64 ಸೇರಿಸಿ ಇದನ್ನು ಅಂದಾಜು ಮಾಡಬೇಡಿ. ಅದು ಅತ್ಯಂತ ಕೆಟ್ಟ ಸ್ಥಿತಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಸಂರಚನೆ ಮುಗಿದಂತೆ ಕಾಣುತ್ತದೆ, ರೂಟ್ ಕೋಷ್ಟಕ ನಮೂದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಇನ್ನೂ ಸರಿಯಾಗಿ ವರ್ತಿಸುತ್ತಿರುವ ಎರಡು ಸ್ಟ್ಯಾಕ್ಗಳ ನಡುವೆ ಎಲ್ಲೋ ಎಸೆಯಲ್ಪಡುತ್ತದೆ.
ping ಬದಲು ಇಂಟರ್ಫೇಸ್ನಿಂದ ಪರಿಶೀಲಿಸಿ. ip -6 addr show tun0 ಟನಲ್ ಲಿಂಕ್ ತನ್ನದೇ link-local ವಿಳಾಸವನ್ನು ರೂಪಿಸಿದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ip -6 route get fe80::1%tun0 ಸ್ಕೋಪ್ ಮಾಡಿದ ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ಕರ್ನಲ್ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಆ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ ತಲುಪಲಾಗದು ಎಂದು ಕರ್ನಲ್ ಹೇಳಿದಾಗ, ಯಾವುದೇ ಟನಲ್ ಸೆಟ್ಟಿಂಗ್ ಅದನ್ನು ಬದಲಾಯಿಸದು, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆ ನಿಲ್ಲಿಸುವ ಸಮಯ.
ಪ್ರಶ್ನೆಯನ್ನು ಇತ್ಯರ್ಥ ಮಾಡುವ ಸಣ್ಣ ಕ್ರಮ:
- ದೂರದ ಹೋಸ್ಟ್ನಲ್ಲಿ ವಿಳಾಸವನ್ನು ಓದಿ ಮತ್ತು ಅದು fe80:: ಅಥವಾ ರೂಟ್ ಮಾಡಬಹುದಾದ ಪೂರ್ವಪ್ರತ್ಯಯ ಎಂದು ಗಮನಿಸಿ.
- ಅದು fe80:: ಆಗಿದ್ದರೆ, ಸೇವೆಯನ್ನು ಮರುಬಂಧಿಸಿ, ಆ ಹೋಸ್ಟ್ನಲ್ಲಿ ರಿಲೇ ಮಾಡಿ, ಅಥವಾ ವಿಭಾಗವನ್ನು ಸೇತುವೆ ಮಾಡಿ; ರೂಟ್ ಮಾಡಬಹುದಾದದ್ದಾಗಿದ್ದರೆ, ರೂಟ್, firewall ಅಥವಾ ಬೈಂಡ್ ವಿಳಾಸವನ್ನು ಸರಿಪಡಿಸಿ.
- ಪ್ರತಿ ಬಾರಿ ಮರುಪರೀಕ್ಷೆ ಮಾಡುವಾಗ ವಲಯವನ್ನು ಮರುಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ನಕಲಿಸಿದ ಆಜ್ಞೆ ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಮೂಲಗಳು: RFC 4291, IPv6 ವಿಳಾಸ ರಚನೆ.