Repository navigation
#native results in incorrect mask, breaking #prefix #27
Description
Activity
#34 fixed
#native.
#31 fixed#ipv4_mapped.#ipv4_compatstill returns an inconsistent mask. As it's been deprecated (in IETF and in this library), I don't think we need to maintain it.
However, this violation in object invariant ("the netmask must be consecutive 1s followed by consecutive 0s") may cause other problems and I'd propose fixing it like#ipv4_mappedif we cannot remove#ipv4_compatnow.Reacted by Taketo Takashima#34 fixed
#native. #31 fixed#ipv4_mapped.#ipv4_compatstill returns an inconsistent mask. As it's been deprecated (in IETF and in this library), I don't think we need to maintain it. However, this violation in object invariant ("the netmask must be consecutive 1s followed by consecutive 0s") may cause other problems and I'd propose fixing it like#ipv4_mappedif we cannot remove#ipv4_compatnow.#ipv4_mappedwas also fixed in #86.The current behavior is as follows:
IPAddr.new('1.2.3.4/31').ipv4_compat => #<IPAddr: IPv6:0000:0000:0000:0000:0000:0000:0102:0304/ffff:ffff:ffff:ffff:ffff:ffff:ffff:fffe> IPAddr.new('1.2.3.4/31').ipv4_compat.prefix => 127 IPAddr.new('1.2.3.4/31').ipv4_compat.instance_variable_get :@mask_addr => 340282366920938463463374607431768211454
Calling
nativeleaves the internal@mask_addras its ipv6 mask instead of converting it to an ipv4 mask. This is most easily seen when callingprefix, but also breaksto_rangeand possibly other methods.Similarly,
ipv4_mappedandipv4_compatalso fail to adjust@mask_addrthe other direction.