▲

IPv6가 훌륭한 설계였던 세상 (2017)

 (apenwarr.ca)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 점대점 연결 중심의 초기 네트워크에는 주소 체계가 거의 필요 없었지만, 비용 절감을 위한 버스 네트워크 확산으로 MAC 주소, 브리징, ARP 같은 복잡성이 누적됨
  • Ethernet과 IP가 결합되면서 다음 홉 전달을 위해 MAC 주소 지정과 ARP 브로드캐스트가 필요해졌고, 대형 상호연결 네트워크와 wifi에서 이 부담이 크게 확대됨
  • IPv6 구상에는 물리적 버스와 layer 2 internetwork를 버리고 브로드캐스트, ARP, DHCP, MAC 주소까지 제거하는 단순한 세계에 대한 기대가 반영됨
  • 그러나 실제 배포 환경에서는 IPv4와 기존 프레이밍이 계속 남아 neighbor discovery, DHCP, NAT, layer 2 브리징 같은 유산도 함께 유지됨
  • 이동 중 연결 유지를 위해 Internet 라우팅 대신 layer 2 브리징과 중앙 터널링이 계속 쓰이고 있으며, QUIC 같은 대안이 roaming 우회 경로로 거론됨

버스 네트워크가 모든 것을 망친 계기

  • 전화망의 초기 회선 교환과 전용선 환경에서는 점대점 연결만 존재해 주소 체계가 필요 없었고, 한쪽에서 넣은 비트가 일정 시간 뒤 반대편에서 나오는 구조였음
  • TDM과 가상 회선 교환 도입 이후에도 사용자 입장에서는 여전히 한쪽 입력이 다른 쪽 출력으로 이어지는 형태였고, 이 단계에서도 주소 필요성은 없었음
  • 여러 인터페이스를 가진 컴퓨터가 선로 사이에서 비트를 전달하면서 IP 주소, 서브넷, 라우팅이 등장했지만, 점대점 링크에서는 여전히 MAC 주소가 필요하지 않았음
  • 로컬 사이트 연결 비용을 줄이기 위해 여러 장치를 하나의 선에 붙이는 버스 네트워크가 등장했고, Internet 계열과 별도로 각자 독자적인 layer 2 체계가 생겨남
  • 초기 LAN인 arcnet은 8비트 layer 2 주소를 점퍼나 DIP 스위치로 수동 설정해야 했고, 중복 시 심각한 장애가 발생했지만 네트워크가 작아 그 불편이 제한적이었음
  • Ethernet은 48비트 MAC 주소를 도입해 제조 단계에서 거의 고유한 주소를 부여하는 방식으로 중복 문제를 해결함
  • IPX와 Netware 같은 LAN 기술은 단일 버스 네트워크 안에서는 주소 설정 없이 잘 동작했고, 아름답고 신뢰성 있게 작동하던 시기로 묘사됨
  • 대형 기업과 대학 네트워크는 단일 10 Mbps 버스의 병목 때문에 여러 버스를 상호 연결해야 했지만, 당시 성숙하지 않았던 IP 대신 Ethernet 주소 기반의 브리징과 스위칭을 확장 경로로 선택함
  • Ethernet 주소는 공장 순차 할당 방식이라 계층 구조를 갖지 못해, 브리징 테이블은 서브넷 단위 경로를 다루는 최신 IP 라우팅 테이블처럼 효율적으로 묶을 수 없었음
    • 효율적 브리징을 위해 각 MAC 주소가 어느 버스에 있는지 기억해야 했음
    • 이를 수동 설정하지 않기 위해 자동 학습과 복잡한 상호작용이 필요해짐
  • 복잡한 브리지 네트워크는 spanning tree 같은 방식으로 이어졌고, 브로드캐스트 플러드, 비최적 경로, 낮은 디버깅 가능성이 뒤따름
  • 중간 브리지에는 일반 Ethernet에서 주소 개념이 없어 traceroute 같은 도구를 만들 수 없었고, 브리징은 사실상 디버깅이 거의 불가능한 구조였음
  • 그럼에도 브리징은 하드웨어 최적화 덕분에 Ethernet 선속도에 가깝게 매우 빠르게 동작했고, 당시에는 그것이 큰 장점이었음

