Blog index > Archives > IPv6 in the Fast Lane
avatar

Secure the IPv6 Network Access with SEcure Neighbor Discovery (SEND, rfc3971 and CGA, rfc3972)

Tuesday, August 30th, 2011

Introduction

IPv6 Nodes on the same link use NDP (rfc4861) to discover each other’s presence and link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.  Both hosts and routers use NDP.  Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection.

If not secured, NDP is vulnerable to various attacks. SEND specifies security mechanisms for NDP.  Unlike those in the original NDP specifications, these mechanisms do not use IPsec.

Read the rest of this entry »

No Comments
avatar

People say that IPv6 is safer and faster than IPv4. The reality can be very different. Why?

Sunday, August 28th, 2011

1) IPSec

People say that IPv6 is more secure than IPv4 because IPSec is mandatory with IPv6.

First, the use of IPSec is not mandatory. The IPv6 node requirements are changing, and one of those changes is reducing IPsec from a MUST to a SHOULD, see <http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-11#section-11>.

But that still does not mean that every IPv6-capable router and IPv6-capable switch implements IPsec.  High end core routers don’t implement IPsec.  IPSec may not be found on some cheap CPEs as well.

IPSec makes sense between CPE routers interconnecting remote sites through a public network, whether this public network is providing a level 1 (i.e. SDH),  a level 2 (i.e. ATM) or a level 3 (MPLS-VPN, IPv4 or IPv6) service.

IPSec also makes sense between hosts but for lots of reasons, hosts use mostly ssh, TLS, or other non-IPsec security mechanisms.


2) Transition to IPv6: tunnels, translation, dual-stack

2.1) Tunnels

– Currently IPv6 is mostly provided thanks to transitions methods. This means that your IPv6 traffic may get through an IPv6 in IPv4 tunnel to reach its destination. This extra encapsulation process is not free regarding performances (bandwidth, delay).

– IPv6 in IPv4 Tunnels are easy targets for attacks by…
Read the rest of this entry »

No Comments
avatar

From NAT66 to IPv6-to-IPv6 Network Prefix Translation (NPTv6)

Sunday, August 28th, 2011

Following long discussions, a lot of emails exchanged and rejected drafts about NAT66, the IETF finally approved Network Prefix Translation or NPTv6 in RFC6296!

The NAT66 IETF Mail Archive can be found there:
http://www.ietf.org/mail-archive/web/nat66/current/maillist.html

NPTv6 proposes a lightweight stateless NAT solution that only translates the network prefix and not the full IPv6 address. This is a one to translation that requires no state on the routers and preserves the end-to-end reachability at the network layer.

NPTv6 (RFC6296) introduction clearly states that the IETF does not approve any Network Address Translation technology for IPv6. It provides many warning about the consequences of using Network Prefix Translation (more about the consequences of using NAT in RFC2993) and gives a reference to a document that explains all the IPv6 answers (RFC4864) to get the benefits people are looking for using NAT (RFC5902) without it!

So why was NPTv6 finally approved?

The arguments for NPTv6 are…
Read the rest of this entry »

1 Comment
avatar

Transition to IPv6 at the Service Providers: NAT64, 6RD, 4RD, DS-LITE, NAT444, dIVI-pd, A+P and Carrier Grade IPv6 (CGv6)

Friday, August 19th, 2011


Introduction: Transition technologies needed


While the Internet is still growing very fast with more connected devices every day, the available IPv4 addresses declines and will be completely depleted very soon. As IPv6 is now implemented for more than 10 years and available on most Operating Systems and Network vendors, most Service Providers and even more companies have not yet switched to the next generation Internet protocol. As a consequence we still need to buy some time to allow a smooth transition to IPv6. It is planned that we will need to support mixed IPv4 and IPv6 networks.

Clearly, maximum performances, security and other benefits we can think about running IPv6 will be achieved when transition will be over. During transition we will need to compromise features, performances and security for the benefit of supporting old IPv4 nodes and applications.

The transitions methods fall into three categories:
Read the rest of this entry »

3 Comments