resource

Book review – IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6

There are many IPv6 books around nowadays with many different approaches to the subject. IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6 by Rick Graziani is an excellent book that will help you fully understand the fundamentals of IPv6. It has a great balance of theory and practical information and is a good starting point for learning about IPv6. Other IPv6 books can be found on our books and e-books pages. We have included a number of Amazon reader reviews below:

[amazon template=image&asin=1587143135]
[amazon template=add to cart&asin=1587143135]

Graziani provides straightforward understanding.
By M.B. Reynolds on June 5, 2013

The title of the book is an accurate depiction of the contents of this work. The material is presented in a straightforward, methodical manner. The material is presented with understanding and teaching in mind utilizing repetition, sample code, examples, and review. The book is primarily a walk through the various Internet Engineering Task Force (IETF) Requests for Comments (RFC) that comprises the aspects, features, and options of IPv6. Most of these RFC walkthroughs are accompanied with Cisco IOS example code for setting up a router to implement the RFC.

After some of these examples, output from a packet sniffer demonstrates the changes to the packet headers. The book finishes with mechanisms for implementing mixed IPv4 and IPv6 environments and approaches to transitioning from IPv4 to IPv6. Additional references and notes point the reader to more details or topics not covered by the book. Overall I certainly recommend this book as a starting point into IPv6 if the reader has some IPv4 and routing experience. I believe for the novice an additional more general book on networking should be digested first.
The book covers the Internet history and the motivation of IPv6. The IPv6 headers and Extension headers are presented in (again) a straightforward explanation with plenty of diagrams and tables. This explanation includes the specific differences between IPv4 and IPv6 headers. A nice overview of IPSec headers includes authentication, transport, and tunneling modes. Chapter four outlines the multitude of unicast, multicast, and anycast address types. The Neighborhood Discovery Protocol is a new feature of Internet Control Message Protocol version 6 (ICMPv6). Graziani shows ICMPv6 with its enhancements is an important change in how IP hosts identify themselves and others hosts and routers on the network.

The middle of the book discusses IPv6 configuration and routing. Initially, a router is configured from scratch with the various address types. The same example configuration and network is nicely used through the middle of the book. This method is useful for continuity and context. Building on this initial configuration static routes and routing tables are built. The old and new RIPng, EIGRP, and OSPF are compared and contrasted in Chapter 8. The middle ends with Dynamic Host Configuration Protocol version 6 (DHCPv6). The new features such as stateless & stateful DHCP and relay agents are covered. Some interesting differences in Domain Name Service (DNS), TCP, and UDP are explained.

The book ends with mixed IPv4 and IPv6 environments. Graziani shows dual stack allows for parallel IPv4 and IPv6 networks. He covers tunneling methods such as 6to4 and ISATAP that allow for IPv6 packets to be encapsulated in IPv4 packets and routed through an IPv4 network. He shows this allows for a smooth transition from IPv4. Finally Network Address Translation IPv6 to IPv4 (NAT64) is walked through. He shows this allows and IPv4 address to be mapped to a IPv6 address and vice versa to allow coexisting IPv4 and IPv6 networks to communicate.

 

One of the most substantial changes from IPv4 to IPv6 is the addresses and their types. After introducing hexadecimal and the address format short hands, Graziani explains well the structure of the new 128-bit address: prefix, subnet, and interface id.

After trying others – THIS is THE BOOK!
By John Scott on March 22, 2013

The review written by Cosmic Traveler says it well. I purchased 2 other books before this one and they both ended up on the bottom shelf of my bookshelf. I ordered this one and I couldn’t put it down. If the mere thought of a 128-bit address represented in hexadecimal format makes your hair stand up, you need to order this book and then go have a glass of wine – or a cold beer.

IPv6
By Matthew Petersen on February 14, 2014

To support future business continuity, growth, and innovation, organizations must transition to IPv6, the next generation protocol for defining how computers communicate over networks. IPv6 Fundamentals provides a thorough yet easy-to-understand introduction to the new knowledge and skills network professionals and students need to deploy and manage IPv6 networks.

