Tag: tw

This article is an introduction to different default gateway solutions. Those technologies are enabling devices on IPv4 local subnets to have more than one Default gateway configured or at least some configuration that make them work half the way of ideal redundant solution. Idea behind this article is to be an introduction to a set of articles that will explain different redundancy solutions based on IPv6 technology. Some of those technologies, will be used in future and some of them already existing and suggested to be used from day one on IPv6 implementation.

Default Gateway?!

Default gateway is the next hop address of the device that leads the packets out of the local LAN segment. If there are packets destined to an IP address that is not from local subnet PC will forward those packets usually to router device that will have the information where to forward those packets in order to get them transferred towards the destination.

All methods to mitigate IPv6 security issues
Real life security intro

In the process of configuring our corporate network test segment for IPv6, there was a direct demand to pay particular attention to security. It was my role to go trough all materials I could get to learn more about IPv6 security.

It was my role to go trough all materials I could get to learn more about IPv6 security. In that process, first stop was my favourite packetpushers podcast. They published more that 200 podcast till now and one of them was about IPv6 security that I needed. In that security show from last year

They published more that 200 podcast till now and one of them was about IPv6 security that I needed. In that security show from last year Healthy Paranoia Show 4:IPv6 Security Smackdown! Mrs. Y with bunch of great hosts discussed IPv6 security. They speak about almost all stuff that exists today in securing IPv6 enabled networks. One of the guests was Mr. Eric Vyncke, Cisco Distinguished Consulting Engineer who wrote IPv6 Security book for CiscoPress. Later, I did see that this book was everything you need to learn IPv6 security.  Of course, it’s easy to get edge router to run IPv6 on

One of the guests was Mr. Eric Vyncke, Cisco Distinguished Consulting Engineer who wrote IPv6 Security book for CiscoPress. Later, I did see that this book was everything you need to learn IPv6 security.  Of course, it’s easy to get edge router to run IPv6 on

Later, I did see that this book was everything you need to learn IPv6 security.  Of course, it’s easy to get edge router to run IPv6 on Internet-facing interface, but my goal is to get IPv6 inside our LAN environment and that part is still tricky if you include all the stuff needed to be done (especially on firewall part of the story).

I searched for additional information and some examples on how to configure Cisco gear for IPv6. Specially helpful were IPv6 webinars from long followed Networking/Cisco genius Ivan Pepelnjak at his great site ipspace.net (one of my homepage tabs). Here the guest is again Eric Vyncke.

After I gathered the knowledge out of those resources, I was ready to deploy IPv6 on my test segments and make it secure. Here are just a few rows about every one of IPv6 first-hop security features that are available on Cisco equipment. Just for the info, not all the equipment has all the features. Some of them came out

Here are just a few rows about every one of IPv6 first-hop security features that are available on Cisco equipment. Just for the info, not all the equipment has all the features. Some of them came out

Just for the info, not all the equipment has all the features. Some of them came out a few months ago so older switches and routers may not have all of these implemented. Sometimes you will be limited by the license to. I need to mention that other vendor’s equipment also supports most features mentioned below. For

I need to mention that other vendor’s equipment also supports most features mentioned below. For now it seems that Cisco invested the most effort and gathered the best team of engineers to add all possible features for IPv6 first-hop security inside IOS.

Let’s go with the list:

Intro

Multipath TCP is an extension of TCP that will soon be standardized by IETF. It is a succesful attempt to resolve major TCP shortcomings emerged from the change in the way we use our devices to communicate. There’s particularly the change in the way our new devices like iPhones and laptops are talking across network. All the devices like the networks are becoming multipath. Networks redundancy and devices multiple 3G and wireless connections made that possible.

Almost all today’s web applications are using TCP to communicate. This is due to TCP virtue of reliable packet delivery and ability to adapt to variable network throughput conditions. Multipath TCP is created so that it is backwards compatible with standard TCP. In that way it’s possible for today’s applications to use Multipath TCP without any changes. They think that they are using normal TCP.

Basics

We know that TCP is single path. It means that there can be only one path between two devices that have TCP session open. That path is sealed as a communication session defined by source and destination IP address of communicating end devices. If some device wants to switch the communication from 3G to wireless as it happens on smartphones when they come in range of known WiFi connection, TCP session is disconnected and new one is created over WiFi. Using multiple paths/subsessions inside one TCP communication MPTCP will enable that new WiFi connection makes new subsession inside established MPTCP connection without braking TCP that’s already in place across 3G. Basically more different paths that are available will be represented by more subsessions inside one MPTCP connection. Device connected to 3G will expand the connection to WiFi and then will use algorithm to decide if it will use 3G and WiFi in the same time or it will stop using 3G and put all the traffic to cheaper and faster WiFi.

TCP single path property is TCP’s fundamental problem

In datacenter environment there is a tricky situation where two servers are talking to each other using TCP to communicate and that TCP session is created across random path between servers and switches in the datacenter. If there are more paths of course. If there are (and there are!) another two servers talking in the same time, it will possibly happen that this second TCP session will be established using partially the same path as the first TCP session. In that situation there will be a collision that will reduce the throughput for both sessions. There is actually no way to control this phenomenon in TCP world. As in our datacenter example the same thing works for every multipath environment so it it true for example for the Internet.

Answer is MPTCP!

Multipath TCP – MPTCP is better as TCP in that enables the use of multiple paths inside a single transport connection. It meets the goal to work well at any place where “normal” TCP would work.

For a long time I was confused about this. It was not clear to me what is the difference between setting the static route using next hop interface IP address instead of exit interface (outgoing interface) syntax. It seemed that both methods are the same and that you have basically two different ways to define static route on specific device for no particular reason.

It was not clear to me why would someone do this kind of option on networking device OS if there were no reason for doing so. In other words I was strongly convinced that there must be some difference between two configs and learning more detail about the process of routers recursive searches and Proxy ARP function did answer all my doubts.

So now is time to put it all on paper for you to see it:

You can define static route like this:

R1(config)#ip route 10.0.0.0 255.255.255.0 10.10.2.1

This means that all packets from R1 with destination address from 10.0.0.0/24 subnet will be forwarded out the interface leading to next hop device with 10.10.2.1 address on its interface.

Other way is to define the same static route like this:

R1(config)#ip route 10.0.0.0 255.255.255.0 fastEthernet 0/0

If fastEthernet 0/0 is the interface on R1 router that leads to next hop router with best path to 10.0.0.0/24

What’s the difference, which is better?

If you use next-hop address, you can conclude that your router will not have the information which interface must he use in order to route those packets out towards destination. R1 must then find an interface that is having 10.10.2.1 on other side.

Some of these things I read in books and some of them took me few days of troubleshooting and sweating to get to them so I give them for free here to save you fellow networker some time:

SLAAC

The mighty SLAAC is the preferred method of IPv6 allocation, but is it so mighty? Or it only seems to be mighty and magic? Your computers or mobile phones in order to use SLAAC must be convinced to do so by the router RA message. That message includes the A flag set beside the prefix and all other info. That kind of RA message will tell the device receiving the RA that he needs to make the “A” autoconfiguration on his interface using EUI-64 method.

But that’s not all.

RA messages will need to have also the O flag set. With the O flag end hosts will tell the router that they will use DHCP but only for the “O” other options. In the first place that other option will be DNS server IPv6 address which is not possible to get from router RA messages. Why? I’m sure that’s the most frequent IPv6 question. The fellows who made the RFC 4861 documents didn’t put that option inside RA Router Advertisement Message Format.

I did try to find a reason why not. Maybe the only partially reasonable answer is that DNS is a hierarchical system that needs to be centralised inside a network architecture and routers as devices that are running routing processes are distributed system (at least before we see SDN in real life). So the answer will be that is not okay to put allocation of DNS address rule on a system that is not centralised. It means that if you need to change DNS in a network with a lot of routers that are sending RA messages on their local subnets you would need to change the config on all routers one by one. That is the best answer that I did find until now, but this sounds more like an excuse that a real reason for this decision. If you put all the info together with the answer that fellows from RFC 4861 did actually make the wrong decision is in existence of fairly new RFC 6106 that proposes addition od DNS IPv6 address allocation in RA message.