IPv4·IPv6 서브넷 계산기

상황

이제 사내 주소 공간을 처음부터 정한다. 거점이 150곳, 공장이 16곳 있고, 클라우드의 가상 네트워크도 같은 공간에 둔다. 사업부는 몇 년마다 재편되고, 거점의 담당 지역도 바뀐다. 10/8의 어디에 무엇을 둘지 가장 먼저 정하는 단계다.

전제

10/8을 자사에서 자유롭게 나눌 수 있을 것. 향후 통합으로 다른 회사의 주소 공간과 섞일 가능성은 지금은 고려하지 않아도 될 것. 용도의 종류를 나중에 추가할 수 있을 것. 경계를 참조하는 필터의 행 수를 셀 수 있을 것.

할당

이유

10/8에서 가장 먼저 정할 것은 두 번째 옥텟에 어떤 의미를 부여할지다. 후보는 세 가지로, 용도로 나누거나, 조직으로 나누거나, 지리로 나누는 것이다.

결론부터 말하면 용도로 나눈다. 조직과 지리는 바뀌지만 용도는 바뀌지 않기 때문이다. 사업부는 몇 년마다 재편되고, 담당 지역도 바뀐다. 반면 공장이 사무 거점으로 바뀌는 일은 없고, 검증 환경이 운영 환경이 되는 일도 없다.

조직으로 나누면 재편할 때마다 경계를 옮기거나, 이름과 실제가 어긋난 채로 두거나 둘 중 하나를 골라야 한다. 거의 언제나 후자가 선택되고, 몇 년 뒤에는 영업의 영역에 다른 부서가 들어와 있게 된다. 그렇게 되면 설계서의 구분과 실제 장비의 내용이 맞지 않게 된다.

최상위 경계는 옮길 수 없다. 10.16.0.0/12는 공장이라는 전제로 필터가 작성되어 있기 때문이며, 경계가 움직이면 이를 참조하는 행을 모두 다시 검토해야 한다. 150개 거점과 16개 공장, 클라우드를 갖고 있다면 수백 행이 되고, 게다가 한꺼번에 전환하지 않으면 한쪽 방향 통신만 통과하는 시간이 생긴다.

그래서 처음에 정하는 양을 최소로 한다. 10/8을 /12로 나누면 용도에 줄 수 있는 블록은 16개가 된다. 용도 4개로 시작하고, 부족해지면 블록을 하나 늘린다. 블록은 추가만 하므로 기존 경계는 움직이지 않는다. 16개 블록 중 4개만 쓰는 것은 낭비처럼 보이지만, 아무것도 옮기지 않아도 된다는 것이 더 가치 있다.

확장 여지

/12 블록은 16개다. 전사 공통, 거점, 공장, 클라우드로 4개를 쓰고 12개가 빈다. 용도를 추가할 때는 10.64.0.0/12처럼 비어 있는 블록을 하나 주고, 기존 경계는 움직이지 않는다. 검증이나 IoT처럼 나중에 생기는 용도도 기존 블록을 쪼개지 않고 새 블록을 받는다. 다음에 어느 블록을 줄지는 필요해진 시점에 정한다.

함정

• 두 번째 옥텟을 조직으로 나눈다. 조직은 몇 년마다 재편되는데 경계는 옮길 수 없으므로, 이름과 실제가 어긋난 채로 남는다. 나누는 기준은 용도로 한다.
• 용도의 종류를 처음부터 세세하게 만든다. 쓰이지 않는 블록이 늘어날 뿐 아니라, 새 요구가 어느 용도에 해당하는지 매번 판단해야 한다. 4개 정도로 시작하고 필요해지면 추가한다.
• 부족해진 용도를 위해 옆 블록의 일부를 빌린다. 블록 중간에 경계가 생기고, 이후 그 블록만 두 용도가 섞인다. 부족하면 블록을 하나 준다.
• 나눈 결과만 남기고 이유는 남기지 않는다. 다음 담당자는 어느 블록이 무엇인지는 읽을 수 있지만 왜 용도로 나눴는지는 읽을 수 없으므로, 조직으로 다시 나누자는 제안이 주기적으로 나온다.
• 전사 공통 영역을 마지막에 잡는다. 쓰기 좋은 블록이 먼저 배정되고, 전사 공통이 멀리 떨어진 블록에 흩어진다. 전사 공통은 첫 번째 블록에 잡는다.

상황

100명 규모의 회사가 현장 장비와 검증용 기기를 192.168 대역에 두고 있다. 거래처나 위탁업체와 거점 간을 연결하는 이야기가 나올 때마다 상대 구내의 주소와 충돌해 조정이 필요해진다. 재택근무 접속에서도 직원이 가져온 무선 공유기와 충돌하는 경우가 있다.

전제

상대 구내에서 쓰는 주소를 항상 사전에 알 수 있는 것은 아닐 것. 외부와 경로를 잇는 기기와 잇지 않는 기기를 나눌 수 있을 것. 장비의 주소를 나중에 바꾸려면 입회와 재설정이 필요할 것. 10/8도 쓸 수 있는 상태일 것.

할당

이유

192.168.0.0/16은 자사만의 것이 아니다. 가정용 기기, 직원이 가져온 무선 공유기, 거래처와 위탁업체의 구내가 같은 공간을 쓰고 있다. 기본값이 192.168.0과 192.168.1에 몰린다는 것은 잘 알려져 있지만, 문제는 그것만이 아니다. 소형 기기의 기본값은 192.168.10이나 192.168.100 등에도 흩어져 있고, 상대가 무엇을 쓰는지는 대개 사전에 알 수 없다.

충돌한 블록을 그때그때 피하는 방식으로 하면 피한 기록이 계속 늘어난다. 10년쯤 운용하면 피한 블록이 수십 개가 되고, 새 상대가 생길 때마다 목록과 대조해야 한다. 대조는 사람이 하므로 빠뜨린다.

그래서 거꾸로 한다. 쓰는 범위를 상위 비트로 고정하고, 세 번째 옥텟이 128 이상인 쪽만 자사의 것으로 한다. 절반을 버리게 되지만 판단은 한 번으로 끝난다. 100명 규모라면 쓰는 블록은 10개도 안 되므로 128개면 충분히 남는다.

두는 것도 제한한다. 이 공간에 두어도 되는 것은 다른 회사나 다른 거점과 경로가 이어지지 않는 것뿐이다. 충돌을 피할 수 없는 공간임을 알고 있다면, 충돌해도 곤란하지 않은 것만 두면 된다. 거점 간 연결의 반대편에서 보이는 것, 상호 접속으로 나가는 것은 10.0.0.0/8에서 가져온다.

확장 여지

