73 lines
3.8 KiB
Plaintext
73 lines
3.8 KiB
Plaintext
IPv6 notes for BIND 4.9.3 Patch 2 Candidate 5 (and later?)
|
|
Paul Vixie, May 20, 1996
|
|
doc/misc/IPv6
|
|
|
|
*** Introduction ***
|
|
|
|
The IPv6 support in this release is latent, in that its presence is not
|
|
documented. The support is not optional, since its presence ought not to
|
|
affect anyone who does not go looking for it. The support includes:
|
|
|
|
inet_ntop() new function.
|
|
inet_pton() new function.
|
|
RES_USE_INET6 causes gethostby*() to return either real IPv6
|
|
addresses (if available) or mapped (::FFFF:a.b.c.d)
|
|
addresses if only IPv4 address records are found.
|
|
gethostbyname() can search for T_AAAA in preference to T_A.
|
|
gethostbyaddr() can search in IP6.INT for PTR RR's.
|
|
named can load, transfer, cache, and dump T_AAAA RRs.
|
|
|
|
*** Some notes on the new functions ***
|
|
|
|
The inet_pton() and inet_ntop() functions differ from the current (as of
|
|
this writing) IPv6 BSD API draft. Discussions were held, primarily between
|
|
myself and Rich Stevens, on the ipng@sunroof.eng.sun.com mailing list, and
|
|
the BIND definitions of these functions are likely to go into the next draft.
|
|
(If not, and BIND has to change its definitions of these functions, then you
|
|
will know why I chose not to document them yet!)
|
|
|
|
These functions can return error values, and as such the process of porting
|
|
code that used inet_aton() to use inet_pton() is not just syntactic. Not all
|
|
nonzero values indicate success; consider "-1". Likewise, inet_ntoa() is not
|
|
just smaller than inet_ntop() -- it's a whole new approach. Inet_ntop() does
|
|
not return a static pointer, the caller has to supply a sized buffer. Also,
|
|
inet_ntop() can return NULL, so you should only printf() the result if you
|
|
have verified that your arguments will be seen as error free.
|
|
|
|
The inet_pton() function is much pickier about its input format than the old
|
|
inet_aton() function has been. You can't abbreviate 10.0.0.53 as 10.53 any
|
|
more. Hexadecimal isn't accepted. You have to supply four decimal numeric
|
|
strings, each of whose value is within the range from 0 to 255. No spaces
|
|
are allowed either before, after, or within an address. If you need the older
|
|
functionality with all the shortcuts and exceptions, continue using inet_aton()
|
|
for your IPv4 address parsing needs.
|
|
|
|
*** Some notes on RES_USE_INET6 ***
|
|
|
|
You can set this by modifying _res.options after calling res_init(), or you
|
|
can turn it on globally by setting "options inet6" in /etc/resolv.conf. This
|
|
latter option ought to be used carefully, since _all_ applications will then
|
|
receive IPv6 style h_addr_list's from their gethostby*() calls. Once you know
|
|
that every application on your system can cope with IPv6 addressing, it is safe
|
|
and reasonable to turn on the global option. Otherwise, don't do it.
|
|
|
|
*** Some notes on mapped IPv4 addresses ***
|
|
|
|
There are two IPv6 prefixes set aside for IPv4 address encapsulation. See
|
|
RFC 1884 for a detailed explaination. The ::a.b.c.d form is used for
|
|
tunnelling, which means wrapping an IPv4 header around IPv6 packets and using
|
|
the existing IPv4 routing infrastructure to reach what are actually IPv6
|
|
endpoints. The ::FFFF:a.b.c.d form can be used on dual-stack (IPv4 and IPv6)
|
|
hosts to signal a predominantly IPv6 stack that it should use ``native'' IPv4
|
|
to reach a given destination, even though the socket's address family is
|
|
AF_INET6.
|
|
|
|
BIND supports both of these address forms, to the extent that inet_pton() will
|
|
parse them, inet_ntop() will generate them, gethostby*() will map IPv4 into
|
|
IPv6 if the RES_USE_INET6 option is set, and gethostbyaddr() will search the
|
|
IN-ADDR.ARPA domain rather than the IP6.INT domain when it needs a PTR RR.
|
|
This last bit of behaviour is still under discussion and it's not clear that
|
|
tunnelled addresses should be mapped using IN-ADDR.ARPA. In other words, this
|
|
bit of behaviour may change in a subsequent BIND release. So now you know
|
|
another reason why none of this stuff is ``officially'' documented.
|