From: "Robert Elz" <[EMAIL PROTECTED]> > Now however, we know how much benefit there is to claim lots of address > space as early as possible, and then to dig in
Is that like claiming TLDs ?....and not giving them up ? Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ----- Original Message ----- From: "Robert Elz" <[EMAIL PROTECTED]> To: "Margaret Wasserman" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, August 10, 2002 6:18 AM Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt > Date: Wed, 07 Aug 2002 09:37:33 -0400 > From: Margaret Wasserman <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | No significant changes will (or should) be made to the addressing > | architecture based on my personal opinions, even if a few other people > | agree with me. > > Of course not. But it would be interesting to actually hear something > from those who don't, with some kind of reasoning, rather than just > assuming that they exist, which seems to be the current state of affairs. > > | It would require a consensus of the WG to change the addressing > | architecture in the ways that I have suggested. > > Of course. But no greater consensus than that required to make the > other two changes that Bob Hinden just proposed (based upon the Yokohama > discussions). There's nothing magic about this draft, we can change it. > > | We have discussed these things before (on the mailing list and in person) > | and, so far, there has been no WG consensus to make these sorts > | of changes. > > No, but so far I have also failed to see any convincing (or even arguable) > reasons why the change should not be made. To me, it is looking a lot > like "I don't want to change it because I don't want to change it, but > I won't say any more why not than that". This isn't the way to technical > excellence (and here, it isn't even if if a change is being proposed which > would require changes to implementations, if anything, exactly the opposite, > the change would align the doc with what is actually implemented and used). > > | But, the semantics of the 'u' bit don't provide this... > > This is the theory, yes. It isn't the practice however. > > | The 'u' bit indicates that a particular IID has been generated from a > | globally unique EUI-64 identifier. > > And from where does a node determine that it has a globally unique EUI-64 ? > > | Addresses that are generated from > | other sources -- non-globally unique EUI-64s, serial numbers, random > | numbers, etc. will not have the 'u' bit set. > > Not in practice. In practice, any address generated from a MAC addr > that has the 'u' bit clear will result in an IPv6 address with the 'u' > bit set. > > So, unless you're able to convince yourself somehow that a MAC address with > the 'u' bit clear is necessarily globally unique, practice doesn't fit with > the theory. > > | So, it can't really be used to distinguish autoconfigured addresses > | from manually configured addresses > > No, and if you look, that's never what I said it was good for. No-one > should ever look at an address and attempt to interpret the 'u' bit to > mean anything at all. > > What it is useful for, is when I am autoconfiguring an address on a link, > based upon the MAC address I am using on that link (which needs to be > unique on the link for the link level to operate properly, on most of > the links we're concerned with) then I set the 'u' bit, and when I am > generating an address another way, I don't. Then the autoconfigured > address is much less likely to fail DAD any time when the link level is > correctly functional. > > | -- it is used to distinguish IIDs that are (or should be) > | globally unique from IIDs that may not be globally unique. > > That's the theory. And it is unworkable. > > | This is a holdover from the 8+8/GRE discussions that we had a few > | years back > > Yes, I know (or I surmised). 8+8 was discussed at some length, > investigated, and discarded as unworkable. But we kept this remnant... > > | But there were a substantial number of people > | (I was one of them) who thought that it was important to maintain the > | global uniqueness of the IID, so that we might later be able to pursue > | such a mechanism. > > Then, if you're one of them (or even if you no longer are, perhaps you > can recall your thinking at the time) perhaps you could explain how this > could ever work? That is, how any node could ever know when it should > set the 'u' bit such that this other mechanism, if it is later invented, > could actually rely upon it? > > And is this more or less important than the ability to remain address > stability when a MAC address changes (change of technology, replacement > of broken hardware, etc) ? > > | So, we decided that the lower 64-bits of an IPv6 should > | always be a globally unique EUI-64 identifier. > > I don't think we ever decided that, or certainly not any time I was > watching, as that never had a chance so ... > > | Not much later, due to the fact that [...] > > I suspect this "not much" must have been measurable in milliseconds > or smaller... (probably without overflowing a 16 bit counter). > > | not all systems have EUI-64 identifiers and rising concerns > | about privacy issues, we backed off of this position and decided to use > | the 'u' bit to distinguish between globally unique IIDs and non-globally- > | unique IIDs. And, there we stand today... > > Yes, this is the history as I remembered it as well (other than there > ever being a time, the 8+8 proposal excepted, when we ever believed that > we could have all addresses contain globally unique EUI-64's - but that > detail doesn't matter at all now). > > What you have described however is how we got ourselves into a messy state, > but without any justification at all for keeping us there. > > Probably it is unfair to expect you to do that, as you started this thread, > this time, by proposing that all the mess be thrown away, which is something > I totally agree with. > > But perhaps someone should be able to get to the keyboard and give some > kind of justification, other than history, for keeping it? > > Or even, to explain what we have today that would break if we make the > change? > > | Personally, I think that it is highly unlikely that there will be any > | benefits to being able to separate the identification and topological > | routing information for _some_ hosts. > > I agree. But even if there were, I can't see how we can ever, under > any circumstances, actually implement the 'u' bit as it is currently > defined, regardless of whether or not doing so would ever be useful. > > | So, I believe that we eliminated > | the ability to implement 8+8/GRE-like mechanisms altogether when we decided > | to use the 'u' bit to distinguish between the IIDs that were globally > | unique and those that were not. I argued this at the time, but there > | was clear WG consensus to use the 'u' bit. > > I recall agreeing that we should keep the 'u' bit for autoconfig > purposes, so when we autoconfig things work easier. That's just fine. > I don't ever recall agreeing (or ever actually hearing any WG consensus) > to treating the 'u' bit as meaning that one can assume the address > contains a globally unique IID. Perhaps this is a case where there > was some confusion about what was actually being asked? > > Perhaps someone who believes that the WG actually reached that consensus > can point out where in the EG list archives it happened, so I can go back > and review the issue? It is kind of hard for me to do that alone, as > I don't think it actually exists anywhere, in this particular form. But > it is very very hard to show that something doesn't exist, and quite easy > to show that it does. > > | I have been told, though, that there are still a significant number of > | people who believe that the 'u' bit should be maintained for later use > | in a system that separates ID and routing goop (as it was called in > | GRE). These people were reportedly willing to accept the compromise > | of splitting the address space into two portions (via the 'u' bit), > | one that would have unique IIDs and one that would not. If there are > | folks who still believe that this is a valuable property, could you > | please speak up in support of it, and explain why? > > Yes, please, and also explain how it works! (Not the as yet undefined > mechanism, we can punt on that for now, just how the "I know when to set > the 'u' bit" works for this purpose). > > | At that time, it didn't seem like a big issue to add a hard /64 > | boundary into the IPv6 address, because we already had several > | hard boundaries in our addresses to provide separate fields for > | aggregation (the TLA/SLA stuff). > > Well, some people thought that we did. It was always quite clear > though that all of the other boundaries were not going to last. > Those ones had even less immediate relevance to anything than this > one does, relating only to how addresses are assigned. > > This one needs to go as well. Which isn't to say that most links > won't get 64 bit prefixes, we want to use autoconfig, and (for the > links currently defined anyway) autoconfig requires 64 bits, which > is just fine. But no-one outside the link should be able to tell > whether an address is one that was autoconfigured on an ethernet > or whether it is one that was manually assigned on a p2p, or even if > the same address is one thing one day, and the other the next. > > | There are some major advantages to retaining this hard /64 boundary: > | > | - It makes autoconfiguration simpler, since all prefixes are > | /64s and all IIDs are 64-bits long. > > No, that's irrelevant. We can keep the /64 for autoconfig purposes > (which is what I have been proposing) while not requiring it as any > kind of fundamental part of the architecture. > > | It would require > | major, and inadvisable, changes to autoconfiguration to > | allow autoconfiguration using prefixes longer than /64. > > Not to autoconfig itself, it doesn't care - just to the currently defined > mechanisms for autoconfig over X, for all the IEEE type links (and anything > else we want to be compatible, so bridging can happen). And no, there is > no need at all to change that. > > But for autoconfig to work on an ethernet (fddi, ...) doesn't require me > to use a /64 for my p2p links (if you don't believe it, I can show you > my configurations, where this stuff all works just fine). > > | - Memory systems and processors are much better at dealing with > | 64-bit values than they are at dealing with longer > | values. > > This is totally bogus. Go back a few years and you'd put in "32" > there just as accurately. > > Routers need to be able to deal with 128 bit addresses in all instances, > as they have to be able to cope with addresses on their directly attached > links. Those need /128's ... A router that routed real fast when the > destination is a long way away, and real slow, when it is nearby, would > perhaps find some market share in the network backbones, but it is never > going to be sold in the mass market. > > Routers can and perhaps should optimise their routing tables so they > only carry the required prefix lengths (though I suspect some of the > ASIC people will now be jumping up and down and saying that is too > hard, there's no need to reply, I understand) - but they cannot afford > to assume that only the first 64 bits of addresses matter. Ever. > > But even if some router was to assume that, and actually find a market, > all that would mean is that that router would need to be deployed in > an environment where longer prefixes aren't visible. Since I certainly > don't expect any of you to ever see explicit routes to m /112 p2p links, > you can deploy such routers if you want to, quite safely. You just > need to number your own p2p links using /64's and assume that aggregation > will take care of everything else. > > | But, what I think this WG needs to think about and understand is _why_ > | operators are using longer prefixes on their router-to-router links. > > That might be reasonable. But at the same time, operators might want to > understand just why this WG thinks it needs to specify that all links be > /64 ? > > Part of the reason that any restriction gets ignored is when the people > supposed to obey it don't understand why it is there, and see it as just > an unnecessary interference with them doing what they want. > > | Is this just because that's how it has always been done? > > I don't think so, but even if it were, surely we should require some > kind of reasonable justification in order to change people's current > operating methods? We're not just making changes to make people have > to change their ways, for our amusement, right? > > | Or are there > | real technical reasons for preferring to use longer prefixes in that > | case? There are two reasons sited in the /127 draft (see subject): > | > | - A router can easily know the address of the router > | on the other end of the link... What is this > | used for? How valuable is this? > > Not at all, that's nonsense. If you know it is a /127 (or even probably > a /126) then you can most probably predict the address of the other end, > but there's essentially no point in that (very little benefit) and what > benefit there is is mostly for the human operator (easier to work out the > ping address). That's just as easy using /64's (or /112's) and using a > consistent numbering scheme though (<whatever>::1 and <whatever>::2 or > something). > > This might explain why some people do it, but it isn't a rational reason. > > | - /127 prefixes ping-pong attacks that were possible with > | older versions of ICMP. These problems were > | fixed in ICMPv3, though, so is this really likely > | to be a problem for deployed IPv6 routers? > > I doubt it. > > | If there are sound reasons to use longer prefixes in some cases, we > | may not want to have an addressing architecture that forbids it. But, > | I haven't seen anyone speak up with those reasons. > > There isn't enough address space. > > The University of Melbourne has an IPv6 address plan (or a preliminary > one anyway, given that I'm the only user there I know of at the minute, > and I'm no-where near there just now, but anyway...). My dept (Comp > Sci & Software Eng) has been allocated 192 SLAs to use. That's > generous compared with out allocation of IPv4 addresses of course (we > have about 16 /24's, that we use mostly as /26's). > > [Aside, 3 blocks of 64 /64's, with usage of nets in each > block constrained to particular purposes, so the people who > insist on filtering can apply consistent rules to whole large > blocks of address space throughout the campus, rather than > having to know the purpose of every individual net - that is, > nets that serve open student labs get different access than > nets that serve staff workstations, and those are different again > from infrastructure nets (servers, and such)]. > > But if I have to number all my p2p links out of that space, and I have > to allocate /64's to every P2P, then those 192 are all gone long before > I start numbering anything other than P2P links (we have about 300 p2p > links to number I think - those fit in the IPv4 space real easily, as > they're almost all /32's (a few /29's), and fit easily in 2 of the /24's > that we have, leaving the other 14 /24's to number 56 ethernets and such, > which is just about what we need. > > Perhaps this is because we're one of those organisations that is in some > ways like an ISP (and on the 6bone list I think it was, ISP types were just > saying "allocate a /48 to use for all your P2P links" ... if I could do that > there would be no issue, but I cannot). Personally I don't think that's > rational address conservation for ISPs either - just because they get a /32 > of which a /48 is just a small piece, doesn't mean that the /48 should > be thrown away on a few dozen (or hundred) links, with 2 nodes on each. > > Of course, in other ways we're not an ISP, we have no customers (or not > for networking services anyway) just lots of users who connect in all kinds > of ways. > > Please, everyone, remember that when ever anything is exhaustible, the > time to conserve it is when it is plentiful, or appears that way. Then > conservation is usually quite easy. Once a shortage starts to manifest > itself (in anything from whales, to rain forests, to IP addresses) attempting > to rebuild the resource gets very very hard (and also tends to get very > unfair, as there's usually no way to reclaim what has already been wasted, > only to limit further consumption - which means those who get in early > and waste as much as they can, can end up having major advantages forever > over those who do not). > > Just look at IPv4 if evidence is needed. And remember that we're looking > back at that with the benefit of hindsight. At the time people using class A > address spaces for (relatively) small organisations didn't think they were > wasting addresses, or getting some benefit over those who came later, it > was just the way things were done. > > Now however, we know how much benefit there is to claim lots of address > space as early as possible, and then to dig in and claim "we can never give > this back or renumber, it has to be ours forever" (as one IPv6 operator > has already started doing - this isn't imagination). > > Let's not be overawed by the size of 2^128 and assume it can never run out. > It can, and will, if not managed sensibly. On the other hand, it is a > very big number, and even with H ratios, or H factors, or whatever they're > called this week, there should be plenty of address space there forever. > Provided that we don't start wasting it. > > Requiring (not just permitting, but actually requiring) that a link that > can never have more than 2 attachment points be allocated 2^64 addresses > is sending a pretty big sign to everyone that address conservation is > irrelevant. That's a very very poor message to send. > > kre > > ps: apologies for the lengths of these two messages, comes from having had > a few days away from the net, and coming back to see this issue still being > discussed, but not advanced at all - that is, all the arguments given are > going one way, but there is apparently still no consensus, because there's > either off list discussion (which should count for nothing at all), or > people are just assuming that there is some disagreement, where none is > actually being stated. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
