Does anyone have suggestions on good books to really get
a thorough understanding of v6, subnetting, security practices,
etc. Or a few books. Just turned up dual stack with our
peers and a test network but I'd like to be a lot more
comfortable with it before looking at our customer network.
Thanks,
David
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
I believe that Silvia Hagan's book [1] is still the primary reference
available, but there are others reviewed here:
http://getipv6.info/index.php/Book_Reviews.
Cheers,
~Chris
PS - Shameless plug: If you're running Juniper, I wrote two books for
them that you can get for free [2][3]. And I have an intro to IPv6
done in four parts on my blog as well (read from the bottom up) [4].
[1] - http://shop.oreilly.com/product/9780596100582.do
[2] - http://chrisgrundemann.com/index.php/2010/day-exploring-ipv6/
[3] - http://chrisgrundemann.com/index.php/2011/day-advanced-ipv6-configuration/
[4] - http://chrisgrundemann.com/index.php/category/ipv6/introducing-ipv6/
Op 5-6-2012 16:29, David Hubbard schreef:
Does anyone have suggestions on good books to really get
a thorough understanding of v6, subnetting, security practices,
etc. Or a few books. Just turned up dual stack with our
peers and a test network but I'd like to be a lot more
comfortable with it before looking at our customer network.
I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it.
Cheers,
Seth
Network Warrior. Sounds a bit silly since it's a bit of an overview
of lots of different things, however it's chapters on IPV6 get right
to the point and helped clear up a lot of things for me.
-B
http://long.ccaba.upc.es/long/070Related_Activities/020Documents/IPv6_An_Internet_Revolution.pdf
worth going through certification................
Shameless plug:
Certification wise, the IPv6 Sage certification at Hurricane Electric (http://www.tunnelbroker.net) uses a practical step-by-step approach where you actually have to deploy IPv6 and make it work to progress through the steps.
Owen
And you get a t-shirt at the end! That was enough motivation for me, anyway 
Hi David,
Instead of going the book route, I'd suggest getting some tunneled
addresses from he.net and then working through
http://ipv6.he.net/certification/ .
They have the basics pretty well covered, it's interactive and it's free.
Some additional thoughts:
1. Anybody who tells you that there are security best practices for
IPv6 is full of it. It simply hasn't seen enough use in the
environment to which we're now deploying it and rudimentary
technologies widely used in IPv4 (e.g. NAT/PAT to private address
space) haven't yet made their transition.
2. Subnetting in v6 in a nutshell:
a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC)
only works for /64.
b. Delegations on 4-bit boundaries for reverse-DNS convenience.
c. If it's a point to point, a reasonable practice seems to be a /64
per network area and around /124 per link. Works OK for ethernet point
to points too.
d. Default customer assignments should be /56 or /48 depending on who
you ask. /48 was the IETF's original plan. Few of your customers
appear to use tens of LANS, let alone thousands. Maybe that will
change but the motivations driving such a thing seem a bit pie in the
sky. /56 let's the customer implement more than one LAN (e.g. wired
and wireless) but burns through your address space much more slowly.
/60 would do that too but nobody seems to be using it. /64 allows only
one LAN, so avoid it.
e. "sparse allocation" if you feel like it. The jury is still out on
whether this is a good idea. Basically, instead of assigning address
blocks linearly, you divide your largest free space in half and stick
the new assignment right in the middle. Good news: if the assignment
later needs to grow your can probably just change the subnet mask,
keeping the number of entries in the routing table the same. Bad news:
fragments the heck out of your address space so when you actually need
a large address block for something, you don't have it.
Trying to keep non-dynamic assignments in local or regional aggregable
blocks works about as well as it did in IPv4, which is to say poorly.
Regards,
Bill Herrin
Does anyone have suggestions on good books to really get
a thorough understanding of v6, subnetting, security practices,
etc. Or a few books. Just turned up dual stack with our
peers and a test network but I'd like to be a lot more
comfortable with it before looking at our customer network.Hi David,
Instead of going the book route, I'd suggest getting some tunneled
addresses from he.net and then working through
IPv6 Certification .They have the basics pretty well covered, it's interactive and it's free.
Some additional thoughts:
1. Anybody who tells you that there are security best practices for
IPv6 is full of it. It simply hasn't seen enough use in the
environment to which we're now deploying it and rudimentary
technologies widely used in IPv4 (e.g. NAT/PAT to private address
space) haven't yet made their transition.
Not quite.
I will say that the security BCPs are not mature and are evolving,
but that does not mean that they do not yet exist.
2. Subnetting in v6 in a nutshell:
a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC)
only works for /64.b. Delegations on 4-bit boundaries for reverse-DNS convenience.
c. If it's a point to point, a reasonable practice seems to be a /64
per network area and around /124 per link. Works OK for ethernet point
to points too.
/64 is perfectly reasonable per point to point as well.
d. Default customer assignments should be /56 or /48 depending on who
you ask. /48 was the IETF's original plan. Few of your customers
appear to use tens of LANS, let alone thousands. Maybe that will
change but the motivations driving such a thing seem a bit pie in the
sky. /56 let's the customer implement more than one LAN (e.g. wired
and wireless) but burns through your address space much more slowly.
/60 would do that too but nobody seems to be using it. /64 allows only
one LAN, so avoid it.
Planning your IPv6 deployment based on today's network needs is
folly. Deploying /48s will help future-proof your network and pave the way
for some very interesting innovations in the home networking space.
e. "sparse allocation" if you feel like it. The jury is still out on
whether this is a good idea. Basically, instead of assigning address
blocks linearly, you divide your largest free space in half and stick
the new assignment right in the middle. Good news: if the assignment
later needs to grow your can probably just change the subnet mask,
keeping the number of entries in the routing table the same. Bad news:
fragments the heck out of your address space so when you actually need
a large address block for something, you don't have it.
Since you should be doing this mostly at the 4-12 bits to the right of your
base allocation and the policy is structured such that you should, in most
cases, be able to assign same-sized chunks everywhere at this level,
that really shouldn't be an issue.
Lower in the hierarchy, it's a judgement call on which optimization fits
better on a case-by-case basis.
Generally, the higher up the hierarchy, the more likely that allocation by
bisection (there are other forms of sparse allocation as well) is ideal.
In some cases, sparse allocation by reservation, for example, can reduce
fragmentation while still providing substantial room for likely growth.
Trying to keep non-dynamic assignments in local or regional aggregable
blocks works about as well as it did in IPv4, which is to say poorly.
If you apply for a large enough IPv6 block, this should be less of an issue.
That was hard to do under previous policy regimes, but the current ISP
allocation policy should make it pretty easy to optimize for this.
Certainly, if you have suggestions for how policy can better support
this, I am open to improvements at any time.
Owen
FWIW - There is a published BCOP on IPv6 subnetting:
http://www.ipbcop.org/ratified-bcops/bcop-ipv6-subnetting/
Cheers,
~Chris
Hi Owen,
Sure, but with the neighbor discovery cache issues that come up with
/64's under attack, why open yourself to trouble where you can't
realize any benefit?
Regards,
Bill
Unfortunately, this BCOP recommends /56s for residential which is
potentially harmful.
I'm also not a fan of the /126 or /127 on point-to-points, but, the theoretical
issues of neighbor table exhaustion attacks, etc. certainly should not
be ignored entirely.
Owen
Why permit external traffic aimed at your point to point links at all?
No external traffic, no attack surface.
Owen
It makes little sense to me to permit people outside your network
to deliver packets to your point to point interfaces. Denying this
traffic at your borders/edges eliminates all of the attacks without
having to juggle inconsistent prefix sizes or do silly bit-math to
figure out which address is at the other end of the link.
Owen
Sure, but with the neighbor discovery cache issues that come up with
/64's under attack, why open yourself to trouble where you can't
realize any benefit?
I happen to be a fan of /126s, but if you chose to use a /64, presumably
your infrastructure ACLs would provide protection against such attacks.
2. Subnetting in v6 in a nutshell:
FWIW - There is a published BCOP on IPv6 subnetting:
Blog – news from data centres and IT | MasterDCUnfortunately, this BCOP recommends /56s for residential which is
potentially harmful.
While it does use /56 as an example (mainly because most of the
operators I have spoken to say that is as big as they'll go and many
are shooting for less) but it does NOT make that a recommendation,
from the BCOP:
"This is an example for demonstrative purposes only. Individual
operators will need to determine their own prefix size preference for
serving customers (internal or external). The SMEs of this BCOP highly
recommend a /48 for any site that requires more than one subnet and
that a site be defined as an individual customer in residential
networks."
I'm also not a fan of the /126 or /127 on point-to-points, but, the theoretical
issues of neighbor table exhaustion attacks, etc. certainly should not
be ignored entirely.
Agreed, they must be considered.
Cheers,
~Chris
Apologies for the double post... Mistakenly hit send instead of cancel on the first one.
Owen
Op 5-6-2012 23:23, William Herrin schreef:
Hi David,
Instead of going the book route, I'd suggest getting some tunneled
addresses from he.net and then working through
IPv6 Certification .They have the basics pretty well covered, it's interactive and it's free.
+1 it's one of the best ways to learn. Do.
Some additional thoughts:
1. Anybody who tells you that there are security best practices for
IPv6 is full of it. It simply hasn't seen enough use in the
environment to which we're now deploying it and rudimentary
technologies widely used in IPv4 (e.g. NAT/PAT to private address
space) haven't yet made their transition.
Well, not quite, but firewall rules work just the same as before. Use those.
The longer version is that some people used from internet to any rules on their wan which in a IPv4 NAT really translated to allow everything to my external address. Unless you used 1:1 ofcourse, but I digress.
In IPv6 such a rule really means anything internal. People that have administered firewalls that route public addresses will know exactly what I mean.
d. Default customer assignments should be /56 or /48 depending on who
you ask. /48 was the IETF's original plan. Few of your customers
appear to use tens of LANS, let alone thousands. Maybe that will
change but the motivations driving such a thing seem a bit pie in the
sky. /56 let's the customer implement more than one LAN (e.g. wired
and wireless) but burns through your address space much more slowly.
/60 would do that too but nobody seems to be using it. /64 allows only
one LAN, so avoid it.
You seem to miss a semi important thing here. Daisy chaining of routers in the premises.
Some routers (pfSense included) allow for setting up prefix delegation, this means that you can connect routers behind the one you have and still have native v6.
Although the automatic setup system I wrote for this works with /56 networks it will only setup PD for /64 networks at this point. I allocate a part of the assigned /56 network for prefix delegation automatically.
If the PD is /48 I can delegate /56 networks to the subrouters, which on their turn can delegate /64 networks to another sub router.
It's not that the user itself will actually assign all those networks, but routers will do automatically and you need proper route aggregation. It's unlikely that all networks will be directly assinged as /64 networks either, it could also be multiple routers.
Even if it was done manually I'd assign a /60 route out of a /56 PD. The notion that it will always be a /64 is... well.
Regards,
Seth
One more (free) book:
http://www.ipv6tf.org/index.php?page=news/newsroom&id=8281
(available in several languages)