Introduction to IPv6

Hi Rene,

In the documentation is written “Every IPV6 interface contains at least one loopback address”.
Could you please explain the meaning of this sentence?
Maybe with an example…

Thanks for your support !

Hi Jose,

I’ve heard this one before but it doesn’t make much sense to me. This is from RFC 4291:

2.5.3.  The Loopback Address

   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
   It may be used by a node to send an IPv6 packet to itself.  It must
   not be assigned to any physical interface.  It is treated as having
   Link-Local scope, and may be thought of as the Link-Local unicast
   address of a virtual interface (typically called the "loopback
   interface") to an imaginary link that goes nowhere.

   The loopback address must not be used as the source address in IPv6
   packets that are sent outside of a single node.  An IPv6 packet with
   a destination address of loopback must never be sent outside of a
   single node and must never be forwarded by an IPv6 router.  A packet
   received on an interface with a destination address of loopback must
   be dropped.

The only IPv6 addresses assigned on an interface are the global unicast and link-local address:

R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ipv6 address 2001:DB8::1/64
R1#show ipv6 interface GigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::F816:3EFF:FED4:B332 
  No Virtual link-local address(es):
  Global unicast address(es):
    2001:DB8::1, subnet is 2001:DB8::/64 
  Joined group address(es):
    FF02::1
    FF02::1:FF00:1
    FF02::1:FFD4:B332

So i’m not sure where it came from…

Rene

Hi Rene,

If no NAT/PAT for IPV6. So we just to static route to outside interface. Is it correct ?

Best Regards,
Chhayheng

Hi Chhayheng,

That’s right. On all your internal devices you can use public IPv6 addresses so there is no need for NAT anymore.

Rene

Rene, just to be clear, they aren’t the same right?
2001:41f0:4060:10::/64 and 2001:41f0:4060:A::/64 ?

Hello Prateek,

That’s right. If you want to see it for yourself, try a conversion from hexadecimal to binary for “10” and “A”.

Rene

Hi Rene,

Can you please brief the below line …

IPsec: IPv6 has native support for IPsec, you don’t have to use it but it’s built-in the protocol.

BR//ZAMAN

Hello Mohammad

In order to allow IPv4 to function with IPSec, you need to add the functionality by using additional headers and encapsulation. From the lesson on IPSec for IPV4, you can see this clearly in the following diagram:

But IPv6 has the IPSec features integrated into its own structure. Before we talk about IPSec, let’s talk a little more generally about the IPv6 header structure.

IPv6 uses two types of headers. The main header, which is equivalent to that of IPv4, as well as extension headers. Zero or more extension headers are appended to the main header depending on what additional features the IP communication requires. The following diagram illustrates this concept:
image
The various types of extension headers can be seen in detail at this Cisco documentation. Two of these extension headers are involved in implementing IPSec for IPv6. Specifically the Authentication header and the Encapsulating Security Payload header. You can find out more about how to configure these at this Cisco documentation.

To answer your specific question, the features of IPSec are incorporated into the IPv6 header itself, as extension headers, and are not added by additional headers and mechanisms as in IPv4. For this reason, it is said that IPv6 has native support of IPSec mechanisms. It is built into the protocol itself.

I hope this has been helpful! Stay healthy and safe!

Laz

Hi, can i get explanation for “Address Renumbering” and “Mobility” more in detail, what it exactly means and how it works using some example.

Hello Mohammad

In order to understand these two concepts, let’s take a look at the limitations involved with IPv4.

When you have a large enterprise network, you have a lot of IPv4 addresses to manage. What happens if you need to change your whole IPv4 address ranges? You will have to either go into each host and change it, if static addressing is used, or go into your DHCP server and change the assignments. This however does cause problems with routing and with any applications that use these particular addresses.

With IPv6 it is easy to renumber the whole enterprise’s addressing scheme (assuming you are using stateless autoconfiguration, which is best practice for IPv6), simply by changing the prefix you’re using. This can be done on the routers serving the particular subnets, and all hosts will immediately follow suit. There is no need for additional changes to routing or to other applications using particular IP addresses since all these will be changed simultaneously.

Concerning mobility, when you use IPv4 networks, if you were to change between one WiFi network to another, or between one mobile telephony data network to another, your device will renegotiate connection and will be assigned a new IPv4 address. This can be disruptive especially for services such as VoIP or video telephony. This may also require a re-logging into particular services when network elements such as the IP address change. IPv6 allows a mobile device, as it moves from wireless network to wireless network, to retain its original IPv6 address, eliminating the need for renegotiation or re-logging in.

If you do a search, using your favourite search engine, for “IPv6 mobility” or “IPv6 renumbering” you will find additional useful information on these features of IPv6.

I hope this has been helpful!

Laz

Hello,

First time using the networklessons forum so sorry in advance if i’m not posting on the right place;

IPv6 uses multicast instead of broadcast ; For example in ipv4 the arp request are sent in L2 destination all FF’s whereas the ndp process uses L2 multicast “3333+8 last hex digits of sollicited node address” and L3 destination “solicited node address” multicast

The aim is that the hosts that are not concerned by specific frame/packet don’t have to process it and thus waste cpu cycles; so my questions are the followings

1 - On which layer the discarding of a multicast frame/packet occurs for a host ? I’ve been told that discarding happens either on hardware level or layer 2 (depending on the driver of the nic) so that it doesn’t have to decapsulate until layer3 ; do you confirm this fact ?

2 - Thus, if true, how does the host do to determine if it has subscribed to the multicast group based on the layer 2 multicast address ? i mean i can see the subscribed groups on a host via “netsh interface ip show joins” but is there a such mapping table for layer-2 multicast groups it joined ?
Or does the host “reverse” calculate the layer2 multicast destination address to the corresponding layer3 multicast address and then compares it to the layer3 multicast groups it joined and then decides if it discards or process the frame ?

Thank you very much in advance

Pierre

Hello Pierre

No worries, you posted your question in the right place!!

The interesting thing about the use of multicast instead of broadcast for IPv6 networks is the fact that by using multicast, you will never have multicast packets arriving at IPv6 hosts for which those packets are not intended. In other words, multicast ensures that any packets that arrive at the NIC of an IPv6 host are indeed intended for that host. Therefore there is never any need to drop any packets.

If we take a look at IPv6’s process of finding layer 2 addresses (ARP’s counterpart in IPv6) which is contained within the operations of the Neighbor Discovery Protocol, every IPv6 host will compute a solicited-node multicast address, and will then join this multicast group address and listens to it.

Now, when another host wants to learn the Layer 2 address of this host, it will send the neighbor solicitation to the remote host’s solicited-node multicast address, the one that was computed before. How does it know it? It can calculate it since it knows the IPv6 address it wants to reach and it also knows the multicast group address that was used to create it.

The result is that only the specific host will receive the neighbor solicitation! The key here is that the multicast group created has only one host that has joined the group, so only that host receives the solicitation.

You can find out more about this process in detail at the following lesson:

I hope this has been helpful!

Laz

Hello Lazaros,

Thanks for your answer ; If i may ask another precision regarding this process :

To be clear i’ll show an example :

Imagine a very little network with 4 PCs and a layer2 switch
All swith’s ports are in vlan 1 and no other configuration has been added;

PC2 's ipv6 adress is 2001:1:1::2/64 ; so it automatically generates a solicited node address of FF02::1:FF00:2 ; also it automatically joins that multicast group in order to listen on it;

Now with PC1 (configured with adress 2001:1:1:1::1/64) trying to ping PC2 (2001:1:1:1::2/64) ; PC1 generates NDP/NS message;
The ethernet header holding that NDP/NS message has got Layer 2 ethernet source address = PC1 MAc address ; and; layer2 ethernet destination address = 3333.FF00.0002 (directly derived from PC2’s solicited node address);
The fact i wanna point is that when that NDP/NS message hits the switch; the switch treats it like any ipv4 broadcast by flooding it out all interfaces (except incoming one); Thus this ND message hits all the other PC’s …

I can add only one image since i’m new user on forum so i’ll add this one to illustrate what i’m trying to point out :

And my original question was about what happens next ; does the other PC’s (pc3/pc4) discard that frame because the destination mac address of 3333.FF00.0002 doesn’t concern them (so a discarding based on multicast mac) or do they decapsulate it and discard them because of the destination ipv6 destination address being FF02::1FF00:2; (which doesn’t concern them) ?

Thanks again Sir

Hello Pierre

Yes, you are absolutely right and thank you for your thoroughness. Ideally, you would have a switch that is IPv6-multicast aware using the Multicast Listener Discovery Protocol which is used to ensure that IPv6 multicasts will only go to the intended destination.

In a scenario just like you describe, you would have a switch with no such configuration, so yes, all hosts on the network will receive those packets. Actually, I went in and labbed it up and checked to see if any multicast MAC addresses appear within the mac address table (either as static, dynamic or multicast), just to ensure that the ND protocol doesn’t change this behaviour, and this is indeed the case.

This means that these multicast frames do reach all hosts on the network. Now the question is, are IPv6 hosts smart enough to detect a multicast MAC and know that they don’t belong to that and drop it before the decapsulate to the Network layer? Well, I don’t know for sure to answer that question, but my hunch would be that it would have to go to the Network layer. That is, the decapsulation would take place up to layer 3 where the multicast IPv6 address is read, and then discarded.

This is because when creating an IPv6 Multicast address of type 3333.XXXX.XXXX, there isn’t a one to one relationship between the multicast MAC and the multicast IPv6 so there is a possibility of duplication. To avoid this, decapsulation should take place to the Network Layer.

I hope this has been helpful!

Laz

Thank you very much Sir,

That’s just that in such case (no implementation of Multicast Listener Discovery for ipv6), i have doubt regarding the real benefit of ipv6 multicast on ipv4 broadcasts;
I trully understand its benefit on other uses of it but here i don’t see the point;
Was just curious after reading the official certification guide that mentions (in short) the “big” benefit of ipv6 use of multicast ; So my conclusion is : Yes it’s a real benefit but not in all cases …

Thanks very much for taking time for testing it / Really appreciate

Hello Pierre

Yes, that is the case for many technologies. The idea is that if you have a fully IPv6 network infrastructure, and you have configured switches to be IPv6 multicast aware using MLD, then the benefits are immense. You can have IPv6 subnets of hundreds or even thousands of hosts without the fear of creating broadcast storms, something that is unheard of for IPv4.

This is especially useful for innovative new applications such as the Internet of Things (IoT), where you may have tens of thousands of devices connected to the same IPv6 subnet without a problem, all because of the fact that you no longer have broadcasts.

Compared to IPv4, you are able to create networks of much greater scale due to the fact that broadcasts have been replaced by multicasts. But for conventional networks, such as a small business LAN for example, there is no essential difference. So it does indeed depend on the case.

I hope this has been helpful!

Laz

Q-1:-you said that mobility device can keep their IP even they will shift to other providers also …But how that public ip can be owned by 2 service provider at the same time ??.

Q-2:- An IPv4 host can’t communicate with a IPv6 host (pingv6 2141::1 source 10.10.10.10 )…right ??.

Q-3:- Can i do nat my pvt IPv4 address users to a IPv6 public IP address ??

Q4–As you said Ipv6 support Ipsec natively, Does that mean IPv6 packets are getting encrypted including payload ??

Hello Narad

As stated in RFC 3775 that defines the IPv6 mobility feature:

Mobile IPv6 allows a mobile node to move from one link to another without changing the mobile node’s “home address”. Packets may be routed to the mobile node using this address regardless of the mobile node’s current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications.

How this is technically achieved can be further examined within the RFC document.

If you don’t configure any mechanisms to allow IPv4 to communicate with IPv6, then you are correct, there can be no direct communication between an IPv4 host and an IPv6 host. However, you can allow IPv4 and IPv6 hosts to communicate using NAT64. An example of this can be seen in this lesson:

Yes, using NAT64.

As far as what is encrypted, IPsec for IPv6 works the same as IPv4. You have both transport and tunnel mode. When configured in transport mode, only the payload is encrypted, while in tunnel mode, the entire IPv6 packet is encrypted and authenticated.

I hope this has been helpful!

Laz

How to find IPv6 Prefix Example

This is in reference to the /53 prexi example. What would have been the difference if the prefix lenth was /52. Wouldn’t that be the same result. Because I notice we put the other bit along/together with the next 4-bit block.

I think it should not be part of the host?

Hello Ibmufa

First of all, remember that network devices view, calculate, and manipulate IPv6 addresses using the binary format. The hexadecimal format is for the benefit of us humans so that we can understand and write out the addresses more easily.

This means that when you see a /53 prefix in this format: 2001:1234:abcd:5678:9877:3322:5541:aabb/53
the network device simply sees it like this:

00100000000000010001001000110100101010111100110101010110011110001001100001110111001100110010001001010101010000011010101010111011

I’ve made the first 53 bits bold to indicate that they are the 53-bit prefix. If we used a 52-bit prefix, it would look like this:

00100000000000010001001000110100101010111100110101010110011110001001100001110111001100110010001001010101010000011010101010111011

So you see, from the point of view of a network device, there are no “4-bit blocks” or 16-bit hextets, so it’s really no problem for a network device to deal with a prefix of any length.

Now having said that, it is difficult for us humans to visualize a /53 simply because of the methodology of representation used. A /53 will cause the prefix to split the IPv6 address within a single hex digit as shown in the lesson.

However, a /52 would be easier to visualize because it actually splits at a particular hex digit. Specifically:

2001:1234:abcd:5678:9877:3322:5541:aabb/52

In the above representation, the bold hex digits belong to the prefix. Remember that each hex digit represents four bits. So that’s 13 hex digits times 4 bits each: 13*4 = 52.

In general, we tend to choose prefixes that are divisible by 16, such as /48 or /64 because they split along one of the “:” indicators in the address. Or, we can choose prefixes that are divisible by 4, so that the split occurs at one of the hex digits, so values of 52, 56, and 60 would also be easily representable in the hex format. But anything not divisible by 4 is typically not used simply because it adds complexity to the hex representation of the addresses.

I hope this has been helpful!

Laz