Hi,

> On 12 May 2015, at 14:18, Jan Ingvoldstad <[email protected]> wrote:
> 
> On Tue, May 12, 2015 at 2:26 PM, Mathew Newton 
> <[email protected] <mailto:[email protected]>> 
> wrote:
> Hi Jan,
> 
> Hi again, Matthew, and thanks for answering.
>  
> 
> -----Original Message-----
> > From: address-policy-wg [mailto:[email protected] 
> > <mailto:[email protected]>] On Behalf Of Jan Ingvoldstad
> > Sent: 12 May 2015 12:33
> 
> > How do you manage your IPv4 space, then?
> 
> Not wishing to sound flippant, but the answer to that really is 'with some 
> difficulty'. This is despite being in the fortunate position of holding a /8 
> IPv4 allocation (amongst other, smaller, ranges) in addition to widespread 
> usage of (overlapping) RFC1918 address space.
> 
> > Do you actually have routing that needs more than 8 total IPv4 spaces?
> 
> I cannot answer that directly because it is, in my view, a false dichotomy as 
> it is far more complicated a situation than that.
> 
> What it does give you, is the opportunity to create 2048 times the amount of 
> routes you could in your current IPv4 /8, without worrying about the things 
> you could do in your internal networks with the remaining part of the /64.
> 
> Besides which, migration to IPv6 would be a wasted opportunity if it was 
> rolled out and configured in exactly the same way as IPv4 given all the 
> existing problems and constraints that would continue to persist.
> 
> Oh, I agree with that. Over here, we actively abuse the system by randomly 
> generating /80 addresses for internal use, and reusing those in ways that 
> apparently never were intended by those who designed the IPv6 address 
> specification.
> 
> What I do think is a problem, though, is that IPv6 address space is 
> considered so plentiful that we're repeating the mistakes of when we thought 
> the IPv4 address space was plentiful.
> 
> I don't see a big problem with RIPE NCC evaluating requests for allocations 
> up to e.g. /24 in some very rare cases.
> 
> However, these things have a way of sliding down a slippery slope, and the 
> IPv6 address space is most likely what we're going to be stuck with for our 
> systems' lifetimes. The prospective system lifetimes are long, perhaps on the 
> order of hundreds of years.
> 
> And that's actually something we need to keep in mind when setting policy 
> today.

We’re to date only allocating from 1/8th of the overall IPv6 address space. 
There’s 7/8ths remaining in which policy can be changed, if required.

And I would put a bet on IPv6 not being the mainstream global / interplanetary 
communication protocol in hundreds of years, but I won’t be around to collect, 
so….

On the /64 boundary, I’d point you at RFC7421.

Tim

Reply via email to