난 할 수 있어

'2020년까지 달에 우주기지를 건설하겠다' 

지난해 10월 미국 부시 대통령이 이런 내용을 담은 우주개발 계획을 발표해 관심을 끌었다. 물, 공기가 없는 황량한 달 표면에 왜 우주기지를 건설하겠다는 것일까? 여러 가지 목적이 있겠지만, 미래 에너지 자원 확보를 선점하기 위한 것으로 보는 시각이 많다. 미국이 달 표면에 널려있는 헬륨3을 가져와, 고갈될 지구의 화석연료를 대체해서 쓸 계획을 세우고 있다는 것이다. 

에너지 전문가들은 지금 추세라면 지구상의 대표적인 화석연료인 석유는 40년, 천연가스도 60년 정도면 고갈될 것으로 보고 있다. 원자력 발전의 연료가 되는 우라늄 역시 재처리해서 쓰지 않는다면 약 65년이면 바닥날 전망이다. 전기 등 에너지가 사라진 지구를 상상할 수 있을까? 과학자들은 태양전지, 풍력, 조력 등으로부터 에너지를 뽑아내기 위해 연구를 하고 있지만, 이러한 자원들이 현재의 화석연료를 대체하기에는 턱없이 부족하다는 게 중론이다. 

그래서 연구되고 있는 것이 핵융합 발전이다. 
태양이 에너지를 만드는 것과 유사하다고 해서 ‘인공태양’이라고도 불리는 핵융합발전은 이중수소와 삼중수소를 결합시켜 헬륨을 만들 때, 손실되는 질량을 에너지로 이용한다. 원자는 핵과 전자로 구성되어 있는데, 에너지는 양자와 중성자로 이루어진 핵에 집중되어 있다. 원자력 발전이 중성자로 핵을 쪼갤 때 발생하는 에너지를 활용한 것이라면, 핵융합은 핵끼리 융합할 때 손실되는 질량(통상 양자나 중성자가 질량을 갖고 있다)이 에너지로 바뀌는 것을 이용한다. 

예를 들어 질량이 2인 중수소(양자1+중성자1)와 질량이 3인 삼중수소(양자1+중성자2)를 결합시키면 어떤 일이 벌어질까? 우선 핵융합 반응에 의해 헬륨(양자2+중성자2)이 생성된다. 이 때 중성자 하나가 남게 되는데, 이 중성자가 연쇄반응을 일으키면서 에너지(E)=질량(m)x빛의 속도(c)2 만큼의 에너지를 만들어낸다. 

헬륨3이 관심을 끄는 것은 3중수소 대신 활용될 수 있기 때문이다. 헬륨3은 보통 헬륨(양자2개+중성자2개)보다 중성자 수가 하나 적다. 즉 양자 2개와 중성자 1개로 구성되어 있는 것이다. 이런 헬륨3에 중수소(양자1개+중성자1개)를 핵융합시키면 헬륨으로 바뀌면서, 양자 1개가 남는데 이것이 에너지로 바뀌게 되는 것이다. 

이러한 핵융합은 무엇보다 적은 양의 연료로 많은 에너지를 생산할 수 있다는 장점이 있다. 즉 화석연료와 핵분열원자력, 핵융합 연료를 비교하여 보면 20톤의 석탄이 탈 때 발생하는 에너지를 1.5kg 의 핵분열 연료로 생성할 수 있는데, 핵융합인 경우는 60g의 핵융합 연료로 가능하게 된다. 게다가 방사선이 없어지는 데 수 만년이 걸리는 원자력발전과는 달리, 반감기도 12년 가량에 불과해 방사성동위원소가 포함된 폐기물을 거의 만들어내지 않는다는 장점까지 갖추고 있다. 

문제는 헬륨3을 지구에서는 거의 얻을 수 없다는 것이다. 반면 달 표면에는 태양풍에 의해 1백만 톤 가량의 헬륨3이 침전되어 있는 것으로 추정된다. 미국 행성지질학연구소의 로런스 테일러 소장은 "헬륨3이 중수소와 결합할 때의 융합 반응은 매우 높은 기온에서 진행되며 놀라운 양의 에너지를 생산할 수 있다"며 "우주왕복선 한 대로 운송할 수 있는 헬륨 25ｔ이면 미국이 1년 동안 쓸 전기를 공급하기에 충분하다" 고 말한다. 과학자들은 헬륨3이 매장된 지역에 800도 이상의 열을 가해 헬륨을 분리해 내고, 이를 지구로 가져온다면 전 세계인들이 5백년 가량 쓸 수 있는 에너지를 확보할 수 있을 것으로 보고 있다. 

