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.
Hm, I would keep the first /48 apart for your own services. Addresses in that first /64 are nice and short.
Then a /48 for the routers. You only need /128s for the loopbacks of course, but you may not even need IPv6 loopbacks if you only have iBGP sessions between the IPv4 loopbacks and also exchange IPv6 BGP routes over those. (This does create a dependency on IPv4 for IPv6, but it saves you a lot of BGP sessions.)
If you use /64s for router links, you can use eui-64 addressing within those, which has the advantage that you don't have to keep track of which router has the ...1 and which router has the ...2 address. If you use a lot of vlans in your own network (as opposed to customer links) you may also want to endcode the vlan id in bits 48 - 63. Makes everything really simple to debug!
I generally like to use a /48 per customer and a separate /64 out of a dedicated /48 for the link to the customer to avoid breaking up their /48 or having to do other hard to remember tricks.
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.
Hm, I would keep the first /48 apart for your own services. Addresses
in that first /64 are nice and short.
agree. i would keep the first "several" /48s though, in case
your network grows.
what we do is we don't use anything greater than a /64.
(excluding loopbacks)
main reason is because it becomes too much of a hassle
to keep track of any prefixs greater than that.
the first few /48 blocks are reserved for own services and networks
and data centers. within these /48s we divide them into /56s
and define what they mean
example:
2001:db8:a::/48 data center "a"
2001:db8:a::/56 routers, ptp links etc
2001:db8:a:0100::/56 ntp's dns's, etc.
2001:db8:a:0200::/56 hosted streaming servers
2001:db8:a:0300::/56 hosted web servers
and so on
we did this because its easier to notice problems this way.
when an alarm is detected on our NMS at 2001:db8:a:0200::/56
we know right away that there is a problem at the streaming zone.
our main business is being an ISP for consumers, so
this might differ if you mainly serve corporate customers.
If you use /64s for router links, you can use eui-64 addressing
within those, which has the advantage that you don't have to keep
track of which router has the ...1 and which router has the ...2
address. If you use a lot of vlans in your own network (as opposed to
customer links) you may also want to endcode the vlan id in bits 48 -
63. Makes everything really simple to debug!
i think this is the most important thing in
deploying IPv6 networks. make it simple to debug, and
that will make life a whole lot easier.
on this side of the puddles, i think most folk use /126s for p2p links.
this has been endlessly and loudly debated, but it still seems extremely
strange to use 18,446,744,073,709,551,616 addresses for a p2p link.
I like /124 a lot. No need to argue, I think, but you can
apply it both on small Ethernet links as well as on p-t-p
links to customers over POS - one linknet size mostly fits
it all, especially if the customer wants some 5 to 10 hosts
only and play with it. /127 on POS links is no good...
Also I cannot help but like how it can be organised with a
brain that still works on IPv4 or so. 2^4 is 16, so ::zzx0
up to ::zzxf and, yeah, the next linknet is then ::zzy0 to
::zzyf, with y being just x+1.
It just seems strange that when establishing POS links with
an all- native v6 providers they won't do it as it *has* to
be /64. I hate this whole discussion just universally by
now.
Anyway, maybe someone could use that in any way. /124 may be
nice in some aspects.
Also I cannot help but like how it can be organised with a
brain that still works on IPv4 or so. 2^4 is 16, so ::zzx0
up to ::zzxf and, yeah, the next linknet is then ::zzy0 to
::zzyf, with y being just x+1.
I second that. I get thoroughly confused every time, there's
an xxxa coming up after a xxx9. I tend to use xx10 first,
then see that it doesn't work, then remember.
Currently we're using /126s on p2p, but I believe a migration
would be in order, considering the small amount of addresses
we are using anyway.
Well, if you want to be really environmentally conscious, do away with that /126 too and just use link-locals, with a single global address per router for management and the generation of ICMPs.
Well, if you want to be really environmentally conscious, do away
with that /126 too and just use link-locals, with a single global
address per router for management and the generation of ICMPs.
jumping in late with less than I'd like of v6 experience I think the
debate goes something like: "use /64 cause autoconf works!" (and it's in
the spec as 'lan' links get /64's) and the other half is your debate of 18
million billion addrs for a ptp sonet link is craziness (and wasteful) and
/126's work fine since we never autoconf things we are going to ping
monitor.
You don't. I don't think the point of link-locals has much to do with pinging customers... But since IPv6 routing protocols work over link-locals you don't need global addresses.
If you want to ping your customers you should probably use a /126 so they can only use the specific address you give them. You need that anyway if you want to route a /48 or what have you to them.
BTW, there is discussion about rethinking /48s for customers in IPv6. Thoughts?
If you want to ping your customers you should probably use a /126 so
they can only use the specific address you give them. You need that
anyway if you want to route a /48 or what have you to them.
Having just done an IPv6 rollout, I went for a block of addresses which I
would use just for p2p links, split it into chunks for peers, customers
etc, then used a /126 for each link. Seems to work fine and (I think)
seems to be what most people are doing.
BTW, there is discussion about rethinking /48s for customers in IPv6.
Thoughts?
The current recommendation for a /48 for any customer (pretty much) does
initially seem to me to be a bit wasteful, though that's perhaps because I
keep thinking in IPv4 terms. Having said that, I think that perhaps a /48
for home users isn't _really_ necessary. How many domestic appliances can
you connect to the net
That's not really the question you want to be asking. The current
mantra is a /64 per subnet. Now, we can argue that point separately,
but taking that as a given for now (so autoconfiguration will work)
what a /48 is really telling you is that a home user gets 65536
subnets.
IPv6 allocations in the host portion (with /64 boundaries) are
sparce, even for the largest networks. The number of hosts becomes
unimportant. The question we need to ask is how many independant
subnets will they need.
This is why many people are proposing a /56 for home users, as it
gives you 256 subnets. Still more than most people will need.
Others have proposed /52 and /60, since many want to claim DNS is
easier if done in nibbles.
And the extra precision offered by the intermediate values isn't really required at this point in the discussion.
I'm very much oppossed to /56 because it's still more than most users need. In and of itself that doesn't matter, but it's also less than what some users need. This creates the situation where people try to make do with a /56, find out that they need a /48 after all (all those /64 ptps...) and have to renumber. I.e., /56 provides too much potential for shooting yourself in the foot.
I think we should go for /60 for (presumably) one-router networks. That's still 3 to 5 times as many subnets as most of those will need. Anyone else should get a /48.
I'm very much oppossed to /56 because it's still more than most users
need. In and of itself that doesn't matter, but it's also less than
what some users need. This creates the situation where people try to
make do with a /56, find out that they need a /48 after all (all
those /64 ptps...) and have to renumber. I.e., /56 provides too much
potential for shooting yourself in the foot.
ah... so is there the admission that renumbering in IPv6
is pretty much a myth?
so renumbering out of a /56 into a /48 is harder than renumbering
out of a /124 into a /112 how? renumbering - regardless of version
is hard... primarly becuase application developers insist that
the IP address is the nodes persistant identifier, not where it is
in the routing topology. renumbering hosts is a breese in either
version of predominate IP protocol, DHCP is your friend. Or if you
want less robust functionality and semantic overload, you can use
the RA/ND stuff in IPv6. - regardless, renumbering from one address
range to another is painful - CIDR -might- be helpful, but artifical
constraints e.g /64 only serve to confuse.
Where is this being discussed? What sizing is being discussed? I'm expecting in the long run some ISPs will hand out /128s in the hope that this will once and for all keep customers from putting more than one device on a connection (of course that would be followed immediately by implementations of NATv6 if it happened).
There is a draft pending in the IETF V6OPS WG (draft-ietf-v6ops-nap-01.txt) that relies heavily on the fact that everyone and his dog gets a /48 to justify the reasons IPv6 solves the world's problems that were previously solved to varying extents by NAT boxes. If the /48 thing is being discussed somewhere, that would significantly alter the underpinnings of the draft's arguments.
In a message written on Wed, Aug 10, 2005 at 01:51:41PM -0400, Daniel Senie wrote:
Where is this being discussed? What sizing is being discussed? I'm
expecting in the long run some ISPs will hand out /128s in the hope
that this will once and for all keep customers from putting more than
one device on a connection (of course that would be followed
immediately by implementations of NATv6 if it happened).
This is a topic of heated discussion at the various RIR meetings,
ARIN for most people on this list. Note the next ARIN meeting is
with a Nanog, so you might want to stick around (show up early?).
In an attempt to be objective, I'll say that there is a line in the
sand between the IETF and the RIR's, and right now both groups seem
to think the other is stepping over the line, and making the wrong
decisions. The IETF seems to think /48 is good, thinks it's extremely
unlikely we'll ever run out of space, and considers that if we do
in 50 years it's probably ok, time for a new protocol anyway. The
RIR's seem to think smaller (/56? /64? /96?) prefixes are good,
that we will run out of space under the current plan it's simply a
question of when, that deploying a new protocol in 50 years is a
bad idea if we can avoid it, and with sane policies we can.
Add in operators and their various opinions of NAT, how many addresses
a user should get, if auto configuration is good bad or ugly, if
you still need DHCP with auto configuration and soforth and you have
quite a mess with no group clearly "leading in the polls".
with less than I'd like of v6 experience 