KR20050086925A - 이종 ｉｐ 네트워크에서 클라이언트와 서버 사이의 통신을구축하는 시스템 및 방법 - Google Patents

이종 ｉｐ 네트워크에서 클라이언트와 서버 사이의 통신을구축하는 시스템 및 방법 Download PDF

Info

Publication number
KR20050086925A
KR20050086925A KR1020057011537A KR20057011537A KR20050086925A KR 20050086925 A KR20050086925 A KR 20050086925A KR 1020057011537 A KR1020057011537 A KR 1020057011537A KR 20057011537 A KR20057011537 A KR 20057011537A KR 20050086925 A KR20050086925 A KR 20050086925A
Authority
KR
South Korea
Prior art keywords
server
client
address
network
node
Prior art date
Application number
KR1020057011537A
Other languages
English (en)
Inventor
프란시스쿠스 아.체. 메이스
마리아나 브이. 니콜로바
마르크 바우클레어
Original Assignee
코닌클리케 필립스 일렉트로닉스 엔.브이.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 코닌클리케 필립스 일렉트로닉스 엔.브이. filed Critical 코닌클리케 필립스 일렉트로닉스 엔.브이.
Publication of KR20050086925A publication Critical patent/KR20050086925A/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Abstract

본 방법 및 시스템은, 클라이언트(예를 들어, 14, 34, 36)로 하여금 이종 IPv6/IPv4 네트워크(예를 들어, 300)에서 DNS 서버를 통해 분석되지 않는 호스트명을 갖는 서버(예를 들어, 19, 20, 22, 26, 30)와 통신하도록 한다. 바람직하게는 네트워크(300)에서의 포털(18)에 저장된 2개의 테이블(40, 50)을 클라이언트에게 제공함으로써 분석이 달성되며, 이에 의해 클라이언트는 서버(19, 20, 22, 26, 30)와 통신할 수 있게 하기 위해 테이블 정보를 이용하여 포털(18)과 프로토콜 교환을 수행한다.

Description

