https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6484
--- Comment #7 from Mark Martinec <[email protected]> 2010-12-13 10:45:45 UTC --- > I noted in the regex for IPv6, we don't need 9 copies (but only 7) of the > latter term as permitting 9 would allow ANY representation where the lower 32 > bits are represented as an IPv4 embedded address. However, only two forms > (in "::/80") were ever defined - and at most, they would have 3 colons and > 3 dots (implying a maximum value of 6, but regular IPv6 addresses can have > 7 colons). Therefore, 9 was lowered to 7 so as to exclude invalid > representations. Don't know where your understanding of the 'alternative form' comes from. My understanding of RFC 4291 section 2.2 yields up to 10 fields, e.g.: 0:0:0:0:0:FFFF:192.0.2.1 An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). Examples: 0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:FFFF:129.144.52.38 or in compressed form: ::13.1.68.3 ::FFFF:129.144.52.38 It is not the purpose of this regexp to validate IPv6 addresses, but just to prescreen/triage obvious misfits. The NetAddr::IP::full6 is perfectly capable of weeding out remaining invalid addresses. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