버스 위에서 돌아가는 Internet

  • 장거리 점대점 링크로 개별 컴퓨터를 연결하던 구조에서, 점차 전체 LAN 연결 요구가 생기며 LAN끼리의 장거리 연결이 필요해짐
  • 단순한 장거리 브리지는 혼잡 제어 문제 때문에 성립하지 않았고, Ethernet 브리징은 모든 링크 속도가 비슷하거나 혼잡이 거의 없다는 전제에서만 동작했음
  • 10 Mbps Ethernet과 0.128 Mbps 점대점 링크를 직접 이어 브리징하는 방식은 희망이 없었고, flooding 기반 경로 탐색도 느린 링크에서는 지나치게 낭비가 컸음
  • 로컬 환경에서는 참을 만하던 비최적 라우팅도 느리고 비싼 장거리 링크에서는 치명적이어서 확장성이 없었음
  • 이 문제군은 Internet 쪽이 이미 다루고 있던 영역이었고, LAN 버스를 Internet 기술로 연결하면 훨씬 나은 구조가 될 수 있었음
  • 그래서 Ethernet과 arcnet 등 LAN 위에 Internet 패킷을 싣는 프레임 형식이 설계됐고, 이 지점부터 문제가 시작됨
  • Ethernet 세그먼트 안에 여러 IP 라우터가 있으면, 어느 라우터가 패킷을 받아 전달할지 구분해야 했고 최종 목적지 IP만으로는 그 선택을 표현할 수 없었음
  • 따라서 최종 목적지는 IP 헤더에 남겨두고, 실제 다음 홉 라우터는 Ethernet 프레임의 MAC 주소로 지정하는 방식이 필요해짐
  • 사람이 표현하고 싶은 실제 정보는 목적지 IP 10.1.1.1을 라우터 MAC 11:22:33:44:55:66으로 보냄이지만, 운영체제는 이를 라우터 IP 192.168.1.1 경유 같은 형태로 다루게 됨
  • 이 추상화를 위해 운영체제는 먼저 라우터 IP의 Ethernet 주소를 찾아야 했고, 그 중간 단계로 ARP가 추가됨
  • ARP는 로컬 Ethernet 전체에 브로드캐스트를 보내 특정 IP 소유자를 찾는 방식이며, 브리지가 있다면 Ethernet 브로드캐스트이므로 모든 인터페이스로 전달해야 했음
  • 대형 상호연결 Ethernet에서는 과도한 브로드캐스트가 가장 큰 악몽 중 하나가 되었고, 특히 wifi에서 더 심각했음
  • 이후 브리지와 스위치는 ARP 전달 범위를 줄이는 특수 해킹을 넣기 시작했고, 일부 장치 특히 wifi 액세스 포인트는 가짜 ARP 응답까지 생성했지만 모두 기술적 해킹에 가까웠음

