JavaScript is required to for searching.
탐색 링크 건너뛰기
인쇄 보기 종료
Oracle Solaris 관리: IP 서비스     Oracle Solaris 11 Information Library (한국어)
search filter icon
search icon

문서 정보

머리말

제1부TCP/IP 관리

1.  네트워크 배치 계획

2.  IPv6 주소 사용 시 고려 사항

3.  IPv4 네트워크 구성

4.  네트워크에서 IPv6 사용

5.  TCP/IP 네트워크 관리

6.  IP 터널 구성

7.  네트워크 문제 해결

8.  IPv4 참조

9.  IPv6 참조

Oracle Solaris IPv6 구현

IPv6 구성 파일

ndpd.conf 구성 파일

/etc/inet/ipaddrsel.conf 구성 파일

IPv6 관련 명령

ipaddrsel 명령

6to4relay 명령

IPv6 지원을 위한 netstat 명령 수정 사항

IPv6 지원을 위한 snoop 명령 수정 사항

IPv6 지원을 위한 route 명령 수정 사항

IPv6 지원을 위한 ping 명령 수정 사항

IPv6 지원을 위한 traceroute 명령 수정 사항

IPv6 관련 데몬

in.ndpd 데몬(Neighbor Discovery용)

in.ripngd 데몬(IPv6 경로 지정용)

inetd 데몬 및 IPv6 서비스

IPv6 Neighbor Discovery 프로토콜

Neighbor Discovery에서 제공하는 ICMP 메시지

자동 구성 프로세스

라우터 알림 획득

접두어 구성 변수

주소 고유성

이웃 요청 및 연결 불가

중복 주소 감지 알고리즘

프록시 알림

인바운드 로드 균형 조정

링크 로컬 주소 변경

ARP 및 관련 IPv4 프로토콜과 Neighbor Discovery 비교

IPv6 경로 지정

라우터 알림

라우터 알림 접두어

라우터 알림 메시지

Oracle Solaris 이름 서비스에 대한 IPv6 확장

IPv6에 대한 DNS 확장

이름 서비스 명령에 대한 변경 사항

NFS 및 RPC IPv6 지원

IPv6 Over ATM 지원

제2부DHCP

10.  DHCP 정보(개요)

11.  ISC DHCP 서비스 관리

12.  DHCP 클라이언트 구성 및 관리

13.  DHCP 명령 및 파일(참조)

제3부IP 보안

14.  IP 보안 아키텍처(개요)

15.  IPsec 구성(작업)

16.  IP 보안 아키텍처(참조)

17.  Internet Key Exchange(개요)

18.  IKE 구성(작업)

19.  Internet Key Exchange(참조)

20.  Oracle Solaris의 IP 필터(개요)

21.  IP 필터(작업)

제4부네트워크 성능

22.  통합된 로드 밸런서 개요

23.  통합 로드 밸런서 구성(작업)

24.  Virtual Router Redundancy Protocol(개요)

25.  VRRP 구성(작업)

26.  혼잡 제어 구현

제5부IPQoS(IP Quality of Service)

27.  IPQoS 소개(개요)

28.  IPQoS 사용 네트워크 계획(작업)

29.  IPQoS 구성 파일 만들기(작업)

30.  IPQoS 시작 및 유지 관리(작업)

31.  흐름 계산 및 통계 수집 사용(작업)

32.  IPQoS 세부 정보(참조)

용어집

색인

IPv6 Neighbor Discovery 프로토콜

IPv6은 RFC 2461, Neighbor Discovery for IP Version 6 (IPv6)에 설명된 Neighbor Discovery 프로토콜을 사용합니다. 주요 Neighbor Discovery 기능에 대한 개요는 System Administration Guide: IP Services의 IPv6 Neighbor Discovery Protocol Overview를 참조하십시오.

이 절에서는 Neighbor Discovery 프로토콜의 다음 기능에 대해 설명합니다.

Neighbor Discovery에서 제공하는 ICMP 메시지

Neighbor Discovery에서는 5개의 새 ICMP(Internet Control Message Protocol) 메시지를 정의합니다. 이 메시지의 목적은 다음과 같습니다.

자동 구성 프로세스