자사가 쓰는 것은 세 번째 옥텟이 128 이상인 쪽뿐이며, 128개 블록 중 4개를 쓴다. 나머지 절반인 192.168.0.0/17은 비워 두고, 상대가 늘어도 블록별 대조는 하지 않는다. 판단은 세 번째 옥텟이 128 이상인지 한 번 확인하는 것으로 끝난다. 외부와 경로를 이어야 하는 것이 생기면 이 공간에 두지 않고 10.0.0.0/8에서 가져온다. 장비가 늘어도 쓰는 쪽 절반으로 충분하다.

함정

• 192.168 전체를 자사 공간으로 쓰는 전제로 나눈다. 상호 접속할 때마다 충돌이 생기고, 그때마다 블록을 피하는 식으로 대응하게 되어 피한 기록이 흩어진다. 쓰는 범위를 상위 비트로 고정한다.
• 충돌한 블록의 목록을 만들어 피한다. 상대가 늘 때마다 대조가 필요하고, 사람이 하므로 빠뜨린다. 판단이 상위 비트 한 번으로 끝나는 형태로 한다.
• 외부에서 보이는 장비를 이 공간에 둔다. 상대 구내와 충돌했을 때 피할 수 있는 것은 자사 쪽뿐이므로 장비의 주소를 바꾸게 된다. 외부로 나가는 것은 10.0.0.0/8에서 가져온다.
• 절반을 버리는 것이 아깝다는 이유로 쓰지 않는 쪽도 쓰기 시작한다. 쓰기 시작한 블록은 되돌릴 수 없고, 얻는 것 없이 판단의 단순함만 잃는다. 100명 규모라면 128개 블록으로 충분히 남는다.

상황

직원 100명 안팎, 1개 층 또는 2개 층을 쓰는 본사·지사. 유선과 무선을 모두 사용하고, 파일 서버와 NAS를 사내에 두고 있는 가장 전형적인 구성이다.

전제

L3 스위치 또는 VLAN을 지원하는 라우터가 1대 이상 있을 것. DHCP는 네트워크 장비와 서버 중 어느 쪽에 두어도 될 것. 향후 3년 안에 인원이 1.5배로 늘어날 가능성을 감안할 것.

할당

이유

100명 규모에서 가장 먼저 고민하는 것은 ‘/24 하나로 충분한가’인데, 답은 유선만이라면 충분하지만 /24 하나로 나누어서는 안 된다는 것이다. 유선 클라이언트만이라면 /24에 들어간다. 그러나 업무용 스마트폰과 노트북의 무선 연결까지 세면 1인당 단말은 실제로 2~3대가 되고, /24의 254개는 금방 찬다.

그래서 /22를 확보하고 내부를 /24와 /26으로 나눈다. 유선 클라이언트와 무선을 각각 독립된 /24로 하는 것은 DHCP 풀의 고갈이 다른 쪽으로 번지지 않게 하기 위해서다. 서버와 관리를 /26에 머물게 하는 것은 이 규모에서는 60대를 넘는 일이 거의 없고, 크게 잡으면 세 번째 옥텟의 가독성을 잃기 때문이다.

세 번째 옥텟에 의미를 부여한 것도 의도적이다. 0=유선, 1=고정 IP 기기, 2=무선, 3=2단계용으로 대응시켜 두면, 패킷 캡처나 로그를 보는 순간 어느 세그먼트인지 알 수 있다. 이 가독성은 장애 대응 속도와 직결된다.

확장 여지

10.20.3.0/24를 통째로 비워 두었으므로, 인원이 1.5배가 되어도 무선을 /23으로 넓히거나 부서별 세그먼트를 하나 추가할 수 있다. 서버의 /26이 비좁아지면 10.20.1.128/27의 프린터를 10.20.1.192/27로 옮기고, 비게 된 10.20.1.128/26으로 기기 관리를 옮기면 10.20.1.0/25로 서버를 두 배로 늘릴 수 있다. 거점을 하나 더 늘릴 때는 10.21.0.0/22, 10.22.0.0/22로 이어 가고 10.20.0.0/14로 집약한다.

함정

• 192.168.1.0/24나 192.168.0.0/24를 사내망에 써 버린다. 가정용 공유기의 기본값과 충돌하기 때문에 재택근무 VPN 접속에서 경로가 깨진다. 10/8에서 잘라 쓰는 것이 무난하다.
• 무선과 유선 클라이언트를 같은 세그먼트에 묶는다. 나중에 방문자용 SSID를 추가하고 싶을 때 주소 설계부터 다시 해야 한다. 처음부터 나누어 두는 비용은 거의 없다.
• 네트워크 장비의 관리 주소를 클라이언트 세그먼트에 섞는다. ACL로 관리 접근만 따로 제한할 수 없게 되고, 감사에서 반드시 지적받는다.
• 예비 /24를 ‘비어 있으니까’라며 눈앞의 용도에 써 버린다. 예비는 쓰지 않는 데 가치가 있으므로, 이름을 ‘예비’가 아니라 ‘2단계용’으로 붙여 두면 지켜지기 쉽다.

상황

좌석을 고정하지 않는 100석 규모의 거점. 재직 인원 120명에 대해 출근율이 날마다 40%에서 80%까지 오르내린다. 모두가 노트북을 들고 다니며, 유선 포트는 회의실과 일부 고정석에만 남아 있다. 파견이나 상주 협력업체 같은 단기 체류자가 늘 10명 안팎 있다.

전제

무선이 거점 전체를 덮고, 직원이 단말을 무선만으로 써서 업무를 할 수 있을 것. DHCP 임대 시간을 세그먼트별로 바꿀 수 있을 것. 출입 기록 등에서 날마다의 실제 재석 인원을 나중에 꺼낼 수 있을 것. 좌석 예약 제도는 도입하지 않은 상태일 것.

할당

이유

풀의 크기를 정할 때 가장 먼저 나오는 숫자는 좌석 수 100과 재직 인원 120이다. 먼저 좌석 수는 제외한다. 다음으로 생각할 것은 최대 재석 시의 단말 수로, 출근율 80%라면 96명이고 1인이 노트북과 업무용 스마트폰을 가지므로 192대가 된다. 여기까지라면 /24의 254개에 들어간다.

어긋나는 것은 그다음이다. 자율좌석제에서는 오늘 누가 올지 정해지지 않는다. 임대 시간을 24시간으로 해 두면, 어제 오고 오늘 오지 않은 사람의 단말 주소가 아직 살아 있다. 출근율이 40%와 80% 사이를 오간다는 것은, 이틀 연속으로 오는 사람이 적은 날이 있다는 뜻이다. 40%(48명) 다음 날이 80%(96명)이고 얼굴이 거의 겹치지 않으면, 이틀 동안 온 사람은 재직 인원 120명에 가까워지고 살아 있는 임대는 최대 240대가 된다. /24의 254개 중 94%로, 남는 것은 14개뿐이다. 고갈은 가장 붐비는 날이 아니라 얼굴이 바뀌는 날에 일어난다. 세어야 할 것은 최대 재석 인원이 아니라 임대 시간 동안 올 수 있는 인원, 즉 재직 인원에 가까운 수다.

