Commit b84ece7c authored by Mike Hibler's avatar Mike Hibler
Browse files

My thoughts about how we are IP-centric and what we will have to do

to not be so (specifically, to support layer 2 and IPv6)
parent af5ad0ce
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.
2. Routing (manual, static, session) is all IPv4 as well.
3. 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.
4. 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.
5. 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?
2. 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.
3. 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
2. 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.
3. 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").
4. Fix jails to understand IPv6. This is more than just restricting jail
interfaces directly, there is *no* jail support in the IPv6 code.
5. 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!
6. Configure/enable IPv6 access in any number of applications. Hopefully,
most are setup to handle either v4 or v6 by default.
7. 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.
8. Multicast? Probably won't be able to do this, the switch will not
recognize IPv6 multicast packets.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment