Solved: ipv6 address and link-local address

sarahr202 · ‎08-25-2010

Hi every body.

I have few questions.

1) one of the feature of ipv6 is auto-configuration. With auto-configuration, a ipv6-device can configure itself with IP address without relying on dhcp server.But what about other parameters for e.g dns? So with ipv6 the need for dhcp is not completely removed am i correct?

2) Let say a ipv6-host boots up and configures itself with link-local address,FE80:: mac address.

Next host receives a prefix 2001:: and host configures another ip address based on prefix received from router. Will router apply both addresses i.e link -local and address based on received prefix from router to a interface? If yes , which one will be used for communication?

Thanks

Peter Paluch · ‎08-25-2010

Hello Sarah,

So nice to meet you here again!

1) You're absolutely correct. The stateless autoconfiguration in IPv6 provides some of the most important IPv6 settings but it is not readily extensible and as an example, as you pointed out very correctly, the DNS server address cannot be currently assigned via Router Advertisement messages. Thus, the need for DHCPv6 is by far not alleviated and I am certain it will never be because the autoconfiguration is just a "quick-and-simple" way of doing things while the DHCPv6 is the fully-fledged solution for centralized IPv6 settings management (think of having fixed IPv6/MAC bindings, automatic web proxy discovery, TFTP service for IP phones, wireless LAN controller address for lightweight access points, WINS, whatever else is out there that can already be pushed to client via DHCP - the stateless autoconfig simply is not meant to provide these settings).

2) I do not entirely understand your question but generally, if a host receives a Router Advertisement message, it already has its own link-local address (derived from its MAC address as a modified EUI-64). The host simply uses this EUI-64 concatenated with the prefix received in the Router Advertisement and form a globally unique address. It will then use this globally unique address. With operating systems supporting the IPv6 Privacy Extensions, they also create a pseudo-random suffix to the IPv6 prefix received in the Router Advertisement message, and so, they have two global unique addresses - the one with the 64 random bits in the host part, and the one using the modified EUI-64. These operating systems will respond if they are contacted on every their IPv6 address. However, for outgoing connections, these operating systems will use the pseudo-random address. The EUI-64 derived IPv6 address 'speaks only when spoken to'.

I hope this helps but please ask further!

Best regards,

Peter

View solution in original post

Giuseppe Larosa · ‎08-25-2010

Hello Sarah,

:

1) you have already found the biggest drawback of staless autoconfiguration: lack of DNS information. This has been a great limit for IPv6 adoption before working implementations of DHCPv6. It is a pity that introducing IPv6 this aspect hasn't been addressed.

2) an IPv6 host will use link local or global addresses (more then one is supported) depending on what source address was used by first sender.

You can imagine that an IPV6 interface can have a link local, a unique local address, and one or more global unicast addresses.

It depends from case to case, so if sending traffic to a link local destination, link local will be used, if sending to an unique local the unique local and so on.

Be aware that router advertisements can advertise prefixes that are on link (reachable by simply using neighbor discovery) and prefixes that are off link where the router has to be used to reach them (default gateway). So each host can build its own tables including a table of next-hops to be used.

An IPv4 host cannot contact directly an host that is in a different subnet even if it is in the same broadcast domain. An IPv6 host can do this.

Peter: may you provide a link to these privacy extensions for IPv6 to complete your very good (as usual) post?

Hope to help

Giuseppe

View solution in original post

Peter Paluch · ‎08-25-2010

Giuseppe,

Thank you very much for your kind words!

Actually, regarding the lack of DNS discovery support in stateless autoconfiguration, there have been some experiments with adding this support to the Router Advertisement messages - you may be interested in reading the following Internet Draft:

http://tools.ietf.org/html/draft-beloeil-ipv6-dns-resolver-option-01

Unfortunately, it never went any further beyond the scope of an Internet Draft.

Regarding the IPv6 Privacy Extensions, they have been created by Microsoft, and the most current RFC is the 4941 at

http://tools.ietf.org/html/rfc4941

Best regards,

Peter

View solution in original post

Peter Paluch · ‎08-26-2010

Hello Sarah,

Regarding the number of addresses on an interface (link-local, prefix+eui64, prefix+random), you are completely correct, that is how usually things look, at least in Windows. If you were using DHCPv6 then it's probable that the prefix+eui64 address would be replaced by a DHCPv6-assigned IPv6 address but that's just a nuisance.

Regarding the link-local address: a host uses for link-local communication like sending Router Solicitation messages, Neighbor Discovery messages and so on. However, this communication usually stems from internal "needs" of the IPv6 protocol. User software only seldom asks to communicate using the link-local address, obviously because we're using DNS hostnames for node identification and nobody is going to put link-local addresses in DNS - and even if he did, knowing just the link-local address is not enough because a link-local address per se does not tell your computer which interface should be used to send the packet to that address. Cisco routers generally refuse to forward packets to link-local addresses until you specify the outgoing interface explicitly. That is logical - a link-local address does not have a prefix identifying the network so there is no indication which interface should a packet targeted to a link-local address be sent out from.

Regarding the conflict of either random or link-local addresses: as you have correctly pointed out, stations do perform DAD when they are about to start using an IPv6 address. If a conflict is detected on a random address, the station can simply generate a new random IPv6 address and verify whether that is unused. I must admit I don't know what will happen when a conflict with link-local addresses ensues but I suppose that the driver will simply do what it can - stop using the link-local address and alert the administrator of the station about this incident. Please note that there is no way out of this situation until and unless the stations have unique link-local addresses. Two stations having the same link-local address on a segment would be actually unable to exchange data because they would not be able to distinguish their own packets from the other party. At least that's my idea

I hope Giuseppe and other friends here will add their comments!

Best regards,

Peter

View solution in original post

Peter Paluch · ‎08-26-2010

Hello Sarah,

You are suggesting that all link-local addresses have the prefix of FE80::/10 and therefore they are all on the same subnet. This supposition is not entirely correct. While it is true that all link-local addresses have an identical prefix, this prefix is not interpreted as a network or subnetwork identifier but merely as an indicator that this is a link-local address with all its ramifications.

A link-local address is always usable only with an explicit indication of the interface on which it is reachable. We are always considering the link-local address in its entirety, i.e., the complete /128 IPv6 address, as a host address - no subnet IDs or prefixes or any of that stuff. For example:

Switch#ping FE80::214:6AFF:FE96:CA4E
Output Interface: Vlan709
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::214:6AFF:FE96:CA4E, timeout is 2 seconds:
Packet sent with a source address of FE80::21B:8FFF:FE8F:DE5A
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/3/9 ms
Switch#ping 2001:4118:300::7:25

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4118:300::7:25, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/8/25 ms
Switch#

Note how the switch asked me for the outgoing interface when I pinged the link-local address of a neighboring router - because without the indication of where the output interface is, the switch wasn't able to proceed with the ping. Pinging a global unicast address went fine directly, according to the normal routing table.

So I actually can use a link-local address to communicate with a neighbor - as you can see, a simple IP communication as ping succeeded but only under circumstances that I precisely know which interface to use for this type of communication.

Routing protocols in IPv6 use the link-local addresses of routers as next-hop addresses so again, the communication based on link-local addresses must actually be possible. However, when you have a look at an IPv6 routing table, a network together with a link-local next-hop address will always be identified together with the outgoing interface:

O   2001:4118:300::7:37/128 [110/20]
     via FE80::214:6AFF:FE96:CA4E, Vlan709
O   2001:4118:300::7:62/128 [110/10]
     via FE80::A1F:F3FF:FE38:5C1, Vlan138
O   2001:4118:300:1::/64 [110/30]
     via FE80::214:6AFF:FE96:CA4E, Vlan709

This makes the routing entry, with respect to the link-local next-hop address, unambiguous.

To sum it up - a link local address is always treated as a host-address with full 128 bits, without any network or subnetwork prefix. A link-local address is usable only with an explicit specification of the egress interface on which it is reachable. A communication using link-local addresses can be successful only on a common link between two nodes and only if the communicating application is able to specify the exact outgoing interface.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎08-26-2010

Hello Sarah,

This is an example of a backbone created by having three routers running IPv6 and RIPng connected to a common switch. The common backbone is 2001:1:1:123::/64. Each of these three routers also has a loopback with the IPv6 address 2001:1:1:fffX::/64 where X is the number of the router (1, 2 or 3).

The routing table on R1 shows:

R1#show ipv6 route
IPv6 Routing Table - 8 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   2001:1:1:123::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:1:1:123::1/128 [0/0]
     via ::, FastEthernet0/0
C   2001:1:1:FFF1::/64 [0/0]
     via ::, Loopback0
L   2001:1:1:FFF1::1/128 [0/0]
     via ::, Loopback0
R   2001:1:1:FFF2::/64 [120/2]
     via FE80::C201:65FF:FE02:0, FastEthernet0/0
R   2001:1:1:FFF3::/64 [120/2]
     via FE80::C202:65FF:FE02:0, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

R1#

Note that the link-local addresses are actually displayed only with the RIP-discovered routes and outgoing interface, as the RIP advertisement from a particular RIP neighbor was received on that particular interface, in this case, Fa0/0.