그렇다면 임대를 짧게 하면 되느냐 하면, 하한이 있다. 점심시간과 오후 회의로 노트북을 덮으면 3~4시간은 통신이 없고, 임대를 2시간으로 하면 복귀할 때 다른 주소를 받는 단말이 나온다. 임대 시간의 상한은 풀의 크기가, 하한은 일하는 방식이 정한다. 둘 다 충족하려면 풀에 /23을 잡을 수밖에 없다. 510개가 있으면 240대여도 53%가 남는다.

/23을 잡는 시점에서 세 번째 옥텟과 세그먼트의 대응은 무너지지만, 이 거점에서는 가독성보다 고갈 회피를 우선한다. 또한 늘 이동하면서 통신하는 단말을 같은 풀에 넣을 때는 별도의 판단이 필요하다.

확장 여지

옆의 10.16.10.0/23을 비워 둔 것은 장래를 위해서가 아니라 풀을 하나의 서브넷으로 넓히기 위해서다. 풀은 나누어 덧붙일 수 없으므로, /23을 /22로 만들려면 인접한 /23이 통째로 비어 있어야 한다. 판단 시점을 재직 인원 210명으로 둔 것은, 이틀 동안 거의 전원이 오면 420대가 되어 /23의 510개 중 82%에 이르기 때문이다. 그때 인접 블록을 합쳐 10.16.8.0/22로 하고, 임대 시간은 그대로 둔다. 이 제약 때문에 유선도 서버도 10.16.12.0/24로 밀려나 있다. 비워 둔 공간을 풀어도 되는 조건을 먼저 정해 두지 않으면, 빈 공간은 반드시 다른 용도에 쓰이게 된다.

함정

• 좌석 수로 풀을 정한다. 100석이니까 /25를 잘라 두면, 1인 2대와 단기 체류자를 세는 순간 부족해져 운용을 시작한 주에 고갈된다. 세는 것은 좌석이 아니라 단말이다.
• 고갈을 피하려고 임대 시간을 줄여 회전을 높인다. 점심시간이나 회의 뒤에 복귀한 단말이 다른 주소를 받아 통신이 끊기지만, 끊기는 것이 복귀하는 순간뿐이라 재현되지 않고 보고도 올라오지 않는다.
• 단기 체류자의 단말을 직원과 같은 풀에 넣는다. 재직 인원으로 추정한 대수와 실제가 계속 어긋나, 증원할 때마다 주소가 몇 개 부족했는지 설명할 수 없게 된다. 수를 예측할 수 있는 쪽과 없는 쪽은 나눈다.
• 유선 포트에 고정 IP를 나눠 주는 운용을 남겨 둔다. 자율좌석제에서는 같은 포트에 날마다 다른 사람이 앉으므로 주소와 사용자의 대응이 금방 무너지고, 주소 대장만 남는다. 유선도 DHCP로 나눠 준다.

상황

본사 1곳, 지역 허브 8곳, 영업소와 창고 141곳으로 모두 150개 거점. 각 거점은 지역 허브를 거쳐 본사에 연결되고, 경로는 지역 허브에서 집약해 상위로 넘긴다. 거점 번호는 이미 자산 관리와 장표에 쓰이고 있으며, 개설 순서대로 붙어 있다. 해마다 몇 곳이 열리고 몇 곳이 닫힌다.

전제

지역 허브가 산하 거점을 하나로 집약해 광고할 수 있을 것. 거점 번호 체계가 이미 있고, 주소 설계 사정으로는 다시 붙일 수 없을 것. 한 거점의 단말이 1,000대를 넘지 않을 것. 거점이 어느 지역에 속하는지가 몇 년 단위로는 바뀌지 않을 것.

할당

이유

150개 거점을 상위로 150개 경로로 넘기지 않으려고 집약한다. 그런데 집약에 필요한 것은 주소 블록이 연속되는 것이지, 거점 번호가 연속되는 것이 아니다. 이것을 혼동하면 설계 전체가 헛수고가 된다.

거점 번호는 이미 있다. 자산 관리와 장표에 쓰이고, 개설 순서대로 붙어 있으며, 지역과는 대응하지 않는다. 이 번호를 그대로 두 번째 옥텟에 옮기면, 지역 3의 허브가 맡는 것은 거점 3, 17, 42, 88처럼 띄엄띄엄한 집합이 된다. 띄엄띄엄한 블록은 하나로 묶이지 않으므로 상위로 나가는 경로는 150개 그대로 남는다. 집약을 위해 번호를 다시 붙일 수도 없다. 번호는 장표와 호칭에 박혀 있다.

그래서 순서를 거꾸로 한다. 집약 단위, 즉 지역 허브에 먼저 블록을 할당하고, 거점 번호는 그 블록 안에서 식별자로 나눠 준다. 지역 8곳에 두 번째 옥텟을 하나씩, 거점에는 /22 블록을 하나씩 준다. 한 지역에는 64개 거점까지 들어간다. 150개 거점이면 가장 큰 지역도 24개뿐이라 모두 들어가고, 상위로 나가는 경로는 8개가 된다. 거점이 두 배인 300개로 늘어도 8개 그대로다.

대가는 주소에서 거점 번호를 읽을 수 없게 된다는 점이다. 읽을 수 있게 하려면 지역의 연속성을 버려야 한다. 장애 대응에 필요한 것은 번호 규칙이 아니라 거점 번호와 블록의 대응표 한 장이다.

확장 여지

지역 블록은 두 번째 옥텟 1부터 8이고, 0은 전사 공통으로 쓴다. 9부터 15까지 7개 블록은 비워 두고, 지역 증설과 64개 거점을 넘은 지역에 주는 두 번째 지역 블록에 쓴다. 이 번호는 연속되지 않으므로 대응표에서 찾는다. 10.16.0.0/12 위로는 손대지 않고, 인수나 다른 사업의 수용을 위해 남긴다.

함정