이종 ＩＰ 네트워크에서 클라이언트와 서버 사이의 통신을 구축하는 시스템 및 방법{SYSTEM AND METHOD FOR ESTABLISHING COMMUNICATION BETWEEN A CLIENT AND A SERVER IN A HETEROGENOUS IP NETWORK}
본 발명은 일반적으로 이종(heterogeneous) IP 네트워크에서 클라이언트와 서버 사이의 전자 컨텐츠 전달에 관한 것이다. 특히, 본 발명은, 이종 네트워크에서 클라이언트가 DNS 서버를 통해 분석될 수 없는 호스트명을 갖는 서버와 통신하도록 하는 방법에 관한 것이다.
인터넷 프로토콜("IP")은, 네트워크 내에서 또는 네트워크 사이에서 트래픽의 라우팅을 용이하게 하도록 설계된 어드레싱 프로토콜이다. 최근에, 인터넷 프로토콜은 인터넷 및 인트라넷을 포함하는 많은 컴퓨터 네트워크 상에 사용되고 있다. 인터넷 프로토콜의 현재 버전, 즉 버전 4("IPv4")는 제한된 어드레스 공간을 지원한다. 32-비트 어드레스-필드를 통해, 4 294 967 296인 최대 232개의 상이한 IPv4 어드레스, 또는 전 세계적으로 40억 개 이상의 고유 어드레스를 할당할 수 있다. 인터넷 프로토콜 버전 6("IPv6")은 IP 어드레스를 위한 128-비트 어드레스-필드의 이용을 제안한다. IPv6은, 또한 어드레스 자동-구성, 이웃 발견, 및 라우터 발견과 같은 기존의 IPv4 프로토콜에 대비한 몇몇 추가적인 구조적 개선점을 포함한다. IPv6에 의해 제공된 장점에도 불구하고, 다수의 네트워크(다수의 인터넷 서브넷을 포함)는 여전히 앞으로도 오랫동안 IPv4를 이용할 것이다. 이것은, 대량의 재정적 및 지식적 투자가 기존의 인터넷 인프라구조(infrastructure)에서 이미 이루어졌기 때문이다. 그러므로, IPv6으로의 전이는 연장된 시간 기간을 필요로 하며, 그 동안 IPv6은 처음에 공존하고, 그 다음에 기존의 IPv4 프로토콜을 점차 대체하기 시작한다.
이러한 이유로 인해, IPv6/IPv4 개체가 나타나는 잠정적 이중 IPv6/IPv4 인프라구조가 예측된다. 후자는 네트워크 프로토콜 스택에서 IPv6 및 IPv4 모두를 지원하고, 양쪽 프로토콜을 통해 통신할 수 있다. IPv4 및 IPv6 공존을 지원하려는 현재의 노력은, 전이로서 기존의 IPv4 백본을 이용하는 "IPv6 아일랜드(island)"(또는 서브넷) 사이의 도메인간의 라우팅에 초점을 맞춘다. 그러나, 이러한 아일랜드 자체는, 인트라-도메인 IPv4-IPv6 전이 메커니즘 및 전략을 필요로 하는 복잡한 이종 IPv4 및 IPv6 내부 구조(예를 들어, 큰 학문적 또는 상업적 캠퍼스 "인트라넷")를 가질 수 있다.
즉, 번역기(translator) 및 터널링(tunneling)은 잘 알려진 전이 메커니즘이다. 번역기는 이러한 애플리케이션에서 추가로 고려되지 않는다. 터널링은 종래 기술에 잘 알려져 있고, 포인트간(point-to-point) 터널을 생성함으로써 동작하며, 이에 의해 IPv6 패킷은 IPv4 라우팅 인프라구조를 통해 이들을 전달하기 위해 IPv4 헤더 내에 캡슐화된다. 2가지 유형의 터널링 기술, 즉 구성된 터널링 기술 및 자동 터널링 기술은 RFC 2893에 개시되어 있다. 구성된 터널링은, 캡슐화 노드 상에서 터널 종점 어드레스의 수동 구성을 특징으로 한다. 구성된 터널링은 구성 및 동작 관리 리소스에 관해 비용이 많이 들고, 네트워크 토폴로지(topology) 변화에 적응되지 않는다. 자동 터널링은 캡슐화 노드 상의 터널 종점 어드레스의 자동 구성을 특징으로 하는, 즉 어떠한 수동 구성도 필요하지 않고, 더욱이 네트워크 토폴로지 변화에 적응된다. 이는 자동 터널링이 바람직한 이유이다. 자동 터널링은 내장된 IPv4 어드레스를 갖는 특수한 IPv6 어드레스의 이용으로 인해 가능하다. 후자는 터널의 종점을 한정하기 위해 캡슐화 노드에 의해 사용된다. 자동 터널링을 용이하게 하는 IPv6 어드레스의 유형은 아래에 설명된다:
- IPv4-호환 IPv6 어드레스(RFC 1886 참조);
- IPv4-매핑 IPv6 어드레스(RFC 1886 참조);
- 6오버4(6over4) 어드레스(RFC 2529 참조);
- 6-4(6to4) 어드레스(RFC 3056 참조);
- ISATAP 어드레스(RFC 드래프트-ietf-ngtrans-isatap-06.txt 참조)/
RFC 3056에 정의된 6-4 어드레스는, 인터-사이트 자동 터널링(상이한 서브넷 사이)이 수행되는 경우에 사용된다. 6-4 어드레스의 저차수(low-order)의 80 비트는 사이트-레벨 집합체 식별자(SLA ID) 및 인터페이스 ID와 같은 IPv6 노드에 국부적으로 이용가능한 정보를 포함한다. 인터페이스 ID는 일반적으로 제조될 때 내장되는 IPv6 노드의 MAC 어드레스와 동일하다. 고차수의 48-비트는 6-4 접두부(prefix)로서 알려져 있다. IANA는 수치값(0×0002), 즉 2002::/16을 6-4 접두부의 고차수 16-비트에 영구적으로 할당하였다. 6-4 접두부의 저차수 32-비트는 가입자 사이트의 범용의 고유 IPv4 어드레스의 콜론-16진수 표시에 대해 예약된다. 6-4 접두부의 일례는 공용 IPv4 어드레스(130.145.174.124)에 대응하는 2002:8291:ae7c:/48이다.
클라이언트가 컨텐츠(예를 들어, 웹 페이지)를 얻거나 통신(오디오/비디오 회의, 채팅, 게임)에 수반되기 위해 서버(IPv4 또는 IPv6 네트워크 중 어느 하나에서)와 접촉하기를 원할 때, 클라이언트는 서버의 이진 IP 어드레스를 먼저 알아야 한다. 클라이언트 및 서버는 동일하거나 상이한 네트워크에 위치될 수 있다. 일반적으로, 클라이언트는 이진 IP 어드레스가 아닌 servername.philips.com과 같은 서버의 호스트명(ASCII 스트링)에 의해, 또는 "friend@philips.com"과 같은 이-메일 어드레스에 의해 서버(호스트, 메일박스 또는 다른 리소스)를 조회한다. 그럼에도 불구하고, 기본적인 IP 네트워크 자체는 IP 어드레스만을 이해하므로, 도메인 이름 시스템(DNS)으로서 알려져 있는 메커니즘은 ASCII 스트링을 이진 IP 어드레스로 변환하는데 사용된다. 초기에 DNS는 IPv4 어드레스만을 지원하지만, 나중에 IPv6 어드레스 집합체 및 리넘버링(renumbering)을 지원하도록 확장된다(RFC 2874를 참조). 그러나, IPv4로부터 IPv6로의 전이 기간에, DNS 인프라구조는 IPv6를 완전히 지원하지 않는데, 즉 IPv6 레코드(즉, AAAA 또는 A6 레코드)를 유지하지 않는 단절된 DNS 서버가 있다. 그러므로, 1차 및 2차 DNS 서버가 A6 레코드를 지원하지 않는 IPv6 노드는 호스트명에 의해 다른 IPv6 노드에 의해 도달(어드레스 지정)가능하지 않는데, 이는 호스트명이 IPv6 어드레스에서 분석될 수 없기 때문이다.
도 1은 클라이언트로 하여금 이종 IPv4 네트워크에서 요청된 서버에 액세스하도록 하기 위해 수반된 단계를 도시한 흐름도.
도 2는 종래 기술에 따른 이중 IPv4 네트워크를 도시한 도면.
도 3은 본 발명의 방법이 실행될 수 있는 이종 IPv6/IPv4 네트워크를 도시한 도면.
도 4는 도 2의 네트워크에서의 포털에 제공된 Hostname2IPaddress 테이블 및 서버의 호스트명 테이블의 예시적인 구조를 도시한 도면.
도 5는, 서버의 IP 어드레스가 DNS 서비스에 의해 취득될 수 있거나 취득될 수 없는, 이종 IPv6/IPv4 네트워크에서 요청된 서버에 클라이언트가 액세스하도록 하기 위해 수반된 단계를 도시한 흐름도.
따라서, 본 발명은, 어드레싱되지 않은 IPv6 노드를 서비스하는 1차 및 2차 DNS 서버가 A6 레코드를 지원하지 않는 경우에 다른 IPv6 노드에 의해 IPv6 노드에 어드레싱할 수 없는 현재 제한을 극복하는 새로운 메커니즘을 제안한다.
본 발명은, 클라이언트로 하여금 이종 IPv6/IPv4 네트워크에서 DNS 서버를 통해 분석되지 않는 호스트명을 갖는 서버와 통신하도록 하는 방법에 관한 것이다.
본 발명의 양상에 따라, 클라이언트로부터 IPv6 서브넷에서 서버에 어드레싱하는 방법은, 상기 클라이언트와 연관된 사용자에 의해, 원하는 컨텐츠를 상기 클라이언트에게 제공할 수 있는 서버 노드 호스트명의 목록을 상기 네트워크에서의 포털(portal)에게 요청하는 단계와; 상기 클라이언트 요청에 응답하여 상기 포털로부터 상기 클라이언트로 제 1 테이블 및 제 2 테이블을 제공하는 단계로서, 상기 제 1 테이블은 서버 노드 호스트명의 상기 목록을 포함하는, 제공 단계와; 상기 클라이언트가 통신을 구축할 수 없는 그러한 서버 노드 호스트명을 차단하기 위해 상기 클라이언트에서 상기 제공된 서버 호스트명의 목록을 필터링하는 단계와; 서버 노드 호스트명의 상기 필터링된 목록으로부터 서버 호스트명을 상기 사용자에 의해 선택하는 단계와; 상기 사용자 선택된 서버의 호스트명과 연관된 IP 어드레스가 도메인 이름 서버(DNS)를 통해 분석가능한지를 상기 제 1 테이블로부터 결정하는 단계와; 상기 단계(e)(WHICH IS THIS STEP? COPY & PASTE 문제?)가 충족되면, 상기 DNS로부터 상기 연관된 IP 어드레스를 얻는 단계와; 상기 단계(e)가 충족되지 않으면, 상기 선택된 서버의 호스트명을 갖는 서버의 하나 이상의 디폴트 IP 어드레스를 결정하기 위해 상기 포털을 갖는 상기 클라이언트에 의해 프로토콜을 실행하는 단계를 포함한다.
본 발명의 양상에 따라, 클라이언트로부터 IPv6 서브넷에서 서버에 어드레싱하는 시스템은, 상기 클라이언트와 연관된 사용자에 의해, 원하는 컨텐츠를 상기 클라이언트에게 제공할 수 있는 서버 호스트명의 목록을 상기 네트워크에서의 포털에게 요청하는 수단과; 상기 클라이언트 요청에 응답하여 상기 포털로부터 상기 클라이언트로 제 1 테이블 및 제 2 테이블을 제공하는 수단으로서, 상기 제 1 테이블은 서버 노드 호스트명의 상기 목록을 포함하는, 제공 수단과; 상기 클라이언트가 통신을 구축할 수 없는 그러한 서버 노드 호스트명을 차단하기 위해 상기 클라이언트에서 상기 제공된 서버 호스트명의 목록을 필터링하는 수단과; 서버 호스트명의 상기 필터링된 목록으로부터 서버 호스트명을 상기 사용자에 의해 선택하는 수단과; 상기 사용자 선택된 서버의 호스트명과 연관된 IP 어드레스가 도메인 이름 서버(DNS)를 통해 분석가능한지를 상기 제 1 테이블로부터 결정하는 수단과; 상기 결정 수단이 충족되면, 상기 DNS로부터 상기 연관된 IP 어드레스를 얻는 수단과; 상기 결정 수단이 충족되지 않으면, 상기 선택된 서버의 호스트명을 갖는 서버의 하나 이상의 디폴트 IP 어드레스를 결정하기 위해 상기 포털을 갖는 상기 클라이언트에 의해 프로토콜을 실행하는 수단을 포함한다.
본 명세서에 설명된 방법 및 시스템은 인터넷 프로토콜 버전4("IPv4") 네트워크로부터 인터넷 프로토콜 버전6("IPv6") 네트워크로의 전이에 도움을 줄 수 있다. 그러나, 본 발명은 그러한 일실시예에 한정되지 않고, X-비트 및 Y-비트 네트워크 어드레스와 이중 네트워크 이용 사이의 전이를 필요로 하는 사실상 임의의 네트워크 세트로 사용될 수 있다.
이들 및 다른 장점은 첨부 도면과 연계하여 다음의 상세한 설명을 읽음으로써 당업자에게 명백할 것이다.
본 발명의 다음의 상세한 설명에서, 다수의 특정 세부사항은 본 발명을 완전히 이해하기 위해 설명된다. 그러나, 본 발명이 이들 특정 세부사항 없이 실행될 수 있음이 당업자에게 명백할 것이다. 몇몇 경우에, 잘 알려진 구조 및 디바이스는 본 발명의 모호함을 피하기 위해 구체적이 아니라 블록도의 형태로 도시된다.
A. 용어
다음 논의는 아래에 주어진 이러한 응용 전체에 사용된 관련 용어를 간략히 검토함으로써 더 명백해질 것이다.
"노드"는 네트워크 프로토콜 스택에서 IPv4 또는 IPv6 중 어느 하나 또는 양쪽 모두를 구현하는 디바이스로서 정의된다.
"라우터"는 자신에 명확히 어드레싱되지 않는 IP 패킷을 송출하는 노드로서 정의된다.
"게이트웨이"는 NA(P)T, DHCP 서버 등과 같은 라우터에 비해 추가 기능을 포함하는 노드로서 정의된다.
"호스트"는 라우터 또는 게이트웨이가 아닌 임의의 노드로서 정의된다.
"인터페이스"는 링크에 대한 노드의 부속물로서 정의된다.
"패킷"은 IP 헤더+임의의 페이로드로서 정의된다.
"IPv4-전용 노드"라는 용어는 일반적으로 IPv4만을 구현하고 IPv6를 이해하지 않는 호스트 또는 라우터를 언급한다.
"IPv6-전용 노드"라는 용어는 일반적으로 IPv6만을 구현하고 IPv4를 이해하지 않는 호스트 또는 라우터를 언급한다.
"IPv4/IPv6 노드"라는 용어는 일반적으로 IPv4 및 IPv6 모두를 구현하는 호스트 또는 라우터를 언급한다.
"IPv4 노드"라는 용어는 일반적으로 IPv4를 구현하는 호스트 또는 라우터를 언급한다. IPv6/IPv4 및 IPv4-전용 노드 모두는 IPv4 노드이다.
"IPv6 노드"라는 용어는 일반적으로 IPv6를 구현하는 호스트 또는 라우터를 언급한다. IPv6/IPv4 및 IPv6-전용 노드 모두는 IPv6 노드이다.
"IPv4 패킷"이라는 용어는 일반적으로 IPv4 헤더+페이로드를 언급한다.
"IPv6 패킷"이라는 용어는 일반적으로 IPv6 헤더+페이로드를 언급한다.
"IPv4 네트워크"는 일반적으로 IPv4 노드만으로 구성된 네트워크를 언급한다.
"IPv6 네트워크"는 일반적으로 IPv6 노드만으로 구성된 네트워크를 언급한다.
"IPv4/IPv6 네트워크"는 일반적으로 IPv4 및 IPv6 노드 모두로 구성된 네트워크를 언급한다.
B. 종래의 IPv4 네트워크
본 발명의 특정한 양상을 더 잘 이해하기 위해, 클라이언트가 종래의 IPv4 네트워크에서의 서버에 어떻게 액세스하는지를 먼저 고려하는 것이 유리하다.
도 1은, 일반적으로 제 1 IPv4 네트워크에 위치한 IPv4-전용 클라이언트가 DNS 서비스를 통해 제 2의(상이한) IPv4 네트워크에 위치한 IPv4 서버에 어떻게 액세스하는지를 설명하는 흐름도이다. DNS 서비스를 통해 서버에 액세스하기 위한 이러한 프로세스는 종래 기술에 잘 알려져 있고, 도 2의 예시적인 IPv4 네트워크와 같은 이종 네트워크에서 호스트명을 IP 어드레스로 항상 분석하도록 보장된다. 그러나, DNS 서비스의 신뢰도는 아래에 설명되는 바와 같이, 도 3의 IPv6/IPv4 네트워크와 같은 이종 네트워크에서 모든 경우에 보장되지 않는다. 본 발명은, 아래에 설명되는 바와 같이 DNS 서비스가 이종 네트워크에 의지할 수 없는 경우에 클라이언트가 서버에 액세스하도록 하는 방법에 관한 것이다.
이제 도 1의 흐름도를 참조하면, 단계(106)에서, 예를 들어 오디오, 비디오 등과 같은 특정 컨텐츠 유형을 제공할 수 있는 서버에 대해 네트워크에서의 포털에 요청할 때 클라이언트에는 포털로부터 응용가능한 서버 호스트명의 목록이 되돌아온다. 단계(108)에서, 클라이언트의 사용자는 제공된 목록으로부터 하나의 서버 호스트명을 선택한다. 단계(110)에서, 클라이언트는 DNS 요청을 네트워크에서의 디폴트 DNS 서버로 송신한다. 단계(112)에서, 클라이언트에는 서버의 IPv4 어드레스(들)가 되돌아온다. 단계(114)에서, 클라이언트는 IPv4를 이용하여 서버와 통신한다.
도 1의 흐름도에 설명된 바와 같이 이종 네트워크에서 클라이언트로부터 서버에 액세스하는 원리는 이제 예로서 보강된다. 더 구체적으로, 도 2는 공용 광역 네트워크("WAN")(24) 및 오피스/홈 근거리 네트워크("LAN")(12)로 구성된 이종 네트워크 통신 시스템(200)이다. 양쪽 네트워크(12 및 24)는, 각 클라이언트(14), 게이트웨이(16), 벤더 포털(18), 서버(19) 및 서버(20) 모두가 공통 프로토콜, 즉 IPv4 프로토콜을 지원한다는 점에서 IPv4에 기반을 두고 있다(RFC 791 참조). 예시적인 네트워크에서, 클라이언트(14)는 서버(19 및 20)와 같은 복수의 인터넷 뮤직 스테이션(컨텐츠 제공자)으로부터 오디오 컨텐츠를 수신할 수 있는 인터넷 라디오 클라이언트인 것으로 간주된다. 클라이언트(14)에서 오디오 컨텐츠를 얻기 위해, 클라이언트(14)는 원하는 컨텐츠를 제공할 수 있는 서버 호스트명{예를 들어, 서버(19 및 20)}의 목록을 취해야 한다. 서버 호스트명의 목록을 얻기 위해, 클라이언트(14)는 먼저 네트워크에서의 디폴트 포털, 즉 벤더 포털(18)에 연결한다. 이 목록에 포함된 서버가 미리 포털(18)에서 자신을 등록한다고 간주된다. 목록을 수신하자마자, 클라이언트(14)와 연관된 사용자는 그 때 제공된 목록으로부터 서버의 호스트명 중 하나를 선택할 수 있다. 그 다음에, 선택된 서버의 호스트명을 이진 IP 어드레스에 매핑하기 위해, 클라이언트(14)는 종래에서와 같이 네트워크(10)에서의 디폴트 DNS 서버(미도시)를 이용한다. DNS 서버는 홈 네트워크(12) 또는 공용 네트워크(24){벤더 포털(18) 상에 포함}에 위치할 수 있다. DNS 서버로부터 되돌아온 IPv4 어드레스를 이용하여, 클라이언트(14)는 그 때 오디오 컨텐츠를 수신하기 위해 선택된 서버, 예를 들어 서버(20)와의 통신에 채택할 수 있다.
상기 예는 도 2의 이종 IPv4 기반의 네트워크(10)가 IPv4로부터 IPv 6으로 이주할 때 더 복잡해진다.
C. IPv4로부터 IPv6으로의 이주
도 3의 통신 네트워크 시스템(300)은 본 발명의 원리를 예시하기 위해 예시적인 이종 IPv6/IPv4 네트워크를 나타낸다. 네트워크(300)는 예로서, 도 2의 IPv4 기반의 네트워크(10)가 이종 IPv6/IPv4 네트워크로 이주할 수 있는 한가지 방법을 나타낸다. 도 2의 홈 IPv4 네트워크(12)는 새로운 클라이언트, 즉 IPv6/IPv4 클라이언트(34) 및 IPv6-전용 클라이언트(36)를 포함하도록 확장된다. 도 2의 공용 IPv4 네트워크(24)는 IPv6/IPv4 컨텐츠 제공자(22)(일반적으로 6-4 라우터, RFC 3056 참조), IPv6-전용 컨텐츠 제공자(26)(일반적으로 6-4 호스트, RFC 3056 참조), IPv6-전용 컨텐츠 제공자(30)(고유 IPv6 어드레스를 갖는), 및 IPv6/IPv4 중계 라우터(28)를 포함하도록 확장된다. IPv6/IPv4 중계 라우터(28)는 IPv6-전용 서버의 고유 IPv6 어드레스와 6-4 어드레스 사이의 라우팅을 지원하도록 구성된다.
설명을 용이하게 하기 위해, 도 3의 이종 IPv6/IPv4 네트워크(300)가 번역기를 지원할 뿐 아리나 번역 메커니즘으로서 터널링을 지원한다고 가정한다. 그러므로, IPv4-전용과 IPv6-전용 호스트 사이의 통신은 유지되지 않는다{예를 들어, IPv4-전용 클라이언트(14)는 IPv6-전용 서버(30)와 통신할 수 없다}. 네트워크(300)에서의 모든 가능한 통신은, 연관된 IP 버전(열 2)을 갖는 주어진 클라이언트(열 1)에 대해 연관된 IP 버전(열 4)을 가진 클라이언트가 직접 또는 터널에 의해 어떤 서버(열 3)와 통신할 수 있는 지를 표시하며, 아래에 표 1에 요약되어 있다.
클라이언트 클라이언트 IP 버전 지원된 서버 통신 서버 IP 버전
14 IPv4-전용 19 IPv4-전용
20 IPv4-전용
22 IPv6/IPv4
34 IPv6/IPv4 19 IPv4-전용
20 IPv4-전용
22 IPv6/IPv4
26 IPv6-전용
30 IPv6-전용
36 IPv6-전용 22 IPv6/IPv4
26 IPv6-전용
30 IPv6-전용
표 1을 참조하면, IPv4-전용 클라이언트(14)가 IPv4-전용 또는 IPv6/IPv4 서버(19, 20, 22)와 접촉하고, IPv6-전용인 서버(26,30)와 접촉하지 않는다는 것을 도시한다. IPv6/IPv4 클라이언트(34)는 모든 서버, 즉 서버(19, 20, 22, 26, 30)와 접촉할 수 있고, 대응하는 서버에 의해 사용된 바와 같이 IPv4 또는 IPv6에 자동으로 적응할 수 있다. IPv6-전용 클라이언트(36)는 IPv6-전용 또는 IPv6/IPv4 서버(22, 26, 30)와 접촉하지만, IPv4-전용인 서버(19 및 20)와 접촉하지 않는다.
도 3의 예시적인 이종 IPv6/IPv4 네트워크(300)를 이용하여, 네트워크에서 클라이언트로부터 서버 액세스를 요청하는 프로세스가 설명될 것이다. 이러한 프로세스가 도 2의 이종 네트워크(200)와 비교하여 도 3의 이종 네트워크(300)에서 상당히 더 복잡해진다는 것이 주지된다. 본 예시적인 예에서, 예를 들어 클라이언트(34)와 같은 IPv6/IPv4 노드는 네트워크(300)에서 각각 IPv4-전용, IPv6/IPv4 및 IPv6-전용 노드인 임의의 서버(19, 20, 22, 26, 30)에 접촉하려고 시도할 수 있다. 이전 예에서, 접촉 노드, 즉 네트워크에서 서버와 접촉하는 IPv6/IPv4 클라이언트(34)에 대한 제 1 단계는, 서버의 호스트명의 목록을 취하기 위해 먼저 벤더 포털(18)과 접촉하는 것이다. 그 다음에, 클라이언트(34)와 연관된 사용자는 복귀된 목록으로부터 서버의 호스트명 중 하나를 선택할 수 있으며, 이에 의해 클라이언트는, 이 때 클라이언트(34)가 선택된 서버와의 통신에 착수할 수 있게 하기 위해 선택된 서버의 호스트명을 이진 IP 어드레스에 매핑하도록 DNS 요청을 한다.
모든 DNS 서버가 IPv6 레코드(즉, A6 또는 AAAA 레코드)를 지원하도록 갱신된다고 가정하면, DNS 서비스는 클라이언트(34)로 되돌아갈 것이다.
- IPv4-전용 서버(19 또는 20)가 선택된 경우에 (적어도 하나의) IPv4 어드레스, 또는
- IPv6/IPv4 서버(22)가 선택된 경우에 (적어도 하나의)IPv6( 및 IPv4) 어드레스, {서버(22)가 6-4 구성에 따라 단일 IPv6 어드레스, 또는 IPv4 및 IPv6 어드레스 모두를 통해 DNS 서버에 어떻게 등록되는지에 따라 하나 또는 2개의 어드레스가 복귀될 수 있음이 주지된다.)
- IPv6-전용 서버(26) 또는 IPv6-전용 서버(30) 중 어느 하나가 선택된 경우에 (적어도 하나의) IPv6 어드레스.
일단 IP 어드레스가 DNS 서버로부터 얻어지면, 클라이언트(34)는 다음과의 통신을 개시할 수 있다:
- IPv4 패키지를 이용하는 IPv4-전용 서버(19 또는 20),
- IPv4 패키지로 캡슐화된 IPv4 패키지 또는 IPv6 패키지를 이용하는 IPv6/IPv4 서버(22), 즉 터널링이 적용될 것이다. 터널링이 적용되는 경우에, 터널의 시작점은 IPv6/IPv4 클라이언트(34)인 반면, 터널의 종점은 서버(22)일 것인데, 즉 이것은 호스트-호스트 6-4 자동 터널링일 것이다(RFC 2893 참조).
- IPv4 패키지로 캡슐화된 IPv6 패키지를 이용하는 IPv6-전용 서버(26), 즉 터널링이 적용될 것이다. 터널링이 적용되는 경우에, 터널의 시작점은 클라이언트(34)인 반면, 터널의 종점은 서버(22){이것은 서버(26)를 위한 라우터이다}일 것인데, 즉 이것은 호스트-호스트 6-4 자동 터널링일 것이다(RFC 2893 참조).
- IPv4 패키지로 터널링된 IPv6 패키지를 이용하는 IPv6-전용 서버(30). 터널의 시작점은 IPv6/IPv4 클라이언트(34)인 반면, 터널의 종점은 IPv6/IPv4 중계 라우터(28)일 것이다. IPv6/IPv4 중계 라우터(28)가 6-4 중계 라우터인 경우에, RFC 3068에 정의된 바와 같이 6-4 라우터를 위한 애니캐스트(anycast) 접두부를 이용함으로써 자동으로 검출될 수 있다. 이것은, 클라이언트(34)가 2002:c058:6301::/48과 동일한 디폴트 중계 라우터 접두부로 구성되어야 한다는 것을 의미한다. 이러한 접두부는 IPv4 어드레스 192.88.99.1에 대응한다.
이종 네트워크에 대해 전술한 어드레싱 구성은, 모든 DNS 서버가 IPv4로부터 IPv6으로 이주시 IPv6 레코드(즉, A6 또는 AAAA 레코드)를 지원하도록 갱신되었다고 간주한다. 그러나, 이러한 가정은, IPv4로부터 IPv6으로 이주시, IPv4 레코드만을, 즉 A 레코드만을 지원하는 "레거시(legacy)" DNS 서버일 가능성이 있다는 점에서 실현될 수 없다. 예를 들어, 예시적인 네트워크(300)에서, IPv6-전용 서버(26) 또는 IPv6-전용 서버(30)에 대한 1차 및 2차 DNS 서버가 IPv4 레코드를 지원하고 A6 레코드를 지원하지 않은 경우, 서버(26 또는 30)의 호스트명을 분석하기 위해 DNS 요청을 송신하는 IPv6/IPv4 클라이언트(34)는 실패할 것이고, 타임아웃(time-out)으로 인해 중단될 가능성이 크다.
본 발명은 IPv4 레코드를 지원하는 특정 DNS 서버만의 이러한 '레거시' 문제를 극복하는 것이다. 특히, 본 발명은, DNS 서버가 단지 IPv4 레코드를 지원하는 레거시 DNS 서버이기 때문에 전이 메커니즘으로서 터널링만을 지원하는 통신 네트워크 시스템에 위치한 요청 클라이언트가 DNS 서버를 통해 분석되지 않는 호스트명을 갖는 서버와의 통신을 설정하도록 하는 방법을 개시한다.
D. 실시예
다른 경우 전술한 이유 및 본 명세서에 명확히 언급되지 않은 다른 이유로 인해 DNS 서버를 통해 분석되지 않을 호스트명의 분석은 본 발명의 일실시예에 따라 얻어질 수 있다. 광범위하게 언급된 바와 같이, 서버 호스트명의 분석은 벤더 포털(18)로부터의 지원 또는 협력으로 클라이언트에 의해 달성된다. 벤더 포털(18)은 2개의 새로운 테이블, 즉 서버의 호스트명 테이블로서 본 명세서에 언급된 제 1 테이블, 및 본 명세서에서 Hostname2IPaddress 테이블로서 언급된 제 2 연관된 테이블을 유지함으로써 지원을 제공한다.
서버의 호스트명 테이블(50) 및 Hostname2IPaddress 테이블(40)의 예시적인 구조는 도 4에 도시된다. 이들 테이블은 포털(18)에 저장되는 것이 바람직하다. 도 4에 도시된 바와 같이, 서버의 호스트명 테이블(50)은 3개의 열로 구성된다. "호스트명"(51)으로 지칭된 제 1 열은 벤더 포털(18)에 알려진 모든 서버의 호스트명을 기재한다. "IP 어드레스 버전"(53)으로 지칭된 제 2 열은 서버의 어드레스의 IP 버전, 즉 IPv4-전용, 또는 IPv6/IPv4 또는 IPv6-전용을 기재한다. "DNS 서버를 통해 취득가능한 IP 어드레스"(55)로 지칭된 제 3 열은, 대응하는 서버의 IP 어드레스가 DNS 서버를 통해 분석가능한지의 여부(예를 들어, 예/아니오)를 기재한다. 각 서버가 벤더 포털(18)에 등록할 때 테이블(50)에 엔트리를 제공할 수 있다는 것이 구상된다. 이러한 정보는 등록 목적을 위해 임의로 이루어질 수 있다. 서버가 DNS에 의해 도달가능하지 않은 경우에(어떤 이유라도), 적어도 하나의 유효 IP 어드레스를 그 액세스능력을 위한 보장으로서 벤더 포털(18)로 규정해야 한다. 이러한 정보는 도 4에 도시된 바와 같이, Hostname2IPaddress 테이블(40)로 언급된 본 발명의 제 2 테이블에 유지된다. Hostname2IPaddress 테이블(40)은 3개의 열로 구성된다. "호스트명"(41)으로 지칭된 제 1 열은, DNS를 통해 IP 어드레스로 분석가능하지 않은 호스트명을 갖는 서버의 호스트명 테이블(50)로부터 이들 서버의 호스트명을 기재한다. 예시적인 예에서, 이것은 서버(26) 및 서버(X)를 포함한다. "IP 어드레스"(43)를 지칭한 테이블(40)의 제 2 열은 서버의 액세스능력을 위한 보장으로서 적어도 하나의 유효 IP 어드레스를 기재한다. "중계 라우터"(45)를 지칭한 Hostname2IPaddress 테이블(40)의 제 3 열은 중계 라우터(적용가능한 경우)의 신원을 나타낸다. 고유 IPv6 어드레스를 갖는 서버가 몇몇 특정한 중계 라우터 어드레스를 인식하면, 서버는 이를 벤더 포털(18)로 규정하고, 이 정보는 테이블(40)의 열(45)에 저장될 것이다.
주어진 호스트가 6-4 어드레스를 갖는다면, 인터넷 상의 어떤 지점에 6-4를 이용하여 다른 호스트와 패킷을 교환할 수 있으므로, 어떠한 중계 라우터 정보도 필요하지 않다. 예를 들어, 클라이언트(34 또는 36)는 어떠한 중계 라우터도 없이 서버(22 또는 26)와 통신할 수 있다. 그러나, 6-4 호환되지 않는 고유 범용의 IPv6 어드레스를 소유하는 IPv6-전용 노드와의 통신은 6-4 중계라우터를 필요로 한다(RFC 2373, 2374 참조). 중계 라우터는 6-4 어드레스와 고유 IPv6 어드레스 사이의 전이 라우팅을 지원하도록 구성된다. 도 3에서, 클라이언트(34 또는 36)는 중계 라우터(28)를 통해서만 서버(30)와 통신할 수 있다.
클라이언트{예를 들어 클라이언트(14, 34, 또는 36)}와 벤더 포털(18) 사이의 상호작용은 다음 규칙에 따라 진행한다:
초기 연결이 클라이언트와 포털(18) 사이에서 구축될 때, 클라이언트는 벤더 포털(18)로부터 서버의 호스트명 테이블(50)을 얻는다. 클라이언트는 자체 IP 버전{예를 들어, 클라이언트(36)를 위한 IPv6-전용}을 인식하므로, 통신할 수 있음을 결정한 서버만을 유지하기 위해 포털(18)에 의해 제공된 테이블(50)의 제 1 열(51)에 기재된 서버를 내부적으로 필터링한다. 테이블(50)의 열(51)에 기재된 서버 호스트명을 필터링하는 것은 테이블(50)의 제 2 열(53)에 제공된 정보에 기초한다. 본 예에서, IPv6-전용 클라이언트(36)는, 2개의 호스트명을 배제하고, 목록으로부터 4개의 호스트명, 즉 IPv6-전용 서버(26, 30, X), 및 IPv6/IPv4 서버(22)를 유지하도록 테이블(50)의 열(51)에서 6개의 호스트명의 목록을 필터링한다. 서버(19 및 20)는, IPv6-전용 클라이언트(36)가 IPv4-전용 서버와의 통신을 구축할 수 없다는 결정에 기초하여 배제된다.
다음 단계에서, 클라이언트(36)는 표준 사용자 인터페이스를 통해 서버의 호스트명의 필터링된 목록을 연관된 사용자에게 제공한다. 그 다음에, 연관된 사용자는 필터링된 목록으로부터 서버의 호스트명 중 하나를 선택할 수 있다. 선택된 서버의 IP 어드레스가 DNS 서버를 통해 얻어질 수 있으면{즉, 테이블(50)의 제 3 열(55)에서의 "예" 표시자}, 클라이언트(36)는 종래에서와 같이 서버 호스트명을 분석하기 위해 DNS 요청으로 진행한다. 다른 경우, 선택된 서버의 IP 어드레스가 DNS 서버를 통해 얻어지지 않으면(즉, "아니오" 표시자), 클라이언트는 포털(18)을 통해 "HelpMeToGetIPaddress(hostname)"으로 언급된 특수한 프로토콜을 실행한다. 본 예에서, 클라이언트(36)가 필터링된 목록으로부터 서버(22)를 선택하면, IP 어드레스는 DNS 서버를 통해 얻어질 수 있다. 대안적으로, 클라이언트(36)가 필터링된 목록으로부터 서버(26)를 선택하면, IP 어드레스는 DNS 서버를 통해 얻어지지 않고, 프로토콜은 이 순간에 요청되어야 한다. 프로토콜은 연관된 테이블(40)의 이용을 수반한다. 더 구체적으로, 프로토콜은, 검색 키 또는 인덱스로서 선택된 서버{예를 들어 서버(26)}의 호스트명을 이용하여 테이블(40)의 제 1 열(41)에서 탐색을 수행하여, 테이블(40)의 각 레코드의 제 2 열(43)에 저장된 서버의 하나 이상의 IP 어드레스를 포털(18)이 결정하는 단계를 수반한다. 적용가능한 경우, 대응하는 중계 라우터는 테이블(40)의 제 3 열(45)로부터 결정된다.
도 5는, 서버의 IP 어드레스가 DNS 서비스에 의해 분석되거나 분석되지 않을 수 있는, 이종 IPv6/IPv4 네트워크에서 요청된 서버에 클라이언트가 액세스하도록 하는 알고리즘을 도시한 흐름도이다. 도 3에서 IPv6/IPv4 네트워크(300)에 대해 계속해서 참조한다. 설명에서, 클라이언트는 도 3의 네트워크의 클라이언트(14, 34 또는 36) 중 임의의 클라이언트를 언급한다. 포털은 도 3에서 벤더 포털(18)을 언급하고, 테이블(50 및 40)은 벤더 포털(18)에 의해 지원된다.
단계(52)에서, 클라이언트는 포털(18)로부터 서버의 호스트명 테이블(50)을 얻고, 테이블(50)의 제 1 열(51)에 저장된 서버의 제공된 목록을 필터링한다. 필터링은 목록에서 각 서버에 의해 사용된 IP 버전(들)과 클라이언트에 의해 사용된 IP 버전(들)을 비교함으로써 수행된다. 특히, 테이블(50)의 각 엔트리(레코드)에 대해, 클라이언트 IP 버전은 테이블(50)의 서버 IP 버전{제 2 열(53)에 정의된 바와 같이, 즉 "IP 어드레스 버전"}에 대해 비교된다. IP 버전이, 클라이언트와 서버 사이에서 통신할 수 있도록 이루어진다는 것이 결정되면, 서버는 필터링된 목록에 유지되고, 그렇지 않으면, 서버는 배제된다. 그 다음에, 클라이언트는 사용자 인터페이스를 통해 서버의 호스트명의 필터링된 목록을 클라이언트의 연관된 사용자에게 제공한다.
단계(54)에서, 클라이언트와 연관된 사용자는 디스플레이되는 필터링된 목록으로부터 하나의 서버 호스트명을 선택할 수 있다.
단계(56)에서, 이때 클라이언트는, 테이블(50)의 제 3 열(55)을 통해, 선택된 서버의 IP 어드레스가 DNS 서버를 통해 얻어질 수 있는지를 체크한다. 만약 "예"이면, 알고리즘은 단계(60)로 나아가고, "아니오"이면, 알고리즘은 단계(70)로 나아간다.
단계(60)에서, 클라이언트는, 선택된 서버의 호스트명의 IP 어드레스를 복귀시키라고 디폴트 DNS 서버에게 요청하고, 알고리즘은 단계(62)로 나아간다.
단계(62)에서, 클라이언트는 선택된 서버의 하나 이상의 IP 어드레스를 취한다. 서버가 하나를 초과하는 IP 어드레스(예를 들어, 2개의 IPv4 어드레스 또는 하나의 IPv4 및 하나의 IPv6 어드레스)로 등록되면, DNS 서버는 이들 모두를 복귀시킬 것임이 주지된다. 그 다음에 알고리즘은 단계(80)로 나아간다.
단계(70)에서, 클라이언트는 서버의 디폴트 IP 어드레스(들) 및 임의의 연관된 라우터 정보를 얻기 위해 전술한 바와 같이 포털(18)로 "HelpMeToGetIPadrress(호스트명)" 프로토콜을 실행시킨다.
단계(72)에서, 클라이언트는 단계(70)에서 초래된 "HelpMeToGetIPadrress(호스트명)" 프로토콜의 출력으로서 서버의 IP 어드레스(들) 및 대응하는 중계 라우터(적용가능한 경우)를 취한다. 그 다음에 알고리즘은 단계(80)로 나아간다.
단계(80)에서, 클라이언트는, DNS 요청 또는 "HelpMeToGetIPadrress(호스트명)" 프로토콜 중 어느 하나의 출력으로서 (제 1의)복귀된 어드레스(들)가 자신의 어드레스와 동일한 IP 버전인지를 체크한다. 만약 "예"이면, 알고리즘은 단계(82)로 나아가고, "아니오"이면, 알고리즘은 단계(84)로 나아간다.
단계(82)에서, 클라이언트는, IP 어드레스가 IPv6 어드레스인지를 체크한다. 만약 "예"이면, 알고리즘은 단계(100)로 나아가고, "아니오"이면, 알고리즘은 단계(90)로 나아간다.
단계(84)에서, 클라이언트는, DNS 또는 "HelpMeToGetIPadrress(호스트명)" 프로토콜 중 어느 하나에 의해 복귀된 다음 어드레스를 선택하고, 단계(80)로 되돌아간다. 단계(52)에서 수행된 서버의 필터링으로 인해, 클라이언트가 통신하는데 사용할 수 있는 적어도 하나의 서버의 IP 어드레스가 있을 것임이 주지된다.
단계(90)에서, 클라이언트는 IPv4를 이용하여 서버와 통신한다.
단계(100)에서, 클라이언트는, 클라이언트의 어드레스 및 서버의 IPv6 어드레스가 6-4 방식에 따라 조합되는지(RFC 3056 참조), 즉 접두부의 처음 16 비트가 2002와 동일한지를 체크한다. 만약 "예"이면, 알고리즘은 단계(102)로 나아가고, "아니오"이면, 알고리즘은 단계(104)로 나아간다.
단계(102)에서, 클라이언트는 IPv6 및 6-4 자동 터널링(RFC 2893 참조)을 이용하여 서버와 통신한다.
단계(104)에서, 클라이언트는, 터널의 종점이 항상 중계 라우터이기 때문에 IPv6 및 자동 터널링(RFC 2893 참조)을 이용하여 서버와 통신한다. 중계 라우터가 6-4이면, RFC 3068에서 정의된 바와 같이 애니캐스트 접두부 2002:c058:6301::/48을 이용함으로써 자동으로 검출될 수 있다. 중계 라우터가 6-4가 아니고, 클라이언트가 단계(72)를 수행하였으면, 중계 라우터의 어드레스/접두부는 포털(18)에 의해 테이블(40)로부터 검색될 것이고, "HelpMeToGetIPadrress(호스트명)" 프로토콜을 실행하는 출력으로서 클라이언트로 복귀될 것이다.
마지막으로, 전술한 논의는 본 발명의 단지 예시에 불과하도록 의도되고, 첨부된 청구항을 임의의 특정 실시예 또는 실시예의 그룹에 한정시키는 것으로 해석되지 않아야 한다. 따라서, 본 발명이 본 발명의 특정한 예시적인 실시예를 참조하여 특히 상세하게 설명되었지만, 다수의 변형 및 변경이 아래의 청구항에 설명된 바와 같이 본 발명의 더 넓고 의도된 사상 및 범주에서 벗어나지 않고도 이루어질 수 있음이 또한 이해되어야 한다. 명세서 및 도면은 이에 따라 예시적인 방식으로 간주될 것이고, 첨부된 청구항의 범주를 한정하도록 의도되지 않는다.
첨부된 청구항을 해석할 때,
a) "포함하는"이라는 단어는 주어진 청구항에 기재된 것 이외의 다른 요소 또는 동작의 존재를 배제하지 않는다;
b) 단수 요소는 그러한 복수의 요소의 존재를 배제하지 않는다;
c) 청구항 내의 임의의 참조 번호는 그 범주를 한정하지 않는다.;
d) 수 개의 "수단"은 동일한 아이템 또는 하드웨어 또는 소프트웨어로 구현된 구조 또는 기능에 의해 나타날 수 있다;
e) 개시된 각 요소는 하드웨어 부분(예를 들어 별도의 전자 회로), 소프트웨어 부분(예를 들어 컴퓨터 프로그래밍) 또는 이들의 임의의 조합으로 구성될 수 있다.
상술한 바와 같이, 본 발명은 일반적으로 이종(heterogeneous) IP 네트워크에서 클라이언트와 서버 사이의 전자 컨텐츠 전달에 관한 것으로, 이종 네트워크에서 클라이언트가 DNS 서버를 통해 분석될 수 없는 호스트명을 갖는 서버와 통신하도록 하는 방법 등에 이용된다.

Claims (27)

  1. 이종(heterogeneous) IP 네트워크(300)에서 클라이언트 노드(14, 34, 36)와 서버 노드 사이의 통신을 구축하는 방법으로서,
    (a) 상기 클라이언트와 연관된 사용자에 의해, 원하는 컨텐츠를 상기 클라이언트에게 제공할 수 있는 서버 호스트명(51)의 목록에 대해 상기 네트워크(300)내의 포털(portal)(18)에게 요청하는 단계와;
    (b) 상기 클라이언트 요청에 응답하여 제 1 테이블(50) 및 제 2 테이블(40)을 상기 포털(18)로부터 상기 클라이언트로 제공하는 단계로서, 상기 제 1 테이블(50)은 서버 노드 호스트명(51)의 상기 목록을 포함하는, 제공 단계와;
    (c) 상기 클라이언트(14, 34, 36)가 통신을 구축할 수 없는 상기 서버 호스트명(51)을 배제하기 위해 상기 클라이언트(14, 34, 36)에서 서버 호스트명(51)의 상기 제공된 목록을 필터링하는 단계와;
    (d) 서버 호스트명(51)의 상기 필터링된 목록으로부터 서버 호스트명(51)을 상기 사용자가 선택하는 단계와;
    (e) 상기 사용자 선택된 서버 호스트명(51)과 연관된 IP 어드레스가 도메인 이름 서버(DNS)를 통해 분석가능한지를 상기 제 1 테이블(50)로부터 결정하는 단계와;
    (f) 상기 단계(e)가 충족되면, 상기 DNS로부터 상기 연관된 IP 어드레스를 취득하는 단계와;
    (g) 상기 단계(e)가 충족되지 않으면, 상기 선택된 서버의 호스트명(51)을 갖는 서버의 하나 이상의 디폴트 IP 어드레스를 결정하기 위해 상기 포털(18)로 상기 클라이언트(14, 34, 36)에 의해 프로토콜을 실행하는 단계를
    포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  2. 제 1항에 있어서, 상기 단계(f)에 뒤이어, 상기 연관된 IP 어드레스를 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 단계를 더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  3. 제 2항에 있어서, 상기 선택된 서버(19, 20, 22, 26, 30)와 통신을 구축하는 단계는,
    (1) 상기 DNS로부터 제 1 복귀된 IP 어드레스의 IP 버전이 상기 클라이언트(14, 34, 36)의 IP 버전과 동일한 버전인지를 결정하는 단계와;
    (2) 상기 단계(1)가 충족되지 않으면, 상기 DNS로부터 다음의 복귀된 IP 어드레스를 취득하고, 상기 단계(1)를 반복하는 단계와;
    (3) 상기 단계(1)가 충족되면, 상기 제 1 복귀된 IP 어드레스의 상기 IP 버전 및 상기 클라이언트(14, 34, 36)의 상기 IP 버전이 IPv6 버전인지를 결정하는 단계와;
    (4) 상기 단계(3)가 충족되면, 상기 IPv6 버전이 6-4(6to4) 어드레스인지를 결정하는 단계와;
    (5) 상기 단계(4)가 충족되면, 상기 IPv6 프로토콜 및 자동 터널링(tunneling)을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 단계를
    더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  4. 제 3항에 있어서, 상기 단계(4)가 충족되지 않으면, 종점(endpoint) 어드레스로서 중계 라우터를 갖는 터널링 방법 및 IPv6 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  5. 제 3항에 있어서, 상기 단계(3)가 충족되지 않으면, IPv4 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  6. 제 1항에 있어서, 상기 단계(g)에 뒤이어, 상기 연관된 IP 어드레스를 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 단계를 더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  7. 제 6항에 있어서, 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 단계는,
    (1) 상기 제 2 테이블(40)로부터의 제 1 복귀된 IP 어드레스의 IP 버전이 상기 클라이언트(14, 34, 36)의 IP 버전과 동일한 버전인지를 결정하는 단계와;
    (2) 상기 단계(1)가 충족되지 않으면, 상기 제 2 테이블(40)로부터 다음의 복귀된 IP 어드레스를 취득하고, 상기 단계(1)를 반복하는 단계와;
    (3) 상기 단계(1)가 충족되면, 상기 제 1 복귀된 IP 어드레스의 상기 IP 버전 및 상기 클라이언트(14, 34, 36)의 상기 IP 버전이 IPv6 버전인지를 결정하는 단계와;
    (4) 상기 단계(3)가 충족되면, 상기 IPv6 버전이 6-4 어드레스인지를 결정하는 단계와;
    (5) 상기 단계(4)가 충족되면, 상기 IPv6 프로토콜 및 자동 터널링을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 단계를
    더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  8. 제 7항에 있어서, 상기 단계(4)가 충족되지 않으면, 종점 어드레스로서 상기 제 2 테이블(40)로부터 얻어진 중계 라우터 어드레스에 대한 터널링 및 IPv6 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  9. 제 7항에 있어서, 상기 단계(3)가 충족되지 않으면, IPv4 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  10. 제 1항에 있어서, 상기 결정 단계는, 상기 DNS를 통해 상기 선택된 서버의 호스트명(51)의 분석가능(resolvability) 상태를 나타내는 레코드 값을 얻기 위해, 인덱스로서 상기 사용자 선택된 서버 호스트명(51)을 이용하여 상기 클라이언트(14, 34, 36)에 의해 상기 제 1 테이블(50)에서 탐색(lookup)을 수행하는 단계를 더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  11. 제 1항에 있어서, 상기 단계(g)는, 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하기 위해 상기 사용자 선택된 서버의 호스트명(51)과 연관된 하나 이상의 디폴트 IP 어드레스(43)를 결정하기 위해, 상기 클라이언트(14, 34, 36)에 의해 상기 사용자 선택된 서버의 호스트명(51)을 인덱스로서 이용하여 상기 제 2 테이블(40)에서의 탐색을 수행하는 단계를 더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  12. 제 1항에 있어서, 상기 단계(a) 이전에, 복수의 레코드를 상기 벤더 포털(18)에서의 상기 제 1 테이블(50)에 위치시키는(populating) 단계를 더 포함하며, 상기 레코드 각각은,
    상기 원하는 컨텐츠를 상기 클라이언트(14, 34, 36)에 제공할 수 있는 상기 네트워크(300)에서의 서버의 상기 서버 호스트명(51)과;
    상기 서버 호스트명(51)과 연관된 IP 어드레스 버전(53)과;
    상기 서버 호스트명(51)이 상기 네트워크(300)에서의 DNS 서버를 통해 분석가능한지에 대한 표시자(55)를
    포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  13. 제 8항에 있어서, 상기 위치 지정(populating) 단계는 상기 IP 네트워크(300)의 동작 이전에 등록 스테이지 동안 수행되는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  14. 제 1항에 있어서, 상기 단계(a) 이전에, 복수의 레코드를 상기 벤더 포털(18)에서의 상기 제 2 테이블(40)에 위치시키는 단계를 더 포함하고, 상기 레코드 각각은,
    상기 원하는 컨텐츠를 상기 클라이언트(14, 34, 36)에게 제공할 수 있는 상기 네트워크(300)에서의 서버의 상기 서버 호스트명(41)과;
    상기 서버 호스트명(41)과 연관된 디폴트 IP 어드레스(43)와;
    중계 라우터 어드레스(45)를
    포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  15. 제 14항에 있어서, 상기 위치 지정 단계는 상기 IP 네트워크(300)의 동작 이전에 등록 스테이지 동안 수행되는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  16. 제 1항에 있어서, 상기 단계(c)는,
    상기 서버 호스트명(51)과 연관된 하나 이상의 IP 어드레스 버전(53)과 상기 클라이언트(14, 34, 36)의 IP 어드레스 버전을 비교하여, 상기 비교된 IP 어드레스 버전이 상기 클라이언트(14, 34, 36)와 상기 서버 사이의 통신을 구축할 수 있는지를 상기 비교로부터 결정하는 단계와;
    상기 비교 단계가 충족되면, 상기 필터링된 목록에서 상기 서버 호스트명(51) 및 연관된 레코드 정보를 유지하는 단계와;
    상기 비교 단계가 충족되지 않으면, 상기 필터링된 목록으로부터 상기 서버 호스트명(51) 및 상기 연관된 정보를 삭제하는 단계를
    더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 방법.
  17. 이종 IP 네트워크(300)에서 클라이언트(14, 34, 36) 노드와 서버 노드(19, 20, 22, 26, 30) 사이의 통신을 구축하는 시스템으로서,
    상기 클라이언트(14, 34, 36)와 연관된 사용자에 의해, 원하는 컨텐츠를 상기 클라이언트(14, 34, 36)에게 제공할 수 있는 서버 호스트명의 목록을 상기 네트워크(300)내의 포털(portal)(18)에게 요청하는 수단과;
    상기 클라이언트 요청에 응답하여 제 1 테이블(50) 및 제 2 테이블(40)을 상기 포털(18)로부터 상기 클라이언트(14, 34, 36)로 제공하는 수단으로서, 상기 제 1 테이블(50)은 서버 노드 호스트명(51)의 상기 목록을 포함하는, 제공 수단과;
    상기 클라이언트(14, 34, 36)가 통신을 구축할 수 없는 상기 서버 호스트명(51)을 배제하기 위해 상기 클라이언트(14, 34, 36)에서 서버 호스트명(51)의 상기 제공된 목록을 필터링하는 수단과;
    서버 호스트명의 상기 필터링된 목록으로부터 서버 호스트명(51)을 상기 사용자가 선택하는 수단과;
    상기 사용자 선택된 서버 호스트명(51)과 연관된 IP 어드레스가 도메인 이름 서버(DNS)를 통해 분석가능한지를 상기 제 1 테이블(50)로부터 결정하는 수단과;
    상기 결정 수단이 충족되면, 상기 DNS로부터 상기 연관된 IP 어드레스를 취득하는 수단과;
    상기 결정 수단이 충족되지 않으면, 상기 선택된 서버의 호스트명(51)을 갖는 서버(19, 20, 22, 26, 30)의 하나 이상의 디폴트 IP 어드레스(43)를 결정하기 위해 상기 클라이언트(14, 34, 36)에 의해 상기 포털(18)로 프로토콜을 실행하는 수단을
    포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  18. 제 17항에 있어서, 상기 결정 수단이 충족될 때, 상기 연관된 IP 어드레스를 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 수단을 더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  19. 제 18항에 있어서, 상기 연관된 IP 어드레스를 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 상기 수단은,
    상기 DNS로부터 제 1 복귀된 IP 어드레스의 IP 버전이 상기 클라이언트(14, 34, 36)의 IP 버전과 동일한 버전인지를 결정하는 제 1 수단과;
    상기 결정 수단이 충족되지 않으면, 상기 DNS로부터 다음의 복귀된 IP 어드레스를 취득하고 결정 수단을 반복하기 위한 수단과;
    상기 제 1 결정 수단이 충족되면, 상기 제 1 복귀된 IP 어드레스의 상기 IP 버전 및 상기 클라이언트(14, 34, 36)의 상기 IP 버전이 IPv6 버전인지를 결정하는 제 2 수단과;
    상기 제 2 수단이 충족되면, 상기 IPv6 버전이 6-4(6to4) 어드레스인지를 결정하는 제 3 수단과;
    상기 제 3 수단이 충족되면, 상기 IPv6 프로토콜 및 자동 터널링을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 수단을
    더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  20. 제 19항에 있어서, 상기 제 3 결정 수단이 충족되지 않으면, 종점 어드레스로서 중계 라우터를 갖는 터널링 방법 및 IPv6 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  21. 제 19항에 있어서, 상기 제 2 결정 수단이 충족되지 않으면, IPv4 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  22. 제 17항에 있어서, 상기 결정 수단이 충족되지 않으면, 상기 연관된 IP 어드레스를 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 수단을 더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  23. 제 22항에 있어서, 상기 통신을 구축하는 수단은,
    상기 제 2 테이블(40)로부터의 제 1 복귀된 IP 어드레스의 IP 버전이 상기 클라이언트(14, 34, 36)의 IP 버전과 동일한 버전인지를 결정하는 제 1 수단과;
    상기 제 1 결정 수단이 충족되지 않으면, 상기 제 2 테이블(40)로부터 다음의 복귀된 IP 어드레스를 취득하고, 상기 제 1 결정 수단을 반복하는 수단과;
    상기 제 1 결정 수단이 충족되면, 상기 제 1 복귀된 IP 어드레스의 상기 IP 버전 및 상기 클라이언트(14, 34, 36)의 상기 IP 버전이 IPv6 버전인지를 결정하는 제 2 수단과;
    상기 제 2 결정 수단이 충족되면, 상기 IPv6 버전이 6-4 어드레스인지를 결정하는 제 3 수단과;
    상기 제 3 결정 수단이 충족되면, 상기 IPv6 프로토콜 및 자동 터널링을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는 수단을
    더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  24. 제 23항에 있어서, 상기 제 3 결정 수단이 충족되지 않으면, 종점 어드레스로서 중계 라우터를 갖는 터널링 방법 및 IPv6 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  25. 제 26항에 있어서, 상기 제 2 결정 수단이 충족되지 않으면, IPv4 프로토콜을 이용하여 상기 선택된 서버(19, 20, 22, 26, 30)와의 통신을 구축하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  26. 제 17항에 있어서, 상기 제 1 테이블(50)은 상기 벤더 포털(18)에 상주하고, 복수의 레코드로 구성되며, 상기 레코드 각각은,
    상기 원하는 컨텐츠를 상기 클라이언트(14, 34, 36)에 제공할 수 있는 상기 네트워크(300)에서의 서버의 상기 서버 호스트명(51)과;
    상기 서버 호스트명(51)과 연관된 IP 어드레스 버전과;
    상기 서버 호스트명(51)이 상기 네트워크(300)에서의 DNS 서버를 통해 분석가능한지에 대한 표시자(55)를
    더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
  27. 제 17항에 있어서, 상기 제 2 테이블(40)은 상기 벤더 포털(18)에 상주하고, 복수의 레코드로 구성되며, 상기 레코드 각각은,
    상기 원하는 컨텐츠를 상기 클라이언트(14, 34, 36)에게 제공할 수 있는 상기 네트워크(300)에서의 서버의 상기 서버 호스트명(41)과;
    상기 서버 호스트명(41)과 연관된 디폴트 IP 어드레스(43)와;
    중계 라우터 어드레스(45)를
    더 포함하는, 이종 IP 네트워크에서 클라이언트 노드와 서버 노드 사이의 통신을 구축하는 시스템.
