diff --git a/Changes b/Changes
index 1ecdcb6..736782d 100644
--- a/Changes
+++ b/Changes
@@ -1,5 +1,8 @@
 Revision history for Perl extension NetAddr::IP
 
+4.004  Wed Aug 16 16:01:54 PDT 2006
+        update to include/exclude files in corrupted distro
+
 4.003  Sun Aug  6 10:48:25 PDT 2006
 	correct SYNOPSIS documentation
 	add :old_nth
diff --git a/IP.pm b/IP.pm
index 28a3796..b59b9ad 100644
--- a/IP.pm
+++ b/IP.pm
@@ -31,7 +31,7 @@
 
 @ISA = qw(Exporter NetAddr::IP::Lite);
 
-$VERSION = do { sprintf " %d.%03d", (q$Revision: 4.3 $ =~ /\d+/g) };
+$VERSION = do { sprintf " %d.%03d", (q$Revision: 4.4 $ =~ /\d+/g) };
 
 =pod
 
@@ -1059,7 +1059,7 @@
 
 =head1 HISTORY
 
-$Id: IP.pm,v 4.3 2006/08/14 16:24:03 lem Exp $
+$Id: IP.pm,v 4.4 2006/08/17 01:00:54 lem Exp $
 
 =over
 
diff --git a/Lite/Lite.pm b/Lite/Lite.pm
index 417887d..fd049de 100644
--- a/Lite/Lite.pm
+++ b/Lite/Lite.pm
@@ -27,7 +27,7 @@
 );
 use vars qw(@ISA @EXPORT_OK $VERSION $Accept_Binary_IP $Old_nth);
 
