제로 구성 네트워킹

Zero-configuration networking

제로 구성 네트워킹(zero-conf)은 컴퓨터 또는 네트워크 주변 기기가 상호 연결되면 TCP/IP(Internet Protocol Suite)를 기반으로 사용 가능한 컴퓨터 네트워크를 자동으로 생성하는 기술 세트입니다.오퍼레이터의 수동 조작이나 특별한 설정 서버가 필요 없습니다.제로 컨피규레이션을 사용하지 않을 경우 네트워크 관리자는 DHCP(Dynamic Host Configuration Protocol) 및 DNS(Domain Name System) 등의 네트워크 서비스를 설정하거나 각 컴퓨터의 네트워크 설정을 수동으로 구성해야 합니다.

Zeroconf는 네트워크 디바이스에 대한 수치 네트워크 주소 자동 할당, 컴퓨터 호스트 이름 자동 배포 및 해결, 인쇄 장치 등의 네트워크 서비스 자동 위치 등 3가지 핵심 기술을 기반으로 구축되었습니다.

인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

배경

컴퓨터 네트워크는 숫자 네트워크 주소를 사용하여 참여 장치 네트워크 내의 통신 엔드포인트를 식별합니다.이것은, 번호열을 할당해 각 전화기를 식별하는 전화 네트워크와 비슷합니다.현대의 네트워크 프로토콜에서 전송되는 정보는 일련의 네트워크 패킷으로 분할됩니다.모든 패킷에는, 전송의 송신원주소와 행선지 주소가 포함됩니다.네트워크 라우터는 이러한 주소를 조사하여 수신처에 대한 각 단계에서 데이터 패킷을 전송하기 위한 최적의 네트워크 경로를 결정합니다.

전화기에 전화번호가 붙어 있는 것과 마찬가지로, 초기 네트워크에서는 네트워크 디바이스에 주소 라벨을 부착하는 것이 일반적이었습니다.최신 네트워크, 특히 필요할 때만 디바이스 전원이 켜지는 가정용 네트워크의 동적인 특성으로 인해 사용자가 초기화와 관리에 관여할 필요가 없는 동적 주소 할당 메커니즘이 필요합니다.이러한 시스템은 브랜드 및 모델 번호와 같이 장비 제조업체에 의해 선택된 공통 이름 또는 장비를 식별하기 위해 사용자가 선택한 공통 이름을 자동으로 부여합니다.그러면 이름과 주소가 디렉토리 서비스에 자동으로 입력됩니다.

초기 컴퓨터 네트워킹은 통신 네트워크의 기술을 기반으로 구축되었으며, 따라서 프로토콜은 로컬 장치를 LAN에 연결하는 것과 주로 장거리 통신을 위한 것의 두 가지 그룹으로 분류되는 경향이 있었습니다.후자의 WAN(Wide Area Network) 시스템에서는 네트워크 관리자가 주소와 이름을 수동으로 할당하는 중앙 집중식 셋업이 이루어지는 경향이 있었습니다.LAN 시스템은 오퍼레이터와 관리자의 개입을 최소한으로 억제하고 새로운 기기를 LAN에 추가할 수 있도록 이러한 작업을 보다 자동화하는 경향이 있었습니다.

제로 구성의 LAN 시스템의 초기 예는 애플이 1980년대에 초기 매킨토시 컴퓨터를 위해 도입한 프로토콜인 AppleTalk입니다.Mac은 물론 프로토콜을 지원하는 다른 장치도 간단히 연결하기만 하면 네트워크에 추가할 수 있으며, 모든 추가 구성이 자동화되었습니다.네트워크 주소는 AARP(AppleTalk Address Resolution Protocol)로 알려진 프로토콜을 사용하여 각 장치에 의해 자동으로 선택되었으며, 각 시스템은 NBP(Name Binding Protocol)로 알려진 프로토콜을 사용하여 자체 로컬 디렉토리 서비스를 구축했습니다.NBP에는 이름뿐만 아니라 디바이스 유형 및 물리적인 위치나 가용성 등 사용자가 제공한 추가 정보가 포함되어 있습니다.사용자는 응용 프로그램 Chooser를 사용하여 네트워크상의 모든 디바이스를 검색할 수 있습니다.이 애플리케이션은 디바이스 유형에 따라 이름을 필터링합니다.

