Robin, On 2008-05-28 13:54, Robin Whittle wrote: > This will no-doubt displease some folks, but here is a set of points > which I think we need to agree upon soon in order to make sufficient > progress to achieve a useful recommendation in March 2009. > > Without such agreement, or something similar, I think we would waste > time arguing about: > > a - A solution which involves significant host changes - and > therefore which could never be implemented in a reasonable > time-frame.
We'd certainly waste time by arguing about it as an abstract principle. But there is evidence that new TCP/IP stacks can be rolled out in the major operating systems on a timescale of a few years, so I would be prepared to consider a solution that includes incremental roll-out to hosts. I think we agree that we're unlikely to invent a solution that solely depends on that, however. In any case I suggest it's already off the research table, since shim6 is already in the IETF process, so not worth discussing here. > b - Router based translation schemes which can't be practical for > IPv4. http://psg.com/lists/rrg/2008/msg01314.html I think it's pretty clearly established that, due to the shortage of IPv4 prefixes, either map-and-encap or pure NAT is *required* for IPv4, iff we believe that the remaining scaling of IPv4 usage will actually exceed BGP4 scaling capability. However, I would observe (even as a well-known NAT hater) that we have *already* broken the IPv4 transparency model by widespread use of NAT. So one can legitimately ask: does it really matter if we break IPv4 transparency even more by deploying much more NAT? What I'm getting at is that it doesn't follow that we need the same solution for IPv4 as for IPv6. We could consider "doing it right" for IPv6 and struggling on with NAT for IPv4. (I can't believe I just wrote that ;-( ) > c - The prospects for near-term (next 5 years or so) widespread > adoption of IPv6 - because we haven't formed a clear > consensus that we need to solve the IPv4 routing scaling > problem directly, but think it could or should be solved by > mass migration from IPv4 to IPv6. I haven't used the word 'migration' for years in that context. The model is very clearly one of long-term *coexistence* of v4 and v6. So v6 deployment is definitely not an excuse for ignoring v4 scaling. > > > Here is the rough list of points, all of which have been discussed > in greater detail in recent days: > > 1 - The scope of the RRG's work should focus on IP addresses and > network based solutions - involving new router functions > and/or new network elements. The solution should not involve > any changes to host stacks or applications, except perhaps > to optimise performance which is degraded by the main solution. I mainly agree with that. Some host based approaches (shim6 and sctp) are already in standards development. However, I think we should have ILNP on the radar screen. > > Discussion of longer-term architectural solutions involving > changing or underpinning existing host-level protocols - > necessarily involving changes to host stacks and/or > applications - should be directed to another forum. > > > 2 - The solution must work for IPv4 and IPv6 and show promise > for being adopted by the majority of end-user networks > in the 3 years following deployment, such as in the 2012 to > 2015 time-frame. While this adoption will be supported and > encouraged by administrative and perhaps business arrangements, > the primary reason for adoption will be the immediate benefits > to the ISPs and end-user networks. See above comment re different solutions for the two cases. > > (We don't have a good definition of "end-user networks", but I > suggest it should include all sizes - existing and new - including > single-host networks: from the largest universities and corporations > down to individuals on DSL lines and with cell-phones.) > > > 3 - The solution must provide portable address space for > end-user networks without impacting the scaling of the > current BGP routing system. (The map-encap schemes do this.) I don't agree. The desire for "portable" prefixes is an artefact of IPv4 experience. Let me reformulate. The solution must allow the option of provider-independent address space and the option of multiple provider-dependent address spaces for end-user networks... I don't think we should constrain the future in a way that IP does not do today. > 4 - As already agreed, the solution needs to support multihoming > and traffic engineering in a scalable fashion. Yes. Brian -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