-$VERSION = do { my @r = (q$Revision: 1.4 $ =~ /\d+/g); sprintf "%d."."%02d" x $#r, @r };
+$VERSION = do { my @r = (q$Revision: 1.5 $ =~ /\d+/g); sprintf "%d."."%02d" x $#r, @r };
 
 require Exporter;
 
diff --git a/Lite/MANIFEST.SKIP b/Lite/MANIFEST.SKIP
deleted file mode 100644
index b318318..0000000
--- a/Lite/MANIFEST.SKIP
+++ /dev/null
@@ -1,3 +0,0 @@
-Makefile
-Makefile.old
-Util/Util_IS.pm
diff --git a/Lite/Util/MANIFEST.SKIP b/Lite/Util/MANIFEST.SKIP
deleted file mode 100644
index c32b057..0000000
--- a/Lite/Util/MANIFEST.SKIP
+++ /dev/null
@@ -1,3 +0,0 @@
-Util_IS.pm
-Makefile
-Makefile.old
diff --git a/Lite/Util/Util.bs b/Lite/Util/Util.bs
deleted file mode 100644
index e69de29..0000000
--- a/Lite/Util/Util.bs
+++ /dev/null
diff --git a/Lite/Util/Util.c b/Lite/Util/Util.c
deleted file mode 100644
index b1862eb..0000000
--- a/Lite/Util/Util.c
+++ /dev/null
@@ -1,996 +0,0 @@
-/*
- * This file was generated automatically by xsubpp version 1.9508 from the
- * contents of Util.xs. Do not edit this file, edit Util.xs instead.
- *
- *	ANY CHANGES MADE HERE WILL BE LOST!
- *
- */
-
-#line 1 "Util.xs"
-
-/*
- * Copyright 2006, Michael Robinton <michael@bizsystems.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-*/
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-#ifdef _CYGWIN
-#include <windows.h>
-#endif
-
-#include "EXTERN.h"
-#include "perl.h"
-#include "XSUB.h"
-
-#ifdef _CYGWIN
-#include <Win32-Extensions.h>
-#endif
-
-/*	take care of missing u_int32_t definitions windoze/sun		*/
-#include "u_intxx.h"
-
-/*	needed for testing with 'printf'
-#include <stdio.h>
- */
-
-#ifdef __cplusplus
-}
-#endif
-
-/*	workaround for OS's without inet_aton			*/
-#include "xs_include/inet_aton.c"
-
-typedef union
-{
-  u_int32_t     u[4];
-  unsigned char c[16];
-} n128;
-
-n128 c128, a128;
-
-u_int32_t wa[4], wb[4];		/*	working registers	*/
-
-struct
-{		/*	character array of 40 bytes		*/
-  char		txt[20];	/*	20 bytes		*/
-  u_int32_t	bcd[5];		/*	20 bytes, 40 digits	*/
-} n;
-
-#define zero ('0' & 0x7f)
-
-void
-extendipv4(void * aa)
-{
-  register u_int32_t * a = wa;
-  *a++ = 0;
-  *a++ = 0;
-  *a++ = 0;
-  *a = *((u_int32_t *)aa);
-}
-
-void
-extendmask4(void *aa)
-{
-  register u_int32_t * a = wa;
-  *a++ = 0xffffffff;
-  *a++ = 0xffffffff;
-  *a++ = 0xffffffff;
-  *a = *((u_int32_t *)aa);
-}
-
-void
-fastcomp128(void * aa)
-{
-  register u_int32_t * a;
-  a = aa;
-
-  *a++ ^= 0xffffffff;
-  *a++ ^= 0xffffffff;
-  *a++ ^= 0xffffffff;
-  *a++ ^= 0xffffffff;
-}
-
-/*	add two 128 bit numbers
-	return the carry
- */
-
-int
-adder128(void * aa, void * bb, int carry)
-{
-  int i;
-  register u_int32_t a, b, r;
-
-  for (i=3; i >= 0; i--) {
-    a = *((u_int32_t *)aa + i);
-    b = *((u_int32_t *)bb + i);
-    r = a + b;
-    a = 0;			/*	ripple carry forward	*/
-    if ( r < a || r < b)	/*	if overflow		*/
-      a = 1;
-
-    b = r + carry;		/*	carry propagate	in	*/
-    if (b < r)			/*	ripple carry forward	*/
-      carry = 1;		/*	if overflow		*/
-    else
-      carry = a;
-
-    *((u_int32_t *)a128.u + i) = b;
-  }
-  return carry;
-}
-
-int
-addercon(void * aa, int32_t con)
-{
-  register u_int32_t tmp = 0x80000000;
-
-  if (con & tmp)
-    tmp = 0xffffffff;
-  else
-    tmp = 0;
-
-  wb[0] = tmp;
-  wb[1] = tmp;
-  wb[2] = tmp;
-  wb[3] = (u_int32_t)con;
-  return adder128(aa,wb,0);
-}
-
-int
-have128(void * bp)
-{
-  register u_int32_t * p = bp;
-
-  if (*p++ || *p++ || *p++ || *p++)
-    return 1;
-  return 0;
-}
-
-int
-_isipv4(void * bp)
-{
-  register u_int32_t * p = bp;
-
-  if (*p++ || *p++ || *p++)
-    return 0;
-  return 1;
-}
-
-/*	network byte swap and copy	*/
-void
-netswap_copy(void * dest, void * src, int len)
-{
-  register u_int32_t * d = dest, * s = src;
-
-  for (/* -- */;len>0;len--) {
-#ifdef host_is_LITTLE_ENDIAN
-    *d++ =  (((*s & 0xff000000) >> 24) | ((*s & 0x00ff0000) >>  8) | \
-             ((*s & 0x0000ff00) <<  8) | ((*s & 0x000000ff) << 24));
-#else
-# ifdef host_is_BIG_ENDIAN
-    *d++ = *s;
-# else
-# error ENDIANness not defined
-# endif
-#endif
-    s++;
-  }
-}
-
-/*	do ntohl / htonl changes as necessary for this OS
- */
-void
-netswap(void * ap, int len)
-{
-#ifdef host_is_LITTLE_ENDIAN
-  register u_int32_t * a = ap;
-  for (/* -- */;len >0;len--) {
-    *a++ =  (((*a & 0xff000000) >> 24) | ((*a & 0x00ff0000) >>  8) | \
-             ((*a & 0x0000ff00) <<  8) | ((*a & 0x000000ff) << 24));
-  }
-#endif
-}
-
-/*	shift right to purge '0's,
-	return mask bit count and remainder value,
-	left fill with ones
- */
-unsigned char
-_countbits(void *ap)
-{
-  register u_int32_t * p0 = (u_int32_t *)ap, * p1 = p0 +1, * p2 = p1 +1, * p3 = p2 +1;
-  unsigned char count = 128;
-
-  fastcomp128(ap);
-
-  do {
-    if (!(*p3 & 1))
-      break;
-    count--;
-    *p3 >>= 1;
-    if (*p2 & 1)
-      *p3 |= 0x80000000;
-    *p2 >>= 1;
-    if (*p1 & 1)
-      *p2 |= 0x80000000;
-    *p1 >>= 1;
-    if (*p0 & 1)
-      *p1 |= 0x80000000;
-    *p0 >>= 1;
-  } while (count > 0);
-  return count;
-}
-
-/*	multiply 128 bit number x 2
- */
-void
-_128x2(void * ap)
-{
-  register u_int32_t * p = (u_int32_t *)ap +3, tmpc, carry = 0;
-
-  do {
-    tmpc = *p & 0x80000000;	/*	propagate hi bit to next word	*/
-    *p <<= 1;
-    if (carry)
-      *p += 1;
-    carry = tmpc;
-  } while (p-- > (u_int32_t *)ap);
-/* printf("2o %04X:%04X:%04X:%04X\n",*((u_int32_t *)ap),*((u_int32_t *)ap +1),*((u_int32_t *)ap +2),*((u_int32_t *)ap +3)); */
-}
-
-/*	multiply 128 bit number X10
- */
-int
-_128x10(void * ap, void * tp)
-{
-  _128x2(ap);					/*	multiply by two		*/
-  *(u_int32_t *)tp	= *(u_int32_t *)ap;	/*	temp save		*/
-  *((u_int32_t *)tp +1)	= *((u_int32_t *)ap +1);
-  *((u_int32_t *)tp +2)	= *((u_int32_t *)ap +2);
-  *((u_int32_t *)tp +3)	= *((u_int32_t *)ap +3);
-  _128x2(ap);
-  _128x2(ap);					/*	times 8			*/
-  (void) adder128(ap,tp,0);
-/* printf("x  %04X:%04X:%04X:%04X\n",*((u_int32_t *)ap),*((u_int32_t *)ap +1),*((u_int32_t *)ap +2),*((u_int32_t *)ap +3)); */
-}
-
-/*	multiply 128 bit number by 10, add bcd digit to result
- */
-void  
-_128x10plusbcd(void * ap, void * tp, char digit)
-{
-/* printf("digit %X + %X = ",digit,*((u_int32_t *)ap +3)); */
-  _128x10(ap,tp);
-  *(u_int32_t *)tp		= 0;
-  *((u_int32_t *)tp + 1)	= 0;
-  *((u_int32_t *)tp + 2)	= 0;
-  *((u_int32_t *)tp + 3)	= digit;
-  (void) adder128(ap,tp,0);
-/* printf("%d %04X:%04X:%04X:%04X\n",digit,*((u_int32_t *)ap),*((u_int32_t *)ap +1),*((u_int32_t *)ap +2),*((u_int32_t *)ap +3)); */
-}
-
-char
-_simple_pack(void * str,int len)
-{
-  int i = len -1, j=19, lo=1;
-  register unsigned char c, * bcdn = (unsigned char *)n.bcd, * sp = (unsigned char *) str;
-
-  if (len > 40)
-    return '*';				/*	error, input string too long	*/
-
-  memset (n.bcd, 0, 20);
-
-  do {
-    c = *(sp + i) & 0x7f;
-    if (c < zero || c > (zero + 9))
-      return c;				/*	error, out of range	*/
-
-    if (lo) {			/*	lo byte ?		*/
-      *(bcdn + j) = c & 0xF;
-      lo = 0;
-    }
-    else {
-      c <<= 4;
-      *(bcdn + j) |= c;
-      lo = 1;			/*	lo byte next		*/
-      j--;
-    }
-  } while (i-- > 0);
-  return 0;
-}
-
-/*	convert a packed bcd string to 128 bit binary string
- */
-void
-_bcdn2bin(void * bp, int len)
-{
-  int i = 0, hasdigits = 0, lo;
-  register unsigned char c, * cp = (unsigned char *)bp;
-
-  memset(a128.c, 0, 16);
-  memset(c128.c, 0, 16);
-
-  while (i < len ) {
-    c = *cp++;
-    for (lo=0;lo<2;lo+=1) {
-      if (lo) {
-        if (hasdigits)			/*	suppress leading zero multiplications	*/
-          _128x10plusbcd(a128.u,c128.u, c & 0xF);
-        else {
-	  if (c & 0xF) {
-            hasdigits = 1;
-	    a128.u[3] = c & 0xF;
-          }
-        }
-      }
-      else {
-        if (hasdigits)			/*	suppress leading zero multiplications	*/
-          _128x10plusbcd(a128.u,c128.u, c >> 4);
-        else {
-          if (c & 0XF0) {
-            hasdigits = 1;
-	    a128.u[3] = c >> 4;
-	  }
-        }
-      }
-      i++;
-      if (i >= len)
-        break;
-    }
-  }
-}
-
-/*	convert a 128 bit number string to a bcd number string
-	returns the length of the bcd string === 20
- */
-int
-_bin2bcd (unsigned char * binary)
-{
-  register u_int32_t tmp, add3, msk8, bcd8, carry;
-  u_int32_t word;
-  unsigned char binmsk = 0;
-  int c = 0,i, j, p;
-  
-  memset (n.bcd, 0, 20);
-
-  for (p=0;p<128;p++) {			/*	bit pointer	*/
-    if (! binmsk) {
-      word = *((unsigned char *)binary + c);
-      binmsk = 0x80;
-      c++;
-    }
-    carry = word & binmsk;		/*	bit to convert	*/
-    binmsk >>= 1;
-    for (i=4;i>=0;i--) {
-      bcd8 = n.bcd[i];
-      if (carry | bcd8) {		/* if something to do		*/
-	add3 = 3;
-	msk8 = 8;
-	
-        for (j=0;j<8;j++) {		/*	prep bcd digits for X2	*/
-          tmp = bcd8 + add3;
-          if (tmp & msk8)
-            bcd8 = tmp;
-          add3 <<= 4;
-          msk8 <<= 4;
-        }
-        tmp = bcd8 & 0x80000000;	/*	propagated carry	*/
-	bcd8 <<= 1;			/*	x 2			*/
-	if (carry)
-          bcd8 += 1;
-        n.bcd[i] = bcd8;
-	carry = tmp;
-      }
-    }
-  }
-  netswap(n.bcd,5);
-  return 20;
-}
-
-/*	convert a bcd number string to a bcd text string
-	returns the number of digits
- */
-int
-_bcd2txt(unsigned char * bcd2p)
-{
-  register unsigned char bcd, dchar;
-  int	i, j = 0;
-
-  for (i=0;i<20;i++) {
-    dchar = *(bcd2p + i);
-    bcd = dchar >> 4;
-    if (j || bcd) {
-      n.txt[j] = bcd + zero;
-      j++;
-    }
-    bcd = dchar & 0xF;
-    if (j || bcd || i == 19) {		/* must be at least one digit	*/
-      n.txt[j] = bcd + zero;
-      j++;
-    }
-  }
-  n.txt[j] = 0;				/* string terminator	*/
-  return j;
-}
-
-#line 433 "Util.c"
-
-/* INCLUDE:  Including 'xs_include/miniSocket.inc' from 'Util.xs' */
-
-#ifndef Newx
-#define Newx(v,n,t) New(1138,v,n,t)
-#endif
-#include <netdb.h>
-XS(XS_NetAddr__IP__Util_inet_aton); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_inet_aton)
-{
-    dXSARGS;
-    if (items != 1)
-	Perl_croak(aTHX_ "Usage: NetAddr::IP::Util::inet_aton(host)");
-    {
-	char *	host = (char *)SvPV_nolen(ST(0));
-#line 76 "xs_include/miniSocket.inc"
-	{
-	struct in_addr ip_address;
-	struct hostent * phe;
-	int ok =
-		(host != NULL) &&
-		(*host != '\0') &&
-		inet_aton(host, &ip_address);
-
-	if (!ok && (phe = gethostbyname(host))) {
-		Copy( phe->h_addr, &ip_address, phe->h_length, char );
-		ok = 1;
-	}
-
-	ST(0) = sv_newmortal();
-	if (ok)
-		sv_setpvn( ST(0), (char *)&ip_address, sizeof ip_address );
-	}
-#line 467 "Util.c"
-    }
-    XSRETURN(1);
-}
-
-XS(XS_NetAddr__IP__Util_inet_ntoa); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_inet_ntoa)
-{
-    dXSARGS;
-    if (items != 1)
-	Perl_croak(aTHX_ "Usage: NetAddr::IP::Util::inet_ntoa(ip_address_sv)");
-    {
-	SV *	ip_address_sv = ST(0);
-#line 98 "xs_include/miniSocket.inc"
-	{
-	STRLEN addrlen;
-	struct in_addr addr;
-	char * addr_str;
-	char * ip_address;
-	ip_address = SvPV(ip_address_sv,addrlen);
-	if (addrlen == sizeof(addr) || addrlen == 4)
-	        addr.s_addr =
-		    (ip_address[0] & 0xFF) << 24 |
-		    (ip_address[1] & 0xFF) << 16 |
-		    (ip_address[2] & 0xFF) <<  8 |
-		    (ip_address[3] & 0xFF);
-	else
-	        croak("Bad arg length for %s, length is %d, should be %d",
-		      "NetAddr::IP::Util::inet_ntoa",
-		      addrlen, sizeof(addr));
-	/* We could use inet_ntoa() but that is broken
-	 * in HP-UX + GCC + 64bitint (returns "0.0.0.0"),
-	 * so let's use this sprintf() workaround everywhere.
-	 * This is also more threadsafe than using inet_ntoa(). */
-	Newx(addr_str, 4 * 3 + 3 + 1, char); /* IPv6? */
-	sprintf(addr_str, "%d.%d.%d.%d",
-		((addr.s_addr >> 24) & 0xFF),
-		((addr.s_addr >> 16) & 0xFF),
-		((addr.s_addr >>  8) & 0xFF),
-		( addr.s_addr        & 0xFF));
-	ST(0) = sv_2mortal(newSVpvn(addr_str, strlen(addr_str)));
-	Safefree(addr_str);
-	}
-#line 510 "Util.c"
-    }
-    XSRETURN(1);
-}
-
-
-/* INCLUDE: Returning to 'Util.xs' from 'xs_include/miniSocket.inc' */
-
-XS(XS_NetAddr__IP__Util_comp128); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_comp128)
-{
-    dXSARGS;
-    dXSI32;
-    if (items < 1)
-       Perl_croak(aTHX_ "Usage: %s(s, ...)", GvNAME(CvGV(cv)));
-    SP -= items;
-    {
-	SV *	s = ST(0);
-#line 436 "Util.xs"
-	unsigned char * ap;
-	STRLEN len;
-	int i;
-#line 532 "Util.c"
-#line 440 "Util.xs"
-	ap = SvPV(s,len);
-	if (len != 16) {
-	  if (ix == 2)
-	    strcpy((char *)wa,"ipv6to4");
-	  else if (ix == 1)
-	    strcpy((char *)wa,"shiftleft");
-	  else
-	    strcpy((char *)wa,"comp128");
-	  croak("Bad arg length for %s%s, length is %d, should be %d",
-		"NetAddr::IP::Util::",(char *)wa,len *8,128);
-	}
-	if (ix == 2) {
-	  XPUSHs(sv_2mortal(newSVpvn((unsigned char *)(ap +12),4)));
-	  XSRETURN(1);
-	}
-	else if (ix == 1) {
-	  if (items < 2) {
-	    memcpy(wa,ap,16);
-	  }
-	  else if ((i = SvIV(ST(1))) == 0) {
-	    memcpy(wa,ap,16);
-	  }
-	  else if (i < 0 || i > 128) {
-	    croak("Bad arg value for %s, is %d, should be 0 thru 128",
-		"NetAddr::IP::Util::shiftleft",i);
-	  }
-	  else {
-	    netswap_copy(wa,ap,4);
-	    do {
-		_128x2(wa);
-		i--;
-	    } while (i > 0);
-	    netswap(wa,4);
-	  }
-	}
-	else {
-	  memcpy(wa,ap,16);
-	  fastcomp128(wa);
-	}
-	XPUSHs(sv_2mortal(newSVpvn((unsigned char *)wa,16)));
-	XSRETURN(1);
-#line 575 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-XS(XS_NetAddr__IP__Util_add128); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_add128)
-{
-    dXSARGS;
-    dXSI32;
-    if (items != 2)
-       Perl_croak(aTHX_ "Usage: %s(as, bs)", GvNAME(CvGV(cv)));
-    SP -= items;
-    {
-	SV *	as = ST(0);
-	SV *	bs = ST(1);
-#line 489 "Util.xs"
-	unsigned char * ap, *bp;
-	STRLEN len;
-#line 595 "Util.c"
-#line 492 "Util.xs"
-	ap = SvPV(as,len);
-	if (len != 16) {
-    Bail:
-	  if (ix == 1)
-	    strcpy((char *)wa,"sub128");
-	  else
-	    strcpy((char *)wa,"add128");
-	  croak("Bad arg length for %s%s, length is %d, should be %d",
-		"NetAddr::IP::Util::",(char *)wa,len *8,128);
-	}
-
-	bp = SvPV(bs,len);
-	if (len != 16) {
-	  goto Bail;
-	}
-
-	netswap_copy(wa,ap,4);
-	netswap_copy(wb,bp,4);
-	if (ix == 1) {
-	  fastcomp128(wb);
-	  XPUSHs(sv_2mortal(newSViv((I32)adder128(wa,wb,1))));
-	}
-	else {
-	  XPUSHs(sv_2mortal(newSViv((I32)adder128(wa,wb,0))));
-	}
-	if (GIMME_V == G_ARRAY) {
-	  netswap(a128.u,4);
-	  XPUSHs(sv_2mortal(newSVpvn(a128.c,16)));
-	  XSRETURN(2);
-	}
-	XSRETURN(1);
-#line 628 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-XS(XS_NetAddr__IP__Util_addconst); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_addconst)
-{
-    dXSARGS;
-    if (items != 2)
-	Perl_croak(aTHX_ "Usage: NetAddr::IP::Util::addconst(s, cnst)");
-    SP -= items;
-    {
-	SV *	s = ST(0);
-	I32	cnst = (I32)SvIV(ST(1));
-#line 529 "Util.xs"
-	unsigned char * ap;
-	STRLEN len;
-#line 647 "Util.c"
-#line 532 "Util.xs"
-	ap = SvPV(s,len);
-	if (len != 16) {
-	  croak("Bad arg length for %s, length is %d, should be %d",
-		"NetAddr::IP::Util::addconst",len *8,128);
-        }
-	netswap_copy(wa,ap,4);
-	XPUSHs(sv_2mortal(newSViv((I32)addercon(wa,cnst))));
-	if (GIMME_V == G_ARRAY) {
-	  netswap(a128.u,4);
-	  XPUSHs(sv_2mortal(newSVpvn(a128.c,16)));
-	  XSRETURN(2);
-	}
-	XSRETURN(1);
-#line 662 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-XS(XS_NetAddr__IP__Util_hasbits); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_hasbits)
-{
-    dXSARGS;
-    dXSI32;
-    if (items != 1)
-       Perl_croak(aTHX_ "Usage: %s(s)", GvNAME(CvGV(cv)));
-    {
-	SV *	s = ST(0);
-#line 552 "Util.xs"
-	unsigned char * bp;
-	STRLEN len;
-#line 680 "Util.c"
-	int	RETVAL;
-	dXSTARG;
-#line 555 "Util.xs"
-	bp = SvPV(s,len);
-	if (len != 16) {
-	  if (ix == 1)
-	    strcpy((char *)wa,"isIPv4");
-	  else
-	    strcpy((char *)wa,"hasbits");
-	  croak("Bad arg length for %s%s, length is %d, should be %d",
-		"NetAddr::IP::Util::",(char *)wa,len *8,128);
-	}
-	if (ix == 1) {
-	  RETVAL = _isipv4(bp);
-	}
-	else {
-	  RETVAL = have128(bp);
-	}
-#line 699 "Util.c"
-	XSprePUSH; PUSHi((IV)RETVAL);
-    }
-    XSRETURN(1);
-}
-
-XS(XS_NetAddr__IP__Util_bin2bcd); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_bin2bcd)
-{
-    dXSARGS;
-    dXSI32;
-    if (items != 1)
-       Perl_croak(aTHX_ "Usage: %s(s)", GvNAME(CvGV(cv)));
-    SP -= items;
-    {
-	SV *	s = ST(0);
-#line 580 "Util.xs"
-	unsigned char * cp;
-	STRLEN	len;
-#line 718 "Util.c"
-#line 583 "Util.xs"
-	cp = SvPV(s,len);
-	if (ix == 0) {
-	  if (len != 16) {
-	    croak("Bad arg length for %s, length is %d, should be %d",
-		"NetAddr::IP::Util::bin2bcd",len *8,128);
-          }
-	  (void) _bin2bcd(cp);
-	  XPUSHs(sv_2mortal(newSVpvn(n.txt,_bcd2txt((unsigned char *)n.bcd))));
-	}
-	else if (ix == 1) {
-	  if (len != 16) {
-	    croak("Bad arg length for %s, length is %d, should be %d",
-		"NetAddr::IP::Util::bin2bcdn",len *8,128);
-	  }
-	  XPUSHs(sv_2mortal(newSVpvn((unsigned char *)n.bcd,_bin2bcd(cp))));
-	}
-	else {
-	  if (len > 20) {
-	    croak("Bad arg length for %s, length is %d, should %d digits or less",
-		"NetAddr::IP::Util::bcdn2txt",len *2,40);
-	  }
-	  XPUSHs(sv_2mortal(newSVpvn(n.txt,_bcd2txt(cp))));
-	}
-	XSRETURN(1);
-#line 744 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-XS(XS_NetAddr__IP__Util_bcd2bin); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_bcd2bin)
-{
-    dXSARGS;
-    dXSI32;
-    if (items < 1)
-       Perl_croak(aTHX_ "Usage: %s(s, ...)", GvNAME(CvGV(cv)));
-    SP -= items;
-    {
-	SV *	s = ST(0);
-#line 621 "Util.xs"
-	unsigned char * cp, badc;
-	STRLEN len;
-#line 763 "Util.c"
-#line 624 "Util.xs"
-	cp = SvPV(s,len);
-	if (len > 40) {
-	  if (ix == 0)
-	    strcpy((char *)wa,"bcd2bin");
-	  else if (ix ==1)
-	    strcpy((char *)wa,"simple_pack");
-    Badigits:
-	  croak("Bad arg length for %s%s, length is %d, should be %d digits or less",
-		"NetAddr::IP::Util::",(char *)wa,len,40);
-	}
-	if (ix == 2) {
-	  if (len > 20) {
-	    len <<= 1;		/*	times 2	*/
-	    strcpy((char *)wa,"bcdn2bin");
-	    goto Badigits;
-	  }
-	  if (items < 2) {
-	    croak("Bad usage, should have %s('packedbcd,length)",
-		"NetAddr::IP::Util::bcdn2bin");
-	  }
-	  len = SvIV(ST(1));
-	  _bcdn2bin(cp,(int)len);
-	  netswap(a128.u,4);
-	  XPUSHs(sv_2mortal(newSVpvn(a128.c,16)));
-	  XSRETURN(1);
-	}
-
-	badc = _simple_pack(cp,(int)len);
-	if (badc) {
-	  if (ix == 1)
-	    strcpy((char *)wa,"simple_pack");
-	  else
-	    strcpy((char *)wa,"bcd2bin");
-	    croak("Bad char in string for %s%s, character is '%c', allowed are 0-9",
-		"NetAddr::IP::Util::",(char *)wa,badc);
-	}
-	if (ix == 0) {
-	  _bcdn2bin(n.bcd,40);
-	  netswap(a128.u,4);
-	  XPUSHs(sv_2mortal(newSVpvn(a128.c,16)));
-	}
-	else {	/*	ix == 1	*/
-	  XPUSHs(sv_2mortal(newSVpvn((unsigned char *)n.bcd,20)));
-	}
-	XSRETURN(1);
-#line 810 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-XS(XS_NetAddr__IP__Util_notcontiguous); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_notcontiguous)
-{
-    dXSARGS;
-    if (items != 1)
-	Perl_croak(aTHX_ "Usage: NetAddr::IP::Util::notcontiguous(s)");
-    SP -= items;
-    {
-	SV *	s = ST(0);
-#line 674 "Util.xs"
-	unsigned char * ap, count;
-	STRLEN len;
-#line 828 "Util.c"
-#line 677 "Util.xs"
-	ap = SvPV(s,len);
-	if (len != 16) {
-	  croak("Bad arg length for %s, length is %d, should be %d",
-		"NetAddr::IP::Util::countbits",len *8,128);
-        }
-	netswap_copy(wa,ap,4);
-	count = _countbits(wa);
-	XPUSHs(sv_2mortal(newSViv((I32)have128(wa))));
-	if (GIMME_V == G_ARRAY) {
-	  XPUSHs(sv_2mortal(newSViv((I32)count)));
-	  XSRETURN(2);
-	}
-	XSRETURN(1);
-#line 843 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-XS(XS_NetAddr__IP__Util_ipv4to6); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_ipv4to6)
-{
-    dXSARGS;
-    dXSI32;
-    if (items != 1)
-       Perl_croak(aTHX_ "Usage: %s(s)", GvNAME(CvGV(cv)));
-    SP -= items;
-    {
-	SV *	s = ST(0);
-#line 697 "Util.xs"
-	unsigned char * ip;
-	STRLEN len;
-#line 862 "Util.c"
-#line 700 "Util.xs"
-	ip = SvPV(s,len);
-	if (len != 4) {
-	  if (ix == 1)
-	    strcpy((char *)wa,"mask4to6");
-	  else
-	    strcpy((char *)wa,"ipv4to6");
-	  croak("Bad arg length for %s%s, length is %d, should be 32",
-		"NetAddr::IP::Util::",(char *)wa,len *8);
-	}
-	if (ix == 0)
-	  extendipv4(ip);
-	else
-	  extendmask4(ip);
-	XPUSHs(sv_2mortal(newSVpvn((unsigned char *)wa,16)));
-	XSRETURN(1);
-#line 879 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-XS(XS_NetAddr__IP__Util_ipanyto6); /* prototype to pass -Wmissing-prototypes */
-XS(XS_NetAddr__IP__Util_ipanyto6)
-{
-    dXSARGS;
-    dXSI32;
-    if (items != 1)
-       Perl_croak(aTHX_ "Usage: %s(s)", GvNAME(CvGV(cv)));
-    SP -= items;
-    {
-	SV *	s = ST(0);
-#line 722 "Util.xs"
-	unsigned char * ip;
-	STRLEN len;
-#line 898 "Util.c"
-#line 725 "Util.xs"
-	ip = SvPV(s,len);
-	if (len == 16)		/* if already 128 bits, return input	*/
-	  XPUSHs(sv_2mortal(newSVpvn(ip,16)));
-	else if (len == 4) {
-	  if (ix == 0)
-	    extendipv4(ip);
-	  else
-	    extendmask4(ip);
-	  XPUSHs(sv_2mortal(newSVpvn((unsigned char *)wa,16)));
-	}
-	else {
-	  if (ix == 1)
-	    strcpy((char *)wa,"maskanyto6");
-	  else
-	    strcpy((char *)wa,"ipanyto6");
-	  croak("Bad arg length for %s%s, length is %d, should be 32 or 128",
-		"NetAddr::IP::Util::",(char *)wa,len *8);
-	}
-	XSRETURN(1);
-#line 919 "Util.c"
-	PUTBACK;
-	return;
-    }
-}
-
-#ifdef __cplusplus
-extern "C"
-#endif
-XS(boot_NetAddr__IP__Util); /* prototype to pass -Wmissing-prototypes */
-XS(boot_NetAddr__IP__Util)
-{
-    dXSARGS;
-    char* file = __FILE__;
-
-    XS_VERSION_BOOTCHECK ;
-
-    {
-        CV * cv ;
-
-        newXSproto("NetAddr::IP::Util::inet_aton", XS_NetAddr__IP__Util_inet_aton, file, "$");
-        newXSproto("NetAddr::IP::Util::inet_ntoa", XS_NetAddr__IP__Util_inet_ntoa, file, "$");
-        cv = newXS("NetAddr::IP::Util::ipv6to4", XS_NetAddr__IP__Util_comp128, file);
-        XSANY.any_i32 = 2 ;
-        sv_setpv((SV*)cv, "$;@") ;
-        cv = newXS("NetAddr::IP::Util::comp128", XS_NetAddr__IP__Util_comp128, file);
-        XSANY.any_i32 = 0 ;
-        sv_setpv((SV*)cv, "$;@") ;
-        cv = newXS("NetAddr::IP::Util::shiftleft", XS_NetAddr__IP__Util_comp128, file);
-        XSANY.any_i32 = 1 ;
-        sv_setpv((SV*)cv, "$;@") ;
-        cv = newXS("NetAddr::IP::Util::add128", XS_NetAddr__IP__Util_add128, file);
-        XSANY.any_i32 = 0 ;
-        sv_setpv((SV*)cv, "$$") ;
-        cv = newXS("NetAddr::IP::Util::sub128", XS_NetAddr__IP__Util_add128, file);
-        XSANY.any_i32 = 1 ;
-        sv_setpv((SV*)cv, "$$") ;
-        newXSproto("NetAddr::IP::Util::addconst", XS_NetAddr__IP__Util_addconst, file, "$$");
-        cv = newXS("NetAddr::IP::Util::hasbits", XS_NetAddr__IP__Util_hasbits, file);
-        XSANY.any_i32 = 0 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::isIPv4", XS_NetAddr__IP__Util_hasbits, file);
-        XSANY.any_i32 = 1 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::bin2bcdn", XS_NetAddr__IP__Util_bin2bcd, file);
-        XSANY.any_i32 = 1 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::bcdn2txt", XS_NetAddr__IP__Util_bin2bcd, file);
-        XSANY.any_i32 = 2 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::bin2bcd", XS_NetAddr__IP__Util_bin2bcd, file);
-        XSANY.any_i32 = 0 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::bcd2bin", XS_NetAddr__IP__Util_bcd2bin, file);
-        XSANY.any_i32 = 0 ;
-        sv_setpv((SV*)cv, "$;@") ;
-        cv = newXS("NetAddr::IP::Util::simple_pack", XS_NetAddr__IP__Util_bcd2bin, file);
-        XSANY.any_i32 = 1 ;
-        sv_setpv((SV*)cv, "$;@") ;
-        cv = newXS("NetAddr::IP::Util::bcdn2bin", XS_NetAddr__IP__Util_bcd2bin, file);
-        XSANY.any_i32 = 2 ;
-        sv_setpv((SV*)cv, "$;@") ;
-        newXSproto("NetAddr::IP::Util::notcontiguous", XS_NetAddr__IP__Util_notcontiguous, file, "$");
-        cv = newXS("NetAddr::IP::Util::ipv4to6", XS_NetAddr__IP__Util_ipv4to6, file);
-        XSANY.any_i32 = 0 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::mask4to6", XS_NetAddr__IP__Util_ipv4to6, file);
-        XSANY.any_i32 = 1 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::maskanyto6", XS_NetAddr__IP__Util_ipanyto6, file);
-        XSANY.any_i32 = 1 ;
-        sv_setpv((SV*)cv, "$") ;
-        cv = newXS("NetAddr::IP::Util::ipanyto6", XS_NetAddr__IP__Util_ipanyto6, file);
-        XSANY.any_i32 = 0 ;
-        sv_setpv((SV*)cv, "$") ;
-    }
-    XSRETURN_YES;
-}
-
diff --git a/Lite/Util/Util.o b/Lite/Util/Util.o
deleted file mode 100644
index 20d535c..0000000
--- a/Lite/Util/Util.o
+++ /dev/null
Binary files differ
diff --git a/Lite/Util/Util.pm b/Lite/Util/Util.pm
index f449183..5658d03 100644
--- a/Lite/Util/Util.pm
+++ b/Lite/Util/Util.pm
@@ -13,7 +13,7 @@
 
 @ISA = qw(Exporter DynaLoader);
 
-$VERSION = do { my @r = (q$Revision: 1.2 $ =~ /\d+/g); sprintf "%d."."%02d" x $#r, @r };
+$VERSION = do { my @r = (q$Revision: 1.3 $ =~ /\d+/g); sprintf "%d."."%02d" x $#r, @r };
 
 my @export_ok = qw(
 	inet_aton
diff --git a/Lite/Util/config.log b/Lite/Util/config.log
deleted file mode 100644
index 245230f..0000000
--- a/Lite/Util/config.log
+++ /dev/null
@@ -1,75 +0,0 @@
-This file contains any messages produced by compilers while
-running siteconf, to aid debugging if siteconf makes a mistake.
-
-It was created by siteconf, which was
-generated by GNU Autoconf 2.53.  Invocation command line was
-
-  $ ./siteconf gcc-3.3 .c .o  -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include  
-
-
-siteconf:285: checking for char
-siteconf:312: gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include conftest.c >&5
-siteconf:315: $? = 0
-siteconf:318: test -s conftest.o
-siteconf:321: $? = 0
-siteconf:331: result: yes
-siteconf:334: checking size of char
-siteconf:612: gcc-3.3 -o conftest -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include  conftest.c  >&5
-siteconf:615: $? = 0
-siteconf:617: ./conftest
-siteconf:620: $? = 0
-siteconf:640: result: 1
-siteconf:647: checking for short int
-siteconf:674: gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include conftest.c >&5
-siteconf:677: $? = 0
-siteconf:680: test -s conftest.o
-siteconf:683: $? = 0
-siteconf:693: result: yes
-siteconf:696: checking size of short int
-siteconf:974: gcc-3.3 -o conftest -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include  conftest.c  >&5
-siteconf:977: $? = 0
-siteconf:979: ./conftest
-siteconf:982: $? = 0
-siteconf:1002: result: 2
-siteconf:1009: checking for int
-siteconf:1036: gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include conftest.c >&5
-siteconf:1039: $? = 0
-siteconf:1042: test -s conftest.o
-siteconf:1045: $? = 0
-siteconf:1055: result: yes
-siteconf:1058: checking size of int
-siteconf:1336: gcc-3.3 -o conftest -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include  conftest.c  >&5
-siteconf:1339: $? = 0
-siteconf:1341: ./conftest
-siteconf:1344: $? = 0
-siteconf:1364: result: 4
-siteconf:1372: checking for u_intXX_t types
-siteconf:1397: gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include conftest.c >&5
-siteconf:1400: $? = 0
-siteconf:1403: test -s conftest.o
-siteconf:1406: $? = 0
-siteconf:1418: result: yes
-siteconf:1539: checking for uintXX_t types in stdint.h
-siteconf:1560: gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include conftest.c >&5
-siteconf:1563: $? = 0
-siteconf:1566: test -s conftest.o
-siteconf:1569: $? = 0
-siteconf:1576: result: yes
-siteconf:1591: checking for inet_aton
-siteconf:1619: gcc-3.3 -o conftest -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include  conftest.c  >&5
-siteconf:1622: $? = 0
-siteconf:1624: ./conftest
-siteconf:1627: $? = 0
-siteconf:1633: result: yes
-siteconf:1648: checking for inet_pton
-siteconf:1676: gcc-3.3 -o conftest -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include  conftest.c  >&5
-siteconf:1679: $? = 0
-siteconf:1681: ./conftest
-siteconf:1684: $? = 0
-siteconf:1690: result: yes
-siteconf:1706: checking ENDIANness
-siteconf:1737: gcc-3.3 -o conftest -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/opt/local/include  conftest.c  >&5
-siteconf:1740: $? = 0
-siteconf:1742: ./conftest
-siteconf:1745: $? = 0
-siteconf:1751: result: BIG_ENDIAN
diff --git a/Lite/Util/docs/rfc1884.txt b/Lite/Util/docs/rfc1884.txt
deleted file mode 100644
index 76f8e88..0000000
--- a/Lite/Util/docs/rfc1884.txt
+++ /dev/null
@@ -1,1023 +0,0 @@
-Network Working Group                       R. Hinden, Ipsilon Networks
-Request for Comments: 1884                       S. Deering, Xerox PARC
-Category: Standards Track                                       Editors
-                                                          December 1995
-
-
-                  IP Version 6 Addressing Architecture
-
-
-
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-
-Abstract
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
-   model, text representations of IPv6 addresses, definition of IPv6
-   unicast addresses, anycast addresses, and multicast addresses, and an
-   IPv6 nodes required addresses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 1]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-Table of Contents
-
-   1. Introduction................................................3
-
-   2. IPv6 Addressing.............................................3
-      2.1 Addressing Model........................................4
-      2.2 Text Representation of Addresses........................4
-      2.3 Address Type Representation.............................5
-      2.4 Unicast Addresses.......................................7
-        2.4.1 Unicast Address Example.............................8
-        2.4.2 The Unspecified Address.............................9
-        2.4.3 The Loopback Address................................9
-        2.4.4 IPv6 Addresses with Embedded IPv4 Addresses.........9
-        2.4.5 NSAP Addresses......................................10
-        2.4.6 IPX Addresses.......................................10
-        2.4.7 Provider-Based Global Unicast Addresses.............10
-        2.4.8 Local-use IPv6 Unicast Addresses....................11
-      2.5 Anycast Addresses.......................................12
-        2.5.1 Required Anycast Address............................13
-      2.6 Multicast Addresses.....................................14
-        2.6.1 Pre-Defined Multicast Addresses.....................15
-      2.7 A Node's Required Addresses.............................17
-
-   REFERENCES.....................................................18
-
-   SECURITY CONSIDERATIONS........................................18
-
-   DOCUMENT EDITOR'S ADDRESSES....................................18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 2]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-1.0 INTRODUCTION
-
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol.  It includes a detailed description of the
-   currently defined address formats for IPv6 [IPV6].
-
-   The editors would like to acknowledge the contributions of Paul
-   Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob
-   Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark,
-   Yakov Rekhter, Bill Simpson, and Sue Thomson.
-
-2.0 IPv6 ADDRESSING
-
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces.  There are three types of addresses:
-
-
-       Unicast:   An identifier for a single interface.  A packet sent
-                  to a unicast address is delivered to the interface
-                  identified by that address.
-
-       Anycast:   An identifier for a set of interfaces (typically
-                  belonging to different nodes).  A packet sent to an
-                  anycast address is delivered to one of the interfaces
-                  identified by that address (the "nearest" one,
-                  according to the routing protocols' measure of
-                  distance).
-
-       Multicast: An identifier for a set of interfaces (typically
-                  belonging to different nodes).  A packet sent to a
-                  multicast address is delivered to all interfaces
-                  identified by that address.
-
-   There are no broadcast addresses in IPv6, their function being
-   superseded by multicast addresses.
-
-   In this document, fields in addresses are given a specific name, for
-   example "subscriber".  When this name is used with the term "ID" for
-   identifier after the name (e.g., "subscriber ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g., "subscriber prefix") it refers to all of the address up to and
-   including this field.
-
-   In IPv6, all zeros and all ones are legal values for any field,
-   unless specifically excluded.  Specifically, prefixes may contain
-   zero-valued fields or end in zeros.
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 3]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   2.1 Addressing Model
-
-   IPv6 Addresses of all types are assigned to interfaces, not nodes.
-   Since each interface belongs to a single node, any of that node's
-   interfaces' unicast addresses may be used as an identifier for the
-   node.
-
-   An IPv6 unicast address refers to a single interface.  A single
-   interface may be assigned multiple IPv6 addresses of any type
-   (unicast, anycast, and multicast).  There are two exceptions to this
-   model.  These are:
-
-     1) A single address may be assigned to multiple physical interfaces
-        if the implementation treats the multiple physical interfaces as
-        one interface when presenting it to the internet layer.  This is
-        useful for load-sharing over multiple physical interfaces.
-
-     2) Routers may have unnumbered interfaces (i.e., no IPv6 address
-        assigned to the interface) on point-to-point links to eliminate
-        the necessity to manually configure and advertise the addresses.
-        Addresses are not needed for point-to-point interfaces on
-        routers if those interfaces are not to be used as the origins or
-        destinations of any IPv6 datagrams.
-
-   IPv6 continues the IPv4 model that a subnet is associated with one
-   link.  Multiple subnets may be assigned to the same link.
-
-
-   2.2 Text Representation of Addresses
-
-   There are three conventional forms for representing IPv6 addresses as
-   text strings:
-
-     1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
-        hexadecimal values of the eight 16-bit pieces of the address.
-        Examples:
-
-                   FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
-                   1080:0:0:0:8:800:200C:417A
-
-        Note that it is not necessary to write the leading zeros in an
-        individual field, but there must be at least one numeral in
-        every field (except for the case described in 2.).
-
-     2. Due to the method of allocating certain styles of IPv6
-        addresses, it will be common for addresses to contain long
-        strings of zero bits.  In order to make writing addresses
-
-
-
-Hinden & Deering            Standards Track                     [Page 4]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-        containing zero bits easier a special syntax is available to
-        compress the zeros.  The use of "::" indicates multiple groups
-        of 16-bits of zeros.  The "::" can only appear once in an
-        address.  The "::" can also be used to compress the leading
-        and/or trailing zeros in an address.
-
-        For example the following addresses:
-
-             1080:0:0:0:8:800:200C:417A  a unicast address
-             FF01:0:0:0:0:0:0:43         a multicast address
-             0:0:0:0:0:0:0:1             the loopback address
-             0:0:0:0:0:0:0:0             the unspecified addresses
-
-        may be represented as:
-
-             1080::8:800:200C:417A       a unicast address
-             FF01::43                    a multicast address
-             ::1                         the loopback address
-             ::                          the unspecified addresses
-
-     3. 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
-
-
-   2.3 Address Type Representation
-
-   The specific type of an IPv6 address is indicated by the leading bits
-   in the address.  The variable-length field comprising these leading
-   bits is called the Format Prefix (FP).  The initial allocation of
-   these prefixes is as follows:
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 5]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-        Allocation                         Prefix         Fraction of
-                                           (binary)       Address Space
-        -------------------------------    --------       -------------
-        Reserved                           0000 0000      1/256
-        Unassigned                         0000 0001      1/256
-
-        Reserved for NSAP Allocation       0000 001       1/128
-        Reserved for IPX Allocation        0000 010       1/128
-
-        Unassigned                         0000 011       1/128
-        Unassigned                         0000 1         1/32
-        Unassigned                         0001           1/16
-        Unassigned                         001            1/8
-
-        Provider-Based Unicast Address     010            1/8
-
-        Unassigned                         011            1/8
-
-        Reserved for Geographic-
-        Based Unicast Addresses            100            1/8
-
-        Unassigned                         101            1/8
-        Unassigned                         110            1/8
-        Unassigned                         1110           1/16
-        Unassigned                         1111 0         1/32
-        Unassigned                         1111 10        1/64
-        Unassigned                         1111 110       1/128
-
-        Unassigned                         1111 1110 0    1/512
-
-        Link Local Use Addresses           1111 1110 10   1/1024
-        Site Local Use Addresses           1111 1110 11   1/1024
-
-        Multicast Addresses                1111 1111      1/256
-
-        Note: The "unspecified address" (see section 2.4.2), the
-        loopback address (see section 2.4.3), and the IPv6 Addresses
-        with Embedded IPv4 Addresses (see section 2.4.4), are assigned
-        out of the 0000 0000 format prefix space.
-
-
-   This allocation supports the direct allocation of provider addresses,
-   local use addresses, and multicast addresses.  Space is reserved for
-   NSAP addresses, IPX addresses, and geographic addresses.  The
-   remainder of the address space is unassigned for future use.  This
-   can be used for expansion of existing use (e.g., additional provider
-   addresses, etc.) or new uses (e.g., separate locators and
-   identifiers).  Fifteen percent of the address space is initially
-
-
-
-Hinden & Deering            Standards Track                     [Page 6]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   allocated.  The remaining 85% is reserved for future use.
-
-   Unicast addresses are distinguished from multicast addresses by the
-   value of the high-order octet of the addresses: a value of FF
-   (11111111) identifies an address as a multicast address; any other
-   value identifies an address as a unicast address.  Anycast addresses
-   are taken from the unicast address space, and are not syntactically
-   distinguishable from unicast addresses.
-
-
-   2.4 Unicast Addresses
-
-   The IPv6 unicast address is contiguous bit-wise maskable, similar to
-   IPv4 addresses under Class-less Interdomain Routing [CIDR].
-
-   There are several forms of unicast address assignment in IPv6,
-   including the global provider based unicast address, the geographic
-   based unicast address, the NSAP address, the IPX hierarchical
-   address, the site-local-use address, the link-local-use address, and
-   the IPv4-capable host address.  Additional address types can be
-   defined in the future.
-
-   IPv6 nodes may have considerable or little knowledge of the internal
-   structure of the IPv6 address, depending on the role the node plays
-   (for instance, host versus router).  At a minimum, a node may
-   consider that unicast addresses (including its own) have no internal
-   structure:
-
-    |                           128 bits                              |
-    +-----------------------------------------------------------------+
-    |                          node address                           |
-    +-----------------------------------------------------------------+
-
-
-   A slightly sophisticated host (but still rather simple) may
-   additionally be aware of subnet prefix(es) for the link(s) it is
-   attached to, where different addresses may have different values for
-   n:
-
-    |                         n bits                 |   128-n bits   |
-    +------------------------------------------------+----------------+
-    |                   subnet prefix                | interface ID   |
-    +------------------------------------------------+----------------+
-
-
-   Still more sophisticated hosts may be aware of other hierarchical
-   boundaries in the unicast address.  Though a very simple router may
-   have no knowledge of the internal structure of IPv6 unicast
-
-
-
-Hinden & Deering            Standards Track                     [Page 7]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   addresses, routers will more generally have knowledge of one or more
-   of the hierarchical boundaries for the operation of routing
-   protocols.  The known boundaries will differ from router to router,
-   depending on what positions the router holds in the routing
-   hierarchy.
-
-
-   2.4.1 Unicast Address Examples
-
-   An example of a Unicast address format which will likely be common on
-   LANs and other environments where IEEE 802 MAC addresses are
-   available is:
-
-
-    |              n bits            | 80-n bits |     48 bits        |
-    +--------------------------------+-----------+--------------------+
-    |        subscriber prefix       | subnet ID |   interface ID     |
-    +--------------------------------+-----------+--------------------+
-
-   Where the 48-bit Interface ID is an IEEE-802 MAC address.  The use of
-   IEEE 802 MAC addresses as a interface ID is expected to be very
-   common in environments where nodes have an IEEE 802 MAC address.  In
-   other environments, where IEEE 802 MAC addresses are not available,
-   other types of link layer addresses can be used, such as E.164
-   addresses, for the interface ID.
-
-   The inclusion of a unique global interface identifier, such as an
-   IEEE MAC address, makes possible a very simple form of auto-
-   configuration of addresses.  A node may discover a subnet ID by
-   listening to Router Advertisement messages sent by a router on its
-   attached link(s), and then fabricating an IPv6 address for itself by
-   using its IEEE MAC address as the interface ID on that subnet.
-
-   Another unicast address format example is where a site or
-   organization requires additional layers of internal hierarchy.  In
-   this example the subnet ID is divided into an area ID and a subnet
-   ID.  Its format is:
-
-    |         s bits       | n bits  |   m bits     | 128-s-n-m bits  |
-    +----------------------+---------+--------------+-----------------+
-    |   subscriber prefix  | area ID |  subnet ID   |  interface ID   |
-    +----------------------+---------+--------------+-----------------+
-
-   This technique can be continued to allow a site or organization to
-   add additional layers of internal hierarchy.  It may be desirable to
-   use an interface ID smaller than a 48-bit IEEE 802 MAC address to
-   allow more space for the additional layers of internal hierarchy.
-   These could be interface IDs which are administratively created by
-
-
-
-Hinden & Deering            Standards Track                     [Page 8]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   the site or organization.
-
-
-   2.4.2 The Unspecified Address
-
-   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
-   must never be assigned to any node.  It indicates the absence of an
-   address.  One example of its use is in the Source Address field of
-   any IPv6 datagrams sent by an initializing host before it has learned
-   its own address.
-
-   The unspecified address must not be used as the destination address
-   of IPv6 datagrams or in IPv6 Routing Headers.
-
-
-   2.4.3 The Loopback Address
-
-   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
-   It may be used by a node to send an IPv6 datagram to itself.  It may
-   never be assigned to any interface.
-
-   The loopback address must not be used as the source address in IPv6
-   datagrams that are sent outside of a single node.  An IPv6 datagram
-   with a destination address of loopback must never be sent outside of
-   a single node.
-
-
-   2.4.4 IPv6 Addresses with Embedded IPv4 Addresses
-
-   The IPv6 transition mechanisms include a technique for hosts and
-   routers to dynamically tunnel IPv6 packets over IPv4 routing
-   infrastructure.  IPv6 nodes that utilize this technique are assigned
-   special IPv6 unicast addresses that carry an IPv4 address in the
-   low-order 32-bits.  This type of address is termed an "IPv4-
-   compatible IPv6 address" and has the format:
-
-
-    |                80 bits               | 16 |      32 bits        |
-    +--------------------------------------+--------------------------+
-    |0000..............................0000|0000|    IPv4 address     |
-    +--------------------------------------+----+---------------------+
-
-
-   A second type of IPv6 address which holds an embedded IPv4 address is
-   also defined.  This address is used to represent the addresses of
-   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
-   This type of address is termed an "IPv4-mapped IPv6 address" and has
-   the format:
-
-
-
-Hinden & Deering            Standards Track                     [Page 9]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-
-    |                80 bits               | 16 |      32 bits        |
-    +--------------------------------------+--------------------------+
-    |0000..............................0000|FFFF|    IPv4 address     |
-    +--------------------------------------+----+---------------------+
-
-
-
-   2.4.5 NSAP Addresses
-
-   This mapping of NSAP address into IPv6 addresses is as follows:
-
-
-    |   7   |                   121 bits                              |
-    +-------+---------------------------------------------------------+
-    |0000001|                 to be defined                           |
-    +-------+---------------------------------------------------------+
-
-   The draft definition, motivation, and usage are under study [NSAP].
-
-
-   2.4.6 IPX Addresses
-
-   This mapping of IPX address into IPv6 addresses is as follows:
-
-
-    |   7   |                   121 bits                              |
-    +-------+---------------------------------------------------------+
-    |0000010|                 to be defined                           |
-    +-------+---------------------------------------------------------+
-
-   The draft definition, motivation, and usage are under study.
-
-
-   2.4.7 Provider-Based Global Unicast Addresses
-
-   The global provider-based unicast address is assigned as described in
-   [ALLOC].  This initial assignment plan for these unicast addresses is
-   similar to assignment of IPv4 addresses under the CIDR scheme [CIDR].
-   The IPv6 global provider-based unicast address format is as follows:
-
-
-    | 3 |  n bits   |  m bits   |   o bits    |   125-n-m-o bits   |
-    +---+-----------+-----------+-------------+--------------------+
-    |010|registry ID|provider ID|subscriber ID|  intra-subscriber  |
-    +---+-----------+-----------+-------------+--------------------+
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 10]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   The high-order part of the address is assigned to registries, who
-   then assign portions of the address space to providers, who then
-   assign portions of the address space to subscribers, etc.
-
-   The registry ID identifies the registry which assigns the provider
-   portion of the address.  The term "registry prefix" refers to the
-   high-order part of the address up to and including the registry ID.
-
-   The provider ID identifies a specific provider which assigns the
-   subscriber portion of the address.  The term "provider prefix" refers
-   to the high-order part of the address up to and including the
-   provider ID.
-
-   The subscriber ID distinguishes among multiple subscribers attached
-   to the provider identified by the provider ID.  The term "subscriber
-   prefix" refers to the high-order part of the address up to and
-   including the subscriber ID.
-
-   The intra-subscriber portion of the address is defined by an
-   individual subscriber and is organized according to the subscribers
-   local internet topology.  It is likely that many subscribers will
-   choose to divide the intra-subscriber portion of the address into a
-   subnet ID and an interface ID.  In this case the subnet ID identifies
-   a specific physical link and the interface ID identifies a single
-   interface on that subnet.
-
-
-   2.4.8 Local-use IPv6 Unicast Addresses
-
-   There are two types of local-use unicast addresses defined.  These
-   are Link-Local and Site-Local.  The Link-Local is for use on a single
-   link and the Site-Local is for use in a single site.  Link-Local
-   addresses have the following format:
-
-    |   10     |
-    |  bits    |        n bits           |       118-n bits           |
-    +----------+-------------------------+----------------------------+
-    |1111111010|           0             |       interface ID         |
-    +----------+-------------------------+----------------------------+
-
-   Link-Local addresses are designed to be used for addressing on a
-   single link for purposes such as auto-address configuration, neighbor
-   discovery, or when no routers are present.
-
-   Routers MUST not forward any packets with link-local source
-   addresses.
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 11]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   Site-Local addresses have the following format:
-
-    |   10     |
-    |  bits    | n bits  |    m bits     |       118-n-m bits         |
-    +----------+---------+---------------+----------------------------+
-    |1111111011|    0    |   subnet ID   |       interface ID         |
-    +----------+---------+---------------+----------------------------+
-
-
-   Site-Local addresses may be used for sites or organizations that are
-   not (yet) connected to the global Internet.  They do not need to
-   request or "steal" an address prefix from the global Internet address
-   space.  IPv6 site-local addresses can be used instead.  When the
-   organization connects to the global Internet, it can then form global
-   addresses by replacing the site-local prefix with a subscriber
-   prefix.
-
-   Routers MUST not forward any packets with site-local source addresses
-   outside of the site.
-
-   2.5 Anycast Addresses
-
-   An IPv6 anycast address is an address that is assigned to more than
-   one interface (typically belonging to different nodes), with the
-   property that a packet sent to an anycast address is routed to the
-   "nearest" interface having that address, according to the routing
-   protocols' measure of distance.
-
-   Anycast addresses are allocated from the unicast address space, using
-   any of the defined unicast address formats.  Thus, anycast addresses
-   are syntactically indistinguishable from unicast addresses.  When a
-   unicast address is assigned to more than one interface, thus turning
-   it into an anycast address, the nodes to which the address is
-   assigned must be explicitly configured to know that it is an anycast
-   address.
-
-   For any assigned anycast address, there is a longest address prefix P
-   that identifies the topological region in which all interfaces
-   belonging to that anycast address reside.  Within the region
-   identified by P, each member of the anycast set must be advertised as
-   a separate entry in the routing system (commonly referred to as a
-   "host route"); outside the region identified by P, the anycast
-   address may be aggregated into the routing advertisement for prefix
-   P.
-
-   Note that in, the worst case, the prefix P of an anycast set may be
-   the null prefix, i.e., the members of the set may have no topological
-   locality.  In that case, the anycast address must be advertised as a
-
-
-
-Hinden & Deering            Standards Track                    [Page 12]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   separate routing entry throughout the entire internet, which presents
-   a severe scaling limit on how many such "global" anycast sets may be
-   supported.  Therefore, it is expected that support for global anycast
-   sets may be unavailable or very restricted.
-
-   One expected use of anycast addresses is to identify the set of
-   routers belonging to an internet service provider.  Such addresses
-   could be used as intermediate addresses in an IPv6 Routing header, to
-   cause a packet to be delivered via a particular provider or sequence
-   of providers.  Some other possible uses are to identify the set of
-   routers attached to a particular subnet, or the set of routers
-   providing entry into a particular routing domain.
-
-   There is little experience with widespread, arbitrary use of internet
-   anycast addresses, and some known complications and hazards when
-   using them in their full generality [ANYCST].  Until more experience
-   has been gained and solutions agreed upon for those problems, the
-   following restrictions are imposed on IPv6 anycast addresses:
-
-      o An anycast address MUST NOT be used as the source address of an
-        IPv6 packet.
-
-      o An anycast address MUST NOT be assigned to an IPv6 host, that
-        is, it may be assigned to an IPv6 router only.
-
-
-   2.5.1 Required Anycast Address
-
-   The Subnet-Router anycast address is predefined.  It's format is as
-   follows:
-
-
-    |                         n bits                 |   128-n bits   |
-    +------------------------------------------------+----------------+
-    |                   subnet prefix                | 00000000000000 |
-    +------------------------------------------------+----------------+
-
-
-   The "subnet prefix" in an anycast address is the prefix which
-   identifies a specific link.  This anycast address is syntactically
-   the same as a unicast address for an interface on the link with the
-   interface identifier set to zero.
-
-   Packets sent to the Subnet-Router anycast address will be delivered
-   to one router on the subnet.  All routers are required to support the
-   Subnet-Router anycast addresses for the subnets which they have
-   interfaces.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 13]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   The subnet-router anycast address is intended to be used for
-   applications where a node needs to communicate with one of a set of
-   routers on a remote subnet.  For example when a mobile host needs to
-   communicate with one of the mobile agents on it's "home" subnet.
-
-
-   2.6 Multicast Addresses
-
-   An IPv6 multicast address is an identifier for a group of nodes.  A
-   node may belong to any number of multicast groups.  Multicast
-   addresses have the following format:
-
-    |   8    |  4 |  4 |                  112 bits                   |
-    +------ -+----+----+---------------------------------------------+
-    |11111111|flgs|scop|                  group ID                   |
-    +--------+----+----+---------------------------------------------+
-
-        11111111 at the start of the address identifies the address as
-        being a multicast address.
-
-                                      +-+-+-+-+
-        flgs is a set of 4 flags:     |0|0|0|T|
-                                      +-+-+-+-+
-
-             The high-order 3 flags are reserved, and must be
-             initialized to 0.
-
-             T = 0 indicates a permanently-assigned ("well-known")
-             multicast address, assigned by the global internet
-             numbering authority.
-
-             T = 1 indicates a non-permanently-assigned ("transient")
-             multicast address.
-
-        scop is a 4-bit multicast scope value used to limit the scope of
-        the multicast group.  The values are:
-
-             0  reserved
-             1  node-local scope
-             2  link-local scope
-             3  (unassigned)
-             4  (unassigned)
-             5  site-local scope
-             6  (unassigned)
-             7  (unassigned)
-             8  organization-local scope
-             9  (unassigned)
-             A  (unassigned)
-
-
-
-Hinden & Deering            Standards Track                    [Page 14]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-             B  (unassigned)
-             C  (unassigned)
-             D  (unassigned)
-             E  global scope
-             F  reserved
-
-        group ID identifies the multicast group, either permanent or
-        transient, within the given scope.
-
-   The "meaning" of a permanently-assigned multicast address is
-   independent of the scope value.  For example, if the "NTP servers
-   group" is assigned a permanent multicast address with a group ID of
-   43 (hex), then:
-
-        FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as
-        the sender.
-
-        FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as
-        the sender.
-
-        FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as
-        the sender.
-
-        FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet.
-
-   Non-permanently-assigned multicast addresses are meaningful only
-   within a given scope.  For example, a group identified by the non-
-   permanent, site-local multicast address FF15:0:0:0:0:0:0:43 at one
-   site bears no relationship to a group using the same address at a
-   different site, nor to a non-permanent group using the same group ID
-   with different scope, nor to a permanent group with the same group
-   ID.
-
-   Multicast addresses must not be used as source addresses in IPv6
-   datagrams or appear in any routing header.
-
-
-   2.6.1 Pre-Defined Multicast Addresses
-
-   The following well-known multicast addresses are pre-defined:
-
-        Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
-                                        FF01:0:0:0:0:0:0:0
-                                        FF02:0:0:0:0:0:0:0
-                                        FF03:0:0:0:0:0:0:0
-                                        FF04:0:0:0:0:0:0:0
-                                        FF05:0:0:0:0:0:0:0
-                                        FF06:0:0:0:0:0:0:0
-
-
-
-Hinden & Deering            Standards Track                    [Page 15]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-                                        FF07:0:0:0:0:0:0:0
-                                        FF08:0:0:0:0:0:0:0
-                                        FF09:0:0:0:0:0:0:0
-                                        FF0A:0:0:0:0:0:0:0
-                                        FF0B:0:0:0:0:0:0:0
-                                        FF0C:0:0:0:0:0:0:0
-                                        FF0D:0:0:0:0:0:0:0
-                                        FF0E:0:0:0:0:0:0:0
-                                        FF0F:0:0:0:0:0:0:0
-
-   The above multicast addresses are reserved and shall never be
-   assigned to any multicast group.
-
-        All Nodes Addresses:    FF01:0:0:0:0:0:0:1
-                                FF02:0:0:0:0:0:0:1
-
-   The above multicast addresses identify the group of all IPv6 nodes,
-   within scope 1 (node-local) or 2 (link-local).
-
-        All Routers Addresses:   FF01:0:0:0:0:0:0:2
-                                 FF02:0:0:0:0:0:0:2
-
-   The above multicast addresses identify the group of all IPv6 routers,
-   within scope 1 (node-local) or 2 (link-local).
-
-        DHCP Server/Relay-Agent: FF02:0:0:0:0:0:0:C
-
-   The above multicast addresses identify the group of all IPv6 DHCP
-   Servers and Relay Agents within scope 2 (link-local).
-
-        Solicited-Node Address:  FF02:0:0:0:0:1:XXXX:XXXX
-
-   The above multicast address is computed as a function of a node's
-   unicast and anycast addresses.  The solicited-node multicast address
-   is formed by taking the low-order 32 bits of the address (unicast or
-   anycast) and appending those bits to the 96-bit prefix FF02:0:0:0:0:1
-   resulting in a multicast address in the range
-
-           FF02:0:0:0:0:1:0000:0000
-
-   to
-
-           FF02:0:0:0:0:1:FFFF:FFFF
-
-   For example, the solicited node multicast address corresponding to
-   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:200E:8C6C.  IPv6
-   addresses that differ only in the high-order bits, e.g., due to
-   multiple high-order prefixes associated with different providers,
-
-
-
-Hinden & Deering            Standards Track                    [Page 16]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-   will map to the same solicited-node address thereby reducing the
-   number of multicast addresses a node must join.
-
-   A node is required to compute and support a Solicited-Node multicast
-   addresses for every unicast and anycast address it is assigned.
-
-   2.7 A Node's Required Addresses
-
-   A host is required to recognize the following addresses as
-   identifying itself:
-
-      o Its Link-Local Address for each interface
-      o Assigned Unicast Addresses
-      o Loopback Address
-      o All-Nodes Multicast Address
-      o Solicited-Node Multicast Address for each of its assigned
-        unicast and anycast addresses
-      o Multicast Addresses of all other groups which the host belongs.
-
-   A router is required to recognize the following addresses as
-   identifying itself:
-
-      o Its Link-Local Address for each interface
-      o Assigned Unicast Addresses
-      o Loopback Address
-      o The Subnet-Router anycast addresses for the links it has
-        interfaces.
-      o All other Anycast addresses with which the router has been
-        configured.
-      o All-Nodes Multicast Address
-      o All-Router Multicast Address
-      o Solicited-Node Multicast Address for each of its assigned
-        unicast and anycast addresses
-      o Multicast Addresses of all other groups which the router
-        belongs.
-
-   The only address prefixes which should be predefined in an
-   implementation are the:
-
-      o Unspecified Address
-      o Loopback Address
-      o Multicast Prefix (FF)
-      o Local-Use Prefixes (Link-Local and Site-Local)
-      o Pre-Defined Multicast Addresses
-      o IPv4-Compatible Prefixes
-
-   Implementations should assume all other addresses are unicast unless
-   specifically configured (e.g., anycast addresses).
-
-
-
-Hinden & Deering            Standards Track                    [Page 17]
-
-
-RFC 1884              IPv6 Addressing Architecture         December 1995
-
-
-REFERENCES
-
-     [ALLOC] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast
-             Address Allocation", RFC 1887, cisco Systems, December
-             1995.
-
-     [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
-             Anycasting Service", RFC 1546, BBN, November 1993.
-
-     [CIDR] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting:
-             an Address Assignment and Aggregation Strategy", RFC 1338,
-             BARRNet, cisco, Merit, OARnet, June 1992.
-
-     [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol,
-             Version 6 (IPv6) Specification", RFC 1883, Xerox PARC,
-             Ipsilon Networks, December 1995.
-
-     [MULT] Deering, S., "Host Extensions for IP multicasting", STD 5,
-             RFC 1112, Stanford University, August 1989.
-
-     [NSAP] Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and
-             TP over IPv6", Work in Progress.
-
-
-
-SECURITY CONSIDERATIONS
-
-   Security issues are not discussed in this document.
-
-
-DOCUMENT EDITOR'S ADDRESSES
-
-   Robert M. Hinden                     Stephen E. Deering
-   Ipsilon Networks, Inc.               Xerox Palo Alto Research Center
-   2191 E. Bayshore Road, Suite 100     3333 Coyote Hill Road
-   Palo Alto, CA 94303                  Palo Alto, CA 94304
-   USA                                  USA
-
-   Phone: +1 415 846 4604               Phone: +1 415 812 4839
-   Fax:   +1 415 855 1414               Fax:   +1 415 812 4471
-   EMail: hinden@ipsilon.com            EMail: deering@parc.xerox.com
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 18]
diff --git a/Lite/Util/localStuff.h b/Lite/Util/localStuff.h
deleted file mode 100644
index 0db9456..0000000
--- a/Lite/Util/localStuff.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* ****************************************************	*
- *		## localStuff.h  ##			*
- *		## ----------- ##			*
- *							*
- * This file was generated automatically by 'siteconf'.	*
- * Don't edit this file, edit 'siteconf' instead.	*
- *							*
- * ****************************************************	*/
-#ifdef host_is_BIG_ENDIAN
-#undef host_is_BIG_ENDIAN
-#endif
-#ifdef host_is_LITTLE_ENDIAN
-#undef host_is_LITTLE_ENDIAN
-#endif
-#define SIZEOF_CHAR 1
-#define SIZEOF_SHORT_INT 2
-#define SIZEOF_INT 4
-#define HAVE_U_INTXX_T 1
-#define HAVE_UINTXX_T 2
-#define LOCAL_HAVE_inet_aton
-#define LOCAL_HAVE_inet_pton
-#define host_is_BIG_ENDIAN
diff --git a/Lite/Util/pm_to_blib b/Lite/Util/pm_to_blib
deleted file mode 100644
index e69de29..0000000
--- a/Lite/Util/pm_to_blib
+++ /dev/null
diff --git a/Lite/pm_to_blib b/Lite/pm_to_blib
deleted file mode 100644
index e69de29..0000000
--- a/Lite/pm_to_blib
+++ /dev/null
diff --git a/MANIFEST b/MANIFEST
index 46cdb2b..f282cb2 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -1,11 +1,10 @@
 Changes
+docs/rfc1884.txt
 IP.pm
 Lite/Changes
 Lite/Lite.pm
 Lite/Makefile.PL
-Lite/MANIFEST.SKIP
 Lite/META.yml
-Lite/pm_to_blib
 Lite/README
 Lite/t/addr.t
 Lite/t/aton.t
@@ -58,14 +57,9 @@
 Lite/t/version.t
 Lite/t/within.t
 Lite/Util/Changes
-Lite/Util/config.log
-Lite/Util/docs/rfc1884.txt
 Lite/Util/GPL
 Lite/Util/lib/NetAddr/IP/UtilPP.pm
-Lite/Util/localStuff.h
 Lite/Util/Makefile.PL
-Lite/Util/MANIFEST.SKIP
-Lite/Util/pm_to_blib
 Lite/Util/README
 Lite/Util/siteconf
 Lite/Util/t/4to6.t
@@ -93,9 +87,6 @@
 Lite/Util/t/sub128.t
 Lite/Util/typemap
 Lite/Util/u_intxx.h
-Lite/Util/Util.bs
-Lite/Util/Util.c
-Lite/Util/Util.o
 Lite/Util/Util.pm
 Lite/Util/Util.xs
 Lite/Util/xs_include/inet_aton.c
diff --git a/MANIFEST.SKIP b/MANIFEST.SKIP
index 1e28ae6..738c068 100644
--- a/MANIFEST.SKIP
+++ b/MANIFEST.SKIP
@@ -4,7 +4,7 @@
 ^blibdirs
 Makefile$
 Makefile\.[a-z]+$
-^pm_to_blib
+pm_to_blib
 CVS/.*
 \.cvs
 ,v$
@@ -12,6 +12,7 @@
 \.old$
 \.bak$
 \.tmp$
+\.xsc$
 ~$
 ^#
 \.shar$
@@ -20,4 +21,7 @@
 \.tar\.gz$
 \.zip$
 _uu$
-Lite/Util/Util_IS.pm
+Util_IS\.pm$
+Util\.(bs|[co])$
+localStuff\.h$
+config\.log$
diff --git a/META.yml b/META.yml
index 0a56dfc..6fa6318 100644
--- a/META.yml
+++ b/META.yml
@@ -1,7 +1,7 @@
 # http://module-build.sourceforge.net/META-spec.html
 #XXXXXXX This is a prototype!!!  It will change in the future!!! XXXXX#
 name:         NetAddr-IP
-version:      4.003
+version:      4.004
 version_from: IP.pm
 installdirs:  site
 requires:
diff --git a/docs/rfc1884.txt b/docs/rfc1884.txt
new file mode 100644
index 0000000..76f8e88
--- /dev/null
+++ b/docs/rfc1884.txt
@@ -0,0 +1,1023 @@
+Network Working Group                       R. Hinden, Ipsilon Networks
+Request for Comments: 1884                       S. Deering, Xerox PARC
+Category: Standards Track                                       Editors
+                                                          December 1995
+
+
+                  IP Version 6 Addressing Architecture
+
+
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
+   model, text representations of IPv6 addresses, definition of IPv6
+   unicast addresses, anycast addresses, and multicast addresses, and an
+   IPv6 nodes required addresses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 1]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+Table of Contents
+
+   1. Introduction................................................3
+
+   2. IPv6 Addressing.............................................3
+      2.1 Addressing Model........................................4
+      2.2 Text Representation of Addresses........................4
+      2.3 Address Type Representation.............................5
+      2.4 Unicast Addresses.......................................7
+        2.4.1 Unicast Address Example.............................8
+        2.4.2 The Unspecified Address.............................9
+        2.4.3 The Loopback Address................................9
+        2.4.4 IPv6 Addresses with Embedded IPv4 Addresses.........9
+        2.4.5 NSAP Addresses......................................10
+        2.4.6 IPX Addresses.......................................10
+        2.4.7 Provider-Based Global Unicast Addresses.............10
+        2.4.8 Local-use IPv6 Unicast Addresses....................11
+      2.5 Anycast Addresses.......................................12
+        2.5.1 Required Anycast Address............................13
+      2.6 Multicast Addresses.....................................14
+        2.6.1 Pre-Defined Multicast Addresses.....................15
+      2.7 A Node's Required Addresses.............................17
+
+   REFERENCES.....................................................18
+
+   SECURITY CONSIDERATIONS........................................18
+
+   DOCUMENT EDITOR'S ADDRESSES....................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 2]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+1.0 INTRODUCTION
+
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol.  It includes a detailed description of the
+   currently defined address formats for IPv6 [IPV6].
+
+   The editors would like to acknowledge the contributions of Paul
+   Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob
+   Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark,
+   Yakov Rekhter, Bill Simpson, and Sue Thomson.
+
+2.0 IPv6 ADDRESSING
+
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces.  There are three types of addresses:
+
+
+       Unicast:   An identifier for a single interface.  A packet sent
+                  to a unicast address is delivered to the interface
+                  identified by that address.
+
+       Anycast:   An identifier for a set of interfaces (typically
+                  belonging to different nodes).  A packet sent to an
+                  anycast address is delivered to one of the interfaces
+                  identified by that address (the "nearest" one,
+                  according to the routing protocols' measure of
+                  distance).
+
+       Multicast: An identifier for a set of interfaces (typically
+                  belonging to different nodes).  A packet sent to a
+                  multicast address is delivered to all interfaces
+                  identified by that address.
+
+   There are no broadcast addresses in IPv6, their function being
+   superseded by multicast addresses.
+
+   In this document, fields in addresses are given a specific name, for
+   example "subscriber".  When this name is used with the term "ID" for
+   identifier after the name (e.g., "subscriber ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g., "subscriber prefix") it refers to all of the address up to and
+   including this field.
+
+   In IPv6, all zeros and all ones are legal values for any field,
+   unless specifically excluded.  Specifically, prefixes may contain
+   zero-valued fields or end in zeros.
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 3]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   2.1 Addressing Model
+
+   IPv6 Addresses of all types are assigned to interfaces, not nodes.
+   Since each interface belongs to a single node, any of that node's
+   interfaces' unicast addresses may be used as an identifier for the
+   node.
+
+   An IPv6 unicast address refers to a single interface.  A single
+   interface may be assigned multiple IPv6 addresses of any type
+   (unicast, anycast, and multicast).  There are two exceptions to this
+   model.  These are:
+
+     1) A single address may be assigned to multiple physical interfaces
+        if the implementation treats the multiple physical interfaces as
+        one interface when presenting it to the internet layer.  This is
+        useful for load-sharing over multiple physical interfaces.
+
+     2) Routers may have unnumbered interfaces (i.e., no IPv6 address
+        assigned to the interface) on point-to-point links to eliminate
+        the necessity to manually configure and advertise the addresses.
+        Addresses are not needed for point-to-point interfaces on
+        routers if those interfaces are not to be used as the origins or
+        destinations of any IPv6 datagrams.
+
+   IPv6 continues the IPv4 model that a subnet is associated with one
+   link.  Multiple subnets may be assigned to the same link.
+
+
+   2.2 Text Representation of Addresses
+
+   There are three conventional forms for representing IPv6 addresses as
+   text strings:
+
+     1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
+        hexadecimal values of the eight 16-bit pieces of the address.
+        Examples:
+
+                   FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
+
+                   1080:0:0:0:8:800:200C:417A
+
+        Note that it is not necessary to write the leading zeros in an
+        individual field, but there must be at least one numeral in
+        every field (except for the case described in 2.).
+
+     2. Due to the method of allocating certain styles of IPv6
+        addresses, it will be common for addresses to contain long
+        strings of zero bits.  In order to make writing addresses
+
+
+
+Hinden & Deering            Standards Track                     [Page 4]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+        containing zero bits easier a special syntax is available to
+        compress the zeros.  The use of "::" indicates multiple groups
+        of 16-bits of zeros.  The "::" can only appear once in an
+        address.  The "::" can also be used to compress the leading
+        and/or trailing zeros in an address.
+
+        For example the following addresses:
+
+             1080:0:0:0:8:800:200C:417A  a unicast address
+             FF01:0:0:0:0:0:0:43         a multicast address
+             0:0:0:0:0:0:0:1             the loopback address
+             0:0:0:0:0:0:0:0             the unspecified addresses
+
+        may be represented as:
+
+             1080::8:800:200C:417A       a unicast address
+             FF01::43                    a multicast address
+             ::1                         the loopback address
+             ::                          the unspecified addresses
+
+     3. 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
+
+
+   2.3 Address Type Representation
+
+   The specific type of an IPv6 address is indicated by the leading bits
+   in the address.  The variable-length field comprising these leading
+   bits is called the Format Prefix (FP).  The initial allocation of
+   these prefixes is as follows:
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 5]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+        Allocation                         Prefix         Fraction of
+                                           (binary)       Address Space
+        -------------------------------    --------       -------------
+        Reserved                           0000 0000      1/256
+        Unassigned                         0000 0001      1/256
+
+        Reserved for NSAP Allocation       0000 001       1/128
+        Reserved for IPX Allocation        0000 010       1/128
+
+        Unassigned                         0000 011       1/128
+        Unassigned                         0000 1         1/32
+        Unassigned                         0001           1/16
+        Unassigned                         001            1/8
+
+        Provider-Based Unicast Address     010            1/8
+
+        Unassigned                         011            1/8
+
+        Reserved for Geographic-
+        Based Unicast Addresses            100            1/8
+
+        Unassigned                         101            1/8
+        Unassigned                         110            1/8
+        Unassigned                         1110           1/16
+        Unassigned                         1111 0         1/32
+        Unassigned                         1111 10        1/64
+        Unassigned                         1111 110       1/128
+
+        Unassigned                         1111 1110 0    1/512
+
+        Link Local Use Addresses           1111 1110 10   1/1024
+        Site Local Use Addresses           1111 1110 11   1/1024
+
+        Multicast Addresses                1111 1111      1/256
+
+        Note: The "unspecified address" (see section 2.4.2), the
+        loopback address (see section 2.4.3), and the IPv6 Addresses
+        with Embedded IPv4 Addresses (see section 2.4.4), are assigned
+        out of the 0000 0000 format prefix space.
+
+
+   This allocation supports the direct allocation of provider addresses,
+   local use addresses, and multicast addresses.  Space is reserved for
+   NSAP addresses, IPX addresses, and geographic addresses.  The
+   remainder of the address space is unassigned for future use.  This
+   can be used for expansion of existing use (e.g., additional provider
+   addresses, etc.) or new uses (e.g., separate locators and
+   identifiers).  Fifteen percent of the address space is initially
+
+
+
+Hinden & Deering            Standards Track                     [Page 6]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   allocated.  The remaining 85% is reserved for future use.
+
+   Unicast addresses are distinguished from multicast addresses by the
+   value of the high-order octet of the addresses: a value of FF
+   (11111111) identifies an address as a multicast address; any other
+   value identifies an address as a unicast address.  Anycast addresses
+   are taken from the unicast address space, and are not syntactically
+   distinguishable from unicast addresses.
+
+
+   2.4 Unicast Addresses
+
+   The IPv6 unicast address is contiguous bit-wise maskable, similar to
+   IPv4 addresses under Class-less Interdomain Routing [CIDR].
+
+   There are several forms of unicast address assignment in IPv6,
+   including the global provider based unicast address, the geographic
+   based unicast address, the NSAP address, the IPX hierarchical
+   address, the site-local-use address, the link-local-use address, and
+   the IPv4-capable host address.  Additional address types can be
+   defined in the future.
+
+   IPv6 nodes may have considerable or little knowledge of the internal
+   structure of the IPv6 address, depending on the role the node plays
+   (for instance, host versus router).  At a minimum, a node may
+   consider that unicast addresses (including its own) have no internal
+   structure:
+
+    |                           128 bits                              |
+    +-----------------------------------------------------------------+
+    |                          node address                           |
+    +-----------------------------------------------------------------+
+
+
+   A slightly sophisticated host (but still rather simple) may
+   additionally be aware of subnet prefix(es) for the link(s) it is
+   attached to, where different addresses may have different values for
+   n:
+
+    |                         n bits                 |   128-n bits   |
+    +------------------------------------------------+----------------+
+    |                   subnet prefix                | interface ID   |
+    +------------------------------------------------+----------------+
+
+
+   Still more sophisticated hosts may be aware of other hierarchical
+   boundaries in the unicast address.  Though a very simple router may
+   have no knowledge of the internal structure of IPv6 unicast
+
+
+
+Hinden & Deering            Standards Track                     [Page 7]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   addresses, routers will more generally have knowledge of one or more
+   of the hierarchical boundaries for the operation of routing
+   protocols.  The known boundaries will differ from router to router,
+   depending on what positions the router holds in the routing
+   hierarchy.
+
+
+   2.4.1 Unicast Address Examples
+
+   An example of a Unicast address format which will likely be common on
+   LANs and other environments where IEEE 802 MAC addresses are
+   available is:
+
+
+    |              n bits            | 80-n bits |     48 bits        |
+    +--------------------------------+-----------+--------------------+
+    |        subscriber prefix       | subnet ID |   interface ID     |
+    +--------------------------------+-----------+--------------------+
+
+   Where the 48-bit Interface ID is an IEEE-802 MAC address.  The use of
+   IEEE 802 MAC addresses as a interface ID is expected to be very
+   common in environments where nodes have an IEEE 802 MAC address.  In
+   other environments, where IEEE 802 MAC addresses are not available,
+   other types of link layer addresses can be used, such as E.164
+   addresses, for the interface ID.
+
+   The inclusion of a unique global interface identifier, such as an
+   IEEE MAC address, makes possible a very simple form of auto-
+   configuration of addresses.  A node may discover a subnet ID by
+   listening to Router Advertisement messages sent by a router on its
+   attached link(s), and then fabricating an IPv6 address for itself by
+   using its IEEE MAC address as the interface ID on that subnet.
+
+   Another unicast address format example is where a site or
+   organization requires additional layers of internal hierarchy.  In
+   this example the subnet ID is divided into an area ID and a subnet
+   ID.  Its format is:
+
+    |         s bits       | n bits  |   m bits     | 128-s-n-m bits  |
+    +----------------------+---------+--------------+-----------------+
+    |   subscriber prefix  | area ID |  subnet ID   |  interface ID   |
+    +----------------------+---------+--------------+-----------------+
+
+   This technique can be continued to allow a site or organization to
+   add additional layers of internal hierarchy.  It may be desirable to
+   use an interface ID smaller than a 48-bit IEEE 802 MAC address to
+   allow more space for the additional layers of internal hierarchy.
+   These could be interface IDs which are administratively created by
+
+
+
+Hinden & Deering            Standards Track                     [Page 8]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   the site or organization.
+
+
+   2.4.2 The Unspecified Address
+
+   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
+   must never be assigned to any node.  It indicates the absence of an
+   address.  One example of its use is in the Source Address field of
+   any IPv6 datagrams sent by an initializing host before it has learned
+   its own address.
+
+   The unspecified address must not be used as the destination address
+   of IPv6 datagrams or in IPv6 Routing Headers.
+
+
+   2.4.3 The Loopback Address
+
+   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
+   It may be used by a node to send an IPv6 datagram to itself.  It may
+   never be assigned to any interface.
+
+   The loopback address must not be used as the source address in IPv6
+   datagrams that are sent outside of a single node.  An IPv6 datagram
+   with a destination address of loopback must never be sent outside of
+   a single node.
+
+
+   2.4.4 IPv6 Addresses with Embedded IPv4 Addresses
+
+   The IPv6 transition mechanisms include a technique for hosts and
+   routers to dynamically tunnel IPv6 packets over IPv4 routing
+   infrastructure.  IPv6 nodes that utilize this technique are assigned
+   special IPv6 unicast addresses that carry an IPv4 address in the
+   low-order 32-bits.  This type of address is termed an "IPv4-
+   compatible IPv6 address" and has the format:
+
+
+    |                80 bits               | 16 |      32 bits        |
+    +--------------------------------------+--------------------------+
+    |0000..............................0000|0000|    IPv4 address     |
+    +--------------------------------------+----+---------------------+
+
+
+   A second type of IPv6 address which holds an embedded IPv4 address is
+   also defined.  This address is used to represent the addresses of
+   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
+   This type of address is termed an "IPv4-mapped IPv6 address" and has
+   the format:
+
+
+
+Hinden & Deering            Standards Track                     [Page 9]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+
+    |                80 bits               | 16 |      32 bits        |
+    +--------------------------------------+--------------------------+
+    |0000..............................0000|FFFF|    IPv4 address     |
+    +--------------------------------------+----+---------------------+
+
+
+
+   2.4.5 NSAP Addresses
+
+   This mapping of NSAP address into IPv6 addresses is as follows:
+
+
+    |   7   |                   121 bits                              |
+    +-------+---------------------------------------------------------+
+    |0000001|                 to be defined                           |
+    +-------+---------------------------------------------------------+
+
+   The draft definition, motivation, and usage are under study [NSAP].
+
+
+   2.4.6 IPX Addresses
+
+   This mapping of IPX address into IPv6 addresses is as follows:
+
+
+    |   7   |                   121 bits                              |
+    +-------+---------------------------------------------------------+
+    |0000010|                 to be defined                           |
+    +-------+---------------------------------------------------------+
+
+   The draft definition, motivation, and usage are under study.
+
+
+   2.4.7 Provider-Based Global Unicast Addresses
+
+   The global provider-based unicast address is assigned as described in
+   [ALLOC].  This initial assignment plan for these unicast addresses is
+   similar to assignment of IPv4 addresses under the CIDR scheme [CIDR].
+   The IPv6 global provider-based unicast address format is as follows:
+
+
+    | 3 |  n bits   |  m bits   |   o bits    |   125-n-m-o bits   |
+    +---+-----------+-----------+-------------+--------------------+
+    |010|registry ID|provider ID|subscriber ID|  intra-subscriber  |
+    +---+-----------+-----------+-------------+--------------------+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 10]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   The high-order part of the address is assigned to registries, who
+   then assign portions of the address space to providers, who then
+   assign portions of the address space to subscribers, etc.
+
+   The registry ID identifies the registry which assigns the provider
+   portion of the address.  The term "registry prefix" refers to the
+   high-order part of the address up to and including the registry ID.
+
+   The provider ID identifies a specific provider which assigns the
+   subscriber portion of the address.  The term "provider prefix" refers
+   to the high-order part of the address up to and including the
+   provider ID.
+
+   The subscriber ID distinguishes among multiple subscribers attached
+   to the provider identified by the provider ID.  The term "subscriber
+   prefix" refers to the high-order part of the address up to and
+   including the subscriber ID.
+
+   The intra-subscriber portion of the address is defined by an
+   individual subscriber and is organized according to the subscribers
+   local internet topology.  It is likely that many subscribers will
+   choose to divide the intra-subscriber portion of the address into a
+   subnet ID and an interface ID.  In this case the subnet ID identifies
+   a specific physical link and the interface ID identifies a single
+   interface on that subnet.
+
+
+   2.4.8 Local-use IPv6 Unicast Addresses
+
+   There are two types of local-use unicast addresses defined.  These
+   are Link-Local and Site-Local.  The Link-Local is for use on a single
+   link and the Site-Local is for use in a single site.  Link-Local
+   addresses have the following format:
+
+    |   10     |
+    |  bits    |        n bits           |       118-n bits           |
+    +----------+-------------------------+----------------------------+
+    |1111111010|           0             |       interface ID         |
+    +----------+-------------------------+----------------------------+
+
+   Link-Local addresses are designed to be used for addressing on a
+   single link for purposes such as auto-address configuration, neighbor
+   discovery, or when no routers are present.
+
+   Routers MUST not forward any packets with link-local source
+   addresses.
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 11]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   Site-Local addresses have the following format:
+
+    |   10     |
+    |  bits    | n bits  |    m bits     |       118-n-m bits         |
+    +----------+---------+---------------+----------------------------+
+    |1111111011|    0    |   subnet ID   |       interface ID         |
+    +----------+---------+---------------+----------------------------+
+
+
+   Site-Local addresses may be used for sites or organizations that are
+   not (yet) connected to the global Internet.  They do not need to
+   request or "steal" an address prefix from the global Internet address
+   space.  IPv6 site-local addresses can be used instead.  When the
+   organization connects to the global Internet, it can then form global
+   addresses by replacing the site-local prefix with a subscriber
+   prefix.
+
+   Routers MUST not forward any packets with site-local source addresses
+   outside of the site.
+
+   2.5 Anycast Addresses
+
+   An IPv6 anycast address is an address that is assigned to more than
+   one interface (typically belonging to different nodes), with the
+   property that a packet sent to an anycast address is routed to the
+   "nearest" interface having that address, according to the routing
+   protocols' measure of distance.
+
+   Anycast addresses are allocated from the unicast address space, using
+   any of the defined unicast address formats.  Thus, anycast addresses
+   are syntactically indistinguishable from unicast addresses.  When a
+   unicast address is assigned to more than one interface, thus turning
+   it into an anycast address, the nodes to which the address is
+   assigned must be explicitly configured to know that it is an anycast
+   address.
+
+   For any assigned anycast address, there is a longest address prefix P
+   that identifies the topological region in which all interfaces
+   belonging to that anycast address reside.  Within the region
+   identified by P, each member of the anycast set must be advertised as
+   a separate entry in the routing system (commonly referred to as a
+   "host route"); outside the region identified by P, the anycast
+   address may be aggregated into the routing advertisement for prefix
+   P.
+
+   Note that in, the worst case, the prefix P of an anycast set may be
+   the null prefix, i.e., the members of the set may have no topological
+   locality.  In that case, the anycast address must be advertised as a
+
+
+
+Hinden & Deering            Standards Track                    [Page 12]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   separate routing entry throughout the entire internet, which presents
+   a severe scaling limit on how many such "global" anycast sets may be
+   supported.  Therefore, it is expected that support for global anycast
+   sets may be unavailable or very restricted.
+
+   One expected use of anycast addresses is to identify the set of
+   routers belonging to an internet service provider.  Such addresses
+   could be used as intermediate addresses in an IPv6 Routing header, to
+   cause a packet to be delivered via a particular provider or sequence
+   of providers.  Some other possible uses are to identify the set of
+   routers attached to a particular subnet, or the set of routers
+   providing entry into a particular routing domain.
+
+   There is little experience with widespread, arbitrary use of internet
+   anycast addresses, and some known complications and hazards when
+   using them in their full generality [ANYCST].  Until more experience
+   has been gained and solutions agreed upon for those problems, the
+   following restrictions are imposed on IPv6 anycast addresses:
+
+      o An anycast address MUST NOT be used as the source address of an
+        IPv6 packet.
+
+      o An anycast address MUST NOT be assigned to an IPv6 host, that
+        is, it may be assigned to an IPv6 router only.
+
+
+   2.5.1 Required Anycast Address
+
+   The Subnet-Router anycast address is predefined.  It's format is as
+   follows:
+
+
+    |                         n bits                 |   128-n bits   |
+    +------------------------------------------------+----------------+
+    |                   subnet prefix                | 00000000000000 |
+    +------------------------------------------------+----------------+
+
+
+   The "subnet prefix" in an anycast address is the prefix which
+   identifies a specific link.  This anycast address is syntactically
+   the same as a unicast address for an interface on the link with the
+   interface identifier set to zero.
+
+   Packets sent to the Subnet-Router anycast address will be delivered
+   to one router on the subnet.  All routers are required to support the
+   Subnet-Router anycast addresses for the subnets which they have
+   interfaces.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 13]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   The subnet-router anycast address is intended to be used for
+   applications where a node needs to communicate with one of a set of
+   routers on a remote subnet.  For example when a mobile host needs to
+   communicate with one of the mobile agents on it's "home" subnet.
+
+
+   2.6 Multicast Addresses
+
+   An IPv6 multicast address is an identifier for a group of nodes.  A
+   node may belong to any number of multicast groups.  Multicast
+   addresses have the following format:
+
+    |   8    |  4 |  4 |                  112 bits                   |
+    +------ -+----+----+---------------------------------------------+
+    |11111111|flgs|scop|                  group ID                   |
+    +--------+----+----+---------------------------------------------+
+
+        11111111 at the start of the address identifies the address as
+        being a multicast address.
+
+                                      +-+-+-+-+
+        flgs is a set of 4 flags:     |0|0|0|T|
+                                      +-+-+-+-+
+
+             The high-order 3 flags are reserved, and must be
+             initialized to 0.
+
+             T = 0 indicates a permanently-assigned ("well-known")
+             multicast address, assigned by the global internet
+             numbering authority.
+
+             T = 1 indicates a non-permanently-assigned ("transient")
+             multicast address.
+
+        scop is a 4-bit multicast scope value used to limit the scope of
+        the multicast group.  The values are:
+
+             0  reserved
+             1  node-local scope
+             2  link-local scope
+             3  (unassigned)
+             4  (unassigned)
+             5  site-local scope
+             6  (unassigned)
+             7  (unassigned)
+             8  organization-local scope
+             9  (unassigned)
+             A  (unassigned)
+
+
+
+Hinden & Deering            Standards Track                    [Page 14]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+             B  (unassigned)
+             C  (unassigned)
+             D  (unassigned)
+             E  global scope
+             F  reserved
+
+        group ID identifies the multicast group, either permanent or
+        transient, within the given scope.
+
+   The "meaning" of a permanently-assigned multicast address is
+   independent of the scope value.  For example, if the "NTP servers
+   group" is assigned a permanent multicast address with a group ID of
+   43 (hex), then:
+
+        FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as
+        the sender.
+
+        FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as
+        the sender.
+
+        FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as
+        the sender.
+
+        FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet.
+
+   Non-permanently-assigned multicast addresses are meaningful only
+   within a given scope.  For example, a group identified by the non-
+   permanent, site-local multicast address FF15:0:0:0:0:0:0:43 at one
+   site bears no relationship to a group using the same address at a
+   different site, nor to a non-permanent group using the same group ID
+   with different scope, nor to a permanent group with the same group
+   ID.
+
+   Multicast addresses must not be used as source addresses in IPv6
+   datagrams or appear in any routing header.
+
+
+   2.6.1 Pre-Defined Multicast Addresses
+
+   The following well-known multicast addresses are pre-defined:
+
+        Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
+                                        FF01:0:0:0:0:0:0:0
+                                        FF02:0:0:0:0:0:0:0
+                                        FF03:0:0:0:0:0:0:0
+                                        FF04:0:0:0:0:0:0:0
+                                        FF05:0:0:0:0:0:0:0
+                                        FF06:0:0:0:0:0:0:0
+
+
+
+Hinden & Deering            Standards Track                    [Page 15]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+                                        FF07:0:0:0:0:0:0:0
+                                        FF08:0:0:0:0:0:0:0
+                                        FF09:0:0:0:0:0:0:0
+                                        FF0A:0:0:0:0:0:0:0
+                                        FF0B:0:0:0:0:0:0:0
+                                        FF0C:0:0:0:0:0:0:0
+                                        FF0D:0:0:0:0:0:0:0
+                                        FF0E:0:0:0:0:0:0:0
+                                        FF0F:0:0:0:0:0:0:0
+
+   The above multicast addresses are reserved and shall never be
+   assigned to any multicast group.
+
+        All Nodes Addresses:    FF01:0:0:0:0:0:0:1
+                                FF02:0:0:0:0:0:0:1
+
+   The above multicast addresses identify the group of all IPv6 nodes,
+   within scope 1 (node-local) or 2 (link-local).
+
+        All Routers Addresses:   FF01:0:0:0:0:0:0:2
+                                 FF02:0:0:0:0:0:0:2
+
+   The above multicast addresses identify the group of all IPv6 routers,
+   within scope 1 (node-local) or 2 (link-local).
+
+        DHCP Server/Relay-Agent: FF02:0:0:0:0:0:0:C
+
+   The above multicast addresses identify the group of all IPv6 DHCP
+   Servers and Relay Agents within scope 2 (link-local).
+
+        Solicited-Node Address:  FF02:0:0:0:0:1:XXXX:XXXX
+
+   The above multicast address is computed as a function of a node's
+   unicast and anycast addresses.  The solicited-node multicast address
+   is formed by taking the low-order 32 bits of the address (unicast or
+   anycast) and appending those bits to the 96-bit prefix FF02:0:0:0:0:1
+   resulting in a multicast address in the range
+
+           FF02:0:0:0:0:1:0000:0000
+
+   to
+
+           FF02:0:0:0:0:1:FFFF:FFFF
+
+   For example, the solicited node multicast address corresponding to
+   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:200E:8C6C.  IPv6
+   addresses that differ only in the high-order bits, e.g., due to
+   multiple high-order prefixes associated with different providers,
+
+
+
+Hinden & Deering            Standards Track                    [Page 16]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   will map to the same solicited-node address thereby reducing the
+   number of multicast addresses a node must join.
+
+   A node is required to compute and support a Solicited-Node multicast
+   addresses for every unicast and anycast address it is assigned.
+
+   2.7 A Node's Required Addresses
+
+   A host is required to recognize the following addresses as
+   identifying itself:
+
+      o Its Link-Local Address for each interface
+      o Assigned Unicast Addresses
+      o Loopback Address
+      o All-Nodes Multicast Address
+      o Solicited-Node Multicast Address for each of its assigned
+        unicast and anycast addresses
+      o Multicast Addresses of all other groups which the host belongs.
+
+   A router is required to recognize the following addresses as
+   identifying itself:
+
+      o Its Link-Local Address for each interface
+      o Assigned Unicast Addresses
+      o Loopback Address
+      o The Subnet-Router anycast addresses for the links it has
+        interfaces.
+      o All other Anycast addresses with which the router has been
+        configured.
+      o All-Nodes Multicast Address
+      o All-Router Multicast Address
+      o Solicited-Node Multicast Address for each of its assigned
+        unicast and anycast addresses
+      o Multicast Addresses of all other groups which the router
+        belongs.
+
+   The only address prefixes which should be predefined in an
+   implementation are the:
+
+      o Unspecified Address
+      o Loopback Address
+      o Multicast Prefix (FF)
+      o Local-Use Prefixes (Link-Local and Site-Local)
+      o Pre-Defined Multicast Addresses
+      o IPv4-Compatible Prefixes
+
+   Implementations should assume all other addresses are unicast unless
+   specifically configured (e.g., anycast addresses).
+
+
+
+Hinden & Deering            Standards Track                    [Page 17]
+
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+REFERENCES
+
+     [ALLOC] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast
+             Address Allocation", RFC 1887, cisco Systems, December
+             1995.
+
+     [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
+             Anycasting Service", RFC 1546, BBN, November 1993.
+
+     [CIDR] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting:
+             an Address Assignment and Aggregation Strategy", RFC 1338,
+             BARRNet, cisco, Merit, OARnet, June 1992.
+
+     [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol,
+             Version 6 (IPv6) Specification", RFC 1883, Xerox PARC,
+             Ipsilon Networks, December 1995.
+
+     [MULT] Deering, S., "Host Extensions for IP multicasting", STD 5,
+             RFC 1112, Stanford University, August 1989.
+
+     [NSAP] Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and
+             TP over IPv6", Work in Progress.
+
+
+
+SECURITY CONSIDERATIONS
+
+   Security issues are not discussed in this document.
+
+
+DOCUMENT EDITOR'S ADDRESSES
+
+   Robert M. Hinden                     Stephen E. Deering
+   Ipsilon Networks, Inc.               Xerox Palo Alto Research Center
+   2191 E. Bayshore Road, Suite 100     3333 Coyote Hill Road
+   Palo Alto, CA 94303                  Palo Alto, CA 94304
+   USA                                  USA
+
+   Phone: +1 415 846 4604               Phone: +1 415 812 4839
+   Fax:   +1 415 855 1414               Fax:   +1 415 812 4471
+   EMail: hinden@ipsilon.com            EMail: deering@parc.xerox.com
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 18]
diff --git a/t/loops.t b/t/loops.t
index 20c26a5..d501e35 100644
--- a/t/loops.t
+++ b/t/loops.t
@@ -1,13 +1,12 @@
-use NetAddr::IP;
+# $Id: loops.t,v 1.2 2006/08/16 19:17:01 lem Exp $
 
-# $Id: loops.t,v 1.1.1.1 2006/08/14 15:36:06 lem Exp $
-
-$| = 1;
+use Test::More;
 
 my @deltas = (0, 1, 2, 3, 255);
 
-print "1..", 15 + @deltas, "\n";
+plan tests => 16 + @deltas;
 
+use_ok('NetAddr::IP');
 my $count = 1;
 
 for (my $ip = new NetAddr::IP '10.0.0.1/28';
@@ -17,37 +16,18 @@
     my $o = $ip->addr;
 
     $o =~ s/^.+\.(\d+)$/$1/;
-    
-    if ($o == $count) {
-	print "ok $count\n";
-    }
-    else {
-	print "not ok $count\n";
-    }
-
+    is($o, $count, "Correct octet for " . $ip);
     ++ $count;
 }
 
 my $ip = new NetAddr::IP '10.0.0.255/24';
 $ip ++;
 
-if ($ip eq '10.0.0.0/24') {
-    print "ok $count\n";
-}
-else {
-    print "not ok $count\n";
-}
-
-++$count;
+is($ip, '10.0.0.0/24', "Correct mask wraparound");
 
 $ip = new NetAddr::IP '10.0.0.0/24';
 
 for my $v (@deltas) {
-    if ($ip + $v eq '10.0.0.' . $v . '/24') {
-	print "ok $count\n";
-    }
-    else {
-	print "not ok $count\n";
-    }
-    ++ $count;
+    my $target = '10.0.0.' . $v . '/24';
+    is($ip + $v, '10.0.0.' . $v . '/24', "$ip + $v vs $target");
 }