You're looking at the internet of today. Think about 10, 15, 20 years out when everything you buy at the grocery store has an IP address and most audio amplifiers act as routers to head-end the other entertainment devices in the cluster.
Think about a time when HDMI is supplanted by multi-gigabit wireless connectivity. Who knows what the future will hold or what technologies may be developed to take advantage of these new capabilities of end-to-end addressing. I'd hate to see them stifled because we got stingy with address space. How is an address less wasted by sitting in the free pool long beyond the useful life of the protocol than it is by being deployed to allow for flexibility in network design? Owen On Jun 3, 2013, at 2:57 AM, Sheng Jiang <shengji...@gmail.com> wrote: > I have to say the hierarchical assignment is a such great way to waste > address space or prefix bit. I cannot real see much benefits or use cases of > it. Why may home site 3 subordinate routers? How many subnets or devices may > a /48 prefix serve in this model? > > Cheers, > > Sheng > > > On 3 June 2013 00:39, Owen DeLong <o...@delong.com> wrote: > > On Jun 2, 2013, at 11:10 AM, Ted Lemon <ted.le...@nominum.com> wrote: > >> On Jun 2, 2013, at 11:59 AM, Owen DeLong <o...@delong.com> wrote: >>> You are assuming that all of the subordinate routers will act as DHCP >>> relays rather than doing PD. >>> That is certainly one possible solution, but, not necessarily ideal in all >>> cases. >>> In cases where the subordinate routers should receive delegations and >>> perform their own PD for their subordinate routers, having a larger bit >>> field can be useful for greater flexibility. >> >> No, there is no use case where this is better than doing the delegations >> from the router that received the initial delegation (since we're apparently >> just arguing by vigorous assertion). >> > > We can agree to disagree. > > One example that comes to mind is if I want greater control and I want my > most capable router with the greatest configuration flexibility to be in > charge of the addressing scheme, but, it is not the router that interfaces > with my ISP. > >>> Thus, providing 16 bits to the end site is, IMHO, worth while. >> >> And hence, this conclusion is not supported. >> >> You are welcome, of course, to contradict me by stating such a use case, but >> bear in mind that when you delegate prefixes for further sub-delegation, >> topology changes in the homenet become impossible. So your use case for >> doing this would have to enable some pretty awesome functionality before it >> would be worth doing. Also make sure you think about how it would work >> during a renumbering event, with sub-delegations and sub-sub-delegations all >> having different lifetimes. >> > > Actually, the need for the larger bit field is precisely to allow topology > changes in said deployment scenario. If the top level router hands out, for > example, /50s to its 3 subordinate routers, the subordinate routers can > support a number of different topologies without requiring any changes at the > top-level router. Additionally, a fourth subordinate router can be added with > its own underlying topology supported. > > OTOH, if there are more than 3 subordinate routers, the top level router can > delegate /51s. True, this would complicate the change from 3 to more than 3 > subordinate routers at the top level somewhat. > >> (I've got nothing against delegating /48's to the home, but the reason we >> did that was to maintain flexibility, not because we really expect a typical >> homenet to have 65,536 subnets. At least for most reasonable values of >> "we.") >> > > You just said exactly what I said to begin with… It's to have a bit field > wide enough to allow flexibility in the automation of the hierarchical > assignments, not to create 65K subnets. I never asserted it was because we > needed 65K subnets. > > Owen > > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- > Sheng Jiang 蒋胜
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
