Moving Beyond NAT (translation of NAT를 넘어서 가자)

content/posts/2019/03/beginning.eng.md

@@ -1,14 +1,16 @@
 ---
 title: Prologue
 date: 2019-03-29
+translated: 2019-04-04
 authors: [swen.mun, hong.minhee]
+translators: [kidon.seo]
 ---
 
-Hello World. This is Team [Planetarium]—builders of [open source library that allows anyone to create decentralized multi-play game through blockchain technology][1].
+Hello World. This is Team [Planetarium] --- builders of [open source library that allows anyone to create decentralized multi-play game through blockchain technology][1].
 
-Ever since [Bitcoin] revealed itself to the world in 2009, lots of studies and researches have been done on decentralization and blockchain tech. These concepts can be traced back to a specific field in computer science called [distributed computing]. Despite a fairly lengthy history of these technologies, applying them in conjunction with game development process at the blockchain core level often causes difficulties e.g. direct application of existing research or a lack of implementations in the platforms required for game development. 
+Ever since [Bitcoin] revealed itself to the world in 2009, lots of studies and researches have been done on decentralization and blockchain tech. These concepts can be traced back to a specific field in computer science called [distributed computing]. Despite a fairly lengthy history of these technologies, applying them in conjunction with game development process at the blockchain core level often causes difficulties, e.g., direct application of existing research or a lack of implementations in the platforms required for game development.
 
-We're going to share what we've learned through our trial and error in short, light format. Like "snack", we’re aiming for short, breathless experiences that do not burden readers compared to conventional, gruesome blog posts-- and we’re hoping to update them regularly. 
+We're going to share what we've learned through our trial and error in short, light format. Like "snack", we're aiming for short, breathless experiences that do not burden readers compared to conventional, gruesome blog posts --- and we're hoping to update them regularly.
 
 We'll be back with our first post. Till then.
 

content/posts/2019/04/nat_traversal_1.eng.md