• 거점 번호를 그대로 주소에 대응시킨다. 번호는 개설 순서로 정해져 지역과 대응하지 않으므로, 같은 허브 산하가 띄엄띄엄해지고 상위로 나가는 경로가 거점 수만큼 남는다. 번호는 지역 블록 안에서 나눠 준다.
• 거점 간 링크의 주소를 그 거점의 블록에서 가져온다. 상대가 다른 지역의 거점이면 이 지역 블록의 주소가 다른 지역에 놓이고, 그만큼 세분화된 경로가 상위로 나간다. 링크는 거점 블록 밖의 공통 블록에서 가져온다.
• 거점 안의 세그먼트를 거점 블록의 경계를 넘어 추가한다. 넘친 부분은 집약에 포함되지 않아 그 거점만 세분화된 경로가 상위로 나간다. 추가는 블록 안에서만 하고, 넘으면 두 번째 블록을 준다.
• 주소에서 거점 번호를 읽을 수 있어야 한다는 것을 요건으로 삼는다. 읽을 수 있게 하면 지역의 연속성을 버리게 되어 집약이 성립하지 않는다. 필요한 것은 번호 규칙이 아니라 대응표다.
• 한 거점만 지리적 사정으로 다른 지역 허브에 수용한다. 주소는 원래 지역 블록 그대로이므로 상위에는 지역 블록과 그 거점만의 경로가 나란히 선다. 수용처를 바꾸려면 주소째 옮긴다.

상황

점대점 링크를 300개 이상 가진 망에서 링크의 프리픽스 길이를 정한다. 기기는 세대가 섞여 있어, 오래된 장치와 특정 용도 장치, 가상 기기가 함께 있다. 주소를 절약하고 싶다는 이유로 /31로 통일하자는 제안이 나와 있다.

전제

링크 양 끝에 있는 기기의 모델과 세대를 목록으로 만들 수 있을 것. 기기가 /31을 처리할 수 있는지 미리 확인할 수 있을 것. 할당을 한곳에서 하고 있을 것. 링크 주소를 나중에 바꾸면 설정과 모니터링을 고쳐 써야 하는 환경일 것.

할당

이유

/30은 주소 4개 중 2개만 쓸 수 있고, /31은 2개 모두 쓸 수 있다. 필요한 주소 수는 절반이 된다.

하지만 절약으로서는 의미가 없다. 링크가 352개라면 /30으로 1,408개, /31로 704개다. 차이인 704개는 링크용으로 잡은 /16 블록의 약 1퍼센트에 불과하다. 이 정도 차이 때문에 판단을 바꿀 이유는 없다.

결정적인 것은 기기가 모두 지원하느냐다. /31은 모든 기기가 처리할 수 있는 것이 아니다. 오래된 장치, 특정 용도 장치, 가상 기기 중 어느 것이 지원하지 않는 경우가 있다. 링크는 양 끝에 기기가 한 대씩 있으므로, 한 대라도 지원하지 않으면 그 링크는 결국 /30이 된다.

섞어 쓰면 할당 절차가 달라진다. 풀 안에 두 가지 크기가 섞이고, 할당할 때마다 양 끝 두 대의 지원 여부를 조사하게 된다. 한 달에 10개라면 연 120회다. 절약한 704개 주소는 연 120회의 조사만큼의 가치가 없다.

그러므로 통일한다. 모든 기기가 지원하면 /31, 한 대라도 미지원이 남아 있으면 모두 /30이다. 굳이 섞으려면 대역을 나눠, 할당할 때마다 조사하지 않아도 되게 한다.

하나 더. 한번 /30으로 자른 링크는 기기가 교체되어도 /31로 옮기지 않는다. 옮기려면 주소를 바꿔야 하고, 설정과 모니터링의 이름이 고쳐 쓰이기 때문이다. 언젠가 옮긴다는 전제는 두지 않는다.

확장 여지

기본은 /30이고, 지원을 확인한 구간만 /31 대역에서 자른다. 대역을 나누는 것은 할당할 때 기기의 지원 여부를 조사하지 않아도 되게 하기 위해서다. /31 대역에 구간을 더하는 것은 양 끝 기기가 교체되어 지원을 확인했을 때뿐이다. 증분은 10.161.16.0/21에서 낸다. 모든 기기가 교체되어도 기존 /30 링크는 전환하지 않는다. 새로 만드는 링크만 /31로 자른다.

함정

• 주소 절약을 이유로 /31을 고른다. 절약되는 것은 링크용 블록의 약 1퍼센트로, 판단을 바꿀 이유가 되지 않는다. 결정적인 것은 기기가 모두 지원하느냐다.
• 두 가지 크기를 같은 대역에 섞는다. 할당할 때마다 양 끝 두 대의 지원 여부를 조사하게 되어, 한 달에 10개라면 연 120회의 작업이 늘어난다. 섞으려면 대역을 나눈다.
• 미지원 기기가 한 대 있는데도 /31을 기본으로 하고, 그 구간만 /30 예외로 둔다. 기기를 교체할 때마다 지원 여부를 확인해야 하고, 한 번이라도 잊으면 그 링크를 쓸 수 없게 된다. 기본은 /30으로 하고, /31은 지원을 확인한 구간의 대역에서 자른다.
• 언젠가 /31로 옮긴다는 전제로 /30을 고른다. 옮기려면 주소를 바꿔야 하고, 설정과 모니터링의 이름이 고쳐 쓰인다. 옮기지 않는다는 전제로 정한다.

상황

100명 규모의 회사에서 방문자용 무선을 마련한다. 평소 방문자 단말은 20대 정도지만, 설명회나 전시가 있는 날에는 400대가 한꺼번에 들어온다. 사내망으로 가는 통신은 필터로 막고 있지만, 이름 해석과 주소 배포는 사내망과 같은 기기를 쓰고 있다.

전제

방문자용 무선을 사내 무선과 별도의 대역으로 낼 수 있을 것. 방문자용으로 바깥으로 나가는 출구를 하나 마련할 수 있을 것. 이름 해석과 주소 배포 기기를 방문자용으로 따로 둘 수 있을 것. 172.16/12 안에 쓸 수 있는 위치가 있을 것.

할당

이유

방문자용 무선에 필요한 것은 사내망과 끊어 두는 것뿐이라고 흔히 생각한다. 사내망으로 가는 통신을 필터로 막으면 된다는 생각이다. 이것으로는 부족하다.

방문자 대역이 사내망과 공유하는 것은 필터 바깥에도 있다. 이름 해석을 사내 기기로 하게 하면, 방문자 단말은 사내 서버의 이름을 조회할 수 있다. 답을 돌려주지 않아도, 어떤 이름이 존재하는지는 조회에 대한 반응으로 알 수 있다. 주소 배포를 사내망과 같은 기기로 하면, 100명 회사에 400대가 들어오는 행사 날에 사내 주소 배포까지 막힌다. 시각을 사내망에 맞추게 하면, 사내 시각 서버로 가는 경로를 하나 여는 셈이 된다.

