[address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

On Tue, May 12, 2015 at 2:26 PM, Mathew Newton <
Mathew.Newton643 at official.mod.uk> wrote:

> Hi Jan,
>

Hi again, Matthew, and thanks for answering.


>
> -----Original Message-----
> > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20150512/b6dcc272/attachment.html>