@@ -0,0 +1,101 @@
+---
+title: Moving Beyond NAT
+date: 2019-04-04
+translated: 2019-04-08
+authors: [swen.mun]
+translators: [kidon.seo]
+---
+
+Hello, I'm Swen Mun from the Planetarium Engineering Team.
+Today we're going to talk about what's known as [<abbr title="Network Address Translation">NAT</abbr> transversal techniques][1].
+
+[1]: https://en.wikipedia.org/wiki/NAT_traversal
+
+
+So what's the problem?
+----------------------
+
+From game servers to smartphones, every device connected to the Internet has an [IP address].
+This enables devices to connect to one another and send/receive messages.
+
+The fundamental problem with IP address is that quantity is limited.
+In the case of [IPv4] --- the most widely used protocol, it uses 32-bit addresses which means address space is limited to 2<sup>32</sup> (more than 4 billion) addresses.
+(Of course we don't use all of these addresses.)
+This seems enough at first glance, but it's far short of operating more than one device per person on the planet.
+In fact, since 2011, [IPv4 addresses have all been exhausted][2] and no new addresses have been assigned.
+
+To solve this problem, [IPv6] has been proposed to increase address space to 128-bits, but the supply hasn't been able to meet users' demand.
+Thus, many network operators chose to separate the network and have multiple private IPs, and convert those addresses so that they could access the Internet through one authorized IP.
+This method is commonly referred to as [NAT] (Network Address Translation) and sometimes refers to a device that handles such process (in general, a [router]).
+
+In the server-client model, accessing the Internet through NAT is not a problem.
+If the server has an authorized IP, the client can access it, whether through NAT or not.
+However, if you need to connect to a device inside the NAT/firewall, you've got a problem.
+Because devices outside NAT cannot access the IP of a private network inside the NAT.
+Techniques to address these situations are called [NAT transversal techniques][1].
+
+[IP address]: https://en.wikipedia.org/wiki/IP_address
+[IPv4]: https://en.wikipedia.org/wiki/IPv4
+[2]: https://en.wikipedia.org/wiki/IPv4_address_exhaustion
+[IPv6]: https://en.wikipedia.org/wiki/IPv6
+[NAT]: https://en.wikipedia.org/wiki/Network_address_translation
+[router]: https://en.wikipedia.org/wiki/Router_(computing)
+
+
+So which technique do I use?
+----------------------------
+
+### <abbr title="Universal_Plug_and_Play">UPnP</abbr> (<abbr title="Internet Gateway Device Protocol">IGDP</abbr>)
+
+Techniques to pass through NAT can largely be divided into two categories --- whether they are supported by NAT or not.
+Protocols such as [UPnP] that are proposed to meet the requirements of the modern Internet in which equipment connectivity is valued also addresses NAT passing issues (e.g., [Internet Gateway Device Protocol][IGDP]).
+However, this solution can only be applied to equipment that supports UPnP protocol.
+
+[UPnP]: https://en.wikipedia.org/wiki/Universal_Plug_and_Play
+[IGDP]: https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol
+
+
+### Relay (<abbr title="Traversal Using Relays around NAT">TURN</abbr>)
+
+The other way around is not getting help from NAT. In other words, this way provides external access while maintaining the private-authorized IP system. How is this possible? At this point, let’s talk about what we can do and can't do.
+
+ -  For device with an authorized IP,
+
+     -  It can process connections from other devices.
+     -  It can connect to a device with a different authorized IP.
+
+ -  A device with a private IP,
+
+     -  It is unable to process connection from other devices. 
+         -  *To be very precise, it's possible within the same network. But I'll exclude this case to simplify the story. :)*
+     -  It can connect to a device that has a different authorized IP.
+
+Let's assume that a server (*S*) with a separate, authorized IP exists outside NAT.
+If this server processes the connection instead of the device (let’s call this *A*) behind NAT and forwards (relay) the content to *A*, then we can handle the connection with confidence without relying on NAT's behavior.
+This method is referred to as relay technique and is officially called, [<abbr title="Traversal Using Relays around NAT">TURN</abbr>][TURN].
+
+[TURN]: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT
+
+
+### Hole Punching
+
+Another way to avoid direct help from NAT is by using a technique called [hole punching] (commonly known as [UDP hole punching] but it is also applicable to TCP).
+
+Hole Punching also assumes a transit server (*S*) similar to [TURN].
+However, unlike [TURN], the transit server does not directly relay all communications.
+Instead, it only passes on NAT's authorized IP and device *A*'s port information to to device *B*.
+In this way when attempting to access *A*, *B* attempts to access NAT's authorized IP and port, not *A*'s private IP.
+
+Although hole punching does not require NAT to implement a specific protocol like UPnP, it does require NAT’s port mapping method.
+Specifically, this technique is only applicable to NAT that follows endpoint independent mapping behavior.
+
+[hole punching]: https://en.wikipedia.org/wiki/TCP_hole_punching
+[UDP hole punching]: https://en.wikipedia.org/wiki/UDP_hole_punching
+
+
+Next Story
+----------
+
+The NAT transversal techniques we have discussed today have different applicable situations and they all have different pros and cons.
+Therefore, people in our field use these methods in combination.
+Next time we'll look have a closer look on [TURN], which is the most expensive but the most reliable communication method to move beyond NAT.

content/posts/2019/04/nat_traversal_1.kor.md

@@ -4,10 +4,11 @@ date: 2019-04-04
 authors: [swen.mun]
 ---
 
-
 안녕하세요. 플라네타리움 개발팀 문성원입니다. 오늘은 [NAT 통과 기법]이라고 알려진 방법에 대해서 이야기를 해볼까 합니다.
 
-# 뭐가 문젠가요?
+
+뭐가 문젠가요?
+--------------
 
 게임 서버에서 스마트폰에 이르기까지 현대 인터넷에 참여하는 모든 단말은 [IP 주소]를 가지고 있습니다. 이는 한 단말이 다른 단말에 연결하여 메시지를 주고받기 위함인데요.
 
@@ -17,13 +18,15 @@ authors: [swen.mun]
 
 서버–클라이언트 모델에서 이런 NAT를 통한 인터넷 접속은 크게 문제가 되지 않습니다. 서버가 공인 IP를 가지고 있다면, 클라이언트는 NAT를 거치건 거치지 않건 접속할 수 있기 때문이죠. 하지만 만약 NAT 안쪽에 있는 단말에 접속해야 한다면 문제가 발생합니다. NAT 안쪽의 사설 네트워크의 IP로는 NAT 바깥의 단말들이 접속할 수 없기 때문이죠. 이러한 상황을 해결하기 위한 기법들을 NAT 통과 기법이라고 합니다.
 
