RFC8950: IPv6 넥스트홉으로 IPv4 경로 광고하기

2계층 주소로 해석할 수 있는 프로토콜이라면 무엇이든 다음 홉으로 쓸 수 있어야 하지 않을까? 필요하면 재귀적으로 해석하면 됨.
IPv4 경로의 다음 홉이 IPv6여도 합리적이고, 반대도 안 될 이유가 없음. IPv4/IPv6 경로의 다음 홉을 MAC 주소로 지정하는 건 간단함. DNS 이름도 IPv4/IPv6 주소를 거쳐 MAC 주소로 해석할 수 있으니 권장하지는 않아도 가능함. NetBEUI 이름을 쓰겠다면 제정신인가 싶겠지만, 굳이 막지는 않겠음.

어떤 2계층을 뜻하는지부터 물어야 함. Ethernet, Token Ring, InfiniBand, ATM, Fibre Channel 중 무엇인가?
IPv4와 IPv6 모두 여러 2계층 프로토콜이 쓰이던 시기에 만들어졌음. 그래서 2계층과 3계층 주소의 대응 관계를 처리하는 별도 프로토콜이 존재하며, 흔히 ‘2.5계층’이라고도 부름. https://en.wikipedia.org/wiki/Address_Resolution_Protocol

그게 사실상 MP-BGP임! 원하는 기능은 이미 실현되어 있고, 본문에 나온 구성도 수년째 작동하고 있음.

직접 만든 SixGate를 홍보해 봄. https://billpg.com/sixgate/.
간단히 말하면 IPv6 전용 네트워크가 IPv4 전용 클라이언트를 위한 게이트웨이를 제공하고, 이를 역방향 DNS로 알리는 방식임.
RFC8950은 IPv4 연결성을 유지하면서 네트워크 코어에서 IPv4를 제거하고, SixGate는 IPv4 전용 클라이언트의 접근성을 유지하면서 서비스 측에서 IPv4를 제거함. 전자는 네트워크 운영자를, 후자는 마지막까지 남아 있는 IPv4 전용 사용자를 대상으로 함.
두 접근 모두 IPv4를 필수 요소가 아닌 선택적 호환 기능으로 바꾸려는 목표를 가짐.

R1과 R2의 인터페이스에는 IPv4가 전혀 없고 라우팅 테이블에만 IPv4 경로가 있다더니, traceroute에는 각 라우터의 IPv4 주소가 나타남. 흥미롭기는 하지만 결국 라우터에 IPv4를 설정해야 하는 것 아닌가? 내가 뭘 놓친 걸까?

ICMP 응답을 보내려면 IPv4 주소가 최소 하나는 필요함. 보통 특정 물리 인터페이스에 연결되지 않은 루프백 주소를 쓰며, 라우터의 루프백 인터페이스는 Linux 워크스테이션과 용도가 꽤 다름. 다만 모든 인터페이스에 IPv4 주소를 설정할 필요는 없으므로 링크별 서브넷 주소 계획도 불필요함.
IPv4 주소를 완전히 없앨 수도 있지만, 그러면 traceroute와 아마 경로 MTU 탐색도 작동하지 않을 테니 MTU를 일관되게 맞춰야 함. 물론 traceroute는 전혀 다른 이유로도 자주 작동하지 않음.

백본 코어를 IPv6 전용으로 운영할 수 있다면, 내부 IPv4를 외부에서 라우팅되는 IPv6로 전환해 지금의 복잡한 NAT 구성을 대체할 수 있을 듯함.
내부에서는 IPv4를 무기한 유지할 수 있으면 더 바랄 게 없겠음. 특히 오래된 ACL을 그대로 쓰는 메시 네트워크에서 유용할 것 같음. 2018년이 그리 오래전 같지는 않지만 벌써 시간이 꽤 지났음.
대부분은 직접 연결되는 경로까지 필요하지도 않고, Kubernetes 플랫폼에서 읽기 쉬운 흐름 로그만 얻으면 됨.

결국 IPv6 사용을 촉진하려는 목적 아닐까?

좀 더 정확히는 IPv4를 끄기 쉽게 만드는 것에 가까움. 백본은 단일 스택으로 관리하는 편이 훨씬 편하지만, 많은 경우 가장자리에서는 여전히 IPv4가 필요하니 이를 해결하는 또 다른 방식으로 보임.
개인적으로는 IS-IS에서 IPv4 링크 서브넷 일부를 없애고, IPv6 링크 로컬 다음 홉만으로 라우팅할 수 있어도 만족하겠음.

우리나라에서는 여러 ISP가 이미 NAT64를 지원하는 IPv6를 도입했음. 이제 CLAT 지원도 가능해졌으니, 대부분 ISP의 다음 단계는 IPv6 전용 네트워크가 될 것으로 봄.

대부분 IPv6로 구성된 네트워크에서 IPv4를 쓰기 쉽게 만드는 것임.

RFC 몇 개, IP 위에 IP를 얹는 임시방편 몇 개, 확장 기능 몇 개만 더 추가하면 드디어 도착하겠네. IPv6는 컴퓨터 과학 역사의 오점이라고 봄.
IPv4 하드웨어에서는 NAT나 IP 캡슐화처럼 작동하고, IPv6 하드웨어에서는 고속 처리 경로를 쓰기만 했어야 함. 그런데 대신 NAT64, 4over6, DS-Lite, MAP-E에 이제 BGP 임시방편까지 붙으며 계속 커지는 괴물이 됨. https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...

IPv4 하드웨어에서 NAT나 IP 캡슐화로 작동하는 방식은 이미 존재함. 완전히 별개의 개념이므로 원래 명세에 포함할 필요도 없음.
IPv6 자체에는 문제가 없음. 잘 ‘돌아가는’ 것을 바꾸기 싫어하는 성향과, IPv4 주소를 많이 소유해 영향력을 가진 이들의 변화에 대한 저항이 문제임.

이건 그런 전환 방식이 아님. 네이티브 IPv6 백본을 운영하는 ISP가 IPv4 주소를 설정하지 않고도 IPv4 트래픽을 교환하고 라우팅하기 위한 기능임.