On Tue, May 12, 2015 at 2:26 PM, Mathew Newton < [email protected]> wrote:
> Hi Jan, > Hi again, Matthew, and thanks for answering. > > -----Original Message----- > > From: address-policy-wg [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. -- Jan
