ACSP Suggestion 2008.10: High Latency IPv6 Allocation Blocks
Suggestion
Author: Bill Nicholls
Submitted On: 05 March 2008
Description:
Consideration of a future internet of interplanetary or wider organization, segmentation of the IPv6 address to separate long transfer/response times from local actions will be essential to avoid unworkable BGP and other maintenance operations.
I will be happy to submit the details with rationale for their choice if there is interest.
Timeframe: Immediate
Status: Completed Updated: 19 March 2008
Tracking Information
ARIN Comment
19 March 2008
This suggestion regarding High Latency IPv6 Blocks for Allocations reflects a policy proposal, and is therefore better directed through the ARIN public policy process.
ARIN recommended to the author to post a draft proposal out on the Public Policy mailing list for comment prior to submitting a formal proposal. Or attend the ARIN XXI meeting in Denver during April 6-9, 2008, to present the proposal during ARIN’s Open Policy Hour to receive initial community feedback and then subsequently submit a formal policy proposal. Lastly, to submit a formal policy proposal according to the guidelines of the Internet Resource Policy Evaluation Process (IRPEP).
Suggestion 2008.10 is now considered closed.
Author Comment
05 March 2008
Rationale:
A Proposed V6 Address Design
Let me preface the details by stating my reason for choosing a segmented address allocation:
I believe that the BGP update requirement will drive us to segmentation to prevent a BGP update explosion which would choke the processors and probably cause the whole system to become unstable.
At this time I have no hard proof of this assertion. I base it on long experience in the IT industry with various technologies, some of which ran into similar limitations. For example, can you imagine a gigabyte memory built on magnetic core technology? It could probably be built, but would it be useful? Could we afford it in quantity? I think not.
The internet routing problem faces a similar limitation – we can build ever larger and faster routers, but they cannot scale as fast as the BGP demand will grow. If we cannot build a solution, we need to change the problem (routing spec) to something that we can scale. Thus my argument for segmentation as a ‘change the problem’ approach.
Segmentation Concept:
My basic segmentation plan is simple, meant to illustrate a class of solutions rather than nail down a specific optimal one. It would not surprise me to find that there is no optimum solution, only a class of tradeoffs for different segments. However, if we can design a system where the segments are losely coupled, the potential for cascading problems is significantly reduced.
For conceptual purposes, I divided the 16 byte address into segments in most to least significant order. Note that I expect that a real world design will not be so symmetric.
Reserved – For future category/class separation: 1 byte except value zero
Top segment – Interplanetary - Everything outside a planet’s satellites: 2 bytes
Second segment - Satellites, local and remote orbits: 3 bytes
Third segment – Global and regional distribution to large cities: 3 bytes
Reserved for either global or local extensions: 1 byte
Fourth segment – Small cityand local population centers: 6 bytes
A Few Practical Considerations:
As a first cut to reality, I expect that the fourth segment will need 6 bytes, and the third only three or four. The second segment could become quite large as our move into space accelerates over the next 20-40 years. We are still in the very early days of space exploration which will change dramatically when reusable launchers will dramatically drop the cost of space access. The very first of these are known as Spaceship One and Two.
<SF mode>
A galactic ambassador arrives with many shiny things. However, the planned relationship flounders when the technical advisor tells us that the Galaxy’s communication service only allocates eight bytes per solar system, and we are incompatible. :-}}</SF mode>