Excellent book, highly recommended!
By MSG causes migraines on October 15, 2013

Even though I have been a CCIE since the 1990s and have dealt with IPv6 successfully on the re-certification exams, this book added a lot of needed clarity on the context and usage of IPv6 so the concepts are more readily absorbed and made intuitive. For those network engineers not yet exposed to IPv6 due to their individual customer/employer situations, it is a near-term reality everyone is going to have to deal with as the IPv4 private addressing RFC 1918 (and the updated IPv4 content in RFC 6761) cannot eliminate the reality that IPv4 is nearing address depletion.
[amazon template=add to cart&asin=1587143135]
UNDERSTANDING IPV6!!!
By COSMIC TRAVELER on November 17, 2012

Are you a network engineer; network designer; network technician; part of the technical staff; and, networking student, including those of the Cisco Networking Academy; who are seeking a solid understanding of the fundamentals of IPv6? If you are, then this book is for you! Author Rick Graziani, has done an outstanding job of writing a book that focuses on the basics of IPv6.

Author Graziani, begins by discussing how the Internet of today requires a new network layer protocol, Ipv6, to meet the demands of its users. Then, the author examines the Ipv6 protocol and its fields. Next, he introduces IPv6 addressing and address types. The author continues by examining the different types of IPv6 addresses in detail. Then, he examines ICMPv6. The author then illustrates the configuration of IPv6, addressing the use of a common topology. Next, he examines the IPv6 routing table and changes in the configurations pertaining to IPv6. The author continues by discussing three routing protocols: RIPng, EIGRP for IPv6 and OSPFv3. Then, he examines DHCP for IPv6 or DHCPv6. The author then covers two of three strategies for IPv4 and IPv6 integration and coexistence: dual-stack and tunneling. Finally, he discusses the third technique for transition from IPv4 and IPv6: Network Address Translation or NAT.

This most excellent book provides a thorough yet easy-to-understand introduction to IPv6. More importantly, this great book is also intended to provide a foundation in IPv6 that will allow you to build on it.

Great book to begin IPv6 study
By Cord Scott on March 22, 2013

Really like this book. Information is accurate and concise and concentrates on the protocol and not just how to configure Cisco gear for IPv6, which is what too many people look for. Not a whole lot on migration but Cisco Press has another book that deals with that.

Everyone should start IPv6 with this book
By Andras Dosztal on May 13, 2013

Detailed but still easy to understand, having a good balance of theory and practical knowledge. Up to date, covers all topics needed for someone who’s getting familiar with IPv6. Having prior IPv4 and routing knowledge is recommended.

[amazon template=add to cart&asin=1587143135]

IPv6 Security Myth #9 – There Aren’t Any IPv6 Security Resources

Security in an IPv6 World

We are approaching the end of this 10 part series on the most common IPv6 security myths. Now it’s time to turn our eyes away from security risks to focus a bit more on security resources. Today’s myth is actually one of the most harmful to those who hold it. If you believe that there is no good information out there, it’s nearly impossible to find that information. So let’s get down to it and dispel our 9th myth. We’ll start by looking at a few of the high level principles and then look at a selection of resources, which contain much more detail.

Myth: There are no IPv6 Security BCPs yet
Reality: There are!

Many security standards don’t discuss IPv6 specifically. However, any general guideline related to IP likely applies to both versions – many security policies are (and should be) higher level. We saw this in Myth’s #2 and #7 to some extent and it’s also evident below, as many of these security practices apply to both IPv6 and IPv4.

Here are a few of the key principles to keep your IPv6 network secure:

  • Perform IPv6 filtering at the perimeter
  • Use RFC2827 (BCP38) and RFC3704 (BCP84) ingress filtering throughout the network
  • Use manual tunnels (with IPsec whenever possible) instead of dynamic tunnels and deny packets for transition techniques not used
  • Use common access-network security measures (NAC/802.1X, disable unused switch ports, Ethernet port security, MACSec/TrustSec)
  • Strive to achieve equivalent protections for IPv6 as with IPv4
  • Continue to let vendors know what you expect in terms of IPv6 security features

