Opened 14 years ago
Last modified 10 years ago
#22 new defect
Check IPv6 handling
Reported by: | Kris Deugau | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 3.0 |
Version: | Keywords: | ||
Cc: |
Description
Current code supports IPv6, more or less, but some segments still assume v4 and result in some strange thing happening.
Change History (9)
comment:1 by , 14 years ago
Milestone: | → 3.0 |
---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
(In [453]) /trunk
Only one lurking bug found in a modest scan for IPv6 problems;
rWHOIS export didn't export since it expected subnets with mask
lengths /30 or shorter. SQL fixed so that v4 blocks will still
only drill down to /30, but v6 blocks will display down to /56
(nominally the minimum size actual netblock an ISP should allocate
to a customer). See #22.
comment:4 by , 14 years ago
Not strictly a bug, but existing IP pool and static IP types will not work at all well for IPv6 - considering a nominal single customer assignment is supposed to be a /64 so devices can autoconfigure...
For v6, do not autopopulate poolips table, just assume there's space, and show how many "recorded hosts in pool" instead. v6 implies very sparse usage of complete 128-bit addresses.
Could also treat /64 as equivalent to current /32, and only fill the pool with "addresses" at the 64-bit boundary; means pools would/could(/should?) be /62 or larger.
comment:6 by , 12 years ago
comment:7 by , 11 years ago
Milestone: | 3.0 → 2.8 |
---|
comment:8 by , 11 years ago
Milestone: | 2.8 → 3.0 |
---|
Bumping back to 3.0; new allocation structures are required for the deeper IPv6 allocation aggregation, and pool handling as previously commented still needs to be implemented. IPv6 is otherwise supported as well as IPv4.
comment:9 by , 10 years ago
(In [690]) /trunk
Head off a potential point of confusion by blocking expandable template
patterns in reverse DNS for IPv6. At best they'll never work the same
way as for IPv4 simply due to the scale of the address space. Could be
considered for /120 and smaller allocations for network infrastructure
someday, maybe. See #1 and #22.
A few best-practices documents recommend allowing for expansion of customer allocations, see #24.