Internet Protocol(IP) 네트워크에서 네트워크의 Domain Name System 데이터베이스는 처음에는 네트워크 관리자가 수동으로 유지 관리했습니다.이 데이터베이스의 유지보수를 자동화하려는 노력으로 DHCP(Dynamic Host Configuration Protocol)와 같은 자동화된 서비스를 제공하는 많은 새로운 프로토콜이 도입되었습니다.

주소 선택

네트워크상의 호스트에는, 같은 네트워크상의 다른 디바이스에 일의로 식별되는 IP 주소를 할당할 필요가 있습니다.일부 네트워크에서는 새로운 디바이스가 추가될 때 이러한 주소를 할당하는 중앙 기관이 있습니다.이 작업을 자동적으로 처리하기 위한 메커니즘이 도입되어 IPv4 와 IPv6 의 양쪽 모두에 주소 자동 설정용 시스템이 포함되어 있습니다.이것에 의해, 디바이스는 단순한 메카니즘을 사용해 사용하는 세이프 주소를 결정할 수 있습니다.링크 로컬 어드레싱의 경우, IPv4 는 특수 블록 169.254.0.0/16 [1]을 사용하고, IPv6 호스트는 프리픽스 fe80::/10 을 사용합니다.일반적으로, 주소는 DHCP 서버에 의해서 할당됩니다.이것은, 컴퓨터 호스트나 라우터등의 공통의 네트워크 하드웨어에 짜넣어지는 경우가 많습니다.

대부분의 IPv4 호스트는, DHCP 서버를 사용할 수 없는 경우에, 링크 로컬 어드레싱을 최후의 수단으로만 사용합니다.그 이외의 경우, IPv4 호스트는, 글로벌 또는 링크 로컬의 모든 통신에 대해서, DHCP 에 의해서 할당된 주소를 사용합니다.1 개의 이유는, IPv4 호스트가 인터페이스 마다 복수의 주소를 서포트할 필요는 없지만, 많은 경우 서포트하고 있기 때문입니다.또, 모든 IPv4 호스트가 분산명 해결(멀티캐스트 DNS 등)을 실장하고 있는 것은 아니기 때문에, 네트워크상의 다른 호스트의 자동 설정 링크 로컬주소를 검출하는 것은 어려울 가능성이 있습니다.다른 호스트의 DHCP 할당 주소를 검출하려면 분산 이름 해결 또는 이 정보가 포함된 유니캐스트 DNS 서버가 필요합니다.일부 네트워크에는 DHCP 할당 호스트 및 주소 정보로 자동 갱신되는 DNS 서버가 있습니다.

인터페이스 마다 복수의 주소를 서포트하려면 , IPv6 호스트가 필요합니다.또, 글로벌주소를 사용할 수 있는 경우에서도, 모든 IPv6 호스트는 링크 로컬주소를 설정할 필요가 있습니다.IPv6 호스트는, 라우터 애드버타이즈먼트메시지를 수신하면, 추가의 주소를 스스로 설정할 수 있기 때문에, DHCP [2]서버가 필요 없게 됩니다.

IPv4 호스트와 IPv6 호스트 모두, 자동 설정된 주소의 호스트 고유의 부분을 랜덤으로 생성할 수 있습니다.IPv6 호스트는, 통상, 최대 64 비트의 프리픽스와 출하시 할당되어 있는 48 비트의 IEEE MAC 주소로부터 취득된 64 비트의 EUI-64 를 조합합니다.MAC 주소는 EUI-64의 기본 속성인 글로벌하게 고유하다는 장점이 있습니다.IPv6 프로토콜 스택에는 다른 호스트와의 충돌을 방지하기 위해 중복 주소 탐지 기능도 포함되어 있습니다.IPv4 에서는, 이 방식을 링크 로컬주소 자동 [1]설정이라고 부릅니다.다만, Microsoft 에서는 이것을 Automatic Private IP Addressing(APIPA)[3] 또는 Internet Protocol Automatic Configuration(IPAC)이라고 부릅니다.이 기능은 적어도 Windows [4]98 이후 Windows에서 지원됩니다.

네임 서비스 검출

인터넷 프로토콜은 통신에 IP 주소를 사용하지만, 이는 인간이 사용하기 쉽지 않습니다. 특히 IPv6는 수동으로 쉽게 입력할 수 없는 매우 긴 숫자 문자열을 사용합니다.이 문제에 대처하기 위해 인터넷에서는 오랫동안 DNS를 사용해 왔습니다.DNS는 사람이 읽을 수 있는 이름을 IP 주소에 관련지을 수 있으며 계층형 데이터베이스 시스템에서 이러한 이름을 검색하기 위한 코드를 포함하고 있습니다.사용자는 example.org과 같은 도메인 이름을 입력합니다. 이 도메인 이름은 컴퓨터의 DNS 소프트웨어가 DNS 데이터베이스에서 검색하여 IP 주소를 검색한 다음 추가 [5]통신을 위해 해당 주소를 프로토콜 스택에 전달합니다.