Myth: There are no IPv6 Security Resources available
Reality: There are!

The BCPs above are really just the tip of the iceberg when it comes to all the things you need to know to securely deploy IPv6. For a deeper dive on how to actually execute on these high level policies you’ll want to do some more reading. Here are a couple of the best IPv6 security resources I’m aware of. Read them and you’re well on your way to being a true IPv6 security expert!

What are your favorite IPv6 security resources? Leave a comment!

Via:: IPv6 News Aggregator

      

Middle East DNS Forum Covers DNSSEC – Let’s Fill In The Map!

Middle East DNS Forum

Over in Amman, Jordon, today our Internet Society colleague Frédéric Donck gave a keynote address at the Middle East DNS Forum where I know he was planning to speak about DNSSEC and our interest in advancing the deployment so that together we can make the Internet more secure via a more secure DNS infrastructure. (His talk was also going to cover Internet governance and infrastructure development topics.) The folks at the Middle East DNS Forum were kind enough to tweet out a photo of Frédéric in action:

In preparation for his presentation at the meeting, I provided Frédéric with a snapshot of our weekly DNSSEC Deployment Maps for the Middle East region (the colors represent the 5 stages of DNSSEC deployment):

As you can see, there’s definitely room to have more of the country-code top-level domains (ccTLDs) signed in the region. From what the database shows, I have this information:

  • Lebanon has signed .LB and the DS record is in the root of DNS.
  • Afghanistan has signed .AF and the DS record is in the root of DNS.
  • Turkey (.TR) is “Announced” because a representative of the registry contacted me with their plans ( and they publicly announced their plans at the ICANN Turkey DNS Forum in November 2014).
  • Israel is in the “Announced” state because a representative of the .IL registry contacted me with their plans.
  • Iraq (.IQ) and Iran (.IR) are in “Experimental” because activity was observed a few years back.

For Lebanon and Afghanistan, they could be in the “Operational” stage and be accepting DS records from domain registrants. We just don’t know because we have no way to find out unless either: 1) someone from the registry tells us (and I haven’t yet tried to contact these ccTLDs to know); or 2) someone who has registered a domain in those ccTLDs lets us know.

Although the agenda of the Middle East DNS Forum is mostly not about technical topics, I do hope Frédéric’s discussion will ignite some interest and we can start seeing the Middle East region joining the rest of the world in providing a way to secure the integrity of DNS information within the ccTLDs.

In fact, if you are visiting our site as a result of that Forum, please do visit our Start Here page to find out how you can begin with DNSSEC – or please contact us so that we can help you find the appropriate resources.

Let’s fill in that map and get the whole region to be green!

P.S. If anyone has more information about the DNSSEC deployment status of ccTLDs in that region, please do let me know – I’d be glad to update the maps.

Via:: IPv6 News Aggregator

      

On “Broccoli Technologies” and IPv6 in The New IP Blog

thenewip

Chris Grundemann recently had the chance to write a guest blog post over on The New IP, which bills itself as “The community for next generation network strategists.

He discusses topics ranging from IPv6 and the Internet of Things to DNSSEC, TLS, securing BGP, and anti-spoofing – naturally, all the things we love here at Deploy360.

I encourage you to read his whole eloquently stated post, but here’s a snippet:

This is why my friend, mentor and former boss Leslie Daigle called these protocols “broccoli technologies.” They’re good for you, but not everyone likes eating them.

For example: Deploying IPv6 today requires resources but there is no short-term ROI. You can’t charge current customers more for it. You’re still offering the same services, just over a newer version of IP. However, if you don’t implement IPv6, you’ll lose connectivity to a growing portion of the Internet — your future customers.

If we don’t all eat our broccoli today, we may soon see this magnificent Internet start to distort, fragment or even crumble.

What do you think? There are already several comments over on The New IP site, including recommendations for a ‘comfort food’ analogy to counteract the ‘broccoli technologies’ angle. Any ideas? I’d love to hear what you’ve got!

(Of course, as always, if you’re looking to get started, we have a page just for you. And it being Friday afternoon as I type this, you might want to check out our Weekend Projects category while you’re here.)

Via:: IPv6 News Aggregator

      

IPv6 Security Myth #8: It Supports IPv6

By Chris Grundemann

Most of our IPv6 Security Myths are general notions, often passed on unwittingly between colleagues, friends, conference attendees, and others. Today’s myth is one that most often comes specifically from your vendors or suppliers. Whether it’s a hardware manufacturer, software developer, or Internet Service Provider (ISP), this myth is all about trust, but verify.

Myth: It Supports IPv6

Reality: It Probably Doesn’t

I am not saying that no products or services support IPv6. What I am saying is that a simple check-box in an RFx isn’t enough. If a sales person tells you “it supports IPv6” without any further details or collateral — you probably need to dig deeper.

Many products and services do in fact support IPv6 today. More companies add IPv6 support to their products every day. The catch, especially from a security standpoint, is what that word “support” really means. Sometimes “IPv6 support” means that a device can be configured with an IPv6 address. Sometimes it means the service passes IPv6 packets. Sometimes it just means the application won’t puke all over itself when deployed in an IPv6 enabled environment.

What you need “IPv6 support” to mean is full feature parity with your existing (likely IPv4) products and services. You also need that IPv6 support to provide the foundation for future changes and improvements as well, of course. What that means is that you must bust this myth yourself every time it pops up.

How can you avoid falling for the “it supports IPv6” myth? Start with detailed requirements. What is it that you need this product or service to do? RIPE-554, “Requirements for IPv6 in ICT Equipment” includes a section specific to “network security equipment” that I highly recommend as a starting place when crafting such a requirements list. Once you find a product or service that meets your needs on paper, lab testing and limited launches (pilot programs / first office installs) will help ensure that you aren’t bitten by this myth. Seeking independent verification is sometimes warranted as well, for an example check out this list of tested home routers published by the University of New Hampshire (UNH) InterOperability Lab (IOL).

The bottom line for this myth is simple: Treat IPv6 like you would any other new technology being deployed on your network. Ensure that all new equipment meets your specific needs, and remember to trust but verify when it comes to IPv6 support.

Written by Chris Grundemann, Internet Technologist, Author, and Speaker. All opinions are his and his alone

Follow CircleID on Twitter

More under: IPv6, Security

Via:: IPv6 News Aggregator

      

IPv6 Security Myth #8 – It Supports IPv6

Security in an IPv6 World

Most of our IPv6 Security Myths are general notions, often passed on unwittingly between colleagues, friends, conference attendees, and others. Today’s myth is one that most often comes specifically from your vendors or suppliers. Whether it’s a hardware manufacturer, software developer, or Internet Service Provider (ISP), this myth is all about trust, but verify.

Myth: It Supports IPv6
Reality: It Probably Doesn’t

I am not saying that no products or services support IPv6. What I am saying is that a simple check-box in an RFx isn’t enough. If a sales person tells you “it supports IPv6” without any further details or collateral – you probably need to dig deeper.

Many products and services do in fact support IPv6 today. More companies add IPv6 support to their products every day. The catch, especially from a security standpoint, is what that word “support” really means. Sometimes “IPv6 support” means that a device can be configured with an IPv6 address. Sometimes it means the service passes IPv6 packets. Sometimes it just means the application won’t puke all over itself when deployed in an IPv6 enabled environment.

What you need “IPv6 support” to mean is full feature parity with your existing (likely IPv4) products and services. You also need that IPv6 support to provide the foundation for future changes and improvements as well, of course. What that means is that you must bust this myth yourself every time it pops up.

