In this post we are going to get to know the packets used in the OSPF process and then build on this in future blogs to gain a good understanding of the topic.

Ospf is a link state protocol , it in essence sets up neighbour relationships with other router in the ospf domain in order to exchange routing information. The messages used in the creation and maintenance of these relationships will be the focus of the blog post.

When the ospf process is turned on on a router and the  interface falls within the ip network range that has been specified with the network command then that interface will actively try to start the party : ie find some neighbours and try to from some adjacencies. So, for example if the following commands were entered in priv level mode and we had interfaces with ip addresses of 10.10.15.1 and 10.10.10.5 then these interfaces would start trying to setup relationships with other routers in area 0
 
router ospf

network 10.10.0.0 0.0.255.255 area 0
 

 Type of Packets Used in the Process

 
OSPF runs directly over IP using protocol number 89. OSPF packets should always be sent with the IP TOS field set to 0. If at all possible, OSPF packets should be given preference over regular IP traffic, both when being sent and received. (As an aid, OSPF packets should have their IP precedence field set to Internetwork Control). All OSPF packets share a common protocol header. Every OSPF packet starts with a standard 24 byte header. This header contains all the information necessary to determine whether the packet should be accepted for further processing.

The following shows the ospf packet header , the various different packet types that we will discuss in the next  section put their various fields and values into the message body part of the packet.
 

 

  Ospf Messages.

 
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 24 byte header as shown above. All OSPF packet types (other than the OSPF Hello packets) deal with lists of link state advertisements. For example, Link State Update packets implement the flooding of advertisements throughout the OSPF routing domain.

• The Hello Packet
• The Database Description Packet.
• The Link state Request Packet
• The Link State Update Packet
• The Link State Acknowledgement Packet

  Hello Messages.

Hello packets are OSPF packet type 1. They serve two functions , one is to setup relationships with neighbours ,the second is to maintain these relationships by sending packets at a given interval to ensure the neighbouring devices is still alive.

These packets are sent periodically on all interfaces in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers and unicast on other link types but more on that on following posts. Hello Packets are closely tied to Dead Timer Values, as mentioned  routers will use the hello packet to maintain state with other devices if a device does not respond to these hello packets then the sending device deems the other device to be down . So for example on an ethernet network  if router A  sends 4 hello packets without response it will deem router B to be down.Default Values for Dead Timer = Hello Timer *4   The default timers are listed below.
 
Default Timers for hello/Dead Timer Packets

Broadcast Networks: 10 Secs  40 Secs

Non Broadcast Multiaccess Networks: 30 Secs  120 Secs
 
During the setup phase of OSPF neighbours will exchange hello Packets . In order for the relations to move on to a fully adjacent state certain parameters must match in the hello packets exchanged between devices.

These are:

• Must Pass the authentication process , ie they must agree that authentication is turned on and if so then they must agree on the method and password variables.
• They must be in the same primary subnet including the same subnet mask.
• They must be in the same area.
• They must be of the same area type. (stub NSSA and so on)
• They re must not be duplicate RIDS (router ids)
• The ospf hello and dead timers must match.

  Database Description Packets.

Remember that although we have not delved too deeply into OSPF too deeply yet we do know that the main objective is the exchange of routes between the devices. This is where the DD packets come into to play.

The DD packets are OSPF packet Type 2. The OSPF router summarizes the local database and the DD packets carry a set of LSAs belonging to the database. When a neighbor sees an LSA that is more recent than its own database copy, it requests this newer LSA from the neighbor.

It is important to note here that in OSPF the database of learned routes that a devices know is held in various ospf databases.LSA or Link State Advertisements are just the state of a link that attach to the device.