-# 그래서 뭘 써야 하나요?
 
-## UPnP (IGDP)
+그래서 뭘 써야 하나요?
+----------------------
+
+### UPnP (IGDP)
 
 NAT를 통과하는 기법은 크게 NAT의 도움을 받느냐 그렇지 않느냐로 구분할 수 있습니다. 장비들의 연결성이 중시되는 현대 인터넷의 요구 사항에 맞춰서 제안된 [UPnP]와 같은 프로토콜은, NAT 통과 문제를 해결하는 기능(예: [Internet Gateway Device Protocol][IGDP])을 지원하기도 합니다. 다만, 이는 어디까지나 해당 프로토콜을 지원하는 장비에만 적용할 수 있는 해결책입니다. 어떠한 장비들은 UPnP를 선택적으로 지원하거나, 아예 지원하지 않을 수도 있습니다.
 
-## Relay (TURN)
+### Relay (TURN)
 
 다른 한 가지 방법은 NAT의 도움을 받지 않는 방법입니다. 다시 이야기하면, 사설 IP ↔ 공인 IP 체계를 유지한 상태에서 외부에서 접속이 가능하게 한다는 것이기도 합니다. 어떻게 할 수 있을까요? 이쯤에서 우리가 할 수 있는 것과 할 수 없는 일을 정리하면 아래와 같습니다.
 
@@ -37,15 +40,18 @@ NAT를 통과하는 기법은 크게 NAT의 도움을 받느냐 그렇지 않느
 
 즉 별도의 공인 IP를 가진 서버(S)를 가정하고, 이 서버가 (본래라면 NAT 뒤의 단말이 처리해야 할) 연결을 대신 처리하면서 내용을 NAT 뒤의 단말에 전달(릴레이)해주면 NAT의 동작에 의존하지 않고 확실하게 연결을 처리할 수 있습니다. 이를 릴레이 기법이라고 하며, [TURN]이라는 표준으로 정의되어 있습니다.
 
-## Hole Punching
+
+### 홀 펀칭
 
 NAT의 직접적인 도움을 받지 않는 다른 방법 중 한 가지는 [홀 펀칭(Hole Punching)][Hole Punching]이라 불리는 기법입니다. (흔히 [UDP 홀펀칭][UDP Hole Punching]으로 널리 알려졌지만, [TCP에 대해서도 적용할 수 있습니다.][TCP Hole Punching])
 
 홀 펀칭 역시 위의 릴레이와 마찬가지로 중계 서버(S)를 가정합니다. 다만 릴레이와 다른 점은, 중계 서버가 직접 통신을 전부 중계하는 것이 아니라, 접속을 처리할 단말(A)이 속한 NAT의 공인 IP와 포트 정보만 접속을 원하는 단말(B)에 넘겨서, B가 A에 접속할 때 A의 사설 IP가 아닌 NAT의 공인 IP와 포트로 접속을 시도하는 방식입니다.
 
 홀 펀칭은 UPnP처럼 NAT에 특정 프로토콜의 구현을 요구하는 것은 아니지만, NAT의 포트 매핑 방식을 이용하는 기법이기 때문에, 동작 모드에 따라, 보다 정확하게 이야기하자면, 목적지 독립적 매핑(Endpoint Independent Mapping)으로 동작하는 NAT에서만 적용 가능합니다.
 
-# 다음 이야기들
+
+다음 이야기들
+-------------
 
 위에서 살펴 본 NAT 통과 기법들은 실현 가능한 상황이나 장단점이 각기 다릅니다. 해서 현업에서는 다양한 방법을 복합적으로 사용합니다.  다음 시간에는 그 중에서 가장 비싸지만 가장 안정적으로 통신을 보장할 수 있는 TURN을 이용한 릴레이 기법에 대해서 더 자세히 살펴보도록 하겠습니다.
 

data/authors/kidon.seo.toml

@@ -0,0 +1,9 @@
+[kor]
+name = "서기돈"
+
+[eng]
+name = "Kidon Seo"
+
+[social]
+github = "area363"
+email = "kidon@planetariumhq.com"