Opened 14 years ago

Last modified 9 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 Kris Deugau, 14 years ago

Milestone: → 3.0

comment:2 by Kris Deugau, 14 years ago

A few best-practices documents recommend allowing for expansion of customer allocations, see #24.

comment:3 by Kris Deugau, 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 Kris Deugau, 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:5 by Kris Deugau, 11 years ago

(In [543]) /trunk

Fix minor IPv4-ism in admin allocate. See #22.

comment:6 by Kris Deugau, 11 years ago

(In [549]) /branches/stable

Minimal server-meltdown-prevention patch for IPv6; create the
block but don't populate IP pools. See #22, sort of.

comment:7 by Kris Deugau, 11 years ago

Milestone: 3.0 → 2.8

comment:8 by Kris Deugau, 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 Kris Deugau, 9 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.

Note: See TracTickets for help on using tickets.