How can you avoid falling for the “it supports IPv6” myth? Start with detailed requirements. What is it that you need this product or service to do? RIPE-554, “Requirements for IPv6 in ICT Equipment” includes a section specific to “network security equipment” that I highly recommend as a starting place when crafting such a requirements list. Once you find a product or service that meets your needs on paper, lab testing and limited launches (pilot programs / first office installs) will help ensure that you aren’t bitten by this myth. Seeking independent verification is sometimes warranted as well, for an example check out this list of tested home routers published by the University of New Hampshire (UNH) InterOperability Lab (IOL).

The bottom line for this myth is simple: Treat IPv6 like you would any other new technology being deployed on your network. Ensure that all new equipment meets your specific needs, and remember to trust but verify when it comes to IPv6 support.

Have you already deployed IPv6? We’d love to hear about your experiences, publish your lessons learned, and promote your success story along with our other IPv6 resources – especially if they relate to IPv6 security directly! If not, what are you waiting for?!? Get started today.

Via:: IPv6 News Aggregator

      

IPv6 Security Myth #7: 96 More Bits, No Magic

By Chris Grundemann

This week’s myth is interesting because if we weren’t talking security it wouldn’t be a myth. Say what?

The phrase “96 more bits, no magic” is basically a way of saying that IPv6 is just like IPv4, with longer addresses. From a pure routing and switching perspective, this is quite accurate. OSPF, IS-IS, and BGP all work pretty much the same, regardless of address family. Nothing about finding best paths and forwarding packets changes all that much from IPv4 to IPv6. For many experienced network engineers, instruction in IPv6 contains a lot of things that can be described to “work just like in/with IPv4.”

This likely explains why virtually every transit provider and backbone operator on the planet has already rolled out IPv6. If all you’re concerned about is moving data, the phrase is true: IPv6 is 96 more bits, no magic.

From a security perspective however, that view has some complications.

Myth: 96 More Bits, No Magic

Reality: IPv6 Address Format is Drastically new

Routing 128 bit addresses is really not much different from routing 32 bit addresses. There’s a source address, a destination address, and hopefully a path or more between them.

Things get more complicated when we start talking about securing the network though. In addition to IPv6 addresses being 96 bits longer, they are also represented in hexadecimal notation instead of decimal. They use colons as delimiters instead of periods. They also introduce zero compression, in addition to zero suppression, expanding the possible formats that an IPv6 address may be represented in.

So what? Well, a lot of network security involves either filtering or forensics, both of which are often heavily (or completely) reliant on identifying nodes by IP address. You can no longer grep logs for decimal numbers separated by periods to find all instances of IP addresses. Now you need to look for hex characters and colons — and don’t forget to think about those double colons! Scripts, filters, and other tools written with IPv4 addresses in mind must be updated to handle IPv6 addresses.

Myth: 96 More Bits, No Magic

Reality: Multiple Addresses on Each Node

To make matters even more complicated, IPv6 nodes (hosts) are pretty much assumed to always have multiple addresses. At the very least they should all have a link-local IP address and a Global Unicast Address (GUA / public IP address), likely in addition to a legacy IPv4 address. Many nodes will also have a Unique Local Address (ULA — somewhat similar to RFC1918 address space in IPv4), one or more constantly changing privacy addresses, and other GUAs as needed.

This means that the node you are searching for may have a different IP address in the logs than the one you are looking for. It means that you may need to filter multiple addresses to have the desired affect on a single node. It means a paradigm shift in how you think about IP addresses as they relate to securing your network.

Myth: 96 More Bits, No Magic

Reality: Syntax Changes

In addition to changing how we think about IP addresses in this new IPv6 enabled world, we must also deal with syntax changes on our gear.

One of the great things about deploying a new version of IP is that we can use the opportunity to fix mistakes made in the old version. This is as true at the software and hardware level as it is at the network and security levels. The downside of this is that improvements at many equipment manufactures mean new syntax for network operators and security experts alike.