KR1020057011537A 2002-12-20 2003-12-05 이종 ｉｐ 네트워크에서 클라이언트와 서버 사이의 통신을구축하는 시스템 및 방법 KR20050086925A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US43523602P 2002-12-20 2002-12-20
US60/435,236 2002-12-20

Publications (1)

Publication Number Publication Date
KR20050086925A true KR20050086925A (ko) 2005-08-30

Family

ID=32682191

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057011537A KR20050086925A (ko) 2002-12-20 2003-12-05 이종 ｉｐ 네트워크에서 클라이언트와 서버 사이의 통신을구축하는 시스템 및 방법

Country Status (7)

Country Link
US (1) US20060095585A1 (ko)
EP (1) EP1579656A1 (ko)
JP (1) JP2006511152A (ko)
KR (1) KR20050086925A (ko)
CN (1) CN1729673A (ko)
AU (1) AU2003303170A1 (ko)
WO (1) WO2004057831A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8964761B2 (en) 2006-01-19 2015-02-24 Samsung Electronics Co., Ltd. Domain name system, medium, and method updating server address information

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050079420A (ko) * 2004-02-05 2005-08-10 삼성전자주식회사 터널링 서비스 방법 및 시스템
JP2006148418A (ja) * 2004-11-18 2006-06-08 Fujitsu Ltd サーバおよび通信制御方法
KR100594773B1 (ko) * 2004-12-20 2006-06-30 한국전자통신연구원 다중 네트워크 인터페이스를 가진 노드의 이기종 네트워크연동 방법
JP4241681B2 (ja) * 2005-07-05 2009-03-18 ブラザー工業株式会社 情報処理装置、およびプログラム
US7810149B2 (en) * 2005-08-29 2010-10-05 Junaid Islam Architecture for mobile IPv6 applications over IPv4
KR100757881B1 (ko) * 2006-09-20 2007-09-11 삼성전자주식회사 Ｎａｔ를 이용한 자동 터널링 방법 및 그 시스템
KR100901790B1 (ko) * 2006-12-04 2009-06-11 한국전자통신연구원 ＩＰｖ４ 네트워크 기반 ＩＰｖ６ 서비스 제공시스템에서의 제어 터널 및 다이렉트 터널 설정 방법
KR100834578B1 (ko) * 2006-12-08 2008-06-02 한국전자통신연구원 듀얼스택 이동 ＩＰｖ６상에서 이동 노드의 이동 감지 방법
US8055795B2 (en) * 2007-10-02 2011-11-08 Echostar Technologies Llc Systems and methods for proxy resolution of domain name service (DNS) requests
JP5199719B2 (ja) * 2008-04-07 2013-05-15 キヤノン株式会社 ネットワークシステム
JP4636172B2 (ja) * 2008-12-18 2011-02-23 ソニー株式会社 操作装置、コンテンツ視聴制限方法及び電子機器装置
CN101827136B (zh) * 2010-03-30 2013-04-24 北京网御星云信息技术有限公司 域名系统服务器缓存感染的防御方法和网络出口设备
CN101834911B (zh) * 2010-03-31 2013-04-24 北京网御星云信息技术有限公司 域名劫持的防御方法和网络出口设备
US8694659B1 (en) * 2010-04-06 2014-04-08 Symantec Corporation Systems and methods for enhancing domain-name-server responses
US8406232B2 (en) * 2010-06-17 2013-03-26 Microsoft Corporation 4to6 network stack for IPv4 applications
CN102546845B (zh) * 2010-12-17 2015-03-11 中国移动通信集团公司 业务访问方法、装置及系统
US9363102B1 (en) * 2010-12-21 2016-06-07 Amazon Technologies, Inc. Methods and apparatus for implementing anycast flow stickiness in stateful sessions
WO2013014731A1 (ja) * 2011-07-22 2013-01-31 富士通株式会社 サーバ装置、通信制御プログラム、及び通信制御方法
CN102291305B (zh) * 2011-08-16 2014-12-31 神州数码网络(北京)有限公司 实现6to4中继路由的方法和设备以及报文转发方法
CN102394817B (zh) * 2011-10-28 2014-08-27 北京星网锐捷网络技术有限公司 一种隧道转发方法、装置及网络设备
KR20130067780A (ko) * 2011-12-14 2013-06-25 삼성전자주식회사 도메인 네임 서버 주소 설정 방법 및 장치
KR101954670B1 (ko) * 2012-04-03 2019-03-06 삼성전자주식회사 통신 시스템에서 도메인 네임 시스템 서버를 관리하기 위한 장치 및 방법
US9407701B2 (en) * 2012-12-14 2016-08-02 Apple Inc. Address family preference in multiple network interface environments
US9838259B1 (en) * 2013-03-08 2017-12-05 F5 Networks, Inc. Methods for managing client defined response requirements in DNS query and devices thereof
US9391891B2 (en) * 2013-10-23 2016-07-12 University Of Electronic Science And Technology Of China Method for accessing internet via a vehicle network
WO2015160934A1 (en) * 2014-04-15 2015-10-22 Level 3 Communications, Llc Geolocation via internet protocol
JP2016110301A (ja) * 2014-12-03 2016-06-20 株式会社リコー システム、情報機器、情報処理装置、情報処理方法およびプログラム
CN104811370B (zh) * 2015-04-27 2018-05-08 北京北信源软件股份有限公司 一种基于标识的安全即时通信系统架构
WO2017106779A1 (en) * 2015-12-18 2017-06-22 F5 Networks, Inc. Methods of collaborative hardware and software dns acceleration and ddos protection
TWI685272B (zh) * 2017-09-27 2020-02-11 關隆股份有限公司 無線系統的連線方法
US11044200B1 (en) 2018-07-06 2021-06-22 F5 Networks, Inc. Methods for service stitching using a packet header and devices thereof
US11245663B1 (en) * 2019-05-03 2022-02-08 Pixalate, Inc. Systems and methods for detecting the IPv4 address and the IPv6 address of a purported end user device over a network
CN111262958B (zh) * 2020-01-09 2023-02-03 深信服科技股份有限公司 内外网站交互方法、装置、设备及计算机可读存储介质
CN112187902B (zh) * 2020-09-21 2023-10-17 普联国际有限公司 IPv6隧道模式下的DNS代理方法、装置、存储介质及终端设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5761618A (en) * 1994-12-22 1998-06-02 Bell Atlantic Mobile Systems, Inc. Updating technique for downloading new system identification (SID) list into a handset
US6003030A (en) * 1995-06-07 1999-12-14 Intervu, Inc. System and method for optimized storage and retrieval of data on a distributed computer network
US6118768A (en) * 1997-09-26 2000-09-12 3Com Corporation Apparatus and methods for use therein for an ISDN LAN modem utilizing browser-based configuration with adaptation of network parameters
ATE445988T1 (de) * 2000-12-04 2009-10-15 Nokia Corp Anwendergerät, verfahren und kommunikationssystem zur herstellung einer verbindung zu einem netzwerkdienstelement
CA2393547A1 (en) * 2002-07-15 2004-01-15 Hexago Inc. Method and apparatus for connecting ipv6 devices through an ipv4 network using a tunneling protocol
US7552237B2 (en) * 2002-10-17 2009-06-23 International Business Machines Corporation Network address cache apparatus and method

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8964761B2 (en) 2006-01-19 2015-02-24 Samsung Electronics Co., Ltd. Domain name system, medium, and method updating server address information

