[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bin/84106: inet_pton(AF_INET6, ....) seems too permissive
- To: Mikhail Teterin <mi+kde_(_at_)_aldan_(_dot_)_algebra_(_dot_)_com>
- Subject: Re: bin/84106: inet_pton(AF_INET6, ....) seems too permissive
- From: Hajimu UMEMOTO <ume_(_at_)_freebsd_(_dot_)_org>
- Date: Wed, 27 Jul 2005 23:42:57 +0900
- Cc: standards_(_at_)_freebsd_(_dot_)_org, FreeBSD-gnats-submit_(_at_)_freebsd_(_dot_)_org
- Organization: Internet Mutual Aid Society, YOKOHAMA
>>>>> On Wed, 27 Jul 2005 09:03:27 -0400
>>>>> Mikhail Teterin <mi+kde_(_at_)_aldan_(_dot_)_algebra_(_dot_)_com> said:
mi+kde> On Wednesday 27 July 2005 06:42 am, Hajimu UMEMOTO wrote:
mi+kde> = mi> 1:2:3:4:5:6:7::8
mi+kde> = mi> or
mi+kde> = mi> 1:2:3:4:5:6::7:8
mi+kde> = mi> inet_pton should reject (return 0) both of these addresses.
mi+kde> = No, I don't think so. I cannot see such restriction in RFC 2373 2.2
mi+kde> = Text Representation of Addresses. Isn't it a problem of NSPR's
mi+kde> = addtest?
mi+kde> I thought, 8 positions is the most an IPv6 address can have. This
mi+kde> strings have 9, don't they?
Ah, yes. I didn't understand your point, correctly.
Since it seems that this problem was fixed in BIND9's inet_pton.c,
I've just commited the fix which was taken from it:
Please try it, and let me know the result.
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
freebsd-standards_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-standards-unsubscribe_(_at_)_freebsd_(_dot_)_org"