Instead of just ping, we now must remember to ping6. Our old friend tracert requires that we add -6 when executing an IPv6 traceroute. The ‘show route’ command is now supplemented by ‘show ipv6 route’ on some routers. The list goes on and on, and is different for each platform or vendor.

These changes affect everyone. As we learned in Myth #1; ignorance is no protection, and no excuse. To keep your network secure today, you must learn the new syntax of IPv6.

Myth: Configure IPv6 Filters the Same as IPv4

Reality: DHCPv6 and Neighbor Discovery Introduce Nuance

This is a more specific version of the ‘no magic’ myth and again, it’s not far from the truth. From a policy perspective you really should treat IPv6 and IPv4 security the same. For example: If a particular activity, destination, or traffic type is blocked for IPv4 it should very likely be blocked for IPv6 as well. The nuts and bolts of doing this aren’t quite the same however.

We’ve already talked about how address format, multiple addresses, and syntax changes may affect your configurations and actions. In addition to these general considerations, firewall filters have a couple of additional things to remember.

One of the biggest things to keep in mind when creating IPv6 filters is that Neighbor Discovery (ND) uses ICMP. This of course means that default ‘deny all ICMP’ rule you are likely to be using in legacy IPv4 filters can’t be copied over directly. Another consideration that may not be obvious at first is that DHCPv6 messages use link-local addresses, which you may typically want to filter out (why would link-local traffic be transiting a router?).

Here is an example stateful firewall filter for a Mikrotik router:

Flags: X — disabled, I — invalid, D — dynamic

0 ;;; Not just ping — ND runs over icmp6.

chain=input action=accept protocol=icmpv6 in-interface=ether1-gateway

1 chain=input action=accept connection-state=established in-interface=ether1-gateway

2 ;;; related means stuff like FTP-DATA

chain=input action=accept connection-state=related in-interface=ether1-gateway

3 ;;; for DHCP6 advertisement (second packet, first server response)

chain=input action=accept protocol=udp src-address=fe80::/16 dst-address=fe80::/16

in-interface=ether1-gateway dst-port=546

4 ;;; ssh to this box for management (note non standard port)

chain=input action=accept protocol=tcp dst-address=[myaddr]/128 dst-port=2222

5 chain=input action=drop in-interface=ether1-gateway

As you can see, rule 0 is in place to allow ND to work and rule 3 allows the node to hear its own DHCPv6 reply. This is just an example but hopefully it illustrates the point: There are subtle differences between IPv4 and IPv6 that must be considered when securing modern networks.

Written by Chris Grundemann, Internet Technologist, Author, and Speaker. All opinions are his and his alone

Follow CircleID on Twitter

More under: IPv6, Security

Via:: IPv6 News Aggregator

      

Main IETF Website Returns To Being DNSSEC Signed Via CloudFlare

IETF web site

Good news this week for DNSSEC and content-distribution-networks (CDNs)! Last year the Internet Engineering Task Force (IETF) decided to move the main IETF web site over to a CDN to speed up access to IETF web pages for people trying to reach them all over the world. While this sped up access to the IETF’s content, it unfortunately meant that the main IETF website had to lose its DNSSEC signature because the CDN vendor, CloudFlare, did not yet support DNSSEC. (I’d note that this was only the main IETF web site – other IETF web sites such as the datatracker and tools sites continued to be DNSSEC-signed.)

Those of us advocating for DNSSEC were naturally disappointed by this move last year, but we understood the need and also understood that CloudFlare was committed to bringing DNSSEC to their customers – and indeed we’ve been writing about CloudFlare’s journey towards DNSSEC.

So this week we were very pleased to see this announcement by IETF Chair Jari Arkko:

Some time ago we moved the static parts of the IETF web page to a CDN service. While this provided a significant improvements for page load times and retained our ability to serve the pages over IPv6, we were unable to provide DNSSEC for the web pages that were being served by the CDN.

Our CDN vendor, Cloudfare, however, has worked in the background to enable DNSSEC for their customers. They have now come back with a system that we have enabled for the IETF web pages. (Thank you Cloudfare, this was important!)