유산에 의한 죽음

  • 시간이 지나면서 Ethernet 위의 비IP 프로토콜은 거의 사라졌고, 네트워크는 물리 계층 선로 위에 버스형 layer 2, 그 버스들을 잇는 브리지, 그리고 그 위에 layer 3 라우터가 얹힌 구조로 굳어짐
  • 수동 IP 설정 피로가 커지면서 자동 설정 요구가 생겼지만, 장치는 이미 Ethernet 주소를 달고 출고됐고 IPv4 32비트 주소는 제조 단계에서 영구적으로 고유 할당하기에 부족했음
  • IP 주소를 단순 순차 할당하면 다시 Ethernet 같은 비계층 구조로 돌아가므로 적절한 해법이 아니었음
  • 그래서 bootp와 DHCP가 등장했고, 이들은 ARP처럼 특별 취급이 필요한 프로토콜이 됨
  • DHCP는 IP 주소가 없는 노드가 먼저 전송해야 하므로, RFC로 규정된 형식의 사실상 무의미한 IP 헤더를 채워 넣어야 했고, DHCP 서버는 커널 IP 계층 대신 raw socket으로 이를 직접 채워 넣어야 했음
  • bootp와 DHCP는 결국 Ethernet 주소를 알아야 IP 주소를 배정할 수 있으므로, ARP의 역방향에 가까운 역할을 수행했음
  • RARP가 같은 일을 더 단순하게 수행했지만, 여기서는 거의 다뤄지지 않는다고 언급됨
  • 결과적으로 Ethernet과 IP는 점점 더 강하게 얽혀 오늘날 거의 분리 불가능한 존재가 되었음
  • IP 라우팅 테이블은 IP 주소로 라우터를 지정하는 척하지만 실제로는 MAC 주소를 우회적으로 지정하고 있으며, ARP는 브리지 위를 지나고 DHCP는 IP 패킷처럼 보이지만 실제로는 Ethernet 프로토콜에 가까운 구조가 됨
  • 동시에 브리징과 라우팅은 모두 더 복잡해졌고, 브리징은 대체로 IEEE와 하드웨어 영역, 라우팅은 대체로 IETF와 소프트웨어 영역으로 나뉜 채 서로를 없는 것처럼 다뤘음
  • 네트워크 운영자는 속도 요구와 DHCP 서버 구성 기피 정도에 따라 브리징과 라우팅을 선택했고, 가능한 한 브리징을 많이 쓰고 필요할 때만 라우팅을 사용했음
  • 브리징 복잡성은 결국 layer 2 의사결정을 상위 계층으로 끌어올려 IP 위 프로토콜로 중앙 관리하는 SDN으로 이어짐
  • SDN은 스위치와 브리지가 각자 제멋대로 동작하는 것보다 나았지만, 본래 너무 커진 네트워크를 소프트웨어로 다루는 IP 자체가 이미 소프트웨어 정의 네트워크였다는 점에서 근본적으로 우스운 면이 있다고 지적됨
  • IPv4는 초기에 하드웨어 가속이 어렵고 실제로도 하드웨어 가속이 충분히 되지 않았으며, DHCP 구성은 매우 번거로워 운영자들은 점점 더 큰 범위를 브리징하는 법을 익히게 됨
  • 오늘날 대형 데이터센터는 사실상 SDN 기반 거대한 가상 버스 네트워크처럼 동작하며, 패킷을 실질적으로 라우팅하지 않는 경우가 많다고 묘사됨

이제 앞의 이야기를 잠시 잊기

  • 1990년대 초 IETF가 IPv6를 구상할 당시에는 이미 많은 혼란이 진행 중이었지만, 다가올 재앙을 피할 수 있다는 가정 아래 설계가 진행됐음
  • 그 과정에서 핵심 변화 하나는 이미 물리적 버스 네트워크 사용이 사실상 중단됐다는 점이었음
  • Ethernet은 더 이상 실제 버스가 아니고 버스인 척만 하며, 속도 증가로 CSMA/CD를 유지할 수 없게 되자 다시 스타 토폴로지로 회귀함
  • 각 스테이션에서 중앙 스위치까지 개별 케이블을 끌어오는 구조가 일반화되며, 벽과 천장과 바닥이 크고 비싼 Ethernet 케이블 다발로 채워졌음
  • wifi조차도 공유 무선 매체라는 궁극의 버스처럼 보이지만, 실제로는 infrastructure mode로 거대한 스타 토폴로지를 흉내 내는 경우가 거의 전부라고 서술됨
  • 같은 액세스 포인트에 연결된 두 wifi 스테이션도 직접 통신하지 않고, 상대 노드의 MAC 주소를 넣은 패킷을 액세스 포인트로 보내면 액세스 포인트가 이를 다시 내보내는 방식임
  • 노드 X가 Internet 노드 Z로, IP 라우터 Y를 거쳐, wifi 액세스 포인트 A를 통해 보내는 경우에는 Z는 IP 목적지, Y는 Ethernet 목적지, A는 실제 무선 전송 상대가 되어 주소 계층이 복잡하게 겹침
  • 이를 위해 802.11은 실제 Ethernet 목적지와 중간 Ethernet 목적지를 함께 담는 3-address mode를 제공함
  • 여기에 to-AP, from-AP 비트가 있어 스테이션→AP, AP→스테이션 방향을 표시하고, 두 비트가 동시에 참이 되면 AP 간 중계기 동작도 표현 가능함
  • A가 repeater여서 다시 기지국 B로 보내야 하는 경우, 공중 전송의 실제 송수신 주체와 Ethernet 소스·목적지가 모두 달라져 4-address mode가 필요해짐
  • 802.11s mesh에는 6-address mode까지 있으며, 그쯤에서 이해를 포기했다고 적혀 있음