그래서 방문자 대역은 사내망과 아무것도 공유하지 않는다. 사내의 어느 세그먼트로도 경로를 두지 않고, 출구는 바깥으로 나가는 하나뿐이다. 이름 해석도 주소 배포도 방문자만을 위해 따로 둔다. 필터로 막는 것이 아니라, 막아야 할 경로가 애초에 존재하지 않는 형태로 만든다. 막은 경로는 한 줄로 열리지만, 없는 경로는 열 방법이 없다.

주소를 고르는 방식에도 이유가 있다. 방문자 단말의 대부분은 자기 회사로 연결을 맺는다. 상대 회사가 내부에서 10/8을 쓰고 있는데 방문자 대역도 10/8에 있으면, 상대 쪽에서 주소가 겹쳐 방문자는 자기 회사에 연결할 수 없게 된다. 대역은 172.16/12 안에서 잘 쓰이지 않는 위치에서 잡는다.

확장 여지

방문자 대역은 사내망 어디로도 경로를 두지 않고, 출구는 바깥으로 나가는 하나뿐이다. 이름 해석과 주소 배포도 방문자용으로 따로 둔다. 행사로 단말이 늘면 172.30.4.0/22를 더해 받고, 더한 부분도 같은 출구로 내보낸다. 사내망으로 가는 경로는 늘리지 않는다. 대역은 172.16/12 안에서 잡고, 방문자의 회사가 쓰고 있을 법한 10/8과는 겹치지 않게 한다.

함정

• 사내망으로 가는 통신을 필터로 막는 것으로 끝낸다. 이름 해석이나 주소 배포를 사내망과 공유하고 있으면, 필터 바깥에서 사내 정보가 새고 부하도 전해진다. 아무것도 공유하지 않는다.
• 방문자 단말에 사내 이름 해석을 쓰게 한다. 답을 돌려주지 않아도, 어떤 이름이 존재하는지가 조회에 대한 반응으로 드러난다. 방문자용으로 따로 둔다.
• 방문자 주소 배포를 사내망과 같은 기기로 한다. 행사 날 방문자가 급증하면 사내 주소 배포까지 막힌다. 주소 배포는 방문자용으로 나눈다.
• 방문자 대역을 10/8에서 잡는다. 방문자가 자기 회사로 연결을 맺을 때 상대 회사의 내부망과 주소가 겹쳐 연결되지 않는다. 172.16/12에서 잘 쓰이지 않는 위치에서 잡는다.

상황

500명 규모의 회사에서 DMZ에 두는 기기가 해마다 늘어 왔다. 공개용 웹 서버, 거래처와 파일을 주고받는 서버, 외부에서 오는 메일을 받는 기기, 외부 서비스를 호출하기만 하는 서버, 모니터링 알림을 바깥으로 보내는 기기가 하나의 대역에 함께 있다.

전제

외부에서 시작되는 통신을 받는 기기와 바깥으로 나가기만 하는 기기를 구별할 수 있을 것. 거래처와의 연결 상대를 특정할 수 있을 것. DMZ 대역을 상대별로 나누어 낼 수 있을 것. 대역 간 통신을 경계에서 막을 수 있을 것.

할당

이유

DMZ에 무엇을 둘지의 기준은 하나다. 외부에서 시작되는 통신을 받는 기기를 둔다.

기준이 없으면 바깥과 통신하는 것이 전부 들어간다. 사내에서 바깥으로 나가기만 하는 기기, 외부 서비스를 호출하기만 하는 서버, 모니터링 알림을 바깥으로 보내는 기기. 이들은 외부에서 시작되는 통신을 받지 않으므로 DMZ에 둘 이유가 없다. 두면 DMZ가 부풀고, 그중 한 대가 침입당했을 때 옆에 있는 전부에 닿게 된다.

둘 것을 정했으면 다음은 받는 상대로 나눈다. 공개용과 거래처용은 같은 대역에 두지 않는다. 공개용은 누구나 오므로 침입당한다는 전제로 생각한다. 거래처용은 상대가 정해져 있으므로 허용은 훨씬 좁다. 같은 대역에 있으면, 공개용 서버가 침입당했을 때 거래처와 주고받는 파일에 옆에서 닿는다. 상대를 좁힌 의미가 사라진다.

나눈 대역 간 통신은 허용하지 않는다. 공개용에서 거래처용으로 갈 이유가 업무상 하나도 없기 때문이다.

외부에서 받는 기기가 새로 나왔는데 누구에게서 받는지가 분명하지 않을 때는 공개용에 넣는다. 상대를 좁힐 수 없는 기기를 거래처용에 넣으면 거래처용 대역의 전제가 무너진다.

확장 여지

DMZ는 받는 상대별로 나누고, 공개용과 거래처용은 다른 대역에 둔다. 대역 간 통신은 허용하지 않는다. 외부에서 받는 기기가 새로 나오면 누구에게서 받는지로 대역을 정하고, 정해지지 않으면 공개용에 넣는다. 대역이 부족해지면 10.170.1.0/24에서 자른다. 바깥으로 나가기만 하는 기기는 늘어나도 DMZ에 넣지 않는다.

함정

• 바깥과 통신하는 것을 전부 DMZ에 넣는다. 바깥으로 나가기만 하는 기기까지 들어가면 DMZ가 부풀고, 한 대의 침입이 옆의 전부에 닿는다. 두는 것은 외부에서 시작되는 통신을 받는 기기로 한정한다.
• 공개용과 거래처용을 같은 대역에 둔다. 공개용이 침입당했을 때 거래처와 주고받는 파일에 옆에서 닿는다. 받는 상대별로 대역을 나눈다.
• 나눈 대역 간 통신을 만일을 위해서라며 허용해 둔다. 업무상 이유가 없는 허용은 침입당했을 때의 통로가 될 뿐이다. 대역 간에는 허용하지 않는다.
• 상대가 분명하지 않은 기기를 거래처용에 넣는다. 거래처용 대역은 상대가 정해져 있다는 전제로 허용을 좁히고 있으므로, 그 전제가 무너진다. 망설여지면 공개용에 넣는다.

상황

클라우드의 가상 네트워크에 기기 10대를 두는 작은 서브넷을 장애 영역마다 만든다. 사내망과 같은 감각으로 /28을 자르면 14대를 둘 수 있을 거라고 생각한다. 같은 가상 네트워크에는 200대 정도의 애플리케이션 서브넷도 둘 예정이다.

전제

쓰는 사업자가 서브넷 안의 주소 몇 개를 먼저 가져간다는 것을 알고 있을 것. 사업자가 가져가는 수와 만들 수 있는 최소 크기를 확인할 수 있을 것. 서브넷을 만든 뒤에는 크기를 바꿀 수 없을 것. 가상 네트워크 안에 빈 공간이 있을 것.