We plan to keep the new arrangement on at http://dnssec.ietf.org for a while before finally moving to this arrangement on http://www.ietf.org. Testing the new arrangement on dnssec.ietf.org would be appreciated!

Jari Arkko, IETF Chair

As noted, the main IETF website is NOT yet DNSSEC-signed at the regular “www.ietf.org” but is instead available with a DNSSEC signature at http://dnssec.ietf.org while everything is tested out.

Regardless, this is great news for DNSSEC, for the IETF … and also as a demonstration that CloudFlare’s implementation is obviously getting that much closer to being available!

Please do check out http://dnssec.ietf.org and give it any kind of DNSSEC-related tests that you can!

And if you haven’t gotten started with DNSSEC yet, please visit our Start Here page to find out how you can begin!

Via:: IPv6 News Aggregator

      

IPv6 Troubleshooting for Helpdesks Now Published as RIPE-631

RIPE NCC

After a year of hard work by IPv6 experts from all over the world, I’m proud to announce that a new deployment-oriented document called IPv6 Troubleshooting for Residential ISP helpdesks is now an officially published RIPE document. It’s intended to provide a starting point for technical support staff at ISPs or enterprise IT help desks in supporting IPv6. Problems with IPv6 are very rare, but fear of the unknown has prevented or delayed many organizations from rolling out IPv6 to their users, even when all technical problems have been solved. While this document cannot encompass all possible problems, it should provide a solid first step for front-line support personnel.

This BCOP (Best Current Operational Practice) document was drafted by a great group of experts, and I would like to thank all of them: Lee Howard, John Jason Brzozowski, David Freedman, Jason Fesler, Tim Chown, Sander Steffann, Chris Grundemann, Jen Linkova, Chris Tuska, Daniel Breuer. Thank you for all the effort that you put in this document.

The document was submitted to the RIPE BCOP Task Force and then to the RIPE IPv6 Working Group, and went through a consensus building process. Finally, we reached consensus in both groups and published the document as RIPE-631 this month. We would like to thank the Internet community for all the feedback and suggestions that made this document much better and to RIPE-NCC staff that facilitated the publishing process!

Now that it’s a RIPE BCOP document, it is stable and will not change for some time. So to all operators out there – when you are deploying IPv6 to your residential customers, use it!

And, as always, if you want to get started with IPv6, please visit our Start Here page to find resources tailored to your role or type of organization!

Via:: IPv6 News Aggregator

      

Today: Interop Radio – The Real Scoop on IPv6

Interop Radio

Today seems to be the day for people to do webinars/podcasts on the topics we care about… in about 35 minutes at 3:00pm US Eastern, an episode of “Interop Radio” will focus on IPv6!

Hosted on BlogTalkRadio, this is the kind of show that anyone can call in to using the phone number listed on the episode page. From that page, the abstract is:

Everyone knows we’ve run out of network addresses. That’s old news. So why don’t we hear about the solutions any more? Is it a thoroughly solved problem or have we all just decided to ignore it until the problem goes away (or the Internet falls over and dies)?

In this episode of Interop Radio we’ll give you the answers and help you understand what those answers mean for your network. To do that we have an expert on board to talk about the technologies and practices that will make a difference for you and your organization.

Brandon Ross, Chief Network Architect and CEO at Network Utility Force, is a network architect and entrepreneur with years of experience building, operating and managing large scale service provider networks. He’s interested in helping telecommunications companies with the best network engineering team and network in the industry via scalable and stable architectures.

The episode records live in about 35 minutes – and then presumably will be available for later listening if you aren’t able to hear it live.

It’s great to see this kind of discussion happening out there – and with very real IPv6 deployment happening around the world, the time is NOW for you to be understanding how your networks and content can be available over IPv6!

We look forward to hearing this show and for seeing even more IPv6 deployment happen! If you want to get started with IPv6, please visit our Start Here page to find resources tailored to your role or type of organization!

Via:: IPv6 News Aggregator