GitHub Repo
OllamaコミュニティがDNS64環境でのダウンロード障害を報告、NAT64アドレスがリダイレクト検査で拒否
10月27日のOllamaコミュニティの報告によると、DNS64ネットワークからHugging Faceのモデルを取得する際、CDNのNAT64アドレスが非公開アドレスと判定され、再試行が続く場合がある。公開コードから関連するアドレス制限は確認できるが、確認時点でメンテナーによる確認や正式な修正はない。
Ollamaのモデルダウンロード経路で、IPv6互換性に関する問題が報告された。10月27日、開発者のNicolas Grekas氏は、DNS64リゾルバーを使用するネットワークで ollama pull hf.co/... を実行すると、ダウンロードがHugging Face CDNへリダイレクトされた後に拒否され、ターミナルにはmanifestの取得中と表示され続け、サーバー側では再試行が繰り返されると報告した。報告された環境はOllama 0.40.11、WSL2上のUbuntu 24.04で、実際のエラーログも添付されている。問題報告
問題の焦点は、リダイレクト先アドレスの検証にある。0.40.11の isPublicIP() は、受け入れるIPv6アドレスを 2000::/3 に限定し、さらに特定用途のネットワーク範囲を除外している。DNS64環境で使われる 64:ff9b::/96 はこの範囲に含まれない。そのため、内包されているのがグローバルIPv4アドレスであっても拒否される可能性があるという報告者の見立ては、ソースコードと整合する。これはダウンロード接続の検査に関する問題であり、モデルの重み形式やGPU推論コアとは無関係だ。関連コード
この種のアドレスには標準上の根拠がある。RFC 6052はIPv4とIPv6の変換に使う既知のプレフィックスを定義しており、IANAも 64:ff9b::/96 をグローバル到達可能として登録している。ただし、登録されているからといって、特定のネットワークでルーティングが成功するとは限らない。またRFCは、このプレフィックスを非グローバルIPv4アドレスの表現に使ってはならないと定めている。したがって、プレフィックス全体を単純に許可するだけでは、安全な検証として不十分だ。RFC 6052、IANA登録表
報告者は、内包されたIPv4アドレスを取り出し、IPv4の検証ルールを適用して、グローバルな接続先とリンクローカルアドレスを区別する方法を提案している。エンジニアリング上の推論として、今後の修正ではダウンロードの互換性と接続先の制限を両立させ、両種類のアドレスを対象とした回帰テストを追加する必要がある。運用者はまず、ログにNAT64アドレスの拒否が記録されているかを確認し、その後、名前解決の結果を確認できる。現時点の根拠はコミュニティ報告1件とコードの照合に限られ、すべてのIPv6ネットワークやHugging Faceからのダウンロードに影響すると推論することはできない。確認時点でIssueはオープンのままで、修正ブランチやプルリクエストは記載されていない。対応状況と提案