Hi Gert, Thanks for your response and for changing the subject line. I agree this is a difficult proposal to make at present. It is early days regarding a "new architecture", but the only proposals which involve no host changes and which work for both IPv4 and IPv6 are in two classes. Firstly BGP improvements. Secondly, ITR-ETR tunneling schemes, as a form of "locator-ID separation, which are IP-based have nothing directly to do with BGP. Unless someone invents a dramatic (several orders of magnitude) improvement to BGP regarding the number of prefixes the global system can handle, and unless someone invents a totally different solution for BGP-less multihoming, portability etc. than the ITR-ETR tunneling schemes, then I think one of these IP-based ITR-ETR tunneling schemes will be built. I guess that some time in the next year or so the BGP proposals and one of the IP-based schemes will be given to IETF WGs for serious development. I imagine that most people would think that these schemes are not yet well developed enough to justify locking up address space to await their completion. However, if nothing is done soon, then there won't be any fresh space left when the new scheme is ready to run. I think that the chosen IP-based ITR-ETR tunneling scheme will still be used to greatly improve the utilisation of IPv4 space, using space which is currently assigned. So it is not disastrous for long-term efficient use of the IPv4 space if no fresh space is reserved. Over time, if the scheme works as well as I think it will, a lot of the currently assigned address space would be assigned to the new scheme without any need for incentives. Roque Gagliano wrote:
What about using the Class E for this use?
Can anyone comment on how the installed base of operating systems is likely to handle 240.0.0.0/4? It is not 224.0.0.0/4 multicast, but it has never been used. So I guess there has been no testing of how it would be handled. If this space was universally, or almost universally, handled well by operating systems and any other devices (routers, WiFi cameras, NAT software etc.) then it may need only an administrative change to use it for general Internet traffic. But if this is the case, then why wouldn't it be allocated to RIRs in the usual way? Randy Bush wrote:
until the map and encap and other hackers give way to good math folk, we will get nowhere. and there has been zero motion in this direction.
I used to have a gung-ho approach to dragging that slacker protocol BGP into the modern world. Imagine a modern IT system gagging on a few hundred thousand of anything, especially when most of these things don't change from one week to the next! It would be great if you and these bright math people could contribute to the discussion in the Routing Research Group, to soup up BGP or replace it incrementally with something far better. Before doing so, you might like to read my message where I summarise how I came to realise why the performance of the BGP network is unlikely to be drastically improved, at least in terms of the number of prefixes it handles. http://www1.ietf.org/mail-archive/web/ram/current/msg01645.html I try to maintain a list of potential BGP improvements at: http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_improvements but the best place to look is the RRG's wiki: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup and the IDR WG, for which there are links in my previous message. - Robin http://www.firstpr.com.au/ip/ivip/