DNS를 사용하여 주소를 검색하려면 DNS 서버의 IP 주소를 알아야 합니다.이것은, 통상, 네트워크상의 디바이스의 1개의 필드에 기존의 서버의 주소를 입력하는 것으로 실현됩니다.초기 시스템에서는 보통 모든 디바이스에서 이 기능이 필요했지만, 이 기능은 DHCP 서버나 케이블모뎀 등의 광대역디바이스에 계층 내의 1개의 레이어 위로 푸시되어 인터넷서비스 프로바이더로부터 이 정보를 수신하고 있습니다.이것에 의해, 유저측의 관리 요건이 경감되어 제로 컨피규레이션액세스의 [5]중요한 요소가 됩니다.

DNS는 네임서비스에 의해 제공되는 example.org 등의 동일한 관리 레름 내의 디바이스 그룹에 균일한 이름을 제공하기 위한 것입니다.주소를 로컬 디바이스(thirdfloorprinter.example.org 등)에 할당하려면 일반적으로 DNS 서버에 대한 관리자 권한이 필요하며 대부분의 경우 수동으로 수행됩니다.또한 기존 DNS 서버는 구성 변경에 대해 자동으로 수정되지 않을 것으로 예상됩니다.예를 들어 프린터를 한 층에서 다른 층으로 이동할 경우 로컬 DHCP [5]서버에 의해 새 IP 주소가 할당될 수 있습니다.

자동 설정의 요구에 대응하기 위해서, Microsoft 는 NetB 를 실장했습니다.IOS 네임 서비스.이 서비스의 일부는 1992년 이전에 Microsoft Windows for Workgroups 3.11에서[6] 이미 제공되었던 컴퓨터 브라우저 서비스입니다.NetBIOS Name Service 는, 1 개의 서브넷을 가지는 네트워크상에서 제로 구성으로, 주소의 시큐어한 자동 등록을 서포트하는 WINS 서버 또는 Microsoft DNS 서버와 조합해 사용할 수 있습니다.이 시스템은 대규모 기업 네트워크에서도 관리 오버헤드가 0이 아니라 작습니다.NetB 프로토콜IOS는 Linux 및 iOS에서도 사용할 수 있는 오픈[6] 프로토콜의 SMB(Server Message Block) 스위트의 일부입니다.단, 일반적으로 Windows는 이를 지원하는 Windows 클라이언트 간에 네고시에이트할 수 있는 광범위한 이른바 사투리를 지원합니다.예를 들어 서버 운영 체제 또는 이후 버전의 Windows에서 실행되는 컴퓨터 브라우저 서비스는 서버 운영 체제를 실행하지 않거나 [6]이전 버전의 Windows를 실행하지 않는 브라우저보다 이른바 마스터 브라우저로 선택됩니다.

2000년에 빌 매닝과 빌 우드콕은 멀티캐스트 도메인 네임[7] 서비스에 대해 설명했는데, 이는 애플과 마이크로소프트에 의한 구현을 낳았다.두 구현 모두 매우 유사합니다.애플의 멀티캐스트 DNS(mDNS)는 표준 트랙 제안으로 공개됩니다. RFC6762에서는 Microsoft의 링크 로컬 멀티캐스트 이름 해결(LLMNR)이 정보 RFC4795로 공개되어 있습니다.LLMNR은 Windows Vista[8] 이후의 모든 Windows 버전에 포함되어 Microsoft NetB의 대체 수단으로서 기능합니다.NetB 이후 IPv4를 통한 IOS 네임서비스 및 IPv6을 통한 치환IPv6 에서는 IOS 를 사용할 수 없습니다.Apple의 구현은 Mac OS X v10.2에서 2002년부터 Bonjour 서비스로 제공됩니다.Bonjour 구현(mDNSResponder)은 Apache 2 Open Source[9] License에서 사용할 수 있으며 Android Jelly Bean 및 이후[10] 동일한 라이센스로 제공됩니다.

