IPv6CP가 협상하는 것과 여전히 프리픽스가 필요한 이유
PPP 인터페이스의 링크 로컬 주소는 설정 단계일 뿐 IPv6 접근이 아닙니다. 식별자 교환과 프리픽스, 경로, 클라이언트 통합을 분리해서 보세요.
PPP 인터페이스에서 IPv6가 올라오고 링크 로컬 주소가 나타나면 변경이 끝났다고 선언합니다. 그런데 아무것도 라우팅되지 않고 전역 주소도 없으며, 인터페이스는 설정된 것처럼 보이는데 공인 목적지로의 테스트만 실패합니다. 링크는 올라왔지만 네트워크는 올라오지 않았습니다. 아래 네 가지 점검을 순서대로 수행하고 차이를 설명하는 항목에서 멈추세요.
링크 로컬 주소가 실제로 증명하는 것
IPv6CP는 PPP 링크에서 IPv6를 올리고 각 측에 인터페이스 식별자를 협상합니다. 그 식별자는 링크 로컬 주소를 만들며, 이는 링크 너머 상대와 이야기하기에는 충분하고 다른 무엇에도 도달하기에는 부족합니다. 주소는 링크가 IPv6를 쓸 준비가 되었음을 증명할 뿐, 상대 뒤의 네트워크에 대해서는 아무것도 증명하지 않습니다. 이를 접근 주소로 읽는 것이 이런 조사의 대부분을 시작하게 만드는 실수입니다.
아래 네 질문은 링크 계층이 결정하는 것과 서비스가 제공해야 하는 것을 구분합니다. 앞 질문이 열려 있는 동안 뒤 질문에는 답할 수 없으므로 순서대로 답하세요.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
프리픽스는 어디에서 와야 하는가
전역 주소에는 라우터 광고, 위임된 프리픽스, DHCPv6, 정적 설정 같은 어딘가의 프리픽스가 필요합니다. IPv6CP는 프리픽스를 나르지 않으며 링크에서 아무리 기다려도 생기지 않습니다. RFC 5072는 IPv6CP를 다른 IPv6 프로토콜이 링크에서 동작하기 전에 실행되는 설정 단계, 즉 링크를 준비하는 일이지 네트워크에 번호를 부여하는 일이 아니라고 규정합니다. 프리픽스를 제공하면 인터페이스는 존재만 하는 대신 트래픽을 나르기 시작합니다.
라우터 광고는 LAN에서는 흔한 답이지만, 클라이언트가 요청을 보내고 응답도 받아들여야 하는 지점 간 터널에서는 덜 신뢰할 만합니다. 어떤 터널 클라이언트는 둘 다 하지 않습니다. 서버가 보내야 하는지 결정하기 전에 클라이언트가 무엇을 받아들일지 확인하세요.
같은 프리픽스는 반대편에서도 도달 가능해야 합니다. 전역 주소는 있지만 돌아오는 경로가 없는 클라이언트는 설정된 것이지 연결된 것이 아닙니다.
경로는 별도의 약속이다
주소가 있어도 클라이언트는 어떤 목적지가 터널에 속하는지 알아야 하고, 서버는 그 목적지로 돌아오는 경로가 필요합니다. 두 곳에서 내리는 두 가지 결정입니다. 모든 IPv6 트래픽을 나르는 터널에는 클라이언트의 기본 경로와 서버의 반환 경로가 필요합니다. 분할 터널은 양쪽이 같은 프리픽스 목록에 합의해야 하며, 합의가 없으면 트래픽은 나간 채로 돌아오지 않습니다.
무엇이든 설정하기 전에 목록을 적으세요. 계획이 터널을 지나는 것은 회사 프리픽스뿐이라고 말한다면, 클라이언트에는 기본 IPv6 경로를 두지 말고 서버도 이를 광고하지 말아야 합니다.
나머지는 클라이언트 통합이 결정한다
일부 터널 클라이언트는 IPv6를 명시적으로 설정합니다. 예를 들어 Apple의 Network Extension은 터널용 주소, 프리픽스, 경로 집합을 받으므로 이를 쓰는 응용 프로그램은 이더넷 방식의 공지를 기다리지 않습니다. 다른 클라이언트는 링크로 도착하는 라우터 광고에 의존합니다. 두 모델 모두 정당하며 서로 다른 서버 동작을 요구하므로, 잘못 고르면 아무도 보내지 않는 메시지를 영원히 기다리는 클라이언트가 됩니다. 서버를 바꾸기 전에 모델을 파악하세요.
ppp0 같은 오래된 인터페이스 이름은 오늘 동작하는 스택에 대해 아무것도 증명하지 않습니다. 요즘 클라이언트는 PPP 인터페이스 대신 패킷 터널 API를 쓸 수 있으며, 과거 연결처럼 동작한다고 가정하는 것이 동작하는 설계를 깨뜨리는 방법입니다. 인터페이스 이름이 아니라 클라이언트 버전과 프로비저닝 방식을 물으세요.
클라이언트에 필요한 계획을 쓰라
완전한 설명은 클라이언트가 어떤 주소를 가지는지, 터널이 어떤 목적지를 나를지, 네트워크가 응답을 어떻게 돌려보내는지의 세 가지를 다룹니다. 링크 로컬 주소는 그중 어느 것에도 답하지 못하고, 받아들인 광고는 하나의 일부에만 답합니다. 초록 표시를 그대로 받아들이지 말고 항목별로 따로 확인하세요. 그런 다음 각 답을 어떤 메커니즘이 제공했는지 기록하면, 그 기록이 다음 IPv6 보고를 두 분짜리 점검으로 바꿉니다.
기록은 서비스 문서와 함께 보관하고 클라이언트가 바뀌면 갱신하세요. PPP 클라이언트에 맞았던 계획이 같은 서비스의 패킷 터널 클라이언트에는 틀릴 수 있습니다. 네 질문은 그대로이고 답만 달라집니다.