Also Published As

Publication number Publication date
JP2006511152A (ja) 2006-03-30
US20060095585A1 (en) 2006-05-04
EP1579656A1 (en) 2005-09-28
AU2003303170A1 (en) 2004-07-14
WO2004057831A1 (en) 2004-07-08
CN1729673A (zh) 2006-02-01

Similar Documents

Publication Publication Date Title
KR20050086925A (ko) 이종 ｉｐ 네트워크에서 클라이언트와 서버 사이의 통신을구축하는 시스템 및 방법
US7639686B2 (en) Access network clusterhead for providing local mobility management of a roaming IPv4 node
US7010585B2 (en) DNS server, DHCP server, terminal and communication system
US6480508B1 (en) Router-based domain name system proxy agent using address translation
US9019965B2 (en) Methods and devices for routing data packets between IPv4 and IPv6 networks
US7411967B2 (en) Private network gateways interconnecting private networks via an access network
US7533164B2 (en) Method and system for enabling connections into networks with local address realms
JP4118909B2 (ja) デュアルスタック変換メカニズムを用いたＩＰｖ４−ＩＰｖ６変換システム及びその方法
US9699136B2 (en) Stateless autoconfiguration of hostnames of network devices
CN110691150A (zh) 一种基于SDN的IPv4与IPv6互联方法及系统
JP2004120534A (ja) ルータと中継装置、フォワーディング方法
JP3858884B2 (ja) ネットワークアクセスゲートウェイ及びネットワークアクセスゲートウェイの制御方法並びにプログラム
JPH1117726A (ja) Ｄｎｓ機能を内蔵したｉｐネットワークの結合制御装置
Rooney Introduction to IP address management
US20040153502A1 (en) Enhanced DNS server
KR100496637B1 (ko) ＩＰｖ６무선 랜 환경에서의 ＩＰｖ４통신방법
EP1919168B1 (en) Global reachability in communication networks
CN102624707A (zh) 一种协商IPv6信息的方法及系统
Cisco Glossary
JP2000156710A (ja) Ｉｐアドレス変換装置
WO2004100499A1 (en) A communication network, a network element and communication protocol and method of address auto-configuration therefor
Elahi et al. Internet Protocols Part I
Wei Research on Campus Network IPV6 Transition Technology
Chen et al. IDNS: A simple approach to internet host portability
Green et al. IPv6 translation for IPv4 embedded systems

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid