Welcome to Hurricane Electric's Tunnelbroker.net forums!
Started by cocodude, June 27, 2012, 05:12:06 AM
Quote from: cocodude on June 28, 2012, 12:31:17 PMIs there any logical reason why a RA program couldn't be written that offers a prefix on a more complicated basis (e.g. a different /64 prefix depending on the MAC address)?
Quote from: cocodude on June 28, 2012, 11:20:41 PMSometimes these customers would like a /64
Quote from: kasperd on June 29, 2012, 12:31:28 PMIt might even be possible to create static IPv6 address to MAC mapping for neighbours, similar to how you'd create a static ARP entry. That would give you an IPv6 address that you can use in your routing table. It doesn't matter that that address isn't even assigned to the receiving interface. Those addresses would never be visible to anything outside of the routing engine itself. If you go that route, you could for example use fd92:ce71:1691:1494::/64 for those static neighbour mappings.
ip route add fd92:ce71:1691:1494::/64 dev wlan0ip neigh add fd92:ce71:1691:1494::10 lladdr 00:xx:xx:11:d5:c2 dev wlan0ip route add 2001:470:1f0b:1da2::/64 via fd92:ce71:1691:1494::10
ip route add fec0::/32 dev wlan0ip neigh add fec0::00:xx:xx:11:d5:c2 lladdr 00:xx:xx:11:d5:c2 dev wlan0ip route add 2001:470:1f0b:1da2::/64 via fec00::00:xx:xx:11:d5:c2
Quote from: kasperd on June 29, 2012, 12:31:28 PMWhy do they want a /64? What do they expect to happen with that /64?
QuoteAs a starting point you use radvd to assign each node a single IPv6 address, and all of them get IPv6 addresses from the same /64. SLAAC doesn't consume all addresses in that /64. You will have plenty of addresses left over for DHCPv6 and static configurations, should you need it.For those customers who ask for a prefix, you assign them a /64 and either delegate the prefix through DHCPv6 or by static configuration. In your routing table you can use any of the addresses assigned to that node as the next hop for the /64 prefix. There is no technical reason you couldn't use the link local address of that node has the next hop for the /64 prefix.
Quote from: amcintosh on June 29, 2012, 03:29:24 PMI almost always fight new systems the first several months, then finally settle down and decide the designers actually did know something.
QuoteI would set up a MySQL environment to grab the next available /64 and associate it with the DUID. I'd have a "last used" field in the table, and always use the "longest abandoned" DUID when forced to rotate. You could initialize the "last used" filed to 1-1-70 0:0:1, 1-1-70 0:0:2, ... if that amuses you.
Quote from: cocodude on June 30, 2012, 01:54:25 PMI just argue that it could be easier to automatically assign a /64 to each customer without having to make configuration changes if the customer decides they want one. As said, I've got a /48 on that server so there are plenty of /64s to go around for each customer to have one.
Quote from: cocodude on June 30, 2012, 01:54:25 PMHaving the default route as the other side of the link local address (to the dom0/master domain, as radvd or similar would hand out) would work I imagine instead of configuring routing through the single IP address in the shared /64. Perhaps this would be a lot easier than setting up manual static routes?
Quote from: cocodude on June 30, 2012, 01:54:25 PMIs your suggestion the standard in the hosting industry?
Quote from: cocodude on June 30, 2012, 01:54:25 PMI agree with you here! Hence my asking whether this would be a good idea. I still don't understand why MAC address matching just doesn't seem to be supported in DHCPv6 servers though!
Quote from: kasperd on June 30, 2012, 03:22:42 PMQuote from: cocodude on June 30, 2012, 01:54:25 PMI just argue that it could be easier to automatically assign a /64 to each customer without having to make configuration changes if the customer decides they want one. As said, I've got a /48 on that server so there are plenty of /64s to go around for each customer to have one.No problem with that. I think it makes perfect sense to give customers a /64 by default. Just keep two things in mind. If at some point you decide that the /48 needs to be split across multiple servers, it will be convenient to have the /64s that you did assign be located closely together. I don't know how many customers you expect to have on that server. If you do get to for example 8000 customers on that server, try to do a survey on how many customers are using the /64 for something.
QuoteI assume you can setup separate virtual network interfaces between dom0 and the individual virtual nodes. From a security perspective it would be better to do it that way. Once the connections to the individual nodes are on different interfaces you can of course use router advertisements to announce a different prefix on each of those interfaces.
QuoteBut again that is still just a /64 for the link between dom0 and the customer node. They are not actually getting a /64 routed to their node, they are getting a /64 in which they can use SLAAC to consume as many addresses as they like.
QuoteAs far as I remember xen does make it independent links by default, and you have to explicitly bridge them in dom0 if you want them to be one link. On a physical network you can make independent links through the use of VLANs.
QuoteDo you think it would better suit your needs to allocate a /64 for the link between dom0 and each customer, and then not route a /64 to each customer. If you don't route a /64 to each customer, then you don't need to mess with DHCPv6 and routing.
Quote from: cocodude on July 04, 2012, 12:00:21 PMThe default script that Xen users seem to use is vif-bridge, which does simply bridge all virtual interfaces to the one 'real' interface.
Quote from: cocodude on July 04, 2012, 12:00:21 PMIt's a bit tricky to configure radvd to offer prefixes on dynamically changing interfaces though