이 둘의 차이점을 이해하는 가장 쉬운 방법은 접두사의 계층 적 특성을 보여주는 예를 이용하는 것입니다.

예제 계층

ISP는 RIR (Regional Internet Registry) 의 접두사를 할당 받았으며 ,이 예에서는로 가정 2001:db8::/32합니다. 이 접두사는 ISP가 BGP를 통해 동료 ISP와 공유해야한다는 점에서 고객에게 전달되는 접두사와 다릅니다.

ISP는 이제 고객에게 접두사를 할당하려고합니다. 먼저 2001:db8:0:1::/64ISP 라우터를 CPE (고객-구내 장비) 라우터에 연결하는 링크에 할당 합니다. 이것은이다 링크 접두사 가 링크에 할당되기 때문이다. 일반적인 권장 사항으로 IPv6의 모든 링크 접두사는이어야합니다 /64.

ISP 라우터는이 접두사를 알리는 라우터 알림을 보내며 CPE는 SLAAC를 사용하여 내부 인터페이스에서 ISP 라우터를 가리키는 외부 인터페이스의 주소를 구성합니다 /64. 외부 인터페이스가 IP 주소를 가지고 있다고 가정 해 봅시다 2001:db8:0:1:42:ff:fe00:42/64(이 표기법 /64에는 링크 접두어의 길이를 알려주기 위해 포함되어 있지만 생략 할 수도 있습니다).

이 링크 접두어는 CPE 라우터가 다른 세계와 통신하기에 충분하지만 CPE 라우터가 내부 인터페이스에 연결된 LAN의 클라이언트를 지원하는 데 도움이되지는 않습니다. CPE 라우터에는이 CPE 라우터를 통해 라우팅되는 LAN 용 접두사가 필요하므로이를 라우팅 접두사 라고 합니다 .

라우팅 된 접두사는 정적으로 또는 DHCPv6을 통해 구성 할 수 있습니다. CPE 라우터가 ISP가 제공 한 DHCPv6 서버와 접두사 길이를 협상하는 방법에 대한 자세한 내용은이 답변의 범위를 벗어납니다. 접두사 위임을 검색하면 이에 대한 자세한 내용을 알 수 있습니다. 라우팅 된 접두사가 결국이라고 가정 해 봅시다 2001:db8:1::/48. ISP 라우터 2001:db8:1::/48에서 게이트웨이를 통해 라우팅되어야 함을 나타내는 라우팅 테이블 항목이 생성 됩니다 2001:db8:0:1:42:ff:fe00:42. 이 라우팅 테이블 항목은 라우팅 된 접두사의 정의 기능입니다.

CPE 라우터에는 여러 내부 LAN이 /48있을 수 있으며 /64각 LAN에 링크 접두사를 할당 할 수 있습니다 . LAN 중 하나가 2001:db8:1:1::/64링크 접두어 로 할당되었다고 가정하면 이 링크의 노드는 2001:db8:1:1::42:ff:fe00:43SLAAC를 통해 주소 를 얻을 수 있습니다 . 해당 노드는 무선 인터페이스의 접두사가 필요한 무선 라우터 일 수 있습니다. CPE 2001:db8:1:100::/60는 무선 라우터의 라우팅 접두사로 할당 할 수 있고 무선 라우터 2001:db8:1:100::/64는 무선 인터페이스의 링크 접두사로 할당 할 수 있습니다.

이제 그러한 설정에서 우리가 가진 것은 접두사의 계층입니다. 다음은 모두 서로 중첩되어 있습니다.

• 2001:db8::/32 BGP 발표 접두사
• 2001:db8:1::/48 라우팅 된 접두사
• 2001:db8:1:100::/60 라우팅 된 접두사
• 2001:db8:1:100::/64 링크 접두사

패킷은 실제로 어떻게 처리됩니까?

ISP 라우터가 패킷을 수신 할 때 2001:db8:0:1::/64 링크 접두사 인 에서 호스트의 MAC 주소를 찾기 위해 인접 장치 검색을 수행합니다 /64.

이런 식으로 ISP 라우터는 링크 접두사 내의 모든 IP 주소에 대해 별도의 인접 캐시 항목이 필요합니다.

ISP 라우터는 2001:db8:1::/48라우팅 된 접두사 인 패킷을 수신하면 인접 장치 검색을 수행하여 게이트웨이의 MAC 주소를 찾습니다 2001:db8:0:1:42:ff:fe00:42.