If I were to set up a static route using a link-local next hop address, it would look as follows:

R1(config)#ipv6 route 2001:1:1:ffff::/64 FE80::C201:65FF:FE02:0 
% Interface has to be specified for a link-local nexthop
R1(config)#ipv6 route 2001:1:1:ffff::/64 Fa0/0 FE80::C201:65FF:FE02:0 
R1(config)#

I need to specify the outgoing interface whenever I want to work with the link-local address.

Does this help? Please ask further!

Best regards,

Peter

View solution in original post

Peter Paluch · ‎08-29-2010

Hello Sarah,

Sorry for replying lately. Let's go over your questions.

A ipv6 node( router or host),  generate link-local addresses.  These
addresses will use prefix FE8X,FE9A,FEBX    where  X  could any
combination of 4 bits.  But  I did not see any link-local address
starting with those above mentioned prefix.

Yes, they are not directly indicated in the routing table, nor should they be. Let's have the routing table displayed again here as I have configured the network anew and the MAC addresses are not entirely the same as the last time:

R1#show ipv6 route
IPv6 Routing Table - 8 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   2001:1:1:123::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:1:1:123::1/128 [0/0]
     via ::, FastEthernet0/0
C   2001:1:1:FFF1::/64 [0/0]
     via ::, Loopback0
L   2001:1:1:FFF1::1/128 [0/0]
     via ::, Loopback0
R   2001:1:1:FFF2::/64 [120/2]
     via FE80::C201:77FF:FE0B:0, FastEthernet0/0
R   2001:1:1:FFF3::/64 [120/2]
     via FE80::C202:77FF:FE0B:0, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
R1#

However, you can see link local addresses when you display the individual interface's IPv6 properties, for example, on R2:

R2#show ipv6 interface Fa0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C201:77FF:FE0B:0
Global unicast address(es):
    2001:1:1:123::2, subnet is 2001:1:1:123::/64
Joined group address(es):
    FF02::1
    FF02::2
    FF02::9
    FF02::1:FF00:2
    FF02::1:FF0B:0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses.
R2#

Notice that the link-local address of R2's Fa0/0 is the next-hop address as visible on R1 for the network 2001:1:1:FFF2::/64.

Towards the end of routing table,
i found following entry.
L FE80::/10 (0/0) via :: null 0
L FF00 ::/8 (0/0) via :: null0
How did we get these   entries?

It's the router's way of saying "all received packet destined to a link-local address will not be routed further". It is placed there by IOS automatically. Either the packet is destined to the router itself, or it will be dropped and not forwarded. It is also the reason why there are no individual link-local addresses recorded in the routing table: they would be considered routable. This Null0 entry makes sure that rerouting attempts of packets destined to link-local addresses will fail.

others  routers  router2 and router 3  must  have generated respective 
link-local addresses  on their interfaces connected to switch.  But 
Rip  did not  advertise those link-local   addresses to router 1.

Correct - and we also don't want the RIPng to advertise them at all, otherwise they would spread through the entire RIPng-enable network.

Router 1 learned two routes from rip advertisement received from router 2 and router 3.

only route learned from router 2 is shown below.

R 2001:1:FFF2::/64 (120/2) via FE80:: C201:65FE:FE02:0 f0/0

here we know router#2 has local-link address FE80::C201:65FE:FE02:0

But router 2 did not advertise its link-local address to router 1.

Router 2 did not have to do that. Remember that Router 2 sent its RIPng message sourced from its link-local address. It is the very same as with RIP in IPv4 - it also does not have to advertise the particular interface's IPv4 address. Instead, the packet's source IPv4 address is taken as the next hop. The same here with RIPng

Best regards,

Peter

View solution in original post

Peter Paluch · ‎08-25-2010

Hello Sarah,

So nice to meet you here again!

1) You're absolutely correct. The stateless autoconfiguration in IPv6 provides some of the most important IPv6 settings but it is not readily extensible and as an example, as you pointed out very correctly, the DNS server address cannot be currently assigned via Router Advertisement messages. Thus, the need for DHCPv6 is by far not alleviated and I am certain it will never be because the autoconfiguration is just a "quick-and-simple" way of doing things while the DHCPv6 is the fully-fledged solution for centralized IPv6 settings management (think of having fixed IPv6/MAC bindings, automatic web proxy discovery, TFTP service for IP phones, wireless LAN controller address for lightweight access points, WINS, whatever else is out there that can already be pushed to client via DHCP - the stateless autoconfig simply is not meant to provide these settings).

