Search this Blog

Thursday, August 26, 2010

IPV6 address and link-local address

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 is it 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?

1) 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) 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'.

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











1) you have already found the biggest drawback of stateless auto configuration: 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.


Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

No comments :

Post a Comment

 
/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */