|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
> The rules today have not resulted in and overly huge number of > multihomers. I suspect that is a matter of perspective. Even if 10% of all sites are multihomed, and we continue in the IPv4 multihoming model, then we will end up with slow exponential growth of the routing table which eventually overtakes and buries us. > The IPv6 crowd evangelists on the one hand insist there's > no need for NAT, while on the other hand provided no solution to > multihoming, and what's been evolving in the various "fixes" for that > are less palatable than running a multiport NAT box. The choice is > simple: live with NAT or provide portable address space. The marketplace > is not likely, IMO, to accept shim6. Why not? I should point out that another perspective on shim6 that should be more to your liking: in actuallity, shim6 is just another incarnation of NAT. It turns each host into a NAT that sits just underneath the transport layer. This seems like a fine compromise to running a multiport NAT or (worse) a distributed multiport NAT. > End systems should not be making decisions on where packets go beyond > the local network segment. This has been tried before. It was called > Token Ring Source Route Bridging. It was a bad idea then, and it's a bad > idea now to have end stations deal with routing. SRB came into being to > save the network elements from the burden of keeping track of the > functioning of the network. Then Ethernet switches came along, spanning > tree, and so forth. That would fly in the face of other requests already made here. I tend to agree that routing should stay in the routing subsystem and that those asking for routing features would be most likely to get them if they asked routing to provide the functionality. > That's true today. Router memory complement has increased over time. So > what? Cost of processing power and memory are a tiny fraction of what > they were when the routing table was in the 20,000 prefix range. Flatly not true. Paid for a line card lately? > Processors in current routers are well below the fastest on the market. > There's plenty of horsepower headroom. There's plenty of opportunity to > expand the amount of memory. Processors are not just for protocol processing. There are also impacts on the costs of forwarding, as each prefix ends up in the high speed static RAM associated with your forwarding engine. Such silicon is not cheap, and while we are currently ahead of the problem, we can easily let the problem grow without bound and leave ourselves in a very bad spot. Scaling the routing subsystem is in everyone's best interest. > That multihoming was not properly addressed as a core goal to solve in > IPv6 is one of the failings in the whole effort. No doubt. However, the fact of the matter is that we are where we are. > The shim6 approach is, > IMO, not going to fly. A multiported NAT box for $179 or less (present > product in the marketplace) provides a simple solution without the end > stations being involved. Sure, it uses NAT. If, in fact, this is the choice of the market, then the issue is solved and PI space is unnecessary. A fine outcome in my book. > Relying on Moore's Law to continue to make > routing equipment keep up is going to be a necessity. Moore's Law has not, and does not apply to routers. Thus, costs are going up non-trivially. Tony
|