멀티 호밍은 ipv6과 어떻게 작동합니까?

IPv4와 IPv6의 멀티 호밍의 차이점은 무엇입니까?

기업은 IPv4와 마찬가지로 BGP를 통해 여러 업스트림 공급자에게 광고 할 수있는 RIR / LIR에서 공급자 독립적 인 IPv6 주소 공간을 요청할 수 있습니까?

공급자 독립적 인 IPv6 할당을 요청하는 규칙이 모든 RIR에 대해 동일합니까?

실제로 LIR을 통해 로컬 RIR에 PI (공급자 독립) 할당을 요청할 수 있습니다. IPv6 주소 공간 블록 라우팅은 IPv4 주소 공간 블록과 같은 방식으로 BGP를 사용하여 수행됩니다. 블록은 조금 더 큽니다 :-)

IPv4의 경우, ISP가 / 24보다 작은 블록 (따라서 / 25 이상의 접두사)을 라우팅하지 않는 것이 일반적입니다. IPv6에서 요즘 일반적인 제한은 / 48로 보입니다.

모든 RIR에는 고유 한 정책이 있으므로 해당 지역의 RIR을 확인하여 세부 사항을 확인해야합니다. RIPE NCC 서비스 지역에있는 경우 질문에 대한 답변을 드릴 수 있습니다.

이는 여러 비즈니스가 시도하는 접근법 인 것 같지만 IPv6 디자인의 목표는 동료 규모의 회사 (예 : Google)를 제외한 모든 회사가 공급자 독립적 인 블록을 가져와 글로벌 라우팅 테이블의 크기를 줄이는 것을 방지하는 것이 었습니다. .

IPv6 호스트는 인터페이스 당 여러 주소를 처리 할 수 ​​있어야하며 엔터프라이즈의 송신 라우터가 업 링크를 통해 사용 가능한 블록 (일반적으로 / 48 또는 / 56) 및 라우터에 대해 각각 광고하도록함으로써 멀티 호밍이 작동하도록 의도했습니다. 접두사 독립 서브넷 번호에 전역 접두사 (일반적으로 DHCPv6을 통해 읽음)를 추가합니다. 라우터 알림에서 정보를 얻는 호스트의 마이그레이션은 관리자의 개입없이 점진적으로 수행 할 수 있습니다.

불행히도 실제 배포에서이 모델은 AAAA레코드 에 DNS 레코드 (리터럴 IP 주소 만 저장)를 채택함으로써 방해를 받아 A6주소 구성 요소 (예 : 전사적 48 비트 접두사 부분 및 80- 독립적으로 관리되고 업데이트 될 수있는 비트 호스트 부분; 초기 라우터 소프트웨어 버전에서 비정상적인 접두사 기반 주소 지원으로 인해 다중 주소 모델이 PI + BGP 모델에 대한 견인력을 얻지 못할 것 같습니다. 초기 RFC는 비 전송 조직에 PI 블록을 할당하는 것을 권장하지 않지만 RFC6177 이상에서는이 권장 사항이 철회 된 것 같습니다.

IPv6 제안자의 원래 아이디어는 조직이 다중 주소를 허용하기 위해 여러 주소 블록을 병렬로 실행한다는 것입니다.

그러나 실제로 이것은 여러 가지 이유로 문제가됩니다.

1. 이러한 설정에서 엔드 호스트가 소스 IP를 선택할 때 근본적으로 라우팅 결정을 내리지 만 엔드 호스트는 라우팅 결정을하기에 적합하지 않습니다.
2. IP가 여러 곳에 저장되어 있으므로 IP 접두사를 추가하거나 제거하기가 어려운 경우가 많습니다. 이를 돕기 위해 DNS에 대한 확장이 제안되었지만 DNS 시스템에 많은 복잡성과 취약성이 추가되어 결국 "역사적"으로 포기되었습니다.
3. 한 공급자에 대한 연결이 예기치 않게 중단되는 경우를 실제로 처리하지는 않습니다.
4. 라우터는 소스 IP를 기반으로 라우팅 결정을 내려야합니다. 일부 라우터는이 작업을 수행 할 수 있지만 일반 라우팅이 아닌 고급 기능입니다.

결국 조직이 그 헛소리를 참지 않을 것이라는 사실을 깨닫게 될 것 같습니다. IPv6을 채택하려면 IPv4 PI 공간과 비슷한 조건으로 IPv6 PI 공간을 제공해야했습니다.

정확한 정확한 정책은 RIR마다 약간 씩 다르지만 일반적으로 멀티 홈에 대한 의도를 입증 할 수 있으면 너무 많은 어려움없이 PI 공간을 확보 할 수 있어야합니다.

이것이 장기적으로 어떻게 진행되는지 보는 것이 흥미로울 것입니다. IPv6 NAT를 강력하게 권장하지 않으면 중소 기업이 natted v4에서 공급자 독립적 인 IPv6으로 이동함에 따라 라우팅 테이블 크기가 급격히 증가하는 것을 볼 수 있습니다.