IPv6가 좋은 설계였던 세계

  • IPv6를 고민하던 IETF는 이미 발생한 혼란과 앞으로 생길 더 큰 혼란을 보며, 기존 레거시를 버린 새로운 세계를 상상했음
  • 그 세계의 전제는 물리적 버스 네트워크 제거, layer 2 internetwork 제거, 브로드캐스트 제거, MAC 주소 제거, ARP와 DHCP 제거, 하드웨어 가속 가능한 단순한 IP 헤더, 주소 부족 해소, 코어를 제외한 수동 IP 설정 제거였음
  • layer 2가 항상 점대점이라면 브로드캐스트를 보낼 대상 자체가 없으므로 멀티캐스트로 대체할 수 있고, 송수신 상대가 자명하므로 MAC 주소도 불필요해진다는 발상이었음
  • MAC 주소가 사라지면 IP와 MAC 사이 대응도 필요 없으므로 ARP와 DHCP도 사라질 수 있고, 큰 서브넷 라우팅을 다시 사용할 수 있을 만큼 충분한 주소 공간도 확보 가능했음
  • 그 세계에서는 wifi repeater, wifi 액세스 포인트, Ethernet 스위치, SDN까지 모두 IPv6 라우터로 동작했을 것이라는 상상이 제시됨
  • 그러면 ARP storm, IGMP snooping bridge, bridging loop가 사라지고, 모든 라우팅 문제를 traceroute로 추적 가능했을 것이라는 기대가 이어짐
  • Ethernet 패킷마다 12바이트의 송수신 MAC 주소, wifi 패킷마다 18바이트의 주소 정보를 제거할 수 있어, IPv6가 IPv4보다 24바이트 더 큰 주소를 쓰더라도 Ethernet 헤더 제거를 감안하면 실질 추가 오버헤드는 12바이트에 불과하다고 계산함
  • 이처럼 언젠가 Ethernet 주소 자체를 제거할 수 있으리라는 기대가 IPv6 주소 길이가 과도하게 커진 선택을 정당화하는 데 도움을 줬다고 서술됨
  • 그러나 이 아름다운 설계는 실제 세계에서 실현되지 않았음

꿈을 위한 진혼곡

  • "계층은 추가될 뿐 제거되지 않는다"는 직장 동료의 표현이 전체 결론으로 제시됨
  • IPv6의 장점은 기존 레거시를 버리고 다시 시작할 수 있어야만 성립했지만, 실제로는 그것이 거의 불가능했음
  • IPv6 보급률이 99%에 이르더라도 IPv4가 완전히 사라지지 않는 한 Ethernet 주소와 wifi 주소도 사라지지 않으며, IEEE 802.3과 802.11 프레이밍 표준을 유지하는 한 해당 바이트 절감도 실현되지 않음
  • 그래서 IPv6에는 결국 ARP보다 더 복잡한 neighbor discovery가 필요해졌고, 버스 네트워크가 사라졌어도 ARP식 동작을 위해 브로드캐스트 비슷한 시뮬레이션이 계속 필요해짐
  • 가정에서는 구식 IPv4 전구를 동작시키기 위해 로컬 DHCP 서버를 계속 운영해야 하고, 그 전구가 인터넷에 닿으려면 NAT도 계속 필요하다고 적혀 있음
  • 더 나쁜 점은 IPv6 팀이 mobile IP 문제를 해결하지 못한 채 남겨두었다는 점이며, 그 결과 끔찍한 layer 2 브리징이 여전히 필요해졌다고 평가됨
  • 당시에는 IPv6를 먼저 몇 년 안에 배포하고, IPv4와 MAC 주소가 사라진 뒤 mobile IP를 더 쉽게 해결할 계획이었던 것으로 이해된다고 적혀 있음
  • 당시에는 이동 중인 컴퓨터 사용 사례가 거의 없다고 여겨져, Ethernet 포트 사이를 옮겨 다니며 ftp를 지속하는 정도의 어색한 상상만 가능했던 것으로 묘사됨