NetB 중 하나의 사용Windows 상의 IOS 또는 LLMNR 서비스는 기본적으로 자동입니다.표준 DNS 클라이언트 API를 사용하면 NetB 중 하나가 사용되기 때문입니다.IOS 또는 LLMNR은 해결되는 이름(이름이 로컬 이름인지 여부), 유효한 네트워크 설정(예: 유효한 DNS 서픽스) 및 유효한 정책(LLMNR 또는 NetB)에 따라 달라집니다.IOS는 디세이블입니다만, 개발자는 개개의 주소 검색에 이러한 서비스를 바이패스 하는 것을 선택할 수 있습니다.

mDNS와 LLMNR 프로토콜은 이름 해결에 대한 접근 방식에 약간의 차이가 있습니다. mDNS는 네트워크 장치가 로컬 DNS 네임스페이스에서 도메인 이름을 선택하고 특별한 멀티캐스트 IP 주소를 사용하여 알릴 수 있도록 합니다.이로 인해 도메인 [11]로컬에 특별한 의미론이 도입되어 일부 IETF [12]구성원에 의해 문제가 있다고 생각됩니다.현재의 LLMNR 드래프트에서는 네트워크 디바이스는 임의의 도메인 이름을 선택할 수 있습니다.이것은 [13]IETF의 일부 멤버에 의해 보안 위험으로 간주됩니다.mDNS는 다음 섹션에서 설명하는 DNS-SD와 호환되지만 LLMNR은 그렇지 않습니다.[14]

서비스 검출

mDNS, LLMNR 등의 네임서비스에서는 디바이스 유형이나 상태에 대한 정보는 제공되지 않습니다.예를 들어, 근처에 있는 프린터를 찾는 사용자가 프린터에 "Bob"이라는 이름이 붙여진 경우 방해가 될 수 있습니다.서비스 디스커버리는 디바이스에 대한 추가 정보를 제공합니다.서비스 검출은 Apple의 Name Binding Protocol이나 Microsoft의 NetB와 같이 네임서비스와 조합되는 경우가 있습니다.IOS.

NetBIOS 서비스 검출

Windows 의 NetBIOS 는, 파일 공유나 프린터등의 서비스를 어드버타이즈 하기 위해서, 네트워크상의 개개의 호스트를 서포트합니다.또, 예를 들면, 네트워크 프린터를 서포트해, 프린터 디바이스와 서포트하는 관련 서비스를 공유하는 호스트로서 자신을 어드버타이즈 합니다.디바이스의 접속 방법(네트워크에 직접 접속하는 방법 또는 디바이스를 공유하는 호스트에 접속하는 방법)과 지원되는 프로토콜에 따라 다릅니다.다만, 접속하고 있는 Windows 클라이언트는, NetB 를 사용해 SSDP 또는 WSD 를 사용하는 것을 선호할 수 있습니다.IOS. NetBIOS는 PnP, 레지스트리, NetBIOS, SSDP 및 WSD용[15] 임베디드 프로바이더를 포함한 기능 디스커버리라고 불리는 보다 일반적인 디스커버리 프로세스를 구현하는 Windows 상의 프로바이더 중 하나입니다.이 프로바이더는 PnP, 레지스트리, NetBIOS, SSDP 및 WSD용 임베디드 프로바이더입니다.이 프로바이더 중 2개는 로컬 전용이며, 후자는 네트워크 디바이스의 디스커버리를 지원합니다.이들 중 어느 것도 로컬서브넷에서 사용하기 위해 설정이 필요하지 않습니다.NetBIOS 는, 종래에는 고가의 프린터에서만 서포트되고 있습니다만, Wi-Fi 또는 이더넷을 탑재한 일부 엔트리 레벨 프린터는 네이티브로 서포트되고 있기 때문에, 매우 낡은 operating system에서도 설정 없이 프린터를 사용할 수 있습니다.

WS-Discovery

Web Services Dynamic Discovery(WS-Discovery)는 로컬 네트워크에서 서비스를 찾기 위한 멀티캐스트 탐색 프로토콜을 정의하는 기술 사양입니다.TCP 및 UDP 포트 3702를 통해 동작하며 IP 멀티캐스트주소 239.255.250을 사용합니다.이름에서 알 수 있듯이 노드 간의 실제 통신은 웹 서비스 표준(특히 SOAP-over-UDP)을 사용하여 이루어집니다.Windows 에서는 Web Services for Devices 및 Devices Profile for Web Services 형식으로 지원됩니다.HP 및 Brother 프린터와 같은 많은 장치가 이를 지원합니다.

DNS 기반 서비스 검출

