Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Ipassumptions

Ipassumptions

How we assume IP (or more correctly, IPv4):

  1. Most obviously, assignment of node addresses, either explicitly by the user or implicitly by us, is IPv4. IPv6 addresses get assigned to interfaces as well (at least by FreeBSD) as a side-effect, but in general, we support nothing else.
  1. Routing (manual, static, session) is all IPv4 as well.
  1. As of FreeBSD 4.7, ipfw only handles IPv4. When bridging, as in our delay nodes, non-IPv4 packets are forwarded without applying any rules. This means that ARP and VETH packets do not get shaped. This is arguably wrong. It would be completely wrong for VETH except that all veth shaping is done using link delays and applied before encapsulation is done. And no veth traffic should ever go through a delayed link.
  1. Current jail support restricts interface access indirectly by specifying the IPv4 addresses that a jail can use. Raw socket access in jails is likewise restricted.
  1. The multiple routing table hack we use for vnodes only applies to IPv4.

What we need to do to support raw ethernet access:

  1. Disable IP assignment and setup. Do we need to give the user a way (on a node) to associate an NS-named link with a MAC address?
  1. Switch to at least FreeBSD 4.9 and use ipfw2 which supports ipfw/dummynet at the MAC level. Then we can shape non-IP packets in general.
  1. Switch jails to explicitly bind to interfaces.

What we need to do to support IPv6:

  1. Support IPv6 addresses in our extended NS syntax for node address assignment as well as well as internally for our implicit address assignments.
  1. Support IPv6 addresses in routing. For static/manual this is just a matter of internal DB representation (I think). For session, we'll have to see if gated even supports IPv6.
  1. Delay nodes. May need a different ipfw (ip6fw?). But probably not for the granularity of (ipfw and dummynet) rules we use (since they are largely interface-based, but we do use "next-hop").
  1. Fix jails to understand IPv6. This is more than just restricting jail interfaces directly, there is *no* jail support in the IPv6 code.
  1. Use something other than the multiple-routing table hack. Probably switch to the multiple network stack implementation. We could hack the multi-routing table stuff, but...ugh!
  1. Configure/enable IPv6 access in any number of applications. Hopefully, most are setup to handle either v4 or v6 by default.
  1. Support IPv6 on the control net? To communicate with the outside world, we cannot do this. Our router doesn't support IPv6. They will have to use GIF tunnels. Ditto to communicate from nodes to boss/ops, since that goes through the router. For node to node control net communication, it shouldn't be any different than the experimental interfaces.
  1. Multicast? Probably won't be able to do this, the switch will not recognize IPv6 multicast packets.