using "reserved" IPv6 space

Owen DeLong owen at
Sun Jul 15 00:02:07 UTC 2012

On Jul 14, 2012, at 2:04 PM, Laurent GUERBY wrote:

> On Sat, 2012-07-14 at 09:18 -0700, Owen DeLong wrote:
>> On Jul 14, 2012, at 9:08 AM, Jérôme Nicolle wrote:
>>> Le 13/07/12 16:38, -Hammer- a écrit :
>>>> In the past, with IPv4, we have used reserved or "non-routable"
>>> I guess "non-routable IPv4" translates well to "non-routable IPv6", thus
>>> putting Link-Local addresses on top of the list.
>>> Thought you may use th auto-configured addresses for that purpose, you
>>> also may set LLAs to your liking. I use fe80::zone_ID:interface_ID , and
>>> set such LLA to every gateways to make routing tables more legible,
>>> those ID beeing arbitrary 16bit values.
>> Given that zone_IDs in my environments consist of terms like:
>> fxp0
>> en0
>> eth0
>> ge-0/0/0.0
>> etc.
>> How, exactly, would you turn those into part of an IPv6 address?
> Hi,
> We use LLA to "virtualize" interconnection to our users:
> their network configuration is always static default via fe80::nnnn
> and we route their /56 prefix to fe80::xxxx:yyyy where xxxx:yyyy is
> unique per user - if our user want to do some routing of course.  Since
> we don't have GUA interconnections we don't have to manage them inside
> our AS and we can move user stuff around without having them changing
> anything to their static configuration.
> We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256
> "IP", it's nice to have more than one /64 around for some uses.
> Is there any "mass" hoster around that does provide by default a pefix
> larger than /64 and that does route it to the user? It's quite simple to
> do in IPv6 and we have the address space for it.
> Sincerely,
> Laurent

Why not just give each end-site a /48?

An end-site with a /24 may only need a single or a few subnets while an end-site with a /32 may have a host of subnets behind their IPv4 NAT gateway. Making IPv6 topological assumptions for your end-users based on their IPv4 presentation makes little sense to me and is likely a disservice to your end users.


More information about the NANOG mailing list