--pgp-sign-Multipart_Wed_Apr__6_17:14:31_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "pj" == Pelle Johansson <morth@morth.org> writes:

    pj> [NAT] would be needed to completely get rid of an IPv4
    pj> internal network but still provide connectivity to IPv4 sites.

That sounds useful, but it would need support on the client as well.
Is this the RFC1933 stuff mentioned in the comment in
/etc/rc.d/network?

It seems like that would be a special case of NAT not totally
analagous to ipnat.conf NAT, because the destination address and the
packet's AF are being translated, not just the source address/port as
with normal NAT.  Extending NAT analagously would leave you without
this feature, and this feature could be provided cleanly and narrowly
without inviting sysadmins to create complicated unwholesome v6-to-v6
NAT networks.

I just want to avoid being responsible for pressuring engineers to
invent the next PPPoE disaster, avoid by not asking for functionality
that isn't best-common-practice.  I thought there was a consensus to
avoid NAT for IPv6, though I'm not very up-to-date, i think i just saw
some mumbling on kame.net.  Maybe the tide turned.

For the load balancing, I can think of three non-NAT ways.

 * BGP anycast (for DNS servers spread out geographically) or
   equal-cost-multipath (for DNS servers on one subnet) routing.
   works for UDP services like DNS, stateless NTP, maybe spam-DCC.  I
   heard of one person actually using this for DNS.  You configure the
   server cluster's advertised address, the same address, on each
   member's lo0 and assign different addresses to each member's
   physical interfaces.

 * an extension of this idea.  PF claims to support round-robin pools
   as the destination of the 'route-to' (like fastroute,
   firewall-layer routing not using the regular routing table except
   for arp/ndp) verb.  You could use 'pass out inet6 tcp from any to
   <cluster::address_on_lo0's> route-to { pool of physical interface
   next-hops, ... } keep state' so that one TCP session always goes to
   the same cluster member.  I don't know if this works well now, but
   since it is clean and well-defined, you could fix it if necessary
   rather than invent NAT from scratch.

 * multicast.  someone in connection with carp/ucarp mentioned
   clusters using L2 (not L3) multicast addresses and servers
   configured to receive all traffic but pay attenton only to disjoint
   sets of clients.  I think this can't work at L3 since multicast
   address should never appear in a packet's source address, but I
   don't know multicast well, and you can always ask to change the
   standard if you can think of something well-defined.  If you
   threaten to use NATv6 if ignored, people will probably listen
   because it is so unwanted.

--pgp-sign-Multipart_Wed_Apr__6_17:14:31_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQlRROInCBbTaW/4dAQJmgQP/YEZ8PjunCEKtnKk68yhccP+w5KaLL8zZ
34a4eZ2d4MHwiBaXl5YMkZLops4lp3R6AxQaCSgyYtBgBLudk5Bc30uHvVuhTRZ/
4BjxL+f46HiMTXbDDWtI0x9SrsRvmuMxeUdChPCYKd1+oeijieOVFAlyLrRK1oLn
aEUj2cO8Nxc=
=nuwo
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Apr__6_17:14:31_2005-1--