할당

이유

클라우드에서 서브넷을 만들면 사업자가 그 안의 주소 몇 개를 먼저 가져간다. 사업자마다 다르지만, 앞쪽 4개와 마지막 1개, 합쳐서 5개를 가져가는 형태가 많다. 사내망에서 쓸 수 없는 것은 처음과 마지막 2개뿐이므로, 이 차이를 모른 채 자르면 주소가 모자란다.

차이는 작은 서브넷일수록 크게 작용한다. /24라면 256개 중 5개로 2퍼센트에 불과하다. /26이라면 64개 중 5개로 8퍼센트다. 만들 수 있는 최소 크기인 /28에서는 16개 중 5개, 약 30퍼센트가 사라진다. 쓸 수 있는 것은 11개다.

사내 감각으로 /28을 자르면 14대를 둘 생각이었는데 11대밖에 둘 수 없다. 기기 10대를 둔다면 여유는 1대뿐이고, 2대를 더하는 날 넘친다. 서브넷은 만든 뒤에 크기를 바꿀 수 없으므로, 넘치면 다시 만들어야 한다.

그래서 작은 서브넷을 자를 때는 예약을 뺀 수로 대수와 비교한다. 10대라면 /28이 아니라 /27을 잡는다. /27이면 32개에서 5개를 빼고 27개를 쓸 수 있다. 작게 자를수록 손실 비율이 커지므로, 작은 서브넷은 사내보다 한 단계 크게 자르는 것을 기본으로 한다.

예약 수는 사업자마다 다르고, 만들 수 있는 최소 크기도 다르다. 계산 탭에서 예약 프로필을 고르면 쓸 수 있는 수가 바로 나온다. 산정은 거기서 확인한다.

확장 여지

작은 서브넷은 예약 5개를 뺀 다음 대수와 비교한다. 10대라면 /28이 아니라 /27을 잡는다. 장애 영역마다 같은 크기로 나열하고, 영역 수만큼 만든다. 서브넷이 늘면 10.216.2.0/24에서 자른다. 산정이 애매하면 계산 탭에서 예약 프로필을 골라 쓸 수 있는 수를 확인한다.

함정

• 사내 감각으로 쓸 수 있는 수를 센다. 처음과 마지막 2개만 빼면 사업자가 가져가는 나머지 3개를 놓쳐, 둘 생각이었던 대수가 들어가지 않는다. 예약을 뺀 수로 비교한다.
• 만들 수 있는 최소 크기인 /28을 표준으로 한다. 16개 중 5개가 사라져 쓸 수 있는 것은 11개뿐이다. 몇 대만 더해도 넘친다. 10대 규모라면 /27을 잡는다.
• 서브넷은 나중에 넓히면 된다고 생각한다. 만든 뒤에는 크기를 바꿀 수 없고, 넘치면 다시 만들어야 한다. 처음부터 예약을 포함해 산정한다.
• 예약 수가 어느 사업자나 같다고 생각한다. 사업자에 따라 가져가는 수도, 만들 수 있는 최소 크기도 다르다. 쓰는 사업자의 프로필로 확인한다.

상황

인수한 회사의 망을 자사 망과 잇는다. 양쪽 모두 10/8을 쓰고 있어 여러 대역이 겹친다. 업무 사정상 다음 달에는 이어져 있어야 하며, 어느 쪽이든 주소를 재부여할 시간은 없다. 경계에서 주소를 변환해 잇는 안이 나와 있다.

전제

양사 망 사이에 주소를 변환할 수 있는 경계를 한 곳 둘 수 있을 것. 변환 후의 주소를 양쪽 어느 주소 공간에도 없는 곳에서 잡을 수 있을 것. 변환 규칙에 기한을 적어 넣을 수 있을 것. 재부여할 쪽을 경영의 판단을 기다리지 않고 정할 수 있을 것.

할당

이유

중복된 두 망을 잇는 방법은 두 가지다. 어느 한쪽의 주소를 재부여하거나, 경계에서 주소를 변환하는 것이다. 변환은 하룻밤이면 들어가고, 재부여는 몇 달이 걸린다. 통합 초기에 변환을 고르는 것은 옳다.

문제는 변환이 영구화되는 데 있다. 변환으로 통신이 통해 버리므로 재부여할 이유가 사라진다. 3년 뒤에는 변환 규칙이 쌓여 아무도 전체를 설명하지 못하게 된다. 장애가 날 때마다 로그에 찍힌 주소가 변환 전인지 후인지를 확인하게 된다.

그래서 변환을 넣는 날 두 가지를 동시에 정한다. 기한과 재부여할 쪽이다. 기한은 날짜로 정하고 변환 규칙 자체에 적어 둔다. 재부여할 쪽은 그날 안에 정하고, 변환 기간은 재부여의 준비 기간으로 다룬다. 어느 쪽을 재부여할지 정하지 않은 변환은 기한이 와도 연장할 수밖에 없다.

변환 후의 주소는 양쪽 어느 공간에도 없는 곳에서 잡는다. 자사도 상대도 10/8을 쓰고 있어서 겹친 것이라면, 변환 후의 주소는 172.16/12에서 잡는다. 어느 한쪽 10/8의 빈 곳을 쓰면, 다음에 다른 회사를 받아들일 때 다시 겹친다.

영구적이어도 되는 변환도 있다. 같은 구성을 그대로 복사해 만든 라인처럼, 같은 주소가 나란히 계속 존재하는 것이 설계의 전제라면 변환은 영구적인 것이 옳다. 통합에서의 중복은 전제가 아니라 사고이며, 사고에 대한 응급 처치를 영구적으로 만들어서는 안 된다.

확장 여지

변환 후의 대역은 172.16/12 안에서 잡고, 상대 망을 보기 위한 대역과 자사 망을 상대에게 보여 주는 대역을 나눈다. 변환 규칙에는 기한을 적고, 기한까지 변환을 넣은 날 정한 쪽의 주소를 재부여한다. 기한까지 늘어나는 분은 172.18.24.0/22에서 자른다. 기한이 지난 변환은 연장하지 않으며, 연장이 필요하면 재부여할 쪽의 판단부터 다시 한다.

함정

• 변환을 넣을 때 기한을 정하지 않는다. 통신이 통해 버리므로 재부여할 이유가 사라지고, 변환 규칙이 쌓여 아무도 설명하지 못하게 된다.
• 재부여할 쪽을 정하지 않고 변환을 넣는다. 기한이 와도 어느 쪽을 옮길지의 논의부터 시작하게 되므로 연장할 수밖에 없다. 변환과 같은 날 정한다.
• 변환 후의 주소를 자사 10/8의 빈 곳에서 잡는다. 다음에 다른 회사를 받아들일 때 다시 겹친다. 양쪽 어느 공간에도 없는 곳에서 잡는다.
• 변환 규칙을 한 대씩 쓴다. 기한 관리도 한 대씩 하게 되어, 어떤 규칙이 남아 있는지 알 수 없게 된다. 대역 단위로 쓴다.

