GitHub Repo
Ollama Community Reports DNS64 Downloads Blocked After NAT64 Address Fails Redirect Check
A report from the Ollama community on October 27 says that pulling models from Hugging Face over a DNS64 network may trigger repeated retries because a CDN’s NAT64 address is classified as non-public. Public code confirms the relevant address restriction, but as of the time of review, no maintainer had confirmed the issue or issued an official fix.
An IPv6 compatibility issue has been reported in Ollama’s model download path. On October 27, developer Nicolas Grekas said that running ollama pull hf.co/... on a network using a DNS64 resolver led to a rejection after the download was redirected to the Hugging Face CDN. The terminal continued to show the manifest being pulled while the server repeatedly retried. The reported environment was Ollama 0.40.11 and Ubuntu 24.04 on WSL2, and the report included an actual error log. Issue report
The key issue is address validation for the redirect destination. In version 0.40.11, isPublicIP() limits acceptable IPv6 addresses to 2000::/3, while excluding certain special-purpose ranges. The 64:ff9b::/96 prefix used in DNS64 environments falls outside that range. The source code therefore supports the report’s assessment: an address may still be blocked even if it embeds a public IPv4 address. This is a download connection check, unrelated to model weight formats or the GPU inference core. Relevant code
These addresses have a standards basis. RFC 6052 defines well-known prefixes used for IPv4/IPv6 translation, and IANA lists 64:ff9b::/96 as globally reachable. However, registry status does not guarantee successful routing on any particular network. The RFC also specifies that this prefix must not represent non-global IPv4 addresses. Therefore, simply allowing the entire prefix would not be sufficient for security validation. RFC 6052, IANA registry
The reporter recommended extracting the embedded IPv4 address and then applying the existing IPv4 validation rules to distinguish public destinations from link-local addresses. From an engineering perspective, a follow-up fix would need to balance download compatibility with destination restrictions and add regression tests for both types of address. Deployers can first check whether logs show a NAT64 address being rejected, then verify the resolution results. The current evidence consists of one community report and a comparison with the code; it does not establish that all IPv6 networks or Hugging Face downloads are affected. As of the time of review, the issue remained open, with no fix branch or pull request listed. Status and recommendations