물론 넘어야 할 산이 많다. 
무엇보다 핵융합 반응을 안정적으로 유지하여 ‘인공태양’을 만들기 위해서는 우선 섭씨 1억도 이상의 온도를 유지할 수 있는 기술이 필요하다. 금속 가운데 녹는점이 가장 높다는 텅스텐도 섭씨 3410도가 넘으면 녹아 버린다. 다행히 초전도 자석 안에서 고온의 플라즈마 상태를 만들고, 1억 도의 온도를 만들어 내는 데는 성공했다. 그러나 핵융합을 에너지원으로 이용하기 위해서는 고온의 플라즈마를 오랫동안 유지하면서 그 안정성을 검증하는 일이 남아 있다. 그런데 수 분 동안 초고온 플라즈마를 유지하는 핵융합 실험로를 짓는 데만 100억 달러 이상의 예산이 투입된다. 이 때문에 미국ㆍ유럽연합(EU)ㆍ러시아ㆍ일본 등이 국제 컨소시엄을 구성해 ‘국제핵융합실험로(ITER)’를 짓기로 했는데 사업이 순조롭게 진행된다고 해도 2015년 경에야 완성될 전망이다. 전문가들은 실용화단계까지 가자면 2050년은 되어야 할 것으로 보고 있다. 

그러나 벌써 경쟁은 시작됐다. 
중국이 최근 다섯번째 달 탐사선을 보낼 계획을 발표하고, 핵융합 연구에 적극적인 일본 역시 달에 탐사선을 보내 헬륨3를 가져오기 위한 계획을 추진하고 있다. 러시아 국영 우주개발 회사인 에너지아(Energia)가 달에서 헬륨3 성분을 캐내 지구의 핵융합 발전소 연료로 쓰겠다는 계획을 발표한 것도 바로 이러한 맥락이다. 미국에서는 광물이 있는 장소를 조사하고 헬륨3이 묻힌 장소를 표시하는 자원지도를 만들자는 논의도 나오고 있다. 자원의 서부 개척시대가 선언된 것이다. (글 : 유상연 – 과학칼럼니스트) 

출처 : NDSL과학향기

[RFC 2133] Basic Socket Interface Extensions for IPv6)

좋은 참고가 되었다.

추천받은 사이트 (Powerd by DNS)

http://ftp.kr.vim.org/doc/PoweredByDNS/

DNS 서비스의 PTR 레코드를 수정하는 기능입니다.
사용자가 등록한 IP주소에 호스트이름을 지정할 수 있습니다.
예를 들어 10.168.192.in-addr.arpa를 등록한 사용자는


 의 역으로


식으로 등록, IP주소를 가지고 도메인을 매핑할 수 있습니다. 

출처 : http://kr.dnsever.com/help/wiki/wiki.php/EditPTRHelp

도메인네임이 IPv4 주소(A RR)와 IPv6 주소(AAAA RR)를 모두 갖고 있는 경우 

IPv4 인터넷에서는 도메인 네임이 갖는 IP 주소는 IPv4 주소 한 종류 뿐이었습니다.

그러나 이제 IPv6 인터넷이 도입되면서, 하나의 도메인네임이 IPv4 주소와 IPv6 주소 모두를 갖는 경우가 발생하게 됩니다.

예를 들어 아래와 같은 경우,

"examp.co.kr" 도메인 설정 내용

ftp.examp.co.kr.  1800  IN  A    192.0.2.200

ftp.examp.co.kr.  1800  IN  AAAA 2001:dc5:f::200

단말 호스트의 IPv6 어플리케이션은 getaddrinfo() 함수 호출의 결과로 ftp.examp.co.kr.  도메인네임에 대해 "192.0.2.200" IPv4 주소와 "2001:dc5:f::200"의 2개 주소를 얻게 됩니다.

이 경우, 어플리케이션은 "이 2개의 주소 중 어느 주소를 선택하여 접속을 시도해야 하는가?" 하는 문제가 발생하게 됩니다.

물론 이것은 원칙적으로 어플리케이션을 작성하는 개발자의 선택에 따라 결정될 것입니다.

어플리케이션이 getaddrinfo() 함수로부터 얻은 IP 주소 중 하나를 다시 Socket API에 인자로 전달함으로써 통신이 개시될 수 있기 때문입니다. 

이 동작은 프로그래머가 정하여 프로그램 코드를 작성할 수 있습니다.

디폴트 IP 주소 선택 알고리듬 (Default Address Selection)

IETF RFC3484 문서는 이 문제를 다루고 있습니다.

Ref Docs : RFC3484 "Default Address Selection for Internet Protocol version 6 (IPv6)"

일반적으로 어플리케이션은 도메인네임의 IP 주소 변환 함수 gethostbyname() 이나 getaddrinfo()가 리턴하는 IP 주소 목록에서 첫 번째 IP 주소를 선택하여 이 IP 주소로 Socket을 열고 통신을 개시합니다.

이러한 일반 사항을 기반으로 RFC3484는 getaddrinfo() 함수가 도메인네임의 IPv4 주소와 IPv6 주소를 함께 파악한 경우, 일정한 디폴트 알고리듬을 적용하여 어플리케이션으로 리턴하는 IP 주소 목록을 정렬(sort)하여 반환하는 동작을 정의합니다.

