[Goat] routing

[ww at parc.styx.org]

some ideas re: dynamic routing in the mesh.

 1. globally unique addresses are desireable.
   a. RFC1918 addresses don't fit the bill 'cause
      people are already using them. addressing
      conflicts are a pain.
   b. using an unallocated block (or defunct 
      allocation) is better, but these addresses
      may be used in the future. it is also at
      odds with the policies of the RIRs and 
      traditional best practices.
   c. it is possible to be allocated ipv4 blocks
      in the usual way.
      i. this brings the burden of either getting
         someone to announce these addresses on
         behalf of the mesh or also obtaining an
         ASN and making peering arrangements if
         direct connectivity to the Internet is
         desired.
      ii. these addresses are scarce and expensive
         to obtain.
   d. ipv6 addresses are plentiful and readily
      available. 
      i. using RFC3056 (stf or 6to4 addresses),
         a single ipv4 address maps into 65536
         subnets of stadard /64 size.
      ii. it has been pointed out that ipv6 is
         percieved as "hard" for end-users.
         perhaps a hybrid approach is in order?
 2. hybrid addressing.
   a. obtain one static ipv4 address that is not
      likely to change at any point in the forseeable
      future (since renumbering is a pain no matter
      what the addressing scheme).
   b. build the backbone of the mesh using these 
      numbers.
   c. at each node that provides service to end users,
      RFC1918 addresses that need not be unique are
      used.
      i. the node will run a caching nameserver,
         BIND9, that listens on its ipv4 address and
         forwards queries over ipv6 to authoritative
         nameservers and external gateways.
      ii. the node will run squid, or a similar proxy,
         likewise listening on the ipv4 address and
         forwarding requests over ipv6.
      iii. using a similar strategy, for other tcp
         services, application layer proxying can be
         configured.
   d. of course the end users are also allocated an
      ipv6 address. these addresses are routed natively
      and so have no need for proxies.
   e. so done this way the mesh is a native ipv6 
      network providing limited but functional support
      for legacy devices that only speak ipv4.
 3. routing protocols.
   a. all of the routing protocols mentioned on the
      wiki page have three inter-related drawbacks.
      i. support for operating systems other than linux
         is very limited.
      ii. support for what would be called "areas" with
         ospf is very limited.
      iii. support for interaction in a predictable way
         with other protocols (i.e. rip, ospf, bgp) is
         limited -- i.e. there is no support for these
         in zebra/quagga or gated.
   b. what do these specialized routing protocols give us
      that say, ospf with equal-cost or weighted-cost 
      multipath routing does not?
      i. support for equal-cost multipath exists in
         linux and (limitedly) in netbsd as well as
         ios and junos.
      ii. zebra/quagga supports equal-cost multipath.
      iii. an implementation of weighted-cost multipath
         would not be too hard but would require some
         kernel hacking as well as modification of 
         zebra/quagga.
 4. hypothetical software inventory for a mesh node
    using this configuration
    a. operating system (NetBSD or Linux according to
       taste, if NetBSD require snapkit from KAME).
    b. quagga
    c. bind9
    d. squid (optional)
    e. 6tunnel (application-layer proxy for legacy hosts)

thoughts?

-- 
The "cutting edge" is getting rather dull.
                -- Andy Purshottam

_______________________________________________
Goat mailing list
Goat at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/goat_isf.waglo.com