[컴퓨터 네트워크] 29. Network Layer (5) : IPv6

IPv6

(IPv5는 실험적 목적이므로 건너감!)

IPv6는 나온지 20년이 넘은 꽤 오래된 개념이다.

약 27년전 시점부터 IPv4의 주소가 고갈될게 분명해져서 그 전에 새로운 주소 체계를 도입하고자 등장한 것이 IPv6이였다.

그런데 주소 체계를 바꾼다는 것은 꽤 큰 일이다.

32bit 에서 128bit 주소 체계로 바꾼다는 것은, 일단 양립성을 포기하는 것과 같다.

32bit 주소체계를 쓰면서 동시에 128bit 주소 체계를 사용하는 것이 불가능하기 때문이다.

 

그래서 IPv6를 설계할 때는 어차피 처음부터 만들 거 IPv4에서 마음에 안들었던 부분을 다같이 바꾸자고 생각했고, 많은 부분들이 개선되었다. (option, checksum 과 같은 필드가 삭제되었다.)

따라서 헤더의 크기가 고정되었기 때문에, 프로세싱이 빨라지는 이점이 생겼다.

 

여기에 더해 Flow의 개념도 도입이 되었다.

27년 전에는 flow 개념이 명확하지 않았다.

flow는 어떤 데이터 흐름을 말하는데, 같은 성격을 가진 데이터 흐름을 플로우로 잡을 수도 있고 (요청한 사용자가 다르더라도 모두 비디오 스트리밍 성격의 트래픽을 요청한다면 이들을 같은 플로우로 묶는다.), 동일한 사용자가 동일한 시간대에 요청한 연속적인 데이터 흐름을 플로우로 묶을 수도 있다.

 

플로우는 어떻게 묶든 정의를 해라, 다만 그렇게 플로우를 구분해서 묶었으면, 플로우 별로 별도 처리가 가능한 개념을 넣었으면 좋겠다고 생각해서 IPv6 에는 flow identifier가 존재한다.

 

IPv6 Header

 

IPv6의 헤더는 위와 같다.

IPv4에 비하면 매우 깔끔해진 것을 볼 수 있다.

 

핵심은 네트워크 계층의 주소인 IP주소이다.

이 주소값의 길이는 128bit 이므로 source, destination 각각 128bit 씩 들어간다.

 

[첫번째 줄]

ver = version

pri = priority, 혹시 IPv6가 패킷의 priority를 고려해서 차별화된 서비스를 제공하지 않을까 생각해서 도입된 필드이다.

flow label =  상술한 플로우 개념을 사용하기 위한 flow identifier 필드이다. (그런데 flow 개념이 아직 제대로 정의되지는 않았다.)

 

[두번째 줄]

payload len = 데이터 필드의 길이이다. 4계층에 없었던 데이터 길이 정보를 이 정보를 토대로 여전히 알 수 있다.

IPv4와 달리 이제 헤더의 길이는 알 필요가 없다. 그 길이가 40byte로 고정되어 있기 때문이다. (IP주소 2개에 32byte, 나머지 헤더 2개 줄 8byte)

 

IPv4에서는 만약 옵션이 없는 경우, 20byte 였고, TCP헤더 길이까지 합치면 진짜 페이로드를 제외한 헤더만 40byte 였으나, IPv6의 경우, 단독으로 40byte의 길이를 갖는다. 헷갈리지 말자!

 

next header = IPv4의 upper layer 필드에 해당하는 내용이다. TCP, UDP 와 같은 값이 들어갈 것이다.

말 그대로 현재 IP 헤더 다음에 들어가는 헤더의 종류를 나타내는 필드인 것이다.

 

hop limit = IPv4의 TTL에 해당하는 값이다. 1씩 감소하면서 패킷이 네트워크 내에서 길을 잃었을 때 적절한 타이밍에 버려질 수 있도록 제어하는 필드이다.

 

 

굉장히 깔끔하게 필드를 구성한 프로토콜이지만, 잘 사용되지는 않는다.

물론 전혀 안쓰는 것은 아니다.

중간에 IPv6로 트래픽을 전달하는 구간이 있을 수 있기 때문이다. 다만 일반 사용자 입장에서는 IPv6를 사용하는 상황을 보기가 힘들다.

유명한 웹서버들이 IPv6를 지원하지 않는 것은 아니지만, 클라이언트에서 굳이 IPv6로 요청을 보내지 않는다.

기존에 사용하던 IPv4로 요청을 보내도 웹서버는 둘 다 지원해서 충분히 서비스를 받을 수 있기 때문이다.

따라서 일반적인 컴퓨터로 어떤 웹서버에 IPv6 주소로 접근할 일은 거의 없다.

 

IPv4와 비교했을 때, 빠진 개념은 checksum, fragmentation / reassembly, option 이다.

(2계층의 기술이 이더넷으로 거의 통일되어가고 있고, 새로운 기술이 나오더라도 프레임 사이즈는 인터넷과 보통 맞춰서 나오기 때문에 굳이 프래그멘테이션을 쓸 일이 없다. 옵션의 경우 필요하다면 어플리케이션에서 구현하라는 것이 IPv6의 원칙이다.)

 

IPv4 에서 IPv6로의 전환

사실 IPv4에서 IPv6로 전환하는 것은 쉽지 않다.

