Mailing List Archive: IPv6 Address Planning

IPv6 Address Planning

clerum at transaria

Aug 9, 2005, 8:53 PM

Post #1 of 30 (9649 views)

Currently we are in the process of planning our IPv6 addressing schema
for our network. We are a service provider with around 20 core routers,
and several hundred enterprise customers. These customers currently
connect back to our core via a separate VLANs or channelized
DS1/DS3/OC-X type interfaces. Thus currently lots of /30 IPv4 blocks.

Our address allocation is 2001:1940::/32

Here is our current plan, but we are looking for suggestions from people
who have been down this road before. The plan is to break out a /48 for
our organization. Then break out the first /64 for loopbacks, and the
next /64 for point-to-point connections. The PTP /64 then breaks out
further into 1 /80 for core links, and 1 /80 for each of our
distribution sites. Within these /80's are individual /112's for PTP
links. What this will allow us to do is aggregate each sites PTP
connections into /80's within our IGP.

Looks something like this.

2001:1940::/48 - TransAria

2001:1940::/64 - Loopbacks/NMS/ETC
2001:1940::1/128 - Router 1
2001:1940::2/128 - Router 2

2001:1940:0:1::/64 - PTP Links
2001:1940:1::/80 - Core Links (non-aggergratable)
2001:1940:0:1::/112 - Core Link 1
2001:1940:0:1::1 - Router A
2001:1940:0:1::2 - Router B
2001:1940:0:1::1:1/112 - Core Link 2
2001:1940:0:1::1:1 - Router A
2001:1940:0:1::1:2 - Router B

2001:1940:0:1:1::/80 - Distribution Site 1
2001:1940:0:1:1::/112 - Customer Link 1
2001:1940:0:1:1::1 - Dist Router
2001:1940:0:1:1::2 - Customer Equipment
2001:1940:0:1:1:0:1:0/112 - Customer Link 2
2001:1940:0:1:1:0:1:1 - Dist Router
2001:1940:0:1:1:0:1:2 - Customer
Equipment

2001:1940:0:1:2::/80 - Distribution Site 2
2001:1940:0:1:2:::/112 - Customer Link 1
2001:1940:0:1:2::1 - Dist Router
2001:1940:0:1:2::2 - Customer Equipment
2001:1940:0:1:2:0:1:0/112
2001:1940:0:1:2:0:1:1 - Dist Router
2001:1940:0:1:2:0:1:1 - Customer
Equipment

2001:1940:1::/48 - Customer 1 Assignment
2001:1940:2::/48 - Customer 2 Assignment
2001:1940:3::/48 - Customer 3 Assignment

Thoughts?

Thanks!

Cody

IPv6 Address Planning [ In reply to ]

Aug 9, 2005, 9:26 PM

Post #2 of 30 (9582 views)

On 9 Aug 2005, at 14:53, Cody Lerum wrote:

> Currently we are in the process of planning our IPv6 addressing schema
> for our network. We are a service provider with around 20 core routers,
> and several hundred enterprise customers. These customers currently
> connect back to our core via a separate VLANs or channelized
> DS1/DS3/OC-X type interfaces. Thus currently lots of /30 IPv4 blocks.

In case it's useful to compare a slight variation on what you
suggested, ISC uses the following address assignment plan. The main
difference between this and yours is that we assign a /48 to every site
in our network. This works for us. We like it.

[.Note that ISC is not really an ISP, and would quite possibly not
qualify for a /32 allocation from ARIN today. We were allocated
2001:4f8::/32 before the current v6 allocation policy was adopted by
ARIN.]

2001:4f8:site:vlan:hhhh:oooo:ssss:tttt

We choose one 16-bit "site" value per site. The site "0000" is special,
and is used for things like point-to-point links, /128 host routes for
services that are not deployed in a site-specific manner, etc.

2001:4f8:0000:0000:: (reserved)
2001:4f8:0000:0001:: point-to-point (/112 assignments)
2001:4f8:0000:0002:: ISC service addresses (/128 assignments)
2001:4f8:0000:0003:: guest service addresses (/128 assignments)
2001:4f8:0000:0004:: (reserved)
...
2001:4f8:0000:ffff:: (reserved)

We number internal, ISC sites from 0001 up. We number external, guest
sites from ffff down. If we were an ISP, we would probably use the word
"customer" instead of "guest".

We choose one 16-bit "vlan" value per "vlan". The vlan "0000" is
special, and is used for things like loopback /128s and other stuff
that has no useful "vlan" number.

So, examples:

The site PAO1 (529 Bryant, Palo Alto, CA, USA) is numbered within
2001:4f8:1::/48. The site SQL1 (950 Charter Street, Redwood City, CA,
USA) is numbered within 2001:4f8:3::/48. The AfNOG regional operator
meetings are assigned 2001:4f8:fffe::/48 (which is routed over a
tunnel, when there's a meeting happening).

The service www.isc.org (which moves between hosts on occasion, and is
hence not site-centric) is numbered 2001:4f8:0:2::d/128. The service
ftp.isc.org (similarly) is numbered 2001:4f8:0:2::18/128.

VLAN 14 in Redwood City is numbered 2001:4f8:3:e::/64. VLAN 505 in Palo
Alto is numbered 2001:4f8:1:1f9::/64.

Joe

IPv6 Address Planning [ In reply to ]

steffann at nederland

Aug 9, 2005, 10:57 PM

Post #3 of 30 (9561 views)

Hi,

> Within these /80's are individual /112's for PTP links.

Why use a /112 for point-to-point links? The only reference I can find is
rfc3627, and that one does not really seem to advise to use a /112 except
when using a /64 is not possible... So I am curious about why a /112 is
used.

Thanks,
Sander.

IPv6 Address Planning [ In reply to ]

mnicks at guruassist

Aug 9, 2005, 10:59 PM

Post #4 of 30 (9585 views)

I've always used /64s for point-to-point interfaces.

-M
--
Michael Nicks

-----Original Message-----
From: ipv6-ops-bounces+nicksm=guruassist.com@lists.cluenet.de
[mailto:ipv6-ops-bounces+nicksm=guruassist.com@lists.cluenet.de] On Behalf
Of Sander Steffann
Sent: Tuesday, August 09, 2005 3:57 PM
To: Cody Lerum; ipv6-ops@lists.cluenet.de
Subject: Re: IPv6 Address Planning

Hi,

> Within these /80's are individual /112's for PTP links.

Why use a /112 for point-to-point links? The only reference I can find is
rfc3627, and that one does not really seem to advise to use a /112 except
when using a /64 is not possible... So I am curious about why a /112 is
used.

Thanks,
Sander.

IPv6 Address Planning [ In reply to ]

clerum at transaria

Aug 9, 2005, 11:10 PM

Post #5 of 30 (9583 views)

The idea was to stay on a boundary for ease of subnetting, as well as
provide aggregation via /112's within /80's.

/64's are possible, but will require burning a /48 for each Distribution
site, and I was trying to reserve /48 level assignments for downstream
organizations. While also only utilizing a /48 for my organization.

Seemed to make sense to me, but this is my first run at a v6 addressing
plan.

-C

-----Original Message-----
From: Sander Steffann [mailto:steffann@nederland.net]
Sent: Tuesday, August 09, 2005 2:57 PM
To: Cody Lerum; ipv6-ops@lists.cluenet.de
Subject: Re: IPv6 Address Planning

Hi,

> Within these /80's are individual /112's for PTP links.

Why use a /112 for point-to-point links? The only reference I can find
is rfc3627, and that one does not really seem to advise to use a /112
except when using a /64 is not possible... So I am curious about why a
/112 is used.

Thanks,
Sander.

IPv6 Address Planning [ In reply to ]

rogerj at jorgensen

Aug 10, 2005, 12:22 AM

Post #6 of 30 (9583 views)

On Tue, 9 Aug 2005, Cody Lerum wrote:
>
> Here is our current plan, but we are looking for suggestions from people
> who have been down this road before. The plan is to break out a /48 for
> our organization. Then break out the first /64 for loopbacks, and the
> next /64 for point-to-point connections. The PTP /64 then breaks out
> further into 1 /80 for core links, and 1 /80 for each of our
> distribution sites. Within these /80's are individual /112's for PTP
> links. What this will allow us to do is aggregate each sites PTP
> connections into /80's within our IGP.

Would strongly suggest you forget the idea of using /80 and /112, don't
use anything smaller than /64. You might not see the need for it now but
experience have thought me to respect the /64 boundary.

--

------------------------------
Roger Jorgensen |
rogerj@stud.cs.uit.no | - IPv6 is The Key!
http://www.jorgensen.no | roger@jorgensen.no
-------------------------------------------------------

IPv6 Address Planning [ In reply to ]

merike at doubleshotsecurity

Aug 10, 2005, 12:31 AM

Post #7 of 30 (9578 views)

I was just in same situation...trying to figure out what addressing
plan makes sense for an IPv6 ISP scenario.

Although there *are* folks who are using /127 or /126 for pt-pt links
and rfc3627 does refer to using a /112 if
a /64 is not available, many folks have expressed strong opinions to
'respect the /64 boundary' :) That has been
our decision to use as well. [.after a bunch of back-and-forth and
trying to squelch the feeling of being wasteful].

Quite frankly I was a bit surprised at how all over the map the pt-pt
addressing schemes were since I was hoping to
use something that was universally thought of as best practice. And
Cody beat me to asking this list to get more opinions :)

- merike

On Aug 9, 2005, at 12:11 PM, Roger Jorgensen wrote:

> On Tue, 9 Aug 2005, Cody Lerum wrote:
>>
>> Here is our current plan, but we are looking for suggestions from
>> people
>> who have been down this road before. The plan is to break out a /48
>> for
>> our organization. Then break out the first /64 for loopbacks, and the
>> next /64 for point-to-point connections. The PTP /64 then breaks out
>> further into 1 /80 for core links, and 1 /80 for each of our
>> distribution sites. Within these /80's are individual /112's for PTP
>> links. What this will allow us to do is aggregate each sites PTP
>> connections into /80's within our IGP.
>
> Would strongly suggest you forget the idea of using /80 and /112, don't
> use anything smaller than /64. You might not see the need for it now
> but
> experience have thought me to respect the /64 boundary.
>
>
>
> --
>
> ------------------------------
> Roger Jorgensen |
> rogerj@stud.cs.uit.no | - IPv6 is The Key!
> http://www.jorgensen.no | roger@jorgensen.no
> -------------------------------------------------------
>

IPv6 Address Planning [ In reply to ]

simon at slimey

Aug 10, 2005, 12:32 AM

Post #8 of 30 (9580 views)

On Tue Aug 09, 2005 at 09:11:36PM +0200, Roger Jorgensen wrote:
> Would strongly suggest you forget the idea of using /80 and /112, don't
> use anything smaller than /64. You might not see the need for it now but
> experience have thought me to respect the /64 boundary.

Okay, I'm sticking to /64 for everything (except /128 loopbacks), but I'm
interested to know why you say experience told you to avoid non-/64's?

Simon
--
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
Director | * Domain & Web Hosting * Internet Consultancy *
Bogons Ltd | * http://www.bogons.net/ * Email: info@bogons.net *

IPv6 Address Planning [ In reply to ]

james at towardex

Aug 10, 2005, 2:37 AM

Post #9 of 30 (9573 views)

On Tue, Aug 09, 2005 at 03:10:50PM -0600, Cody Lerum wrote:
> The idea was to stay on a boundary for ease of subnetting, as well as
> provide aggregation via /112's within /80's.
>
> /64's are possible, but will require burning a /48 for each Distribution
> site, and I was trying to reserve /48 level assignments for downstream
> organizations. While also only utilizing a /48 for my organization.
>
> Seemed to make sense to me, but this is my first run at a v6 addressing
> plan.
>
> -C

Honestly, /112 vs. /64 to me is just "do whatever is comfortable for you and
your team the most" issue. At first one can do a design that will take into
consideration of aggregation in routing as much as possible, but at the end of
the day, in my experience, route aggregation at least in my internal iBGP and
IGP table do not seem to be causing too much scalability problems than
expected, that just assigning /64s in a clean manner is simpler for us..

One can also say, "why not use /126 if you are really going point to point?"
To me, personally (and this is just me by the way), a /126 makes more sense
than a /112 for PTP links. But by the same token, given that "/64 is what is
considered a subnet in IPv6" tradition still remains popular, we still remain
to use /64s at this time. I guess it does not hurt to reserve another /48
for switchover to /126 if need be in the future ;)

James

>
> -----Original Message-----
> From: Sander Steffann [mailto:steffann@nederland.net]
> Sent: Tuesday, August 09, 2005 2:57 PM
> To: Cody Lerum; ipv6-ops@lists.cluenet.de
> Subject: Re: IPv6 Address Planning
>
> Hi,
>
> > Within these /80's are individual /112's for PTP links.
>
> Why use a /112 for point-to-point links? The only reference I can find
> is rfc3627, and that one does not really seem to advise to use a /112
> except when using a /64 is not possible... So I am curious about why a
> /112 is used.
>
> Thanks,
> Sander.
>

--
James Jun
Infrastructure and Technology Services
TowardEX Technologies
Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
james@towardex.com | www.towardex.com

IPv6 Address Planning [ In reply to ]

dreeder at ipv6

Aug 10, 2005, 4:16 AM

Post #10 of 30 (9593 views)

for what its worth, ipv6.net.au uses /126s for all its ptp links (tunnels
between us and the user). Anything else is just pointless.

Dan

----- Original Message -----
From: "James" <james@towardex.com>
To: <ipv6-ops@lists.cluenet.de>
Sent: Wednesday, August 10, 2005 10:37 AM
Subject: Re: IPv6 Address Planning

> On Tue, Aug 09, 2005 at 03:10:50PM -0600, Cody Lerum wrote:
>> The idea was to stay on a boundary for ease of subnetting, as well as
>> provide aggregation via /112's within /80's.
>>
>> /64's are possible, but will require burning a /48 for each Distribution
>> site, and I was trying to reserve /48 level assignments for downstream
>> organizations. While also only utilizing a /48 for my organization.
>>
>> Seemed to make sense to me, but this is my first run at a v6 addressing
>> plan.
>>
>> -C
>
> Honestly, /112 vs. /64 to me is just "do whatever is comfortable for you
> and
> your team the most" issue. At first one can do a design that will take
> into
> consideration of aggregation in routing as much as possible, but at the
> end of
> the day, in my experience, route aggregation at least in my internal iBGP
> and
> IGP table do not seem to be causing too much scalability problems than
> expected, that just assigning /64s in a clean manner is simpler for us..
>
> One can also say, "why not use /126 if you are really going point to
> point?"
> To me, personally (and this is just me by the way), a /126 makes more
> sense
> than a /112 for PTP links. But by the same token, given that "/64 is what
> is
> considered a subnet in IPv6" tradition still remains popular, we still
> remain
> to use /64s at this time. I guess it does not hurt to reserve another /48
> for switchover to /126 if need be in the future ;)
>
> James
>
>>
>> -----Original Message-----
>> From: Sander Steffann [mailto:steffann@nederland.net]
>> Sent: Tuesday, August 09, 2005 2:57 PM
>> To: Cody Lerum; ipv6-ops@lists.cluenet.de
>> Subject: Re: IPv6 Address Planning
>>
>> Hi,
>>
>> > Within these /80's are individual /112's for PTP links.
>>
>> Why use a /112 for point-to-point links? The only reference I can find
>> is rfc3627, and that one does not really seem to advise to use a /112
>> except when using a /64 is not possible... So I am curious about why a
>> /112 is used.
>>
>> Thanks,
>> Sander.
>>
>
> --
> James Jun
> Infrastructure and Technology Services
> TowardEX Technologies
> Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
> james@towardex.com | www.towardex.com
>
>

IPv6 Address Planning [ In reply to ]

pekkas at netcore

Aug 10, 2005, 7:04 AM

Post #11 of 30 (9575 views)

On Tue, 9 Aug 2005, Sander Steffann wrote:
>> Within these /80's are individual /112's for PTP links.
>
> Why use a /112 for point-to-point links? The only reference I can find is
> rfc3627, and that one does not really seem to advise to use a /112 except
> when using a /64 is not possible... So I am curious about why a /112 is used.

FWIW, IMHO there's little difference between a /64 and /112
_technically_.

We ended up using /112's in our backbone because we wanted to create a
nice "mapping" mechanism, where we encode the region of the pop, the
pop itself, and the sequence number of the router in the pop in the
prefix. Just by looking at a p2p link prefix, I can see the routers
which it connects. As DNS exists for reverse lookups, I don't think
this is necessary, but we felt this provided some value, so we ended
up using /112's.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

IPv6 Address Planning [ In reply to ]

jorgen at hovland

Aug 10, 2005, 10:10 AM

Post #12 of 30 (9576 views)

If a /64 can contain a single user but also 25000 users, then I am sure you
all will agree on that this will affect the transition from existing v4
services to v6.
When it comes to implementing restrictions and limitations on your services,
statistics, classification (for banners/ads etc) and so on, you will most
likely be forced to treat a /64 as 1 user and not 25k.
The people using /112 are already doomed due to this "greediness".
Note that I do not have a suggestion to how it should be and I am not sure
if there should be any, but if the only reason for this addressing scheme is
to ease the subnetting then you obviously have a problem with your existing
addressing system and should take measures to improve it instead. As a
suggestion, perhaps you want something like this:

# ./allocate 2001:293a:83:: /84 92833477
Finding a free /84 from within the subnet
> 2001:293a:83::/40 (Slot #2)
>> 2001:293a:83::/48 (POP #138)
>>> 2001:293a::/32 (My ISP AG)
please hold...

2001:293a:83:0:c939::0/84 has been allocated to customer ID 92833477
(Netsystems AG), whois updated

And then you add it in bgp, static route or whatever.

Maybe we should be more concerned about how it will affect our existing
services when switching them over to v6 rather than making what seems to be
an easy addressing plan at first glance. It's not like you are going to
remember all your addressing schemes anyway, are you?

j
J?rgen Hovland ENK

-----Original Message-----
From: ipv6-ops-bounces+jorgen=hovland.cx@lists.cluenet.de
[mailto:ipv6-ops-bounces+jorgen=hovland.cx@lists.cluenet.de] On Behalf Of
Simon Lockhart
Sent: 10. august 2005 00:32
To: Roger Jorgensen
Cc: ipv6-ops@lists.cluenet.de
Subject: Re: IPv6 Address Planning

On Tue Aug 09, 2005 at 09:11:36PM +0200, Roger Jorgensen wrote:
> Would strongly suggest you forget the idea of using /80 and /112, don't
> use anything smaller than /64. You might not see the need for it now but
> experience have thought me to respect the /64 boundary.

Okay, I'm sticking to /64 for everything (except /128 loopbacks), but I'm
interested to know why you say experience told you to avoid non-/64's?

Simon
--
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
Director | * Domain & Web Hosting * Internet Consultancy *
Bogons Ltd | * http://www.bogons.net/ * Email: info@bogons.net *

IPv6 Address Planning [ In reply to ]

jordi.palet at consulintel

Aug 10, 2005, 10:21 AM

Post #13 of 30 (9586 views)

One option that I've used and seen used by others several times is /126.

Also it could be convenient to use the first /64 of each /48 to number the
"customer" infrastructure (here you still can choose the /126, of course).

Regards,
Jordi

> De: Cody Lerum <clerum@transaria.com>
> Responder a: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de>
> Fecha: Tue, 9 Aug 2005 12:53:10 -0600
> Para: <ipv6-ops@lists.cluenet.de>
> Asunto: IPv6 Address Planning
>
> Currently we are in the process of planning our IPv6 addressing schema
> for our network. We are a service provider with around 20 core routers,
> and several hundred enterprise customers. These customers currently
> connect back to our core via a separate VLANs or channelized
> DS1/DS3/OC-X type interfaces. Thus currently lots of /30 IPv4 blocks.
>
> Our address allocation is 2001:1940::/32
>
> Here is our current plan, but we are looking for suggestions from people
> who have been down this road before. The plan is to break out a /48 for
> our organization. Then break out the first /64 for loopbacks, and the
> next /64 for point-to-point connections. The PTP /64 then breaks out
> further into 1 /80 for core links, and 1 /80 for each of our
> distribution sites. Within these /80's are individual /112's for PTP
> links. What this will allow us to do is aggregate each sites PTP
> connections into /80's within our IGP.
>
> Looks something like this.
>
> 2001:1940::/48 - TransAria
>
> 2001:1940::/64 - Loopbacks/NMS/ETC
> 2001:1940::1/128 - Router 1
> 2001:1940::2/128 - Router 2
>
> 2001:1940:0:1::/64 - PTP Links
> 2001:1940:1::/80 - Core Links (non-aggergratable)
> 2001:1940:0:1::/112 - Core Link 1
> 2001:1940:0:1::1 - Router A
> 2001:1940:0:1::2 - Router B
> 2001:1940:0:1::1:1/112 - Core Link 2
> 2001:1940:0:1::1:1 - Router A
> 2001:1940:0:1::1:2 - Router B
>
> 2001:1940:0:1:1::/80 - Distribution Site 1
> 2001:1940:0:1:1::/112 - Customer Link 1
> 2001:1940:0:1:1::1 - Dist Router
> 2001:1940:0:1:1::2 - Customer Equipment
> 2001:1940:0:1:1:0:1:0/112 - Customer Link 2
> 2001:1940:0:1:1:0:1:1 - Dist Router
> 2001:1940:0:1:1:0:1:2 - Customer
> Equipment
>
> 2001:1940:0:1:2::/80 - Distribution Site 2
> 2001:1940:0:1:2:::/112 - Customer Link 1
> 2001:1940:0:1:2::1 - Dist Router
> 2001:1940:0:1:2::2 - Customer Equipment
> 2001:1940:0:1:2:0:1:0/112
> 2001:1940:0:1:2:0:1:1 - Dist Router
> 2001:1940:0:1:2:0:1:1 - Customer
> Equipment
>
> 2001:1940:1::/48 - Customer 1 Assignment
> 2001:1940:2::/48 - Customer 2 Assignment
> 2001:1940:3::/48 - Customer 3 Assignment
>
> Thoughts?
>
> Thanks!
>
> Cody

************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

IPv6 Address Planning [ In reply to ]

iljitsch at muada

Aug 10, 2005, 10:22 AM

Post #14 of 30 (9577 views)

On 10-aug-2005, at 10:09, J?rgen Hovland wrote:

> If a /64 can contain a single user but also 25000 users, then I am
> sure you
> all will agree on that this will affect the transition from
> existing v4
> services to v6.
> When it comes to implementing restrictions and limitations on your
> services,
> statistics, classification (for banners/ads etc) and so on, you
> will most
> likely be forced to treat a /64 as 1 user and not 25k.

Note that we were talking about internal stuff between routers before.

You really shouldn't give customers artificially small subnets in
IPv6, because that way they can't further subnet themselves or
autoconfigure.

IPv6 Address Planning [ In reply to ]

mohacsi at niif

Aug 10, 2005, 10:27 AM

Post #15 of 30 (9593 views)

On Tue, 9 Aug 2005, Cody Lerum wrote:

> Currently we are in the process of planning our IPv6 addressing schema
> for our network. We are a service provider with around 20 core routers,
> and several hundred enterprise customers. These customers currently
> connect back to our core via a separate VLANs or channelized
> DS1/DS3/OC-X type interfaces. Thus currently lots of /30 IPv4 blocks.
>
> Our address allocation is 2001:1940::/32
>
> Here is our current plan, but we are looking for suggestions from people
> who have been down this road before. The plan is to break out a /48 for
> our organization. Then break out the first /64 for loopbacks, and the
> next /64 for point-to-point connections. The PTP /64 then breaks out
> further into 1 /80 for core links, and 1 /80 for each of our
> distribution sites. Within these /80's are individual /112's for PTP
> links. What this will allow us to do is aggregate each sites PTP
> connections into /80's within our IGP.
>

Another option, that used by us:
-Allocate /48 for customers
-Use /128 for loopbacks
-Use /64 where necessary to have addressable interfaces.
-Use linklocal for p2p links - even for p2p Ethernet. If there is a need
you can add /64 later. This does not break IGP:
- OSPFv3 uses linklocal addresses
- IS-IS uses NSAP addresses
However for traceroute you might have to setup for each interface "ipv6
unnumbered loopback?" - according to Cisco terminology- to have consistent
output.

For the aggregation use your network hierarchy. e.g. /40 for regions
etc...

Regards,

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98

IPv6 Address Planning [ In reply to ]

jorgen at hovland

Aug 10, 2005, 10:48 AM

Post #16 of 30 (9584 views)

----- Original Message -----
From: "Iljitsch van Beijnum" <iljitsch@muada.com>

>Note that we were talking about internal stuff between routers before.

We do not normally allocate a range for a POP which again is subnetted to
customers. The reason is that a customer might move (and they do) and want
to keep its range. We might also have several POPs in the same place, and
moving the customer to another POP for some valid reason. This is what we
also do with v4 (we don't use iBGP for /32 ppp links and similar services
obviously, they are aggregated).

>You really shouldn't give customers artificially small subnets in IPv6,
>because that way they can't further subnet themselves or autoconfigure.

As long as the prefixlen is smaller than /128 they can always subnet.
Arguing wether 18446744073709551616 or 17592186044416 ips is enough for
subnetting is probably not a good idea.

IPv6 Address Planning [ In reply to ]

rogerj at jorgensen

Aug 10, 2005, 1:05 PM

Post #17 of 30 (9583 views)

On Tue, 9 Aug 2005, Cody Lerum wrote:

> The idea was to stay on a boundary for ease of subnetting, as well as
> provide aggregation via /112's within /80's.
>
> /64's are possible, but will require burning a /48 for each Distribution
> site, and I was trying to reserve /48 level assignments for downstream
> organizations. While also only utilizing a /48 for my organization.

why a /48 for each? Use a /48 globaly in your network for p2p links? Or
break out smaller pieces from the /48, a /56 or /52 for each site. (know
it's not widely accepted but the last discussion the topic seemed to agree
/52's are okay?)

> Seemed to make sense to me, but this is my first run at a v6 addressing
> plan.
>
> -C
>
> -----Original Message-----
> From: Sander Steffann [mailto:steffann@nederland.net]
> Sent: Tuesday, August 09, 2005 2:57 PM
> To: Cody Lerum; ipv6-ops@lists.cluenet.de
> Subject: Re: IPv6 Address Planning
>
> Hi,
>
> > Within these /80's are individual /112's for PTP links.
>
> Why use a /112 for point-to-point links? The only reference I can find
> is rfc3627, and that one does not really seem to advise to use a /112
> except when using a /64 is not possible... So I am curious about why a
> /112 is used.
>
> Thanks,
> Sander.
>
>
>
>

--

------------------------------
Roger Jorgensen |
rogerj@stud.cs.uit.no | - IPv6 is The Key!
http://www.jorgensen.no | roger@jorgensen.no
-------------------------------------------------------

IPv6 Address Planning [ In reply to ]

rogerj at jorgensen

Aug 10, 2005, 1:10 PM

Post #18 of 30 (9581 views)

On Tue, 9 Aug 2005, Simon Lockhart wrote:
> On Tue Aug 09, 2005 at 09:11:36PM +0200, Roger Jorgensen wrote:
> > Would strongly suggest you forget the idea of using /80 and /112, don't
> > use anything smaller than /64. You might not see the need for it now but
> > experience have thought me to respect the /64 boundary.
>
> Okay, I'm sticking to /64 for everything (except /128 loopbacks), but I'm
> interested to know why you say experience told you to avoid non-/64's?

old story really but when I started out I didn't really see the need for
using a /64 for p2p links, or even a /112 or /126. So at some point they
introduced anycast (think that's the name) and my usage of /127 gave me a
nice /dev/null feature for all those links :} Fixed it by adding a /128
for each of the IPs in the /127... I'm quite sure more of these type of
features/changes will arrive in the future.

and as I said in a private mail to Cody, wouldn't surprise me if some
vendor start to use 64bits uniq ID for interfaces or other places and
then all of your p2p links needs to be redone. Not really likely but who
knows?

--

------------------------------
Roger Jorgensen |
rogerj@stud.cs.uit.no | - IPv6 is The Key!
http://www.jorgensen.no | roger@jorgensen.no
-------------------------------------------------------

IPv6 Address Planning [ In reply to ]

Aug 10, 2005, 1:49 PM

Post #19 of 30 (9591 views)

Cody,

To add to the opinions, here's how BIT practices IPv6. We assign one /48
to each core router in our network (and have room for 63 of those core
routers currently:

2001:7b8::/32 BIT
2001:7b8:0000::/44 are points of presence (aka core-routers)
2001:7b8:0::/48 reserved
2001:7b8:1::/48 router1,
2001:7b8:2::/48 router2,
..
2001:7b8:3f::/48 router63

2001:7b8:40::/44 are transitnetworks (/64 each)
2001:7b8:40:1::/64 transitnet1
2001:7b8:40:1::/64 transitnet1
2001:7b8:80:: up to 2001:7b8:200:: are reserved in /44 chunks to
facilitate either new POP space or new transitnetworks.

2001:7b8:200::/40 customer allocations, 256 of size /48 each
2001:7b8:200::/48 customer0
2001:7b8:2ff::/48 customer255

2001:7b8:300::/40 is our SixXS tunnelbroker space, where
2001:7b8:300::/48 is /64 transitnetworks, and
2001:7b8:301::/48 sixxs-net1
2001:7b8:3ff::/48 sixxs-net255

2001:7b8:400::/40 and up are free for either tunnels or customers.

A POP consists of:
2001:7b8:3::/48 jun1.kelvin.network.bit.nl
2001:7b8:3:XYYY::/64 where YYY are 12 bits for VLANs and X are 4 bits
for physical interfaces.

An exception to this rule is our DSL space. This done as follows:
2001:7b8:5:XXYY:ZZZZ::/80, where
XX is the ATM interface number, YY is the VCI and ZZZZ is the VPI. This
way we can number a lot of customers in one /48 while keeping a scalable
scheme. We do not autoconfigure our RFC1483 DSL downstreams, while we
have a pool (XX=255) which is planned to give out /80s to customers
using PPP autonegotiation.

I feel that using smaller-than /64 networks is just fine where one does
not need autonegotiation. Otherwise, ISPs will be throwing away large
amounts of /48s on DSL interconnects, allthough BIT might change this
policy later on in life [.ie, when we have a tool which maps VCI/VPI to
/64 transitnetwork, and then numbering from 1 to N for customer links in
stead of deriving the transitnetwork from iface/vci/vpi directly].

Hope this helps.

--
---------- - - - - -+- - - - - ----------
Pim van Pelt Email: pim@ipng.nl
http://www.ipng.nl/ IPv6 Deployment
-----------------------------------------------

IPv6 Address Planning [ In reply to ]

dgethings at dsl

Aug 11, 2005, 9:33 PM

Post #20 of 30 (9573 views)

> -----Original Message-----
>
> for what its worth, ipv6.net.au uses /126s for all its ptp
> links (tunnels between us and the user). Anything else is
> just pointless.
<pun>
Surely you mean pointless to pointless.
</pun>

Sorry about that couldn't resist.

Cheers

Dg

IPv6 Address Planning [ In reply to ]

dreeder at ipv6

Aug 13, 2005, 1:34 PM

Post #21 of 30 (9584 views)

not sure that I entirely understand what the joke is there, Dg...

the /126 is between the the customer and the isp. Two usable addresses for
the point to point.
The customer gets a /48 assigned to them to do whatever they want.
You ask why /126? I ask you: why not?

Dan
----- Original Message -----
From: "David Gethings" <dgethings@dsl.pipex.com>
To: <ipv6-ops@lists.cluenet.de>
Sent: Friday, August 12, 2005 5:33 AM
Subject: RE: IPv6 Address Planning

>> -----Original Message-----
>>
>> for what its worth, ipv6.net.au uses /126s for all its ptp
>> links (tunnels between us and the user). Anything else is
>> just pointless.
> <pun>
> Surely you mean pointless to pointless.
> </pun>
>
> Sorry about that couldn't resist.
>
> Cheers
>
> Dg
>
>
>

IPv6 Address Planning [ In reply to ]

iljitsch at muada

Aug 13, 2005, 2:04 PM

Post #22 of 30 (9582 views)

On 13-aug-2005, at 13:34, Dan Reeder wrote:

> the /126 is between the the customer and the isp. Two usable
> addresses for the point to point.

Actually it's three usable addresses. :-)

You can't use the all-zeros address because it's supposed to be the
subnet all-routers anycast address, but the all-ones address is fair
game.

> The customer gets a /48 assigned to them to do whatever they want.
> You ask why /126? I ask you: why not?

Since you ask...

- it's inconvenient because you need to do (some) binary math to
determine which addresses go together. With a /124 you can use the
last digit for this, so that's easier

- doesn't accommodate for the 128 reserved anycast addresses, but a /
120 does

- you need to keep track of which router has which address. with
eui-64 addressing and a /64 you don't (whether this is useful depends
on whether you need to refer to the other side's address elsewhere.
for customers you generally do to route their /48 or what have you to
them, for internal stuff you don't, routing protocols take care of it)

IPv6 Address Planning [ In reply to ]

dreeder at ipv6

Aug 14, 2005, 3:10 AM

Post #23 of 30 (9590 views)

> - it's inconvenient because you need to do (some) binary math to
> determine which addresses go together. With a /124 you can use the last
> digit for this, so that's easier

easy to do in php, which is what the web-based tunnelbroker is built on in
the first place - simple.

> - doesn't accommodate for the 128 reserved anycast addresses, but a / 120
> does

why is there a need for anycast on a peer-to-peer link? there should be no
data on that link except data sent specifically from one end to the other.

> - you need to keep track of which router has which address. with eui-64
> addressing and a /64 you don't (whether this is useful depends on whether
> you need to refer to the other side's address elsewhere. for customers
> you generally do to route their /48 or what have you to them, for
> internal stuff you don't, routing protocols take care of it)

not required in a ptp link, with all references to the routing for the two
addresses (/128) and the end user allocation (/48) in question already taken
care of by php, mysql, and quagga.

Honestly folks, talk about storm in a teacup. Its logical, its simple,
nothing is broken: it just works.

Dan

----- Original Message -----
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
To: "Dan Reeder" <dreeder@ipv6.net.au>
Cc: <ipv6-ops@lists.cluenet.de>
Sent: Saturday, August 13, 2005 9:43 PM
Subject: Re: IPv6 Address Planning

> On 13-aug-2005, at 13:34, Dan Reeder wrote:
>
>> the /126 is between the the customer and the isp. Two usable addresses
>> for the point to point.
>
> Actually it's three usable addresses. :-)
>
> You can't use the all-zeros address because it's supposed to be the
> subnet all-routers anycast address, but the all-ones address is fair
> game.
>
>> The customer gets a /48 assigned to them to do whatever they want.
>> You ask why /126? I ask you: why not?
>
> Since you ask...
>
> - it's inconvenient because you need to do (some) binary math to
> determine which addresses go together. With a /124 you can use the last
> digit for this, so that's easier
>
> - doesn't accommodate for the 128 reserved anycast addresses, but a / 120
> does
>
> - you need to keep track of which router has which address. with eui-64
> addressing and a /64 you don't (whether this is useful depends on whether
> you need to refer to the other side's address elsewhere. for customers
> you generally do to route their /48 or what have you to them, for
> internal stuff you don't, routing protocols take care of it)
>
>
>

IPv6 Address Planning [ In reply to ]

rogerj at jorgensen

Aug 15, 2005, 3:53 PM

Post #24 of 30 (9576 views)

On Sun, 14 Aug 2005, Dan Reeder wrote:
>
> > - doesn't accommodate for the 128 reserved anycast addresses, but a / 120
> > does
>
> why is there a need for anycast on a peer-to-peer link? there should be no
> data on that link except data sent specifically from one end to the other.

it's not really an options, it's the way it is, just accept it.

<snip>
> > - you need to keep track of which router has which address. with eui-64
> > addressing and a /64 you don't (whether this is useful depends on whether
> > you need to refer to the other side's address elsewhere. for customers
> > you generally do to route their /48 or what have you to them, for
> > internal stuff you don't, routing protocols take care of it)
>
> not required in a ptp link, with all references to the routing for the two
> addresses (/128) and the end user allocation (/48) in question already taken
> care of by php, mysql, and quagga.
>
> Honestly folks, talk about storm in a teacup. Its logical, its simple,
> nothing is broken: it just works.

it don't juts work, the /128, /127, /126 is a good exampe of that, due to
change a /127 isn't usable over night :}

the only way you can be guaranatied it will work are to use /64, or /112
as everyone claim is okay...

---

------------------------------
Roger Jorgensen |
rogerj@stud.cs.uit.no | - IPv6 is The Key!
http://www.jorgensen.no | roger@jorgensen.no
-------------------------------------------------------

IPv6 Address Planning [ In reply to ]

lerik at nolink

Aug 16, 2005, 5:08 PM

Post #25 of 30 (9585 views)

On Mon, 15 Aug 2005, Roger Jorgensen wrote:

> On Sun, 14 Aug 2005, Dan Reeder wrote:
>>
>>> - doesn't accommodate for the 128 reserved anycast addresses, but a / 120
>>> does
>>
>> why is there a need for anycast on a peer-to-peer link? there should be no
>> data on that link except data sent specifically from one end to the other.
>
> it's not really an options, it's the way it is, just accept it.

"The reasonable man adapts himself to the world; the unreasonable one
persists to adapt the world to himself. Therefore all progress depends on
the unreasonable man." - George Bernard Shaw

Accepting that you'd need space for 128 reserved anycast addresses on a
p-t-p link is not something I'm prepared to do, I prefer to remain
unreasonable. :)

>> Honestly folks, talk about storm in a teacup. Its logical, its simple,
>> nothing is broken: it just works.
>
> it don't juts work, the /128, /127, /126 is a good exampe of that, due to
> change a /127 isn't usable over night :}

/127 still seem to work just fine on my gear, fwiw. Although we use /126
ourselves in the production network, and are considering standardizing
on /124 instead due to them being more "human-friendly".

> the only way you can be guaranatied it will work are to use /64, or /112
> as everyone claim is okay...

Or, if it turns out "everyone" is actually using longer prefixes, then the
vendors will make sure to support it. They follow the money. And don't
particularly care what the academics and other non-ops people who spend
their time bickering in various IETF-WGs over pointless details says as
long as their real-world customers pay.

Sometimes capitalism actually works rather well.

/leg