DNS-SD를 사용하면 클라이언트는 표준 DNS 쿼리를 사용하여 이름 있는 서비스인스턴스 목록을 검출하고 이러한 서비스를 호스트 이름으로 해결할 수 있습니다.이 사양은 기존 유니캐스트 DNS 서버 및 클라이언트소프트웨어와 호환되지만 제로 구성 환경에서는 mDNS와 동일하게 동작합니다.각 서비스 인스턴스는 DNS SRV[16] 및 DNS TXT[17] 레코드를 사용하여 기술됩니다.클라이언트는 특정 서비스 유형 이름의 DNS PTR[18] 레코드를 조회하여 해당 서비스 유형에 대해 사용 가능한 인스턴스 목록을 검출합니다.서버는 <Service> 형식의 이름을 0 이상 반환합니다.각각 SRV/TXT 레코드 쌍을 지원하는 <Domain>.SRV 레코드는 인스턴스를 제공하는 도메인 이름으로 해결되며 TXT는 서비스 고유의 설정 파라미터를 포함할 수 있습니다.그런 다음 클라이언트는 도메인 이름의 A/AAAA 레코드를 해결하고 서비스에 연결할 수 있습니다.

서비스 유형은 선착순으로 제공됩니다.서비스 유형 레지스트리는 원래 [19]DNS-SD.org에 의해 유지 관리되었지만 이후 DNS SRV [20]레코드를 위해 IANA의 레지스트리에 병합되었습니다.

역사

1997년 스튜어트 체셔는 서비스 디스커버리 [21]기능의 부족을 해결하기 위해 Apple의 성숙한 Name Binding Protocol을 IP 네트워크에 적용할 것을 제안했습니다.Chesire는 그 후 Apple에 입사하여 mDNS 및 DNS 기반 서비스 디스커버리용 IETF 초안 제안서를 작성하여 AppleTalk에서 IP 네트워킹으로의 이행을 지원했습니다.2002년, 애플은 Rendezvous(나중에 Bonjour로 개명)라는 이름으로[22] 두 프로토콜의 구현을 발표했다.10.[citation needed]1에서 사용된 SLP(Service Location Protocol)를 대체하기 위해 Mac OS X 10.2에 처음 포함되었습니다.2013년에는 RFC 6762[23] 및 RFC 6763으로 [24]비준되었습니다.

DNS-SD와 멀티캐스트

mDNS 는, 유니캐스트 DNS 와 같은 패킷을 사용해 호스트명을 해결합니다만, 호스트명은 멀티캐스트링크를 경유해 송신됩니다.각 호스트는 well-known 멀티캐스트주소로 전송된mDNS 포트 5353을 리슨하여 IP 주소로 .local hostname(A, AAAA, CNAME 등)의 DNS 레코드에 대한 요구를 해결합니다.mDNS 클라이언트는 로컬호스트명을 IP 주소로 해결할 필요가 있는 경우, 그 이름의 DNS 요구를 기존의 멀티캐스트주소로 송신합니다.대응하는 A/AAAA 레코드가 있는 컴퓨터는 IP 주소로 응답합니다.mDNS 멀티캐스트주소는 IPv4의 경우 224.0.0.251, IPv6 링크 로컬주소의 경우 ff02::fb 입니다.

DNS Service Discovery(DNS-SD; DNS 서비스 디스커버리) 요구는 mDNS를 사용하여 전송하여 제로 구성의 DNS-SD를 [25]생성할 수도 있습니다.DNS PTR, SRV, TXT 레코드를 사용하여 서비스 유형의 인스턴스, 해당 인스턴스의 도메인 이름 및 이러한 인스턴스에 연결하기 위한 옵션 설정 파라미터를 변경합니다.그러나 현재 SRV 레코드는 .local 도메인 이름으로 해결되며 mDNS는 이를 로컬 IP 주소로 해결할 수 있습니다.

지지하다

DNS-SD는 Apple 제품, 대부분의 네트워크 프린터, Debian 및 Ubuntu를 [26]포함한 많은 Linux 디스트리뷰션 및 다양한 운영체제용 서드파티 제품에서 사용됩니다.예를 들어 Safari, iChat, Messages 등 Apple에 의해 작성된 많은 OS X 네트워크 애플리케이션은 DNS-SD를 사용하여 인근 서버와 피어 투 피어 클라이언트를 찾을 수 있습니다.Windows 10 에는, JavaScript [27]를 사용해 작성된 애플리케이션의 DNS-SD 가 서포트되고 있습니다.윈도상의 대부분의 인스턴트 메시징 및 VoIP 클라이언트가 DNS-SD를 지원하도록 개개의 응용 프로그램이 오래된 버전의 운영체제시스템에 자체 지원을 포함할 수 있습니다.일부 Unix, BSD 및 Linux 배포에는 DNS-SD도 포함되어 있습니다.예를 들어 Ubuntu는 기본 배포에 mDNS/DNS-SD 구현인 Avahi를 제공합니다.

