On Jul 17, 2011, at 4:44 PM, Fred Baker wrote: > > On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote: > >> In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote: >>> The quite novel technique of allocation transient addresses to >>> applications/processes to assist with firewalling also takes advantage >>> of IPv6's large address space and that hosts can have multiple >>> addresses at once. It'd be a shame to loose the opportunity to do that >>> or similar innovative things with the large IPv6 address space - >> >> A more scalable approach is to simply route a /96 to the host. There paper >> already suggests that: >> >> "If necessary in a given environment, this could be faked by hav- >> "ing a host pretend to be a stub router; however, this would require >> "the host to participate in routing protocols, which is generally >> "considered to be a bad idea. A better solution would be to extend >> "NDP to handle host address prefix lengths. >> >> I guess the authors didn't know about DHCPv6 prefix delegation. >> >> I think the same applies to hosts with lots of VMs: maintaining a potentially >> large number of NC entries for a single MAC address is unlikely to scale. >> This is what routing is designed for. > > One issue to think about has to do with virtual machines. If I have one > physical platform that appears to the network to be many virtual platforms, I > would likely want to give it many IPv6 addresses. In a cloud computing > environment, if I move a virtual machine from one platform to another, I > would like to move the address and its routing, by changing the MAC address > associated with the IPv6 address. Forcing a /96 here would limit my options - > to change the routing, I would be forced to change the address, which is > something in a cloud computing environment that I don't want to do.
Practically speaking you can also achieve the host mobility that large layer-2's achieve through an l3 mobility approach. eg. the host uses an igp to advertise it's availability (that is, the nexthop for a prefix which it has bound to it) within the datacenter... This (could) reduce the visibility of the subnet to which the host is attached. (it doesn't have to be externally reachable for example, host address assignments may be independent of local topology etc. I can't say I've done it with end systems but we do do a similar thing with load balancers (which are linux boxes running bgp), where they are ebgp peered with the DC border using a private AS and you you can take a load-balancer or prefix out of service or move it by withdrawing the prefix on one load balancer or advertise it on another. vmware vmotion for example is happy to work across layer-3 networks, the hosts however need intervention when their numbering changes. > I could imagine a mix of the proposals, though. I could imagine using a /80 > for a rack or a /96 per platform for virtual machines that reside there, with > a smattering of /128s within the data center for virtual machines that have > moved - and if there was a long term movement, I could imagine renumbering > the machine by adding a new address to it in its new /96, changing the DNS > name, waiting an appropriate interval, and then removing the old address's > /128 from routing and from the virtual machine. I was mostly interested in solving the problem independently of the subnet size. My assumption is that due to slaac, that I'm going to be using /64 subnets for networks which have hosts on them... while much of the exposed side of a DC probably doesn't rely on slaac and is in fact point-to-point links, places where hosts connect probably are. if the mac address ends up being encoded in the address at any point it seems a little silly to split the difference between /64 and /80, both are trivially big enough to blow up the unpoliced ND cache or dos the routers cpu. > _______________________________________________ > v6ops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/v6ops > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
