We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
Chris Gotstein wrote:
We are a small ISP that is in the process of setting up IPv6 on our
network. We already have the ARIN allocation and i have a couple
routers and servers running dual stack. Wondering if someone out there
would be willing to give me a few pointers on setting up my addressing
scheme?
Strange, I recall that you had to submit one when requesting address
space from ARIN. Why don't you use that one?
I've been mulling over how to do it, and i think i'm making it
more complicated than it needs to be. You can hit me offlist if you
wish to help. Thanks.
It all depends on your network and how you want to set it up, but for
the sake of internal aggregation:
* Determine the expected amount of IPv6 customers at a certain
location for the next X years, making X > 2 (though 10 is probably a
better idea, just in case, if don't want to do it again 
)
* Take that number round it up to a power of 2
* Every customer gets a /48, you know the number, which is a power of
2, thus root it, and you know how many bits you need at that site
eg expect 200 customers, round to power of 2 thus 256, which is 2^8,
thus you will need a /48 + 8 bits = /40 at that location.
You now know how much address space you need at that location for the
next X years.
Repeat that for all your locations / routing areas, basically the PoPs
or termination points of your customers; or if you are really big do
that per city/town/suburb. Keep enough space (the rounding helps there
quite a bit, especially with numbers like 50k customers
Now you have an overview of what you expect to be allocating at each and
every site. To add a little growth/future proof and to make live easy,
you could either opt at this stage to round everything off to 'nice'
numbers, eg only use /40's or /36's per PoP. Thus making everything the
same, or doing things like grouping smaller PoPs together.
Then when you have done that, take those blocks, and try to squeeze them
a bit together. You should now have arrived to the address plan that you
originally submitted to ARIN.
Fill those blocks into a nice database, roll a PHP/shell/perl/whatever
script to spit out your router configuration and presto: you are done.
Enjoy the weekend
Greets,
Jeroen
I do not know about arin but ripe changed it's policy so you only have to say "pretty please" to receive your allocation. It better that way anyway.
Thomas Mangin
I think we had to let ARIN know the time frame of deploying IPv6 and how many customers we expected to put on in the first couple years. They did not ask for an addressing scheme.
Reading over the RFC's and other IPv6 resources, we have decided to hand out /56's to small/home/SOHO customers and /48's to larger customers.
I'm just not able to wrap my brain around the subnetting that needs to be done on the router. Like i said before, i think i'm just over complicating it in my mind.
Chris Gotstein
Sr Network Engineer
UP Logon/Computer Connection UP
500 N Stephenson Ave
Iron Mountain, MI 49801
Phone: 906-774-4847
Fax: 906-774-0335
chris@uplogon.com
Thomas Mangin wrote:
One of the things which has struck me as being fairly insane about current recommended 'best practices' for IPv6 addressing is the practice of wasting huge blocks of addresses on p2p links; even given the gigantic address space, in a world in which every soda-can, every window-blind, and swarms of medical nanobots injected into one's bloodstream will potentially become spimes, this just seems grossly short-sighted.
The other, more immediately worrisome aspect of this practice is that it seems that we're essentially turning routers into sinkholes by doing this, with all the negative consequences this implies.
Comments/clue greatly appreciated on this and related aspects . . .
Chris Gotstein wrote:
I think we had to let ARIN know the time frame of deploying IPv6 and how
many customers we expected to put on in the first couple years. They
did not ask for an addressing scheme.Reading over the RFC's and other IPv6 resources, we have decided to hand
out /56's to small/home/SOHO customers and /48's to larger customers.I'm just not able to wrap my brain around the subnetting that needs to
be done on the router. Like i said before, i think i'm just over
complicating it in my mind.
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?)
/126 - Router p2p
/112 - Router LAN shared segments (p2mp)
/64 - Single customer LAN segments (customers asking for basic IPv6)
/56 - Customer wants multiple LANs, doesn't want to fill out
justification form
/48 - Customer wants multiple LANs, thinks /56 is too small (for some
reason), needs for routing, wants rDNS delegation etc.etc.etc..
This question gets asked so many times now, whilst people argue about
the implications of using networks smaller than /64 for anything
such deployments continue to exist and are successful.
Perhaps we should document people's addressing plans somewhere, I
see ratemyaddressingplan.com hasn't been taken yet? 
Dave.
Sounds like an excellent topic for a tutorial/talk/panel at the next NANOG.
--celeste.
I'll point out that you can do rDNS delegation down to the /64 (or even the /124) level.
As to documenting, I think that the ARIN IPv6 wiki (http://getipv6.info) might be an
excellent place to add such data.
Owen
i believe this is recently trod NANOG ground. i've seen a number of
folks exploring techniques very similar to this from an addressing
plan perspective. it's simple, intuitive and if you don't like it,
well, you are free to craft your own. in either event it's a
practical discussion of some of the considerations.
http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MyZuYW5vZzQ2&nm=nanog46
/126 - Router p2p
/127, see
MATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127
at a ripe or apricot or both. both web sites are absolutely horrid at
letting one find talks (see nanog for an example of good).
randy
/126 - Router p2p
/127, see
MATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127
at a ripe or apricot or both. both web sites are absolutely horrid at
letting one find talks (see nanog for an example of good).
randy
Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where you have say 20 devices (routers, switches, etc.) and know you'll never have more than say 50-100 devices, why not go as far as using a /120?
Randy Bush wrote:
/126 - Router p2p
/127, seeMATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127
at a ripe or apricot or both. both web sites are absolutely horrid at
letting one find talks (see nanog for an example of good).randy
Here's a link to the talk --
http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf
-Larry
Jon Lewis wrote:
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?)
/126 - Router p2p
/112 - Router LAN shared segments (p2mp)Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where
you have say 20 devices (routers, switches, etc.) and know you'll never
have more than say 50-100 devices, why not go as far as using a /120?
Actually, this is where I start to move from "conserve addressing
the good old way (tm)" to "Make it look readable"
$ sipcalc 2001:dbb::/64 --v6split=112 | grep \: | head -n9
- -[ipv6 : 2001:dbb::/64] - 0
Network - 2001:0dbb:0000:0000:0000:0000:0000:0000 -
2001:0dbb:0000:0000:0000:0000:0000:ffff
Network - 2001:0dbb:0000:0000:0000:0000:0001:0000 -
2001:0dbb:0000:0000:0000:0000:0001:ffff
Network - 2001:0dbb:0000:0000:0000:0000:0002:0000 -
2001:0dbb:0000:0000:0000:0000:0002:ffff
Network - 2001:0dbb:0000:0000:0000:0000:0003:0000 -
2001:0dbb:0000:0000:0000:0000:0003:ffff
From: Roland Dobbins [mailto:rdobbins@arbor.net]
I'm just not able to wrap my brain around the subnetting that needs to
be done on the router.One of the things which has struck me as being fairly insane about current
recommended 'best practices' for IPv6 addressing is the practice of wasting
huge blocks of addresses on p2p links; even given the gigantic address
space,
in a world in which every soda-can, every window-blind, and swarms of
medical
nanobots injected into one's bloodstream will potentially become spimes,
this
just seems grossly short-sighted.
It is all a matter of perspective.
If you want to use /126s (or whatever longer-than-64bit-prefix-you-like)
that is ~OK - it certainly works! - but you may be complicating your life in
the future.
It is "your network" - build it however you wish, just be sure of the
benefits and drawbacks associated with those choices.
(Purely an off-the-top-of-my-head hypothetical: What if PtP links become
drastically less common, and you need to re-address your network from ~/126s
to /64s because of that? You are causing yourself pain, and for what gain?
To conserve a resource that is not (and according to some, will effectively
never be) in short supply?)
A great counter-point to this is that if you do use /64s (or for that matter
- anything shorter than the currently-not-recommended /127s, AFAIK), you
should apply ACLs to them to prevent ping-pong.
((FWIW - counting the number of individual address being used is a
non-starter ... ~18,000,000,000,000,000,000 addresses on each segment is
more than enough for any solution I expect in the relevant future. I am not
saying the goal of conservation is bad (e.g. - I like /56s to homes instead
of /48s), just trying to keep things in perspective.))
Pick your flavor of answer, and drink heavily. I prefer coffee ... or
Vodka.
/TJ
Hi Chris,
Suggested scheme:
Router loopback: /128
Router serial link: /126
Router/server ethernet link: /64
Dynamic IP customer: /128 from a /64 pool
Dynamic IP always-on customer: Not sure there are any well conceived
and solidly implemented answers here.
Your customer's "DSL router" isn't going to work and you shouldn't
expect a production-grade IPv6 NAT CPE any time soon. You can go DHCP
or autoconfiguration and let him chew as many /128's as he wants but
then you'll run into the broadcast traffic problem same as when you
used DHCP for IPv4. On the flip side, you can convert your always-on
folks to static IP customers with the risk of a routing explosion as
these customers move around and as you merge and split service POPs.
I'm not aware of any way of dynamically assigning an IPv6 subnet to a
customer that's as well automated as IPv4 /32 dynamic assignment to a
DSL router with an RFC1918 NATed interior, but that may just be my
ignorance since I haven't needed to research it.
Static IP customer: /60
Any static-IP customer who bothers to ask: /48
In all other respects follow whatever strategy works for you for IPv4
wrt routing areas and aggregation.
Several notes:
The RDNS delegation boundary for IPv6 is 4 bits (as opposed to IPv4's
8 bits). This makes boundaries like /48, /52, /56, /60 and /64 very
convenient. You should probably avoid customer assignments that don't
fall on one of those boundaries.
Ethernet in IPv6 is intended to work on a /64 subnet. You can make it
work on any other size but why create extra hassle for yourself for no
good reason?
I recommend /60 as the customer default where most folks suggest /56
or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use
profile and /60 is 16 subnets. How many of your customers find a
reason to use more than 3 IPv4 subnets, including their RFC1918 ones?
Relatively few.
Giving every customer enough subnets by default to meet 90% of the
typical usage profiles is not the worst idea in the world... IMHO it's
a pretty bright idea. But there's no need to be damnfool wasteful
about it.
Regards,
Bill Herrin
TJ wrote:
[..]
A great counter-point to this is that if you do use /64s (or for that matter
- anything shorter than the currently-not-recommended /127s, AFAIK), you
should apply ACLs to them to prevent ping-pong.
One should be doing uRPF at minimum on all links anyway. BCP84
If the user (or whatever you call the place where you send packets to)
has a default route back and is not properly routing those packets can
come back quite quickly.
eg, route a /48 to the user. The user only uses the first /64, and
doesn't care about the rest and doesn't route them to lo0 to avoid the
default to match, the packets will nicely ping pong back to you.
Easy solution: source address check, then the source will not be
matching and you can drop the packet, or ICMP !A them so that the user
might once figure out what goes on.
Of course if user is sending packets with their source and their
destination you will need another kind of filter, but they will only
hurt themselves with it.
Greets,
Jeroen
William Herrin wrote:
[..]
I'm not aware of any way of dynamically assigning an IPv6 subnet to a
customer that's as well automated as IPv4 /32 dynamic assignment to a
DSL router with an RFC1918 NATed interior, but that may just be my
ignorance since I haven't needed to research it.
DHCP-PD (prefix delegation)
Static IP customer: /60
ARIN defines a /56 minimum. That is the reason that ISPs get a /32.
RIPE defines a /48 at the moment.
[..]
I recommend /60 as the customer default where most folks suggest /56
or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use
profile and /60 is 16 subnets. How many of your customers find a
reason to use more than 3 IPv4 subnets, including their RFC1918 ones?
Relatively few.
Think Future. And why bother with that anyway. If you as an ISP needs
more address space just ring RIPE/ARIN/APNIC and ask for more, they will
happily give it to you.
Giving every customer enough subnets by default to meet 90% of the
typical usage profiles is not the worst idea in the world... IMHO it's
a pretty bright idea. But there's no need to be damnfool wasteful
about it.
I guess you ran the numbers on how to run out of IPv6 address space?
You can always ask the US DoD for a few /32s, they have enough of them...
Routing will become a problem before IPv6 address space will run out.
Oh, and we are only allocating from 2000::/3 at the moment, can retry on
the other 7 /8s....
Greets,
Jeroen
William Herrin wrote:
[..]I'm not aware of any way of dynamically assigning an IPv6 subnet to a
customer that's as well automated as IPv4 /32 dynamic assignment to a
DSL router with an RFC1918 NATed interior, but that may just be my
ignorance since I haven't needed to research it.DHCP-PD (prefix delegation)
Hi Jeroen,
Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof
manner sometime between now and eternity.
Static IP customer: /60
ARIN defines a /56 minimum. That is the reason that ISPs get a /32.
RIPE defines a /48 at the moment.
ARIN "defines" a /64 minimum customer assignment and suggests /56.
They go on to say that, "RIRs/NIRs are not concerned about which
address size an LIR/ISP actually assigns."
See ARIN NRPM 6.5.4.1. https://www.arin.net/policy/nrpm.html#six54
I recommend /60 as the customer default where most folks suggest /56
or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use
profile and /60 is 16 subnets. How many of your customers find a
reason to use more than 3 IPv4 subnets, including their RFC1918 ones?
Relatively few.Think Future. And why bother with that anyway. If you as an ISP needs
more address space just ring RIPE/ARIN/APNIC and ask for more, they will
happily give it to you.
The future looks a lot like the past but with more blinking lights.
Seriously, I'm pretty nuts when it comes to networking. My basement is
AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine
how *I* would use more than 16 subnets then it's a safe bet that many
years will pass before Joe random DSL customer wants to.
The world won't end, even if you assign every customer a /48. But why
be so grossly wasteful *before* anyone has demonstrated a practical
use for doing so?
I guess you ran the numbers on how to run out of IPv6 address space?
IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a
few hundred thousand allocations like that one to wipe out the IPv6
address space.
Regards,
Bill Herrin
"IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space."
Do we expect a few hundred thousand places that need 2^29 (500M, give or take(OTTOMH)) /48s? Didn't we _just_ get to seeing ~64k ASNs as a limiting factor?
/TJ