IPv6로 바꾸는 제일 강제적인 방법은 flag day 이다.

특정한 날을 정해서 이날부터는 IPv6를 사용하자고 전세계적으로 동시에 합의를 보는 것이다.

업그레이드 안된 뒤쳐지는 로드가 없기 때문에 가능하다면 제일 깔끔하지만, 어떤 메이저 업데이트를 전 세계적으로 딱 맞춰서 하는 것은 쉽지 않다. 각 국가마다 이해관계가 다 다르기 때문이다.

굳이 잘 쓰고 있는 IPv4를 놔두고 새로운 네트워크 장비를 사면서까지 IPv6로 넘어가야 하냐고 생각하는 국가나 기관들이 굉장히 많다.

 

하지만 선제적으로 IPv6를 도입한 기업이나 라우터들도 충분히 있을 수 있다.

이런 기업이나 라우터 (노드)는 IPv6, IPv4를 동시에 지원하고있다.

즉, 네트워크를 구성하는 노드가 IPv4만 지원하는 노드, IPv4 / IPv6를 모두 지원하는 노드로 나눠진 것이다.

따라서 IPv4와 IPv6가 공존할 수 있는 tunneling 기술이 등장했다.

 

IPv6를 이해하고 있는 어떤 노드가 있다고 하자.

그리고 이 노드가 자신과 멀리 떨어져있는 목적지에 데이터를 보내는데, 이 목적지도 IPv6를 이해하고 있다고 하자.

그런데 중간에 통과하는 라우터는 IPv4밖에 모른다고 해보자.

그러면 중간에 통과하는 라우터에 맞게 IPv4 방식을 맞춰줄 필요가 있다.

 

그래서 IPv6 패킷을 보낼 때, 중간 노드들이 이해할 수 있도록 추가적으로 IPv4 헤더를 씌우는 것을 터널링 기법이라고 한다.

tunnelling 예시

 

어떤 이더넷이 IPv6 라우터를 서로 연결하고 있다.

이때는 그냥 IPv6 패킷을 보내면 될 것이다.

빨간 부분은 데이터 링크 계층의 헤더가 되어 프레임 단위로 데이터가 왔다갔다 한다.

 

 

하지만 그림과 같이 중간에 IPv4 만 지원하는 네트워크가 있다면

 

이렇게 IPv4 터널이 IPv6 라우터를 연결하고 있다고 표현할 수 있다.

 

이때는 IPv6 데이터그램이 IPv4 의 데이터로 들어가고, IPv4 데이터그램이 터널의 전송단위가 될 것이다.

하나의 패킷을 터널 지나가듯 다른 패킷에 넣는다고 해서 터널링 기법이라고 한다.

---

 

구체적인 예시를 살펴보면, 그림과 같이 논리적인 관점에서는 IPv6 라우터 2개가 IPv4 터널을 통해 연결되어있다고 볼 수 있고, 실제 물리적인 관점에서는 IPv6 사이에 IPv4 라우터가 연결된 형태가 될 것이다.

 

 

이때 실제로 주고받는 데이터그램의 형태를 보면 위와 같이 되어있다.

 

중간에 flow 라는 필드에는 IPv6 라는 것을 구분하기 위해 플로우에 X라는 데이터를 넣었다.

A-B, E-F 사이에는 IPv6 형태의 데이터그램을 주고 받고, 그 중간에는 IPv4 형태의 데이터그램을 주고 받아야하므로, 기존 IPv6 데이터그램을 IPv4 데이터 그램의 데이터로 넣어서 주고 받는다.

 

B는 IPv6, IPv4를 모두 지원하는데, 자신과 연결된 C가 IPv4만 지원하는 것을 보고 자신이 보낼 패킷을 IPv4 데이터그램에 담아서 보낸다. (C가 IPv4만 지원하는 것은 라우팅 프로토콜에 의해 파악한다.) 이때 Src, Dest 는 각각 B, E 가 된다.

목적지가 E라는 것도 라우팅 프로토콜을 통해 파악한다.

C, D 는 내가 받은 IPv4 패킷의 목적지가 E라고 생각하고 패킷을 전송한다.

 

E는 자신에게 도착한 패킷을 보고 해석을 하는데, 해석해보니 자신에게 온 데이터가 IPv6인 것을 확인했다.

E는 IPv6도 지원하기 때문에 이 패킷 역시 해석할 수 있다.

따라서 이 패킷을 해석한 내용을 토대로 F에 자신의 데이터로 들어온 IPv6 패킷을 전송한다.

 

---

IPv6 채택 현황

그렇다면 IPv6는 얼마나 많이 쓰이고 있을까?

 

이 통계는 약 4년정도 된 통계이다.

이 통계에 따르면 대략 30% 정도는 IPv6를 사용하고 있다는 것을 알 수 있다.

하지만 아직 2/3는 IPv6를 사용할 준비가 되어있지 않다는 것을 알 수 있다.

 

등장한지가 오래되었음에도 이렇게 IPv6가 잘 사용되지 않는 이유는 NAT같은 여러 꼼수가 등장했기 때문이다.

또 CIDR 의 등장으로 IP를 조금 더 세밀하게 컨트롤해서 낭비되는 IP주소를 최소화할 수 있게 되면서 IPv6로 넘어가는 것을 저지하고 있다.