UPnP

UPnP에는 서비스 검색을 위한 몇 가지 프로토콜 구성 요소가 있습니다.

SSDP

SSDP(Simple Service Discovery Protocol)는 Windows XP 이후에 사용되는 UPnP 프로토콜입니다.SSDP는 서비스 유형 URI와 Unique Service Name(USN; 고유 서비스 이름)을 제공하는 HTTP 알림 방송을 사용합니다.서비스 유형은 유니버설 플러그 앤 플레이 운영 위원회에 의해 규제됩니다.SSDP는 많은 프린터, NAS 및 Brother와 같은 어플라이언스 제조업체에서 지원됩니다.특정 브랜드의 네트워크 기기 및 많은 SOHO 방화벽 어플라이언스에서 지원되며, 이 어플라이언스의 배후에 있는 호스트 컴퓨터가 애플리케이션을 위해 구멍을 뚫을 수 있습니다.호스트 컴퓨터와 미디어 센터 간의 미디어 교환을 용이하게 하기 위해 홈시어터 PC 시스템에서도 사용됩니다.

DLNA

DLNA(Digital Living Network Alliance)는 네트워크 디바이스 검출에 UPnP를 사용하는 또 다른 표준 스위트입니다.DLNA에는 이를 지원하는 TV, NAS 기기 등과 같은 기기를 생산하는 유명 제조업체가 많이 있습니다.DLNA는 모든 주요 운영 체제에서 지원됩니다.DLNA 서비스 디스커버리는 SSDP 위에 레이어됩니다.

IETF 표준 프로토콜을 위한 노력

SLP는 Hewlett-Packard의 네트워크 프린터, Novell 및 Sun Microsystems에서 지원됩니다.SLP는 RFC 2608 및 RFC 3224에 기술되어 있으며 Solaris와 Linux 모두에서 구현이 가능합니다.

AllJoyn

AllJoyn은 IoT 디바이스에서 풀사이즈 컴퓨터까지 다양한 디바이스를 위한 오픈 소스 소프트웨어 스택으로 네트워크(Wifi, 이더넷) 및 기타 링크(Bluetooth, ZigBee 등) 상의 디바이스를 검출 및 제어합니다.mDNS 및 HTTP over UDP 및 기타 프로토콜을 사용합니다.

표준화

RFC 2608은 서비스 취득처를 파악하기 위한 SLP 규격으로 SVROC IETF 워킹그룹에 [28]의해 1999년6월에 공개되었습니다.

RFC 3927은 네트워크 아이템의 주소 선택에 관한 표준으로 2005년 3월에 IETF Zeroconf 작업 그룹에 의해 공표되었습니다.이 그룹에는 애플, 썬,[29] 마이크로소프트의 개인들이 포함되어 있었다.

LLMNR은 IETF DNSEXT 워킹그룹에서 정식 채택을 위해 제출되었지만 합의를 얻지 못해 [30]2007년1월에 정보 RFC 4795로 발행되었습니다.

LLMNR이 인터넷 표준이 되지 않고 mDNS/DNS-SD가 LLMNR보다 훨씬 널리 사용되고 있는 것을 고려하면 IETF는 정보 RFC뿐만 아니라 mDNS/DNS-SD 사양도 [citation needed]제출하도록 요구받았습니다.

2013년 2월에 mDNS 및 DNS-SD는 Standards Track Proposals RFC 6762 및 RFC 6763으로 발행되었습니다.

보안 문제

mDNS는 지정된 DNS 서버가 아닌 네트워크 전체를 신뢰하는 유니캐스트 DNS와는 다른 신뢰 모델로 동작하기 때문에 같은 브로드캐스트도메인 내의 모든 시스템에 의한 스푸핑 공격에 취약합니다.SNMP 및 다른 많은 네트워크 관리 프로토콜과 마찬가지로 공격자가 네트워크와 [31]해당 시스템에 대한 자세한 정보를 신속하게 얻기 위해 사용할 수도 있습니다.따라서 어플리케이션은 DNS-SD/mDNS를 통해 트래픽을 검출하고 해결한 후에도 리모트호스트에 대한 트래픽(RSA, SSH 등)을 인증 및 암호화해야 합니다.LLMNR에도 같은 [32]취약성이 있습니다.