getaddrinfo() 함수는 일정한 규칙으로 IP 주소 목록을 반환하여 어플리케이션이 접속 시도하는 IP 주소를 일정하게 제어하는 역할을 하게 됩니다.

접속대상 주소 선택 알고리듬에 사용되는 디폴트 정책 테이블(default poliy table)은 아래와 같습니다.

    Prefix        Precedence     Label      비고

----------       -------------------  ----------  --------------------

::1/128                            50             0     IPv6 LoopBack 주소

::/0                                   40              1    이외의 모든 IPv6 주소

2002::/16                        30             2     6to4 IPv6 주소

::/96                                20             3     IPv4-compatible IPv6 주소

::ffff:0:0/96                      10             4     IPv4-mapped IPv6 주소, IPv4 주소를 의미

Source : RFC3484 "Default Address Selection for Internet Protocol version 6 (IPv6)"

                2.1. Policy Table

이 주소 선택 알고리듬의 개략적인 내용은 아래와 같이 정리할 수 있습니다.

1. IPv4 주소와 IPv6 주소가 함께 리스트에 있는 경우, IPv6 주소가 디폴트로 리스트 중 첫 번째 IP 주소로 리턴됩니다.

IPv4 주소(::ffff:0:0/96) 보다 IPv6 주소(::1/128, ::/0, 2002::/16, ::/96)들이  Precedence에서 모두 우선순위가 높습니다.

이에 따라 IPv6 어플리케이션이 getaddrinfo() 함수로부터 반환받는 IP 주소 리스트에 IPv4와 IPv6가 혼재하는 경우, 디폴트 동작으로 그 첫 번째 IP 주소는 IPv6 주소가 됩니다.

결과적으로 IPv6 어플리케이션은 IPv4와 IPv6 주소 모두 가진 도메인네임에 대해서는 IPv6를 먼저 접속 시도 주소로 선택하는 동작을 하게 됩니다.

2. IPv6 주소가 다수 존재하는 경우, IPv6 루프백(loopback) 주소, 일반적인 IPv6 주소, 6to4 IPv6 주소, IPv4-compatible IPv6 주소의 순으로 정렬(sort)하여 리턴합니다.

IPv6 주소 "2001:dc5:f::200"와 IPv6 주소 "2002:c000:02c8::c000:02c8"가 도메인네임에 함께 지정되어 있는 경우, APNIC을 통해 할당된 native IPv6 주소 "2001:dc5:f::200"가 6to4 tunnelling 방식의 자동생성된 6to4 IPv6 주소 "2002:c000:02c8::c000:02c8"보다 우선하게 됩니다.

곧 어플리케이션은 native IPv6 주소와 6to4 IPv6 주소가 있는 경우, native IPv6 주소로 먼저 접속시도하게 됩니다.

NOTE!: DNS의 IPv6 주소 설정오류가 야기하는 어플리케이션의 접속 시간 지연 문제

일반적으로 어플리케이션은 getaddrinfo() 등의 함수로부터 리턴받은 IP 주소 목록 중 첫 번째 IP 주소로 접속을 시도한 후 접속에 실패하면 다음의 IP 주소를 사용하여 접속을 시도합니다.

따라서 IPv4와 IPv6 주소가 하나씩 있는 경우, IPv6 주소로 먼저 접속을 시도하고, 이에 실패하게 되면, IPv4 주소로 접속을 시도합니다.

만일 DNS의 특정 도메인네임에 존재하지 않는 IPv6 주소가 설정되어 있는 경우, 어플리케이션에서는 접속시도와 그 timeout에 따르는 시간지연이 발생한 후 IPv4 주소로 접속이 성공함으로써, 사용자는 접속이 느린 현상을 경험하게 됩니다.

위에서 정리된 디폴트 주소 선택 알고리듬 내용은 개략적인 것으로 이외에 시스템 환경조건에 의한 주소 선택 및 정렬 알고리듬을 RFC3484 문서에서 정의하고 있습니다.

주의할 점은 RFC3484에서 정의한 주소선택 알고리듬은 디폴트 알고리듬일 뿐이며 어플리케이션에서 별도의 선택 알고리듬을 사용하여 특정한 주소 선택을 하거나, 디폴트 주소 선택 정책 테이블의 내용을 변경하는 경우, 선택 방식이 변경될 수 있다는 

사실입니다.

Windows 2003 서버의 경우, 아래와 같이 default policy table 내용을 볼 수 있으며, 이 테이블에서 각 필드 값을 변경하여 getaddrinfo() 함수의 정렬 순서를 변경할 수 있습니다.

C:>netsh interface ipv6 show prefixpolicy

Querying active state...

Precedence  Label  Prefix

----------------  ---------  --------------------------------

                  10         4  ::ffff:0:0/96

                  20         3  ::/96

                  30         2  2002::/16

                  40         1  ::/0

                  50         0  ::1/128