모바일 IP라는 킬러 앱

  • 이후 역사에서 들고 다니는 컴퓨터, 즉 전화기를 여러 무선 액세스 포인트 사이에서 이동시키는 사용 사례가 일상이 되었음
  • LTE에서는 이런 이동이 대부분 동작하고 wifi에서는 가끔 동작하지만, 그 비밀은 Internet 라우팅이 아니라 layer 2 브리징에 있다는 지적임
  • Internet 라우팅은 이동성을 전혀 처리하지 못하고, IP 네트워크에서 움직여 IP 주소가 바뀌면 열려 있던 연결이 모두 깨짐
  • 기업용 wifi는 LAN 전체를 layer 2로 브리징해 중앙 DHCP 서버가 어느 액세스 포인트에 붙어도 같은 IP 주소를 주도록 만들고, 브리지가 재구성되는 몇 초 동안의 혼란만 감수하며 연결을 이어감
  • 여러 extender나 repeater를 가진 가정용 wifi도 같은 방식을 사용함
  • 반면 길을 걸으며 상점마다 제공하는 공용 wifi처럼 서로 다른 wifi 네트워크를 건너가면 매번 새 IP 주소를 받고, 그때마다 모든 연결이 끊김
  • LTE는 더 과감하게 여러 기지국 사이를 수 마일 이동해도 같은 IP 주소를 유지시키며, 모바일 네트워크에서는 대개 IPv6 주소를 사용한다고 언급됨
  • 그 방법은 트래픽을 중앙 지점으로 터널링한 뒤, 많은 방화벽과 함께 하나의 초거대 가상 layer 2 LAN으로 브리징하는 방식이며, 그 대가로 엄청난 복잡성과 부끄러울 정도의 추가 지연 시간이 발생함
  • 통신사는 이를 고치고 싶어 하지만 거의 불가능하다고 서술됨

모바일 IP를 실제로 동작시키는 방법 1

  • mobile IP가 왜 제대로 안 되는지에 대한 답은, 세션 식별에 쓰는 유명한 4-tuple 정의가 잘못됐기 때문이라는 결론으로 이어짐
  • TCP와 UDP 세션은 (source ip, source port, destination ip, destination port)로 식별되는데, 이 구조는 layer 3과 layer 4를 가로지르며 IP 주소 변화에 취약함
  • 세션 식별이 layer 4 데이터만으로 이뤄졌다면 mobile IP는 완벽하게 동작했을 것이라는 주장이 제시됨
  • 예시로 X:1111이 Y:80과 통신할 때, X가 Q로 주소를 바꾸면 패킷은 (Q,1111,Y,80)이 되어 Y는 이를 기존 세션으로 인식하지 못하고 버리며, Y가 (Y,80,X,1111)로 되돌린 패킷도 더는 X에 도달하지 못함
  • 대안으로 포트 번호를 현재 16비트 대신 128 또는 256비트 정도의 고유한 해시 값으로 키우고, 소켓을 IP 주소와 무관한 태그로 식별하는 그림이 제시됨
  • 이 경우 패킷은 여전히 layer 3에서 (X,Y) 주소 정보를 포함해 라우팅되지만, 커널은 수신 시 layer 3 정보를 소켓 식별에 사용하지 않고 uuid만 사용함
  • 목적지 포트 80은 새 세션 시작 시 원하는 서비스를 구분하는 데만 필요하고, 이후에는 무시하거나 생략할 수 있다고 적혀 있음
  • Y의 커널은 (uuid) 세션 패킷이 최근에 X에서 왔음을 캐시하고, X가 Q로 이동한 뒤 같은 (uuid,80) 태그를 달고 오면 해당 세션으로 매칭하면서 응답 목적지를 X 대신 Q로 갱신할 수 있음
  • 이렇게 하면 연결이 유지되지만, 사칭자에 의한 연결 탈취를 막기 위한 추가 주의가 필요하다는 단서가 붙음
  • 그러나 UDP와 TCP는 이렇게 동작하지 않고, 지금 와서 이를 바꾸는 일은 IPv4를 IPv6로 바꾸는 것처럼 쉬워 보였지만 수십 년 뒤에도 절반 미만만 끝난 종류의 프로젝트라고 평가됨