2) I do not entirely understand your question but generally, if a host receives a Router Advertisement message, it already has its own link-local address (derived from its MAC address as a modified EUI-64). The host simply uses this EUI-64 concatenated with the prefix received in the Router Advertisement and form a globally unique address. It will then use this globally unique address. With operating systems supporting the IPv6 Privacy Extensions, they also create a pseudo-random suffix to the IPv6 prefix received in the Router Advertisement message, and so, they have two global unique addresses - the one with the 64 random bits in the host part, and the one using the modified EUI-64. These operating systems will respond if they are contacted on every their IPv6 address. However, for outgoing connections, these operating systems will use the pseudo-random address. The EUI-64 derived IPv6 address 'speaks only when spoken to'.

I hope this helps but please ask further!

Best regards,

Peter

sarahr202 · ‎08-25-2010

Thanks Peter and Giuseppe.

It is nice seeing you too peter after a long time.

I am still thinking about your and Giuseppe responses. Being a slower learner , i will take some time

Peter Paluch · ‎08-25-2010

Sarah,

No problem, take your time - I have had my own troubles understanding the guts of IPv6 myself

Best regards,

Peter

sarahr202 · ‎08-25-2010

seppeThanks Peter.

So in nut shell, a host could have :

1) link-local ip address

2) prefix + Eui-64( prefix received from router)

3) prefix + randomly generated number( in case of Operating system supporting privacy extention)

Now the question is which one will be used.

Based on your response, all the outgoing connection from host will use prefix+ randomly generated number.

Prefix+ eui-64 will only be used if host receives packet at this address.

But what about link-local address. Based on Giuseppe response, host will use only this address on local link.

Is my understanding correct?

Now lets talk about the uniqueness of the address.

For successful communication to occur , each host should have unique ip address. Before host transition the link-local address to preferred state, it first checks if some other host is using the same address by performing " duplicate address duplication" or simply "DAD".

How the uniqueness can be sure in case of two last address i.e prefix+ eui-64, prefix + randomly generated number.

Let talk about first prefix+ 64 eui.

There are number of software tools available to change your mac address. You might be using mac address of your NIC, but it is possible someone else might be using the same mac because he /she uses the software tool to change mac address. Though the possibility is very remote, it is possible.

Now lets talk about prefix+ randomly generated number.

It is possible for two host across the globe to generate the same number and thus end up with same ipv6 address. Again the uniqueness of ip address is not sure.

What will internet router do if they receive link-local address as destination address? for example in case of ipv4, internet routers will drop the packet if they receive a packet with private address as destination.

thanks Giuseppe and Peter.

Peter Paluch · ‎08-26-2010

Hello Sarah,

Regarding the number of addresses on an interface (link-local, prefix+eui64, prefix+random), you are completely correct, that is how usually things look, at least in Windows. If you were using DHCPv6 then it's probable that the prefix+eui64 address would be replaced by a DHCPv6-assigned IPv6 address but that's just a nuisance.

Regarding the link-local address: a host uses for link-local communication like sending Router Solicitation messages, Neighbor Discovery messages and so on. However, this communication usually stems from internal "needs" of the IPv6 protocol. User software only seldom asks to communicate using the link-local address, obviously because we're using DNS hostnames for node identification and nobody is going to put link-local addresses in DNS - and even if he did, knowing just the link-local address is not enough because a link-local address per se does not tell your computer which interface should be used to send the packet to that address. Cisco routers generally refuse to forward packets to link-local addresses until you specify the outgoing interface explicitly. That is logical - a link-local address does not have a prefix identifying the network so there is no indication which interface should a packet targeted to a link-local address be sent out from.

Regarding the conflict of either random or link-local addresses: as you have correctly pointed out, stations do perform DAD when they are about to start using an IPv6 address. If a conflict is detected on a random address, the station can simply generate a new random IPv6 address and verify whether that is unused. I must admit I don't know what will happen when a conflict with link-local addresses ensues but I suppose that the driver will simply do what it can - stop using the link-local address and alert the administrator of the station about this incident. Please note that there is no way out of this situation until and unless the stations have unique link-local addresses. Two stations having the same link-local address on a segment would be actually unable to exchange data because they would not be able to distinguish their own packets from the other party. At least that's my idea

I hope Giuseppe and other friends here will add their comments!

Best regards,

Peter

Giuseppe Larosa · ‎08-29-2010

Hello Peter,

>> I must admit I don't know what will happen when a conflict with link-local addresses

Duplicate Address detection is performed also for link local addresses if a duplicate is found the IPv6 host will try again with a modified host portion.

