Transcript for this video
Welcome to the InterWorking Labs IPv6 MIBs webinar.
This is Module 3, discussing changes in forwarding, TCP, and UDP MIBs.
Each of these MIBs replaced two different RFCs.
There was one for the IPv4, and one for the IPv6 versions of these tables.
So now we have reduced it down to a single MIB per table.
In general, the changes to these were relatively straightforward: replacing the IPv4 addresses and all of the indices with a new construct.
There was also a set of changes to update the MIBs to reflect new understandings of connections.
In TCP, we split the table into a listening table and a connections table, as the two have somewhat different characteristics.
In UDP, we added connected information into the table itself, and in both of them we added the OS process number to allow mapping from a given connection into the actual process within a system.
The next slides discuss an indexing example so that you can see how the new indexing would work and what type of changes you might have to make.
In the first slide, we have an IPv4 address for the TCP listener local stuff.
If you look at the green field, that’s the IPv4 tag; this turns out to be 1 in our current numbering, followed by the red field, which is the length field.
This we could have simply passed on, and gone with saying that we know how long an IPv4 address is, but given the possibility of error, we decided that it would be better to put in the length field and allow the protocol itself to be able to do checking on this.
Following the length field is the actual address itself.
This is split up; one subID per byte of actual address.
And finally is the orange field, which is the local port which is attached to it.
On the next slide, we have an example of an IPv6 address with zoning information.
As you may remember from the last module, a zone indicates a particular region within which this address is useful.
So, given an address of this very long IPv6, you can see how it would work out towards the bottom.
We would again have a type field, represented by purple in this case.
In this case, it is 4 for v6 with zone information.
The length field would become 20 in this case.
That’s 16 bytes of IPv6 address and four bytes of zone information.
The entire address and zone is treated as a single unit in this particular case, so we have 20 bytes worth of information with each of those bytes getting its own subID.
The zone is shown in green here, and because it’s being treated as a string rather than an integer, it has to be set up as four separate subIDs rather than converting one integer into a single subID.
And lastly, we again have the local listener port which is 22. That is an integer and is treated as an integer, so it can go into a single subID.
This concludes Module 3.
Want to Know More?
|Find more videos||How to buy||Contact an Expert|