상황

같은 장비 구성의 생산 라인이 여러 개 있고, 앞으로도 라인을 늘릴 예정인 공장이다. 장비 공급업체가 납품한 제어 기기에는 고정 IP가 출하 시점부터 박혀 있으며, 라인 사이에 같은 주소가 중복된 상태에서 출발한다.

전제

각 라인의 제어 기기 주소를 바꿀 수 없거나, 바꾸려면 장비 공급업체의 재검수가 필요할 것. 라인끼리 직접 통신할 필요는 없고, 상위의 수집 시스템과만 통신하면 될 것. 라인 경계에 L3 장비나 NAT가 가능한 장비를 둘 수 있을 것.

할당

이유

OT 네트워크가 IT와 결정적으로 다른 점은 주소를 자유롭게 정할 수 없다는 것이다. 장비 공급업체는 여러 고객에게 같은 구성을 납품하기 때문에 제어 기기의 주소는 출하 시점에 고정되어 있고, 같은 192.168.0.10이 2번 라인에도 3번 라인에도 존재한다. 이를 IT 쪽의 상식대로 "중복되니까 재부여한다"고 처리하면 장비 보증과 재검수 이야기로 번지고, 현장은 멈춘다.

그래서 재부여하지 않는다. 라인 내부의 주소는 장비 공급업체의 설정 그대로 건드리지 않고, 라인 경계의 장비에서 1:1 주소 변환을 걸어 바깥에서 보이는 주소만 라인 번호로 구분한다. 1번 라인의 제어 기기는 바깥에서 172.20.1.x로, 2번 라인의 같은 기기는 172.20.2.x로 보인다. 세 번째 옥텟을 라인 번호로 하는 규칙으로 해 두면, 수집 시스템의 로그를 보는 사람이 기기 이름을 몰라도 어느 라인인지 바로 판별할 수 있다.

이 설계의 본질은 장비 공급업체의 사정과 IT 쪽의 관리 편의를 변환이라는 한 겹의 층으로 분리하는 데 있다. 라인 내부는 "장비 공급업체의 세계", 경계부터 위는 "정보시스템 부서의 세계"로 선을 긋는다. 라인을 늘릴 때마다 설계를 다시 하지 않고, 번호를 하나 늘려 같은 설정을 복사하기만 하면 된다는 것이 가장 큰 이점이다.

확장 여지

가까운 증설용으로 172.20.4.0/22(4~7번 라인)를 예약해 두었다. 기준 블록이 /16이므로 세 번째 옥텟을 라인 번호로 쓰는 규칙 그대로 255번 라인까지 닿고(0은 라인 번호로 쓰지 않고 공용 수집·유지보수에 쓴다), 8번 이후는 172.20.8.0/21, 172.20.16.0/20으로 자연스럽게 이어 갈 수 있다. 공장이 늘어나면 두 번째 옥텟을 공장 번호로 삼아 172.21.0.0/16을 다음 공장에 할당하고, 172.20.0.0/15로 집약한다. 한 라인이 /24로 부족해지는 것은 라인 안의 제어 기기가 250대를 넘을 때인데, 그 규모라면 라인을 논리적으로 나누는 편이 운용하기 쉽다.

함정

• 라인 사이의 통신을 "만일을 위해" 허용한다. 한 라인이 악성코드에 감염되면 같은 구성의 모든 라인이 한꺼번에 멈춘다. 라인 사이는 원칙적으로 차단하고, 필요한 통신은 수집 시스템을 거치게 한다.
• 유지보수 단말용 세그먼트를 마련하지 않고 반입 PC를 제어 세그먼트에 바로 꽂는다. OT 보안 사고의 입구로 가장 흔한 경로이며, 기록도 남지 않는다. 전용 세그먼트를 만들고 거기서만 제어 쪽으로 들어가게 한다.
• 주소 변환의 대응표를 장비 설정 안에만 둔다. 설정한 담당자가 이동하면 어느 외부 주소가 어느 장비인지 아무도 설명할 수 없게 된다. 대응표는 설계서 쪽에 1차 정보로 둔다.
• 공장 주소에 192.168 대역을 쓴다. 유지보수 업체가 들고 오는 라우터나 모바일 라우터와 충돌하기 쉽고, 게다가 충돌은 현장에서만 드러난다. 172.16/12나 10/8에서 잘라 쓴다.
• 라인 번호와 주소의 대응을 증설할 때마다 비어 있는 번호를 채우는 식으로 정한다. 7번 라인이 철거되고 나중에 다른 장비가 들어오면 번호와 실물이 어긋나 아무도 믿지 않게 된다. 번호는 재사용하지 않는다.

상황

부지 안에 사무동과 공장동이 있고, 지금까지 하나의 네트워크로 운용해 온 직원 300명 규모의 공장이다. 생산관리 시스템에서 장비로 내리는 지시와 장비에서 올리는 실적 수집은 앞으로도 필요하지만, 사무실 PC가 제어 기기에 직접 닿는 상태는 없애고 싶다. 라인 내부 설계에는 손대지 않고, 라인의 위아래 경계만 먼저 다시 긋는 단계다.

전제

사무 쪽과 공장 쪽 사이에 L3 장비를 1대 이상 둘 수 있을 것. 양쪽을 넘나드는 통신을 적어도 연계 서버 단위로 상대와 방향별로 정리할 수 있을 것. 이번에는 제어 기기의 주소를 바꾸지 않고, 라인 내부의 재설계는 따로 할 것. 경계 장비가 멈춘 동안에도 생산을 계속할 수 있어야 한다는 것을 요건에 포함할 것.

할당

이유

분리에 반대하는 사람은 없다. 정해지지 않는 것은 경계에 둘 구역을 어느 크기로 하느냐다.

경계를 /24로 잡으면 반드시 실패한다. 이 규모에서 정말로 양쪽과 통신해야 하는 것은 연계 서버뿐이고, 열몇 대에 그친다. 남은 240여 개는 빈터가 되고, 빈터는 반드시 채워진다. 반년 뒤에는 정보계의 파일 서버가, 이듬해에는 사무 쪽 인증 기반에 가입한 점프 서버가 들어온다. 그 시점에 경계는 더 이상 경계가 아니지만, 주소표 위에서는 아무것도 바뀌지 않으므로 아무도 알아채지 못한다.

