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 位址遭拒，再確認解析結果；目前證據仍是一份社群回報與程式碼對照，不能推論所有 IPv6 網路或 Hugging Face 下載均受影響。截至查核時，議題仍開放，未列出修補分支或拉取請求。處理狀態與建議