DNS64, NAT64를 알아보자

만약 다음과 같이 Host A, Host B가 설정돼 있다면, 서로의 주소를 이해할 수 없기 때문에 두 서버는 서로 통신이 불가합니다.

Host A : IPv6 only Server

Host B : IPv4 only Server

위 상황에서 통신이 가능하게끔하기 위해 보통 IPv4 주소와 IPv6 주소를 서버에 같이 설정하여 사용하기도 하는데 이는 IPv4 고갈에 대비하기 위한 설정이 아니기 때문에 목적에 부합하다고는 볼 수 없습니다. 또한 IPv4 위에 IPv6를 위치시켜 Tunnel 구성을 하는 방법도 있으나 Tunnel인터페이스를 거쳐 통신해야 하므로 요구사항에 맞지 않을 수 있습니다.

이러한 상황을 해결하기 위해 사용할 수 있는 기술이 'DNS64', 'NAT64' 입니다.

이번 포스팅에서는 두 기술에 대해  이해해 보는 시간을 가지려 합니다.

 

NAT 64

---

[그림 1]

[그림 1]에서 7 ~ 10와 같이 통신이 가능하게끔 도와주는 기술이며 라우터 장비에서 활성화할 수 있습니다.

네트워크 엔지니어가 아니라서 장비에서 어떻게 활성화하는지는 제가 모르니 기술의 이론적인 부분만 살펴보겠습니다.

RFC6052 문서에서 볼 수 있듯이, IPv6 <-> IPv4 주소 변환을 위한 WKP (Well-Known Prefix) 영역은 64:ff9b::/96입니다. 물론 사용자가 직접 NSP(Network-Specific Prefix)를 지정할 수 있으며. Prefix의 범위에 따라 v4(32) IPv4의 변환된 주소가 위치하는 곳이 달라집니다.

RFC8215 문서에서와 같이 사설로 NAT64를 사용하는 경우 64:ff9b:1::/48를 사용하는 것으로 가이드되고 있습니다.

    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |32|     prefix    |v4(32)         | u | suffix                    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |40|     prefix        |v4(24)     | u |(8)| suffix                |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |48|     prefix            |v4(16) | u | (16)  | suffix            |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |56|     prefix                |(8)| u |  v4(24)   | suffix        |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |64|     prefix                    | u |   v4(32)      | suffix    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |96|     prefix                                    |    v4(32)     |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

사용자가 NSP를 설정하지 않았고 일반적으로 RFC에 의해 예약된 WKP를 사용한다면 64:ff9b:: 주소 뒤에 IPv6구조에 맞춰 변환된 IPv4 주소가 위치하게 됩니다.

주소변환 과정에 대해서 조금 더 가시적으로 살펴보겠습니다.

# 원본 주소
192.168.0.1

# 변환 과정
1.Prefix 뒤에 v4 주소를 위치시킨다. 
  Prefix::192.168.0.1

2. 각 v4 주소를 2진수로 변환한다.
  192 -> 1100 0000
  168 -> 1010 1000
    0 -> 0000 0000
    1 -> 0000 0001

3. 전환된 2진수 값을 4개씩 나누어 16진수로 변환한다.
  192 -> 1100 0000 -> C 0
  168 -> 1010 1000 -> A 8
    0 -> 0000 0000 -> 0 0
    1 -> 0000 0001 -> 0 1

4. 변환된 16진수를 Prefix와 합한다.
  0064:ff9b:0000:0000:0000:0000:c0a8:0001

5. IPv6 주소를 간소화한다.
  0064:ff9b:0000:0000:0000:0000:c0a8:0001

  -> 맨 앞에있는 0 생략

  64:ff9b:0000:0000:0000:0000:c0a8:0001

  -> 반복되는 :0000: 영역은 :: 로 표기하여 생략

  64:ff9b::c0a8:0001

# 변환된 주소
  64:ff9b::c0a8:0001

위에 설명드린 부분에서도 확인하실 수 있듯이

1. Prefix뒤에 v4주소를 위치시킨 다음
2. v4 주소들을 2진수로 나열하고
3. 16진수로 변환하기 위해 4자리씩 묶어 변환하고
4. Prefix와 변환한 16진수를 합한 후
5. IPv6 주소를 간소화

과정을 거쳐 주소 변환이 이루어집니다. 이제 NAT64 기능을 사용하는 라우터가 어떻게 주소 변환을 하는지 이해할 수 있게 됐습니다. 포스팅 뒤에서 나올 '주소변환'이 등장하는 용어는 해당 과정을 거쳐 진행한다고 이해해 주시면 됩니다.

그림으로 간략하게 나타내면 다음과 같습니다.

v4 -> v6

NAT64 라우터와 DNS 64가 엮어서 동작하는 것은 DNS 64를 살펴본 후에 다시 설명드리겠습니다. 여기까지는 NAT 64는 서로 다른 주소체계를 가진 서버가 통신을 하기 위해서 주소 번역을 해주는 역할을 하는구나 정도만 이해하셔도 충분합니다.

 

DNS 64

---

DNS64는 사용자가 AAAA 레코드를 요청했을 때 A 레코드만 있다면 설정한 Prefix로 NAT64에서 설명드린 변환과정을 동일하게 거쳐 AAAA레코드를 Resolver에서 반환해 주는 기능입니다.

NAT 64를 알아볼 때 v6로의 변환 과정을 이미 살펴보았기 때문에 이해하기 편하실 거라 생각이 듭니다.