그래서 연계는 /28로 제한한다. 14개밖에 없으면 15번째를 두려는 사람은 반드시 누군가와 상의하게 된다. 크기를 운용 규칙으로 작동시키는 것이 목적이며, 증설 여지는 옆에 다른 이름의 2단계용으로 두고 연계 구역 자체는 넓히지 않는다.

/20을 0~3(IT)·4~7(경계)·8~15(제어)의 세 영역으로 나눈 것도 의도한 것이다. 경계 장비의 필터를 10.60.0.0/22, 10.60.4.0/22, 10.60.8.0/21 세 줄로 다 쓸 수 있고, 세그먼트를 추가해도 이 세 줄은 바뀌지 않는다. 추가할 때마다 필터를 건드리는 설계는 언젠가 잘못 건드려 생산을 멈추게 한다.

제어망 공용 서비스 구역(/25)을 제어 쪽에 둔 것은 가용성 때문이다. 경계 장비가 멈춰 있는 동안에도 생산은 계속된다. 시간 동기화와 이름 해석을 사무 쪽에 의존시키면 경계의 정지가 그대로 제어 쪽의 정지가 된다.

확장 여지

경계에는 10.60.4.64/26을 2단계용으로 비워 두었다. 연계를 넓히는 용도가 아니라 외부 데이터 연동이나 원격 유지보수 중개를 나중에 더하는 자리다. 제어 쪽은 라인별 구역으로 10.60.12.0/22를 비워 두었고, 라인 단위 설계는 여기에 둔다. 무선이 /24로 부족해지면 10.60.10.0/23을 추가한다. 공장이 늘어나면 10.60.16.0/20을 다음 공장에 할당하고 10.60.0.0/16으로 집약한다. 세 영역을 /22 단위로 맞춰 두었으므로 어느 공장에서도 필터 세 줄이 같은 형태가 된다.

함정

• 경계에 점프 서버를 두고 그것을 사무 쪽 인증 기반에 가입시킨다. 인증 정보가 사무 쪽에서 흘러드는 경로가 생겨 경계의 의미가 사라진다. 점프 서버를 둔다면 인증은 경계 안에서 닫는다.
• 제어 기기의 시간 동기화 대상을 사무 쪽 서버 그대로 둔다. 경계 장비를 멈춘 순간 제어 쪽의 시각이 어긋나기 시작해, 나중에 장애를 추적할 때 로그를 맞춰 볼 수 없다. 시간 동기화는 제어 쪽에 둔다.
• 분리 요건을 "사무실에서 제어망으로 들어가지 못할 것"만으로 정의한다. 제어 쪽에서 사무 쪽으로 가는 통신이 방치되어, 장비 사이에 섞여 들어온 단말이 밖으로 나가는 경로가 남는다. 방향은 양쪽 모두 정한다.
• 연계 서버에 수집과 파일 보관까지 겸하게 한다. 멈출 수 없는 쪽 사정 때문에 업데이트할 수 없게 되고, 몇 년 지나면 아무도 손대지 못하는 서버가 된다. 역할별로 나누고, /28 안에서 대수를 관리한다.

상황

거점이 10곳인 회사가 통신사로부터 IPv6 /48을 받았다. 지금까지 IPv4에서는 대수에 맞춰 서브넷 크기를 바꾸고, 예비를 둘 위치와 단편화에 신경을 써 왔다. 같은 사고방식으로 IPv6 할당을 시작하려 하고 있다.

전제

통신사로부터 /48을 받았을 것. 사내 기기가 IPv6의 주소 자동 설정을 쓸 수 있을 것. 거점 수와 용도 수가 각각 15 이하에 머물 전망일 것. 사람이 주소를 읽고 의미를 파악하는 운용일 것.

할당

이유

/48을 받으면 그 안에는 /64가 65,536개 있다. IPv4에서 쌓아 온 사고방식의 상당수가 여기서는 반대가 된다.

IPv4에서는 서브넷 크기를 대수로 정했다. 10대라면 /28, 200대라면 /24를 썼다. IPv6에서는 그렇게 하지 않는다. 서브넷은 대수와 관계없이 항상 /64로 한다. 단말이 자기 주소를 스스로 정하는 구조는 /64를 전제로 만들어져 있다. /64보다 작게 자르면 그 구조가 동작하지 않는다.

절약도 필요 없다. /64 65,536개를 다 쓰는 조직은 거의 없다. IPv4에서 고생했던, 예비를 어디에 둘지, 단편화를 어떻게 막을지 같은 문제는 거의 사라진다.

남는 결정은 하나다. 네 번째 그룹(16비트)의 16비트를 어떻게 구분할지다. 여기서는 거점에 4비트, 용도에 4비트, 일련번호에 8비트를 준다. 의미의 경계를 16진수 자리의 경계에 맞추면 주소만 보고도 읽을 수 있다. 2001:db8:100:1200::/64라면 거점 1 서버의 첫 번째 서브넷이다.

구분은 16진수 자리에 맞춘다. 자리 중간에서 구분하면 주소를 읽을 때마다 2진수로 바꿔야 하고, 읽을 수 있다는 이점이 사라진다. 거점이 15를 넘을 전망이라면 처음부터 거점에 8비트를 주고, 용도와 일련번호에 4비트씩 준다.

확장 여지

네 번째 그룹의 첫 자리가 거점이며, 1부터 쓰고 0은 전사 공통용으로 남겨 둔다. 두 번째 자리가 용도, 마지막 두 자리가 일련번호다. 서브넷은 항상 /64이며, 대수가 늘어도 키우지 않는다. 세그먼트 표의 /64가 대수에 비해 커 보이는 것은 프로토콜이 /64를 요구하기 때문이지, 여유를 잡았기 때문이 아니다. 거점이 15를 넘으면 구분을 바꾸지 않고 두 번째 /48을 받는다.

함정

• 서브넷 크기를 대수로 정하고 /64보다 작게 자른다. 단말이 스스로 주소를 정하는 구조가 /64를 전제로 하고 있어 동작하지 않게 된다. 항상 /64로 한다.
• IPv4처럼 예비와 단편화를 신경 써서 빈틈없이 자른다. /64 65,536개를 다 쓰는 일은 거의 없어, 빈틈없이 잘라도 얻는 것이 없다. 읽기 쉬움을 우선한다.
• 네 번째 그룹을 16진수 자리 중간에서 구분한다. 주소를 읽을 때마다 2진수로 바꿔야 하고, 주소에서 의미를 읽을 수 없게 된다. 16진수 자리에 맞춰 구분한다.
• 거점 자리를 0부터 매긴다. 전사 공통을 둘 자리가 없어져 나중에 끼워 넣게 된다. 0은 전사 공통용으로 남겨 둔다.