At least in theory, to be noted that only the lowest 24 bits are used for deriving the host portion of local address so the standard should have provided for handling a duplicate.

Sarah:

link local addresses have been introduced in order to be able to remove the use of broadcast frames and of ARP.

Without link local addresses and their associated IPv6 link local multicast addresses neighbor discovery would not be possible (given that broadcast destination cannot be used even at OSI layer2)

link local addresses are there to build the next-hop table and they are not intended for routing but as help for forwarding.

As Peter has showed Link local can appear as next-hop always with an outgoing interface but there is no need to route towards a link local address.

Hope to help

Giuseppe

Peter Paluch · ‎08-29-2010

Hi Giuseppe,

Thank you very much for adding this information!

Best regards,

Peter

sarahr202 · ‎08-31-2010

Hi Peter.

sorry about the belated question.

Let say we have ipv6 host and dhcpv6 server. we are using stateful DHCP i.e host ipv6 will request the ipv6 assignmeny by dhcp server. Further assume the host is windows host. Will host still generate prefix+ randomly generated number as globally unique address though it has received an ipv6 address from dhcpv6 server?

thanks and have a great day.

Giuseppe Larosa · ‎08-25-2010

Hello Sarah,

:

1) you have already found the biggest drawback of staless autoconfiguration: lack of DNS information. This has been a great limit for IPv6 adoption before working implementations of DHCPv6. It is a pity that introducing IPv6 this aspect hasn't been addressed.

2) an IPv6 host will use link local or global addresses (more then one is supported) depending on what source address was used by first sender.

You can imagine that an IPV6 interface can have a link local, a unique local address, and one or more global unicast addresses.

It depends from case to case, so if sending traffic to a link local destination, link local will be used, if sending to an unique local the unique local and so on.

Be aware that router advertisements can advertise prefixes that are on link (reachable by simply using neighbor discovery) and prefixes that are off link where the router has to be used to reach them (default gateway). So each host can build its own tables including a table of next-hops to be used.

An IPv4 host cannot contact directly an host that is in a different subnet even if it is in the same broadcast domain. An IPv6 host can do this.

Peter: may you provide a link to these privacy extensions for IPv6 to complete your very good (as usual) post?

Hope to help

Giuseppe

Peter Paluch · ‎08-25-2010

Giuseppe,

Thank you very much for your kind words!

Actually, regarding the lack of DNS discovery support in stateless autoconfiguration, there have been some experiments with adding this support to the Router Advertisement messages - you may be interested in reading the following Internet Draft:

http://tools.ietf.org/html/draft-beloeil-ipv6-dns-resolver-option-01

Unfortunately, it never went any further beyond the scope of an Internet Draft.

Regarding the IPv6 Privacy Extensions, they have been created by Microsoft, and the most current RFC is the 4941 at

http://tools.ietf.org/html/rfc4941

Best regards,

Peter

Giuseppe Larosa · ‎08-25-2010

thanks

Peter

unfortunately the draft has expired long time ago, have you noticed how many french people can be found in IPv6 topics?

Best Regards

Giuseppe

Peter Paluch · ‎08-25-2010

Giuseppe,

You are welcome. Regarding French specialists being active in IPv6 field - I must admit I did not pay attention to that. Are there many in your opinion? I don't have the opportunity to go over the several IPv6 RFCs right now.

Best regards,

Peter

sarahr202 · ‎08-26-2010

Hi Peter

Router installs the best route in its routing table. Also router requires each of its interface must be on the different network/subnet.

Keeping the above fact in mind, let consider a ipv6 router with two interface, f1 and f2

Both interface will generate link-local addresses as part of auo- configuration processes.It is worth remembering both these link address share the same prefix i.e 1111 1110 10, thus both interface will have addresses on the same network.

Now if i use show ip route command what do i expect to see? should i expext to see:

C FE80::/10 directly connected f1

C FE 80::/10 directly connected f2

But this contradicts the fact the router requires each of its interface should be on different subnet/prefix.

will routing table look like as mentioned above?

if yes this is the reason router can not forward the packet destined to FE80:/10 because it can not figure out which interface be used to send packet.

============================================================================

Let say we have laptop with fastethernet and wireless adapter.

As it is part of auto-configuration processes,both interface will generate link-local addresses . Both of which will be on the same prefix/network.

if laptop has to forward a packet to FE80::2/10 then it will encounter the same problem just like router did in our previous example. laptop can not determine which interface be used to send the packet/frame to FE80::2/10 .

Given the above assumptions are correct,link-local addresses can not be used for regular communication between nodes .

is my understanding correct?

thanks and have a nice week.

Peter Paluch · ‎08-26-2010