QUIC와 우회 가능한 가능성

  • 긍정적인 면으로, 또 하나의 계층 위반을 통해 우회적 해결 가능성이 제시됨
  • 낡은 TCP를 버리고 UDP 위의 QUIC를 사용하면, UDP의 4-tuple 자체를 연결 식별자로 사용하지 않는 방식이 가능해짐
  • UDP 포트가 특별한 mobility layer 포트라면, 그 안의 내용을 다시 풀어 적절한 uuid 태그를 가진 내부 패킷으로 해석하고 이를 올바른 세션과 소켓에 매칭할 수 있음
  • 실험적 QUIC 프로토콜은 적어도 이론상 이런 구조에 맞는 패킷 형식을 이미 갖추고 있다고 서술됨
  • QUIC가 사용하는 무상태 패킷 암호화와 인증에는 원래도 고유한 세션 식별자 또는 키가 필요하므로, 비교적 적은 작업으로 투명한 roaming 지원이 가능할 수 있다는 기대가 제시됨
  • 그렇게 되면 남은 UDP와 TCP를 Internet에서 모두 제거하기만 하면, 이번에는 정말로 layer 2 브리징이 더는 필요 없어지고, 브로드캐스트와 MAC 주소, SDN, DHCP도 없앨 수 있다는 결론으로 이어짐
  • 마지막은 Internet의 우아함 회복이라는 문장으로 마무리됨