이 절에서는 자동 구성 중 인터페이스에서 수행하는 일반적인 단계에 대해 간략히 설명합니다. 자동 구성은 멀티캐스트 가능 링크에서만 수행됩니다.

  1. 예를 들어 멀티캐스트 가능 인터페이스는 노드의 시스템 시작 중에 사용으로 설정됩니다.

  2. 노드는 인터페이스에 대한 링크 로컬 주소를 생성하여 자동 구성 프로세스를 시작합니다.

    링크 로컬 주소는 인터페이스의 MAC(매체 액세스 제어) 주소에서 생성됩니다.

  3. 노드가 임시 링크 로컬 주소를 대상으로 포함하는 이웃 요청 메시지를 전송합니다.

    이 메시지의 목적은 예상 주소를 링크의 다른 노드에서 아직 사용하고 있지 않음을 확인하는 것입니다. 확인 후 링크 로컬 주소를 인터페이스에 지정할 수 있습니다.

    1. 다른 노드에서 이미 제안된 주소를 사용하고 있는 경우 주소가 이미 사용 중임을 나타내는 이웃 알림을 노드에서 반환합니다.

    2. 다른 노드에서도 동일한 주소를 사용하려고 하는 경우 해당 노드에서도 대상에 대한 이웃 요청을 전송합니다.

      이웃 요청 전송/재전송 횟수 및 연속 요청 간격은 링크별로 다릅니다. 필요한 경우 이러한 매개변수를 설정할 수 있습니다.

  4. 노드에서 예상 링크 로컬 주소가 고유하지 않다고 판단될 경우 자동 구성이 중지됩니다. 이 경우 인터페이스의 링크 로컬 주소를 수동으로 구성해야 합니다.

    간단하게 복구하려면 기본 식별자를 대체하는 대체 인터페이스 ID를 제공하면 됩니다. 그러면 고유한 새 인터페이스 ID를 사용하여 자동 구성 방식이 다시 시작될 수 있습니다.

  5. 노드에서 예상 링크 로컬 주소가 고유하다고 판단될 경우 노드가 주소를 인터페이스에 지정합니다.

    이 경우 노드가 이웃 노드와 IP 레벨로 연결됩니다. 나머지 자동 구성 단계는 호스트에 의해서만 수행됩니다.

라우터 알림 획득

자동 구성의 다음 단계는 라우터 알림을 확보하거나 라우터가 없음을 확인하는 것입니다. 라우터가 있을 경우 호스트에서 수행해야 하는 자동 구성의 유형을 지정하는 라우터 알림이 전송됩니다.

라우터는 라우터 알림을 정기적으로 전송합니다. 그러나 연속 알림 간격은 일반적으로 자동 구성을 수행하는 호스트의 대기 시간보다 깁니다. 알림을 신속하게 확보하기 위해 호스트는 하나 이상의 라우터 요청을 모든 라우터 멀티캐스트 그룹에 전송합니다.

접두어 구성 변수

라우터 알림에는 또한 Stateless 주소 자동 구성이 접두어를 생성하는 데 사용되는 정보를 포함하는 접두어 변수도 있습니다. 라우터 알림의 Stateless Address Autoconfiguration(Stateless 주소 자동 구성) 필드는 개별적으로 처리됩니다. 접두어 정보를 포함하는 한 옵션 필드 즉, Address Autoconfiguration(주소 자동 구성) 플래그는 옵션이 Stateless 자동 구성에도 적용되는지 여부를 나타냅니다. 이 옵션 필드가 적용되는 경우 추가 옵션 필드에 서브넷 접두어가 수명 값과 함께 포함됩니다. 이 값은 접두어로부터 생성된 주소가 선호 및 유효 주소로 유지되는 시간을 나타냅니다.

라우터에서는 라우터 알림을 정기적으로 생성하기 때문에 호스트는 계속 새로운 알림을 수신합니다. IPv6 지원 호스트는 각 알림에 포함된 정보를 처리합니다. 그런 다음 정보를 추가합니다. 호스트는 또한 이전 알림에서 수신된 정보를 새로 고칩니다.

주소 고유성

보안을 위해 모든 주소는 인터페이스에 지정되기 전에 고유한지 테스트해야 합니다. Stateless 자동 구성을 통해 생성되는 주소마다 상황이 다릅니다. 주소의 고유성은 주로 인터페이스 ID에서 구성되는 주소 부분에 의해 결정됩니다. 따라서 노드에서 이미 링크 로컬 주소의 고유성이 확인된 경우 추가 주소를 개별적으로 테스트할 필요가 없습니다. 주소는 동일한 인터페이스 ID에서 생성되어야 합니다. 반대로, 수동으로 확보된 모든 주소는 개별적으로 고유한지 테스트해야 합니다. 어떤 사이트의 시스템 관리자는 중복 주소 감지를 수행할 때 발생하는 오버헤드가 이점을 능가한다고 생각합니다. 이 사이트의 경우 인터페이스별 구성 플래그를 설정하여 중복 주소 감지 사용을 사용 안함으로 설정할 수 있습니다.

호스트가 라우터 알림을 기다리는 동안 링크 로컬 주소를 생성하고 고유성을 확인하면 자동 구성 프로세스를 신속하게 수행할 수 있습니다. 라우터는 라우터 요청에 대한 응답을 몇 초 동안 지연시킬 수 있습니다. 따라서 두 단계를 연속해서 수행할 경우 자동 구성을 완료하는 데 필요한 총 시간이 상당히 길어질 수 있습니다.

이웃 요청 및 연결 불가

Neighbor Discovery는 이웃 요청 메시지를 사용하여 둘 이상의 노드에 동일한 유니캐스트 주소가 지정되었는지 확인합니다. 이웃 연결 불가 감지는 이웃 오류 또는 이웃에 대한 정방향 경로 오류를 찾아냅니다. 이 감지의 경우 이웃으로 전송된 패킷이 실제로 해당 이웃에 도달했다는 긍정적인 확인이 필요합니다. 이웃 연결 불가 감지는 또한 노드의 IP 계층에서 패킷이 올바르게 처리되고 있는지도 확인합니다.

