Hello Liz Sir,
I am confused with Assignment of IPV6’s unique Local Address!
If we set to two PC the same IP Address in IPV4, it can’t be assigned and gives this error (This Address is already used in the network!
My question is in IPV6 that I have set the same IPv6 Address to PC, 0 And PC,1 and they have successfully ping reply, please see the output and why!
Best Regard
Ajmal
Hello Ajmal
You are able to configure two devices with the same IPv6 link local address just as you have done in your lab above. When you try to ping this address, you are actually pinging the link local address found on the local device. This ping will always be successful.
Now even though you are able to configure these hosts with the same link local address, IPv6 uses Duplicate Address Detection (DAD) to inform you if there is a duplicate address. When I did this in a lab environment and set up two Cisco routers to use the same link local address, I got the following syslog message:
*Dec 7 11:51:30.821: %IPV6_ND-6-DUPLICATE_INFO: DAD attempt detected for FE80::5054:FF:FE08:522B on GigabitEthernet0/1
So DAD does detect the duplicate address, but the configurations will still stand.
I hope this has been helpful!
Laz
Hi Lazaros,
I have a question about link-local in the lesson it says they are never used for routing and then a couple of sentences later it says they are used for routing and put in the table?
Hello Daniel
In the lesson, Rene states that “we never route these addresses”. This means that these addresses are never advertised by routing protocols. Link-local addresses can only be reached if they exist on the same subnet. If they exist on a different subnet, then they will not be routed.
Rene also states that the link-local addresses of routers are used as the next-hop IP addresses. This is different. This is the IP address of the next-hop router to get your packet to its destination.
Take a look at an IPv6 routing table like the one below.
Here you can see some routes learned via EIGRP, the ones indicated with a D. In all of these routes, you will never find a link-local address appearing right after the D. This fulfills the first statement that we never route link-local addresses. These are the actual routed addresses, the destination networks.
But you will find that all next-hop IP addresses are link-local addresses. Those are the addresses appearing after the word “via”.
I hope this has been helpful!
Laz
Thanks Lazaros that clears it up a bit
According to RFC 4193, Locally Assigned Global IDsMUST be generated with a pseudo-random algorithm.
When working with Unique Local IPv6 Address, how does the one keep track of the entire IP address within a private network (as in not connected to the internet). Especially, as one of the criteria to meet RFC 4193 requirement is obtain the current time of day in 64-bit NTP format, among other parameters.
Do the IPv6 capable devices already have a functionality to verify global ID portion (40 bit) of the IPv6 address? Any clarification would be great.
Hello Priyanka
The actual random generation of the global ID doesn’t take place on the device itself, nor is it calculated “on the fly” like it is in the case of the link-local address. When it says that the global ID must be generated with a pseudo-random algorithm, it means that you will use a tool such as that indicated at the link below, to generate the global ID or global IDs that you will be using for your particular network:
https://www.sixxs.net/tools/grh/ula/
The above site lets you register your own global ID to make sure that you’re not using one that another organization is using. This type of registration is not mandatory but is simply a way to ensure uniqueness. The global ID remains the same throughout your particular IPv6 subnets on your implementation on your network, so you define them, and manage them. ULAs are actually implemented in exactly the same way as your global unicast addresses, but you simply have to ensure that they are in the ULA range to reap the benefits of using this range. (Benefits that are few, at least for the time being.)
Now, why would all of this be necessary since the ULAs are not routed on the Internet? Who cares if you’re using the same range as another enterprise. You’re using 192.168.1.0/24 in IPv4 and so is most of the rest of the world!
Well, the idea is that if your company merges with another company, and your networks merge, you won’t have to worry about duplicate IPv6 addresses. Or, if your company network becomes part of a larger interconnected private network with your partners, suppliers, and customers, you’ll be sure that all your addresses are unique.
The following is an example from Cisco of how you can implement a ULA on your network, which may enlighten you further.
https://www.ciscopress.com/articles/article.asp?p=2154678&seqNum=2
I hope this has been helpful!
Laz
Hello @lagapidis
I have a questiong regarding Anycast :
The company i work for (an ISP), (CIO)implemented DNS Server using IPv6 Anycast and they required that CTO implement BGP load-balancing in Aggregation Nodes and Core Nodes (basically is tell BGP AFI ipv6 between PE ↔ Route-Reflectors to use load-balancing).
But im curious about some details :
For example if a DNS request is made by an user, it only reaches one of this multiple DNS Server configured with the same global unicast ipv6 addr (anycast) based on the statement that only the packet reaches the closest one ? And therefore DNS reply will only be made by this same DNS Server ?
Does the main purpose to migrate to IPv6 Anycast DNS Servers could be to reduce the effects of a DDoS attack ?
Hello Juan
Yes, that is correct. In an Anycast setup, when a DNS request is made by a user, it is routed to the “nearest” DNS server based on the routing protocol’s definition of distance (usually the shortest path). The response will come from this same server. This is one of the key benefits of Anycast, as it allows for load distribution and can help reduce latency.
Yes, using Anycast can indeed help mitigate the effects of a DDoS attack, in a somewhat indirect way. When a DDoS attack occurs, it is typically directed at a single IP address. In an Anycast setup, this traffic would be distributed among multiple servers depending on the source of each of the attackers, reducing the load on any single server and increasing the chances that the servers can handle the attack without going down. However, this is a kind of “brute force” method of dealing with DoS. If he DoS attack is intense enough, and distributed enough, it can still be successful against multiple servers using a single anycast address.
The main purpose of anycast is load balancing and reducing latency. Resiliance against DDoS attacks is a benefit but it is not foolproof, and should not be used as the sole defence against such attacks.
I hope this has been helpful!
Laz
Now, it makes more sense for me.
Implementing BGP Multiple Paths enables to reach the shortest. Take for example 10 DNS Servers IPv6 Anycast distributed along the country. From the perspective of an user from region “A” connected to PE"A" DNS 1 is the shortest. From the perspective of an user from region “B” conneceted to PE"B" DNS 2 could be the shortest path.
For this Route Reflectors must annouce all ipv6 paths to PE , not the best one (from the perspective of the RRs).
Thank you.
Hello Juan
If I understand correctly, you’re suggesting the use of BGP Multipath along with IPv6 Anycast to more adequately load balance users across multiple servers? Well, I don’t believe that would be quite right.
Remember, BGP Multipath is used to allow multiple paths to be installed in the BGP table, resulting in load balancing of traffic via these multiple paths. When IPv6 anycast is used, because the location of the multiple servers sharing that same IPv6 address will typically be distributed geographically, it is unlikely that multipath will install multiple paths to the IPv6 anycast addresses. However, even if it does, this is undesirable because then that would result in BGP trying to load balance a single session of traffic across two or more different servers. This would result in one server receiveing half of the session packets while the other server receivingthe other half.
However, anycast on its own will simply allow BGP to route traffic to the single closest server that shares that IPv6 address. So other than the mention of BGP multipath, your description in your post is correct. Also, whether you use an RR or not will not affect the operation of anycast.
Remember, IPv6 anycast will function regardless of the routing protocol being used. So it is not specific to BGP, but will also work with OSPF, EIGRP or other routing protocols.
I hope this has been helpful!
Laz
One thing that’s always confused me about IPv6:
Why were site-local addresses split into link-local and unique local in the first place? Wouldn’t it have just made more sense to have site-local addresses alone? Why have one version that’s only good for its own subnet and another that can traverse different subnets?
Hello CJ
This needs a bit of clarification. Site local addresses, defined as fec0::/10 were originally reserved for use with a single “site”. However, there was an insufficient definition of the term “site” and this led to confusion over the governing routing rules.
For this reason, this definition was deprecated and replaced with fc00::/7 for use as unique local addresses (ULAs), which are essentially the counterparts of IPv4 private addresses. The first bit following the prefix, if set, indicates that the address is locally assigned. This splits the address block into two equally sized halves, fc00::/8 and fd00::/8.
Currently, fc00::/8 is undefined and reserved for future use while only the fd00::/8 is currently used as ULAs.
Now the link-local range is completely independent of ULAs, and is not actually part of the range of ULAs. It is defined as fe80::/10. Link-Local addresses are not routable beyond their network segment, meaning they are not intended to be routed through the Internet, or even on other network segments within the same enterprise network. These addresses are automatically configured on all IPv6-enabled devices for local network communication, typically for automatic address configuration, neighbor discovery, or when no external routing is available.
So although both link-local and ULA ranges are used for local communication, their scopes and purposes are different, with link-local addresses being automatically configured for immediate network segment communication and ULAs being used for more extensive, yet still private, network communication across multiple sites or subnets.
I hope this has been helpful!
Laz
Hi again Laz,
Thanks for the explanation. I already knew all that from the very well put together topic on the matter and a little bit of my own reading, but I was more curious as to what the point of having LLAs and ULAs separate even was to begin with. What is the benefit of having one address type for communication within a subnet and another for network-wide communication? Why not just have it be like private IPv4 addresses where one type can be used for either? It sounds like this is what the Site-Local Addresses would have been.
Edit:
Nevermind, someone else answered my question:
No, it can’t.
If it auto-generates an address, it has no way to check if that same address is already in-use in a different subnet. In order to do that, you either need A) a dedicated prefix for that particular subnet (which is what ULAs are) or you need B) a way to, beforehand, contact all potential other subnets to check for conflicts.
And C, if you did that, the routers sitting between subnets would have no idea which address is reachable over which interface or where it actually should route packets to.
If you have five seperated networks, all using fe80:: xxxx:xxxx:xxxx:xxxx addresses, and you want to connect them using routers or using a VPN, if a router receives a packet for fe80:: 1234:1234:1234:1234, it has no idea what network that’s in and which other router it needs to forward that packet to. In order to do that, it needs ULAs so it can be like “clients starting with fd11 are behind router A and clients starting with fd12 are behind router B”.
