Re: [xml] ipv6 and gnome-xml

Date view Thread view Subject view Author view

From: winterlion (winterlion@fsj.net)
Date: Sat Dec 16 2000 - 19:34:05 EST


On Sat, 16 Dec 2000, Daniel Veillard wrote:

> > I've just discovered libxml (and switched to libxml2 - hope it doesn't
> > break anything. v2.2.2) and discovered that the URL parser can't handle
> > ipv6 defined addresses...
> > ie: http://[::1]:80 == http://localhost:80
>
> Well I never looked at the IPv6 URI support, this should be added to the
> TODO list :-)
> I have pointers but never got the time to look at those.
> If you could provide a brief summary of the changes needed to both
> the URI parsing algorithms and possibly the changes needed when dealing
> with the socket interfaces, that would be really useful.
> Patches are welcome too, but I would like first to understand the
> basic changes needed :-)

First: There IS windows 98+ IPv6 support although I think it's a
commercial extra.. I haven't looked for it yet. Also for FreeBSD,
NetBSD, probably MacOS X. FreeBSD, NetBSD and Linux are the testing
ground for the standard so.... *g*

The socket interface requires minimal changes thankfully. At least to get
operational...

Now for the URI format: (paraphrasing rfc 2732)
markers "[" and "]" are to be moved from unwise character set to reserved
character set.

host address specification:
host = hostname | IPv4address | IPv6reference
IPv6reference = "[" IPv6address "]"

rfc 2373 describes the IPv6 address format. The basic outline from what
I've seen though is:
::1 -- localhost
fe80::248:54ff:fe8a:5bef -- real example - my second ethernet card *g*
                                (not accessible to the internet)
::FFFF:129.144.52.38 -- from rfc2732; a site that doesn't understand
                                        ipv6

There's lots of details.. hrm.. I'll look into that next.
ipv6 addresses are 128bit;
preferred form x:x:x:x:x:x:x:x
- x is a 16-bit hexadecimal code
- "::" refers to a group of missing zeros. Any number; so "::1" implies
that the entire address except the last 16bits are 0. and the second
code above (my ethernet card) implies that fe80:0:0:0:248... Only one
such block is allowed to be present in an address.
- an IPv4 varient is when the last two 16-bit values are replaced with a
standard IPv4 address... eg: ::192.168.0.1 or ::FFFF:142.27.10.30 or
0:0:0:0:0:ffff:204.244.132.1 if that helps *g* (fsj.net's not setup for
ipv6 :)

special addresses:
     0:0:0:0:0:0:0:0 - unspecified address; also the "any" address
                when binding to a port to allow any incoming site...
                (I think - according to glibc docs IIRC)
     0:0:0:0:0:0:0:1 - loopback address *g* (or ::1 for ease)

ipv4 addresses:
        ::<ip address> - reference to an IP address
        ::FFFF:<ip address> - reference to a site that doesn't understand
                                ipv6

special:
        FE80:0:0:0:y:y:y:y - link-local address for when finding
                                neighbour addresses, local nodes, or
                                when no ipv6 router is available.
                                (my ethernet card defaulted to this)
        FEC0:0:0:x:y:y:y:y - internal site address; do not allow into
                                internet; (private site addresses)
                                I use 192.y.y.y in this manner
                                x - subnet ID; y - interface ID
        (I've deliberately not compressed these ID's)

- IPX addresses are also described a little (leading bits are 0000010)
- global aggregratable unicast addresses start with bits 001
- multicast addresses start with bits 11111111 (ie:FF)
- anycast addresses (sort of the equivalent of broadcast addresses)
start with subnet y:y:y:y... and finish with ...0:0:0:0
though the number of bits of both vary.... an address ending with a 0 bit
is by nature an "anycast" address as near as I can tell.

Now I've cut out a lot of details and skipped most of what involved
address formation - just including a couple bits of reserved address
handling. Does this help, or is it too much detail? Or did I skip
something important?

I'm not including how IPv6 communicates or how routing, packets, and so on
are formed. Just address formation. glibc-2.1 and newer include ipv6
support (it was a patch for glibc-2.0 iirc) and designed their interface
to require as little modifications as possible. IPv6 allows a lot of
features that IPv4 doesn't - including encrypted communications where a
significant portion of the headers can be encrypted as well. *g*. I
haven't really explored it all that much yet outside of addresses though.

one thing: definitions present for identifying ipv6:
if ipv6 is present, ISC_PLATFORM_HAVEIPV6 in isc/platform.h;
RES_USE_INET6 in resolv.h; IPV6_ADDRFORM (plus lots more) in bits/in.h;
DNS_DISPATCHATTR_IPV6 in dns/dispatch.h; and IPPROTO_IPV6 in netinet/in.h

I dinna have the foggiest which one(s) are guaranteed when ipv6 is present
*g*.

Feel free to ask me anything about this. If I don't know I'll happily
RTFM :) (or RTFS really - I don't have any manuals outside of rfc's)

G'day, eh? :)
        - Teunis

(PS: does anyone know if the "192" A-block is still reserved for internal
use?)

----
Message from the list xml@rpmfind.net
Archived at : http://xmlsoft.org/messages/
to unsubscribe: echo "unsubscribe xml" | mail  majordomo@rpmfind.net


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Dec 16 2000 - 19:43:31 EST