I don't agree with any of your points I'm afraid, and I don't think they'd stand up to any thorough analysis (e.g. /128s verses /64s don't have any significant impact on HD ratios when an ISP gets a _minimum_ of a /32 or 4 billion /64s)
However, I don't think this conversation is making any progress. People do what they want to do, including sometimes making life harder for themselves than it needs to be. C'est la vie. On Sat, 28 Aug 2010 23:56:07 -0400 Christopher Morrow <christopher.mor...@gmail.com> wrote: > On Sat, Aug 28, 2010 at 11:26 PM, Mark Smith > <i...@69706e6720323030352d30312d31340a.nosense.org> wrote: > > On Sat, 28 Aug 2010 22:43:21 -0400 > > Christopher Morrow <christopher.mor...@gmail.com> wrote: > > > >> On Sat, Aug 28, 2010 at 7:34 PM, Mark Smith > >> <i...@69706e6720323030352d30312d31340a.nosense.org> wrote: > >> > >> > I think IPv6 "CIDR" i.e. longest match rule across the whole 128 bits is > >> > really only insurance against having to perform a whole of Internet > >> > upgrade, similar to what had to happen when CIDR was introduced, should > >> > >> folk are already holding (internally) /128's for things, I suppose > >> they could have /64's, but that means dedicating a 'LAN' to some task > >> (anycast of a nameserver, for instance) when you really only want to > >> use a 'host' for that. > >> > > > > This is one of the issues. People are being unnecessarily precious about > > address space. What real benefit do they gain? It seems that their > > not precious with address space, precious with opex costs... > > if you put each service address on it's own /64 that may be fine for > some folks but will run afoul of hd-ratio and other measures of how > 'full' your use of the address space you'd been allocated may be. > > if you put multiple service-addrs on a single /64 you have to > maintenance all of these service-addrs at the same time or suffer > spotty service coverage. > > If you value resilient services (dns and ntp for two simple examples) > spotty coverage isn't really an option. > > >> I > >> agree that making almost all 'LAN' segments a /64 is a fine plan, > > > > So why isn't it a fine plan for all links in a network? We can afford > > the address space. > > not every link needs it and there are some pretty scary implications > of using /64's on some link types (ptp links, for the /127 example > here), plus complexity and headache that's just not necessary when you > aim to put the 2 ends of the ptp link on well known (to you) and well > defined addresses. SLAAC is just un-useful in this case, RA and ND and > other functions are just a waste of CPU time I want to be used making > RIB/FIB updates go faster. > > > > >> some > >> folks may choose other boundaries and in those cases will not get RA > >> or other things, they may not need those things though. > >> > > > > A number of innovations are possible and have been developed in IPv6 > > because the single and soft boundary between the network and node > > portions at the 64 bit mark. These innovations would not have been > > possible if that soft boundary hadn't been chosen in the past. If that > > soft boundary is now eliminated, then what useful innovations won't be > > possible in the future? Maybe somebody will come up with an innovation > > that would be of real benefit on point-to-point links between routers, > > maybe, though we've been using the same (essentially) technology for > this for ~30 years and ... the largest change has been /30 -> /31 > migrations. this part of the network isn't where 'innovation' is > supposed to happen. the edge can do that just fine... operating a > cheap (very, very cheap), fast (very, very fast) and simple core is > the goal. 'innovation' in the core isn't a super good plan for the 2 > other parts (cheap/fast). > > Today, and in the past number of years, the operational reality and > migration of the industry has been to fast, cheap core wherever > possible. Costs added to operations or capital in the core just don't > happen. Ask VZB/UUNET how many 'network engineers' are doing 'network > engineering' for their global public ip backbone today? far fewer than > in years past. I suspect you'll see the same story at Level3, ATT, > Comcast, Telia, NTT etc... > > > however it needs 64 bit identifiers. Yet if /127s are widely deployed, > > then that innovation may never be worth developing because it can't be > > widely deployed. It may even never be thought of, because people will > > core links are, by numbers, I imagine far fewer than edge links... > Enterprises make up the vast majority of edge network user cases, > equipment buys, etc. Heck, Comcast has ~20m end users, that's got to > be a few orders of magnitude more than their core links, right? :) > > > become ingrained in "point-to-point" links are only /127s. > > they are. > > > One of my concerns about /127s is that it'll become the thin edge of > > the wedge for also eliminating the /64 boundary on LANs. Then we'll > > for LANs, SLAAC works fine for getting addresses and default-gw pushed > out. Until ~3 years ago (thanks to thaler, nartens, et-al for the > change then) it was useless for pretty much everything else :( > > I don't think folks really want to change LAN architecture... it does > seem to 'just work'. > > > have spotty SLAAC support, different devices with different prefix > > lengths etc., - all the problems we've had with incorrect subnet masks > > in IPv4, as well as new ones like SLAAC not working. > > > > Fundamentally, people seem to be wanting to introduce constraints into > > IPv6 that seem to have no other reason to be other than "that's how we > > did it in IPv4". Yet there doesn't seem to be any questioning of why > > "thats how our operations model works today, that's where the money is > driving this train, that's what operations folks are asking for." > > > those methods had to be implemented in IPv4, and if the design of IPv6 > > eliminates those IPv4 constraints - and if we'd had a choice in IPv4, > > would we have accepted them in the first place. > > I do think folks asked these questions, they did so sometime in the > past... they now have implemented a bunch of stuff and want to keep > operating their networks in the manner they are today. Adding more > complications isn't the right direction here. > > Understanding that 10+ years ago when ipv6 was designed the world was > a very different place is what we all need to keep in mind. Today > billiions (at least) of dollars depend on a reliable, scalable, useful > network. screwing with that is not in anyone's best interest. I think > what the authors are trying to do here is to document what they've got > working, why it's working that way and push that forward (since there > seems to be a decent amount of agreement among folks that operate > networks, worldwide) as an acceptable method. > > -chris -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