When two devices are starting to exchange this information it  must be done on a organinsed and acknowledged manner. To achieve this during the exchange of information one of the devices becomes the master and one becomes the slave this allows for tagging and tracking all packets .The first DD packet is used to elect the master and slave relationship and to set the initial sequence number elected by the master. The router with the highest router ID becomes the master and initiates the database synchronization. The master sends the sequence number, and the slave acknowledges it. After the master and the slave are elected, the database synchronization starts; in this process, the headers of all the LSAs are exchanged with neighbors. Remember that the LSA’s are attached link to any given device for example is router A has two interfaces that are in up state , that are both 100 Mbps , and have ips of 10.10.0.1/2 then the LSA that is announced is a reflection of that information and a DD is summary of this information.
 

  Link State Request Messages.

Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its topological database are out of date. These packets consist of the OSPF header (as usual) plus fields that uniquely identify the database information that the router is seeking.

A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting, defined by LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request Packet itself. The router may receive even more recent instances in response.
 

  Link State Update Messages.

Link-State Update messages are OSPF packet with Type 4. These packets implement the flooding of LSAs. The Link-State Update message are acknowledged using Link-State Acknowledgement messages. These messages are sent to ALL SPF Routers multicast address. However, if re-sending is required, then they are unicast.

This message will fill in the gaps and provide as all the details that were not included in the DD message. LSA themselves can take up a varirty of formats an will be covered in a later post , for now understanding that the update packet contains details about the LSA (or a number of LSA’s) is the key goal here.
 

  Link State Acknowlegment  Messages.

These messages have a Type value of 5 in the header. They then contain a list of LSA headers corresponding to the LSAs being acknowledged. Simply put they acknowledge the LSA’s they received by responding with the corresponding LSA headers.
 

  Goodbye

 
Thats it for the OSPF message types , this blog has been a high level overview of the message that are used by OSPF , in the next post we will put their application to use and see how devices become neighbours and start exchanging LSA’s
 
Kevin

• running all the system processes required by the device and supporting the technologies enables in the config.
• Sending and receiving packets for the device hardware , such as ports , wic etc.

An increase in packet volume on the network or a process requiring more time/cycles from the processor will result in the utilisation going up resulting in possible issues. The purpose of this post is to help me and anyone interested  to understand and resolve issues surrounding the CPU. So when is busy too busy,well simply put  when a process or an increase in packet flow across the router is so great that it affects the routers ability to serve other packet flows or system processes.  All networks configuration are different and high CPU may be the norm on some routers , when they can handle it of course.  Greater traffic volumes or increase services used on the router such as NAT, acls, gre tunnels, ipsec tunnels etc can and do bring other  routers to a crawl in certain cases and if you are reading this then maybe it has already happened to you.

It is normal ( yes it’s a general assumption) to see router CPU utilisation at below 10 %.  For example the L3 switch we are going to use in this example has never been over 8% in the past 6 months . Granted 10 host and 6 ip phones in not exactly what I would call a 14 hour shift in a coal mine but it could be described as about an  average workload.

Before we get into the examples and finer details of this . it is important to discuss ASIC’s and thier role in Cisco devices. Cisco L3 switches use application specific integrated circuits. As  the name implies it is a circuit designed to do a very specific thing in this case forward packets.  This chips allow the L3 switch to forward packets in hardware instead of software . Router generally do route packets in software which is slower. The trade off with ASIC’ is that they are not as feature rich as the software model of the routers. Ya, sure you can do some rip and eigrp on a L3 switch but not nearly as much funky stuff you can do with a router. Often when you decide trying to decide about which device is better a L3 switch our router you need to start out realising you it is a choice between throughput/speed of a switch against the feature rich design of a router. Why are we talking about this here, well this directly relates to the volume of traffic hitting the CPU. L3 switches can handle the bulk of their traffic in hardware thus not bothering the CPU (via interrupts ) except in case when it does not know the ip route or when the packet requires fragmentation or when NBAR is used. Routers on the other hand use the CPU for most  packets routed through the network . This is a big difference between the two . This divide in operation has become less defined over the past few years but still worth noting.

Checking out the status

To determine the Device utilisation enter the show processes sorted command in priv mode.  Adding the sorted option at the end lists the proc’s that are using the most system resources at the top of the page.

Figure 1

Figure 1 displays the output of the command. There are a number of key numbers to note. The first number 5% (underlined in red) tells us the total utilisation of  the proc  in the last five seconds. The number directly to the right of this 0% represents the percentage of time at the interupt level in the past five seconds. The interupt % is the amount of time the proc spent receiving packets from the device hardware over the last five seconds.  This number is always less than or equal to the total utilisation.  The third number to note is  undelined in purple is the average utilisation for the past minute , . 4%. The fourth number in brown is the average utilisation over the past five minutes 4%.

The processes are listed below in order of usage  and the process using the most resources in this example is the Virtual Exec( my telent session)in pink and it is using .47%. Not a busy router then huh……….

Figure 2.

The other primary command used in resolving cpu based issues is the sh processes cpu history command.  This output of this is as ugly as a bulldog chewing a wasp but it its handy when tryin to align certain network occurances with cpu spikes.

Figure 2

So looking at the output above the cpu histoory is displayed for the last 60 seconds , sixty minutes and 72 hours . Thw Y axis shows the utilisation with the digits across the top also teling us the utilisation. The bottom x axis shows u the time scale in various 5 second,5 minutes and five hour segments.  I have labelled these. The time work lefts to right = new to old . So for example in the first table which lists the last minute over  the last  10 seconds the utilisation was up to 10% ( 5/6 to be precise) .   Another example in the bottom table ( 72 hours which is the last three day ) , 44 hours ago there was a spike that pushed the utilisation up to 23 percent. Just count from left to right in 5 hour block then use the graph on the left of the top of the page to see the utilisation at that time. The utilisation could have been at that level for all the time during the time segment or once during the time segment the graph displays the highest util during the time range and plots its.

When a high utilsation is to be expected.

• Spanning tree both calculations and process is a real burner .  PVLAN spanning-tree protcol in particular.
• Ip Routing update. BGP full or part table. Alos with the use of route-maps and extended acls adding to the issue.
• IOS commands. Show tech-support,sh runing-config,wr mem and debug all causing a spike.
• Other events include igmp requests, large numbers of IP Sla sessions, SNMP pollling activities, Netflow,Largre numbers of DHCP requests, ARP broadcasts, Ethernet storms.

Where is the Problem I am going to lose my Job Soon !!!!!

Right so , we have established there is a problem we are not aware of any obvious problems on the network or any reason for high cpu on our router/switch.   The first thing I try and do is find out if the problem is a process on the box  or a high interrupt level ( which as mentioned above is a sign that the device is getting alot of packets for the network .

Figure 3

In Figure 3 it is safe to say we have a problem ( excuse the poor paint edit , I have no intention of crashing any of the routers in work for the sake of learning). A high interupt level a shown above indicates too much network traffic. This is the most common cause of  high CPU utilisation. On the other hand a high CPU utilisation a with low interupts indicate a issue with a system process.  Its normal for an interupt level to between 5 and 10 % . However any higher that 10% and you rneed to start having a look at things.

So we now need to check the System Process or try and find out where all the Traffic is coming from.That will be covered in the following post. Thanks for reading.

In our previous post we discussed how nodes can use the ipv6 neighbour discovery components of ipv6 to find a local router and attain global addressing or instruction on where to find a global address if not dierctly provided. In this post we will flesh out this process a bit more. This is not an complete in depth look at the process but a pretty decent high level overview.  Should you be looking to nerd out a bit  check out RFC 4861.

Comparison can often aid the learning process so ipv6 ND is comparable to ipv4 arp in that it allow a node find local devices but ipv6 ND is more powerful and more independent an entity that our old buddy arp.  Also bear in mind that ipv4 needs to have an address manually defined or assigned by a DHCP server , this is not a requirement in ipv6 it can assign itself a link-local address and then contact a router on the local link to attain a global unicast address, that is a very powerful feature and make new network role out a less daunting task for us. Node use ND to resolve/complete the following issues/requirements.

• Router Discovery

• parameter Discovery.

• Address Autoconfiguration.

• Address resolution.

• Next Hop Determination.

• Duplicate Address Detection.

So how does all this black magic work ,well in ipv6 the functionality and transport we need is provided for by icmpv6. Remember arp and broadcasting are not used in ipv6. Let step through the process and detail each step and note the various types of icmpv6 packets that are used in the various stages. These messages are multicast addresses.

Router Discovery

When an interface becomes enabled, hosts can send router solicitations. The solicitations request routers to generate router advertisements immediately, rather than at their next scheduled time. The solicitations are sent to help the node acquire its global address, the MTU of the link , the suggested hop count, etc .The node sends  icmpv6 type 133 message- Router Solicitation, and the routers respond with type icmpv6  type 134 Router Advertisement messages . The node then receives the router advertisements and build up a list of default routers.

Router advertisements/ Parameter Discovery.

Routers advertise their presence, various link parameters, and various Internet parameters. Routers advertise either periodically, or in response to a router solicitation message. Router advertisements contain prefixes that are used for on-link determination or address configuration, a suggested hop limit value, and so on. Remember they can be periodic and not dependant on first receiving a solicitation message.

Address Autoconfiguration.

The receiving node can then use the received parameters for the advertisement messages to automatically assign itself a global address as defined in the process of the last post. The diagram below is a sanitized display of this in progress.

Now lets talk about node to node communication for a bit.

Next hop Determination.

So what about if the node wants to send traffic to  neighbouring node on the same link and not to some distant BitTorrent server in Turkey  that is Ipv6 ready , just a good old file transfer across the Lan. In Ipv4 we would look at the subnet mask of the destination packet, decide if it was local to our subnet and if so we would check our arp or arp for the relevant mac address and boom , send that dodgy jpg to the lads in the office. Not so in ipv6, it is a bit different. In IPv6, the prefix information obtained from local routers is compared to the destination of the datagram to determine if the destination device is local or off-net. If it is local,    the next hop is the same as the destination address; if it is non-local, the next hop is chosen from the device’s list of local routers (which are determined either by manual configuration or using the host-router discovery features of ND.)For efficiency purposes, hosts do not perform this next-hop determination for each and every datagram. They maintain a destination cache that contains information about what the next hop should    be for recent devices to which datagrams have been sent. Each time a next hop determination is performed for a particular destination, information from that determination is entered into the cache, so it can be    used the next time datagrams are sent to that device.

Neighbour/Address resolution.

To find the layer 2 address of the host you want to send data to you use another subset of  icmpv6 packets types , the process is very similar to the Router discovery process above. You use Neighbour Solicitation icmpv6 type 135 and Neighbour Advertisement icmpv6 type 136 during the process. A host looking for a neighbour will multicast to the all node address of ff02:1 address  and the destination address will reply       with the sender defined address.

Here is a quote from rfc 2641

Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast whenthe node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor.

Ipv6 Redirection.

The final aspect of the neighbour discovery capability of ipv6 that we will discuss is icmpv6 type 137 , Redirect. This function is used by routers to  tell sending hosts about a better path for traffic or put in a mode crude way ” If you want to send that traffic there talk to other  router on the link he is better than me”. Therefore router on the local link are responsible for correcting a suboptimal first hop routing decision and      then correcting it by informing the sending host that a better first hop exists. See the following diagram for a example.  the packet type used to facilate this correction is know as a Redirect packet and is                 icmpv6 type 137. it is also worth noting that the original packet flow is not dropped it continues on its way but the following packets are send via R1 in the exampe below.

Thanks for reading happy xmas.

Kevin.

ipv6 has three main address types.

• Unicast , these can be of the global or local-link variety or special address type.
• Multicast , these are the same as conventional multicast addresses , packets are destined for all interfaces in a multicast group
• Anycast,  here packets are destined for the one of a group of interfaces usually the nearest one are determined by a routing protocol.

One of the key things to grasp about ipv6 is that an interface can and normally does have multiple addresses. It is common for an interface to have global addresses and local address. In the wonderful world of MS windows you even have more than one type of the local-link address type  just to make thing more interesting and harder to firewall, so lets start.

Unicast address type 1 – Global Unicast

The first type of ipv6 address we will discuss is the global unicast , this is comparable to the publicly routeable address in ipv4 that we are assigned by our ISP. Again the main difference is the lenght (128 bits)  and the fact that we  are no longer trying to conserve these addresses. Currently IANA is assigned addresses from the 2000::/3 range.  Let take an example.

We have been given  the following  range by our ISP 2003:0001:0002::/48.

We then subnet this address ourselves to the 64 bit lenght.  So taking the first subnet of this we would get

2003:0001:0002:0001::/64 . So we are using the fourth field for subnetting and 0001 is the first subnet in the range so that is what we will use for our example network. Rememeber we need the last remaining 64 bits for the Interface ID (host address).

Next we will assign an address to the the host in our chosen network.

2003:001:0002:0001:0000:0000:0000:0001/64 which of course we can write in short hand notation as

2003:1:2:1::1/64.

So we now have our global address for our end server or workstation. In the simple old world of ipv4 internal hosts are normally given an rfc 1918  address such as 10.x.x.x but in the new world of ipv6 everyhost has an address that be routed on the internet without the sue of  NAT , this is another key aspect of ipv6 that need s to be grasped.

Unicast address type 2-  Local Addresses.

Local addresses in ipv6 come in a few different variety but the all serve the same function to facilate communication on local links like LAN’s P2P link etc.  They are kinda comparable to ipv4 private address  but are different.  When two node or router are communcating on the lan with each other they will use these address as the source and destination of the traffic. For example two router speaking OSPF will use thier link-local address when going through neighbour relationship phases and the like.  Ipv6 had its own set of host/router  discovery mechanisms ( like arp in ipv4 but way m0re advanced) and again these local address are used. So they are a key factor of ipv6.

Type 2.1 Site Local.

This address is comparable to a private address in ipv4. It is only routeable within the organsation and not on the internet. Its scope is limited to this context. When configured, a site-local address uses a specific prefix (FEC0::/10).  Owing to the fuzzy terms of its definition and the fact that  it isnt neccasary to have private address of this type in ipv6  ( we have enough addresses even for  the dog in the street and his iphone !!!) this type had been depricated.

Type 2.1 Link-Local.

This one is very important and a key requirement in understanding ipv6. These addresses have a smaller scope than site local. There are not routeable within the organisation they stay on the local link. Router will not forward these off a link. They are used for ipv6 neighbour discovey and other inter host/router communcation on a given physical link as mentioned above. Also and importantly they allow addressing hosts to communicate  without using a globally-routable address prefix. Again routers will not forward packets with link-local addresses. These addresses ar configure within the range of FE80::10.

So how are these address assigned , well they can be manually assigned on the network card are per ipv4 or they can be assigned by a process known as Ipv6 Stateless  Address  Autoconfiguration , I know, sounds funky enough but is is cool and important to grasp. It contracts with  another method of addressing which is  stateful and  involves a server and a protocol called DHCPv6. So stateless equals no DCHP and no annoying dhcp scope assignment happy days. So stateful configuration is dhcp and static assignment and stateless is stateless address autoconfig.

The IPv6 Stateless Address Autoconfiguration Process.

Step 1.

The device generates a link local address. The format is as follows. The first part of the address is always the same. the first ten bits are as follows. The address is generates at his stage is often call the EUI-64 address, dont ask me why !!!.

fe80 HEX

1111 1110 10 BIN

The next 54   are all always zeros.

fe80                                                         000000000000000000000000000000000000000000000000000000

So the first network portion of the address is fe80::/64.

Step 1.1

The host portion of the node remember it is always the last 64 bits of the address is then assigned in the following manner. The mac address of the network card is taken and modified in two ways to come up with the ipv6 address. Example work best as always.

First of all the address is split by inserting the fffe characters in the middle of the mac address 00:90:2717:fc:0f. resulting in 00:90:27:ff:fe:17:fc:0f.

Step 1.2

The universal /local U/L bit is flipped. This is the 7th bit of the address in this case   00 hex in decimal is  00000000 would result in 00000010 which gives an overall address of 02:90:27:ff:fe:17:fc:0f.

So we now have an overall link-local ipv6 address for our host which  is fe80::0290:27ff:fe17:fc0f.

That is the first step in the process but by itself it is quite an important step. We are now going to proceed in detailing how the node/router can attain its global address by using stateless address autoconfiguration.

Step 2.

The node tests to see if the address it has generates is indeed unique. Unlikely put the step is mandatory. It sends out a neigbour solicitation message using the neighbour discovery protocol. ( The topic of the next post) It then listens for a neighbour advertisement in response to see if any other host is using this address. It is higlhy unlikely but neccessary.

Step 3

Assuming that the address is unique the node goes ahead and assigns itself the address. It is now active and able to communicate on the local link but not the wider network or internet.

Step 4.

The node will hen try and contact a lcoat router to try and find out how it will get its other address the global unicast address ,remember in ipv6 addressing interfaces generally have two or more addresses. The node will send a router solicitation message to find out oif there are any router on the link and if so , ask the router how to progress. The router may tell the host to sue dhcpv6 but in most cases it will tell the node to use our old bud stateless auto-config. So to attain its global unicast address the will get the first part of the address ie the network prefix from the router and use the same process as in step 1 above to get the last 64 bits for the host address.

example, we have assign a network address of 2003:3:3:3/64 for the network , the node use the eui-64 address as detailed above and has a global address of   2003:3:3:3/640290:27ff:fe17:fc0f.

Step 5

The node now assigns its second address to the interface  and now has the two address it needs for both local link communication and global communcation , cool enough  all done without us having to ring the monkeys on the systems team , now that my friends is a good thing….

Unicast address type 3 – Special Address types.

Type 3.1  IPv6/ Ipv4 Address Embedding.

Now just so we are under no illusions here , ipv6 and ipv6 will both be running side by side in dual stack configuration for quite a while . So as  result we need a way to represent ipv4 address in the world of ipv6 so that is where address embedding comes in. IPv6 is backward compatible with IPv4, provided that special techniques are used. For example, to enable communication between “islands” of IPv6 devices connected by IPv4 networks, tunneling may be employed. To support IPv4/IPv6 compatibility, a scheme was developed to allow IPv4 addresses to be embedded within the IPv6 address structure. This method takes regular IPv4 addresses and puts them in a special IPv6 format so they are recognized as being IPv4 addresses by certain IPv6 devices.

These address exist on devices that are classified are dual stack that being that theysupport both ipv6 and ipv4 prootcols.

Lets look at an example , th following figure is belonging to the brillaint www.tcpipguide.com , one of the best website out there.

So as you can see the first 96 bits are all zeros and the last 32 bits of the address as the ipv4 address , it is a simple enough process.

Multicast Addresses.

Multicast is a very big topic in Ipv6. The conventional purpose of multicast , to allow one source to send one stream to multiple receipents still exists however there are more features and way more uses for mcast technology in ipv6. Now one of the best things about ipv6 is that there is no more broadcast . That as the americans would say is totally awesome. No more pesky arp requests and no more spotty teeangers causing havic with childlike man in the middle attacks.

Under Ipv4 mulitcast was utilised under the D block of reserved addresses. with Ipv6 mulicast has it own leading prefix of range of address . These are

FF00::/8 in hex

1111:1111:0000:0000 in Binary.

So any address leading with this address is multicast. As you can see we have load and loads and laods of buts left for a whole range of multicast groups and enetities.

The next two fields in the address are used to specify the scope and range of the addres are highlightd in the figure below again from www.tcpipguide.com below. So in total the multicast group will up the first 16 bits of the address field.

I am sparse on information about the current use and naming convention of the flags field .

Here a quote from tcpipguide.com

Flags: Four bits are reserved for flags that can be used to indicate the nature of certain multicast addresses. At the present time the first three of these are unused and set to zero. The fourth is the “T” (Transient) flag. If left as zero, this marks the multicast address as a permanently-assigned, “well-known” multicast address, as we will see below. If set to one, this means this is a transient multicast address, meaning that it is not permanently assigned.

The Scope ID field is somewhat easier to understand however. These four bits are used to dictate the scope or proposed location of the multicast group f0r example scope id 2 is link local only , scope id E ot 15 in dec is global so ca be used on the internet.

The list is as follow some are not yet in use and as with all ipv6 specification are subject to change.

0 reserved
1 interface-local scope
2 link-local scope
3 reserved
4 admin-local scope
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope
9 (unassigned)
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope
F reserved

The remainding 112 bits ar used to address the actual multicast group.

So lets take a few examples.

A link local multicast address to al router in the nodes on the link would be ff02::1 ( note ::1 as a host is all node on a link by)

All nodes on the local network site would be ff05::1.

Lets  pretend that a new NTP server was created by NASA for the whole internet , The potential address would be ff0e:0001::1.

Anycast  Addresses.

An anycast address is something quite new and sweet in terms onf load balanacing  it is essence  identifies multiple interfaces by one address . With the appropriate routing topology, packets addressed to an anycast address are delivered to a single interface (the nearest interface that is identified by the address). The nearest interface is defined as being closest in terms of routing distance. A multicast address is used for one-to-many communication, with delivery to multiple interfaces. An anycast address is used for one-to-one-of-many communication, with delivery to a single interface.

That all then , next I ll be looking at ipv6 neighbour discovery protocol. As some of the concepts here are new to me I welcome comments.

ipv6 like it or not is coming down the track and fast. The why for ipv6 is simple enough we are running out of ipv4 addresses and fast. Different sources quote different timelines , the website potaroo.com lists a detailed graph and countdown timer that estimates d-day for ” ahh you want a ipv4 public address , sorry they are all gone” to be sometime mid 2011. The long and the short of all this end of the world stuff for us net engineers is that we need to get to grips with the new kid in town IPV6.

The big difference between ipv4 and ipv6 is the volume of bits available to use as addresses. With ipv4 we had somewhere in the region of 4 billion addresses to use on the internet , with ipv6 this number is somewhat larger try 2^128, about 3.4×10³⁸ or 3.4340,282,366,920,938,463,463,374,607,431,768,211,456 which is a number that I can’t even describe , suffice to say this there is enough publicly routeable address for even human with multiple devices to connect to the internet for the foreseeable future. This difference stems for the fact that whereas ipv4 uses 32 bits for addressing ipv6 uses 128 bits for addressing. The other key difference in the format of the two address types is that while ipv4 uses decimal to denote the address , ipv6 uses hexidecimal, why I hear you exclaim in horror. Well to provide  convenience to  humans of course !!!,  since the computer really only understands pure binary. Hex is much more compact since it is based on 16 (the fourth power of 2) instead of 2. Pure binary numbers based on 2 can quickly become unwieldy to write. For example, the three-digit decimal number 513 requires ten digits in pure binary (1000000001) but only three (201) in hex.

&nbps;
An example of how this can help us compact the massive ipv6 addresses is below..

Here is a sample ipv6 address. ( note ipv6 is not case-sensitive so cap/non cap = same thing)

805b.2d96.dc28::FC57.D4C8.1FFF

the same address written in decimal is

128.91.45.157.220.40.0.0.0.0.252.87.212.200.31.255.

Now the address do indeed look complex but don’t worry it is not that bad when you get into it , I am just trying to highlight the shorter notation of a hex address.

So when looking at an ipv6 address you have to view it as a hex add, hex values to decimal values are as follows.

0 = 0          3 = 3      6 = 6     8 = 8       11 = B     14 = E

1 = 1           4 = 4       6 = 6      9 = 9     12 = C   15 = F

2 = 2           5 = 5     7 = 7     10 = A   13 = D.

lets look at an example of another ipv6 address and.

(note: a field is a group of digits hex/dec or bin separated by the colons as below)

2001:0db8:c008:0001:0000:0000:0000:0001.

each hex character above represents 4 bits so each field is 16 bits or 2 bytes written in binary the first two parts of the address would be.

0020000000000001:0000110110111000:

to calculate the binary to hex conversion just think as each character in hex representing 4 bits and use the conversion chart above.

Shorter format.

So we are agreed the addresses are longin ipv6, are in hex for us simple humans to digest but luckily the designers of ipv6 created a couple of ways to shorten the address notation.

Method 1

leading zeros can be dropped ,  however there must be one remaining character in each field  ,again examples work best. The following address can be shortened to the lower address.

2001:0004:04de:0000:0123:2345:002f:003e

2001:4:4de:0:123:2345:2f:3e

Method 2

Consecutive fields of zeros can be replaced by using the double colon options. The following address can be shortened to the lower address.

2003:0000:0000:0000:0000:5d34:002e:0001

2003::5d34:2e:1

both options can be combined together to shorten the address. check out this one , pretty slick indeed.

2002:0000:0000:0000:0000:0000:0000:0001

2002::1

(Note: you cannot have more than one set on double colons in an address it is illegal. the following example is an illegal ipv6 address).

2002::e4f:234e::23

Subnets.

Subnetting in ipv6 is similar to subnetting in ipv6 . it uses cidr prefixes in the prefix/prefix length notation. however there are clearly defined boundaries and functionality within each boundary.
&nbps;

An IPv6 address is broken into three different parts; the site prefix, the subnet ID, and the interface ID. These three components are identified by the position of the bits within the address. The first three fields in an IPv6 address make up the site prefix. The next field represents the subnet ID, and the last four fields are used for the interface ID.

The site prefix is similar to an IPv4 network number. It is the number that is assigned to your site by an ISP. Typically, all of the computers within a site would share the same site prefix. The site prefix tends to the public in nature since that uniquely identifies your network and allows your network to be accessible from the Internet.

Unlike the site prefix, the subnet ID is private because it is internal to your network. The subnet ID describes the network’s site topology. The subnet ID works very similarly to the way that subnetting works in the IPv4 protocol. The biggest differences are that these subnets can be 16 bytes in length, and is expressed in hexadecimal format rather than in dotted decimal notation. An IPv6 subnet typically corresponds to a single network branch (site) just as an IPv4 subnet does.

The interface ID works similarly to an IPv4 host ID. This number uniquely identifies an individual host on your network. The interface ID (which is sometimes referred to as a token) is typically configured automatically based on the network interface’s MAC address. The interface ID can be manually configured in EUI-64 format

lets take a typical example of an allocation.

A small ISP would typically get an address something similar to 2001:0db8::/32

This isp would then allocate an address  to a corporate customer/ building or home 2001:0db8:0015::/48

Typical subnets including Lans/P2P links etc would be given an address of 2001:0db8:001548c3::64 , this leaves the remaining 64 bits fir a host id.

That is generally as small  as the networkmask gets. so it breaks down to 64 bits for the subnet and 64 bits for the host id on that subnet . The reason for this us something call eui-64 addressing which is something you can read about in the next post about ipv6 address types. as you will have noticed there is huge wastage on ipv6 addressing schemes but thepoint of the matter is that we are not trying to conserve ipv6 addresses like we did for ipv4 we are trying to have standard configuration address blocks to make things more uniform.

As this is my first post, it will not be perfect so any feedback or comments are welcome. Until next time . Slan…