On Thu, 7 Feb 2013, Charles Sprickman wrote:
Topics I'm interested in are:
IPv6 BGP best practices/gotchas
A lot of this is still "ask 100 people and you'll get 100 different
answers".
One thing I think you'll get a consistent answer on is the importants of
coming up with a good addressing plan up front. Many people see IPv6
deployments as "green-field" build-outs, which can provide the opportunity
to correct planning mistakes (or a complete lack of planning due to
inheriting an already-built network with already-built problems) such as
not having a defined chunk of space for network infrastructure, which
makes perimeter security much easier to plan and deploy.
Security considerations (particularly WRT network gear)
1. Some network devices that handle IPv4 XYZ in hardware do not
necessarily handle the equivalent IPv6 XYZ(s) in hardware, or handle in
hardware with limitations (lower throughput, fewer routes, impact on TCAM,
etc...).
2. Vendors are still grappling with the right way to handle extension
headers, or setting limits on the number of extension headers that can or
should be accepted.
3. ICMPv6 is a much different animal than IPv4, and things like PMTUD are
much more important to the proper function of IPv6.
4. Some vendors leak link-local addresses beyind the link even though they
shouldn't, hence the term *link*-local.
5. Different vendors and different platforms from the same vendor seem to
have differing notions of how control-plane policing its equivalent should
work.
6. Multicast is much more tightly integrated into IPv6. Performance
considerations raised in point 1 apply here as well.
7. IPv6 as designed, and IPv6 in practice are sometimes two different
beasts as well ;)
8. I've taken (and am taking) a stab at what I think is a good baseline
ruleset for Cisco ASA firewalls. That line of thinking could be extended
to other vendors or other security tools such as ACLs.
http://www.cluebyfour.org/ipv6/
^^^^^^ Suggestions and feedback are always welcome
Preferred interior routing protocols
This really depends on what you're more comfortable with. It really boils
down to IS-IS or OSPFv3. In my experience, both are now stable and
well-supported in the Cisco and Juniper worlds. If you're already running
IS-IS, adding IPv6 functionality is not a big deal. If you're running
OSPFv2 today for your IPv4 IGP, there is not a major learning curve to
migrate to OSPFv3, but there are some differences in how the two
versions operate that need to be taken into account. NOTE: going with
OSPFv3 might require you to run OSPFv2 and v3 concurrently for a time, as
OSPFv3 multi-address-family support in some areas is still lacking.
An overview of where vendors (in this case, Cisco) fall short + workarounds
I'm sure the people on thie list, juniper-nsp, lists for other vendors,
and NANOG could provide very extensive and very different answers to this
question ;)
As definitive a set of guidelines as is possible at this (early?) point
regarding subnet sizes for business customers, residential customers,
PoPs
It's a slightly different question in IPv6. An individual subnet is a
/64, so that 1. takes away the notion of having to right-size subnets to
customer need like in IPv4, and 2. changes the question from subnet size
to the number of subnets you make available per customer, per POP, etc.
On that point, you will get many different answers.
I know folks like CYMRU (https://www.team-cymru.org/) have some
excellent security BCPs, but nothing IPv6 specific. Many of the
IPv6-centric information sites seem to mainly deal with end-user issues
and application-specific information. Am I missing a particularly solid
"nsp" IPv6 resource?
From what I've seen, information is still pretty fragmented.
jms
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