결과부터 보여드리면 DNS Auth 쪽에는 test1.wyj.kr 에 대한 AAAA 레코드는 존재하지 않습니다. DNS 64 기능을 지원하지 않는 리졸버로 질의를 하게 되면 응답을 받을 수 없습니다.

하나 다음과 같이 DNS 64가 활성화된 리졸버를 통해 질의를 하게 되면 AWK Prefix와 192.168.0.1 IP가 합쳐진 64:ff9b::c0 a8:1 주소를 정상적으로 AAAA레코드 응답 값으로 수신받을 수 있습니다.

pdns-recursor # dig @127.0.0.1 -p 5355 test1.wyj.kr A +short
192.168.0.1

pdns-recursor # dig @127.0.0.1 -p 5355 test1.wyj.kr AAAA +short
64:ff9b::c0a8:1

이해를 위해 그림으로 한 번 더 확인해 보도록 하겠습니다.

1. User는 test1.wyj.kr의 AAAA 레코드 결과를 Resolver에 요청합니다.

2. Resolver는 Local Cache에 Data가 없으므로 wyj.kr Auth에 AAAA 레코드를 질의합니다.

3. Auth는 가지고 있는 AAAA 레코드가 없으므로 반환할 데이터가 없음을 응답합니다.

4. Resolver는 AAAA 레코드는 없지만 A 레코드는 있고, DNS 64 기능이 활성화돼 있으므로 Prefix값과 v4 IP를 변환하여 응답합니다.

pdns-recursor 기준 dns64-prefix 값을 설정함으로 기능을 enable 할 수 있으며 4.9 버전 기준 /96 bit subnet만 지원합니다.
dns64-prefix=64:ff9b::/96

 

실제 TCPDUMP로 확인하면 더욱 명확히 확인할 수 있습니다.

# Resolver가 Auth에 test1.wyj.kr의 AAAA레코드가 있는지 찾아봅니다.
09:12:19.557743 ethertype IPv4, IP (tos 0x0, ttl 64, id 6178, offset 0, flags [DF], proto UDP (17), length 74)
    resolver.24122 > auth.53: [bad udp cksum 0xa38f -> 0x2a3d!] 52485 [1au] AAAA? test1.wyj.kr. ar: . OPT UDPsize=1232 DO (46)

# Auth는 (0/1/1) answer 값이 0 인 응답을 주고 test1.wyj.kr에 대한 AAAA레코드는 없다고 응답합니다. 
09:12:19.559890 IP (tos 0x0, ttl 56, id 21180, offset 0, flags [DF], proto UDP (17), length 138)
    auth.53 > resolver.24122: [udp sum ok] 52485*- q: AAAA? test1.wyj.kr. 0/1/1 ns: wyj.kr. SOA gloria.ns.cloudflare.com. dns.cloudflare.com. 2324134032 10000 2400 604800 1800 ar: . OPT UDPsize=1232 DO (110)

# resolver는 dns64 설정에 의해 다시 test1.wyj.kr에 대한 A레코드를 질의합니다.
09:12:19.560065 ethertype IPv4, IP (tos 0x0, ttl 64, id 33915, offset 0, flags [DF], proto UDP (17), length 63)
    resolver.43629 > auth.53: [bad udp cksum 0x9cae -> 0x70e4!] 23753 [1au] A? test1.wyj.kr. ar: . OPT UDPsize=1232 DO (35)

# Auth는 A레코드가 있으므로 A레코드 값을 반환합니다.
09:12:19.562480 IP (tos 0x0, ttl 56, id 45135, offset 0, flags [DF], proto UDP (17), length 79)
    auth.53 > resolver.43629: [udp sum ok] 23753*- q: A? test1.wyj.kr. 1/0/1 wyj.kr. A 192.168.0.1 ar: . OPT UDPsize=1232 DO (51)

 

DNS 64 & NAT 64

---

지금까지 설명드린 부분을 모두 이해하셨다면 이제 아래 그림을 해석하실 수 있게 됩니다.

[그림 1]

0. Client는 IPv6 주소만 가지고 있기에 IPv6 주소를 가진 서버와만 통신이 가능합니다.

1. Client는 test1.wyj.kr 서버와 통신하기 위해 서버의 AAAA 레코드를 요청합니다.

2. Resolver는 Local Cache에 test1.wyj.kr의 AAAA 레코드 값이 있다면 이를 반환하고 없다면 Auth에 요청합니다.

3. Auth는 test1.wyj.kr 서버의 AAAA레코드가 없기 때문에 없음을 응답합니다.

4. Resolver는 AAAA레코드가 없지만 A레코드가 있고 DNS64가 활성화됐기 때문에 v4를 v6로 변환하여 Client에게 반환합니다.

5. Client는 받은 v6 주소를 dst에 담아 NAT 64를 통해 통신을 요청합니다.

6. NAT 64는 test1.wyj.kr서버와 통신하기 위해 src주소를 snat 하여 본인의 v4 IP로 변경하고 서버로 요청을 전달합니다.

7. 요청받은 서버는 응답을 NAT 64의 v4주소로 보냅니다.

8. NAT 64는 v4로 온 응답의 src주소를 snat 하여 본인의 v6 IP로 변경하고 Client에 요청을 전달합니다.

 

후기

---

1. NAT64의 실습은 진행하지 못해 아쉽습니다.. nftables나 실습할 수 있는 환경을 찾아봐야겠습니다.

2. DNS64로 인해 resolver는 cname과 같이 auth에 두 번의 질의를 하게 됩니다. dns64가 많이 사용하게 되면 resolver의 cache에 더 많은 공간을 확보해야 하고 쿼리수가 증가할 것을 예비해야 할 듯합니다.