보충 수정 사항

  • 2017-08-16 수정

    • 앞선 mobile IP 관련 구상은 IPv6에 한정되지 않음
    • IPv4와 NAT 환경, 심지어 여러 NAT를 가로지르는 roaming에서도 동작 가능하다고 수정됨

  • 2017-08-15 수정

    • 연결 탈취 방지 방법으로 TCP 시작 시점의 SYN-ACK-SYNACK 유사 교환이 가장 단순한 예로 제시됨
    • Y가 새 호스트 Q의 첫 패킷을 바로 신뢰하면, 인터넷 어디에서나 공격자가 X→Y 연결을 가로채기 쉬워짐
    • Y가 쿠키를 보내고 Q가 이를 받아 처리해 다시 Y로 돌려보내게 하면, 적어도 단순 외부 공격자가 아니라 중간자 수준은 되어야 공격 가능해짐
    • QUIC 같은 암호화된 프로토콜을 쓰는 경우, 해당 핸드셰이크도 세션 키로 보호 가능함

  • 2017-10-24 수정

    • QUIC 외에도 이런 roaming 지원형 TCP 대체 프로토콜 후보가 있으며, MinimaLT가 예시로 언급됨
    • MinimaLT는 roaming 문제를 우아하게 해결한 첫 프로토콜로 들었다고 적혀 있으며, 앞으로 채택될 해법도 이 구조를 본뜰 가능성이 언급됨

  • 2020-07-09 수정

    • IPv4/IPv6 마이그레이션과 상호운용성에 대한 추가 생각을 다른 글에 게시했다는 언급만 있고, 본문 안의 추가 설명은 없음

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 내 관점에서는 IPv6가 완벽한 프로토콜 설계의 정점은 아니어도, 사람들이 더 낫다고 내놓는 대안이 결국 IPv6와 비슷한 형태로 수렴함. 다들 꾸준히 이보다 나은 걸 못 만든다면, IPv6는 결국 꽤 괜찮은 설계라는 뜻이라고 봄

    • 내가 보기엔 그보다 더 강한 얘기임. 사람들이 내놓는 거의 모든 더 나은 대안은 사실 IPv6 설계 과정에서 이미 검토됐다가, 대체로 충분한 이유를 가지고 기각된 아이디어였음
    • 돌이켜보면 IPv4에 16비트나 32비트만 더 붙였어도 충분했을 것 같지만, 그래도 IPv6가 괜찮고 잘 동작한다는 점에는 동의함. 내가 듣는 불만 대부분은 무지에서 오지만, 예외 하나는 긴 주소임. 이건 진짜 불편하고 사람이 읽는 인코딩도 별로라서, 가독성 좋은 표현 방식만 고쳐도 도움이 클 것 같음
    • 나는 그 해석에 동의하지 않음. 세상은 계속 바뀌고, IPv6는 1998년에 네트워크 장비 회사들의 필요를 중심으로 설계됐다고 봄. 최종 사용자나 네트워크 관리자, 앱 개발자 관점은 충분히 반영되지 않았다고 느낌. 지금까지 남아 있는 이유도 상당 부분 매몰비용과 오래된 기술 부채 때문이라고 봄. 오늘 새로 설계한다면 SD-WAN, 모바일 수요, 칩 가격 변화 같은 조건이 완전히 다르니 다른 프로토콜이 나올 가능성이 큼. 나는 소스와 목적지 주소 개념 자체도 다시 생각해야 한다고 봄. 2026년에 기본적으로 0RTT 암호화가 없는 네트워크 계층은 시대착오적으로 느껴짐. ND, ARP, RA, DHCP처럼 기본적으로 신뢰를 전제하는 요소들도 인증이 없어서 불안함. 이웃 장치가 특정 주소를 가진다고 주장하면 왜 내 장치가 그냥 믿어야 하는지 의문임. 유선이든 무선이든 네트워크에 붙을 때 왜 상대 네트워크의 보안성과 신원 체계를 검증하지 않는지도 답답함. 보안, 신뢰, 신원 문제가 중심이 돼야 하는데 그렇지 못했고, 새 기능도 결국 벤더 수익 구조에 맞춰지는 느낌이 강함. 보안 외에도 숫자 기반 주소 대신 identity-based addressing으로 가는 방향이 중요하다고 봄. 이 기술 의존도가 너무 큰 만큼 정부 개입도 필요하다고 느끼며, 미래 세대와 화성 식민지에도 2005년식 주소와 보안 문제를 넘기는 건 씁쓸하다고 느낌
    • 나는 그들이 더 잘할 수 없었다는 식의 해석에는 동의하지 않음. 그냥 출시하고 끝낸 느낌이 강함. IPv6처럼 크게 바꾸기보다, 좀 더 여러 번 다듬어서 IPv4의 연장선에 가까운 ipv4+ 를 만들었어야 했다고 봄

  • 예전 Hacker News 토론들을 모아보면 2017년 스레드, 2019년 스레드, 2020년 스레드, 2023년 스레드처럼 이 주제가 몇 년 주기로 계속 반복되고 있음

  • 나는 이 글이 ARP를 너무 부정적으로 보는 점은 마음에 들지 않음. ARP 덕분에 라우터 없이도 LAN 안에서 IP 네트워킹이 가능해지고, 기본 게이트웨이도 같은 일반적 LAN IP 통신의 특수 사례로 다룰 수 있음. 다만 네트워킹 역사 설명 자체는 정말 훌륭하고, 아직 IPv6 부분은 읽는 중임

    • 물론 레이어 2 주소를 해결하는 방식이 ARP만 있는 건 아니라고 봄. ARP는 계층 위반과 과도한 브로드캐스트 트래픽을 낳고, 그게 WiFi 같은 환경에서 추가 문제를 만든다고 느낌. 예를 들어 IPv6의 NDP는 ICMPv6 기반의 실제 IPv6 패킷 위에서 동작해서 이런 위반이 없고, 멀티캐스트 덕분에 레이어 2 전체에 브로드캐스트를 뿌릴 필요도 줄어듦

  • 나는 이 글이 정확히 뭘 말하려는지 조금 헷갈림. 내 네트워크 장비들이 MAC 주소 기반으로 스스로 IPv6 주소를 잡는다는 얘기인지, 그게 stateless IPv6의 핵심인지 궁금함. 내가 알기로 IPv6는 IPv4 고갈과 NAT 문제를 해결하려고 나온 것이기도 함. 그런데 내 Xbox는 IPv6가 없다고 네트워크가 별로라고 하는데, 이것도 꽤 북미 중심적 시각처럼 느껴짐

    • 정확히 말하면 요즘 대부분의 비서버 장비는 MAC 주소나 EUI64 대신 RFC8064와 RFC7217에서 말하는 semantically opaque interface identifiers를 쓰는 편임. 안정적인 주소는 주로 인바운드용으로 쓰고, 아웃바운드에는 시간에 따라 바뀌는 임시 privacy address를 쓸 수 있음. 그리고 stateless라는 건 DHCPv6 같은 중앙 설정 없이, 장비가 SLAAC로 스스로 주소를 구성한다는 뜻에서 성립함
    • 내 생각에 Xbox가 불평하는 건 IPv6 자체보다 UPnP 부재일 가능성이 큼. 물론 IPv6가 있으면 그런 문제 일부가 줄어들 수는 있음. 다만 아이러니하게도 콘솔 쪽이 IPv6 지원은 오히려 늦었던 편이라, Xbox가 실제로 얼마나 잘 지원하는지는 나도 궁금함
    • 나는 반대로 IPv4 없이 Xbox가 제대로 동작하는지도 궁금함. 내 회사 Windows 장비는 그렇지 못하고, 다른 게임 콘솔들도 IPv4 의존성이 남아 있는 걸 알고 있음

  • 나는 IPv6에서 SLAAC와 DHCPv6를 둘 다 둔 것이 큰 실수였다고 점점 느끼고 있음. SLAAC 자체는 훌륭하지만 설정 메커니즘이 둘이면 너무 헷갈림. Android가 DHCPv6를 지원하지 않는 점도 혼란을 더 키움. 내 추측으로 SLAAC는 컴퓨터가 비싸고 DHCP 서버가 별도 장비이던 시대의 산물임. 하지만 지금은 컴퓨터가 싸고 대부분의 라우터가 DHCP를 돌릴 수 있으니 상황이 다름. DHCPv6가 기본적으로 MAC 기반 주소를 나눠주는 쪽으로 갔으면 설정이 더 단순했을 것 같고, 링크 로컬에서는 자동 설정도 그대로 유지됐을 것 같음

    • 참고로 Android 11부터는 Prefix Delegation 형태의 DHCPv6 지원이 있긴 함. 다만 관련 글을 보면, 여전히 플랫폼 쪽의 우리가 더 잘 안다식 접근으로 느껴지는 부분이 있다고 봄

  • 나는 이 글이 매우 흥미로웠지만 한 지점은 잘 이해가 안 됨. 저자가 WiFi에서도 이제 CSMA/CD를 쓰지 않는다고 말하는데, 그럼 실제로는 어떻게 동작하는지 궁금함. 저자는 같은 액세스 포인트에 붙은 두 WiFi 스테이션도 서로 직접 통신하지 않는다고 설명함. 그렇다면 각 스테이션은 자신이 듣는 신호가 자기 것인지, 다른 스테이션이 AP에 보내는 것인지, 아니면 AP가 다른 스테이션에 보내는 것인지를 어느 시점엔가는 구분해야 함. 그렇다면 이름만 다를 뿐 비슷한 메커니즘은 여전히 필요한 것 아닌지 궁금함

    • 내가 알기로 WiFi는 원래부터 CSMA/CA를 써왔고, 802.11ax부터는 OFDMA도 함께 활용함. 이 배경은 Hidden node problem 설명에서 잘 볼 수 있음

  • 예전에는 IPv6가 피할 수 없는 다음 단계처럼 보였는데, 지금 와서 이렇게 힘이 빠진 걸 보면 애초에 해결하려던 문제가 그렇게 중요하지 않았던 건가 하는 생각이 듦. 실사용자 관점에서는 어쨌든 IPv4 주소를 어떻게든 충분히 확보해서 인터넷이 계속 굴러가는 것처럼 보였고, 그래서 정말 IPv6가 필요했던 게 맞는지 스스로 의문이 듦. 이 결론이 틀린 건지 궁금함

    • 나는 여기서 말하는 우리가 누구인지부터 애매하다고 느낌. 예전엔 신청만 하면 /24도 받을 수 있었지만, 지금은 폐쇄된 스패머 네트워크가 쓰던 대역을 중고로 사야 해서 IP 평판이 엉망인 경우도 많음. 직접 뭔가를 호스팅하려 해도 큰 네트워크 단위가 아니면 사실상 미국 회사에서 IPv4 하나를 임대해야 하는 상황이 흔함. 내게는 이게 마치 우라늄이 이론상 시장에 있다면서 실제로는 구하기 극도로 어려운 상황과 비슷하게 느껴짐
    • 나는 그 문제가 여전히 중요하다고 봄. NAT 같은 우회책이 존재하는 것 자체가 그 증거라고 느낌. 사람들은 점점 덜 좋은 환경에 익숙해졌고, 높은 지연의 통화 품질이나 Cloudflare 같은 인프라가 멈췄을 때 통신 전체가 막히는 상황도 당연하게 받아들이고 있음. 하지만 인터넷은 원래 그런 중앙 의존을 피하려고 설계된 것임. 내게는 이걸 두고 문제가 없다고 말하는 게, 오늘 출근에 성공했으니 교통 체증은 문제 없다고 말하는 것처럼 들림. 더 길게, 더 큰 그림으로 봐야 한다고 느낌
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.