이런 방식으로 ISP 라우터는 라우팅 된 접두사 내의 모든 IP 주소로 패킷을 라우팅하기 위해 게이트웨이에 대한 단일 인접 캐시 항목 만 필요합니다. 이 속성은 인터넷의 확장성에 중요합니다.

라우팅 된 접두어 부족 문제 해결

간혹 고객은 링크 접두사 만 제공하고 라우팅 접두사는 제공하지 않는 ISP를 사용하는 경우가 있습니다. 이러한 상황에서 고객은 링크 접두사의 특정 하위 범위 내에서 모든 IP 주소에 대한 이웃 검색에 응답하는 데몬을 설치할 수 있습니다. 이는 해당 접두사를 라우팅 된 접두사로 구성하는 것과 비슷한 효과가 있습니다. 그러나 몇 가지 단점이 있습니다.

• 일반적으로 라우팅 된 접두어는보다 짧아야 /64하지만 이웃 검색 요청에 응답하는 데몬은 “라우트 된”접두사 만 만들 수 있습니다 /64.
• IP 주소가 ISP 라우터의 인접 캐시에 없을 때마다 추가 왕복으로 인해 대기 시간이 약간 증가합니다.
• 훨씬 더 빈번한 이웃 발견이 필요하기 때문에 ISP 라우터의로드가 증가합니다. ISP 라우터가 순전히 하드웨어에서 이미 알려진 대상 접두사로 패킷을 전달할 가능성은 있지만 소프트웨어에서 이웃 검색이 수행 될 것입니다.
• ISP 라우터에서 메모리 소비가 증가합니다. ISP가 각 고객에게 라우팅 된 접두사를 할당하면 고객 당 하나의 인접 캐시 항목 만 있으면 쉽게 벗어날 수 있습니다. 그러나 이웃 응답자 데몬을 사용하면 고객 당 수천 개의 항목으로 바뀔 수 있습니다.

ISP 라우터의 처리 오버 헤드는 중요한 문제 일 수 있습니다. 일부 라우터는 이웃 검색을 필요로하는 많은 패킷을 처리하는 데 너무 나빠서 실제 DoS 공격으로 바뀌 었으며 더 긴 링크 접두사 ( /120– 127범위 내)를 이러한 DoS 공격의 해결 방법으로 사용했습니다.

라우터가 DoS 공격에 취약하지 않더라도 위에서 설명한 해결 방법을 사용할 때 인접 캐시 항목에 필요한 메모리는 라우팅 된 접두사의 IP 주소보다 ISP에 훨씬 비싸므로 이유가 거의 없습니다 ISP가 라우팅 된 접두사를 전달하는 것을 거부합니다.

지점 간 링크와 관련된 특수 사례

지점 간 링크 (예 : 6in4 터널 및 PPP 링크)에서는 이웃 검색이 필요하지 않습니다. 이러한 링크에서 패킷을 보내는 방향은 한 가지뿐이므로 패킷을 보내기 전에 하드웨어 주소를 찾을 필요가 없습니다.

이는 인접 링크의 오버 헤드가 그러한 링크에서 문제가되지 않음을 의미합니다. 따라서 끝점에 누가 어떤 주소를 사용하는지에 대한 동의가있는 한 지점 간 링크의 한쪽 끝에서 많은 주소를 사용하는 것은 문제가되지 않습니다. 이웃 검색이 없다는 것은 중복 주소 감지가 없다는 것을 의미하므로 두 엔드 포인트가 예상 한대로 작동하지 않는 동일한 주소를 사용하려고하면 (애니 캐스트 주소로 동작 할 것으로 예상하지 않는 한).

포인트-투-포인트 링크에 ​​대해 명심해야 할 한 가지주의 사항이 있습니다. 각 엔드 포인트는 링크 자체에 할당되지 않은 링크의 모든 주소가 다른 쪽 끝에 할당되었다고 가정합니다. 이는 지점 간 링크에서 사용되지 않는 주소가 라우팅 루프를 트리거하기 쉽다는 것을 의미합니다. 엔드 포인트는 패킷을 수신 한 노드로 직접 다시 보내지 않는 엔드 포인트를 통해 이러한 라우팅 루프 (및 여러 다른 라우팅 루프 사례)를 피할 수 있습니다. 따라서 지점 간 링크에서 수신 한 패킷은 하나의 엔드 포인트가이 권한을 얻는 한 라우팅 루프가 끊어지면 동일한 지점 간 링크를 통해 다시 전송되지 않아야합니다. 이더넷의 사이드 노드로서 패킷을 수신하여 동일한 링크로 다시 전달하는 것이 유효하지만, 수신 된 곳에서 동일한 MAC 주소로 다시 전달되는 경우에는 피하는 것이 좋습니다.

