One thing I'm pretty sure of is that allocating this space for another RFC1918-like private network block isn't going to solve the collision problem. I could see more utility in letting this be space for "router" use only, say to allow cable ISPs to assign such addresses to non-publicly accessible components in their networks. Such use would presumably have fewer deployment barriers than use as either ordinary public or private space. I could also see some utility in assigning smaller blocks from this space to enterprise networks, similar to ULIAs in IPv6. Such blocks could be used, for instance, to interconnect between private networks without address collisions. But for that kind of use I would assume that the deployment barriers would be much greater. Bottom line - I think that any proposal to reassign class E addresses needs to provide one or more specific use cases. And for each of those cases, it should consider deployment cost vs. benefit, and compare that to the cost vs. benefit of using IPv6. Keith > Keith, all, > > The common use case that people discuss is cable. My impression is > that CableLabs has done a pretty good job of driving IPv6 adoption in > cable modems for DOCSIS 3.0. The authors being from APNIC, I would > imagine there is a billion person problem (or so) to be solved? > > What I'd ask, therefore, is that the authors include in their > introduction answers to the following questions: > > 1. Should the address space be allocated to private networks? If so, > please give some examples of uses. > 2. If the space is to be allocated for global reachability, could you > please provide a current estimate as to how much time is bought? > > In addition, while I don't think the coding issues are all that > substantial, deployment issues could be sizable. Anyone planning to > make use of this address space because they have exhausted 10/8 should > CLEARLY be making plans to go to IPv6. Anyone expecting to avoid a > collision through the use of this space should be cautioned. > > Also the document should be in the same class as RFC 1918, which is a > BCP and not a standard. If you proceed, you might want to consider > obsoleting 1918 in favor of an abbreviated replacement, as much of the > text in that document is dated. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf