Transcript for this video
Welcome to the InterWorking Labs webinar.
This is Module 2: the IPv6 MIBs Challenge.
This module describes the basic challenge in changing the old MIBs into the new MIBs and why we needed to do this.
The basic problem was the IPv4 MIBs only allowed a v4 address in the indexing construct for many of the structures that they had.
Obviously this was not going to survive—not be able to be used with a 128 bit address, as with IPv6.
So the original solution was to add a completely new set of IP MIBs.
This sort of worked, unfortunately it has a new problem; there’s two MIB documents.
Everybody has to implement two different things, the code can’t necessarily be reused, not particularly scalable, and not something most people were particularly happy with.
The new challenge was to fix that.
The new solution was to create a single addressing construct that would support both IPv4 and IPv6 addresses, and at the same time we added in DNS addresses because they might be useful as well, and to make this extensible for future purposes so that if there is another IPv7, IPv8, that can be added as well.
RFC 4001 is the definition for these addresses.
It discusses several other constructs as well, but there are two major textual conventions: the InetAddressType and the InetAddress.
The InetAddressType specifies how to interpret the address, so if you think of this as a type selector within another language, it’s somewhat similar.
It tells us if it’s an unknown, IPv4, v6, IPv4z, v6z, or a DNS address.
The “Zs” refer to whether or not there’s a zone in the address.
The InetAddress itself is an octet string, and you need the two of them together to tell you how to interpret the second one.
So if you have an InetAddressType of IPv4, then your InetAddress will be a particular format.
In that particular case it’ll be four octets long and will represent a standard IPv4 address.
When using these in indexing constructs, they do have a slight oddity to them—that there’s a length field included in the indexing stream.
So instead of just having a type and, say, the four bytes of an IPv4 address, you’ll have this type, followed by length, followed by the appropriate bytes of the actual address.
So if we go to the indexing example, we have an IP address of 126.96.36.199.
When we turn this into an index, it will become 188.8.131.52.3.4
1 indicates that it is a type of IPv4, 4 is the length of the 4 octets, and the 184.108.40.206 is the address actually split up one octet per subID.
Scope and zone are also included in the addressing concepts.
The Zs refer to zones.
This allows us to have different areas of addressing.
A scope is a general description of the entire class, whereas a zone is a particular area within that.
So for example, on a link local thing, a single Ethernet link, scope is that particular description; it is one Ethernet segment.
Zone would describe a particular segment within that.
So if you have one host plugged into three or four different Ethernet segments, you would have four separate zones there.
And they might be numbered 1, 2, 3, and 4 so that you could separate out those addresses that are unique in and of themselves if you have a link local address.
For example, a host that’s plugged into four different Ethernets, you would need a separate zone identifier for each of those Ethernets.
This ends Module 2.
Want to Know More?
|Find more videos||How to buy||Contact an Expert|