주요 구현

애플 봉쥬르

Apple로부터의 Bonjour, mDNS 및 DNS 서비스 디스커버리를 사용합니다.Mac OS X 10.1과 10.2 사이에서 애플은 선호하는 제로콘프 기술을 SLP에서 mDNS 및 DNS-SD로 변경했지만 SLP는 Mac OS X에서 계속 지원됩니다.

Apple의 mDNSResponder는 C 및[33] Java용 인터페이스를 갖추고 있으며 BSD, Apple Mac OS X, Linux, 기타 POSIX 기반 운영 체제 및 MS Windows에서 사용할 수 있습니다.Windows 의 다운로드는, Apple [34]의 Web 사이트에서 입수할 수 있습니다.

아바히

Avahi는 Linux 및 BSD용 Zeroconf 구현입니다.IPv4LL, mDNS 및 DNS-SD 를 실장합니다.대부분의 Linux 배포의 일부이며 일부 배포에는 기본적으로 설치됩니다.nss-mdns 와 함께 실행하는 경우는, 호스트명 [35]해결도 가능합니다.

Avahi는 또한 Bonjour와 과거의 mDNS 구현 Howl을 에뮬레이트하는 바이너리 호환성 라이브러리를 구현하므로 이러한 구현을 사용하도록 만들어진 소프트웨어도 에뮬레이션 인터페이스를 통해 Avahi를 활용할 수 있습니다.

MS Windows CE 5.0

Microsoft Windows CE 5.0 에는, Microsoft 독자적인 LLMNR 의 실장이 포함되어 있습니다.

시스템

Systemd는 mDNS와 LLMNR을 모두 구현합니다.systemd-resolved.

링크 로컬 IPv4 주소

호스트에 IP 주소를 할당하는 데 사용할 수 있는 DHCP 서버가 없는 경우 호스트는 자체 링크 로컬 주소를 선택할 수 있습니다.링크 로컬 주소를 사용하면 호스트는 이 링크를 통해 통신할 수 있지만 로컬에서만 통신할 수 있습니다.다른 네트워크 및 인터넷에 액세스할 수 없습니다.사용 가능한 링크 로컬 IPv4 주소의 실장은, 다음과 같습니다.

  • Apple Mac OS 및 MS Windows는 [citation needed]1998년부터 링크 로컬주소를 지원하고 있습니다.Apple은 오픈 소스 구현을 Darwin bootp 패키지로 출시했습니다.
  • Avahi는 avahi-autoipd 툴에 IPv4LL을 실장하고 있습니다.
  • 제로 컨피드 IP(zcip)[36]
  • Busy Box 는, 심플한 IPv4LL 실장을 짜넣을 수 있습니다.
  • Busybox의 포크인 Stabilbox는 [37]llad라는 이름의 약간 수정된 IPv4LL 구현을 제공합니다.
  • Zeroconf는[38] Arthur van [39]Hoff가 구현한 Simple IPv4LL 기반의 패키지입니다.

위의 실장은 모두 DHCP 클라이언트용 스탠드아론 데몬 또는 플러그인으로 링크 로컬 IP 주소만 취급합니다.또 다른 접근방식은 신규 또는 기존 DHCP 클라이언트에 지원을 포함시키는 것입니다.

  • Elvis Pfützenreuter는 uDHCP 클라이언트/[40]서버용 패치를 작성했습니다.
  • dhcpcd는[41] IPv4LL 지원을 포함한 Linux 및 BSD용 오픈소스 DHCP 클라이언트입니다.NetBSD에 표준으로 포함되어 있습니다.

ARP 응답의[42] 브로드캐스트나 기존의 네트워크 접속의 종료등의 커널의 문제는, 어느 실장에서도 해결할 수 없습니다.

「 」를 참조해 주세요.

레퍼런스

