Ok, so site multihoming with IPv6 is going to be tough - we all know that.  Basically, an ISP will give you a PA (provider assigned) prefix, usually a /48, since it's next to impossible to get a /32 of PI (provider independent) space, for fear of the IPv6 route table ballooning like its v4 cousin.  Unfortunately, many ISPs (ahem, Verizon) have chosen to filter any prefixes larger than /32s.  If you get yourself multihomed, and happen to arrange with your upstreams to announce your PA space through both ISPs, the prefix will probably not make it everywhere because of this.

Some folks at the IETF came up with Shim6, or the "Site Multihoming by IPv6 Intermediation" protocol.  After reading through some of the documents, I'm wondering why people think this is a good idea.  From what I can tell, the IPv6 stacks on end hosts are modified to accept multiple addresses from different provider's PA space, and netogiate which ones to use and/or load-balance with the remote hosts.  This seems like a bad idea for several reasons:

• The site multihoming should not be handled by end hosts - this potentially gives users the ability to control traffic flow out or in to your networks.  Erm, remind you of source routing, or the original RSVP spec?  Anyone?
• Multiple IPv6 addresses on end hosts is possible, but just because you CAN doesn't mean you SHOULD.  I don't have faith in many operating systems to handle this properly.  Sorry.
• How do you firewall hosts that could potentially have up to a dozen different addresses?  How about keeping state?  Maybe we'll end up using the flowlabel field after all…
• This is worse than a routing table with 640k routes!

Hopefully this will just go by the wayside.  I really don't want to see this implemented.

New comments are currently disabled for this entry.