이웃 연결 불가 감지는 상위 계층 프로토콜 및 이웃 요청 메시지라는 두 소스에서 보내는 확인을 사용합니다. 가능한 경우 상위 계층 프로토콜은 연결이 진행 중이라는 긍정적인 확인을 제공합니다. 예를 들어 새 TCP 긍정 응답이 수신될 경우 이전에 전송된 데이터가 올바르게 전달되었음이 확인됩니다.

노드가 상위 계층 프로토콜로부터 긍정적인 확인을 받지 못할 경우 유니캐스트 이웃 요청 메시지를 전송합니다. 이 메시지는 다음 홉에서 연결 가능성을 확인해 주는 이웃 알림을 요청합니다. 불필요한 네트워크 트래픽을 줄이려면 노드가 활발하게 패킷을 전송하는 이웃에게만 검사 메시지를 전송해야 합니다.

중복 주소 감지 알고리즘

구성된 모든 주소가 특정 링크에서 고유한지 확인하기 위해 노드는 주소에 대해 중복 주소 감지 알고리즘을 실행합니다. 주소를 인터페이스에 지정하기 전에 노드에서 이 알고리즘을 실행해야 합니다. 중복 주소 감지 알고리즘은 모든 주소에 대해 수행됩니다.

이 절에 설명된 자동 구성 프로세스는 라우터가 아닌 호스트에만 적용됩니다. 호스트 자동 구성에는 라우터가 알리는 정보가 사용되므로 라우터를 다른 방식으로 구성해야 합니다. 그러나 라우터는 이 장에 설명된 방식을 사용하여 링크 로컬 주소를 생성합니다. 또한 라우터는 주소를 인터페이스에 지정하기 전에 모든 주소에 대한 중복 주소 감지 알고리즘을 성공적으로 전달합니다.

프록시 알림

대상 주소 대신 패킷을 수락하는 라우터는 비대체 이웃 알림을 발행할 수 있습니다. 라우터는 이웃 요청에 응답할 수 없는 대상 주소에 대한 패킷을 수락할 수 있습니다. 현재는 프록시 사용이 지정되어 있지 않습니다. 그러나 프록시 알림을 사용하면 오프 링크가 이동된 모바일 노드와 같은 경우를 잠재적으로 처리할 수 있습니다. 프록시 사용은 이 프로토콜을 구현하는 노드를 처리하는 일반적인 방식은 아닙니다.

인바운드 로드 균형 조정

복제된 인터페이스를 포함하는 노드의 경우 동일한 링크의 여러 네트워크 인터페이스에서 패킷 수신 로드에 대한 균형을 조정해야 합니다. 이러한 노드에서는 여러 개의 링크 로컬 주소가 동일한 인터페이스에 지정되어 있습니다. 예를 들어 한 개의 네트워크 드라이버가 여러 네트워크 인터페이스를 링크 로컬 주소가 여러 개인 하나의 논리적 인터페이스로 표시할 수 있습니다.

로드 균형 조정은 라우터가 소스 링크 로컬 주소를 라우터 알림 패킷에서 생략하는 방식으로 처리됩니다. 따라서 이웃은 이웃 요청 메시지를 사용하여 라우터의 링크 로컬 주소를 알아내야 합니다. 그러면 요청을 발행한 주체에 따라 달라지는 링크 로컬 주소가 반환된 이웃 알림 메시지에 포함될 수 있습니다.

링크 로컬 주소 변경

링크 로컬 주소가 변경되었음을 알고 있는 노드는 요청되지 않은 멀티캐스트 이웃 알림 패킷을 전송할 수 있습니다. 이 노드의 경우 멀티캐스트 패킷을 모든 노드에 전송하여 잘못된 캐시된 링크 로컬 주소를 업데이트할 수 있습니다. 요청되지 않은 알림은 성능 향상을 위한 목적으로만 전송됩니다. 이웃 연결 불가 감지 알고리즘은 지연이 다소 길어지더라도 모든 노드가 새로운 주소를 안정적으로 검색할 수 있도록 해줍니다.

ARP 및 관련 IPv4 프로토콜과 Neighbor Discovery 비교

IPv6 Neighbor Discovery 프로토콜의 기능은 IPv4 프로토콜의 ARP(Address Resolution Protocol), ICMP(Internet Control Message Protocol) 라우터 검색 및 ICMP 재지정을 결합한 것입니다. IPv4에는 이웃 연결 불가 감지에 대해 일반적으로 합의된 프로토콜이나 방식이 없습니다. 그러나 호스트 요구 사항에 사용 불능 게이트웨이 감지에 대한 알고리즘이 지정되어 있습니다. 사용 불능 게이트웨이 감지는 이웃 연결 불가 감지를 통해 해결되는 문제의 일부입니다.

다음은 Neighbor Discovery 프로토콜을 관련 IPv4 프로토콜 세트와 비교한 목록입니다.