지점 간 링크의 대부분의 주소는 이웃 검색없이 링크의 다른 쪽 끝으로 전달되기 때문에 라우팅 된 접두사와 매우 유사합니다. 예를 들어 ISP가 2001 : db8 : 42 :: / 64에 주소 2001 : db8 : 42 :: 1 및 2001 : db8 : 42 :: 2가 할당 된 끝점과의 지점 간 링크에 2001 : db8 : 42 :: / 64를 할당 한 경우 대부분의 주소로 패킷을 보냅니다. 2001 : db8 : 42 :: / 64는 2001 : db8 : 42 :: 2를 게이트웨이로 사용하여 라우팅 된 접두사 인 경우와 동일한 방식으로 ISP에서 고객에게 전달됩니다.

이것은 특정 해킹이 가능하다는 것을 의미합니다. CPE에서 실제로 2001 : db8 : 42 :: / 64를 LAN의 링크 접두어로 구성 할 수 있습니다. CPE가 특정 대상이있는 두 링크 중 어느 링크에 있는지 알기 위해서는 ISP를 향한 점대 점 링크의 실제 구성을 2001 : db8 : 42 :: / 126으로 변경해야합니다. 이것은 모두 하나의 사소한 예외로 작동하며, LAN의 호스트는 2001 년 4 개의 IP 주소와 통신 할 수 없습니다 : db8 : 42 :: / 126. 그들은 어쨌든 그들과 통신 할 필요가 없었기 때문에 큰 문제는 아닙니다. 그러나이 핵을 사용하지 않는 것이 좋습니다. 올바른 구성은 ISP로부터 라우팅 된 접두사를 얻는 것입니다.

주소를 저장하는 또 다른 해킹은 라우팅 된 접두사에 대한 전역 주소 만 할당하고 지점 간 링크에 RFC 4193 주소를 사용하는 것입니다. 그러나 이것은 존재하지 않는 문제를 해결하기 위해 여전히 몇 가지 단점이 있기 때문에 바보 같은 해킹입니다.

포인트-포인트 링크에 ​​접두사를 전혀 할당하지 않을 수도 있습니다. 각 엔드 포인트에 글로벌 주소가있는 다른 인터페이스가 있으면 지점 간 링크에서 통신 할 때 다른 인터페이스에 지정된 주소를 사용할 수 있습니다. 이 접근 방식의 단점을 모릅니다. 따라서 지점 간 링크에 대한이 접근 방식을 사용하면 네트워크 구성이 단순화되어 자유롭게 사용할 수 있지만 주소를 저장하기위한 수단으로 사용하지 마십시오.

라우팅 된 접두사 사용 사례

• 첫 번째 예에서와 같이 계층 적 라우팅 은 라우팅 된 접두사가 설계된 것입니다.
• VPN / 터널 은 접두사가 필요한 라우터 계층에 다른 계층을 추가합니다. 실제 하드웨어가 아니라 가상이지만 주소 지정 측면에서 다르지 않으며 실제 링크처럼 라우팅 된 접두사가 필요합니다.
• 호스트에 많은 주소 할당 . 단일 호스트에 많은 주소를 할당하는 사용 사례가 있습니다. 일부 주소의 경우 주소가있는 각 캐시 항목 및 여러 개의 캐시 항목에 대해 이웃 검색을 사용하여 간단히 주소를 지정하고 처리 할 수 ​​있습니다. 그러나 수천 개의 주소가 필요한 경우 라우팅 된 접두사가 더 좋습니다.

마지막 요점의 더 자세한 예는 DNS 되풀이입니다. IPv4와의 싸움이 끝날 때까지 DNSSEC가 많은 관심을 끌지 못하기 때문에 DNS 중독에 대한 다른 조치가 필요합니다. 쿼리에 최대한 많은 엔트로피를 가져 오려고 노력했습니다. ID 및 포트 번호는 최대 32 비트의 엔트로피를 보유 할 수 있으며, 분석 할 도메인 이름에 대문자와 소문자가 혼합 된 경우 요청에 다른 비트가 보유 될 수 있습니다. 이 방법으로 총 48 비트 이상이되는 경우는 거의 없습니다. /64DNS recursor에 full 을 할당 하면 엔트로피를 한 번에 64 비트 씩 증가시킬 수 있으며 이는 다른 모든 노력을 합한 것보다 더 많은 것입니다.

---

답변