메모들

  1. ^ a b S. Cheshire; B. Aboba; E. Guttman (May 2005). Dynamic Configuration of IPv4 Link-Local Addresses. Network Working Group. doi:10.17487/RFC3927. RFC 3927.
  2. ^ S. Thomson; T. Narten; T. Jinmei (September 2007). IPv6 Stateless Address Autoconfiguration. Network Working Group. doi:10.17487/RFC4862. RFC 4862. RFC 2462를 폐지합니다.RFC 7527에 의해 갱신되었습니다.
  3. ^ "Apipa", MS Developer Network, Microsoft, archived from the original on 2017-03-18, retrieved 2008-07-05
  4. ^ "How to use automatic TCP/IP addressing without a DHCP server", Knowledge base, Microsoft
  5. ^ a b c Marshall Brain과 Stephanie Crawford, "도메인 네임 서버 구조", 구조
  6. ^ a b c "Description of the Microsoft Computer Browser Service". Microsoft Knowledge Base. Microsoft. Retrieved 1 November 2015.
  7. ^ Manning, Bill; Woodcock, Bill (August 2000), Multicast Domain Name Service, IETF
  8. ^ Microsoft TechNet Library Link-Local Multicast Name Resolution (webpage), Microsoft
  9. ^ Bonjour Licensing and Trademarks (webpage), Apple
  10. ^ Android 4.1 APIs (webpage)
  11. ^ Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard (electronic mail message), IETF, archived from the original on 2008-12-07, retrieved 2006-02-10
  12. ^ Re: Summary of the LLMNR Last Call (electronic mail message), IETF, archived from the original on 2008-12-07, retrieved 2006-02-10
  13. ^ Summary of the LLMNR Last Call (electronic mail message), IETF, archived from the original on 2008-12-07, retrieved 2005-11-11
  14. ^ More details on the differences (electronic mail message), IETF
  15. ^ "About Function Discovery". Windows Dev Center. Microsoft. Retrieved 1 November 2015.
  16. ^ RFC 2782
  17. ^ RFC 1035
  18. ^ RFC 1035
  19. ^ DNS-SD
  20. ^ Service types, DNS-SD
  21. ^ Cheshire, Stuart, Name Binding Protocol over IP (rant)[자체 인식 소스?]
  22. ^ Zero conf[자체 인식 소스?]
  23. ^ S. Cheshire; M. Krochmal (February 2013). Multicast DNS. IETF. doi:10.17487/RFC6762. RFC 6762.
  24. ^ S. Cheshire; M. Krochmal (February 2013). DNS-Based Service Discovery. IETF. doi:10.17487/RFC6763. RFC 6763.
  25. ^ S. Cheshire; M. Krochmal (February 2013). DNS-Based Service Discovery. IETFissn=2070-1721. doi:10.17487/RFC6763. RFC 6763. RFC 8553에 의해 갱신되었습니다.
  26. ^ "Ubuntu 15.10 desktop manifest". Ubuntu. Retrieved 23 October 2015.
  27. ^ "Windows.Networking.ServiceDiscovery.Dnssd namespace". Windows Dev Center. Microsoft. Retrieved 1 November 2015.
  28. ^ Service Location Protocol (svrloc) Charter, IETF
  29. ^ Zero Configuration Networking (zeroconf) Charter, IETF, archived from the original on 2004-11-01, retrieved 2004-10-28
  30. ^ DNS Extensions (dnsext) Charter, IETF, archived from the original on 2005-03-07, retrieved 2005-03-02
  31. ^ Name (MDNS) Poisoning Attacks Inside the LAN (World Wide Web log), GNU citizen, 23 January 2008
  32. ^ Lodge, David (22 September 2015). "How to get Windows to give you credentials through LLMNR". Pen Test Partners.
  33. ^ A Rendezvous with Java, Mac Dev Center, 2004-08-31
  34. ^ "Bonjour for MS Windows 1.0.4", Support, Apple
  35. ^ Lennart, nss-mdns 0.10, DE: 0 pointer
  36. ^ zcip, Source forge
  37. ^ "Stable box", Code
  38. ^ Zeroconf, AU: UTS, archived from the original on 2005-05-09, retrieved 2005-05-04
  39. ^ AVH IPv4LL (C source code), Zero conf
  40. ^ "Zeroconf in udhcpc", udhcpc (electronic mail message), Busy box, May 2005, archived from the original on 2006-02-06, retrieved 2006-03-15
  41. ^ Marples, Roy, dhcpcd (project), archived from the original (wiki) on 2010-07-12, retrieved 2011-01-07
  42. ^ "Link-Local ARP Measurements", AIR (wiki), NE: UVA

원천

  • Guttman, Erik (2001), "Autoconfiguration for IP Networking: Enabling Local Communication", IEEE Internet Computing, 5 (3): 81–86, doi:10.1109/4236.935181

외부 링크