diff --git a/Contralto.sln b/Contralto.sln index 095cc50..095a27c 100644 --- a/Contralto.sln +++ b/Contralto.sln @@ -8,9 +8,6 @@ EndProject Project("{930C7802-8A8C-48F9-8165-68863BCCD9DD}") = "ContraltoSetup", "ContraltoSetup\ContraltoSetup.wixproj", "{47BBC195-80C5-43F3-B691-7D27B0803B84}" EndProject Global - GlobalSection(Performance) = preSolution - HasPerformanceSessions = true - EndGlobalSection GlobalSection(SolutionConfigurationPlatforms) = preSolution Debug|Any CPU = Debug|Any CPU Debug|x64 = Debug|x64 @@ -30,6 +27,7 @@ Global {CC6D96B3-8099-4497-8AD8-B0795A3353EA}.Release|Any CPU.Build.0 = Release|Any CPU {CC6D96B3-8099-4497-8AD8-B0795A3353EA}.Release|x64.ActiveCfg = Release|x64 {CC6D96B3-8099-4497-8AD8-B0795A3353EA}.Release|x86.ActiveCfg = Release|x86 + {CC6D96B3-8099-4497-8AD8-B0795A3353EA}.Release|x86.Build.0 = Release|x86 {47BBC195-80C5-43F3-B691-7D27B0803B84}.Debug|Any CPU.ActiveCfg = Debug|x86 {47BBC195-80C5-43F3-B691-7D27B0803B84}.Debug|x64.ActiveCfg = Debug|x86 {47BBC195-80C5-43F3-B691-7D27B0803B84}.Debug|x86.ActiveCfg = Debug|x86 @@ -45,4 +43,7 @@ Global GlobalSection(Performance) = preSolution HasPerformanceSessions = true EndGlobalSection + GlobalSection(Performance) = preSolution + HasPerformanceSessions = true + EndGlobalSection EndGlobal diff --git a/Contralto/CPU/ConstantMemory.cs b/Contralto/CPU/ConstantMemory.cs index 04cab3a..6e82034 100644 --- a/Contralto/CPU/ConstantMemory.cs +++ b/Contralto/CPU/ConstantMemory.cs @@ -178,18 +178,18 @@ namespace Contralto.CPU private static RomFile[] _constantRomsAltoI = { - new RomFile(Configuration.GetAltoIRomPath("c0_23.BIN"), 0x000, 12), - new RomFile(Configuration.GetAltoIRomPath("c1_23.BIN"), 0x000, 8), - new RomFile(Configuration.GetAltoIRomPath("c2_23.BIN"), 0x000, 4), - new RomFile(Configuration.GetAltoIRomPath("c3_23.BIN"), 0x000, 0), + new RomFile(Configuration.GetAltoIRomPath("C0_23.BIN"), 0x000, 12), + new RomFile(Configuration.GetAltoIRomPath("C1_23.BIN"), 0x000, 8), + new RomFile(Configuration.GetAltoIRomPath("C2_23.BIN"), 0x000, 4), + new RomFile(Configuration.GetAltoIRomPath("C3_23.BIN"), 0x000, 0), }; private static RomFile[] _constantRomsAltoII = { - new RomFile(Configuration.GetAltoIIRomPath("c0"), 0x000, 12), - new RomFile(Configuration.GetAltoIIRomPath("c1"), 0x000, 8), - new RomFile(Configuration.GetAltoIIRomPath("c2"), 0x000, 4), - new RomFile(Configuration.GetAltoIIRomPath("c3"), 0x000, 0), + new RomFile(Configuration.GetAltoIIRomPath("C0"), 0x000, 12), + new RomFile(Configuration.GetAltoIIRomPath("C1"), 0x000, 8), + new RomFile(Configuration.GetAltoIIRomPath("C2"), 0x000, 4), + new RomFile(Configuration.GetAltoIIRomPath("C3"), 0x000, 0), }; private static RomFile _acSourceRoms = new RomFile(Configuration.GetRomPath("ACSOURCE.NEW"), 0x000, 0); diff --git a/Contralto/CPU/UCodeMemory.cs b/Contralto/CPU/UCodeMemory.cs index 1b25a29..334f2ac 100644 --- a/Contralto/CPU/UCodeMemory.cs +++ b/Contralto/CPU/UCodeMemory.cs @@ -447,24 +447,24 @@ namespace Contralto.CPU private static RomFile[] _uCodeRomsAltoII = { // first K (standard uCode) - new RomFile(Configuration.GetAltoIIRomPath("u55"), 0x000, 28), - new RomFile(Configuration.GetAltoIIRomPath("u64"), 0x000, 24), - new RomFile(Configuration.GetAltoIIRomPath("u65"), 0x000, 20), - new RomFile(Configuration.GetAltoIIRomPath("u63"), 0x000, 16), - new RomFile(Configuration.GetAltoIIRomPath("u53"), 0x000, 12), - new RomFile(Configuration.GetAltoIIRomPath("u60"), 0x000, 8), - new RomFile(Configuration.GetAltoIIRomPath("u61"), 0x000, 4), - new RomFile(Configuration.GetAltoIIRomPath("u62"), 0x000, 0), + new RomFile(Configuration.GetAltoIIRomPath("U55"), 0x000, 28), + new RomFile(Configuration.GetAltoIIRomPath("U64"), 0x000, 24), + new RomFile(Configuration.GetAltoIIRomPath("U65"), 0x000, 20), + new RomFile(Configuration.GetAltoIIRomPath("U63"), 0x000, 16), + new RomFile(Configuration.GetAltoIIRomPath("U53"), 0x000, 12), + new RomFile(Configuration.GetAltoIIRomPath("U60"), 0x000, 8), + new RomFile(Configuration.GetAltoIIRomPath("U61"), 0x000, 4), + new RomFile(Configuration.GetAltoIIRomPath("U62"), 0x000, 0), // second K (MESA 5.0) - new RomFile(Configuration.GetAltoIIRomPath("u54"), 0x400, 28), - new RomFile(Configuration.GetAltoIIRomPath("u74"), 0x400, 24), - new RomFile(Configuration.GetAltoIIRomPath("u75"), 0x400, 20), - new RomFile(Configuration.GetAltoIIRomPath("u73"), 0x400, 16), - new RomFile(Configuration.GetAltoIIRomPath("u52"), 0x400, 12), - new RomFile(Configuration.GetAltoIIRomPath("u70"), 0x400, 8), - new RomFile(Configuration.GetAltoIIRomPath("u71"), 0x400, 4), - new RomFile(Configuration.GetAltoIIRomPath("u72"), 0x400, 0) + new RomFile(Configuration.GetAltoIIRomPath("U54"), 0x400, 28), + new RomFile(Configuration.GetAltoIIRomPath("U74"), 0x400, 24), + new RomFile(Configuration.GetAltoIIRomPath("U75"), 0x400, 20), + new RomFile(Configuration.GetAltoIIRomPath("U73"), 0x400, 16), + new RomFile(Configuration.GetAltoIIRomPath("U52"), 0x400, 12), + new RomFile(Configuration.GetAltoIIRomPath("U70"), 0x400, 8), + new RomFile(Configuration.GetAltoIIRomPath("U71"), 0x400, 4), + new RomFile(Configuration.GetAltoIIRomPath("U72"), 0x400, 0) }; diff --git a/Contralto/Configuration.cs b/Contralto/Configuration.cs index fa88f8d..1024d49 100644 --- a/Contralto/Configuration.cs +++ b/Contralto/Configuration.cs @@ -18,6 +18,7 @@ using Contralto.Logging; using System; using System.IO; +using System.Reflection; namespace Contralto { @@ -86,13 +87,13 @@ namespace Contralto { static Configuration() { - // Initialize things to defaults. + // Initialize things to defaults. HostAddress = 0x22; BootAddress = 0; BootFile = 0; - SystemType = SystemType.TwoKRom; + SystemType = SystemType.OneKRom; InterlaceDisplay = false; @@ -202,7 +203,7 @@ namespace Contralto public static string GetAltoIRomPath(string romFileName) { - return Path.Combine("ROM", "AltoI", romFileName); + return Path.Combine("ROM", "AltoI", romFileName); } public static string GetAltoIIRomPath(string romFileName) @@ -216,26 +217,29 @@ namespace Contralto } /// - /// Reads the current configuration file from the app's configuration. - /// - /// TODO: use reflection to do this. + /// Reads the current configuration file from the appropriate place. /// public static void ReadConfiguration() - { - Drive0Image = (string)Properties.Settings.Default["Drive0Image"]; - Drive1Image = (string)Properties.Settings.Default["Drive1Image"]; - SystemType = (SystemType)Properties.Settings.Default["SystemType"]; - HostAddress = (byte)Properties.Settings.Default["HostAddress"]; - HostPacketInterfaceName = (string)Properties.Settings.Default["HostPacketInterfaceName"]; - HostPacketInterfaceType = (PacketInterfaceType)Properties.Settings.Default["HostPacketInterfaceType"]; - AlternateBootType = (AlternateBootType)Properties.Settings.Default["AlternateBootType"]; - BootAddress = (ushort)Properties.Settings.Default["BootAddress"]; - BootFile = (ushort)Properties.Settings.Default["BootFile"]; - InterlaceDisplay = (bool)Properties.Settings.Default["InterlaceDisplay"]; - ThrottleSpeed = (bool)Properties.Settings.Default["ThrottleSpeed"]; - EnableAudioDAC = (bool)Properties.Settings.Default["EnableAudioDAC"]; - EnableAudioDACCapture = (bool)Properties.Settings.Default["EnableAudioDACCapture"]; - AudioDACCapturePath = (string)Properties.Settings.Default["AudioDACCapturePath"]; + { + if (Configuration.Platform == PlatformType.Windows + && Program.StartupArgs.Length == 0) + { + // + // By default, on Windows we use the app Settings functionality + // to store settings in the registry on a per-user basis. + // If a configuration file is specified, we will use it instead. + // + ReadConfigurationWindows(); + } + else + { + // + // On UNIX platforms we read in a configuration file. + // This is mostly because Mono's support for Properties.Settings + // is broken in inexplicable ways and I'm tired of fighting with it. + // + ReadConfigurationUnix(); + } } /// @@ -243,23 +247,221 @@ namespace Contralto /// public static void WriteConfiguration() { - Properties.Settings.Default["Drive0Image"] = Drive0Image; - Properties.Settings.Default["Drive1Image"] = Drive1Image; - Properties.Settings.Default["SystemType"] = (int)SystemType; - Properties.Settings.Default["HostAddress"] = HostAddress; - Properties.Settings.Default["HostPacketInterfaceName"] = HostPacketInterfaceName; - Properties.Settings.Default["HostPacketInterfaceType"] = (int)HostPacketInterfaceType; - Properties.Settings.Default["AlternateBootType"] = (int)AlternateBootType; - Properties.Settings.Default["BootAddress"] = BootAddress; - Properties.Settings.Default["BootFile"] = BootFile; - Properties.Settings.Default["InterlaceDisplay"] = InterlaceDisplay; - Properties.Settings.Default["ThrottleSpeed"] = ThrottleSpeed; - Properties.Settings.Default["EnableAudioDAC"] = EnableAudioDAC; - Properties.Settings.Default["EnableAudioDACCapture"] = EnableAudioDACCapture; - Properties.Settings.Default["AudioDACCapturePath"] = AudioDACCapturePath; + if (Configuration.Platform == PlatformType.Windows) + { + WriteConfigurationWindows(); + } + else + { + // + // At the moment the configuration files are read-only + // on UNIX platforms. + // + } + } + private static void ReadConfigurationWindows() + { + Properties.Settings.Default.AudioDACCapturePath = Properties.Settings.Default.AudioDACCapturePath; + Drive0Image = Properties.Settings.Default.Drive0Image; + Drive1Image = Properties.Settings.Default.Drive1Image; + SystemType = (SystemType)Properties.Settings.Default.SystemType; + HostAddress = Properties.Settings.Default.HostAddress; + HostPacketInterfaceName = Properties.Settings.Default.HostPacketInterfaceName; + HostPacketInterfaceType = (PacketInterfaceType)Properties.Settings.Default.HostPacketInterfaceType; + AlternateBootType = (AlternateBootType)Properties.Settings.Default.AlternateBootType; + BootAddress = Properties.Settings.Default.BootAddress; + BootFile = Properties.Settings.Default.BootFile; + InterlaceDisplay = Properties.Settings.Default.InterlaceDisplay; + ThrottleSpeed = Properties.Settings.Default.ThrottleSpeed; + EnableAudioDAC = Properties.Settings.Default.EnableAudioDAC; + EnableAudioDACCapture = Properties.Settings.Default.EnableAudioDACCapture; + AudioDACCapturePath = Properties.Settings.Default.AudioDACCapturePath; + } + + private static void WriteConfigurationWindows() + { + Properties.Settings.Default.Drive0Image = Drive0Image; + Properties.Settings.Default.Drive1Image = Drive1Image; + Properties.Settings.Default.SystemType = (int)SystemType; + Properties.Settings.Default.HostAddress = HostAddress; + Properties.Settings.Default.HostPacketInterfaceName = HostPacketInterfaceName; + Properties.Settings.Default.HostPacketInterfaceType = (int)HostPacketInterfaceType; + Properties.Settings.Default.AlternateBootType = (int)AlternateBootType; + Properties.Settings.Default.BootAddress = BootAddress; + Properties.Settings.Default.BootFile = BootFile; + Properties.Settings.Default.InterlaceDisplay = InterlaceDisplay; + Properties.Settings.Default.ThrottleSpeed = ThrottleSpeed; + Properties.Settings.Default.EnableAudioDAC = EnableAudioDAC; + Properties.Settings.Default.EnableAudioDACCapture = EnableAudioDACCapture; + Properties.Settings.Default.AudioDACCapturePath = AudioDACCapturePath; + Properties.Settings.Default.AudioDACCapturePath = Properties.Settings.Default.AudioDACCapturePath; Properties.Settings.Default.Save(); } + + private static void ReadConfigurationUnix() + { + string configFilePath = null; + + if (Program.StartupArgs.Length > 0) + { + configFilePath = Program.StartupArgs[0]; + } + else + { + // No config file specified, default. + configFilePath = "Contralto.cfg"; + } + + // + // Check that the configuration file exists. + // If not, we will warn the user and use default settings. + // + if (!File.Exists(configFilePath)) + { + Console.WriteLine("Configuration file {0} does not exist or cannot be accessed. Using default settings.", configFilePath); + return; + } + + using (StreamReader configStream = new StreamReader(configFilePath)) + { + // + // Config file consists of text lines containing name / value pairs: + // = + // Whitespace is ignored. + // + int lineNumber = 0; + while (!configStream.EndOfStream) + { + lineNumber++; + string line = configStream.ReadLine().Trim(); + + if (string.IsNullOrEmpty(line)) + { + // Empty line, ignore. + continue; + } + + if (line.StartsWith("#")) + { + // Comment to EOL, ignore. + continue; + } + + // Find the '=' separating tokens and ensure there are just two. + string[] tokens = line.Split(new char[] { '=' }, StringSplitOptions.RemoveEmptyEntries); + + if (tokens.Length < 2) + { + Console.WriteLine( + "{0} line {1}: Invalid syntax.", configFilePath, lineNumber); + continue; + } + + string parameter = tokens[0].Trim(); + string value = tokens[1].Trim(); + + // Reflect over the public, static properties in this class and see if the parameter matches one of them + // If not, it's an error, if it is then we attempt to coerce the value to the correct type. + System.Reflection.FieldInfo[] info = typeof(Configuration).GetFields(BindingFlags.Public | BindingFlags.Static); + + bool bMatch = false; + foreach (FieldInfo field in info) + { + // Case-insensitive compare. + if (field.Name.ToLowerInvariant() == parameter.ToLowerInvariant()) + { + bMatch = true; + + // + // Switch on the type of the field and attempt to convert the value to the appropriate type. + // At this time we support only strings and integers. + // + try + { + switch (field.FieldType.Name) + { + case "Int32": + { + int v = Convert.ToInt32(value, 8); + field.SetValue(null, v); + } + break; + + case "UInt16": + { + UInt16 v = Convert.ToUInt16(value, 8); + field.SetValue(null, v); + } + break; + + case "Byte": + { + byte v = Convert.ToByte(value, 8); + field.SetValue(null, v); + } + break; + + case "String": + { + field.SetValue(null, value); + } + break; + + case "Boolean": + { + bool v = bool.Parse(value); + field.SetValue(null, v); + } + break; + + case "SystemType": + { + field.SetValue(null, Enum.Parse(typeof(SystemType), value, true)); + } + break; + + case "PacketInterfaceType": + { + field.SetValue(null, Enum.Parse(typeof(PacketInterfaceType), value, true)); + } + break; + + case "AlternateBootType": + { + field.SetValue(null, Enum.Parse(typeof(AlternateBootType), value, true)); + } + break; + + case "LogType": + { + field.SetValue(null, Enum.Parse(typeof(LogType), value, true)); + } + break; + + case "LogComponent": + { + field.SetValue(null, Enum.Parse(typeof(LogComponent), value, true)); + } + break; + } + } + catch + { + Console.WriteLine( + "{0} line {1}: Value '{2}' is invalid for parameter '{3}'.", configFilePath, lineNumber, value, parameter); + } + } + } + + if (!bMatch) + { + Console.WriteLine( + "{0} line {1}: Unknown configuration parameter '{2}'.", configFilePath, lineNumber, parameter); + } + } + } + } } } diff --git a/Contralto/Contralto.cfg b/Contralto/Contralto.cfg new file mode 100644 index 0000000..c8f6bcb --- /dev/null +++ b/Contralto/Contralto.cfg @@ -0,0 +1,20 @@ +# contralto.cfg: +# +# This file contains configuration parameters for ContrAlto. +# All integers are specified in octal. +# + +# System configuration +SystemType = TwoKRom +HostAddress = 42 + +# Host networking configuration +HostPacketInterfaceType = None +HostPacketInterfaceName = None + +# Emulation Options +ThrottleSpeed = True +InterlaceDisplay = False +BootAddress = 0 +BootFile = 0 +AlternateBootType = Ethernet diff --git a/Contralto/Contralto.csproj b/Contralto/Contralto.csproj index 545c15f..843d199 100644 --- a/Contralto/Contralto.csproj +++ b/Contralto/Contralto.csproj @@ -46,6 +46,7 @@ TRACE prompt 4 + true true @@ -76,6 +77,7 @@ prompt MinimumRecommendedRules.ruleset true + false bin\x86\Release\ @@ -86,6 +88,7 @@ prompt MinimumRecommendedRules.ruleset true + false Alto.ico @@ -98,21 +101,28 @@ ..\packages\NAudio.1.8.0\lib\net35\NAudio.dll True - + False - pcap\PcapDotNet.Base.dll + ..\packages\Pcap.Net.x86.1.0.4.1\lib\net45\PcapDotNet.Base.dll + True - + False - pcap\PcapDotNet.Core.dll + ..\packages\Pcap.Net.x86.1.0.4.1\lib\net45\PcapDotNet.Core.dll + True - + False - pcap\PcapDotNet.Core.Extensions.dll + ..\packages\Pcap.Net.x86.1.0.4.1\lib\net45\PcapDotNet.Core.Extensions.dll + True - + False - pcap\PcapDotNet.Packets.dll + ..\packages\Pcap.Net.x86.1.0.4.1\lib\net45\PcapDotNet.Packets.dll + True + + + ..\packages\SDL2-CS.dll.2.0.0.0\lib\net20\SDL2-CS.dll @@ -143,6 +153,11 @@ True Settings.settings + + + + + Form @@ -215,6 +230,9 @@ + + PreserveNewest + Designer @@ -487,6 +505,9 @@ + + PreserveNewest + PreserveNewest diff --git a/Contralto/Display/IAltoDisplay.cs b/Contralto/Display/IAltoDisplay.cs index c66241c..34ee280 100644 --- a/Contralto/Display/IAltoDisplay.cs +++ b/Contralto/Display/IAltoDisplay.cs @@ -29,6 +29,12 @@ namespace Contralto.Display /// public interface IAltoDisplay { + /// + /// Attach the AltoSystem to this display instance. + /// + /// + void AttachSystem(AltoSystem system); + /// /// Renders a word's worth of data to the specified scanline and word offset. /// diff --git a/Contralto/IO/AudioDAC.cs b/Contralto/IO/AudioDAC.cs index 98eb0fb..4ac6256 100644 --- a/Contralto/IO/AudioDAC.cs +++ b/Contralto/IO/AudioDAC.cs @@ -82,8 +82,12 @@ namespace Contralto.IO /// public void Load(int address, ushort data, TaskType task, bool extendedMemory) { - if (Configuration.EnableAudioDAC) - { + // + // This is only supported on Windows platforms at this time. + // + if (Configuration.EnableAudioDAC && + Configuration.Platform == PlatformType.Windows) + { // Ensure we have a sink for audio output capture if so configured. if (Configuration.EnableAudioDACCapture && _waveFile == null) { diff --git a/Contralto/Program.cs b/Contralto/Program.cs index 873b1db..e552b55 100644 --- a/Contralto/Program.cs +++ b/Contralto/Program.cs @@ -16,6 +16,7 @@ */ using Contralto.IO; +using Contralto.SdlUI; using System; using System.Collections.Generic; using System.Windows.Forms; @@ -27,11 +28,22 @@ namespace Contralto [STAThread] static void Main(string[] args) { + // + // Check for command-line arguments. + // We expect at most one argument, specifying a configuration file to load. + // + StartupArgs = args; + if (args.Length > 1) + { + Console.WriteLine("usage: Contralto "); + return; + } + // Handle command-line args PrintHerald(); // See if WinPCap is installed and working - TestPCap(); + TestPCap(); _system = new AltoSystem(); @@ -69,13 +81,32 @@ namespace Contralto // // Invoke the main UI window; this will run until the user closes it, at which // point we are done. - // - using (AltoWindow mainWindow = new AltoWindow()) - { - mainWindow.AttachSystem(_system); - Application.Run(mainWindow); - } - } + // + + if (Configuration.Platform == PlatformType.Windows) + { + using (AltoWindow mainWindow = new AltoWindow()) + { + mainWindow.AttachSystem(_system); + Application.Run(mainWindow); + } + } + else + { + using (SdlAltoWindow mainWindow = new SdlAltoWindow()) + { + // Invoke the command-line console + SdlConsole console = new SdlConsole(_system); + console.Run(mainWindow); + + // Start the SDL display running. + mainWindow.AttachSystem(_system); + mainWindow.Run(); + } + } + } + + public static string[] StartupArgs; private static void OnProcessExit(object sender, EventArgs e) { @@ -86,6 +117,8 @@ namespace Contralto // _system.CommitDiskPack(0); _system.CommitDiskPack(1); + + _system.Shutdown(); // // Commit current configuration to disk @@ -96,25 +129,32 @@ namespace Contralto private static void PrintHerald() { - Console.WriteLine("ContrAlto v1.1 (c) 2015, 2016 Living Computers: Museum+Labs."); + Console.WriteLine("ContrAlto v1.2 (c) 2015-2017 Living Computers: Museum+Labs."); Console.WriteLine("Bug reports to joshd@livingcomputers.org"); Console.WriteLine(); } private static void TestPCap() { - // Just try enumerating interfaces, if this fails for any reason we assume - // PCap is not properly installed. - try + if (Configuration.Platform == PlatformType.Windows) { - List interfaces = EthernetInterface.EnumerateDevices(); - Configuration.HostRawEthernetInterfacesAvailable = true; + // Just try enumerating interfaces, if this fails for any reason we assume + // PCap is not properly installed. + try + { + List interfaces = EthernetInterface.EnumerateDevices(); + Configuration.HostRawEthernetInterfacesAvailable = true; + } + catch + { + Configuration.HostRawEthernetInterfacesAvailable = false; + } } - catch + else { - Configuration.HostRawEthernetInterfacesAvailable = false; + Configuration.HostRawEthernetInterfacesAvailable = false; } - } + } private static AltoSystem _system; } diff --git a/Contralto/Properties/AssemblyInfo.cs b/Contralto/Properties/AssemblyInfo.cs index 4c51d27..b342b51 100644 --- a/Contralto/Properties/AssemblyInfo.cs +++ b/Contralto/Properties/AssemblyInfo.cs @@ -10,7 +10,7 @@ using System.Runtime.InteropServices; [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("Living Computers: Museum+Labs")] [assembly: AssemblyProduct("ContrAlto")] -[assembly: AssemblyCopyright("Copyright © Living Computers: Museum+Labs 2016")] +[assembly: AssemblyCopyright("Copyright © Living Computers: Museum+Labs 2015-2017")] [assembly: AssemblyTrademark("")] [assembly: AssemblyCulture("")] @@ -32,5 +32,5 @@ using System.Runtime.InteropServices; // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] -[assembly: AssemblyVersion("1.1.1")] -[assembly: AssemblyFileVersion("1.1.0.0")] +[assembly: AssemblyVersion("1.2.0")] +[assembly: AssemblyFileVersion("1.2.0.0")] diff --git a/Contralto/SdlUI/ConsoleExecutor.cs b/Contralto/SdlUI/ConsoleExecutor.cs new file mode 100644 index 0000000..a996ad7 --- /dev/null +++ b/Contralto/SdlUI/ConsoleExecutor.cs @@ -0,0 +1,672 @@ +/* + This file is part of ContrAlto. + + ContrAlto is free software: you can redistribute it and/or modify + it under the terms of the GNU Affero General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + ContrAlto is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License + along with ContrAlto. If not, see . +*/ + +using System; +using System.Collections.Generic; +using System.Reflection; +using System.Text; +using System.IO; + +namespace Contralto.SdlUI +{ + /// + /// Defines a node in the debug command tree. + /// + public class DebuggerCommand + { + public DebuggerCommand(object instance, string name, String description, String usage, MethodInfo method) + { + Instance = instance; + Name = name.Trim().ToLower(); + Description = description; + Usage = usage; + Methods = new List(4); + + if (method != null) + { + Methods.Add(method); + } + + SubCommands = new List(); + } + + public object Instance; + public string Name; + public string Description; + public string Usage; + public List Methods; + public List SubCommands; + + public override string ToString() + { + if (this.Methods.Count == 0) + { + return String.Format("{0}... ({1})", this.Name, this.SubCommands.Count); + } + else + { + return this.Name; + } + } + + public void AddSubNode(List words, MethodInfo method, object instance) + { + // We should never hit this case. + if (words.Count == 0) + { + throw new InvalidOperationException("Out of words building command node."); + } + + // Check the root to see if a node for the first incoming word has already been added + DebuggerCommand subNode = FindSubNodeByName(words[0]); + + if (subNode == null) + { + // No, it has not -- create one and add it now. + subNode = new DebuggerCommand(instance, words[0], null, null, null); + this.SubCommands.Add(subNode); + + if (words.Count == 1) + { + // This is the last stop -- set the method and be done with it now. + subNode.Methods.Add(method); + + // early return. + return; + } + } + else + { + // The node already exists, we will be adding a subnode, hopefully. + if (words.Count == 1) + { + // + // If we're on the last word at this point then this is an overloaded command. + // Check that we don't have any other commands with this number of arguments. + // + int argCount = method.GetParameters().Length; + foreach (MethodInfo info in subNode.Methods) + { + if (info.GetParameters().Length == argCount) + { + throw new InvalidOperationException("Duplicate overload for console command"); + } + } + + // + // We're ok. Add it to the method list. + // + subNode.Methods.Add(method); + + // and return early. + return; + } + } + + // We have more words to go. + words.RemoveAt(0); + subNode.AddSubNode(words, method, instance); + } + + public DebuggerCommand FindSubNodeByName(string name) + { + DebuggerCommand found = null; + + foreach (DebuggerCommand sub in SubCommands) + { + if (sub.Name == name) + { + found = sub; + break; + } + } + + return found; + } + } + + public class ConsoleExecutor + { + public ConsoleExecutor(params object[] commandObjects) + { + List commandList = new List(commandObjects); + BuildCommandTree(commandList); + + _consolePrompt = new DebuggerPrompt(_commandRoot); + } + + public CommandResult Prompt() + { + CommandResult next = CommandResult.Normal; + try + { + // Get the command string from the prompt. + string command = _consolePrompt.Prompt().Trim(); + + if (command != String.Empty) + { + next = ExecuteLine(command); + } + } + catch (Exception e) + { + Console.WriteLine(e.Message); + } + + return next; + } + + public CommandResult ExecuteScript(string scriptFile) + { + CommandResult state = CommandResult.Normal; + + using (StreamReader sr = new StreamReader(scriptFile)) + { + while (!sr.EndOfStream) + { + string line = sr.ReadLine(); + + if (!string.IsNullOrWhiteSpace(line)) + { + Console.WriteLine(line); + state = ExecuteLine(line); + } + } + } + + return state; + } + + private CommandResult ExecuteLine(string line) + { + CommandResult next = CommandResult.Normal; + + if (line.StartsWith("#")) + { + // Comments start with "#", just ignore them + } + else if(line.StartsWith("@")) + { + // A line beginning with an "@" indicates a script to execute. + string scriptFile = line.Substring(1); + + next = ExecuteScript(scriptFile); + } + else + { + string[] args = null; + DebuggerCommand command = GetDebuggerCommandFromCommandString(line, out args); + + if (command == null) + { + // Not a command. + Console.WriteLine("Invalid command."); + } + else + { + next = InvokeConsoleMethod(command, args); + } + } + + return next; + } + + private CommandResult InvokeConsoleMethod(DebuggerCommand command, string[] args) + { + MethodInfo method = null; + + // + // Find the method that matches the arg count we were passed + // (i.e. handle overloaded commands). + // That this only matches on argument count is somewhat of a kluge... + // + foreach (MethodInfo m in command.Methods) + { + ParameterInfo[] paramInfo = m.GetParameters(); + + if (args == null && paramInfo.Length == 0 || + paramInfo.Length == args.Length) + { + // found a match + method = m; + break; + } + } + + if (method == null) + { + // invalid argument count. + throw new ArgumentException(String.Format("Invalid argument count to command.")); + } + + ParameterInfo[] parameterInfo = method.GetParameters(); + object[] invokeParams; + + if (args == null) + { + invokeParams = null; + } + else + { + invokeParams = new object[parameterInfo.Length]; + } + + int argIndex = 0; + for (int paramIndex = 0; paramIndex < parameterInfo.Length; paramIndex++) + { + ParameterInfo p = parameterInfo[paramIndex]; + + if (p.ParameterType.IsEnum) + { + // + // This is an enumeration type. + // See if we can find an enumerant that matches the argument. + // + FieldInfo[] fields = p.ParameterType.GetFields(); + + foreach (FieldInfo f in fields) + { + if (!f.IsSpecialName && args[argIndex].ToLower() == f.Name.ToLower()) + { + invokeParams[paramIndex] = f.GetRawConstantValue(); + break; + } + } + + if (invokeParams[paramIndex] == null) + { + // no match, provide possible values + StringBuilder sb = new StringBuilder(String.Format("Invalid value for parameter {0}. Possible values are:", paramIndex)); + + foreach (FieldInfo f in fields) + { + if (!f.IsSpecialName) + { + sb.AppendFormat("{0} ", f.Name); + } + } + + sb.AppendLine(); + + throw new ArgumentException(sb.ToString()); + } + + argIndex++; + + } + else if (p.ParameterType.IsArray) + { + // + // If a function takes an array type, i should do something here, yeah. + // + argIndex++; + } + else + { + if (p.ParameterType == typeof(bool)) + { + invokeParams[paramIndex] = bool.Parse(args[argIndex++]); + } + else if (p.ParameterType == typeof(uint)) + { + invokeParams[paramIndex] = TryParseUint(args[argIndex++]); + } + else if (p.ParameterType == typeof(ushort)) + { + invokeParams[paramIndex] = TryParseUshort(args[argIndex++]); + } + else if (p.ParameterType == typeof(string)) + { + invokeParams[paramIndex] = args[argIndex++]; + } + else if (p.ParameterType == typeof(char)) + { + invokeParams[paramIndex] = (char)args[argIndex++][0]; + } + else if (p.ParameterType == typeof(float)) + { + invokeParams[paramIndex] = float.Parse(args[argIndex++]); + } + else + { + throw new ArgumentException(String.Format("Unhandled type for parameter {0}, type {1}", paramIndex, p.ParameterType)); + } + } + } + + // + // If we've made it THIS far, then we were able to parse all the commands into what they should be. + // Invoke the method on the object instance associated with the command. + // + return (CommandResult)method.Invoke(command.Instance, invokeParams); + } + + enum ParseState + { + NonWhiteSpace = 0, + WhiteSpace = 1, + QuotedString = 2, + } + + private List SplitArgs(string commandString) + { + // We split on whitespace and specially handle quoted strings (quoted strings count as a single arg) + // + List args = new List(); + + commandString = commandString.Trim(); + + StringBuilder sb = new StringBuilder(); + + ParseState state = ParseState.NonWhiteSpace; + + foreach(char c in commandString) + { + switch (state) + { + case ParseState.NonWhiteSpace: + if (char.IsWhiteSpace(c)) + { + // End of token + args.Add(sb.ToString()); + sb.Clear(); + state = ParseState.WhiteSpace; + } + else if (c == '\"') + { + // Start of quoted string + state = ParseState.QuotedString; + } + else + { + // Character in token + sb.Append(c); + } + break; + + case ParseState.WhiteSpace: + if (!char.IsWhiteSpace(c)) + { + // Start of new token + if (c != '\"') + { + sb.Append(c); + state = ParseState.NonWhiteSpace; + } + else + { + // Start of quoted string + state = ParseState.QuotedString; + } + } + break; + + case ParseState.QuotedString: + if (c == '\"') + { + // End of quoted string. + args.Add(sb.ToString()); + sb.Clear(); + state = ParseState.WhiteSpace; + } + else + { + // Character in quoted string + sb.Append(c); + } + break; + } + } + + if (sb.Length > 0) + { + // Add the last token to the args list + args.Add(sb.ToString()); + } + + return args; + } + + private DebuggerCommand GetDebuggerCommandFromCommandString(string command, out string[] args) + { + args = null; + + List cmdArgs = SplitArgs(command); + + DebuggerCommand current = _commandRoot; + int commandIndex = 0; + + while (true) + { + // If this node has an executor and no subnodes, or if this node has an executor + // and there are no further arguments, then we're done. + if ((current.Methods.Count > 0 && current.SubCommands.Count == 0) || + (current.Methods.Count > 0 && commandIndex > cmdArgs.Count -1)) + { + break; + } + + if (commandIndex > cmdArgs.Count - 1) + { + // Out of args with no match. + return null; + } + + // Otherwise we continue down the tree. + DebuggerCommand next = current.FindSubNodeByName(cmdArgs[commandIndex]); + + commandIndex++; + + if (next == null) + { + // + // If a matching subcommand was not found, then if we had a previous node with an + // executor, use that; otherwise the command is invalid. + // + if (current.Methods.Count > 0) + { + break; + } + else + { + return null; + } + } + + current = next; + } + + // Now current should point to the command with the executor + // and commandIndex should point to the first argument to the command. + + cmdArgs.RemoveRange(0, commandIndex); + + args = cmdArgs.ToArray(); + return current; + } + + + private enum Radix + { + Binary = 2, + Octal = 8, + Decimal = 10, + Hexadecimal = 16, + } + + private static uint TryParseUint(string arg) + { + uint result = 0; + Radix radix = Radix.Decimal; + + switch (arg[0]) + { + case 'b': + radix = Radix.Binary; + arg = arg.Remove(0, 1); + break; + + case 'o': + radix = Radix.Octal; + arg = arg.Remove(0, 1); + break; + + case 'd': + radix = Radix.Decimal; + arg = arg.Remove(0, 1); + break; + + case 'x': + radix = Radix.Hexadecimal; + arg = arg.Remove(0, 1); + break; + + default: + radix = Radix.Octal; + break; + } + + try + { + result = Convert.ToUInt32(arg, (int)radix); + } + catch + { + Console.WriteLine("{0} is not a valid 32-bit value.", arg); + throw; + } + + return result; + } + + private static ushort TryParseUshort(string arg) + { + ushort result = 0; + Radix radix = Radix.Decimal; + + switch (arg[0]) + { + case 'b': + radix = Radix.Binary; + arg = arg.Remove(0, 1); + break; + + case 'o': + radix = Radix.Octal; + arg = arg.Remove(0, 1); + break; + + case 'd': + radix = Radix.Decimal; + arg = arg.Remove(0, 1); + break; + + case 'x': + radix = Radix.Hexadecimal; + arg = arg.Remove(0, 1); + break; + + default: + radix = Radix.Octal; + break; + } + + try + { + result = Convert.ToUInt16(arg, (int)radix); + } + catch + { + Console.WriteLine("{0} is not a valid 16-bit value.", arg); + throw; + } + + return result; + } + + /// + /// Builds the debugger command tree. + /// + private void BuildCommandTree(List commandObjects) + { + // Build the flat list which will be built into the tree, by walking + // the classes that provide the methods + _commandList = new List(); + + // Add ourself to the list + commandObjects.Add(this); + + foreach (object commandObject in commandObjects) + { + Type type = commandObject.GetType(); + foreach (MethodInfo info in type.GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic)) + { + object[] attribs = info.GetCustomAttributes(typeof(DebuggerFunction), true); + + if (attribs.Length > 1) + { + throw new InvalidOperationException(String.Format("More than one ConsoleFunction attribute set on {0}", info.Name)); + } + else if (attribs.Length == 1) + { + // we have a debugger attribute set on this method + // this cast should always succeed given that we're filtering for this type above. + DebuggerFunction function = (DebuggerFunction)attribs[0]; + + DebuggerCommand newCommand = new DebuggerCommand(commandObject, function.CommandName, function.Description, function.Usage, info); + + _commandList.Add(newCommand); + } + } + } + + // Now actually build the command tree from the above list! + _commandRoot = new DebuggerCommand(null, "Root", null, null, null); + + foreach (DebuggerCommand c in _commandList) + { + string[] commandWords = c.Name.Split(' '); + + // This is kind of ugly, we know that at this point every command built above have only + // one method. When building the tree, overloaded commands may end up with more than one. + _commandRoot.AddSubNode(new List(commandWords), c.Methods[0], c.Instance); + } + } + + [DebuggerFunction("show commands", "Shows debugger commands and their descriptions.")] + private CommandResult ShowCommands() + { + foreach (DebuggerCommand cmd in _commandList) + { + if (!string.IsNullOrEmpty(cmd.Usage)) + { + Console.WriteLine("{0} {2} - {1}", cmd.Name, cmd.Description, cmd.Usage); + } + else + { + Console.WriteLine("{0} - {1}", cmd.Name, cmd.Description); + } + } + + return CommandResult.Normal; + } + + private DebuggerPrompt _consolePrompt; + private DebuggerCommand _commandRoot; + private List _commandList; + } +} diff --git a/Contralto/SdlUI/DebuggerAttributes.cs b/Contralto/SdlUI/DebuggerAttributes.cs new file mode 100644 index 0000000..331f16e --- /dev/null +++ b/Contralto/SdlUI/DebuggerAttributes.cs @@ -0,0 +1,64 @@ +/* + This file is part of ContrAlto. + + ContrAlto is free software: you can redistribute it and/or modify + it under the terms of the GNU Affero General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + ContrAlto is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License + along with ContrAlto. If not, see . +*/ + + +using System; + +namespace Contralto.SdlUI + +{ + public class DebuggerFunction : Attribute + { + public DebuggerFunction(string commandName) + { + _commandName = commandName; + _usage = ""; + } + + public DebuggerFunction(string commandName, string description) + { + _commandName = commandName; + _description = description; + } + + public DebuggerFunction(string commandName, string description, string usage) + { + _commandName = commandName; + _description = description; + _usage = usage; + } + + public string CommandName + { + get { return _commandName; } + } + + public string Usage + { + get { return _usage; } + } + + public string Description + { + get { return _description; } + } + + private string _commandName; + private string _description; + private string _usage; + } +} diff --git a/Contralto/SdlUI/DebuggerPrompt.cs b/Contralto/SdlUI/DebuggerPrompt.cs new file mode 100644 index 0000000..4d96408 --- /dev/null +++ b/Contralto/SdlUI/DebuggerPrompt.cs @@ -0,0 +1,497 @@ +/* + This file is part of ContrAlto. + + ContrAlto is free software: you can redistribute it and/or modify + it under the terms of the GNU Affero General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + ContrAlto is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License + along with ContrAlto. If not, see . +*/ + + +using System; +using System.Collections.Generic; +using System.Text; + +namespace Contralto.SdlUI +{ + public class DebuggerPrompt + { + + public DebuggerPrompt(DebuggerCommand root) + { + _commandTree = root; + _commandHistory = new List(64); + _historyIndex = 0; + } + + /// + /// Runs a nifty interactive debugger prompt. + /// + public string Prompt() + { + DisplayPrompt(); + ClearInput(); + UpdateOrigin(); + + bool entryDone = false; + + while (!entryDone) + { + UpdateDisplay(); + + // Read one keystroke from the console... + ConsoleKeyInfo key = Console.ReadKey(true); + + //Parse special chars... + switch (key.Key) + { + case ConsoleKey.Escape: //Clear input + ClearInput(); + break; + + case ConsoleKey.Backspace: // Delete last char + DeleteCharAtCursor(true /* backspace */); + break; + + case ConsoleKey.Delete: //Delete character at cursor + DeleteCharAtCursor(false /* delete */); + break; + + case ConsoleKey.LeftArrow: + MoveLeft(); + break; + + case ConsoleKey.RightArrow: + MoveRight(); + break; + + case ConsoleKey.UpArrow: + HistoryPrev(); + break; + + case ConsoleKey.DownArrow: + HistoryNext(); + break; + + case ConsoleKey.Home: + MoveToBeginning(); + break; + + case ConsoleKey.End: + MoveToEnd(); + break; + + case ConsoleKey.Tab: + DoCompletion(false /* silent */); + break; + + case ConsoleKey.Enter: + DoCompletion(true /* silent */); + UpdateDisplay(); + CRLF(); + entryDone = true; + break; + + case ConsoleKey.Spacebar: + if (!_input.EndsWith(" ") && + DoCompletion(true /* silent */)) + { + UpdateDisplay(); + } + else + { + InsertChar(key.KeyChar); + } + break; + + default: + // Not a special key, just insert it if it's deemed printable. + if (char.IsLetterOrDigit(key.KeyChar) || + char.IsPunctuation(key.KeyChar) || + char.IsSymbol(key.KeyChar) || + char.IsWhiteSpace(key.KeyChar)) + { + InsertChar(key.KeyChar); + } + break; + + } + } + + // Done. Add to history if input is non-empty + if (_input != string.Empty) + { + _commandHistory.Add(_input); + HistoryIndex = _commandHistory.Count - 1; + } + + return _input; + } + + private void DeleteCharAtCursor(bool backspace) + { + if (_input.Length == 0) + { + //nothing to delete, bail. + return; + } + + if (backspace) + { + if (TextPosition == 0) + { + // We's at the beginning of the input, + // can't backspace from here. + return; + } + else + { + // remove 1 char at the position before the cursor. + // and move the cursor back one char + _input = _input.Remove(TextPosition - 1, 1); + + TextPosition--; + } + } + else + { + if (TextPosition == _input.Length) + { + // At the end of input, can't delete a char from here + return; + } + else + { + // remove one char at the current cursor pos. + // do not move the cursor + _input = _input.Remove(TextPosition, 1); + } + } + } + + private void DisplayPrompt() + { + Console.Write(">"); + } + + private void UpdateDisplay() + { + //if the current input string is shorter than the last, then we need to erase a few chars at the end. + string clear = String.Empty; + + if (_input.Length < _lastInputLength) + { + StringBuilder sb = new StringBuilder(_lastInputLength - _input.Length); + for (int i = 0; i < _lastInputLength - _input.Length; i++) + { + sb.Append(' '); + } + + clear = sb.ToString(); + } + + int column = ((_textPosition + _originColumn) % Console.BufferWidth); + int row = ((_textPosition + _originColumn) / Console.BufferWidth) + _originRow; + + // Move cursor to origin to draw string + Console.CursorLeft = _originColumn; + Console.CursorTop = _originRow; + Console.Write(_input + clear); + + // Move cursor to text position to draw cursor + Console.CursorLeft = column; + Console.CursorTop = row; + Console.CursorVisible = true; + + _lastInputLength = _input.Length; + } + + private void MoveLeft() + { + TextPosition--; + } + + private void MoveRight() + { + TextPosition++; + } + + private void HistoryPrev() + { + if (HistoryIndex < _commandHistory.Count) + { + _input = _commandHistory[HistoryIndex]; + TextPosition = _input.Length; + HistoryIndex--; + } + } + + private void HistoryNext() + { + if (HistoryIndex < _commandHistory.Count) + { + HistoryIndex++; + _input = _commandHistory[HistoryIndex]; + TextPosition = _input.Length; + } + else + { + _input = String.Empty; + } + } + + private void MoveToBeginning() + { + TextPosition = 0; + } + + private void MoveToEnd() + { + TextPosition = _input.Length; + } + + private void ClearInput() + { + _input = String.Empty; + HistoryIndex = _commandHistory.Count - 1; + TextPosition = 0; + } + + private void InsertChar(char c) + { + _input = _input.Insert(TextPosition, c.ToString()); + TextPosition++; + } + + private void CRLF() + { + Console.WriteLine(); + } + + private bool DoCompletion(bool silent) + { + // This code should probably move to another class, but hey, I'm lazy. + + // Take the current input and see if it matches anything in the command tree + string[] tokens = _input.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries); + + // Save off the current cursor row; this is an ugly-ish hack to detect whether the match process + // output anything. If the cursor row changes then we'll need to move the prompt + int oldRow = Console.CursorTop; + + string matchString = FuzzyMatch(_commandTree, new List(tokens), silent); + + bool changed = false; + + if (matchString != String.Empty) + { + changed = _input.Trim().ToLower() != matchString.Trim().ToLower(); + + _input = matchString; + TextPosition = _input.Length; + } + + if (!silent && oldRow != Console.CursorTop) + { + DisplayPrompt(); + UpdateOrigin(); + } + + return changed; + } + + private string FuzzyMatch(DebuggerCommand root, List tokens, bool silent) + { + if (tokens.Count == 0) + { + if (!silent) + { + // If there are no tokens, just show the completion for the root. + PrintCompletions(root.SubCommands); + } + return String.Empty; + } + + DebuggerCommand match = null; + + // Search for exact matches. If we find one it's guaranteed to be unique + // so we can follow that node. + foreach (DebuggerCommand c in root.SubCommands) + { + if (c.Name.ToLower() == tokens[0].ToLower()) + { + match = c; + break; + } + } + + if (match == null) + { + // No exact match. Try a substring match. + // If we have an unambiguous match then we can complete it automatically. + // If the match is ambiguous, display possible completions and return String.Empty. + List completions = new List(); + + foreach (DebuggerCommand c in root.SubCommands) + { + if (c.Name.StartsWith(tokens[0], StringComparison.InvariantCultureIgnoreCase)) + { + completions.Add(c); + } + } + + if (completions.Count == 1) + { + // unambiguous match. use it. + match = completions[0]; + } + else if (completions.Count > 1) + { + // ambiguous match. display possible completions. + if (!silent) + { + PrintCompletions(completions); + } + } + } + + if (match == null) + { + // If we reach this point then no matches are available. return the tokens we have... + StringBuilder sb = new StringBuilder(); + for (int i = 0; i < tokens.Count; i++) + { + if (i < tokens.Count - 1) + { + sb.AppendFormat("{0} ", tokens[i]); + } + else + { + sb.AppendFormat("{0}", tokens[i]); + } + } + + return sb.ToString(); + } + else + { + // A match was found + tokens.RemoveAt(0); + + string subMatch = String.Empty; + + if (tokens.Count > 0) + { + subMatch = FuzzyMatch(match, tokens, silent); + } + else // if (exactMatch) + { + if (!silent && match.SubCommands.Count > 1) + { + // More than one possible completion + // Just show the completions for this node. + PrintCompletions(match.SubCommands); + } + else if(!silent && match.SubCommands.Count == 1) + { + // Just one possible completion; fill it out. + DebuggerCommand next = match.SubCommands[0]; + StringBuilder sb = + new StringBuilder(String.Format("{0} {1}", match.Name, next.Name)); + + while(next.SubCommands.Count > 0) + { + if (next.SubCommands.Count > 1) + { + break; + } + + next = next.SubCommands[0]; + sb.AppendFormat(" {0}", next.Name); + } + + return sb.ToString(); + } + } + + if (subMatch == String.Empty) + { + return String.Format("{0} ", match.Name); + } + else + { + return String.Format("{0} {1}", match.Name, subMatch); + } + } + } + + private void PrintCompletions(List completions) + { + // Just print all available completions at this node + Console.WriteLine(); + Console.WriteLine("Possible completions are:"); + foreach (DebuggerCommand c in completions) + { + Console.Write("{0}\t", c); + } + Console.WriteLine(); + } + + private void UpdateOrigin() + { + _originRow = Console.CursorTop; + _originColumn = Console.CursorLeft; + } + + private int TextPosition + { + get + { + return _textPosition; + } + + set + { + // Clip input between 0 and the length of input (+1, to allow adding text at end) + _textPosition = Math.Max(0, value); + _textPosition = Math.Min(_textPosition, _input.Length); + } + } + + private int HistoryIndex + { + get + { + return _historyIndex; + } + + set + { + _historyIndex = Math.Min(_commandHistory.Count - 1, value); + _historyIndex = Math.Max(0, _historyIndex); + + } + } + + private DebuggerCommand _commandTree; + + + private int _originRow; + private int _originColumn; + + private string _input; + private int _textPosition; + private int _lastInputLength; + + private List _commandHistory; + private int _historyIndex; + } +} diff --git a/Contralto/SdlUI/SdlAltoWindow.cs b/Contralto/SdlUI/SdlAltoWindow.cs new file mode 100644 index 0000000..25ae93a --- /dev/null +++ b/Contralto/SdlUI/SdlAltoWindow.cs @@ -0,0 +1,628 @@ +/* + This file is part of ContrAlto. + + ContrAlto is free software: you can redistribute it and/or modify + it under the terms of the GNU Affero General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + ContrAlto is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License + along with ContrAlto. If not, see . +*/ + + +using System; +using System.Runtime.InteropServices; +using System.Collections.Generic; + +using SDL2; +using Contralto.Display; +using Contralto.IO; + +namespace Contralto.SdlUI +{ + /// + /// AltoWindow provides a wrapper around SDL2-CS, which is in itself an incredibly thin + /// wrapper around SDL 2.0. It presents a window capable of displaying the Alto's video + /// and handles keyboard and mouse input. + /// + /// This is intended for use on non-Windows platforms but will work on Windows as well. + /// + public class SdlAltoWindow : IAltoDisplay, IDisposable + { + public SdlAltoWindow() + { + InitKeymap(); + } + + public event EventHandler OnClosed; + + public void Dispose() + { + + } + + public void AttachSystem(AltoSystem system) + { + _system = system; + _system.AttachDisplay(this); + } + + public void Run() + { + InitSDL(); + + SDL.SDL_Event e; + bool running = true; + + while(running) + { + // + // Run main message loop + // + while (SDL.SDL_PollEvent(out e) != 0) + { + switch(e.type) + { + case SDL.SDL_EventType.SDL_QUIT: + running = false; + OnClosed(null, null); + break; + + case SDL.SDL_EventType.SDL_USEREVENT: + // This should always be the case since we only define one + // user event, but just to be truly pedantic... + if (e.user.type == _renderEventType) + { + RenderDisplay(); + } + break; + + case SDL.SDL_EventType.SDL_MOUSEMOTION: + MouseMove(e.motion.x, e.motion.y); + break; + + case SDL.SDL_EventType.SDL_MOUSEBUTTONDOWN: + MouseDown(e.button.button, e.button.x, e.button.y); + break; + + case SDL.SDL_EventType.SDL_MOUSEBUTTONUP: + MouseUp(e.button.button); + break; + + case SDL.SDL_EventType.SDL_KEYDOWN: + KeyDown(e.key.keysym.sym); + break; + + case SDL.SDL_EventType.SDL_KEYUP: + KeyUp(e.key.keysym.sym); + break; + + default: + break; + } + } + + SDL.SDL_Delay(0); + } + + // + // Shut things down nicely. + // + if (_sdlRenderer != IntPtr.Zero) + { + SDL.SDL_DestroyRenderer(_sdlRenderer); + _sdlRenderer = IntPtr.Zero; + } + + if (_sdlWindow != IntPtr.Zero) + { + SDL.SDL_DestroyWindow(_sdlWindow); + _sdlWindow = IntPtr.Zero; + } + + SDL.SDL_Quit(); + } + + public void Close() + { + SDL.SDL_Event closeEvent = new SDL.SDL_Event(); + closeEvent.type = SDL.SDL_EventType.SDL_QUIT; + + SDL.SDL_PushEvent(ref closeEvent); + } + + public void DrawDisplayWord(int scanline, int wordOffset, ushort word, bool lowRes) + { + if (lowRes) + { + // Low resolution; double up pixels. + int address = scanline * 76 + wordOffset * 4; + + if (address > _1bppDisplayBuffer.Length) + { + throw new InvalidOperationException("Display word address is out of bounds."); + } + + UInt32 stretched = StretchWord(word); + + _1bppDisplayBuffer[address] = (byte)(stretched >> 24); + _1bppDisplayBuffer[address + 1] = (byte)(stretched >> 16); + _1bppDisplayBuffer[address + 2] = (byte)(stretched >> 8); + _1bppDisplayBuffer[address + 3] = (byte)(stretched); + } + else + { + int address = scanline * 76 + wordOffset * 2; + + if (address > _1bppDisplayBuffer.Length) + { + throw new InvalidOperationException("Display word address is out of bounds."); + } + + _1bppDisplayBuffer[address] = (byte)(word >> 8); + _1bppDisplayBuffer[address + 1] = (byte)(word); + } + + } + + /// + /// Invoked by the DisplayController to draw the cursor at the specified position on the given + /// scanline. + /// + /// The scanline (Y) + /// X offset (in pixels) + /// The word to be drawn + public void DrawCursorWord(int scanline, int xOffset, bool whiteOnBlack, ushort cursorWord) + { + + int address = scanline * 76 + xOffset / 8; + + // + // Grab the 32 bits straddling the cursor from the display buffer + // so we can merge the 16 cursor bits in. + // + UInt32 displayWord = (UInt32)((_1bppDisplayBuffer[address] << 24) | + (_1bppDisplayBuffer[address + 1] << 16) | + (_1bppDisplayBuffer[address + 2] << 8) | + _1bppDisplayBuffer[address + 3]); + + // Slide the cursor word to the proper X position + UInt32 adjustedCursorWord = (UInt32)(cursorWord << (16 - (xOffset % 8))); + + if (!whiteOnBlack) + { + displayWord &= ~adjustedCursorWord; + } + else + { + displayWord |= adjustedCursorWord; + } + + _1bppDisplayBuffer[address] = (byte)(displayWord >> 24); + _1bppDisplayBuffer[address + 1] = (byte)(displayWord >> 16); + _1bppDisplayBuffer[address + 2] = (byte)(displayWord >> 8); + _1bppDisplayBuffer[address + 3] = (byte)(displayWord); + + } + + /// + /// "Stretches" a 16 bit word into a 32-bit word (for low-res display purposes). + /// + /// + /// + private UInt32 StretchWord(ushort word) + { + UInt32 stretched = 0; + + for (int i = 0x8000, j = 15; j >= 0; i = i >> 1, j--) + { + uint bit = (uint)(word & i) >> j; + + stretched |= (bit << (j * 2 + 1)); + stretched |= (bit << (j * 2)); + } + + return stretched; + } + + /// + /// Transmogrify 1bpp display buffer to 32-bits. + /// + private void ExpandBitmapToARGB() + { + int rgbIndex = 0; + + for (int i = 0; i < _32bppDisplayBuffer.Length / 8; i++) + { + byte b = _1bppDisplayBuffer[i]; + for (int bit = 7; bit >= 0; bit--) + { + byte color = (byte)((b & (1 << bit)) == 0 ? 0x00 : 0xff); + + _32bppDisplayBuffer[rgbIndex++] = (int)((color == 0) ? 0xff000000 : 0xffffffff); + } + } + } + + /// + /// Invoked when the Alto is done with a field. Tells SDL to redraw the Alto display. + /// This is called on the Alto emulation thread. + /// + public void Render() + { + // + // Send a render event to the SDL message loop so that things + // will get rendered. + // + SDL.SDL_PushEvent(ref _renderEvent); + } + + private void RenderDisplay() + { + // + // Stuff the display data into the display texture + // + ExpandBitmapToARGB(); + + IntPtr textureBits = IntPtr.Zero; + int pitch = 0; + SDL.SDL_LockTexture(_displayTexture, IntPtr.Zero, out textureBits, out pitch); + + Marshal.Copy(_32bppDisplayBuffer, 0, textureBits, _32bppDisplayBuffer.Length); + + SDL.SDL_UnlockTexture(_displayTexture); + + // + // Render the display texture to the renderer + // + SDL.SDL_RenderCopy(_sdlRenderer, _displayTexture, IntPtr.Zero, IntPtr.Zero); + + // + // And show it to us. + // + SDL.SDL_RenderPresent(_sdlRenderer); + } + + private void MouseMove(int x, int y) + { + if (!_mouseCaptured) + { + return; + } + + if (_skipNextMouseMove) + { + _skipNextMouseMove = false; + return; + } + + // + // As with the Winforms mouse capture code... + + int mx = _windowWidth / 2; + int my = _windowHeight / 2; + + int dx = x - mx; + int dy = y - my; + + if (dx != 0 || dy != 0) + { + _system.Mouse.MouseMove(dx, dy); + + // Don't handle the very next Mouse Move event (which will just be the motion we caused in the + // below line...) + _skipNextMouseMove = true; + + // + // Move the mouse pointer to the middle of the window. + // + SDL.SDL_WarpMouseInWindow(_sdlWindow, mx, my); + } + } + + private void KeyDown(SDL.SDL_Keycode code) + { + if (!_mouseCaptured) + { + return; + } + + if (_keyMap.ContainsKey(code)) + { + _system.Keyboard.KeyDown(_keyMap[code]); + } + } + + private void KeyUp(SDL.SDL_Keycode code) + { + // + // Check for Alt key to release mouse + // + if (code == SDL.SDL_Keycode.SDLK_LALT || + code == SDL.SDL_Keycode.SDLK_RALT) + { + ReleaseMouse(); + } + + if (!_mouseCaptured) + { + return; + } + + if (_keyMap.ContainsKey(code)) + { + _system.Keyboard.KeyUp(_keyMap[code]); + } + } + + private void MouseDown(byte button, int x, int y) + { + // + // OS X issue: we get mousedown events when the window title + // is clicked, sometimes. So ignore those. + // + if (x < 0 || y < 0) + { + return; + } + + if (!_mouseCaptured) + { + CaptureMouse(); + } + + AltoMouseButton altoButton = GetMouseButton(button); + + if (altoButton != AltoMouseButton.None) + { + _system.Mouse.MouseDown(altoButton); + } + } + + private void MouseUp(byte button) + { + if (!_mouseCaptured) + { + return; + } + + AltoMouseButton altoButton = GetMouseButton(button); + + if (altoButton != AltoMouseButton.None) + { + _system.Mouse.MouseUp(altoButton); + } + } + + private void CaptureMouse() + { + // + // Turn off the mouse cursor and ensure the mouse is trapped + // within our window. + // + _mouseCaptured = true; + SDL.SDL_ShowCursor(0); + SDL.SDL_SetWindowGrab(_sdlWindow, SDL.SDL_bool.SDL_TRUE); + + UpdateWindowTitle(); + } + + private void ReleaseMouse() + { + // + // Turn the mouse cursor back on, and release the mouse. + // + _mouseCaptured = false; + SDL.SDL_ShowCursor(1); + SDL.SDL_SetWindowGrab(_sdlWindow, SDL.SDL_bool.SDL_FALSE); + + UpdateWindowTitle(); + } + + private void UpdateWindowTitle() + { + SDL.SDL_SetWindowTitle( + _sdlWindow, + String.Format("ContrAlto{0}", + _mouseCaptured ? " - Mouse captured. Press 'Alt' to release." : "")); + } + + private void InitSDL() + { + int retVal; + + // Get SDL humming + if ((retVal = SDL.SDL_Init(SDL.SDL_INIT_VIDEO)) < 0) + { + throw new InvalidOperationException(String.Format("SDL_Init failed. Error {0:x}", retVal)); + } + + // + if (SDL.SDL_SetHint(SDL.SDL_HINT_RENDER_SCALE_QUALITY, "1") == SDL.SDL_bool.SDL_FALSE) + { + throw new InvalidOperationException("SDL_SetHint failed to set scale quality."); + } + + _sdlWindow = SDL.SDL_CreateWindow( + "ContrAlto", + SDL.SDL_WINDOWPOS_UNDEFINED, + SDL.SDL_WINDOWPOS_UNDEFINED, + _windowWidth, + _windowHeight, + SDL.SDL_WindowFlags.SDL_WINDOW_SHOWN); + if (_sdlWindow == IntPtr.Zero) + { + throw new InvalidOperationException("SDL_CreateWindow failed."); + } + + _sdlRenderer = SDL.SDL_CreateRenderer(_sdlWindow, -1, SDL.SDL_RendererFlags.SDL_RENDERER_ACCELERATED); + if (_sdlRenderer == IntPtr.Zero) + { + throw new InvalidOperationException("SDL_CreateRenderer failed."); + } + + _displayTexture = SDL.SDL_CreateTexture( + _sdlRenderer, + SDL.SDL_PIXELFORMAT_ARGB8888, + (int)SDL.SDL_TextureAccess.SDL_TEXTUREACCESS_STREAMING, + 608, + _windowHeight); + + if (_displayTexture == IntPtr.Zero) + { + throw new InvalidOperationException("SDL_CreateTexture failed."); + } + + SDL.SDL_SetRenderDrawColor(_sdlRenderer, 0x00, 0x00, 0x00, 0x00); + + // Register a User event for rendering. + _renderEventType = SDL.SDL_RegisterEvents(1); + _renderEvent = new SDL.SDL_Event(); + _renderEvent.type = (SDL.SDL_EventType)_renderEventType; + } + + private void InitKeymap() + { + _keyMap = new Dictionary(); + + _keyMap.Add(SDL.SDL_Keycode.SDLK_a, AltoKey.A); + _keyMap.Add(SDL.SDL_Keycode.SDLK_b, AltoKey.B); + _keyMap.Add(SDL.SDL_Keycode.SDLK_c, AltoKey.C); + _keyMap.Add(SDL.SDL_Keycode.SDLK_d, AltoKey.D); + _keyMap.Add(SDL.SDL_Keycode.SDLK_e, AltoKey.E); + _keyMap.Add(SDL.SDL_Keycode.SDLK_f, AltoKey.F); + _keyMap.Add(SDL.SDL_Keycode.SDLK_g, AltoKey.G); + _keyMap.Add(SDL.SDL_Keycode.SDLK_h, AltoKey.H); + _keyMap.Add(SDL.SDL_Keycode.SDLK_i, AltoKey.I); + _keyMap.Add(SDL.SDL_Keycode.SDLK_j, AltoKey.J); + _keyMap.Add(SDL.SDL_Keycode.SDLK_k, AltoKey.K); + _keyMap.Add(SDL.SDL_Keycode.SDLK_l, AltoKey.L); + _keyMap.Add(SDL.SDL_Keycode.SDLK_m, AltoKey.M); + _keyMap.Add(SDL.SDL_Keycode.SDLK_n, AltoKey.N); + _keyMap.Add(SDL.SDL_Keycode.SDLK_o, AltoKey.O); + _keyMap.Add(SDL.SDL_Keycode.SDLK_p, AltoKey.P); + _keyMap.Add(SDL.SDL_Keycode.SDLK_q, AltoKey.Q); + _keyMap.Add(SDL.SDL_Keycode.SDLK_r, AltoKey.R); + _keyMap.Add(SDL.SDL_Keycode.SDLK_s, AltoKey.S); + _keyMap.Add(SDL.SDL_Keycode.SDLK_t, AltoKey.T); + _keyMap.Add(SDL.SDL_Keycode.SDLK_u, AltoKey.U); + _keyMap.Add(SDL.SDL_Keycode.SDLK_v, AltoKey.V); + _keyMap.Add(SDL.SDL_Keycode.SDLK_w, AltoKey.W); + _keyMap.Add(SDL.SDL_Keycode.SDLK_x, AltoKey.X); + _keyMap.Add(SDL.SDL_Keycode.SDLK_y, AltoKey.Y); + _keyMap.Add(SDL.SDL_Keycode.SDLK_z, AltoKey.Z); + + _keyMap.Add(SDL.SDL_Keycode.SDLK_0, AltoKey.D0); + _keyMap.Add(SDL.SDL_Keycode.SDLK_1, AltoKey.D1); + _keyMap.Add(SDL.SDL_Keycode.SDLK_2, AltoKey.D2); + _keyMap.Add(SDL.SDL_Keycode.SDLK_3, AltoKey.D3); + _keyMap.Add(SDL.SDL_Keycode.SDLK_4, AltoKey.D4); + _keyMap.Add(SDL.SDL_Keycode.SDLK_5, AltoKey.D5); + _keyMap.Add(SDL.SDL_Keycode.SDLK_6, AltoKey.D6); + _keyMap.Add(SDL.SDL_Keycode.SDLK_7, AltoKey.D7); + _keyMap.Add(SDL.SDL_Keycode.SDLK_8, AltoKey.D8); + _keyMap.Add(SDL.SDL_Keycode.SDLK_9, AltoKey.D9); + + _keyMap.Add(SDL.SDL_Keycode.SDLK_SPACE, AltoKey.Space); + _keyMap.Add(SDL.SDL_Keycode.SDLK_PERIOD, AltoKey.Period); + _keyMap.Add(SDL.SDL_Keycode.SDLK_COMMA, AltoKey.Comma); + _keyMap.Add(SDL.SDL_Keycode.SDLK_QUOTE, AltoKey.Quote); + _keyMap.Add(SDL.SDL_Keycode.SDLK_BACKSLASH, AltoKey.BSlash); + _keyMap.Add(SDL.SDL_Keycode.SDLK_SLASH, AltoKey.FSlash); + _keyMap.Add(SDL.SDL_Keycode.SDLK_EQUALS, AltoKey.Plus); + _keyMap.Add(SDL.SDL_Keycode.SDLK_UNDERSCORE, AltoKey.Minus); + + _keyMap.Add(SDL.SDL_Keycode.SDLK_ESCAPE, AltoKey.ESC); + _keyMap.Add(SDL.SDL_Keycode.SDLK_DELETE, AltoKey.DEL); + _keyMap.Add(SDL.SDL_Keycode.SDLK_LEFT, AltoKey.Arrow); + _keyMap.Add(SDL.SDL_Keycode.SDLK_LSHIFT, AltoKey.LShift); + _keyMap.Add(SDL.SDL_Keycode.SDLK_RSHIFT, AltoKey.RShift); + _keyMap.Add(SDL.SDL_Keycode.SDLK_LCTRL, AltoKey.CTRL); + _keyMap.Add(SDL.SDL_Keycode.SDLK_RCTRL, AltoKey.CTRL); + _keyMap.Add(SDL.SDL_Keycode.SDLK_RETURN, AltoKey.Return); + _keyMap.Add(SDL.SDL_Keycode.SDLK_F1, AltoKey.BlankTop); + _keyMap.Add(SDL.SDL_Keycode.SDLK_F2, AltoKey.BlankMiddle); + _keyMap.Add(SDL.SDL_Keycode.SDLK_F3, AltoKey.BlankBottom); + _keyMap.Add(SDL.SDL_Keycode.SDLK_F4, AltoKey.Lock); + _keyMap.Add(SDL.SDL_Keycode.SDLK_BACKSPACE, AltoKey.BS); + _keyMap.Add(SDL.SDL_Keycode.SDLK_TAB, AltoKey.TAB); + + _keyMap.Add(SDL.SDL_Keycode.SDLK_SEMICOLON, AltoKey.Semicolon); + _keyMap.Add(SDL.SDL_Keycode.SDLK_LEFTBRACKET, AltoKey.LBracket); + _keyMap.Add(SDL.SDL_Keycode.SDLK_RIGHTBRACKET, AltoKey.RBracket); + _keyMap.Add(SDL.SDL_Keycode.SDLK_DOWN, AltoKey.LF); + } + + private static AltoMouseButton GetMouseButton(byte button) + { + AltoMouseButton altoButton = AltoMouseButton.None; + + switch (button) + { + case 1: + altoButton = AltoMouseButton.Left; + break; + + case 2: + altoButton = AltoMouseButton.Middle; + break; + + case 3: + altoButton = AltoMouseButton.Right; + break; + } + + return altoButton; + } + + private AltoSystem _system; + + private IntPtr _sdlWindow = IntPtr.Zero; + private IntPtr _sdlRenderer = IntPtr.Zero; + + private UInt32 _renderEventType; + private SDL.SDL_Event _renderEvent; + + + // + // Display data + // + private const int _windowWidth = 608; + private const int _windowHeight = 808; + + // Rendering textures + private IntPtr _displayTexture = IntPtr.Zero; + + // + // Buffer for display pixels. This is 1bpp, directly written by the Alto. + // + private byte[] _1bppDisplayBuffer = new byte[808 * 76 + 4]; // + 4 (32-bits) to make cursor display logic simpler. + // and 608 pixels wide to make it a multiple of 8 bits. + + // + // Buffer for rendering pixels. SDL doesn't support 1bpp pixel formats, so to keep things simple we use + // an array of ints and a 32bpp format. What's a few extra bits between friends. + // + private int[] _32bppDisplayBuffer = new int[(808 * 608 + 8)]; // + 8 (32-bits) as above. + // and 608 pixels wide as above. + + + // + // Keyboard data + // + private Dictionary _keyMap; + + // + // Mouse data + // + private bool _mouseCaptured; + private bool _skipNextMouseMove; + + } +} diff --git a/Contralto/SdlUI/SdlConsole.cs b/Contralto/SdlUI/SdlConsole.cs new file mode 100644 index 0000000..1fd1af8 --- /dev/null +++ b/Contralto/SdlUI/SdlConsole.cs @@ -0,0 +1,369 @@ +/* + This file is part of ContrAlto. + + ContrAlto is free software: you can redistribute it and/or modify + it under the terms of the GNU Affero General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + ContrAlto is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License + along with ContrAlto. If not, see . +*/ + +using System; +using System.Threading; + +namespace Contralto.SdlUI +{ + public enum CommandResult + { + Normal, + Quit + } + + /// + /// Provides a command-line interface to ContrAlto controls, + /// as a substitute for the GUI interface of the Windows version. + /// + public class SdlConsole + { + public SdlConsole(AltoSystem system) + { + _system = system; + + _controller = new ExecutionController(_system); + _controller.ErrorCallback += OnExecutionError; + } + + + /// + /// Invoke the CLI loop in a separate thread. + /// + public void Run(SdlAltoWindow mainWindow) + { + Console.WriteLine("You are at the ContrAlto console. Type 'show commands' to see"); + Console.WriteLine("a list of possible commands, and hit Tab to see possible command completions."); + + _mainWindow = mainWindow; + _mainWindow.OnClosed += OnMainWindowClosed; + + _cliThread = new Thread(RunCliThread); + _cliThread.Start(); + } + + /// + /// The CLI thread + /// + private void RunCliThread() + { + ConsoleExecutor executor = new ConsoleExecutor(this); + CommandResult state = CommandResult.Normal; + + while (state != CommandResult.Quit) + { + state = executor.Prompt(); + } + + // + // Ensure the emulator is stopped. + // + _controller.StopExecution(); + + // + // Ensure the main window is closed. + // + _mainWindow.Close(); + } + + private void OnMainWindowClosed(object sender, EventArgs e) + { + // + // Make sure the emulator is stopped. + // + _controller.StopExecution(); + + _system.Shutdown(); + + // + // The Alto window was closed, shut down the CLI. + // + _cliThread.Abort(); + } + + /// + /// Error handling + /// + /// + private void OnExecutionError(Exception e) + { + Console.WriteLine("Execution error: {0} - {1}", e.Message, e.StackTrace); + System.Diagnostics.Debugger.Break(); + } + + [DebuggerFunction("quit", "Exits ContrAlto.")] + private CommandResult Quit() + { + _controller.StopExecution(); + return CommandResult.Quit; + } + + // + // Console commands + // + [DebuggerFunction("start", "Starts the emulated Alto normally.")] + private CommandResult Start() + { + if (_controller.IsRunning) + { + Console.WriteLine("Alto is already running."); + } + else + { + _controller.StartExecution(AlternateBootType.None); + Console.WriteLine("Alto started."); + } + + return CommandResult.Normal; + } + + [DebuggerFunction("stop", "Stops the emulated Alto.")] + private CommandResult Stop() + { + _controller.StopExecution(); + Console.WriteLine("Alto stopped."); + + return CommandResult.Normal; + } + + [DebuggerFunction("reset", "Resets the emulated Alto.")] + private CommandResult Reset() + { + _controller.Reset(AlternateBootType.None); + Console.WriteLine("Alto reset."); + + return CommandResult.Normal; + } + + [DebuggerFunction("start with keyboard disk boot", "Starts the emulated Alto with the specified keyboard disk boot address.")] + private CommandResult StartDisk() + { + if (_controller.IsRunning) + { + Console.WriteLine("Alto is already running. Use 'stop' to stop the Alto first."); + } + else + { + _controller.StartExecution(AlternateBootType.Disk); + } + + return CommandResult.Normal; + } + + [DebuggerFunction("start with keyboard net boot", "Starts the emulated Alto with the specified keyboard ethernet boot number.")] + private CommandResult StartNet() + { + if (_controller.IsRunning) + { + Console.WriteLine("Alto is already running. Use 'stop' to stop the Alto first."); + } + else + { + _controller.StartExecution(AlternateBootType.Ethernet); + } + + return CommandResult.Normal; + } + + [DebuggerFunction("load disk", "Loads the specified drive with the requested disk image.", " ")] + private CommandResult LoadDisk(ushort drive, string path) + { + if (drive > 1) + { + throw new InvalidOperationException("Drive specification out of range."); + } + + // Save current drive contents. + _system.CommitDiskPack(drive); + + // Load the new pack. + _system.LoadDrive(drive, path); + Console.WriteLine("Drive {0} loaded.", drive); + + return CommandResult.Normal; + } + + [DebuggerFunction("unload disk", "Unloads the specified drive.", "")] + private CommandResult UnloadDisk(ushort drive) + { + if (drive > 1) + { + throw new InvalidOperationException("Drive specification out of range."); + } + + // Save current drive contents. + _system.CommitDiskPack(drive); + + // Unload the current pack. + _system.UnloadDrive(drive); + Console.WriteLine("Drive {0} unloaded.", drive); + + return CommandResult.Normal; + } + + [DebuggerFunction("show disk", "Displays the contents of the specified drive.", "")] + private CommandResult ShowDisk(ushort drive) + { + if (drive > 1) + { + throw new InvalidOperationException("Drive specification out of range."); + } + + // Save current drive contents. + if (_system.DiskController.Drives[drive].IsLoaded) + { + Console.WriteLine("Drive {0} contains image {1}", + drive, + _system.DiskController.Drives[drive].Pack.PackName); + } + else + { + Console.WriteLine("Drive {0} is not loaded.", drive); + } + + return CommandResult.Normal; + } + + [DebuggerFunction("show system type", "Displays the Alto system type.")] + private CommandResult ShowSystemType() + { + Console.WriteLine("System type is {0}", Configuration.SystemType); + return CommandResult.Normal; + } + + [DebuggerFunction("set ethernet address", "Sets the Alto's host Ethernet address.")] + private CommandResult SetEthernetAddress(byte address) + { + if (address == 0 || address == 0xff) + { + Console.WriteLine("Address {0} is invalid.", Conversion.ToOctal(address)); + } + else + { + Configuration.HostAddress = address; + } + + return CommandResult.Normal; + } + + [DebuggerFunction("show ethernet address", "Displays the Alto's host Ethernet address.")] + private CommandResult ShowEthernetAddress() + { + Console.WriteLine("Ethernet address is {0}", Conversion.ToOctal(Configuration.HostAddress)); + return CommandResult.Normal; + } + + [DebuggerFunction("show host network interface name", "Displays the host network interface used for Ethernet emulation")] + private CommandResult ShowHostNetworkInterfaceName() + { + Console.WriteLine("Network interface is '{0}'", Configuration.HostPacketInterfaceName); + return CommandResult.Normal; + } + + [DebuggerFunction("show host network interface type", "Displays the host network interface type (RAW or UDP)")] + private CommandResult ShowHostNetworkInterfaceType() + { + Console.WriteLine("Network interface type is '{0}'", Configuration.HostPacketInterfaceType); + return CommandResult.Normal; + } + + [DebuggerFunction("set keyboard net boot file", "Sets the boot file used for net booting.")] + private CommandResult SetKeyboardBootFile(ushort file) + { + Configuration.BootFile = file; + return CommandResult.Normal; + } + + [DebuggerFunction("set keyboard disk boot address", "Sets the boot address used for disk booting.")] + private CommandResult SetKeyboardBootAddress(ushort address) + { + Configuration.BootFile = address; + return CommandResult.Normal; + } + + // Not yet supported on non-Windows platforms + /* + [DebuggerFunction("enable display interlacing", "Enables interlaced display.")] + private CommandResult EnableDisplayInterlacing() + { + Configuration.InterlaceDisplay = true; + return CommandResult.Normal; + } + + [DebuggerFunction("disable display interlacing", "Disables interlaced display.")] + private CommandResult DisableDisplayInterlacing() + { + Configuration.InterlaceDisplay = false; + return CommandResult.Normal; + } + + [DebuggerFunction("enable speed throttling", "Limits execution speed to 60 fields/sec.")] + private CommandResult EnableSpeedThrottling() + { + Configuration.ThrottleSpeed = true; + return CommandResult.Normal; + } + + [DebuggerFunction("disable speed throttling", "Removes speed limits.")] + private CommandResult DisableSpeedThrottling() + { + Configuration.ThrottleSpeed = false; + return CommandResult.Normal; + } + + [DebuggerFunction("enable audio dac", "Enables the Audio DAC.")] + private CommandResult EnableAudioDAC() + { + Configuration.EnableAudioDAC = true; + return CommandResult.Normal; + } + + [DebuggerFunction("disable audio dac", "Disables the Audio DAC.")] + private CommandResult DisableAudioDAC() + { + Configuration.EnableAudioDAC = false; + return CommandResult.Normal; + } + + [DebuggerFunction("enable audio capture", "Enables capture of DAC output.")] + private CommandResult EnableAudioDACCapture() + { + Configuration.EnableAudioDACCapture = true; + return CommandResult.Normal; + } + + [DebuggerFunction("disable audio capture", "Disables capture of DAC output.")] + private CommandResult DisableAudioDACCapture() + { + Configuration.EnableAudioDACCapture = false; + return CommandResult.Normal; + } + + [DebuggerFunction("set audio capture path", "Configures the path for capture output.")] + private CommandResult SetAudioCapturePath(string path) + { + Configuration.AudioDACCapturePath = path; + return CommandResult.Normal; + } + */ + + private AltoSystem _system; + private ExecutionController _controller; + private SdlAltoWindow _mainWindow; + private Thread _cliThread; + } +} diff --git a/Contralto/packages.config b/Contralto/packages.config index 14d3468..0d96e65 100644 --- a/Contralto/packages.config +++ b/Contralto/packages.config @@ -1,4 +1,6 @@  + + \ No newline at end of file diff --git a/Contralto/pcap/PcapDotNet.Base.dll b/Contralto/pcap/PcapDotNet.Base.dll deleted file mode 100644 index f0cac7f..0000000 Binary files a/Contralto/pcap/PcapDotNet.Base.dll and /dev/null differ diff --git a/Contralto/pcap/PcapDotNet.Base.xml b/Contralto/pcap/PcapDotNet.Base.xml deleted file mode 100644 index f2a6707..0000000 --- a/Contralto/pcap/PcapDotNet.Base.xml +++ /dev/null @@ -1,1955 +0,0 @@ - - - - PcapDotNet.Base - - - - - Extension methods for IDictionary<TKey,TValue> interface. - - - - - Tests for equality between dictionaries. - Two dictionaries are equal if they have the same pairs. - Keys are compared using Equals() and values are compared using the given comparator. - - The type of the key of the dictionary. - The type of the value of the dictionary. - The first dictionary to compare. - The second dictionary to compare. - The comparator to check for values equality. - True iff the dictionaries are equal. - - - - Tests for equality between dictionaries. - Two dictionaries are equal if they have the same pairs. - Keys are compared using Equals() and values are compared using the default EqualityComparer. - - The type of the key of the dictionary. - The type of the value of the dictionary. - The first dictionary to compare. - The second dictionary to compare. - True iff the dictionaries are equal. - - - - Extension method for UShort structure. - - - - - Reverses the endianity of the given value. - - - - - Extension methods for String. - - - - - Returns whether all of the chars in the given string are in the [minValue, maxValue] range. - - The string to test. - The first char in the chars range. - The last char in the chars range. - True iff all of the string's chars are in the given range. - - - - A 48 bit unsigned integer. - - - - - The number of bytes this type will take. - - - - - The minimum value of this type. - - - - - The maximum value of this type. - - - - - Converts the string representation of a number to its 48-bit unsigned integer equivalent. - - A string that represents the number to convert. - A 48-bit unsigned integer equivalent to the number contained in . - The parameter is . - The parameter is not in the correct format. - The parameter represents a number less than or greater than . - - The parameter should be the string representation of a number in the following form. - [ws][sign]digits[ws] - Elements in square brackets ([ and ]) are optional. The following table describes each element. - - - Element - Description - - wsOptional white space. - - sign - - An optional sign. - Valid sign characters are determined by the and properties of the current culture. - However, the negative sign symbol can be used only with zero; otherwise, the method throws an . - - - digitsA sequence of digits from 0 through 9. Any leading zeros are ignored. - - - The parameter is interpreted using the style. - It cannot contain any group separators or decimal separator, and it cannot have a decimal portion. - - The parameter is parsed by using the formatting information in a object that is initialized for the current system culture. - For more information, see . - To parse a string by using the formatting information of a specific culture, use the method. - - - - - Converts the string representation of a number in a specified culture-specific format to its 48-bit unsigned integer equivalent. - - A string that represents the number to convert. - An object that supplies culture-specific formatting information about . - A 48-bit unsigned integer equivalent to the number specified in . - The parameter is . - The parameter is not in the correct style. - - The parameter represents a number less than or greater than . - - - This overload of the Parse(String, IFormatProvider) method is typically used to convert text that can be formatted in a variety of ways to a value. - For example, it can be used to convert the text entered by a user into an HTML text box to a numeric value. - The parameter contains a number of the form: - [ws][sign]digits[ws] - - Elements in square brackets ([ and ]) are optional. - The following table describes each element: - - - - Element - Description - - wsOptional white space. - - sign - An optional positive sign, or a negative sign if represents the value zero. - - digitsA sequence of digits from 0 through 9. - - The parameter is interpreted using the style. - In addition to the unsigned integer value's decimal digits, only leading and trailing spaces along with a leading sign is allowed. - (If the negative sign is present, must represent a value of zero, or the method throws an .) - To explicitly define the style elements together with the culture-specific formatting information that can be present in , use the method. - - The parameter is an implementation whose method returns a object that provides culture-specific information about the format of . - There are three ways to use the parameter to supply custom formatting information to the parse operation: - - - You can pass the actual object that provides formatting information. (Its implementation of simply returns itself.) - You can pass a object that specifies the culture whose formatting is to be used. Its property provides formatting information. - You can pass a custom implementation. Its method must instantiate and return the object that provides formatting information. - - If provider is , the object for the current culture is used. - - - - - Converts the string representation of a number in a specified style to its 48-bit unsigned integer equivalent. - - - A string that represents the number to convert. - The string is interpreted by using the style specified by the parameter. - - - A bitwise combination of the enumeration values that specifies the permitted format of . - A typical value to specify is . - - A 48-bit unsigned integer equivalent to the number specified in . - The parameter is . - - is not a value. - -or- - is not a combination of and values. - - The parameter is not in a format compliant with . - - The parameter represents a number less than or greater than . - -or- - includes non-zero, fractional digits. - - - The parameter defines the style elements (such as white space, the positive or negative sign symbol, the group separator symbol, or the decimal point symbol) that are allowed in the s parameter for the parse operation to succeed. - It must be a combination of bit flags from the enumeration. - Depending on the value of style, the parameter may include the following elements: - [ws][$][sign][digits,]digits[.fractional_digits][E[sign]exponential_digits][ws] - - Elements in square brackets ([ and ]) are optional. - If includes , the parameter may contain the following elements: - - [ws]hexdigits[ws] - The following table describes each element. - - - Element - Description - - - ws - - Optional white space. - White space can appear at the start of if includes the flag, - and it can appear at the end of if includes the flag. - - - - $ - - A culture-specific currency symbol. - Its position in the string is defined by the and properties of the current culture. - The current culture's currency symbol can appear in if includes the flag. - - - - sign - - An optional sign. - The sign can appear at the start of if includes the flag, and it can appear at the end of if includes the flag. - Parentheses can be used in to indicate a negative value if includes the flag. - However, the negative sign symbol can be used only with zero; otherwise, the method throws an . - - - - digits - A sequence of digits from 0 through 9. - - - . - - A culture-specific decimal point symbol. - The current culture's decimal point symbol can appear in if includes the flag. - - - - , - - A culture-specific group separator symbol. - The current culture's group separator can appear in if includes the flag. - - - fractional_digits - - One or more occurrences of the digit 0-9 if includes the flag, - or one or more occurrences of the digit 0 if it does not. - Fractional digits can appear in only if includes the flag. - - - - E - - The "e" or "E" character, which indicates that the value is represented in exponential (scientific) notation. - The parameter can represent a number in exponential notation if includes the flag. - - - - exponential_digits - - A sequence of digits from 0 through 9. - The parameter can represent a number in exponential notation if includes the flag. - - - hexdigitsA sequence of hexadecimal digits from 0 through f, or 0 through F. - - A string with decimal digits only (which corresponds to the style) always parses successfully. - Most of the remaining members control elements that may be present, but are not required to be present, in this input string. - The following table indicates how individual members affect the elements that may be present in . - - - value - Elements permitted in in addition to digits - - The digits element only. - The decimal point (.) and fractional_digits elements. However, if does not include the flag, fractional_digits must consist of only one or more 0 digits; otherwise, an is thrown. - The "e" or "E" character, which indicates exponential notation, along with exponential_digits. - The ws element at the start of . - The ws element at the end of . - The sign element at the start of . - The sign element at the end of . - The sign element in the form of parentheses enclosing the numeric value. - The group separator (,) element. - The currency ($) element. - All elements. However, cannot represent a hexadecimal number or a number in exponential notation. - The ws element at the start or end of , sign at the start of , and the decimal point (.) symbol. The parameter can also use exponential notation. - The ws, sign, group separator (,), and decimal point (.) elements. - All elements. However, cannot represent a hexadecimal number. - - Unlike the other values, which allow for, but do not require, the presence of particular style elements in , the style value means that the individual numeric characters in are always interpreted as hexadecimal characters. - Valid hexadecimal characters are 0-9, A-F, and a-f. - The only other flags that can be combined with the parameter are and . - (The enumeration includes a composite number style, , that includes both white-space flags.) - - If is the string representation of a hexadecimal number, it cannot be preceded by any decoration (such as 0x or &h) that differentiates it as a hexadecimal number. - This causes the conversion to fail. - - The parameter is parsed by using the formatting information in a object that is initialized for the current system culture. - To specify the culture whose formatting information is used for the parse operation, call the overload. - - - - - Converts the string representation of a number in a specified style and culture-specific format to its 48-bit unsigned integer equivalent. - - - A string that represents the number to convert. - The string is interpreted by using the style specified by the parameter. - - - A bitwise combination of enumeration values that indicates the style elements that can be present in . - A typical value to specify is . - - An object that supplies culture-specific formatting information about . - A 48-bit unsigned integer equivalent to the number specified in . - The parameter is . - - is not a value. - -or- - is not a combination of and values. - - The parameter is not in a format compliant with . - - The parameter represents a number less than or greater than . - -or- - includes non-zero, fractional digits. - - - The parameter defines the style elements (such as white space, the positive or negative sign symbol, the group separator symbol, or the decimal point symbol) that are allowed in the s parameter for the parse operation to succeed. - It must be a combination of bit flags from the enumeration. - Depending on the value of style, the parameter may include the following elements: - [ws][$][sign][digits,]digits[.fractional_digits][E[sign]exponential_digits][ws] - - Elements in square brackets ([ and ]) are optional. - If includes , the parameter may contain the following elements: - - [ws]hexdigits[ws] - The following table describes each element. - - - Element - Description - - - ws - - Optional white space. - White space can appear at the start of if includes the flag, - and it can appear at the end of if includes the flag. - - - - $ - - A culture-specific currency symbol. - Its position in the string is defined by the and properties of the object that is returned by the method of the provider parameter. - The currency symbol can appear in if includes the flag. - - - - sign - - An optional sign. - The sign can appear at the start of if includes the flag, and it can appear at the end of if includes the flag. - Parentheses can be used in to indicate a negative value if includes the flag. - However, the negative sign symbol can be used only with zero; otherwise, the method throws an . - - - digitsA sequence of digits from 0 through 9. - - . - - A culture-specific decimal point symbol. - The current culture's decimal point symbol can appear in if includes the flag. - - - - , - - A culture-specific group separator symbol. - The current culture's group separator can appear in if includes the flag. - - - fractional_digits - - One or more occurrences of the digit 0-9 if includes the flag, - or one or more occurrences of the digit 0 if it does not. - Fractional digits can appear in only if includes the flag. - - - - E - - The "e" or "E" character, which indicates that the value is represented in exponential (scientific) notation. - The parameter can represent a number in exponential notation if includes the flag. - - - - exponential_digits - - A sequence of digits from 0 through 9. - The parameter can represent a number in exponential notation if includes the flag. - - - hexdigitsA sequence of hexadecimal digits from 0 through f, or 0 through F. - - A string with decimal digits only (which corresponds to the style) always parses successfully. - Most of the remaining members control elements that may be present, but are not required to be present, in this input string. - The following table indicates how individual members affect the elements that may be present in . - - - value - Elements permitted in in addition to digits - - The digits element only. - The decimal point (.) and fractional_digits elements. However, if does not include the flag, fractional_digits must consist of only one or more 0 digits; otherwise, an is thrown. - The "e" or "E" character, which indicates exponential notation, along with exponential_digits. - The ws element at the start of . - The ws element at the end of . - The sign element at the start of . - The sign element at the end of . - The sign element in the form of parentheses enclosing the numeric value. - The group separator (,) element. - The currency ($) element. - All elements. However, cannot represent a hexadecimal number or a number in exponential notation. - The ws element at the start or end of , sign at the start of , and the decimal point (.) symbol. The parameter can also use exponential notation. - The ws, sign, group separator (,), and decimal point (.) elements. - All elements. However, cannot represent a hexadecimal number. - - Unlike the other values, which allow for, but do not require, the presence of particular style elements in , the style value means that the individual numeric characters in are always interpreted as hexadecimal characters. - Valid hexadecimal characters are 0-9, A-F, and a-f. - The only other flags that can be combined with the parameter are and . - (The enumeration includes a composite number style, , that includes both white-space flags.) - - If is the string representation of a hexadecimal number, it cannot be preceded by any decoration (such as 0x or &h) that differentiates it as a hexadecimal number. - This causes the conversion to fail. - - The parameter is an implementation whose method returns a object that provides culture-specific information about the format of . - There are three ways to use the parameter to supply custom formatting information to the parse operation: - - You can pass the actual object that provides formatting information. (Its implementation of simply returns itself.) - You can pass a object that specifies the culture whose formatting is to be used. Its property provides formatting information. - You can pass a custom implementation. Its method must instantiate and return the object that provides formatting information. - - If provider is , the object for the current culture is used. - - - - - Converts a 32 bit unsigned integer to a 48 bit unsigned integer by taking all the 32 bits. - - The 32 bit value to convert. - The 48 bit value created by taking all the 32 bits of the 32bit value. - - - - Converts a 64 bit signed integer to a 48 bit unsigned integer by taking the 48 least significant bits. - - The 64 bit value to convert. - The 48 bit value created by taking the 48 least significant bits of the 64 bit value. - - - - Converts a 64 bit unsigned integer to a 48 bit unsigned integer by taking the 48 least significant bits. - - The 64 bit value to convert. - The 48 bit value created by taking the 48 least significant bits of the 64 bit value. - - - - Converts the 48 bits unsigned integer to a 64 bits signed integer. - - The 48 bit value to convert. - The 64 bit value converted from the 48 bit value. - - - - Converts the 48 bits unsigned integer to a 64 bits unsigned integer. - - The 48 bit value to convert. - The 64 bit value converted from the 48 bit value. - - - - Converts the 48 bits unsigned integer to an 8 bits unsigned integer. - - The 48 bit value to convert. - The 8 bit value converted from the 48 bit value. - - - - Returns true iff the two values represent the same value. - - The value to compare to. - True iff the two values represent the same value. - - - - Indicates whether this instance and a specified object are equal. - - - true if and this instance are the same type and represent the same value; otherwise, false. - - Another object to compare to. 2 - - - - Returns true iff the two values represent the same value. - - The first value to compare. - The second value to compare. - True iff the two values represent the same value. - - - - Returns true iff the two values represent different values. - - The first value to compare. - The second value to compare. - True iff the two values represent different values. - - - - Returns the hash code for this instance. - - - A 32-bit signed integer that is the hash code for this instance. - - - - - Returns a string representing the value using a default format and an invariant culture format provider. - - - - - Returns a string representing the value using the given string format and an invariant culture format provider. - - - - - Returns a string representing the value using the given string format and the given format provider. - - - - - Extension methods for Func of type T. - - - - - Generates an array of a given size by generating elements using the given delegate. - - The type of the array to create. - The delegate to generate elements with. - The size of the array to create. - An array of a given size with elements generated by the given delegate. - - - - Extension method for UInt structure. - - - - - Returns the number of digits the number will be represented by according to a specific base. - - The number to check for number of digits. - The base of the digits. - The number of digits the number will be represented by according to a specific base. - - - - Extension methods for Match class. - - - - - Returns all the values that were captured for a given group name. - - The match to take the captured values from. - The name of the capture group to take the values of. - All the values that were captured for a given group name. - - - - Extension methods for Encoding class. - - - - - ISO-8859-1 Encoding. - - - - - A 24 bit unsigned integer. - - - - - The number of bytes this type will take. - - - - - The maximum value of this type. - - - - - Converts a 16 bit unsigned integer to a 24 bit unsigned integer. - - The 16 bit value to convert. - The 24 bit value created. - - - - Converts a 32 bit signed integer to a 24 bit unsigned integer by taking the 24 least significant bits. - - The 32 bit value to convert. - The 24 bit value created by taking the 24 least significant bits of the 32 bit value. - - - - Converts a 32 bit unsigned integer to a 24 bit unsigned integer by taking the 24 least significant bits. - - The 32 bit value to convert. - The 24 bit value created by taking the 24 least significant bits of the 32 bit value. - - - - Converts the 24 bits unsigned integer to a 32 bits signed integer. - - The 24 bit value to convert. - The 32 bit value converted from the 24 bit value. - - - - Returns true iff the two values represent the same value. - - The value to compare to. - True iff the two values represent the same value. - - - - Indicates whether this instance and a specified object are equal. - - - true if and this instance are the same type and represent the same value; otherwise, false. - - Another object to compare to. 2 - - - - Returns true iff the two values represent the same value. - - The first value to compare. - The second value to compare. - True iff the two values represent the same value. - - - - Returns true iff the two values represent different values. - - The first value to compare. - The second value to compare. - True iff the two values represent different values. - - - - Returns the hash code for this instance. - - - A 32-bit signed integer that is the hash code for this instance. - - 2 - - - - Returns the fully qualified type name of this instance. - - - A containing a fully qualified type name. - - 2 - - - - Useful functions for a sequence of objects. - - - - - Returns the xor of the hash codes of the given objects. - - - - - Returns the xor of the hash codes of the given objects. - - - - - Returns the xor of the hash codes of the given objects. - - - - - Extension methods for PropertyInfo. - - - - - Returns the value of the given instance's non-indexed property. - - - - - Extension methods for char structure. - - - - - True iff the given character is one of the capital english letters. - - The input character to check. - True for capital english letters. - - - - A 128 bit unsigned integer. - - - - - The number of bytes this type will take. - - - - - The minimum UInt128 value. - - - - - The maximum value of this type. - - - - - A Zero UInt128 value. - - - - - A One UInt128 value. - - - - - Creates a value using two 64 bit values. - - The most significant 64 bits of the value. - The least significant 64 bits of the value. - - - - Conversion of a object to an unsigned 128-bit integer value. - - The value to convert to an unsigned 128-bit integer. - The parameter represents a number less than or greater than . - - - - Defines an explicit conversion of a object to an unsigned 128-bit integer value. - - The value to convert to an unsigned 128-bit integer. - The 128 bit value created by equivalent to . - The parameter represents a number less than or greater than . - - - - Converts the 128 bits unsigned integer to a . - - The 128 bit value to convert. - The value converted from the 128 bit value. - - - - Converts a 64 bit unsigned integer to a 128 bit unsigned integer by taking all the 64 bits. - - The 64 bit value to convert. - The 128 bit value created by taking all the 64 bits of the 64 bit value. - - - - Converts the 128 bits unsigned integer to a 64 bits unsigned integer. - - The 128 bit value to convert. - The 64 bit value converted from the 128 bit value. - - - - Converts the string representation of a number in a specified style and culture-specific format to its equivalent. - - A string that contains a number to convert. - - A bitwise combination of the enumeration values that specify the permitted format of value. - - An object that provides culture-specific formatting information about . - A value that is equivalent to the number specified in the value parameter. - is not a value or includes the or flag along with another value. - is null. - does not comply with the input pattern specified by . - The parameter represents a number less than or greater than . - - The parameter defines the style elements - (such as white space, the positive or negative sign symbol, the group separator symbol, or the decimal point symbol) - that are allowed in the parameter for the parse operation to succeed. - must be a combination of bit flags from the enumeration. - The parameter makes this method overload useful when contains the string representation of a hexadecimal value, - when the number system (decimal or hexadecimal) represented by value is known only at run time, or when you want to disallow white space or a sign symbol in value. - Depending on the value of , the parameter may include the following elements: - [ws][$][sign][digits,]digits[.fractional_digits][E[sign]exponential_digits][ws] - If includes , the parameter may include the following elements: - [ws]hexdigits[ws] - Elements in square brackets ([ and ]) are optional. The following table describes each element. - - - Element - Description - - - ws - - Optional white space. - White space can appear at the start of value if includes the flag, - and it can appear at the end of value if includes the flag. - - - - $ - - A culture-specific currency symbol. - Its position in the string is defined by the and properties of the culture indicated by the parameter. - The current culture's currency symbol can appear in value if includes the flag. - - - - sign - - An optional sign. - The sign can appear at the start of if includes the flag, - and it can appear at the end of if includes the flag. - Parentheses can be used in to indicate a negative value if includes the flag. - - - - digits, fractional_digits, exponential_digits - A sequence of digits from 0 through 9. A sequence of digits from 0 through 9. For fractional_digits, only the digit 0 is valid. - - - , - - A culture-specific group separator symbol. - The group separator symbol of the culture specified by can appear in if includes the flag. - - - - . - - A culture-specific decimal point symbol. - The decimal point symbol of the culture designated by can appear in if includes the flag. - Only the digit 0 can appear as a fractional digit for the parse operation to succeed; - if fractional_digits includes any other digit, a is thrown. - - - - E - - The "e" or "E" character, which indicates that the value is represented in exponential (scientific) notation. - The parameter can represent a number in exponential notation if includes the flag. - - - - hexdigits - A sequence of hexadecimal digits from 0 through f, or 0 through F. - - - If you use the method to round-trip the string representation of a value that was output by the method, - you should use the method with the "R" format specifier to generate the string representation of the value. - Otherwise, the string representation of the preserves only the 50 most significant digits of the original value, and data may be lost when you use the method to restore the value. - - Unlike the other values, which allow for but do not require the presence of particular style elements in , - the style value means that the individual numeric characters in are always interpreted as hexadecimal characters. - Valid hexadecimal characters are 0-9, A-F, and a-f. - The only other flags that can be combined with the parameter are and . - (The enumeration includes a composite number style, , that includes both white-space flags.) - - - If is the string representation of a hexadecimal number, it cannot be preceded by any decoration (such as 0x or &h) that differentiates it as a hexadecimal number. - This causes the conversion to fail. - - If is a hexadecimal string, the method interprets as a negative number stored by using two's complement representation if its first two hexadecimal digits are greater than or equal to 0x80. - In other words, the method interprets the highest-order bit of the first byte in as the sign bit. - To make sure that a hexadecimal string is correctly interpreted as a positive number, the first digit in must have a value of zero. - For example, the method interprets 0x80 as a negative value, but it interprets either 0x080 or 0x0080 as a positive value. - - The parameter is an implementation. - Its method returns a object that provides culture-specific information about the format of value. - Typically, can be any one of the following: - - - A object that represents the culture that provides numeric formatting information. - Its method returns the object that provides numeric formatting information. - - A object that provides formatting information. (Its implementation of just returns itself.) - - A custom object that implements and uses the method - to instantiate and return the object that provides formatting information. - - - If is , the object for the current culture is used. - - - - - - Converts the string representation of a number in a specified culture-specific format to its equivalent. - Uses style. - - A string that contains a number to convert. - An object that provides culture-specific formatting information about . - A value that is equivalent to the number specified in the value parameter. - is null. - The parameter represents a number less than or greater than . - - See important remarks in - - - - - Converts the string representation of a number in a specified style to its equivalent. - Uses as the format provider. - - A string that contains a number to convert. - A bitwise combination of the enumeration values that specify the permitted format of value. - A value that is equivalent to the number specified in the value parameter. - is not a value or includes the or flag along with another value. - is null. - does not comply with the input pattern specified by . - The parameter represents a number less than or greater than . - - See important remarks in - - - - - Converts the string representation of a number in a specified style to its equivalent. - Uses style. - Uses as the format provider. - - A string that contains a number to convert. - A value that is equivalent to the number specified in the value parameter. - is null. - The parameter represents a number less than or greater than . - - See important remarks in - - - - - Tries to convert the string representation of a number in a specified style and culture-specific format to its equivalent, - and returns a value that indicates whether the conversion succeeded. - - The string representation of a number. The string is interpreted using the style specified by . - - A bitwise combination of enumeration values that indicates the style elements that can be present in . - A typical value to specify is . - - An object that supplies culture-specific formatting information about . - - When this method returns, contains the equivalent to the number that is contained in value, or if the conversion failed. - The conversion fails if the value parameter is , is not in a format that is compliant with or represents a number that is less than or greater than . - This parameter is passed uninitialized. - true if the parameter was converted successfully; otherwise, false. - - The method is like the method, - except that it does not throw an exception if the conversion fails. - This method eliminates the need to use exception handling to test for a if is invalid and cannot be parsed successfully. - For more information see - - - - - Tries to convert the string representation of a number to its equivalent, - and returns a value that indicates whether the conversion succeeded. - - The string representation of a number. - - When this method returns, contains the equivalent to the number that is contained in value, or if the conversion failed. - The conversion fails if the value parameter is or represents a number that is less than or greater than . - This parameter is passed uninitialized. - true if the parameter was converted successfully; otherwise, false. - - The method is like the method, - except that it does not throw an exception if the conversion fails. - This method eliminates the need to use exception handling to test for a if is invalid and cannot be parsed successfully. - For more information see - - - - - Returns true iff the two values represent the same value. - - The value to compare to. - True iff the two values represent the same value. - - - - Indicates whether this instance and a specified object are equal. - - - true if and this instance are the same type and represent the same value; otherwise, false. - - Another object to compare to. 2 - - - - Compares the current object with another object of the same type. - - - A value that indicates the relative order of the objects being compared. - The return value has the following meanings: - Less than zero - This object is less than the . - parameter.Zero - This object is equal to . - Greater than zero - This object is greater than . - - An object to compare with this object. - - - - Returns true iff the two values represent the same value. - - The first value to compare. - The second value to compare. - True iff the two values represent the same value. - - - - Returns true iff the two values represent different values. - - The first value to compare. - The second value to compare. - True iff the two values represent different values. - - - - Returns true iff the first value is smaller than the second value. - - The first value to compare. - The second value to compare. - True iff the first value is smaller than the second value. - - - - Returns true iff the first value is greater than the second value. - - The first value to compare. - The second value to compare. - True iff the first value is greater than the second value. - - - - Returns true iff the first value is smaller than or equal to the second value. - - The first value to compare. - The second value to compare. - True iff the first value is smaller than or equal to the second value. - - - - Returns true iff the first value is greater than or equal to the second value. - - The first value to compare. - The second value to compare. - True iff the first value is greater than or equal to the second value. - - - - Shifts its first operand right by the number of bits specified by its second operand. - - The value to shift. - The number of bits to shift. - The value after it was shifted by the given number of bits. - - - - Shifts its first operand left by the number of bits specified by its second operand. - - The value to shift. - The number of bits to shift. - The value after it was shifted by the given number of bits. - - - - Shifts its first operand right by the number of bits specified by its second operand. - - The value to shift. - The number of bits to shift. - The value after it was shifted by the given number of bits. - - - - Shifts its first operand left by the number of bits specified by its second operand. - - The value to shift. - The number of bits to shift. - The value after it was shifted by the given number of bits. - - - - Bitwise ands between two values. - - The first value to do bitwise and. - The second value to do bitwise and. - The two values after they were bitwise anded. - - - - Bitwise ands between two values. - - The first value to do bitwise and. - The second value to do bitwise and. - The two values after they were bitwise anded. - - - - Bitwise ors between two values. - - The first value to do bitwise or. - The second value to do bitwise or. - The two values after they were bitwise ored. - - - - Bitwise ors between two values. - - The first value to do bitwise or. - The second value to do bitwise or. - The two values after they were bitwise ored. - - - - Sums the given values and returns the sum. - - The first value to sum. - The second value to sum. - The sum of the given values. - - - - Sums the given values and returns the sum. - - The first value to sum. - The second value to sum. - The sum of the given values. - - - - Substract the second value from the first value and returns the result of the substraction. - - The first value to sum. - The second value to sum. - The result of substracting the second value from the first value. - - - - Substract the second value from the first value and returns the result of the substraction. - - The first value to sum. - The second value to sum. - The result of substracting the second value from the first value. - - - - Returns the hash code for this instance. - - - A 32-bit signed integer that is the hash code for this instance. - - 2 - - - - Converts the numeric value of the current object to its equivalent string representation by using the specified format and culture-specific format information. - - A standard or custom numeric format string. - An object that supplies culture-specific formatting information. - The string representation of the current value as specified by the and parameters. - is not a valid format string. - - The parameter can be any valid standard numeric format specifier, or any combination of custom numeric format specifiers. - If is equal to or is , the return value of the current object is formatted with the general format specifier ("G"). - If is any other value, the method throws a . - - The parameter is an implementation. - Its method returns a object that provides culture-specific information about the format of the string returned by this method. - When the method is invoked, it calls the parameter's method and passes it a object that represents the type. - The method then returns the object that provides information for formatting the object, such as the negative sign symbol, the group separator symbol, or the decimal point symbol. - There are three ways to use the parameter to supply formatting information to the method: - - - You can pass a object that represents the culture that provides numeric formatting information. - Its method returns the object that provides numeric formatting information. - - You can pass the actual object that provides formatting information. (Its implementation of just returns itself.) - - You can pas a custom object that implements and uses the method - to instantiate and return the object that provides formatting information. - - - If is , the formatting of the returned string is based on the object of the current culture. - - - - - - Converts the numeric value of the current object to its equivalent string representation by using the specified format. - Uses as the format provider. - - A standard or custom numeric format string. - The string representation of the current value as specified by the parameter. - is not a valid format string. - - See for remarks. - - - - - Converts the numeric value of the current object to its equivalent string representation by using the specified culture-specific format information. - Uses "G" format. - - An object that supplies culture-specific formatting information. - The string representation of the current value as specified by the parameter. - - See for remarks. - - - - - Converts the numeric value of the current object to its equivalent string representation. - Uses "G" format. - Uses as the format provider. - - The string representation of the current value. - - See for remarks. - - - - - A 32 bit serial number as defined in RFC 1982. - - - - - The number of bytes this type takes. - - - - - Number of bits of the serial number. - - - - - The maximum value that can be added to the serial number. - - - - - Constructs a serial number from an unsigned value. - - The value to set the serial number. - - - - Adds a value to the serial number and returns the result. - should not be bigger than . - - The value to add. - A new serial number that represents the sum of the original serial number and . - - - - Two serial numbers are equal if their value is equal. - - The object to compare to. - True iff the two serial numbers are equal. - - - - Two serial numbers are equal if their value is equal. - - The object to compare to. - True iff the two serial numbers are equal. - - - - Returns the hash code for this instance. - - A 32-bit signed integer that is the hash code for this instance. - - - - Compares the current object with another object of the same type. - - - A value that indicates the relative order of the objects being compared. - The return value has the following meanings: - Value Meaning Less than zero This object is less than the . - parameter.Zero This object is equal to . - Greater than zero This object is greater than . - - An object to compare with this object. - - - - The string representation of this serial number. - - A string representing this serial number. - - - - The string representation of this serial number using the given format provider. - - The format of the output string. - A string representing this serial number using the given format provider. - - - - Implicitly cast a uint to a serial number. - - The value to cast. - The casted value. - - - - Returns true iff the two serial numbers are equal. - - First serial number to compare. - Second serial number to compare. - True iff the two serial numbers are equal. - - - - Returns true iff the two serial numbers are not equal. - - First serial number to compare. - Second serial number to compare. - True iff the two serial numbers are not equal. - - - - Returns true iff the first serial number is smaller than the second serial number. - - First serial number to compare. - Second serial number to compare. - True iff the first serial number is smaller than the second serial number.. - - - - Returns true iff the first serial number is greater than the second serial number. - - First serial number to compare. - Second serial number to compare. - True iff the first serial number is greater than the second serial number.. - - - - The value of the serial number. - - - - - Extension methods for MemberInfo. - - - - - When overridden in a derived class, returns a sequence of custom attributes identified by System.Type. - - TThe type of attribute to search for. Only attributes that are assignable to this type are returned. - The memberInfo to look the attributes on. - Specifies whether to search this member's inheritance chain to find the attributes. - A sequence of custom attributes applied to this member, or a sequence with zero (0) elements if no attributes have been applied. - - - - Extension methods for IEnumerable of type T. - - - - - Returns true if the given enumerable is null or empty. - - - - - Concatenates a sequence with more values. - - The type of an element in the sequence. - The sequence to concatenate. - The values that will be concatenated with the sequence. - A sequence containing all the original sequence elements cocatenated with values elements. - - - - Returns the bitwise xor of all the elements in the sequence. - - The elements to xor. - The bitwise xor of all the elements in the sequence. - - - - Returns the bitwise xor of all the elements in the sequence. - - The elements to xor. - The bitwise xor of all the elements in the sequence. - - - - Returns the bitwise xor of all the selected values of the elements in the sequence. - - The elements to select values to xor. - The selector used to select the values. - The bitwise xor of all the selected values of the elements in the sequence. - - - - Returns the bitwise xor of all the selected values of the elements in the sequence. - - The elements to select values to xor. - The selector used to select the values. - The bitwise xor of all the selected values of the elements in the sequence. - - - - Converts a sequence to a string by converting each element to a string. - - The type of an element in the sequence. - The sequence with the elements to translate to string. - A separator between the elements. - Prefix to the entire string. - Suffix to the entire string. - A string of all the elements. - - - - Converts a sequence to a string by converting each element to a string. - - The type of an element in the sequence. - The sequence with the elements to translate to string. - A separator between the elements. - Prefix to the entire string. - A string of all the elements. - - - - Converts a sequence to a string by converting each element to a string. - - The type of an element in the sequence. - The sequence with the elements to translate to string. - A separator between the elements. - A string of all the elements. - - - - Converts a sequence to a string by converting each element to a string. - - The type of an element in the sequence. - The sequence with the elements to translate to string. - A separator between the elements. - A string of all the elements. - - - - Converts a sequence to a string by converting each element to a string. - - The type of an element in the sequence. - The sequence with the elements to translate to string. - A string of all the elements. - - - - Returns a string by converting all the bytes to a hexadecimal string. - - The bytes to convert to a string. - The string to put between every two bytes. - The string resulted by converting all the bytes to hexadecimal strings and putting the separator between them. - - - - Returns a string by converting all the bytes to a hexadecimal string. - - The bytes to convert to a string. - The string resulted by converting all the bytes to hexadecimal strings. - - - - Creates a hash code by xoring the hash codes of the elements in the sequence. - - The type of the elements in the sequence. - The sequence with the elements to create the hash code for. - The hash code created by xoring all the hash codes of the elements in the sequence. - - - - Returns a hash code by xoring all the bytes. - Each byte is xored with the next 8 bits of the integer. - - The bytes to xor. - The hash code resulted by xoring all the bytes. - - - - Returns a hash code by xoring all the ushorts. - Each ushort is xored with the next 16 bits of the integer. - - The ushorts to xor. - The hash code resulted by xoring all the ushorts. - - - - Counts the number of types the given value is contained in the given sequence. - - The type of the elements in the sequence. - The sequence to look for the value in. - The value to look for in the sequence. - The number of types the given value is contained in the given sequence. - - - - Returns true iff the given sequence is strictly ordered using the elements as keys and a default comparer. - - The type of the objects in the sequence that will be used as keys for comparison using a default comparer. - The sequence of elements to check for strict order. - True iff the sequence is strictly ordered. - - - - Returns true iff the given sequence is strictly ordered using the by keys computed using a given function and a default comparer. - - - The type of the objects in the sequence that will that will be operated with the given key selector function to get the keys - to compare using a default comparer. - - The type of the keys to compare using a default comparer. - The sequence of elements to check for strict order. - The function to operate on the sequence elements to get the keys to compare. - True iff the sequence is strictly ordered. - - - - Returns true iff the given sequence is strictly ordered using the by keys computed using a given function and a given comparer. - - - The type of the objects in the sequence that will that will be operated with the given key selector function to get the keys - to compare using a given comparer. - - The type of the keys to compare using a given comparer. - The sequence of elements to check for strict order. - The function to operate on the sequence elements to get the keys to compare. - The comparer to use to compare the computed keys. - True iff the sequence is strictly ordered. - - - - Useful functions for sequences of bits. - - - - - Casts a bit to a byte. - True becomes 1 and false becomes 0. - - Bit 7 of the byte. - 1 for true, 0 for false. - - - - Merges 2 bits to a byte. - Bits should be arranged from the most significant to the least. - - Bit 6 of the byte. - Bit 7 of the byte. - A byte with the 2 least significant bits determined by the input. - - - - Merges 3 bits to a byte. - Bits should be arranged from the most significant to the least. - - Bit 5 of the byte. - Bit 6 of the byte. - Bit 7 of the byte. - A byte with the 3 least significant bits determined by the input. - - - - Merges 4 bits to a byte. - Bits should be arranged from the most significant to the least. - - Bit 4 of the byte. - Bit 5 of the byte. - Bit 6 of the byte. - Bit 7 of the byte. - A byte with the 4 least significant bits determined by the input. - - - - Merges 5 bits to a byte. - Bits should be arranged from the most significant to the least. - - Bit 3 of the byte. - Bit 4 of the byte. - Bit 5 of the byte. - Bit 6 of the byte. - Bit 7 of the byte. - A byte with the 5 least significant bits determined by the input. - - - - Merges 6 bits to a byte. - Bits should be arranged from the most significant to the least. - - Bit 2 of the byte. - Bit 3 of the byte. - Bit 4 of the byte. - Bit 5 of the byte. - Bit 6 of the byte. - Bit 7 of the byte. - A byte with the 6 least significant bits determined by the input. - - - - Merges 7 bits to a byte. - Bits should be arranged from the most significant to the least. - - Bit 1 of the byte. - Bit 2 of the byte. - Bit 3 of the byte. - Bit 4 of the byte. - Bit 5 of the byte. - Bit 6 of the byte. - Bit 7 of the byte. - A byte with the 7 least significant bits determined by the input. - - - - Merges 8 bits to a byte. - Bits should be arranged from the most significant to the least. - - Bit 0 of the byte. - Bit 1 of the byte. - Bit 2 of the byte. - Bit 3 of the byte. - Bit 4 of the byte. - Bit 5 of the byte. - Bit 6 of the byte. - Bit 7 of the byte. - A byte whose bits are determined by the input. - - - - Merges 2 bytes to a ushort. - Bytes should be arranged from the most significant to the least. - - Bits 0-7 of the ushort. - Bits 8-15 of the ushort. - A ushort whose bits are determined by the input. - - - - Merges 3 bytes to a UInt24. - Bytes should be arranged from the most significant to the least. - - Bits 0-7 of the UInt24. - Bits 8-15 of the UInt24. - Bits 16-23 of the UInt24. - A UInt24 whose bits are determined by the input. - - - - Merges 4 bytes to a uint. - Bytes should be arranged from the most significant to the least. - - Bits 0-7 of the uint. - Bits 8-15 of the uint. - Bits 16-23 of the uint. - Bits 24-31 of the uint. - A uint whose bits are determined by the input. - - - - Merges 6 bytes to a UInt48. - Bytes should be arranged from the most significant to the least. - - Bits 0-7 of the UInt48. - Bits 8-15 of the UInt48. - Bits 16-23 of the UInt48. - Bits 24-31 of the UInt48. - Bits 32-39 of the UInt48. - Bits 40-47 of the UInt48. - A UInt48 whose bits are determined by the input. - - - - Merges 8 bytes to a ulong. - Bytes should be arranged from the most significant to the least. - - Bits 0-7 of the ulong. - Bits 8-15 of the ulong. - Bits 16-23 of the ulong. - Bits 24-31 of the ulong. - Bits 32-39 of the ulong. - Bits 40-47 of the ulong. - Bits 48-55 of the ulong. - Bits 56-63 of the ulong. - A ulong whose bits are determined by the input. - - - - Merges 16 bytes to a UInt128. - Bytes should be arranged from the most significant to the least. - - Bits 0-7 of the UInt128. - Bits 8-15 of the UInt128. - Bits 16-23 of the UInt128. - Bits 24-31 of the UInt128. - Bits 32-39 of the UInt128. - Bits 40-47 of the UInt128. - Bits 48-55 of the UInt128. - Bits 56-63 of the UInt128. - Bits 64-71 of the UInt128. - Bits 72-79 of the UInt128. - Bits 80-87 of the UInt128. - Bits 88-95 of the UInt128. - Bits 96-103 of the UInt128. - Bits 104-111 of the UInt128. - Bits 112-119 of the UInt128. - Bits 120-127 of the UInt128. - A UInt128 whose bits are determined by the input. - - - - Merges 2 ushort to a uint. - ushorts should be arranged from the most significant to the least. - - Bits 0-15 of the uint. - Bits 16-31 of the uint. - A uint whose bits are determined by the input. - - - - Merges a byte and a ushort to a UInt24. - Values should be arranged from the most significant to the least. - - Bits 0-7 of the UInt24. - Bits 8-23 of the UInt24. - A UInt24 whose bits are determined by the input. - - - - Merges a ushort and 2 bytes to a uint. - Values should be arranged from the most significant to the least. - - Bits 0-15 of the uint. - Bits 16-23 of the uint. - Bits 24-31 of the uint. - A uint whose bits are determined by the input. - - - - Merges a ushort and 2 bytes to a uint. - Values should be arranged from the most significant to the least. - - Bits 0-7 of the uint. - Bits 8-23 of the uint. - Bits 24-31 of the uint. - A uint whose bits are determined by the input. - - - - Merges a ushort and 2 bytes to a uint. - Values should be arranged from the most significant to the least. - - Bits 0-7 of the uint. - Bits 8-15 of the uint. - Bits 16-31 of the uint. - A uint whose bits are determined by the input. - - - - Merges a uint and 2 ushorts to a ulong. - values should be arranged from the most significant to the least. - - Bits 0-31 of the ulong. - Bits 32-47 of the ulong. - Bits 48-63 of the ulong. - A ulong whose bits are determined by the input. - - - - Merges 2 uints to a ulong. - uints should be arranged from the most significant to the least. - - Bits 0-31 of the ulong. - Bits 32-63 of the ulong. - A ulong whose bits are determined by the input. - - - - Merges 2 ulongs to a UInt128. - ulongs should be arranged from the most significant to the least. - - Bits 0-63 of the UInt128. - Bits 64-127 of the UInt128. - A UInt128 whose bits are determined by the input. - - - - Extension methods for Type. - - - - - Returns all the possible values for the given enum type. - - - - - Extension methods for TimeSpan. - - - - - Represents the number of ticks in 1 microsecond. This field is constant. - - - - - Divides the TimeSpan by a given value. - - The TimeSpan to divide. - The value to divide the TimeSpan by. - A TimeSpan value equals to the given TimeSpan divided by the given value. - - - - Multiplies the TimeSpan by a given value. - - The TimeSpan to multiply. - The value to multiply the TimeSpan by. - A TimeSpan value equals to the given TimeSpan multiplied by the given value. - - - - Extension methods for DateTime. - - - - - Returns a new DateTime that adds the specified number of microseconds to the value of this instance. - - The DateTime to add microseconds to. - A number of whole and fractional microseconds. The value parameter can be negative or positive. Note that this value is rounded to the nearest integer. - An object whose value is the sum of the date and time represented by this instance and the number of microseconds represented by value. - - - - An equality comparer that is implemented using the given equals and getHashCode functions. - - The type of objects to compare. - - - - Constructs the comparer using the given equals and getHashCode functions. - - The function to use to implement Equals(). - The function to use to implement GetHashCode(). - - - - Determines whether the specified objects are equal using the equals function that was given in the constructor. - - - true if the specified objects are equal; otherwise, false. - - The first object of type to compare.The second object of type to compare. - - - - Returns a hash code for the specified object using the getHashCode function that was given in the constructor. - - - A hash code for the specified object. - - The for which a hash code is to be returned.The type of is a reference type and is null. - - - - Extension method for Short structure. - - - - - Reverses the endianity of the given value. - - - - - Extension methods for IList of type T. - - - - - Wraps a list with a ReadOnlyCollection. - - The type of an element in the collection. - The list to wrap in a ReadOnlyCollection. - - - - - Returns an enumerable of all the elements in the given list starting in a specific offset and taking no more than a specific count. - - The type of an element in the collection. - The list to take the elements from. - The offset of the first element to take. - The maximum number of elements to take. - An enumerable of all the elements in the given list starting in a specific offset and taking no more than a specific count. - - - diff --git a/Contralto/pcap/PcapDotNet.Core.Extensions.XML b/Contralto/pcap/PcapDotNet.Core.Extensions.XML deleted file mode 100644 index 5c35201..0000000 --- a/Contralto/pcap/PcapDotNet.Core.Extensions.XML +++ /dev/null @@ -1,110 +0,0 @@ - - - - PcapDotNet.Core.Extensions - - - - - Different extension methods for PacketCommunicator class. - - - - - - Collect a group of packets. - Similar to ReceivePackets() except instead of calling a callback the packets are returned as an IEnumerable. - - - - The PacketCommunicator to work on - Number of packets to process. A negative count causes ReceivePackets() to loop until the IEnumerable break (or until an error occurs). - An IEnumerable of Packets to process. - Thrown if the mode is not Capture or an error occurred. - - Only the first bytes of data from the packet might be in the received packet (which won't necessarily be the entire packet; to capture the entire packet, you will have to provide a value for snapshortLength in your call to PacketDevice.Open() that is sufficiently large to get all of the packet's data - a value of 65536 should be sufficient on most if not all networks). - If a break is called on the returned Enumerable before the number of packets asked for received, the packet that was handled while breaking the enumerable may not be the last packet read. More packets might be read. This is because this method actually loops over calls to ReceiveSomePackets() - - - - - Collect a group of packets. - Similar to ReceivePackets() except instead of calling a callback the packets are returned as an IEnumerable. - Loops until the IEnumerable break (or until an error occurs). - - - - The PacketCommunicator to work on - An IEnumerable of Packets to process. - Thrown if the mode is not Capture or an error occurred. - - Only the first bytes of data from the packet might be in the received packet (which won't necessarily be the entire packet; to capture the entire packet, you will have to provide a value for snapshortLength in your call to PacketDevice.Open() that is sufficiently large to get all of the packet's data - a value of 65536 should be sufficient on most if not all networks). - If a break is called on the returned Enumerable, the packet that was handled while breaking the enumerable may not be the last packet read. More packets might be read. This is because this method actually loops over calls to ReceiveSomePackets() - - - - - Extension methods for LivePacketDevice class. - - - - - Returns the GUID (NetCfgInstanceId) for a instance. - The GUID is parsed from the property. - - The instance. - The GUID (NetCfgInstanceId) of the instance. - When the doesn't match the expectations. - - - - Returns the PNPDeviceID for a instance. - The PNPDeviceID is retrieved by querying the registry. - - The instance. - The PNPDeviceID of the instance. - When the PNPDeviceID cannot be retrieved from the registry. - - - - Returns the network interface of the packet device. - The interface is found using its id. - If no interface is found, null is returned. - - The LivePacketDevice to look for a matching network interface for. - The network interface found according to the given device or null if none is found. - - - - Returns the of the network interface of the given device. - If no interface matches the given packet device, an exception is thrown. - We first look for the device using and if that fails we look for them using WMI. - - The packet device to look for the matching interface. - The of the given device's matching interface. - - - - Returns the for a instance. - The is retrieved through using WMI. - - The instance. - The of the instance. - When the cannot be retrieved using WMI. - - - - Extension methods for NetworkInterface class. - - - - - Returns the LivePacketDevice of the given NetworkInterface. - The LivePacketDevice is found using the NetworkInterface's id and the LivePacketDevice's name. - If no interface is found, null is returned. - - The NetworkInterface to look for a matching LivePacketDevice for. - The LivePacketDevice found according to the given NetworkInterface or null if none is found. - - - diff --git a/Contralto/pcap/PcapDotNet.Core.Extensions.dll b/Contralto/pcap/PcapDotNet.Core.Extensions.dll deleted file mode 100644 index 25ea555..0000000 Binary files a/Contralto/pcap/PcapDotNet.Core.Extensions.dll and /dev/null differ diff --git a/Contralto/pcap/PcapDotNet.Core.dll b/Contralto/pcap/PcapDotNet.Core.dll deleted file mode 100644 index 62b5b5d..0000000 Binary files a/Contralto/pcap/PcapDotNet.Core.dll and /dev/null differ diff --git a/Contralto/pcap/PcapDotNet.Core.xml b/Contralto/pcap/PcapDotNet.Core.xml deleted file mode 100644 index e622ef7..0000000 --- a/Contralto/pcap/PcapDotNet.Core.xml +++ /dev/null @@ -1,1173 +0,0 @@ - - - - "PcapDotNet.Core" - - - - -Open a generic source in order to capture / send (WinPcap only) traffic. - - Length of the packet that has to be retained. For each packet received by the filter, only the first 'snapshotLength' bytes are stored in the buffer and passed to the user application. For instance, snaplen equal to 100 means that only the first 100 bytes of each packet are stored. - Keeps several flags that can be needed for capturing packets. - Read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it waits for some amount of time to allow more packets to arrive and to read multiple packets from the OS kernel in one operation. Not all platforms support a read timeout; on platforms that don't, the read timeout is ignored. - Thrown on failure. - - - -List of addresses for the interface. - - - - -Interface flags. Currently the only possible flag is Loopback, that is set if the interface is a loopback interface. - - - - -if not null, a string giving a human-readable description of the device. - - - - -A string giving a name for the device. - - - - -Create a list of local machine network devices that can be opened with Open(). -Platform independent. - - -A readonly collection of LivePacketDevices. - - -Thrown if some errors occurred. -An error could be due to several reasons: - libpcap/WinPcap was not installed on the local/remote host.The user does not have enough privileges to list the devices.A network problem.other errors (not enough memory and others). - -There may be network devices that cannot be opened with Open() by the process calling AllLocalMachine, because, for example, that process might not have sufficient privileges to open them for capturing; if so, those devices will not appear on the list. - - - - -A live interface. - - - - -Open a generic source in order to capture / send (WinPcap only) traffic. - - length of the packet that has to be retained. For each packet received by the filter, only the first 'snapshotLength' bytes are stored in the buffer and passed to the user application. For instance, snaplen equal to 100 means that only the first 100 bytes of each packet are stored. - Keeps several flags that can be needed for capturing packets. - Read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it waits for some amount of time to allow more packets to arrive and to read multiple packets from the OS kernel in one operation. Not all platforms support a read timeout; on platforms that don't, the read timeout is ignored. - Thrown on failure. - - - -List of addresses for the interface. - - - - -Interface flags. Currently the only possible flag is Loopback, that is set if the interface is a loopback interface. - - - - -if not null, a string giving a human-readable description of the device. - - - - -A string giving a name for the device. - - - - -Creates a device object from a pcap file. -The device can opened to read packets from. - - The name of the pcap file. - - - -An offline interface - a pcap file to read packets from. - - - - -No sampling has to be done on the current capture. -In this case, no sampling algorithms are applied to the current capture. - - - - -Indicates the 'waiting time' in milliseconds before one packet got accepted. -In other words, if 'value = 10', the first packet is returned to the caller; the next returned one will be the first packet that arrives when 10ms have elapsed. - - - - -Constructs by giving an interval as TimeSpan. - - The time to wait between packets sampled. - The interval is negative or larger than 2^31 milliseconds. - - - -Constructs by giving an interval in milliseconds. - - The number of milliseconds to wait between packets sampled. - The given number of milliseconds is negative. - - - -This sampling method defines that we have to return 1 packet every given time-interval. -In other words, if the interval is set to 10 milliseconds, the first packet is returned to the caller; the next returned one will be the first packet that arrives when 10ms have elapsed. - - - - -Send a buffer of packets to the network. -This function transmits the content of a queue to the wire. - - Contains the packets to send. - Determines if the send operation must be synchronized: if it is true, the packets are sent respecting the timestamps, otherwise they are sent as fast as possible. - An error occurred during the send. The error can be caused by a driver/adapter problem or by an inconsistent/bogus send buffer.. - - - Using this function is more efficient than issuing a series of SendPacket(), because the packets are buffered in the kernel driver, so the number of context switches is reduced. Therefore, expect a better throughput when using Transmit(). - When isSync is true, the packets are synchronized in the kernel with a high precision timestamp. This requires a non-negligible amount of CPU, but allows normally to send the packets with a precision of some microseconds (depending on the accuracy of the performance counter of the machine). Such a precision cannot be reached sending the packets with SendPacket(). - - - - - -Statistics on current capture. -The values represent packet statistics from the start of the run to the time of the call. - - Thrown if there is an error or the underlying packet capture doesn't support packet statistics. - - - -A network device packet communicator. - - - - -Open a generic source in order to capture / send (WinPcap only) traffic. -Uses maxmimum snapshotLength (65536), promiscuous mode and 1 second read timeout. - - - - -Open a generic source in order to capture / send (WinPcap only) traffic. - - Length of the packet that has to be retained. For each packet received by the filter, only the first 'snapshotLength' bytes are stored in the buffer and passed to the user application. For instance, snaplen equal to 100 means that only the first 100 bytes of each packet are stored. - Keeps several flags that can be needed for capturing packets. - Read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it waits for some amount of time to allow more packets to arrive and to read multiple packets from the OS kernel in one operation. Not all platforms support a read timeout; on platforms that don't, the read timeout is ignored. - Thrown on failure. - - - -List of addresses for the interface. - - - - -Interface flags. Currently the only possible flag is Loopback, that is set if the interface is a loopback interface. - - - - -if not null, a string giving a human-readable description of the device. - - - - -A string giving a name for the device. - - - - -This snapshort length value should be sufficient, on most if not all networks, to capture all the data available from the packet. - - - - -The base class of a live or offline interface. - - - - -Open a generic source in order to capture / send (WinPcap only) traffic. -Uses maxmimum snapshotLength (65536), promiscuous mode and 1 second read timeout. - - - - -Open a generic source in order to capture / send (WinPcap only) traffic. - - Length of the packet that has to be retained. For each packet received by the filter, only the first 'snapshotLength' bytes are stored in the buffer and passed to the user application. For instance, snaplen equal to 100 means that only the first 100 bytes of each packet are stored. - Keeps several flags that can be needed for capturing packets. - Read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it waits for some amount of time to allow more packets to arrive and to read multiple packets from the OS kernel in one operation. Not all platforms support a read timeout; on platforms that don't, the read timeout is ignored. - Thrown on failure. - - - -List of addresses for the interface. - - - - -Interface flags. Currently the only possible flag is Loopback, that is set if the interface is a loopback interface. - - - - -if not null, a string giving a human-readable description of the device. - - - - -A string giving a name for the device. -The name of the device is returned directly by the network card driver. - - - - -Represents a live or offline interface. - - - - -Attributes of a device. - - - - -Interface is loopback. - - - - -No attributes apply. - - - - -The ip version 6 address. - - - - -An internet protocol version 6 address for a device. - - - - -Transmit is not supported on offline captures. - - Thrown always. - - - -TotalStatistics is not supported on offline captures. - - Thrown always. - - - -Indicates the number of packets (minus 1) that must be discarded before one packet got accepted. -In other words, if 'value = 10', the first packet is returned to the caller, while the following 9 are discarded. - - - - -Constructs by giving a count. - - 1 packet out of count packets will be sampled (for each sampled packet, count-1 will be discarded). - The given count is non-positive. - - - -Defines that only 1 out of count packets must be returned to the user. -In other words, if the count is set to 10, the first packet is returned to the caller, while the following 9 are discarded. - - - - -The Pcap library version. - - - - -This class holds methods for general pcap library functionality. - - - - -The maximum legal timestamp to put in a packet. - - - - -The minimum legal timestamp to put in a packet. - - - - -Close the files associated with the capture and deallocates resources. - - - - -Open a file to write packets. -Called to open an offline capture for writing. The name "-" in a synonym for stdout. - - Specifies the name of the file to open. - -A dump file to dump packets capture by the communicator. - - Thrown on failure. - -The created dump file should be disposed by the user. -Only ISO-8859-1 characters filenames are supported. - - - - -Compile and associate a filter to a capture. -This method actually wraps a call to CreateFilter(), SetFilter() and Dispose(). - - A high level filtering expression (see WinPcap Filtering expression syntax). - Thrown on failure. - - - -Associate a filter to a capture. - - The filter to associate. Usually the result of a call to CreateFilter(). - Thrown on failure. - - - -Compile a packet filter according to the communicator IPv4 netmask. - todo bug in documentation - - A high level filtering expression (see WinPcap Filtering expression syntax) - -The compiled filter that can be applied on the communicator. - - An error occurred. - -The created filter should be disposed by the user. - - - - -Send a buffer of packets to the network. -This function transmits the content of a queue to the wire. - - Contains the packets to send. - Determines if the send operation must be synchronized: if it is true, the packets are sent respecting the timestamps, otherwise they are sent as fast as possible. - Trying to transmit to an offline device or an error occurred during the send. The error can be caused by a driver/adapter problem or by an inconsistent/bogus send buffer. - - - Using this function is more efficient than issuing a series of SendPacket(), because the packets are buffered in the kernel driver, so the number of context switches is reduced. Therefore, expect a better throughput when using Transmit(). - When isSync is true, the packets are synchronized in the kernel with a high precision timestamp. This requires a non-negligible amount of CPU, but allows normally to send the packets with a precision of some microseconds (depending on the accuracy of the performance counter of the machine). Such a precision cannot be reached sending the packets with SendPacket(). - - - - - -Send a raw packet. -This function allows to send a raw packet to the network. - - The packet to send (including the various protocol headers). The MAC CRC doesn't need to be included, because it is transparently calculated and added by the network interface driver. - The packet wasn't successfully sent. - - - -Set a flag that will force ReceiveSomePackets(), ReceivePackets() or ReceiveStatistics() to return rather than looping. -They will return the number of packets/statistics that have been processed so far, with return value BreakLoop. - - - - This routine is safe to use inside a signal handler on UNIX or a console control handler on Windows, as it merely sets a flag that is checked within the loop. - The flag is checked in loops reading packets from the OS - a signal by itself will not necessarily terminate those loops - as well as in loops processing a set of packets/statistics returned by the OS. - Note that if you are catching signals on UNIX systems that support restarting system calls after a signal, and calling Break() in the signal handler, you must specify, when catching those signals, that system calls should NOT be restarted by that signal. Otherwise, if the signal interrupted a call reading packets in a live capture, when your signal handler returns after calling Break(), the call will be restarted, and the loop will not terminate until more packets arrive and the call completes. - ReceivePacket() will, on some platforms, loop reading packets from the OS; that loop will not necessarily be terminated by a signal, so Break() should be used to terminate packet processing even if ReceivePacket() is being used. - Break() does not guarantee that no further packets/statistics will be processed by ReceiveSomePackets(), ReceivePackets() or ReceiveStatistics() after it is called; at most one more packet might be processed. - If BreakLoop is returned from ReceiveSomePackets(), ReceivePackets() or ReceiveStatistics(), the flag is cleared, so a subsequent call will resume reading packets. If a different return value is returned, the flag is not cleared, so a subsequent call will return BreakLoop and clear the flag. - - - - - -Collect a group of statistics every readTimeout given in LivePacketDevice.Open(). - - Number of statistics to process. A negative count causes ReceiveStatistics() to loop forever (or at least until an error occurs). - Specifies a routine to be called with one argument: the statistics received. - - - - Return value - description - - - Ok - Count is exhausted - - - BreakLoop - Indicates that the loop terminated due to a call to Break() before count statistics were processed. - - - - Thrown if the mode is not Statistics or an error occurred. - - - -Receives a single statistics data on packets from an interface instead of receiving the packets. -The statistics can be received in the resolution set by readTimeout when calling LivePacketDevice.Open(). - - The received statistics if it was read without problems. null otherwise. - - - - Return value - description - - - Ok - The statistics has been read without problems. In statistics mode the readTimeout is always used and it never runs on offline captures so Ok is the only valid result. - - - - Thrown if the mode is not Statistics or an error occurred. - - - -Collect a group of packets. -Similar to ReceiveSomePackets() except it keeps reading packets until count packets are processed or an error occurs. It does not return when live read timeouts occur. - - Number of packets to process. A negative count causes ReceivePackets() to loop forever (or at least until an error occurs). - Specifies a routine to be called with one argument: the packet received. - - - - Return value - description - - - Ok - Count is exhausted - - - Eof - Count wasn't exhausted and EOF was reached reading from an offline capture. - - - BreakLoop - Indicates that the loop terminated due to a call to Break() before count packets were processed. - - - - Thrown if the mode is not Capture or an error occurred. - - - -Collect a group of packets. -Used to collect and process packets. - - - - Specifies the maximum number of packets to process before returning. - This is not a minimum number; when reading a live capture, only one bufferful of packets is read at a time, so fewer than maxPackets packets may be processed. - - A maxPackets of -1 processes all the packets received in one buffer when reading a live capture, or all the packets in the file when reading an offline capture. - - Specifies a routine to be called with one argument: the packet received. - - The number of packets read is returned. - 0 is returned if no packets were read from a live capture (if, for example, they were discarded because they didn't pass the packet filter, or if, on platforms that support a read timeout that starts before any packets arrive, the timeout expires before any packets arrive, or if the communicator is in non-blocking mode and no packets were available to be read) or if no more packets are available in an offline capture. - - - - - Return value - description - - - Ok - countGot packets has been read without problems. This includes the case where a read timeout occurred and the case the communicator is in non-blocking mode and no packets were available - - - Eof - EOF was reached reading from an offline capture. - - - BreakLoop - Indicates that the loop terminated due to a call to Break() before any packets were processed. - - - - Thrown if the mode is not Capture or an error occurred. - - Only the first bytes of data from the packet might be in the received packet (which won't necessarily be the entire packet; to capture the entire packet, you will have to provide a value for snapshortLength in your call to PacketDevice.Open() that is sufficiently large to get all of the packet's data - a value of 65536 should be sufficient on most if not all networks). - When reading a live capture, ReceiveSomePackets() will not necessarily return when the read times out; on some platforms, the read timeout isn't supported, and, on other platforms, the timer doesn't start until at least one packet arrives. This means that the read timeout should NOT be used in, for example, an interactive application, to allow the packet capture loop to ``poll'' for user input periodically, as there's no guarantee that ReceiveSomePackets() will return after the timeout expires. - - - - -Read a packet from an interface or from an offline capture. -This function is used to retrieve the next available packet, bypassing the callback method traditionally provided. -The method fills the packet parameter with the next captured packet. - - The received packet if it was read without problems. null otherwise. - - - - Return value - description - - - Ok - The packet has been read without problems. - - - Timeout - The timeout set with LivePacketDevice.Open() has elapsed. In this case the packet out parameter will be null. - - - Eof - EOF was reached reading from an offline capture. In this case the packet out parameter will be null. - - - - Thrown if the mode is not Capture or an error occurred. - - - -Define a sampling method for packet capture. -This function allows applying a sampling method to the packet capture process. -The mtthod will be applied as soon as the capture starts. - - -Warning: Sampling parameters cannot be changed when a capture is active. These parameters must be applied before starting the capture. If they are applied when the capture is in progress, the new settings are ignored. -Warning: Sampling works only when capturing data on Win32 or reading from a file. It has not been implemented on other platforms. Sampling works on remote machines provided that the probe (i.e. the capturing device) is a Win32 workstation. - - The sampling method to be applied - - - -Set the minumum amount of data received by the kernel in a single call. -Changes the minimum amount of data in the kernel buffer that causes a read from the application to return (unless the timeout expires). -If the value of size is large, the kernel is forced to wait the arrival of several packets before copying the data to the user. -This guarantees a low number of system calls, i.e. low processor usage, and is a good setting for applications like packet-sniffers and protocol analyzers. -Vice versa, in presence of a small value for this variable, the kernel will copy the packets as soon as the application is ready to receive them. -This is useful for real time applications that need the best responsiveness from the kernel. - - minimum number of bytes to copy - Thrown on failure. - - - -Set the size of the kernel buffer associated with an adapter. -If an old buffer was already created with a previous call to SetKernelBufferSize(), it is deleted and its content is discarded. -LivePacketDevice.Open() creates a 1 MByte buffer by default. - - the size of the buffer in bytes - Thrown on failure. - - - -Switch between blocking and nonblocking mode. -Puts a live communicator into "non-blocking" mode, or takes it out of "non-blocking" mode. -In "non-blocking" mode, an attempt to read from the communicator with ReceiveSomePackets will, if no packets are currently available to be read, return immediately rather than blocking waiting for packets to arrive. -ReceivePacket and ReceivePackets will not work in "non-blocking" mode. - - Thrown if there is an error. - - - -The working mode of the interface. - - - - -Statistics on current capture. -The values represent packet statistics from the start of the run to the time of the call. -Supported only on live captures, not on offline. No statistics are stored in offline, so no statistics are available when reading from an offline device. - - Thrown if there is an error or the underlying packet capture doesn't support packet statistics. - - - -The minor version number of the pcap library used to write the file. - - - - -The major version number of the pcap library used to write the file. - - - - -True if the current file uses a different byte order than the current system. - - - - -The IPv4 netmask of the network on which packets are being captured; useful for filters when checking for IPv4 broadcast addresses in the filter program. If the netmask of the network on which packets are being captured isn't known to the program, or if packets are being captured on the Linux "any" pseudo-interface that can capture on more than one network, the value will be null and a filter that tests for IPv4 broadcast addreses won't be done correctly, but all other tests in the filter program will be OK. - - - - -The dimension of the packet portion (in bytes) that is delivered to the application. - - - - -List of the supported data link types of the interface associated with the packet communicator. -This property is currently unsupported to avoid memory leakage until a bug fix will be released in winpcap. - - Thrown on failure. - - - -The link layer of an adapter. - - Thrown when setting the datalink fails. - - - -Used to receive and send packets accross the network or to read and write packets to a pcap file. - - - - -This is the base sampling method class. -Every sampling method is defined by a method and an optional value, both for internal usage. - - - - -The different return values when receiving from a packet communicator. - - - - This return value should never be returned - - - The loop has been broken by a call to Break() before all the requested packets could be read. - - - EOF was reached reading from an offline capture. - - - The timeout set with Open() has elapsed when trying to read packets. - - - The packets/statistics have been read without problems. - - - -Working modes for packet communicator. - - - - Kernel dump working mode. - - - Kernel monitoring mode. - - - Statistical working mode. - - - Capture working mode. - - - -Deletes a send buffer and frees all the memory associated with it. - - - - -Adds a raw packet at the end of the send buffer. -'Raw packet' means that the sending application will have to include the protocol headers, since every packet is sent to the network 'as is'. The CRC of the packets needs not to be calculated, because it will be transparently added by the network interface. - - The packet to be added to the buffer - Thrown on failure. - - - -This function allocates a send buffer, i.e. a buffer containing a set of raw packets that will be transimtted on the network with PacketCommunicator.Transmit(). - - The size, in bytes, of the buffer, therefore it determines the maximum amount of data that the buffer will contain. - - - -Represents a buffer of packets to be sent. -Note that transmitting a send buffer is much more efficient than performing a series of Send(), because the send buffer is buffered at kernel level drastically decreasing the number of context switches. - - - - -Win32 specific. Number of packets captured, i.e number of packets that are accepted by the filter, that find place in the kernel buffer and therefore that actually reach the application. - - - - -Number of packets dropped by the interface. - - - - -Number of packets dropped by the driver. - - - - -Number of packets transited on the network. - - - - -Statistics on capture from the start of the run. - - - - -The number of bytes received during the last interval. - - - - -The number of packets received during the last interval. - - - - -The time the statistics was received. - - - - -Represents a statistics value when running in statistics mode. - - - - -Flags to use when openning a device to send and receive packets. - - - - -This flag configures the adapter for maximum responsiveness. -In presence of a large value for nbytes, WinPcap waits for the arrival of several packets before copying the data to the user. -This guarantees a low number of system calls, i.e. lower processor usage, i.e. better performance, which is good for applications like sniffers. -If the user sets this flag, the capture driver will copy the packets as soon as the application is ready to receive them. -This is suggested for real time applications (like, for example, a bridge) that need the best responsiveness. - - - - -Defines if the local adapter will capture its own generated traffic. -This flag tells the underlying capture driver to drop the packets that were sent by itself. -This is useful when building applications like bridges, that should ignore the traffic they just sent. -Note that this flag applies to the specific PacketCommunicator opened with it only. - - - - -Defines if the remote probe will capture its own generated traffic. -In case the remote probe uses the same interface to capture traffic and to send data back to the caller, -the captured traffic includes the RPCAP traffic as well. -If this flag is turned on, the RPCAP traffic is excluded from the capture, -so that the trace returned back to the collector does not include this traffic. - - - - -Defines if the data trasfer (in case of a remote capture) has to be done with UDP protocol. -Use this flag if you want a UDP data connection, don't use it if you want a TCP data connection; control connection is always TCP-based. -A UDP connection is much lighter, but it does not guarantee that all the captured packets arrive to the client workstation. -Moreover, it could be harmful in case of network congestion. -This flag is meaningless if the source is not a remote interface. In that case, it is simply ignored. - - - - -Defines if the adapter has to go in promiscuous mode. -Note that even if this parameter is false, the interface could well be in promiscuous mode for some other reason -(for example because another capture process with promiscuous mode enabled is currently using that interface). -On on Linux systems with 2.2 or later kernels (that have the "any" device), this flag does not work on the "any" device; -if an argument of "any" is supplied, the 'promisc' flag is ignored. - - - - -No flags. - - - - -Closes a savefile. - - - - -Return the file position for a "savefile". -Returns the current file position for the "savefile", representing the number of bytes written by PacketCommunicator.OpenDump() and Dump(). - - Thrown on error. - - - -Flushes the output buffer to the ``savefile,'' so that any packets written with Dump() but not yet written to the ``savefile'' will be written. - - Thrown on error. - - - -Save a packet to disk. -Outputs a packet to the "savefile" opened with PacketCommunicator.OpenDump(). - - The packet to write to disk. - - - -Creates a dump file and saves the given packets to disk. -This method is useful when you've got packets to save but no device. - - The name of the dump file. - The data link of the packets saved globally in the dump file. - The dimension of the packet portion (in bytes) that is used when writing the packets. 65536 guarantees that the whole packet will be captured on all the link layers. - The packets to save to the dump file. - - - -A file to write packets. - - - - -The description of the datalink. - - - - -The name of the datalink. - - - - -The pcap value of the datalink. - - - - -The kind of the datalink. - - - - -Create the datalink its name. - - The name of the pcap datalink. - - - -Create the datalink from an int value (pcap value). - - The pcap value of the datalink. - - - -Create the datalink from one of the well defined datalink kinds. - - The kind of datalink to create. - - - -A packet communicator datalink. - - - - -Free a filter. -Used to free up allocated memory when that BPF program is no longer needed, for example after it has been made the filter program for a packet communicator by a call to PacketCommunicator.SetFilter(). - - - - -Returns if a given filter applies to an offline packet. -This method is used to apply a filter to a packet that is currently in memory. -This process does not need to open an adapter; we need just to create the proper filter (by settings parameters like the snapshot length, or the link-layer type) by means of the Pcap. -The current API of libpcap does not allow to receive a packet and to filter the packet after it has been received. However, this can be useful in case you want to filter packets in the application, instead of into the receiving process. This function allows you to do the job. - - The packet that has to be filtered. - -True iff the given packet satisfies the filter. - - - - -Returns if a given filter applies to an offline packet. -This method is used to apply a filter to a packet that is currently in memory. -This process does not need to open an adapter; we need just to create the proper filter (by settings parameters like the snapshot length, or the link-layer type) by means of the Pcap. -The current API of libpcap does not allow to receive a packet and to filter the packet after it has been received. However, this can be useful in case you want to filter packets in the application, instead of into the receiving process. This function allows you to do the job. - - The length of the bytes that are currently available into the packet if the packet satisfies the filter, 0 otherwise. - The packet that has to be filtered. - -True iff the given packet satisfies the filter. - - - - -Compile a packet filter without the need of opening an adapter. -This constructor converts a high level filtering expression (see WinPcap Filtering expression syntax) in a program that can be interpreted by the kernel-level filtering engine. -Assumes the netmask of the network on which packets are being captured isn't known to the program, or that packets are being captured on the Linux "any" pseudo-interface that can capture on more than one network. -Tests for IPv4 broadcast addreses won't be done correctly, but all other tests in the filter program will be OK. - - A high level filtering expression (see WinPcap Filtering expression syntax) - Length of the packet that has to be retained of the communicator this filter will be applied on. - The link layer of an adapter that this filter will apply upon. - Indicates an error. Probably caused by bad syntax. - -If the purpose of this filter is to apply it on a communicator and not to test packets in memory, it would be simpler to call to PacketCommunicator.CreateFilter() or to directly call PacketCommunicator.SetFilter(). - - - - -Compile a packet filter without the need of opening an adapter. -This constructor converts a high level filtering expression (see WinPcap Filtering expression syntax) in a program that can be interpreted by the kernel-level filtering engine. - - A high level filtering expression (see WinPcap Filtering expression syntax) - Length of the packet that has to be retained of the communicator this filter will be applied on. - The link layer of an adapter that this filter will apply upon. - Specifies the IPv4 netmask of the network on which packets are being captured; it is used only when checking for IPv4 broadcast addresses in the filter program. If the netmask of the network on which packets are being captured isn't known to the program, or if packets are being captured on the Linux "any" pseudo-interface that can capture on more than one network, null can be supplied; tests for IPv4 broadcast addreses won't be done correctly, but all other tests in the filter program will be OK. - Indicates an error. Probably caused by bad syntax. - -If the purpose of this filter is to apply it on a communicator and not to test packets in memory, it would be simpler to call to PacketCommunicator.CreateFilter() or to directly call PacketCommunicator.SetFilter(). - - - - -A packet filter, converting a high level filtering expression (see WinPcap Filtering expression syntax) in a program that can be interpreted by the kernel-level filtering engine. -The user must dispose instances of this class to deallocate resources. - - - - -The ip version 4 address. - - - - -An internet protocol version 4 address for a device. - - - - -if not null, the destination address corresponding to the address in Address; may be null if the interface isn't a point-to-point interface - - - - -if not null, the broadcast address corresponding to the address in Address; may be null if the interface doesn't support broadcasts. - - - - -if not null, the netmask corresponding to the address in Address. - - - - -The Device Address. - - - - -Representation of an interface address. - - - - -Family (type) of the socket address. - - - - -The base of all device addresses. -Contains the family (type) of the address. - - - - -The type of socket address for a device address. - - - - -Bluetooth RFCOMM/L2CAP protocols - - - - -Network Designers OSI & gateway - - - - -IrDA - - - - -IEEE 1284.4 WG AF - - - - -Microsoft Wolfpack - - - - -Internetwork Version 6 - - - - -Native ATM Services - - - - -Banyan - - - - -Somebody is using this! - - - - -Protocols from Firefox - - - - -VoiceView - - - - -NetBios-style addresses - - - - -AppleTalk - - - - -NSC Hyperchannel - - - - -LAT - - - - -Direct data link interface - - - - -DECnet - - - - -IBM SNA - - - - -CCITT protocols, X.25 etc - - - - -datakit protocols - - - - -european computer manufacturers - - - - -OSI is ISO - - - - -ISO protocols - - - - -IPX protocols: IPX, SPX, etc. - - - - -XEROX NS protocols - - - - -mit CHAOS protocols - - - - -pup protocols: e.g. BSP - - - - -arpanet imp addresses - - - - -internetwork: UDP, TCP, etc. - - - - -local to host (pipes, portals) - - - - -unspecified - - - - \ No newline at end of file diff --git a/Contralto/pcap/PcapDotNet.Packets.dll b/Contralto/pcap/PcapDotNet.Packets.dll deleted file mode 100644 index dc60815..0000000 Binary files a/Contralto/pcap/PcapDotNet.Packets.dll and /dev/null differ diff --git a/Contralto/pcap/PcapDotNet.Packets.xml b/Contralto/pcap/PcapDotNet.Packets.xml deleted file mode 100644 index b33cc30..0000000 --- a/Contralto/pcap/PcapDotNet.Packets.xml +++ /dev/null @@ -1,30549 +0,0 @@ - - - - PcapDotNet.Packets - - - - - Base class for different IPv4 options. - - The option concerete type. - - - - A generic Options class. - Represents a list of options (either IPv4 options, IPv6 options or TCP options). - - The Option type this collection contains. - - - - Two options are equal iff they have the exact same options. - - - - - Two options are equal iff they have the exact same options. - - - - - The hash code is the xor of the following hash codes: number of bytes the options take and all the options. - - - - - Returns an enumerator that iterates through the collection. - - - A that can be used to iterate through the collection. - - 1 - - - - Returns an enumerator that iterates through a collection. - - - An object that can be used to iterate through the collection. - - 2 - - - - A string of all the option type names. - - - - - Returns the collection of options. - - - - - Returns the number of options. - - - - - Returns the option in the given index. - - The zero based index of the option. - The option in the given index. - - - - The number of bytes the options take. - - - - - Whether or not the options parsed ok. - - - - - TCP Alternate Checksum Data Option (RFC 1146). - - - The format of the TCP Alternate Checksum Data Option is: - 
-            +-----+--------+
-            | Bit | 0-7    |
-            +-----+--------+
-            | 0   | Kind   |
-            +-----+--------+
-            | 8   | Length |
-            +-----+--------+
-            | 16  | Data   |
-            | ... |        |
-            +-----+--------+
-
- - - - This field is used only when the alternate checksum that is negotiated is longer than 16 bits. - These checksums will not fit in the checksum field of the TCP header and thus at least part of them must be put in an option. - Whether the checksum is split between the checksum field in the TCP header and the option or the entire checksum is placed in the option - is determined on a checksum by checksum basis. - - - - The length of this option will depend on the choice of alternate checksum algorithm for this connection. - - - - While computing the alternate checksum, the TCP checksum field and the data portion TCP Alternate Checksum Data Option are replaced with zeros. - - - - - - Represents a complex TCP option. - Complex option means that it contains data and not just the type. - - - - - Represents a TCP option according to rfc 793. - - - - - Either an IPv4 option or a TCP option. - - - - - A generic option (for IPv4, IPv6 and TCP). - The option is read from buffer and can be of different length. - - - - - Returns true iff the given object is an equivalent option. - - - - - Returns true iff the given option is an equivalent option. - - - - - Returns a hash code for the option. - - - - - The number of bytes this option will take. - - - - - Checks whether two options have equivalent type. - Useful to check if an option that must appear at most once appears in the list. - - - - - True iff this option may appear at most once in a datagram. - - - - - Checks whether two options have equivalent type. - Useful to check if an option that must appear at most once appears in the list. - - - - - Checks if the two options are exactly the same - including type and value. - - - - - Checks if the two options are exactly the same - including type and value. - - - - - The hash code for a tcp option is the hash code for the option type. - This should be overridden by tcp options with data. - - - - - The string that represents the option type. - - - - - Initializes the option type. - - - - - This option code indicates the end of the option list. - This might not coincide with the end of the TCP header according to the Data Offset field. - This is used at the end of all options, not the end of each option, - and need only be used if the end of the options would not otherwise coincide with the end of the TCP header. - - - - - This option code may be used between options, - for example, to align the beginning of a subsequent option on a word boundary. - There is no guarantee that senders will use this option, - so receivers must be prepared to process options even if they do not begin on a word boundary. - - - - - The type of the TCP option. - - - - - The number of bytes this option header take. - - - - - Creates a complex option using the given option type. - - - - - This interface is used to create all complex options. - Every complex option should implement such a factory to create itself from a buffer. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The minimum number of bytes this option take. - - - - - The minimum number of bytes this option's value take. - - - - - Creates the option using the given data. - - - - - the default option data is no data. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The alternate checksum data. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - This class is used to build different packets. - Packets are built from layers. - This class can be used using static Build methods by giving the Packet's timestamp and layers. - This class can be instantiated with different layers and then use the Build method by only giving the Packet's timestamp. - If a layer that an instance of this class holds is modified, the PacketBuilder instance will create different packets. - This sample shows how to create ICMP Echo Request packets to different servers with different IP ID and ICMP sequence numbers and identifiers. - - EthernetLayer ethernetLayer = new EthernetLayer - { - Source = new MacAddress("00:01:02:03:04:05"), - Destination = new MacAddress("A0:A1:A2:A3:A4:A5") - }; - - IpV4Layer ipV4Layer = new IpV4Layer - { - Source = new IpV4Address("1.2.3.4"), - Ttl = 128, - }; - - IcmpEchoLayer icmpLayer = new IcmpEchoLayer(); - - PacketBuilder builder = new PacketBuilder(ethernetLayer, ipV4Layer, icmpLayer); - - List<Packet> packets = new List<Packet>(); - - for (int i = 0; i != 100; ++i) - { - ipV4Layer.Destination = new IpV4Address("2.3.4." + i); - ipV4Layer.Identification = (ushort)i; - icmpLayer.SequenceNumber = (ushort)i; - icmpLayer.Identifier = (ushort)i; - - packets.Add(builder.Build(DateTime.Now)); - } - - - - - - - Builds a single packet using the given layers with the given timestamp. - - The packet's timestamp. - The layers to build the packet accordingly and by their order. - A packet built from the given layers with the given timestamp. - - - - Builds a single packet using the given layers with the given timestamp. - - The packet's timestamp. - The layers to build the packet accordingly and by their order. - A packet built from the given layers with the given timestamp. - - - - Creates a PacketBuilder that can build packets according to the given layers and with different timestamps. - The layers' properties can be modified after the builder is built and this will affect the packets built. - - The layers to build the packet accordingly and by their order. - - - - Creates a PacketBuilder that can build packets according to the given layers and with different timestamps. - The layers' properties can be modified after the builder is built and this will affect the packets built. - - The layers to build the packet accordingly and by their order. - - - - Builds a single packet using the builder's layers with the given timestamp. - - The packet's timestamp. - A packet built from the builder's layers with the given timestamp. - - - - The option-type octet is viewed as having 3 fields: - - - Bits - Description - - 1 bit - - Copied flag. - - The copied flag indicates that this option is copied into all fragments on fragmentation. - - 0 = not copied. - 1 = copied. - - - - - 2 bits - - Option class. - - The option classes are: - - 0 = control. - 1 = reserved for future use. - 2 = debugging and measurement. - 3 = reserved for future use. - - - - - 5 bitsOption number. - - - - - DoD Extended Security Option (133), RFC 1108, is not supported because it only defines abstract option and no concrete option RFC is available. - EIP: The Extended Internet Protocol, RFC 1385, is not supported because according iana.org its option type is 145 but according to the RFC its option type is 138 (0x8A). - - - - - - End of Option list. - This option occupies only 1 octet; it has no length octet. - - - - - No Operation. - This option occupies only 1 octet; it has no length octet. - - - - - Record Route. - Used to trace the route an internet datagram takes. - - - - - MTU Probe. - RFCs 1063, 1191. - Obsoleted. - - - - - Quick Start (QS). RFC 4782. - - - - - Internet Timestamp. - - - - - Traceroute Using an IP Option. - RFC 1393. - - - - - DoD Basic Security: - Used to carry the classification level and protection authority flags. - - - - - Loose Source Routing. - Used to route the internet datagram based on information supplied by the source. - - - - - Strict Source Routing. - Used to route the internet datagram based on information supplied by the source. - - - - - Stream ID. - Used to carry the stream identifier. - - - - - Router Alert Option (RFC 2113). - - - - - Represents a timestamp IPv4 option with each timestamp preceded with internet address of the registering entity or the internet address fields are prespecified. - - - - - Internet Timestamp - 
-            +--------+--------+--------+--------+
-            |01000100| length | pointer|oflw|flg|
-            +--------+--------+--------+--------+
-            |         internet address          |
-            +--------+--------+--------+--------+
-            |             timestamp             |
-            +--------+--------+--------+--------+
-            |                 .                 |
-                              .
-                              .
-             Type = 68
-
- - - The Option Length is the number of octets in the option counting the type, length, pointer, and overflow/flag octets (maximum length 40). - - - - The Pointer is the number of octets from the beginning of this option to the end of timestamps plus one - (i.e., it points to the octet beginning the space for next timestamp). - The smallest legal value is 5. - The timestamp area is full when the pointer is greater than the length. - - - - The Overflow (oflw) [4 bits] is the number of IP modules that cannot register timestamps due to lack of space. - - - - The Flag (flg) [4 bits] values are - - 0 - time stamps only, stored in consecutive 32-bit words. - 1 - each timestamp is preceded with internet address of the registering entity. - 3 - the internet address fields are prespecified. - - An IP module only registers its timestamp if it matches its own address with the next specified internet address. - - - - The Timestamp is a right-justified, 32-bit timestamp in milliseconds since midnight UT. - If the time is not available in milliseconds or cannot be provided with respect to midnight UT - then any time may be inserted as a timestamp provided the high order bit of the timestamp field is set to one - to indicate the use of a non-standard value. - - - - The originating host must compose this option with a large enough timestamp data area to hold all the timestamp information expected. - The size of the option does not change due to adding timestamps. - The intitial contents of the timestamp data area must be zero or internet address/zero pairs. - - - - If the timestamp data area is already full (the pointer exceeds the length) the datagram is forwarded without inserting the timestamp, - but the overflow count is incremented by one. - If there is some room but not enough room for a full timestamp to be inserted, or the overflow count itself overflows, - the original datagram is considered to be in error and is discarded. - In either case an ICMP parameter problem message may be sent to the source host. - - - - The timestamp option is not copied upon fragmentation. - It is carried in the first fragment. - Appears at most once in a datagram. - - - - - - Represents a complex IPv4 option. - Complex option means that it contains data and not just the type. - - - - - Represents an ip option according to rfc 791. - - - - - Checks whether two options have equivalent type. - Useful to check if an option that must appear at most once appears in the list. - - - - - Checks if the two options are exactly the same - including type and value. - - - - - Checks if the two options are exactly the same - including type and value. - - - - - The hash code of the option is the hash code of the option type. - - - - - - The string of the option is the string of the option type. - - - - - Constructs the option by type. - - - - - This option indicates the end of the option list.
- This might not coincide with the end of the internet header according to the internet header length. - This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the internet header. - May be copied, introduced, or deleted on fragmentation, or for any other reason. - - - - - This option may be used between options, for example, to align the beginning of a subsequent option on a 32 bit boundary. - May be copied, introduced, or deleted on fragmentation, or for any other reason. - - - - - The type of the IP option. - - - - - The header length in bytes for the option (type and size). - - - - - Constructs the option by type. - - - - - The minimum length in bytes for the option (type, length, pointer, overflow and flags). - - - - - The minimum length in bytes of the option value. - - - - - The maximum value for the overflow field. - - - - - The maximum value for the pointed index field. - - - - - Two options are equal if they have the same value (timestamp, overflow, pointed equals, addresses and timestamps). - - - - - Two options are equal if they have the same value (timestamp, overflow, pointed equals and addresses). - - - - - Create the option by giving it all the data. - - The timestamp option type. - The number of IP modules that cannot register timestamps due to lack of space. Maximum value is 15. - The index in the timestamp to points to the octet beginning the space for next timestamp. The timestamp area is considered full when the index points beyond the timestamps. - - - - True iff the options values is equal. - - - - - Writes the value of the option to the buffer. - - - - - The timestamp option type. - - - - - The number of IP modules that cannot register timestamps due to lack of space. - - - - - The index in the timestamp that points to the for next timestamp. - The timestamp area is considered full when the index points beyond the timestamps. - - - - - The number of timestamps this option holds (or can hold). - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - The number of bytes the value of the option take. - - - - - Create the option by giving it all the data. - - The timestamp option type. - The number of IP modules that cannot register timestamps due to lack of space. Maximum value is 15. - The index in the timestamp that points to the for next timestamp. - The pairs of addresses and timestamps where each timestamp time passed since midnight UT. - - - - Create the option by giving it all the data. - - The timestamp option type. - The number of IP modules that cannot register timestamps due to lack of space. Maximum value is 15. - The index in the timestamp that points to the for next timestamp. - The pairs of addresses and timestamps where each timestamp time passed since midnight UT. - - - - True iff the options values is equal. - - - - - Writes the value of the option to the buffer. - - - - - The number of timestamps this option holds (or can hold). - - - - - The pairs of addresses and timestamps where each timestamp time passed since midnight UT. - - - - - The number of bytes the value of the option take. - - - - - Set of Mobility options for IPv6 Mobility Extension Header. - - - - - Base class for different IPv6 options types. - - The option concrete type. - - - - Creates options from a list of options. - - The list of options. - - - - Creates options from a list of options. - - The list of options. - - - - Creates options from a list of options. - - The list of options. - - - - No options instance. - - - - - RFC 5096. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Data                       |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Value                      |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - RFC 6275. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Option Data                |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Option Type | Opt Data Len (optional) |
-            +-----+-------------+-------------------------+
-            | 16  | Option Data (optional)                |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Returns true iff the given option is an equivalent option. - - - - - Returns true iff the given option is an equivalent option. - - - - - Returns a hash code for the option. - - - - - The type of the IP option. - - - - - True iff parsing of this option didn't encounter issues. - - - - - The number of bytes the option takes. - - - - - Creates an option from the given data. - - Data related to the experimental protocol extension. - - - - Data related to the experimental protocol extension. - - - - - RFC 5846. - 
-            +-----+---+---+---+-----+-------------------------+
-            | Bit | 0 | 1 | 2 | 3-7 | 8-15                    |
-            +-----+---+---+---+-----+-------------------------+
-            | 0   | Next Header     | Header Extension Length |
-            +-----+-----------------+-------------------------+
-            | 16  | MH Type         | Reserved                |
-            +-----+-----------------+-------------------------+
-            | 32  | Checksum                                  |
-            +-----+-----------------+-------------------------+
-            | 48  | B.R. Type       | R. Trigger              |
-            +-----+-----------------+-------------------------+
-            | 64  | Sequence #                                |
-            +-----+---+---+---+-------------------------------+
-            | 80  | P | V | G | Reserved                      |
-            +-----+---+---+---+-------------------------------+
-            | 96  | Mobility Options                          |
-            | ... |                                           |
-            +-----+-------------------------------------------+
-
- - - - - RFC 5846. - 
-            +-----+---+---+---+-----+-------------------------+
-            | Bit | 0 | 1 | 2 | 3-7 | 8-15                    |
-            +-----+---+---+---+-----+-------------------------+
-            | 0   | Next Header     | Header Extension Length |
-            +-----+-----------------+-------------------------+
-            | 16  | MH Type         | Reserved                |
-            +-----+-----------------+-------------------------+
-            | 32  | Checksum                                  |
-            +-----+-----------------+-------------------------+
-            | 48  | B.R. Type       | R. Trigger or Status    |
-            +-----+-----------------+-------------------------+
-            | 64  | Sequence #                                |
-            +-----+---+---+---+-------------------------------+
-            | 80  | P | V | G | Reserved                      |
-            +-----+---+---+---+-------------------------------+
-            | 96  | Mobility Options                          |
-            | ... |                                           |
-            +-----+-------------------------------------------+
-
- - - - - RFC 3775, 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Message Data                          |
-            | ... | ends with Mobility Options            |
-            +-----+---------------------------------------+
-
- - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | Data                                  |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - RFC 2460. - - - - - True iff the given extension header is equal to this extension header. - - - - - True iff the given extension header is equal to this extension header. - - - - - Returns a hash code of the extension header. - - - - - Identifies the type of this extension header. - - - - - Identifies the type of header immediately following this extension header. - If the extension header is constructed with null NextHeader, it would be auto calculated according to the next extension or next layer when writing - the layer. - - - - - The number of bytes this extension header takes. - - - - - List of all extension header protocols. - - - - - True iff the extension header parsing didn't encounter an issue. - - - - - The minimum number of bytes the extension header takes. - - - - - True iff the given extension header is equal to this extension header. - - - - - Returns a hash code of the extension header. - - - - - The number of bytes this extension header takes. - - - - - The minimum number of bytes this extension header takes. - - - - - Identifies the type of this extension header. - - - - - True iff the extension header parsing didn't encounter an issue. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - The pseudo-header contains IPv6 header fields. - The Next Header value used in the pseudo-header is 135. - The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet - carrying the Mobility Header. - - - Note that the procedures of calculating upper-layer checksums while away from home apply even for the Mobility Header. - If a mobility message has a Home Address destination option, then the checksum calculation uses the home address in this option as the value of the IPv6 Source Address field. - - - The Mobility Header is considered as the upper-layer protocol for the purposes of calculating the pseudo-header. - The Upper-Layer Packet Length field in the pseudo-header MUST be set to the total length of the Mobility Header. - - - For computing the checksum, the checksum field is set to zero. - - - - - - Zero or more TLV-encoded mobility options. - - - - - The minimum number of bytes the message data takes. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Defines the type of the Binding Revocation Message. - - - - - In indication, used by the initiator to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. - This sequence number could be a random number. - At any time, implementations must ensure there is no collision between the sequence numbers of all outstanding Binding Revocation Indication - Messages. - In acknowledgement, copied from the Sequence Number field in the Binding Revocation Indication. - It is used by the initiator, e.g., HA, LMA, MAG, in matching this Binding Revocation Acknowledgement - with the outstanding Binding Revocation Indication. - - - - - In indication, set by the initiator to indicate that the revoked binding(s) is a PMIPv6 binding. - In acknowledgement, set if set in the corresponding Binding Revocation Indication message. - - - - - In indication, Set by the initiator, home agent, or local mobility anchor to indicate to the receiving mobility entity the termination - of the IPv4 Home Address binding only as in Home Agent Operation and Local Mobility Anchor Operation. - In acknowledgement, set if the it is set in the corresponding Binding Revocation Indication message. - - - - - In indication, Set by the initiator, LMA or MAG, to indicate the termination of all Per-Peer mobility Bindings or Multiple Bindings that share - a common identifier(s) and are served by the initiator and responder as in Local Mobility Anchor Operation and Mobile Access Gateway Operation. - In acknowledgement, set if it is set in the corresponding Binding Revocation Indication message. - - - - - Creates an instance from next header, checksum, revocation trigger, sequence number, proxy binding, IPv4 home address binding only, global - and options. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Indicating the event that triggered the initiator to send the BRI message. - - - Used by the initiator to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. - This sequence number could be a random number. - At any time, implementations must ensure there is no collision between the sequence numbers of all outstanding Binding Revocation Indication - Messages. - - - Set by the initiator to indicate that the revoked binding(s) is a PMIPv6 binding. - - - Set by the initiator, home agent, or local mobility anchor to indicate to the receiving mobility entity the termination - of the IPv4 Home Address binding only as in Home Agent Operation and Local Mobility Anchor Operation. - - - Set by the initiator, LMA or MAG, to indicate the termination of all Per-Peer mobility Bindings or Multiple Bindings that share - a common identifier(s) and are served by the initiator and responder as in Local Mobility Anchor Operation and Mobile Access Gateway Operation. - - - Zero or more TLV-encoded mobility options. - - - - - Defines the type of the Binding Revocation Message. - - - - - Indicating the event that triggered the initiator to send the BRI message. - - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+-------------+-------------------------+
-            | 48  | Status      | Reserved                |
-            +-----+-------------+-------------------------+
-            | 64  | Home Address                          |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            +-----+---------------------------------------+
-            | 192 | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, status, home address and options. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Indicating the reason for this message. - - The home address that was contained in the Home Address destination option. - The mobile node uses this information to determine which binding does not exist, in cases where the mobile node has several home addresses. - - - Zero or more TLV-encoded mobility options. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Indicating the reason for this message. - - - - - The home address that was contained in the Home Address destination option. - The mobile node uses this information to determine which binding does not exist, in cases where the mobile node has several home addresses. - - - - - Represents an ICMP layer with an unknown message type. - - - - - - Represents an ICMP layer. - - - - - - A simple layer is a layer that doesn't care what is the length of its payload, what layer comes after it and what layer comes before it. - - - - - The base class of a layer used to build a Packet. - Each layer represents the part of the packet relevant to a specific protocol. - A sequence of layers can represent a packet. - A packet can be according to a sequence of layers. - - - - - - The interface of a layer used to build a Packet. - Each layer represents the part of the packet relevant to a specific protocol. - A sequence of layers can represent a packet. - A packet can be according to a sequence of layers. - - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Finalizes the layer data in the buffer. - Used for fields that must be calculated according to the layer's payload (like checksum). - - The buffer to finalize the layer in. - The offset in the buffer the layer starts. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes after this layer. null if this is the last layer. - - - - The number of bytes this layer will take. - - - - - The kind of the data link of the layer. - Can be null if this is not the first layer in the packet. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Finalizes the layer data in the buffer. - Used for fields that must be calculated according to the layer's payload (like checksum). - - The buffer to finalize the layer in. - The offset in the buffer the layer starts. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes after this layer. null if this is the last layer. - - - - True iff the two objects are equal Layers. - - - - - True iff the two objects are equal Layers. - - - - - Returns a hash code for the layer. - The hash code base is a XOR of the hash codes of the layer length and data link. - - - - - The number of bytes this layer will take. - - - - - The kind of the data link of the layer. - Can be null if this is not the first layer in the packet. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Writes the layer to the buffer. - This method ignores the payload length, and the previous and next layers. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - A layer under an IP layer. - Must provide the IPv4 Protocol. - - - - - The protocol that should be written in the previous (IPv4) layer. - - - - - Writes the layer to the buffer. - This method ignores the payload length, and the previous and next layers. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - Writes the ICMP payload to the buffer. - Doesn't include payload in the next layers. - - The buffer to write the ICMP payload to. - The offset in the buffer to start writing the payload at. - - - - Finalizes the layer data in the buffer. - Used for the ICMP checksum. - - The buffer to finalize the layer in. - The offset in the buffer the layer starts. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes after this layer. null if this is the last layer. - - - - ICMP layers are equal if they have the same message type, code, checksum, variable and payload. - - - - - ICMP layers are equal if they have the same message type, code, checksum, variable and payload. - - - - - Returns a hash code for the layer. - The hash code is a XOR of the layer length, data link, message type and code, checksum and variable. - - - - - Returns a string containing the message type, code and variable. - - - - - True iff the ICMP payload is equal to the other ICMP payload. - - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - A combination of the ICMP Message Type and Code. - - - - - The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. - For computing the checksum, the checksum field should be zero. - This checksum may be replaced in the future. - null means that this checksum should be calculated to be correct. - - - - - A value that should be interpreted according to the specific message. - - - - - The number of bytes this layer will take. - - - - - The number of bytes the ICMP payload takes. - - - - - The protocol that should be written in the previous (IPv4) layer. - - - - - Writes the ICMP payload to the buffer. - Doesn't include payload in the next layers. - - The buffer to write the ICMP payload to. - The offset in the buffer to start writing the payload at. - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - A value that should be interpreted according to the specific message. - - - - - The payload of the ICMP. - All the data without the ICMP header. - - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - The number of bytes the ICMP payload takes. - - - - - A value that should be interpreted according to the specific message. - - - - - Used to represent an ICMP datagram with an unknown message type. - - - - - Generic - 
-            +-----+------+------+-----------+
-            | Bit | 0-7  | 8-15 | 16-31     |
-            +-----+------+------+-----------+
-            | 0   | Type | Code | Checksum  |
-            +-----+------+------+-----------+
-            | 32  | Value according to Type |
-            +-----+-------------------------+
-            | 64  | Payload                 |
-            | ... |                         |
-            +-----+-------------------------+
-
- - - - - Represents a packet datagram. - A datagram is part of the packet bytes that can be treated as a specific protocol data (usually header + payload). - Never copies the given buffer. - - - - - Represents segement of a byte array. - Never copies the given buffer. - - - - - Take all the bytes as a segment. - - The buffer to take as a segment. - - - - Take only part of the bytes as a segment. - - The bytes to take the segment from. - The offset in the buffer to start taking the bytes from. - The number of bytes to take. - - - - Creates a subsegment starting from a given offset in the segment taking a given number of bytes. - - The offset in the segment to start taking. - The number of bytes to take from the segment. - A new DataSegment that is part of the given DataSegment. - - - - Returns the Segment's bytes as a read only MemoryStream with a non-public buffer. - - A read only MemoryStream containing the bytes of the segment. - - - - Iterate through all the bytes in the segment. - - - - - Two segments are equal if they have the same data. - - - - - Two segments are equal if they have the same data. - - - - - The hash code of a segment is the hash code of its length xored with all its bytes (each byte is xored with the next byte in the integer). - - - - - Creates a string starting with the number of bytes the data segment contains - and ending with the first 10 bytes of the data segment as hexadecimal digits. - - - A string starting with the number of bytes the data segment contains - and ending with the first 10 bytes of the data segment as hexadecimal digits. - - - - - Converts the segment to a hexadecimal string representing every byte as two hexadecimal digits. - - A hexadecimal string representing every byte as two hexadecimal digits. - - - - Converts the segment to a string using the given encoding. - - The encoding to use to convert the bytes sequence in the segment to a string. - A string of the bytes in the segment converted using the given encoding. - - - - Reads a requested number of bytes from a specific offset in the segment. - - The offset in the segment to start reading. - The number of bytes to read. - The bytes read from the segment starting from the given offset and in the given length. - - - - Reads 2 bytes from a specific offset in the segment as a ushort with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 3 bytes from a specific offset in the segment as a UInt24 with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset in the segment as an int with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset in the segment as a uint with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 6 bytes from a specific offset in the segment as a UInt48 with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 6 bytes from a specific offset in the segment as a MacAddress with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset in the segment as an IpV4Address with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset in the segment as an IpV4TimeOfDay with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset in the segment as an IpV4Address with a given endianity. - - The offset in the segment to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Converts the given 16 bits sum to a checksum. - Sums the two 16 bits in the 32 bits value and if the result is bigger than a 16 bits value repeat. - The result is one's complemented and the least significant 16 bits are taken. - - - - - - - Sums bytes in a buffer as 16 bits big endian values. - If the number of bytes is odd then a 0x00 value is assumed after the last byte. - Used to calculate checksum. - - The buffer to take the bytes from. - The offset in the buffer to start reading the bytes. - The number of bytes to read. - A value equals to the sum of all 16 bits big endian values of the given bytes. - - - - The number of bytes in this segment. - - - - - The value of the byte in the given offset in the segment. - - The offset in the segment to take the byte from. - - - - Returns the last byte of the segment. - - - - - An empty DataSegment. - - - - - The original buffer that holds all the data for the segment. - - - - - The offset of the first byte of the segment in the buffer. - - - - - Take all the bytes as a datagram. - - The buffer to take as a datagram. - - - - Take only part of the bytes as a datagram. - - The bytes to take the datagram from. - The offset in the buffer to start taking the bytes from. - The number of bytes to take. - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - The default validity check always returns true. - - - - - An empty datagram. - Useful for empty payloads. - - - - - A datagram is checked for validity according to the protocol. - - - - - The number of bytes the ICMP header takes. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - ICMP is valid if the datagram's length is OK, the checksum is correct and the code is in the expected range. - - - - - Creates an IcmpDatagram from a buffer according to the message type. - - The buffer of the datagram. - The offset where the datagram starts. - The length of the datagram in the buffer. - An IcmpDatagram according to the Icmp message type. - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - A combination of the ICMP Message Type and Code. - - - - - The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. - For computing the checksum, the checksum field should be zero. - This checksum may be replaced in the future. - - - - - A value that should be interpreted according to the specific message. - - - - - True iff the checksum value is correct according to the datagram data. - - - - - The payload of the ICMP. - All the data without the header. - - - - - The minimum valid ICMP code for this type of ICMP datagram. - - - - - The maximum valid ICMP code for this type of ICMP datagram. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Unknown ICMP datagrams are always invalid. - - - - - Take only part of the bytes as a datagarm. - - The bytes to take the datagram from. - The offset in the buffer to start taking the bytes from. - The number of bytes to take. - - - - RFC 1393. - 
-            +-----+------+-------------+------------------+
-            | Bit | 0-7  | 8-15        | 16-31            |
-            +-----+------+-------------+------------------+
-            | 0   | Type | Code        | Checksum         |
-            +-----+------+-------------+------------------+
-            | 32  | ID Number          | unused           |
-            +-----+--------------------+------------------+
-            | 64  | Outbound Hop Count | Return Hop Count |
-            +-----+--------------------+------------------+
-            | 96  | Output Link Speed                     |
-            +-----+---------------------------------------+
-            | 128 | Output Link MTU                       |
-            +-----+---------------------------------------+
-
- - - - - The number of bytes this datagram should take. - - - - - The number of bytes this ICMP payload should take. - - - - - The value the Return Hop Count should be for an outbound ICMP packet. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if the datagram's length is OK, the checksum is correct and the code is in the expected range. - - - - - The ID Number as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. - This is NOT related to the ID number in the IP header. - - - - - The Outbound Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. - - - - - The Return Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. - - - - - The speed, in OCTETS per second, of the link over which the Outbound/Return Packet will be sent. - Since it will not be long before network speeds exceed 4.3Gb/s, and since some machines deal poorly with fields longer than 32 bits, octets per second was chosen over bits per second. - If this value cannot be determined, the field should be set to zero. - - - - - The MTU, in bytes, of the link over which the Outbound/Return Packet will be sent. - MTU refers to the data portion (includes IP header; excludes datalink header/trailer) of the packet. - If this value cannot be determined, the field should be set to zero. - - - - - Is the packet an Outbound packet. - This is indicated by a value of 0xFFFF in the ReturnHopCount field. - - - - - The minimum valid ICMP code for this type of ICMP datagram. - - - - - The maximum valid ICMP code for this type of ICMP datagram. - - - - - RFC 1256. - 
-            +-----+-----------+-----------------+----------+
-            | Bit | 0-7       | 8-15            | 16-31    |
-            +-----+-----------+-----------------+----------+
-            | 0   | Type      | Code            | Checksum |
-            +-----+-----------+-----------------+----------+
-            | 32  | Num Addrs | Addr Entry Size | Lifetime |
-            +-----+-----------+-----------------+----------+
-            | 64  | Router Address[1]                      |
-            +-----+----------------------------------------+
-            | 96  | Preference Level[1]                    |
-            +-----+----------------------------------------+
-            | 128 | Router Address[2]                      |
-            +-----+----------------------------------------+
-            | 160 | Preference Level[2]                    |
-            +-----+----------------------------------------+
-            |  .  |                   .                    |
-            |  .  |                   .                    |
-            |  .  |                   .                    |
-
- - - - - The default number of 32-bit words of information per each router address. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if the datagram's length is OK, the checksum is correct, the code is in the expected range - and the address entry size is the default address entry size. - - - - - The number of router addresses advertised in this message. - - - - - The number of 32-bit words of information per each router address (2, in the version of the protocol described here). - - - - - The maximum number of seconds that the router addresses may be considered valid. - - - - - The maximum time that the router addresses may be considered valid. - - - - - The pairs of sending router's IP address(es) on the interface from which this message is sent - and the preferability of each Router Address[i] as a default router address, relative to other router addresses on the same subnet. - A signed, twos-complement value; higher values mean more preferable. - - - - - RFC 1256. - An ICMP Router Advertisement layer. - - - - - - Writes the ICMP payload to the buffer. - Doesn't include payload in the next layers. - - The buffer to write the ICMP payload to. - The offset in the buffer to start writing the payload at. - - - - True iff the Entries are equal to the other ICMP entries. - - - - - True iff the Entries are equal to the other ICMP entries. - - - - - The maximum time that the router addresses may be considered valid. - - - - - The pairs of sending router's IP address(es) on the interface from which this message is sent - and the preferability of each Router Address[i] as a default router address, relative to other router addresses on the same subnet. - A signed, twos-complement value; higher values mean more preferable. - - - - - The value of this field determines the format of the remaining data. - - - - - A value that should be interpreted according to the specific message. - - - - - The number of bytes the ICMP payload takes. - - - - - Represents an ICMP layer with an Identifier and a Sequence Number. - - - - - An identifier to aid in matching requests and replies, may be zero. - - - - - A sequence number to aid in matching requests and replies, may be zero. - - - - - A value that should be interpreted according to the specific message. - - - - - RFC 2616. - The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, - in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. - - - - - An HTTP field with a name and value. - - - - - Creates a field according to the field name and value. - - The name of the field to create. - The bytes value of the field to create. - The constructed HTTP field. - - - - Creates a field according to the field name and encoded string value. - - The name of the field to create. - The value of the field to create encoded in the given encoding. - The encoding that encodes the given field value. - The constructed HTTP field. - - - - Creates a field according to the field name and encoded string value. - - The name of the field to create. - The value of the field to create encoded in ISO-8859-1 encoding. - The constructed HTTP field. - - - - True iff the two HTTP fields are of equal value. - Two fields are equal iff they have the same name (case insensitive) and the same bytes value. - - - - - True iff the two HTTP fields are of equal value. - Two fields are equal iff they have the same name (case insensitive) and the same bytes value. - - - - - Returns a hash code of this field according to the name and value. - - - - - A string representing the field similar to how it would like in the HTTP protocol. - - - - - - The name of the field. - - - - - The Value of the field. - - - - - The Value of the field as a string using ISO-8859-1 encoding. - - - - - The number of bytes the field will take in the HTTP protocol. - - - - - The field name. - - - - - The field name in uppercase. - - - - - Creates a Content Length Field according to a given content length. - - - The size of the entity-body, in decimal number of OCTETs, sent to the recipient or, - in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. - - - - - The size of the entity-body, in decimal number of OCTETs, sent to the recipient or, - in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. - - - - - A layer that contains an ARP layer. - Must provide the ARP hardware type. - - - - - The ARP Hardware Type of the layer before the ARP layer. - - - - - Eastlake. - - - - - Undefined value. - - - - - The SNMP subset of ASN.1. - - - - - OSI ASN.1 1990 [ASN.1]. - - - - - OSI ASN.1 1994. - - - - - Private abstract syntax notations. - This coding value will not be assigned to a standard abstract syntax notation. - An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used. - - - - - DNS RRs. - The data portion consists of DNS resource records as they would be transmitted in a DNS response section. - The subcoding octet is the number of RRs in the data area as an unsigned integer. - Domain names may be compressed via pointers as in DNS replies. - The origin for the pointers is the beginning of the RDATA section of the SINK RR. - Thus the SINK RR is safe to cache since only code that knows how to parse the data portion need know of and can expand these compressions. - - - - - MIME structured data [RFC 2045, 2046]. - The data portion is a MIME structured message. - The "MIME-Version:" header line may be omitted unless the version is other than "1.0". - The top level Content-Transfer-Encoding may be encoded into the subcoding octet. - Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. - - - - - Text tagged data. - The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item - is considered to be a tag labeling the immediately following text item. - If there are an odd number of text items overall, then the last is considered to label a null text item. - Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). - Thus any organization with a domain name can assign tags without fear of conflict. - - - - - Private formats indicated by a URL. - The format of the data portion is indicated by an initial URL [RFC 1738] which is terminated by a zero valued octet - followed by the data with that format. - The subcoding octet is available for whatever use the private formating wishes to make of it. - The manner in which the URL specifies the format is not defined but presumably the retriever will recognize the URL or the data it points to. - - - - - Faltstrom. - 
-            +-----+----------+--------+
-            | bit | 0-15     | 16-31  |
-            +-----+----------+--------+
-            | 0   | Priority | Weight |
-            +-----+----------+--------+
-            | 32  | Target            |
-            | ... |                   |
-            +-----+-------------------+
-
- - - - - A DNS resource record type that any domain name that it contains should not be compressed when written and cannot decompress them when reads them. - - - - - A DNS resource record type that any domain name that it contains should not be compressed when written. - - - - - RFC 1035. - Represents a resource record data. - - - - - Returns the DnsResourceData concrete type that should be created for the given DnsType. - - - - - Constructs an instance out of the priority, weight and target fields. - - - The priority of the target URI in this RR. - A client must attempt to contact the URI with the lowest-numbered priority it can reach; - URIs with the same priority should be tried in the order defined by the weight field. - - - A server selection mechanism. - The weight field specifies a relative weight for entries with the same priority. - Larger weights should be given a proportionately higher probability of being selected. - - The URI of the target. Resolution of the URI is according to the definitions for the Scheme of the URI. - - - - Two DnsResourceDataUri are equal iff their priority, weight and target fields are equal. - - - - - Two DnsResourceDataUri are equal iff their priority, weight and target fields are equal. - - - - - A hash code of the combination of the priority, weight and target fields. - - - - - The priority of the target URI in this RR. - A client must attempt to contact the URI with the lowest-numbered priority it can reach; - URIs with the same priority should be tried in the order defined by the weight field. - - - - - A server selection mechanism. - The weight field specifies a relative weight for entries with the same priority. - Larger weights should be given a proportionately higher probability of being selected. - - - - - The URI of the target. - Resolution of the URI is according to the definitions for the Scheme of the URI. - - - - - Wijngaards. - 
-            +----------------------+
-            | Previous Domain Name |
-            +----------------------+
-            | Next Domain Name     |
-            +----------------------+
-
- - - - - Constructs the resource data from the previous and next fields. - - The start, or previous name. - End or next name in the list. - - - - Two trust anchor link resource datas are equal iff their previous and next fields are equal. - - - - - Two trust anchor link resource datas are equal iff their previous and next fields are equal. - - - - - The combined hash code of the previous and next fields. - - - - - The start, or previous name. - - - - - End or next name in the list. - - - - - RFC 1706. - 
-            +-----+-----+----------------------+----------+-----------+
-            | bit | 0-7 | 8-7+X                | 8+X-55+X | 56+X-63+X |
-            +-----+-----+----------------------+----------+-----------+
-            | 0   | AFI | Domain Specific Area | ID       | Sel       |
-            +-----+-----+-----+----------------+----------+-----------+
-            | 0   | AFI | IDI | HO-DSP         | ID       | Sel       |
-            +-----+-----+-----+----------------+----------+-----------+
-            | 0   | Area Address               | ID       | Sel       |
-            +-----+-----------+----------------+----------+-----------+
-            | 0   | IDP       | DSP                                   |
-            +-----+-----------+---------------------------------------+
-
- IDP is Initial Domain Part. - DSP is Domain Specific Part. - HO-DSP may use any format as defined by the authority identified by IDP. - - - - - Constructs an instance out of the area address, system identifier and selector fields. - - - The combination of [IDP, HO-DSP] identify both the routing domain and the area within the routing domain. - Hence the combination [IDP, HO-DSP] is called the "Area Address". - All nodes within the area must have same Area address. - - System Identifier. - NSAP Selector. - - - - Two DnsResourceDataNetworkServiceAccessPoint are iff their area address, system identifier and selector fields are equal. - - - - - Two DnsResourceDataNetworkServiceAccessPoint are iff their area address, system identifier and selector fields are equal. - - - - - A hash code of the combination of the area address, system identifier and selector fields. - - - - - Authority and Format Identifier. - - - - - The combination of [IDP, HO-DSP] identify both the routing domain and the area within the routing domain. - Hence the combination [IDP, HO-DSP] is called the "Area Address". - All nodes within the area must have same Area address. - - - - - System Identifier. - - - - - NSAP Selector. - - - - - RFC 1035. - 
-            +-----+
-            | CPU |
-            +-----+ 
-            | OS  |
-            +-----+
-
- - - - - Base class for any resource data that contains DNS strings. - Each DNS string is a segment of up to 255 bytes. - The format of each DNS string is one byte for the length of the string and then the specified number of bytes. - - - - - Two strings resources datas are equal if they are of the same concrete type and their strings are equal and in the same order. - - - - - Two strings resources datas are equal if they are of the same concrete type and their strings are equal and in the same order. - - - - - A hash code based on the concrete type and the strings. - - - - - Constructs the resource data from the CPU and OS parameters. - - A string which specifies the CPU type. - A string which specifies the operating system type. - - - - A string which specifies the CPU type. - - - - - A string which specifies the operating system type. - - - - - Identifies the public key's cryptographic algorithm and determines the format of the public key field. - - - - - Indicates that no key is present. - - - - - A DSA key is present, in the format defined in RFC 2536. - - - - - A RSA key is present, in the format defined in RFC 3110 with the following changes: - The earlier definition of RSA/MD5 in RFC 2065 limited the exponent and modulus to 2552 bits in length. - RFC 3110 extended that limit to 4096 bits for RSA/SHA1 keys - The IPSECKEY RR imposes no length limit on RSA public keys, other than the 65535 octet limit imposed by the two-octet length encoding. - This length extension is applicable only to IPSECKEY; it is not applicable to KEY RRs. - - - - - The type of digest that is used to create a digest value. - - - - - No definition for digest type. - Should not be used. - - - - - RFC 3658. - SHA-1. - - - - - RFC 4509. - SHA-256. - - - - - RFC 5933. - GOST R 34.11-94. - - - - - RFCs 2535, 2536, 2537, 2539, 3110, 3755, 4034, 5155, 5702, 5933. - The key algorithm. - - - - - RFC 4034. - Field is not used or indicates that the algorithm is unknown to a secure DNS, - which may simply be the result of the algorithm not having been standardized for DNSSEC. - - - - - RFCs 2537, 4034. - RSA/MD5. - Deprecated. - - - - - RFC 2539. - Diffie-Hellman. - Implementation is optional, key only. - - - - - RFCs 2536, 3755. - DSA - Digital Signature Algorithm. - Implementation is mandatory. - - - - - Reserved for elliptic curve crypto. - - - - - RFCs 3110, 3755. - RSA/SHA-1. - - - - - RFC 5155. - DSA-NSEC3-SHA1. - - - - - RFC 5155. - RSASHA1-NSEC3-SHA1. - - - - - RFC 5702. - RSA/SHA-256. - - - - - RFC 5702. - RSA/SHA-512. - - - - - RFC 5933. - GOST R 34.10-2001. - - - - - RFC 4034. - Reserved for Indirect Keys. - - - - - RFCs 2535, 3755. - Private algorithms - domain name. - - - - - RFCs 2535, 3755. - Private algorithms - OID. - - - - - IEEE P802.1p. - Eight different classes of service are available as expressed through the 3-bit PCP field in an IEEE 802.1Q header added to the frame. - The way traffic is treated when assigned to any particular class is undefined and left to the implementation. - - - - - BE. - Best Effort. - - - - - BK. - Background. - Lowest. - - - - - EE. - Excellent Effort. - - - - - CA. - Critical Applications. - - - - - VI. - Video - Under 100 ms latency. - - - - - VO. - Voice. - Under 10 ms latency. - - - - - IC. - Internetwork Control. - - - - - NC. - Network Control. - Highest. - - - - - RFC 768. - This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication - in the environment of an interconnected set of computer networks. - This protocol assumes that the Internet Protocol (IP) is used as the underlying protocol. - - - This protocol provides a procedure for application programs to send messages to other programs - with a minimum of protocol mechanism. - The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. - Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP). - - - - Format - 
-             0      7 8     15 16    23 24    31
-            +--------+--------+--------+--------+
-            |     Source      |   Destination   |
-            |      Port       |      Port       |
-            +--------+--------+--------+--------+
-            |                 |                 |
-            |     Length      |    Checksum     |
-            +--------+--------+--------+--------+
-            |
-            |          data octets ...
-            +---------------- ...
-
- - - - - - Contains the common part of UDP and TCP. - - - Format: - 
-            +-----+-------------+----------+-----+-----+-----+-----+-----+-----+------------------+
-            | Bit | 0-4         | 4-9      | 10  | 11  | 12  | 13  | 14  | 15  | 16-31            |
-            +-----+-------------+----------+-----+-----+-----+-----+-----+-----+------------------+
-            | 0   | Source Port                                                | Destination Port |
-            +-----+------------------------------------------------------------+------------------+
-            | 32  | Sequence Number                                                               |
-            +-----+-------------------------------------------------------------------------------+
-
- - - - - - Indicates the port of the sending process. - In UDP, this field is optional and may only be assumed to be the port - to which a reply should be addressed in the absence of any other information. - If not used in UDP, a value of zero is inserted. - - - - - Destination Port has a meaning within the context of a particular internet destination address. - - - - - Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, - the Transport header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. - - - - - True iff the checksum for the transport type is optional. - - - - - The payload of the transport datagram. - - - - - The number of bytes the datagram header takes. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - A udp datagram is valid if it has a full header. - - - - - The length in octets of this user datagram including this header and the data. - (This means the minimum value of the length is eight.) - - - - - Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, - the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. - - - - - True iff the checksum for the transport type is optional. - - - - - The payload of the UDP datagram. - - - - - The payload of the datagram as a DNS datagram. - - - - - A Transport layer under an IP layer. - Must supply information about the Transport layer checksum. - - - - - Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, - the Transport header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. - If null is given, the Checksum will be calculated to be correct according to the data. - - - - - Whether the checksum should be calculated. - Can be false in UDP because the checksum is optional. false means that the checksum will be left zero. - - - - - The offset in the layer where the checksum should be written. - - - - - Whether the checksum is optional in the layer. - - - - - RFC 2711. - 
-            +-----+-------------+--------+
-            | Bit | 0-7         | 8-15   |
-            +-----+-------------+--------+
-            | 0   | Option Type | 2      |
-            +-----+-------------+--------+
-            | 16  | Router Alert Type    |
-            +-----+----------------------+
-
- - - - - RFC 2460. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Option Data                |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Option Type | Opt Data Len (optional) |
-            +-----+-------------+-------------------------+
-            | 16  | Option Data (optional)                |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - True iff the option type and data are equal. - - - - - True iff the option type and data are equal. - - - - - Returns a hash code for the option. - - - - - The type of the IP option. - - - - - The number of bytes the option takes. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - The number of bytes the option data takes. - - - - - Creates an instance according to the given router alert type. - - Type of router alert. - - - - Parses the given data to create a router alert IPv6 option. - - The data to parse to create the option. - Router alert IPv6 option according to the data parsed. - - - - Type of router alert. - - - - - Type of an IPv6 Mobility option. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - Alternate Care-of Address. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 3963. - Mobile Network Prefix Option. - - - - - RFC 5568. - Mobility Header Link-Layer Address option. - - - - - RFC 4283. - MN-ID-OPTION-TYPE. - - - - - RFC 4285. - AUTH-OPTION-TYPE. - - - - - RFC 4285. - MESG-ID-OPTION-TYPE - - - - - RFC 4866. - CGA Parameters Request. - - - - - RFC 4866. - CGA Parameters. - - - - - RFC 4866. - - - - - RFC 4866. - - - - - RFC 4866. - Care-of Test Init - - - - - RFC 4866. - Care-of Test. - - - - - RFC 5026. - DNS-UPDATE-TYPE. - - - - - RFC 5096. - Experimental Mobility Option. - - - - - RFC 5094. - Vendor Specific Mobility Option. - - - - - RFC 5149. - - - - - RFC 5568. - Binding Authorization Data for FMIPv6 (BADF). - - - - - RFC 5213. - - - - - RFC 5213. - - - - - RFC 5213. - - - - - RFC 5213. - Mobile Node Link-layer Identifier Option - - - - - RFC 5213. - Link-local Address Option. - - - - - RFC 5213. - - - - - RFC 5847. - - - - - RFC 5555. - IPv4 Home Address. - - - - - RFC 5555. - IPv4 Address Acknowledgement. - - - - - RFC 5555. - NAT Detection. - - - - - RFC 5555. - IPv4 Care-of Address. - - - - - RFC 5845. - GRE Key Option. - - - - - RFC 5568. - Mobility Header IPv6 Address/Prefix. - - - - - RFC 5648. - - - - - RFC5844. - IPv4 Home Address Request. - - - - - RFC 5844. - IPv4 Home Address Reply. - - - - - RFC 5844. - IPv4 Default-Router Address. - - - - - RFC 5844. - IPv4 DHCP Support Mode. - - - - - RFC 5949. - - - - - RFC 5949. - - - - - RFC 5949. - Mobile Node Link-local Address Interface Identifier Option. - - - - - RFC 6058. - - - - - RFC 6089 - - - - - RFC 6089. - - - - - RFC 6463. - Redirect-Capability Mobility Option. - - - - - RFC 6463. - - - - - RFC 6463. - - - - - RFC 6463. - Alternate IPv4 Care-of Address. - - - - - RFC 6602. - - - - - RFC 6705. - MAG IPv6 Address. - - - - - RFC 6757. - - - - - RFC 6275. - 
-            +-----+--------------+
-            | Bit | 0-7          |
-            +-----+--------------+
-            | 0   | Option Type  |
-            +-----+--------------+
-            | 8   | Opt Data Len |
-            +-----+--------------+
-            | 16  | 0            |
-            | ... |              |
-            +-----+--------------+
-
- - - - - Creates an instance from padding data length. - - - - - - The number of bytes the option data takes. - - - - - RFC 5568. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | SPI                        |
-            |     |                            |
-            +-----+----------------------------+
-            | 48  | Authenticator              |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from security parameter index and authenticator. - - - SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys. - - - Contains a cryptographic value that can be used to determine that the message in question comes from the right authority. - Rules for calculating this value depends on the used authorization procedure. - - - - - SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys. - - - - - - Contains a cryptographic value that can be used to determine that the message in question comes from the right authority. - Rules for calculating this value depends on the used authorization procedure. - - - For the return routability procedure, this option can appear in the Binding Update and Binding Acknowledgements. - Rules for calculating the Authenticator value are the following: - - - Mobility Data = care-of address | correspondent | MH Data - Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) - - - Where | denotes concatenation. - "Care-of address" is the care-of address that will be registered for the mobile node if the Binding Update succeeds, - or the home address of the mobile node if this option is used in de-registration. - Note also that this address might be different from the source address of the Binding Update message, - if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero. - - - The "correspondent" is the IPv6 address of the Previous Access Router (PAR). - Note that, if the message is sent to a destination that is itself mobile, the "correspondent" address may not be the address found in the - Destination Address field of the IPv6 header; instead, the home address from the type 2 Routing header should be used. - - - "MH Data" is the content of the Mobility Header, excluding the Authenticator field itself. - The Authenticator value is calculated as if the Checksum field in the Mobility Header was zero. - The Checksum in the transmitted packet is still calculated in the usual manner, - with the calculated Authenticator being a part of the packet protected by the Checksum. - Kbm is a shared key between the MN and the PAR. - Note that while the contents of a potential Home Address destination option are not covered in this formula, - the rules for the calculation of the Kbm do take the home address in account. - This ensures that the MAC will be different for different home addresses. - - - The first 96 bits from the MAC result are used as the Authenticator field. - - - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 32  | Options                               |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | Options                               |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Extension header options. - - - - - True iff the extension header parsing didn't encounter an issue. - - - - - Creates an instance from next header and options. - - Identifies the type of header immediately following this extension header. - Extension header options. - - - - Identifies the type of this extension header. - - - - - RFC 5213. - - - - - Reserved. - - - - - Virtual. - Logical Network Interface. - - - - - Point-to-Point Protocol. - - - - - IEEE 802.3. - Ethernet. - - - - - IEEE 802.11a/b/g. - Wireless LAN. - - - - - IEEE 802.16e. - WIMAX. - - - - - RFC 5568. - 
-            +-----+---+---+----------+-------------------------+
-            | Bit | 0 | 1 | 2-7      | 8-15                    |
-            +-----+---+---+----------+-------------------------+
-            | 0   | Next Header      | Header Extension Length |
-            +-----+------------------+-------------------------+
-            | 16  | MH Type          | Reserved                |
-            +-----+------------------+-------------------------+
-            | 32  | Checksum                                   |
-            +-----+--------------------------------------------+
-            | 48  | Sequence #                                 |
-            +-----+---+---+----------+-------------------------+
-            | 64  | S | U | Reserved | Code                    |
-            +-----+---+---+----------+-------------------------+
-            | 96  | Mobility Options                           |
-            | ... |                                            |
-            +-----+--------------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, sequence number, assigned address configuration, buffer, code and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Must be set by the sender so replies can be matched to this message. - - Assigned address configuration flag. - When set to true, this message requests a new CoA to be returned by the destination. - May be set when Code = 0. Must be false when Code = 1. - - - When set, the destination should buffer any packets toward the node indicated in the options of this message. - Used when Code = 0, should be set to false when Code = 1. - - Describes whether the source ip address is a previous care of address. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Must be set by the sender so replies can be matched to this message. - - - - - Assigned address configuration flag. - When set to true, this message requests a new CoA to be returned by the destination. - May be set when Code = 0. Must be false when Code = 1. - - - - - When set, the destination should buffer any packets toward the node indicated in the options of this message. - Used when Code = 0, should be set to false when Code = 1. - - - - - Describes whether the source ip address is a previous care of address. - - - - - Represents an IGMP group record with all the relevant fields. - Used to build an IGMP report of version 3. - - - - - Create the record according to all the fields. - - The type of group record included in the report message. - The Multicast Address field contains the IP multicast address to which this Group Record pertains. - - The Source Address [i] fields are a vector of n IP unicast addresses, - where n is the value in this record's Number of Sources (N) field. - - - The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. - The protocol specified in this document, IGMPv3, does not define any auxiliary data. - Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, - and MUST ignore any auxiliary data present in any received Group Record. - The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field. - - - - - Create the record according to all the fields. - - The type of group record included in the report message. - The Multicast Address field contains the IP multicast address to which this Group Record pertains. - - The Source Address [i] fields are a vector of n IP unicast addresses, - where n is the value in this record's Number of Sources (N) field. - - - The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. - The protocol specified in this document, IGMPv3, does not define any auxiliary data. - Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, - and MUST ignore any auxiliary data present in any received Group Record. - The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field. - - - - - A string containing the record type, multicast address, source addresses and the number of bytes in teh auxiliary data. - - - - - Two records are equal if the record type, multicast address, source addresses and auxiliary data are equal. - - - - - Two records are equal if the record type, multicast address, source addresses and auxiliary data are equal. - - - - - The hash code of a record is the xor of the hash code of the record type, multicast address, source addresses and auxiliary data. - - - - - The type of group record included in the report message. - - - - - The Multicast Address field contains the IP multicast address to which this Group Record pertains. - - - - - The Source Address [i] fields are a vector of n IP unicast addresses, - where n is the value in this record's Number of Sources (N) field. - - - - - The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. - The protocol specified in this document, IGMPv3, does not define any auxiliary data. - Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, - and MUST ignore any auxiliary data present in any received Group Record. - The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field. - - - - - RFC 2236. - - - - - RFC 2236. - Represents a generic IGMP version 2 datagram. - - - - - - Represents a Simple IGMP layer. - A simple layer only has the 8 bytes header without additional fields. - - - - - - The base of all IGMP layers. - - - - - - IGMP layers are equal if they have the same message type, query version, similar max response time and the same specific type fields. - - - - - IGMP layers are equal if they have the same message type, query version, similar max response time and the same specific type fields. - - - - - Xor of the hash codes of the layer length, datalink, message type and query version. - - - - - true iff the fields that are not mutual to all IGMP layers are equal. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - The IGMP version of a Membership Query message. - If the type is not a query, None will be returned. - - - - - The actual time allowed, called the Max Resp Time. - - - - - The protocol that should be written in the previous (IPv4) layer. - - - - - Represents an IGMP layer that contains a Group Address. - - - - - - The Group Address field is set to zero when sending a General Query, - and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query. - In a Membership Report of version 1 or 2 or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left. - In a Membership Report of version 3 this field is meaningless. - - - - - Writes the layer to the buffer. - This method ignores the payload length, and the previous and next layers. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - Xor of the hash codes of the layer length, datalink, message type, query version and group address. - - - - - true iff the the group address is equal. - - - - - true iff the the group address is equal. - - - - - The Group Address field is set to zero when sending a General Query, - and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query. - In a Membership Report of version 1 or 2 or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left. - In a Membership Report of version 3 this field is meaningless. - - - - - The number of bytes this layer will take. - - - - - The actual time allowed, called the Max Resp Time. - - - - - The actual time allowed, called the Max Resp Time. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - RFC 3376. - Represents an IGMP Query version 3 layer. - - - - - - Creates an instance of an IGMP Query Version 3 layer. - Default SourceAddresses is no addresses. - - - - - Writes the layer to the buffer. - This method ignores the payload length, and the previous and next layers. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - Xor of the combination of the IsSuppressRouterSideProcessing and QueryRobustnessVariable fields with - the hash codes of the layer length, datalink, message type, query version, group address and all the source addresses. - - - - - true iff the GroupAddress, IsSuppressRouterSideProcessing, QueryRobustnessVariable and SourceAddresses fields are equal - and the QueryInterval is similar. - - - - - true iff the GroupAddress, IsSuppressRouterSideProcessing, QueryRobustnessVariable and SourceAddresses fields are equal - and the QueryInterval is similar. - - - - - The actual time allowed, called the Max Resp Time. - - - - - The Group Address field is set to zero when sending a General Query, - and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query. - In a Membership Report of version 1 or 2 or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left. - In a Membership Report of version 3 this field is meaningless. - - - - - When set to one, the S Flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. - It does not, however, suppress the querier election or the normal "host-side" processing of a Query - that a router may be required to perform as a consequence of itself being a group member. - - - - - If non-zero, the QRV field contains the [Robustness Variable] value used by the querier, i.e., the sender of the Query. - If the querier's [Robustness Variable] exceeds 7, the maximum value of the QRV field, the QRV is set to zero. - Routers adopt the QRV value from the most recently received Query as their own [Robustness Variable] value, - unless that most recently received QRV was zero, in which case the receivers use the default [Robustness Variable] value or a statically configured value. - - - - - The actual interval, called the Querier's Query Interval (QQI). - - - - - The Source Address [i] fields are a vector of n IP unicast addresses, - where n is the value in the Number of Sources (N) field. - - - - - The number of bytes this layer will take. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - The IGMP version of a Membership Query message. - If the type is not a query, None will be returned. - - - - - The actual time allowed, called the Max Resp Time. - - - - - RFC 792. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-
- - - - - RFC 792. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-
- - - - - An identifier to aid in matching requests and replies, may be zero. - - - - - A sequence number to aid in matching requests and replies, may be zero. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - RFC 2616. - The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body - in order to safely transfer it between the sender and the recipient. - This differs from the content-coding in that the transfer-coding is a property of the message, not of the entity. - - 
-            Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding
-
- - Example: - - 
-            Transfer-Encoding: chunked
-
- - If multiple encodings have been applied to an entity, the transfer-codings MUST be listed in the order in which they were applied. - Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification. - - - - - The field name. - - - - - The field name in uppercase. - - - - - Creates an HTTP transfer encoding field from a set of transfer codings. - - - - - Creates an HTTP transfer encoding field from a set of transfer codings. - - - - - True iff the two HTTP transfer encoding fields are of equal value. - Two HTTP transfer encoding fields are equal iff they have the same transfer codings. - - - - - True iff the two HTTP transfer encoding fields are of equal value. - Two HTTP transfer encoding fields are equal iff they have the same transfer codings. - - - - - Transfer-coding values are used to indicate an encoding transformation that has been, can be, - or may need to be applied to an entity-body in order to ensure "safe transport" through the network. - This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity. - - 
-            transfer-coding         = "chunked" | transfer-extension
-            transfer-extension      = token *( ";" parameter )
-
- - Parameters are in the form of attribute/value pairs. - - 
-            parameter               = attribute "=" value
-            attribute               = token
-            value                   = token | quoted-string
-
- - All transfer-coding values are case-insensitive. - Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", - unless the message is terminated by closing the connection. - When the "chunked" transfer-coding is used, it MUST be the last transfer-coding applied to the message-body. - The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. - These rules allow the recipient to determine the transfer-length of the message. - - - - - RFC 1702. - Represents a source route entry consisting of a list of Autonomous System numbers and indicates an AS source route. - - - - - RFC 1701. - SRE. - 
-            +-----+----------------+------------+------------+
-            | Bit | 0-15           | 16-23      | 24-31      |
-            +-----+----------------+------------+------------+
-            | 0   | Address Family | SRE Offset | SRE Length |
-            +-----+----------------+------------+------------+
-            | 32  | Routing Information ...                  |
-            +-----+------------------------------------------+
-
- - - - - The number of bytes the entry header takes. - - - - - Two entries are equal iff they have the same address family, length, payload offset and payload. - - - - - Two entries are equal iff they have the same address family, length, payload offset and payload. - - - - - The hash code of an entry is a xor of the hash code of the address family, length, payload offset and payload. - - - - - True iff the payloads a are equal. - - - - - Writes the payload to the given buffer in the given offset. - - The buffer to write the payload to. - The offset in the buffer to start writing. - - - - The Address Family field contains a two octet value which indicates the syntax and semantics of the Routing Information field. - - - - - The number of bytes the entry takes. - - - - - The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined. - - - - - The SRE Length field contains the number of octets in the SRE. - - - - - The hash code of the payload. - - - - - Initializes using the given AS numbers and the next as number index. - - Autonomous System numbers of the source route. - The next AS number index in the source route. - - - - True iff the AS numbers are equal. - - - - - Writes the payload to the given buffer in the given offset. - - The buffer to write the payload to. - The offset in the buffer to start writing. - - - - The Address Family field contains a two octet value which indicates the syntax and semantics of the Routing Information field. - - - - - The SRE Length field contains the number of octets in the SRE. - - - - - The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined. - - - - - The xor of the hash code of the AS numbers. - - - - - Autonomous System numbers of the source route. - - - - - The next AS number index in the source route. - - - - - The next AS number. - - - - - Represents a GRE layer. - - - - - - A base class for Ethernet like layers. - Contains an Ethernet type that can be calculated according to the previous layer - and defines that if the next layer is an ARP layer, the hardware type should be Ethernet. - - - - - Creates an instance with zero values. - - - - - Ethernet type (next protocol). - - - - - The ARP Hardware Type of the layer before the ARP layer. - - - - - Sets the key according to the payload length and call id. - - (High 2 octets of Key) Size of the payload, not including the GRE header. - (Low 2 octets of Key) Contains the Peer's Call ID for the session to which this packet belongs. - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Finalizes the layer data in the buffer. - Used for fields that must be calculated according to the layer's payload (like checksum). - - The buffer to finalize the layer in. - The offset in the buffer the layer starts. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes after this layer. null if this is the last layer. - - - - True iff the two objects are equal Layers. - - - - - True iff the two objects are equal Layers. - - - - - The GRE Version Number. - - - - - The Protocol Type field contains the protocol type of the payload packet. - These Protocol Types are defined in [RFC1700] as "ETHER TYPES" and in [ETYPES]. - An implementation receiving a packet containing a Protocol Type which is not listed in [RFC1700] or [ETYPES] SHOULD discard the packet. - - - - - Recursion control contains a three bit unsigned integer which contains the number of additional encapsulations which are permissible. - This SHOULD default to zero. - - - - - Must be set to zero (0). - - - - - If the Checksum Present bit is set to 1, then the Checksum field is present and contains valid information. - If either the Checksum Present bit or the Routing Present bit are set, BOTH the Checksum and Offset fields are present in the GRE packet. - - - - - The Checksum field contains the IP (one's complement) checksum sum of the all the 16 bit words in the GRE header and the payload packet. - For purposes of computing the checksum, the value of the checksum field is zero. - This field is present only if the Checksum Present bit is set to one. - In order to calculate the Checksum automatically, leave null in this field and set the ChecksumPresent field to true. - - - - - The Key field contains a four octet number which was inserted by the encapsulator. - It may be used by the receiver to authenticate the source of the packet. - The Key field is only present if the Key Present field is set to 1. - null iff the Key isn't present. - - - - - (High 2 octets of Key) Size of the payload, not including the GRE header. - - - - - (Low 2 octets of Key) Contains the Peer's Call ID for the session to which this packet belongs. - - - - - The Sequence Number field contains an unsigned 32 bit integer which is inserted by the encapsulator. - It may be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. - null off the sequence number present bit is 0. - - - - - Contains the sequence number of the highest numbered GRE packet received by the sending peer for this user session. - Present if A bit (Bit 8) is one (1). - null iff not present. - - - - - The offset field indicates the octet offset from the start of the Routing field to the first octet of the active Source Route Entry to be examined. - This field is present if the Routing Present or the Checksum Present bit is set to 1, and contains valid information only if the Routing Present bit is set to 1. - Should be null iff the Routing is null (routing is not present). - - - - - The Routing field is optional and is present only if the Routing Present bit is set to 1. - The Routing field is a list of Source Route Entries (SREs). - null iff the routing isn't present. - - - - - If the source route is incomplete, then the Strict Source Route bit is checked. - If the source route is a strict source route and the next IP destination or autonomous system is NOT an adjacent system, the packet MUST be dropped. - - - - - The number of bytes this layer will take. - - - - - The protocol that should be written in the previous (IPv4) layer. - This is GRE. - - - - - Reid. - 
-            +---------------------+
-            | One ore more strings|
-            +---------------------+
-
- - - - - Constructs the resource data from strings. - - A descriptive text in one or more strings. - - - - Constructs the resource data from strings. - - A descriptive text in one or more strings. - - - - RFC 1035. - 
-            +---------+
-            | RMAILBX |
-            +---------+
-            | EMAILBX |
-            +---------+
-
- - - - - A resource record data that contains exactly 2 domain names. - - - - - A base class for resource record datas that contain DNS domain names. - - - - - Two domain names resource data are equal if they are of the same type and contain the same domain names in the same order. - - - - - Two domain names resource data are equal if they are of the same type and contain the same domain names in the same order. - - - - - The hash code of the resource data is based on the concrete type and domain names. - - - - - Constructs a mailing list info resource data from mailing list and error mailbox. - - - Specifies a mailbox which is responsible for the mailing list or mailbox. - If this domain name names the root, the owner of the MINFO RR is responsible for itself. - Note that many existing mailing lists use a mailbox X-request for the RMAILBX field of mailing list X, e.g., Msgroup-request for Msgroup. - This field provides a more general mechanism. - - - Specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR - (similar to the ERRORS-TO: field which has been proposed). - If this domain name names the root, errors should be returned to the sender of the message. - - - - - Specifies a mailbox which is responsible for the mailing list or mailbox. - If this domain name names the root, the owner of the MINFO RR is responsible for itself. - Note that many existing mailing lists use a mailbox X-request for the RMAILBX field of mailing list X, e.g., Msgroup-request for Msgroup. - This field provides a more general mechanism. - - - - - Specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR - (similar to the ERRORS-TO: field which has been proposed). - If this domain name names the root, errors should be returned to the sender of the message. - - - - - RFC 1876. - 
-            +-----+---------+------+-----------+----------+
-            | bit | 0-7     | 8-15 | 16-23     | 24-31    |
-            +-----+---------+------+-----------+----------+
-            | 0   | VERSION | SIZE | HORIZ PRE | VERT PRE |
-            +-----+---------+------+-----------+----------+
-            | 32  | LATITUDE                              |
-            +-----+---------------------------------------+
-            | 64  | LONGITUDE                             |
-            +-----+---------------------------------------+
-            | 96  | ALTITUDE                              |
-            +-----+---------------------------------------+
-
- - - - - The maximum value for the size field. - - - - - The number of bytes this resource data takes. - - - - - Constructs an instance from the version, size, horizontal precision, vertical precision, latitude, longitude and altitude fields. - - - Version number of the representation. - This must be zero. - Implementations are required to check this field and make no assumptions about the format of unrecognized versions. - - - The diameter of a sphere enclosing the described entity, in centimeters. - Only numbers of the form decimal digit times 10 in the power of a decimal digit are allowed since it is expressed as a pair of four-bit unsigned integers, - each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. - This allows sizes from 0e0 (<1cm) to 9e9(90,000km) to be expressed. - This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 = 1e5. - Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. - - Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), - it is therefore suitable for use as a "worldwide" size. - - - The horizontal precision of the data, in centimeters, expressed using the same representation as Size. - This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. - (This was chosen to match the interpretation of Size; to get a "plus or minus" value, divide by 2.) - - - The vertical precision of the data, in centimeters, expressed using the sane representation as for Size. - This is the total potential vertical error, rather than a "plus or minus" value. - (This was chosen to match the interpretation of SIize; to get a "plus or minus" value, divide by 2.) - Note that if altitude above or below sea level is used as an approximation for altitude relative to the ellipsoid, the precision value should be adjusted. - - - The latitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, - most significant octet first (network standard byte order), in thousandths of a second of arc. - 2^31 represents the equator; numbers above that are north latitude. - - - The longitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, - most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. - 2^31 represents the prime meridian; numbers above that are east longitude. - - - The altitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, - most significant octet first (network standard byte order), in centimeters, - from a base of 100,000m below the reference spheroid used by GPS (semimajor axis a=6378137.0, reciprocal flattening rf=298.257223563). - Altitude above (or below) sea level may be used as an approximation of altitude relative to the the spheroid, - though due to the Earth's surface not being a perfect spheroid, there will be differences. - (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the spheroid. - Adjustments to Altitude and/or VerticalPrecision will be necessary in most cases. - The Defense Mapping Agency publishes geoid height values relative to the ellipsoid. - - - - - Two DnsResourceDataLocationInformation are equal iff their version, size, horizontal precision, vertical precision, latitude, - longitude and altitude fields are equal. - - - - - Two DnsResourceDataLocationInformation are equal iff their version, size, horizontal precision, vertical precision, latitude, - longitude and altitude fields are equal. - - - - - A hash code based on the version, size, horizontal precision, vertical precision, latitude, longitude and altitude fields - - - - - Version number of the representation. - This must be zero. - Implementations are required to check this field and make no assumptions about the format of unrecognized versions. - - - - - The diameter of a sphere enclosing the described entity, in centimeters. - Only numbers of the form decimal digit times 10 in the power of a decimal digit are allowed since it is expressed as a pair of four-bit unsigned integers, - each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. - This allows sizes from 0e0 (<1cm) to 9e9(90,000km) to be expressed. - This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 = 1e5. - Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent. - - Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m), - it is therefore suitable for use as a "worldwide" size. - - - - - The horizontal precision of the data, in centimeters, expressed using the same representation as Size. - This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value. - (This was chosen to match the interpretation of Size; to get a "plus or minus" value, divide by 2.) - - - - - The vertical precision of the data, in centimeters, expressed using the sane representation as for Size. - This is the total potential vertical error, rather than a "plus or minus" value. - (This was chosen to match the interpretation of SIize; to get a "plus or minus" value, divide by 2.) - Note that if altitude above or below sea level is used as an approximation for altitude relative to the ellipsoid, the precision value should be adjusted. - - - - - The latitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, - most significant octet first (network standard byte order), in thousandths of a second of arc. - 2^31 represents the equator; numbers above that are north latitude. - - - - - The longitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, - most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. - 2^31 represents the prime meridian; numbers above that are east longitude. - - - - - The altitude of the center of the sphere described by the Size field, expressed as a 32-bit integer, - most significant octet first (network standard byte order), in centimeters, - from a base of 100,000m below the reference spheroid used by GPS (semimajor axis a=6378137.0, reciprocal flattening rf=298.257223563). - Altitude above (or below) sea level may be used as an approximation of altitude relative to the the spheroid, - though due to the Earth's surface not being a perfect spheroid, there will be differences. - (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the spheroid. - Adjustments to Altitude and/or VerticalPrecision will be necessary in most cases. - The Defense Mapping Agency publishes geoid height values relative to the ellipsoid. - - - - - RFC 2137. - - - - - The general update signatory field bit has no special meaning. - If the other three bits are all zero, it must be one so that the field is non-zero to designate that the key is an update key. - The meaning of all values of the signatory field with the general bit and one or more other signatory field bits on is reserved. - - - - - If non-zero, this key is authorized to add and update RRs for only a single owner name. - If there already exist RRs with one or more names signed by this key, they may be updated but no new name created until the number of existing names is reduced to zero. - This bit is meaningful only for mode A dynamic zones and is ignored in mode B dynamic zones. - This bit is meaningful only if the owner name is a wildcard. - (Any dynamic update KEY with a non-wildcard name is, in effect, a unique name update key.) - - - - - If non-zero, this key is authorized to add and delete RRs even if there are other RRs with the same owner name and class that are authenticated by a SIG signed with a different dynamic update KEY. - If zero, the key can only authorize updates where any existing RRs of the same owner and class are authenticated by a SIG using the same key. - This bit is meaningful only for type A dynamic zones and is ignored in type B dynamic zones. - - Keeping this bit zero on multiple KEY RRs with the same or nested wild card owner names permits multiple entities to exist that can create and delete names but can not effect RRs with different owner names from any they created. - In effect, this creates two levels of dynamic update key, strong and weak, where weak keys are limited in interfering with each other but a strong key can interfere with any weak keys or other strong keys. - - - - - If nonzero, this key is authorized to attach, detach, and move zones by creating and deleting NS, glue A, and zone KEY RR(s). - If zero, the key can not authorize any update that would effect such RRs. - This bit is meaningful for both type A and type B dynamic secure zones. - NOTE: do not confuse the "zone" signatory field bit with the "zone" key type bit. - - - - - Represents a gateway to which an IPsec tunnel may be created in order to reach the entity named by an IPsec resource record. - - - - - Two gateway representations are equal if they are of the same type and the value is the same. - - - - - Two gateway representations are equal if they are of the same type and the value is the same. - - - - - Serves as a hash function for a particular type. - - A hash code for the current gateway represnetation. - - - - An instance that represents that no gateway exists. - - - - - The gateway represnetation type. - - - - - The number of bytes the gateway represnetation takes. - - - - - RFC 2671. - 
-            +------+----------------+----------+
-            | bit  | 0-7            | 8-15     |
-            +------+----------------+----------+
-            | 0    | Name                      |
-            | ...  |                           |
-            +------+---------------------------+
-            |      | Type = OPT                |
-            +------+---------------------------+
-            |      | Sender's UDP payload size |
-            +------+----------------+----------+
-            |      | EXTENDED-RCODE | VERSION  |
-            +------+----------------+----------+
-            |      | Flags                     |
-            +------+---------------------------+
-            |      | Resource Data Length      |
-            +------+---------------------------+
-            |      | Resource Data             |
-            | ...  |                           |
-            +------+---------------------------+
-
- - - - - RFC 1035. - A resource record with data. - Used for the answers, authorities and additionals sections. - For OPT resource records, DnsOptResourceRecord should be used. - 
-            +------+-------------------------------------------------+
-            | byte | 0-1                                             |
-            +------+-------------------------------------------------+
-            | 0    | Name                                            |
-            | ...  |                                                 |
-            +------+-------------------------------------------------+
-            |      | Type                                            |
-            +------+-------------------------------------------------+
-            |      | Class                                           |
-            +------+-------------------------------------------------+
-            |      | TTL                                             |
-            |      |                                                 |
-            +------+-------------------------------------------------+
-            |      | Resource Data Length                            |
-            +------+-------------------------------------------------+
-            |      | Resource Data                                   |
-            | ...  |                                                 |
-            +------+-------------------------------------------------+
-
- - - - - RFC 1035. - All RRs have the same top level format shown below: - 
-            +------+-------------------------------------------------+
-            | byte | 0-1                                             |
-            +------+-------------------------------------------------+
-            | 0    | Name                                            |
-            | ...  |                                                 |
-            +------+-------------------------------------------------+
-            |      | Type                                            |
-            +------+-------------------------------------------------+
-            |      | Class                                           |
-            +------+-------------------------------------------------+
-            |      | TTL (not available in queries)                  |
-            |      |                                                 |
-            +------+-------------------------------------------------+
-            |      | Resource Data Length (not available in queries) |
-            +------+-------------------------------------------------+
-            |      | Resource Data (not available in queries)        |
-            | ...  |                                                 |
-            +------+-------------------------------------------------+
-
- - - - - A string representing the resource record by concatenating its different parts. - - - - - An owner name, i.e., the name of the node to which this resource record pertains. - - - - - Two octets containing one of the RR TYPE codes. - - - - - Two octets containing one of the RR CLASS codes. - - - - - A 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. - Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. - For example, SOA records are always distributed with a zero TTL to prohibit caching. - Zero values can also be used for extremely volatile data. - Not available in queries. - - - - - A variable length string of octets that describes the resource. - The format of this information varies according to the TYPE and CLASS of the resource record. - For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address. - Not available in queries. - - - - - Creates a resource record from domain name, type, class, ttl and data. - - An owner name, i.e., the name of the node to which this resource record pertains. - Two octets containing one of the RR TYPE codes. - Two octets containing one of the RR CLASS codes. - - A 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. - Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. - For example, SOA records are always distributed with a zero TTL to prohibit caching. - Zero values can also be used for extremely volatile data. - - - A variable length string of octets that describes the resource. - The format of this information varies according to the TYPE and CLASS of the resource record. - For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address. - - - - - A string representing the resource record by concatenating its different parts. - - - - - Two DnsDataResourceRecord are equal iff their domain name, dns type, dns class, ttl and data fields are equal. - - - - - Two DnsDataResourceRecord are equal iff their domain name, dns type, dns class, ttl and data fields are equal. - - - - - A hash code of the combination of the domain name, dns type, dns class, ttl and data fields. - - - - - A 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. - Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. - For example, SOA records are always distributed with a zero TTL to prohibit caching. - Zero values can also be used for extremely volatile data. - - - - - A variable length string of octets that describes the resource. - The format of this information varies according to the TYPE and CLASS of the resource record. - For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address. - - - - - Constructs an instance out of the domain name, senders UDP payload size, extended return code, version, flags and data fields. - - An owner name, i.e., the name of the node to which this resource record pertains. - - The number of octets of the largest UDP payload that can be reassembled and delivered in the sender's network stack. - Note that path MTU, with or without fragmentation, may be smaller than this. - - - Forms upper 8 bits of extended 12-bit RCODE. - Note that EXTENDED-RCODE value "0" indicates that an unextended RCODE is in use (values "0" through "15"). - - - Indicates the implementation level of whoever sets it. - Full conformance with this specification is indicated by version "0". - Requestors are encouraged to set this to the lowest implemented level capable of expressing a transaction, - to minimize the responder and network load of discovering the greatest common implementation level between requestor and responder. - A requestor's version numbering strategy should ideally be a run time configuration option. - - OPT flags. - An OPT resource record data - - - - A string representing the resource record by concatenating its different parts. - - - - - The number of octets of the largest UDP payload that can be reassembled and delivered in the sender's network stack. - Note that path MTU, with or without fragmentation, may be smaller than this. - - - - - Forms upper 8 bits of extended 12-bit RCODE. - Note that EXTENDED-RCODE value "0" indicates that an unextended RCODE is in use (values "0" through "15"). - - - - - Indicates the implementation level of whoever sets it. - Full conformance with this specification is indicated by version "0". - Requestors are encouraged to set this to the lowest implemented level capable of expressing a transaction, - to minimize the responder and network load of discovering the greatest common implementation level between requestor and responder. - A requestor's version numbering strategy should ideally be a run time configuration option. - - - - - OPT flags. - - - - - Represents a DNS layer. - - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - Finalizes the layer data in the buffer. - Used for fields that must be calculated according to the layer's payload (like checksum). - - The buffer to finalize the layer in. - The offset in the buffer the layer starts. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes after this layer. null if this is the last layer. - - - - True iff the two objects are equal Layers. - - - - - True iff the two objects are equal Layers. - - - - - A 16 bit identifier assigned by the program that generates any kind of query. - This identifier is copied the corresponding reply and can be used by the requester to match up replies to outstanding queries. - - - - - A one bit field that specifies whether this message is a query (0), or a response (1). - - - - - Specifies whether this message is a query or a response. - - - - - Specifies kind of query in this message. - This value is set by the originator of a query and copied into the response. - - - - - This bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section. - Note that the contents of the answer section may have multiple owner names because of aliases. - The AA bit corresponds to the name which matches the query name, or the first owner name in the answer section. - - - - - Specifies that this message was truncated due to length greater than that permitted on the transmission channel. - - - - - This bit may be set in a query and is copied into the response. - If RD is set, it directs the name server to pursue the query recursively. - Recursive query support is optional. - - - - - This bit is set or cleared in a response, and denotes whether recursive query support is available in the name server. - - - - - Reserved for future use. - Must be false in all queries and responses. - - - - - The name server side of a security-aware recursive name server must not set the AD bit in a response - unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. - The name server side should set the AD bit if and only if the resolver side considers all RRsets in the Answer section - and any relevant negative response RRs in the Authority section to be authentic. - The resolver side must follow the Authenticating DNS Responses procedure to determine whether the RRs in question are authentic. - However, for backward compatibility, a recursive name server may set the AD bit when a response includes unsigned CNAME RRs - if those CNAME RRs demonstrably could have been synthesized from an authentic DNAME RR that is also included in the response - according to the synthesis rules described in RFC 2672. - - - - - Exists in order to allow a security-aware resolver to disable signature validation - in a security-aware name server's processing of a particular query. - - The name server side must copy the setting of the CD bit from a query to the corresponding response. - - The name server side of a security-aware recursive name server must pass the state of the CD bit to the resolver side - along with the rest of an initiating query, - so that the resolver side will know whether it is required to verify the response data it returns to the name server side. - If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires. - Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response. - When the CD bit is set, the recursive name server should, if possible, return the requested data to the originating resolver, - even if the recursive name server's local authentication policy would reject the records in question. - That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, - and the recursive name server should not interfere. - - If the resolver side implements a BAD cache and the name server side receives a query that matches an entry in the resolver side's BAD cache, - the name server side's response depends on the state of the CD bit in the original query. - If the CD bit is set, the name server side should return the data from the BAD cache; - if the CD bit is not set, the name server side must return RCODE 2 (server failure). - - The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks - while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks. - Several of the possible reasons why signature validation might fail involve conditions - that may not apply equally to the recursive name server and the client that invoked it. - For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security - that the recursive name server does not share. - In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client. - - - - - A response of the server that can sign errors or other messages. - - - - - The queries resource records. - Typically exactly one query will exist. - - - - - The answers resource records. - - - - - The authorities resource records. - - - - - The additionals resource records. - - - - - All the resource records by the order the will be written. - - - - - How to compress the domain names. - - - - - The number of bytes this layer will take. - - - - - An enum for all the different tcp option types. - - - - - End of Option List (RFC793) - - - - - No-Operation (RFC793) - - - - - Maximum Segment Size (RFC793) - - - - - WSOPT - Window Scale (RFC1323) - - - - - SACK Permitted (RFC2018) - - - - - SACK (RFC2018) - - - - - Echo (obsoleted by option 8) (RFC1072) - - - - - Echo Reply (obsoleted by option 8) (RFC1072) - - - - - TSOPT - Time Stamp Option (RFC1323) - - - - - Partial Order Connection Permitted (RFC1693) - - - - - Partial Order Service Profile (RFC1693) - - - - - CC (RFC1644) - - - - - CC.NEW (RFC1644) - - - - - CC.ECHO (RFC1644) - - - - - TCP Alternate Checksum Request (RFC1146) - - - - - TCP Alternate Checksum Data (RFC1146) - - - - - MD5 Signature Option (RFC2385) - - - - - Selective Negative Acknowledgements. - - - - - Denote Packet Mood (RFC5841) - - - - - Quick-Start Response (RFC4782) - - - - - User Timeout Option (RFC5482) - - - - - TCP Authentication Option (RFC5925) - - - - - IPv6 Routing Type. - Used in Routing Extension Header. - - - - - RFCs 2460, 5095. - Deprecated. - - - - - Deprecated 06-May-2009. - - - - - RFC 6275. - - - - - RFC 6554. - - - - - RFC 5844. - 
-            +-----+------------+-----+--------------+
-            | Bit | 0-5        | 6-7 | 8-15         |
-            +-----+------------+-----+--------------+
-            | 0   | Option Type      | Opt Data Len |
-            +-----+------------+-----+--------------+
-            | 16  | Prefix-len | Reserved           |
-            +-----+------------+--------------------+
-            | 32  | IPv4 home address               |
-            |     |                                 |
-            +-----+---------------------------------+
-
- - - - - RFC 5844. - - - - - The prefix length of the address. - - - - - Contains the IPv4 home address. - - - - - The maximum value for Prefix Length. - - - - - The number of bytes this option data takes. - - - - - Creates an instance from Prefix Length and Home Address. - - - Indicates the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option. - - - Contains the IPv4 home address that is being requested. - The value of 0.0.0.0 is used to request that the local mobility anchor perform the address allocation. - - - - - Indicates the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option. - - - - - Contains the IPv4 home address that is being requested. - The value of 0.0.0.0 is used to request that the local mobility anchor perform the address allocation. - - - - - RFC 6602. - - - - - Invalid value. - - - - - RFC 6602. - - - - - List of IPv6 extension headers. - - - - - Create an instance from a ReadOnlyCollection of extension headers. - Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. - Assumes the collection won't be modified. - - The extension headers. - - - - Create an instance from an array of extension headers. - Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. - Assumes the collection won't be modified. - - The extension headers. - - - - Create an instance from a list of extension headers. - Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. - Assumes the collection won't be modified. - - The extension headers. - - - - Create an instance from an enumerable of extension headers. - Verifies that there's at most one Encapsulating Security Payload extension header and that it is the last extension header. - Assumes the collection won't be modified. - - The extension headers. - - - - Returns an enumerator that iterates through the collection. - - - A that can be used to iterate through the collection. - - 1 - - - - Returns an enumerator that iterates through a collection. - - - An object that can be used to iterate through the collection. - - 2 - - - - True iff all the extension headers are equal to the given extension headers instance. - - - - - True iff all the extension headers are equal to the given extension headers instance. - - - - - A hash code based on all the extension headers. - - - - - Returns the extension header in the 'index' place. - - The index of the extension header returned. - The extension header in the 'index' place. - - - - The extension headers. - - - - - The total number of bytes the extension headers take. - - - - - True iff a parsing issue wasn't encountered when parsing the extension headers. - - - - - The protocol of the first extension header or null if there are no extension headers. - - - - - The protocol of the last extension header or null if there are no extension headers. - - - - - The next header of the last extension header or null if there are no extension headers. - - - - - An empty list of extension headers. - - - - - Group Record Type. - - - - - Illegal record type. - - - - - A "Current-State Record" is sent by a system in response to a Query received on an interface. - It reports the current reception state of that interface, with respect to a single multicast address. - - MODE_IS_INCLUDE - indicates that the interface has a filter mode of INCLUDE for the specified multicast address. - The Source Address [i] fields in this Group Record contain the interface's source list for the specified multicast address, if it is non-empty. - - - - - - A "Current-State Record" is sent by a system in response to a Query received on an interface. - It reports the current reception state of that interface, with respect to a single multicast address. - - MODE_IS_EXCLUDE - indicates that the interface has a filter mode of EXCLUDE for the specified multicast address. - The Source Address [i] fields in this Group Record contain the interface's source list for the specified multicast address, if it is non-empty. - - - - - - A "Filter-Mode-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of the filter mode - (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), - of the interface-level state entry for a particular multicast address. - The Record is included in a Report sent from the interface on which the change occurred. - - CHANGE_TO_INCLUDE_MODE - indicates that the interface has changed to INCLUDE filter mode for the specified multicast address. - The Source Address [i] fields in this Group Record contain the interface's new source list for the specified multicast address, if it is non-empty. - - - - - - A "Filter-Mode-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of the filter mode - (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), - of the interface-level state entry for a particular multicast address. - The Record is included in a Report sent from the interface on which the change occurred. - - CHANGE_TO_EXCLUDE_MODE - indicates that the interface has changed to EXCLUDE filter mode for the specified multicast address. - The Source Address [i] fields in this Group Record contain the interface's new source list for the specified multicast address, if it is non-empty. - - - - - - A "Source-List-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of source list - that is *not* coincident with a change of filter mode, of the interface-level state entry for a particular multicast address. - The Record is included in a Report sent from the interface on which the change occurred. - - ALLOW_NEW_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the additional sources - that the system wishes to hear from, for packets sent to the specified multicast address. - If the change was to an INCLUDE source list, these are the addresses that were added to the list; if the change was to an EXCLUDE source list, - these are the addresses that were deleted from the list. - - - If a change of source list results in both allowing new sources and blocking old sources, - then two Group Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES. - - - - - - A "Source-List-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of source list - that is *not* coincident with a change of filter mode, of the interface-level state entry for a particular multicast address. - The Record is included in a Report sent from the interface on which the change occurred. - - BLOCK_OLD_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the sources - that the system no longer wishes to hear from, for packets sent to the specified multicast address. - If the change was to an INCLUDE source list, these are the addresses that were deleted from the list; if the change was to an EXCLUDE source list, - these are the addresses that were added to the list. - - - If a change of source list results in both allowing new sources and blocking old sources, - then two Group Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES. - - - - - - The version of the IGMP query message. - - - - - No query version - not a query. - - - - - Version 1 query - RFC1112. - - - - - Version 2 query - RFC2236. - - - - - Version 3 query - RFC3376. - - - - - The version of the query could not be interpreted. - - - - - RFC 1112. - Version 1 (query or report): - 
-            +-----+---------+------+--------+----------+
-            | Bit | 0-3     | 4-7  | 8-15   | 16-31    |
-            +-----+---------+------+--------+----------+
-            | 0   | Version | Type | Unused | Checksum |
-            +-----+---------+------+--------+----------+
-            | 32  | Group Address                      |
-            +-----+------------------------------------+
-
- - RFC 2236. - Version 2 (query, report or leave group): - 
-            +-----+------+---------------+----------+
-            | Bit | 0-7  | 8-15          | 16-31    |
-            +-----+------+---------------+----------+
-            | 0   | Type | Max Resp Time | Checksum |
-            +-----+------+---------------+----------+
-            | 32  | Group Address                   |
-            +-----+---------------------------------+
-
- - RFC 3376. - Version 3 query: - 
-            +-----+------+---+-----+---------------+-----------------------+
-            | Bit | 0-3  | 4 | 5-7 | 8-15          | 16-31                 |
-            +-----+------+---+-----+---------------+-----------------------+
-            | 0   | Type = 0x11    | Max Resp Code | Checksum              |
-            +-----+----------------+---------------+-----------------------+
-            | 32  | Group Address                                          |
-            +-----+------+---+-----+---------------+-----------------------+
-            | 64  | Resv | S | QRV | QQIC          | Number of Sources (N) |
-            +-----+------+---+-----+---------------+-----------------------+
-            | 96  | Source Address [1]                                     |
-            +-----+--------------------------------------------------------+
-            | 128 | Source Address [2]                                     |
-            +-----+--------------------------------------------------------+
-            .     .                         .                              .
-            .     .                         .                              .
-            +-----+--------------------------------------------------------+
-            | 64  | Source Address [N]                                     |
-            | +   |                                                        |
-            | 32N |                                                        |
-            +-----+--------------------------------------------------------+
-
- - RFC 3376. - Version 3 report: - 
-            +-----+-------------+----------+-----------------------------+
-            | Bit | 0-7         | 8-15     | 16-31                       |
-            +-----+-------------+----------+-----------------------------+
-            | 0   | Type = 0x22 | Reserved | Checksum                    |
-            +-----+-------------+----------+-----------------------------+
-            | 32  | Reserved               | Number of Group Records (M) |
-            +-----+------------------------+-----------------------------+
-            | 64  | Group Record [1]                                     |
-            .     .                                                      .
-            .     .                                                      .
-            .     .                                                      .
-            |     |                                                      |
-            +-----+------------------------------------------------------+
-            |     | Group Record [2]                                     |
-            .     .                                                      .
-            .     .                                                      .
-            .     .                                                      .
-            |     |                                                      |
-            +-----+------------------------------------------------------+
-            |     |                         .                            |
-            .     .                         .                            .
-            |     |                         .                            |
-            +-----+------------------------------------------------------+
-            |     | Group Record [M]                                     |
-            .     .                                                      .
-            .     .                                                      .
-            .     .                                                      .
-            |     |                                                      |
-            +-----+------------------------------------------------------+
-
- - - - - The number of bytes the IGMP header takes for all messages but query version 3. - All the bytes but the records of the report version 3. - - - - - The number of bytes the query version 3 IGMP message header takes. - All the bytes but the source addresses. - - - - - The maximum value for the query robustness varialbe. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - IGMP is valid if the checksum is correct, the length fits the message type and data and the MaxResponseCode is 0 in messages where it is not used. - - - - - Calculates the value from the given code as follows: - 
-             0 1 2 3 4 5 6 7
-            +-+-+-+-+-+-+-+-+
-            |1| exp | mant  |
-            +-+-+-+-+-+-+-+-+
-
- Value = (mant | 0x10) << (exp + 3). - - - - - The Max Resp Code field specifies the maximum time allowed before sending a responding report. - - - - - The maximum value for the max response time in version 3 messages. - - - - - The maximum value for the query interval. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - The version of the IGMP protocol for this datagram. - - - - - The IGMP version of a Membership Query message is determined as follows: - - IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero. - IGMPv2 Query: length = 8 octets AND Max Resp Code field is non-zero. - IGMPv3 Query: length >= 12 octets. - - If the type is not a query, None will be returned. - If the query message do not match any of the above conditions (e.g., a Query of length 10 octets) Unknown will be returned. - - - - - The Max Resp Code field specifies the maximum time allowed before sending a responding report. - The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows: - - If Max Resp Code < 128, Max Resp Time = Max Resp Code. - - If Max Resp Code >= 128, Max Resp Code represents a floating-point value as follows: - 
-                0 1 2 3 4 5 6 7
-                +-+-+-+-+-+-+-+-+
-                |1| exp | mant  |
-                +-+-+-+-+-+-+-+-+
-
- Max Resp Time = (mant | 0x10) << (exp + 3). - - - - - Small values of Max Resp Time allow IGMPv3 routers to tune the "leave latency" - (the time between the moment the last host leaves a group and the moment the routing protocol is notified that there are no more members). - Larger values, especially in the exponential range, allow tuning of the burstiness of IGMP traffic on a network. - - - - - - The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows: - - If the query version is 1 or 2 or if Max Resp Code < 128, Max Resp Time = Max Resp Code. - - If Max Resp Code >= 128, Max Resp Code represents a floating-point value as follows: - 
-                 0 1 2 3 4 5 6 7
-                +-+-+-+-+-+-+-+-+
-                |1| exp | mant  |
-                +-+-+-+-+-+-+-+-+
-
- Max Resp Time = (mant | 0x10) << (exp + 3). - - - - - - - The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). - For computing the checksum, the Checksum field is set to zero. - When receiving packets, the checksum MUST be verified before processing a packet. - - - - - True iff the checksum value is correct according to the datagram data. - - - - - The Group Address field is set to zero when sending a General Query, - and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query. - In a Membership Report of version 1 or 2 or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left. - In a Membership Report of version 3 this field is meaningless. - - - - - When set to one, the S Flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. - It does not, however, suppress the querier election or the normal "host-side" processing of a Query - that a router may be required to perform as a consequence of itself being a group member. - - - Valid only on query of version 3. - - - - - If non-zero, the QRV field contains the [Robustness Variable] value used by the querier, i.e., the sender of the Query. - If the querier's [Robustness Variable] exceeds 7, the maximum value of the QRV field, the QRV is set to zero. - Routers adopt the QRV value from the most recently received Query as their own [Robustness Variable] value, - unless that most recently received QRV was zero, in which case the receivers use the default [Robustness Variable] value or a statically configured value. - - - Valid only on query of version 3. - - - - - The Querier's Query Interval Code field specifies the [Query Interval] used by the querier. - The actual interval, called the Querier's Query Interval (QQI), is represented in units of seconds and is derived from the Querier's Query Interval Code as follows: - - If QQIC < 128, QQI = QQIC - - If QQIC >= 128, QQIC represents a floating-point value as follows: - 
-                 0 1 2 3 4 5 6 7
-                +-+-+-+-+-+-+-+-+
-                |1| exp | mant  |
-                +-+-+-+-+-+-+-+-+
-
- QQI = (mant | 0x10) << (exp + 3) - - - Multicast routers that are not the current querier adopt the QQI value from the most recently received Query as their own [Query Interval] value, - unless that most recently received QQI was zero, in which case the receiving routers use the default [Query Interval] value. - - - Valid only on query of version 3. - - - - - The actual interval, called the Querier's Query Interval (QQI), is represented in units of seconds and is derived from the Querier's Query Interval Code as follows: - - If QQIC < 128, QQI = QQIC - - If QQIC >= 128, QQIC represents a floating-point value as follows: - 
-                 0 1 2 3 4 5 6 7
-                +-+-+-+-+-+-+-+-+
-                |1| exp | mant  |
-                +-+-+-+-+-+-+-+-+
-
- QQI = (mant | 0x10) << (exp + 3) - - - - - Valid only on query of version 3. - - - - - The Number of Sources (N) field specifies how many source addresses are present in the Query. - This number is zero in a General Query or a Group-Specific Query, and non-zero in a Group-and-Source-Specific Query. - This number is limited by the MTU of the network over which the Query is transmitted. - For example, on an Ethernet with an MTU of 1500 octets, the IP header including the Router Alert option consumes 24 octets, - and the IGMP fields up to including the Number of Sources (N) field consume 12 octets, leaving 1464 octets for source addresses, - which limits the number of source addresses to 366 (1464/4). - - - Valid only on query of version 3. - - - - - The Source Address [i] fields are a vector of n IP unicast addresses, - where n is the value in the Number of Sources (N) field. - - - Valid only on query of version 3. - - - - - The Number of Group Records (M) field specifies how many Group Records are present in this Report. - - - Valid only on report of version 3. - - - - - Each Group Record is a block of fields containing information pertaining to the sender's membership in a single multicast group on the interface from which the Report is sent. - - - - - RFC 1788. - - - - - The value of this field determines the format of the remaining data. - - - - - The ICMP code values for Code Conversion Failed ICMP type. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 2616. - Represents an HTTP layer. - - - - - Two HTTP layers are equal iff they have the same version, header and body. - Extended by specific HTTP layers types for more checks. - - - - - Two HTTP layers are equal iff they have the same version, header and body. - Extended by specific HTTP layers types for more checks. - - - - - Writes the HTTP layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - True iff the message is a request and iff the message is not a response. - - - - - True iff the message is a response and iff the message is not a request. - - - - - The version of this HTTP message. - - - - - The header of the HTTP message. - - - - - Message Body. - - - - - The number of bytes this layer will take. - - - - - Base class for all datagrams that behave like Ethernet. - Contains a header with an Ethernet type and a payload that should be according to this Ethernet type. - - - - - Header length in bytes. - - - - - Ethernet type (next protocol). - - - - - The Ethernet payload. - - - - - The bytes padding the Ethernet packet beyond the actual Ethernet payload until it is a 60 bytes packet. - This assumes we know how to calculate the actual payload length (For example, by using the Total Length of the IPv4 payload). - If we don't know how to calculate the actual payload length will be returned. - The Padding doesn't include the and the if any exist. - - - - - The bytes padding the Ethernet packet beyond the actual Ethernet payload and beyond the first 60 bytes of the packet. - This assumes we know how to calculate the actual payload length (For example, by using the Total Length of the IPv4 payload). - If we don't know how to calculate the actual payload length will be returned. - The trailer doesn't include the and the if any exist. - - - - - The 4 bytes of the Frame Check Sequence (FCS). - Usually, these bytes won't be available because the device remvoed them after checking their validity. - We assume they exist when we see that the Ethernet extra bytes pads to 68 bytes or more. - If the packet isn't that long or we don't know how to calculate the real payload length, will be returned. - - - - - A sequence of bytes that includes the padding bytes, trailer bytes and the frame check sequence bytes. - - - - - The Ethernet payload as a VLAN Tagged Frame datagram. - - - - - The Ethernet payload as an IPv4 datagram. - - - - - The Ethernet payload as an IPv6 datagram. - - - - - Returns the IP Datagram. - This is either an IPv4 Datagram or an IPv6 Datagram (according to the Ethernet Type). - - - - - The Ethernet payload as an ARP datagram. - - - - - RFC 4255. - 
-            +-----+-----------+-----------+
-            | bit | 0-7       | 8-15      |
-            +-----+-----------+-----------+
-            | 0   | algorithm | fp type   |
-            +-----+-----------+-----------+
-            | 16  | fingerprint           |
-            | ... |                       |
-            +-----+-----------------------+
-
- - - - - Constructs an instance out of the algorithm, fingerprint type and fingerprint fields. - - Describes the algorithm of the public key. - Describes the message-digest algorithm used to calculate the fingerprint of the public key. - - The fingerprint is calculated over the public key blob. - The message-digest algorithm is presumed to produce an opaque octet string output, which is placed as-is in the RDATA fingerprint field. - - - - - Two DnsResourceDataSshFingerprint are equal iff the algorithm, fingerprint type and fingerprint fields are equal. - - - - - Two DnsResourceDataSshFingerprint are equal iff the algorithm, fingerprint type and fingerprint fields are equal. - - - - - A hash code based on the algorithm, fingerprint type and fingerprint fields. - - - - - Describes the algorithm of the public key. - - - - - Describes the message-digest algorithm used to calculate the fingerprint of the public key. - - - - - The fingerprint is calculated over the public key blob. - The message-digest algorithm is presumed to produce an opaque octet string output, which is placed as-is in the RDATA fingerprint field. - - - - - RFC 5155. - 
-            +-----+-------------+----------+--------+------------+
-            | bit | 0-7         | 8-14     | 15     | 16-31      |
-            +-----+-------------+----------+--------+------------+
-            | 0   | Hash Alg    | Reserved | OptOut | Iterations |
-            +-----+-------------+----------+--------+------------+
-            | 32  | Salt Length | Salt                           |
-            +-----+-------------+                                |
-            | ... |                                              |
-            +-----+----------------------------------------------+
-
- - - - - RFC 5155. - 
-            +-----+-------------+----------+--------+------------+
-            | bit | 0-7         | 8-14     | 15     | 16-31      |
-            +-----+-------------+----------+--------+------------+
-            | 0   | Hash Alg    | Reserved | OptOut | Iterations |
-            +-----+-------------+----------+--------+------------+
-            | 32  | Salt Length | Salt                           |
-            +-----+-------------+                                |
-            | ... |                                              |
-            +-----+----------------------------------------------+
-            | ... | ...                                          |
-            +-----+----------------------------------------------+
-
- - - - - Identifies the cryptographic hash algorithm used to construct the hash-value. - - - - - Can be used to indicate different processing. - All undefined flags must be zero. - - - - - Defines the number of additional times the hash function has been performed. - More iterations result in greater resiliency of the hash value against dictionary attacks, - but at a higher computational cost for both the server and resolver. - - - - - Appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks. - - - - - Constructs a next domain secure 3 parameters resource data from the hash algorithm, flags, iterations and salt fields. - - Identifies the cryptographic hash algorithm used to construct the hash-value. - Can be used to indicate different processing. All undefined flags must be zero. - - Defines the number of additional times the hash function has been performed. - More iterations result in greater resiliency of the hash value against dictionary attacks, - but at a higher computational cost for both the server and resolver. - - Appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks. - - - - Two DnsResourceDataNextDomainSecure3Parameters are equal if they have the hash algorithm, flags, iterations and salt fields. - - - - - Two DnsResourceDataNextDomainSecure3Parameters are equal if they have the hash algorithm, flags, iterations and salt fields. - - - - - A hash code made up from the combination of the hash algorithm, flags, iterations and salt fields. - - - - - RFC 3596. - 
-            +-----+-------+
-            | bit | 0-127 |
-            +-----+-------+
-            | 0   | IP    |
-            +-----+-------+
-
- - - - - Constructs an IPv6 resource data from the given IP. - - - - - Two IPv6 resource datas are equal if their IP is equal. - - - - - Two IPv6 resource datas are equal if their IP is equal. - - - - - Returns the hash code of the IPv6 value. - - - - - The IPv6 value. - - - - - RFC 2671. - A set of options. - - - - - Constructs options from the given list of options. - The given otpions list should be modified after the call to this constructor. - - - - - Constructs options from the given list of options. - The given otpions list should be modified after the call to this constructor. - - - - - Two options objects are equal if they have the same options in the same order. - - - - - Two options objects are equal if they have the same options in the same order. - - - - - A hash code based on the list of options. - - - - - Empty options. - - - - - The list of options. - - - - - The total number of bytes the options take. - - - - - http://files.dns-sd.org/draft-sekar-dns-llq.txt. - - - - - Undefined value. - - - - - An LLQ is initiated by a client, and is completed via a four-way handshake. - This handshake provides resilience to packet loss, demonstrates client reachability, and reduces denial of service attack opportunities. - - - - - If the client desires to maintain the LLQ beyond the duration specified in the LEASE-LIFE field of the Request Acknowledgment, - the client must send a Refresh Request. - A Refresh Request is identical to an LLQ Challenge Response, but with the LLQ-OPCODE set to LLQ-REFRESH. - Unlike a Challenge Response, a Refresh Request returns no answers. - - - - - When a change ("event") occurs to a name server's zone, the server must check if the new or deleted resource records answer any LLQs. - If so, the resource records must be sent to the LLQ requesters in the form of a gratuitous DNS response sent to the client, - with the question(s) being answered in the Question section, and answers to these questions in the Answer section. - The response also includes an OPT RR as the last record in the Additional section. - This OPT RR contains, in its RDATA, an entry for each LLQ being answered in the message. - Entries must include the LLQ-ID. This reduces the potential for spoof events being sent to a client. - - - - - RFC 2535. - - - - - Undefined value. - - - - - Connection with TLS. - - - - - Connection with email. - - - - - DNS security. - The protocol field should be set to this value for zone keys and other keys used in DNS security. - Implementations that can determine that a key is a DNS security key by the fact that flags label it a zone key or the signatory flag field is non-zero are not required to check the protocol field. - - - - - Oakley/IPSEC [RFC 2401] protocol. - Indicates that this key is valid for use in conjunction with that security standard. - This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user flag bits are set. - The presence of a KEY resource with this protocol value is an assertion that the host speaks Oakley/IPSEC. - - - - - The key can be used in connection with any protocol for which KEY RR protocol octet values have been defined. - The use of this value is discouraged and the use of different keys for different protocols is encouraged. - - - - - A simple TCP option - holds only the type. - - - - - The number of bytes this option will take. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - TCP POC-permitted Option (RFC 1693) - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-
- - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates a partial order connection permitted option. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - TCP Alternate Checksum Request Option (RFC 1146). - 
-            +-----+----------+
-            | Bit | 0-7      |
-            +-----+----------+
-            | 0   | Kind     |
-            +-----+----------+
-            | 8   | Length   |
-            +-----+----------+
-            | 16  | Checksum |
-            +-----+----------+
-
- - - Here chksum is a number identifying the type of checksum to be used. - - - - The currently defined values of chksum are: - - 0 - TCP checksum. - 1 - 8-bit Fletcher's algorithm. - 2 - 16-bit Fletcher's algorithm. - - - - - Note that the 8-bit Fletcher algorithm gives a 16-bit checksum and the 16-bit algorithm gives a 32-bit checksum. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates the option using the given checksum type. - - - - - The default checksum type is the TCP checksum. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The type of the checksum. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - Represents an IPv6 address. - - - - - The number of bytes the address take. - - - - - Create an address from a 128 bit integer. - 0 -> :: - 1 -> ::1 - 256 -> ::100 - - - - - Creates an address from an address string ("2001:0db8:0::22:1.2.3.4"). - - - - - Gets the address value as a 128 bit integer. - - - - - Two addresses are equal if the have the exact same value. - - - - - Two addresses are equal if the have the exact same value. - - - - - Two addresses are equal if the have the exact same value. - - - - - Two addresses are different if the have different values. - - - - - The hash code of an address is the hash code of its 128 bit integer value. - - - - - Translates the address to a string (0ABC:1234:5678:0443:0ABC:1234:5678:0443). - - - - - Translates the address to a string given the format. - - - - - Translates the address to a string given the format provider. - - - - - Translates the address to a string given the format and format provider. - - - - - The zero address (::). - - - - - The maximum address value. - - - - - RFC 4782. - 
-            +-----+-------------+------+----------+--------------+-------+-------+
-            | Bit | 0-7         | 8-15 | 16-19    | 20-23        | 24-29 | 30-31 |
-            +-----+-------------+------+----------+--------------+-------+-------+
-            | 0   | Option Type | 6    | Function | Rate Request | QS TTL        |
-            +-----+-------------+------+----------+--------------+-------+-------+
-            | 32  | QS Nonce                                             | R     |
-            +-----+------------------------------------------------------+-------+
-
- - - - - RFC 4782. - Common interface of a quick start option. - - - - - The function of this quick start option. - - - - - If function is request then this field is the rate request. - If function is report then this field is the rate report. - - - - - The rate translated to KBPS. - - - - - The Quick-Start TTL (QS TTL) field. - The sender MUST set the QS TTL field to a random value. - Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. - The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. - - - For a Rate Request, the transport sender MUST calculate and store the TTL Diff, - the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows: - TTL Diff = ( IP TTL - QS TTL ) mod 256 - - - - - - The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. - This is particularly important if the receiver knows the original value of the Rate Request - (e.g., when the sender always requests the same value, and the receiver has a long history of communication with that sender). - Without the QS Nonce, there is nothing to prevent the receiver from reporting back to the sender a Rate Request of K, - when the received Rate Request was, in fact, less than K. - - - The format for the 30-bit QS Nonce. - - - Bits - Purpose - - Bits 0-1Rate 15 -> Rate 14 - Bits 2-3Rate 14 -> Rate 13 - Bits 4-5Rate 13 -> Rate 12 - Bits 6-7Rate 12 -> Rate 11 - Bits 8-9Rate 11 -> Rate 10 - Bits 10-11Rate 10 -> Rate 9 - Bits 12-13Rate 9 -> Rate 8 - Bits 14-15Rate 8 -> Rate 7 - Bits 16-17Rate 7 -> Rate 6 - Bits 18-19Rate 6 -> Rate 5 - Bits 20-21Rate 5 -> Rate 4 - Bits 22-23Rate 4 -> Rate 3 - Bits 24-25Rate 3 -> Rate 2 - Bits 26-27Rate 2 -> Rate 1 - Bits 28-29Rate 1 -> Rate 0 - - - - - The transport sender MUST initialize the QS Nonce to a random value. - If the router reduces the Rate Request from rate K to rate K-1, - then the router MUST set the field in the QS Nonce for "Rate K -> Rate K-1" to a new random value. - Similarly, if the router reduces the Rate Request by N steps, - the router MUST set the 2N bits in the relevant fields in the QS Nonce to a new random value. - The receiver MUST report the QS Nonce back to the sender. - - - - If the Rate Request was not decremented in the network, then the QS Nonce should have its original value. - Similarly, if the Rate Request was decremented by N steps in the network, - and the receiver reports back a Rate Request of K, then the last 2K bits of the QS Nonce should have their original value. - - - - - - The number of bytes the option data takes. - - - - - Creates an instance from the given function, rate, TTL and nonce. - - Function field. - - For rate request, this is the Rate Request field. - For Report of Approved Rate, this is the Rate Report field. - - - For a Rate Request, contains the Quick-Start TTL (QS TTL) field. - The sender must set the QS TTL field to a random value. - Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. - The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. - The transport sender must calculate and store the TTL Diff, the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows: - TTL Diff = ( IP TTL - QS TTL ) mod 256. - For a Report of Approved Rate, this is not used. - - - For a Rate Request and Report of Approved Rate, contain a 30-bit QS Nonce. - The sender should set the QS Nonce to a random value. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - Function field. - - - - - For rate request, this is the Rate Request field. - For Report of Approved Rate, this is the Rate Report field. - - - - - The rate translated to KBPS. - - - - - For a Rate Request, contains the Quick-Start TTL (QS TTL) field. - The sender must set the QS TTL field to a random value. - Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. - The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. - The transport sender must calculate and store the TTL Diff, the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows: - TTL Diff = ( IP TTL - QS TTL ) mod 256. - For a Report of Approved Rate, this is not used. - - - - - For a Rate Request and Report of Approved Rate, contain a 30-bit QS Nonce. - The sender should set the QS Nonce to a random value. - - - - - +-----+-----+ - | Bit | 0-7 | - +-----+-----+ - | 0 | 0 | - +-----+-----+ - - - - - RFC 2460. - 
-            +-----+-------------+
-            | Bit | 0-7         |
-            +-----+-------------+
-            | 0   | Option Type |
-            +-----+-------------+
-
- - - - - The number of bytes this option takes. - - - - - The number of bytes the option takes. - - - - - Constructs an instance. - - - - - RFC 5555. - 
-            +-----+------------+---+---+--------------+
-            | Bit | 0-5        | 6 | 7 | 8-15         |
-            +-----+------------+---+---+--------------+
-            | 0   | Option Type        | Opt Data Len |
-            +-----+------------+---+---+--------------+
-            | 16  | Prefix-len | P | Reserved         |
-            +-----+------------+---+------------------+
-            | 32  | IPv4 home address                 |
-            |     |                                   |
-            +-----+-----------------------------------+
-
- - - - - The maximum value for Prefix Length. - - - - - The number of bytes this option data takes. - - - - - Creates an instance from Prefix Length, Request Prefix and Home Address. - - - The length of the prefix allocated to the mobile node. - If only a single address is allocated, this field must be set to 32. - In the first binding update requesting a prefix, the field contains the prefix length requested. - However, in the following binding updates, this field must contain the length of the prefix allocated. - A value of zero is invalid and must be considered an error. - - - When true, indicates that the mobile node requests a mobile network prefix. - This flag is only relevant for new requests, and must be ignored for binding refreshes. - - - The mobile node's IPv4 home address that should be defended by the home agent. - This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. - The value 0.0.0.0 is used to request an IPv4 home address from the home agent. - A mobile node may choose to use this option to request a prefix by setting the address to All Zeroes and setting the RequestPrefix flag. - The mobile node could then form an IPv4 home address based on the allocated prefix. - Alternatively, the mobile node may use two different options, one for requesting an address (static or dynamic) and another for requesting a - - - - - The length of the prefix allocated to the mobile node. - If only a single address is allocated, this field must be set to 32. - In the first binding update requesting a prefix, the field contains the prefix length requested. - However, in the following binding updates, this field must contain the length of the prefix allocated. - A value of zero is invalid and must be considered an error. - - - - - When true, indicates that the mobile node requests a mobile network prefix. - This flag is only relevant for new requests, and must be ignored for binding refreshes. - - - - - The mobile node's IPv4 home address that should be defended by the home agent. - This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. - The value 0.0.0.0 is used to request an IPv4 home address from the home agent. - A mobile node may choose to use this option to request a prefix by setting the address to All Zeroes and setting the RequestPrefix flag. - The mobile node could then form an IPv4 home address based on the allocated prefix. - Alternatively, the mobile node may use two different options, one for requesting an address (static or dynamic) and another for requesting a - prefix. - - - - - RFC 5555, 5844. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-            | 32  | IPv4 address               |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - RFC 5568. - A code for a Link Layer Address IPv6 option. - - - - - Wildcard requesting resolution for all nearby access points. - - - - - Link-Layer Address of the New Access Point. - The address contains the link-layer address of the access point for which handover is about to be attempted. - This is used in the Router Solicitation for Proxy Advertisement message. - - - - - Link-Layer Address of the MN (Mobility Node). - The address contains the link-layer address of an MN. - It is used in the Handover Initiate message. - - - - - Link-Layer Address of the NAR (New Access Router) (i.e., Proxied Originator). - The address contains the link-layer address of the access router to which the Proxy Router Solicitation message refers. - - - - - Link-Layer Address of the source of RtSolPr (Router Solicitation for Proxy Advertisement) or PrRtAdv (Proxy Router Advertisement) message. - - - - - The access point identified by the LLA belongs to the current interface of the router. - - - - - No prefix information available for the access point identified by the LLA - - - - - No fast handover support available for the access point identified by the LLA - - - - - RFC 5844. - - - - - Success. - - - - - Failure, reason unspecified. - - - - - Administratively prohibited. - - - - - Incorrect IPv4 home address. - - - - - Invalid IPv4 address. - - - - - Dynamic IPv4 home address assignment not available. - - - - - RFC 6089. - - - - - Creates options from a list of options. - - The list of options. - - - - Creates options from a list of options. - - The list of options. - - - - No options instance. - - - - - RFC 4285 - - - - - Invalid value. - - - - - Used to authenticate the Binding Update and Binding Acknowledgement messages based on the shared-key-based security association - between the Mobile Node and the Home Agent. - The shared-key-based mobility security association between Mobile Node and Home Agent used within this specification consists of a mobility SPI, - a key, an authentication algorithm, and the replay protection mechanism in use. - The mobility SPI is a number in the range [0-4294967296], where the range [0-255] is reserved. - The key consists of an arbitrary value and is 16 octets in length. - The authentication algorithm is HMAC_SHA1. - The replay protection mechanism may use the Sequence number as specified in RFC 3775 or the Timestamp option. - If the Timestamp option is used for replay protection, the mobility security association includes a "close enough" field to account - for clock drift. - A default value of 7 seconds should be used. - This value should be greater than 3 seconds. - The MN-HA mobility message authentication option must be the last option in a message with a mobility header - if it is the only mobility message authentication option in the message. - The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option. - Authentication Data = First(96, HMAC_SHA1(MN-HA Shared key, Mobility Data)) - Mobility Data = care-of address | home address | Mobility Header (MH) Data - MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. - The Checksum field in the Mobility Header must be set to 0 to calculate the Mobility Data. - The first 96 bits from the Message Authentication Code (MAC) result are used as the Authentication Data field. - - - - - The MN-AAA authentication mobility option is used to authenticate the Binding Update message based on the shared mobility security association - between the Mobile Node and AAA server in Home network (AAAH). - It is not used in Binding Acknowledgement messages. - The corresponding Binding Acknowledgement messages must be authenticated using the MN-HA mobility message authentication option. - The MN-AAA mobility message authentication option must be the last option in a message with a mobility header. - The corresponding response must include the MN-HA mobility message authentication option, - and must not include the MN-AAA mobility message authentication option. - The Mobile Node may use the Mobile Node Identifier option (RFC 4283) to enable the Home Agent to make use of available AAA infrastructure. - The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option. - The authentication data shall be calculated as follows: - Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) - hash_fn() is decided by the value of mobility SPI field in the MN-AAA mobility message authentication option. - SPI = HMAC_SHA1_SPI: - If mobility SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is HMAC_SHA1. - When HMAC_SHA1_SPI is used, the BU is authenticated by AAA using HMAC_SHA1 authentication. - In that case, MAC_Mobility Data is calculated as follows: - MAC_Mobility Data = SHA1(care-of address | home address | MH Data) - MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. - - - - - RFC 6757. - 
-            +-----+---------------------+
-            | Bit | 0-7                 |
-            +-----+---------------------+
-            | 0   | ANI Type            |
-            +-----+---------------------+
-            | 8   | ANI Length          |
-            +-----+---------------------+
-            | 16  | Op-ID Type          | 
-            +-----+---------------------+
-            | 24  | Operator-Identifier |
-            | ... |                     | 
-            +-----+---------------------+
-
- - - - - RFC 6757. - - - - - True iff the two options are equal. - Two options are equal iff their type, length and data are equal. - - - - - True iff the two options are equal. - Two options are equal iff their type, length and data are equal. - - - - - Returns the option hash code. - - - - - The type of the option. - - - - - The number of bytes this option takes. - - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from identifier type and identifier. - - Indicates the type of the Operator-Identifier. - - Up to 253 octets of the Operator-Identifier. - The encoding of the identifier depends on the used Operator-Identifier Type. - - - - - Indicates the type of the Operator-Identifier. - - - - - Up to 253 octets of the Operator-Identifier. - The encoding of the identifier depends on the used Operator-Identifier Type. - - - - - Represents IPv6 layer. - - - - - - A layer under an Ethernet layer. - Must provide the Ethernet Type and the default destination MAC address (if any). - - - - - The Ethernet Type the Ethernet layer should write when this layer is the Ethernet payload. - - - - - The default MAC Address value when this layer is the Ethernet payload. - null means there is no default value. - - - - - Creates an IPv6 layer with all zero values. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Finalizes the layer data in the buffer. - Used for fields that must be calculated according to the layer's payload (like checksum). - - The buffer to finalize the layer in. - The offset in the buffer the layer starts. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes after this layer. null if this is the last layer. - - - - True iff the two IPv4 layers have the same TypeOfService, Identification, Fragmentation, Ttl, Protocol, HeaderChecksum, Source, Destination and Options. - - - - - True iff the two IPv4 layers have the same TypeOfService, Identification, Fragmentation, Ttl, Protocol, HeaderChecksum, Source, Destination and Options. - - - - - Returns a hash code for the layer. - The hash code is a XOR of the TrafficClass and HopLimit combined and the hash codes of the FlowLabel, Source, CurrentDestination, NextHeader, HeaderChecksum, ExtensionHeaders. - - - - - Contains the Source, Destination and Protocol. - - - - - Available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of - IPv6 packets. - - - - - May be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, - such as non-default quality of service or "real-time" service. - Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, - pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet. - - - - - Identifies the type of header immediately following the IPv6 header. - Uses the same values as the IPv4 Protocol field. - null means that this value should be calculated according to the next layer. - - - - - Decremented by 1 by each node that forwards the packet. - The packet is discarded if Hop Limit is decremented to zero. - - - - - Address of the originator of the packet. - - - - - Address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). - - - - - The IPv6 extension headers. - - - - - The Ethernet Type the Ethernet layer should write when this layer is the Ethernet payload. - - - - - The protocol that should be written in the previous (IPv4) layer (in this case: IP). - - - - - The default MAC Address value when this layer is the Ethernet payload. - null means there is no default value. - - - - - The number of bytes this layer will take. - - - - - The IPv6 last next header field. - If there are no extension headers, this is the IPv6 layer next header field. - If there are extesion headers, this is the last extension header next header field. - Returns null if the last next header should be calculated automatically when building a packet. - - - - - RFC 5568. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Sequence #                            |
-            +-----+-------------+-------------------------+
-            | 64  | Reserved    | Code                    |
-            +-----+-------------+-------------------------+
-            | 80  | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, sequence number, code and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Copied from the corresponding field in the Handover Initiate message to which this message is a response, - to enable the receiver to match this Handover Acknowledge message with an outstanding Handover Initiate message. - - Describes whether the handover was accepted or not and more details. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Copied from the corresponding field in the Handover Initiate message to which this message is a response, - to enable the receiver to match this Handover Acknowledge message with an outstanding Handover Initiate message. - - - - - Describes whether the handover was accepted or not and more details. - - - - - RFC 5568. - 
-            +-----+---+---+---+---+-----+-------------------------+
-            | Bit | 0 | 1 | 2 | 3 | 4-7 | 8-15                    |
-            +-----+---+---+---+---+-----+-------------------------+
-            | 0   | Next Header         | Header Extension Length |
-            +-----+---------------------+-------------------------+
-            | 16  | MH Type             | Reserved                |
-            +-----+---------------------+-------------------------+
-            | 32  | Checksum                                      |
-            +-----+---------------------+-------------------------+
-            | 48  | Sequence #                                    |
-            +-----+---+---+---+---+-------------------------------+
-            | 64  | A | H | L | K | Reserved                      |
-            +-----+---+---+---+---+-------------------------------+
-            | 80  | Lifetime                                      |
-            +-----+-----------------------------------------------+
-            | 96  | Mobility Options                              |
-            | ... |                                               |
-            +-----+-----------------------------------------------+
-
- - - - - RFCs 5568, 6275. - 
-            +-----+---+---+---+---+-----+-------------------------+
-            | Bit | 0 | 1 | 2 | 3 | 4-7 | 8-15                    |
-            +-----+---+---+---+---+-----+-------------------------+
-            | 0   | Next Header         | Header Extension Length |
-            +-----+---------------------+-------------------------+
-            | 16  | MH Type             | Reserved                |
-            +-----+---------------------+-------------------------+
-            | 32  | Checksum                                      |
-            +-----+-----------------------------------------------+
-            | 48  | Sequence #                                    |
-            +-----+---+---+---+---+-------------------------------+
-            | 64  | A | H | L | K | Reserved                      |
-            +-----+---+---+---+---+-------------------------------+
-            | 80  | Lifetime                                      |
-            +-----+-----------------------------------------------+
-            | 96  | Mobility Options                              |
-            | ... |                                               |
-            +-----+-----------------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. - - - - - Set by the sending mobile node to request a Binding Acknowledgement be returned upon receipt of the Binding Update. - For Fast Binding Update this must be set to one to request that PAR send a Fast Binding Acknowledgement message. - - - - - Set by the sending mobile node to request that the receiving node should act as this node's home agent. - The destination of the packet carrying this message must be that of a router sharing the same subnet prefix as the home address - of the mobile node in the binding. - For Fast Binding Update this must be set to one. - - - - - Set when the home address reported by the mobile node has the same interface identifier as the mobile node's link-local address. - - - - - - If this is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent - does not survive movements. - It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) - If manual IPsec configuration is used, the bit must be cleared. - - - This bit is valid only in Binding Updates sent to the home agent, and mustbe cleared in other Binding Updates. - Correspondent nodes must ignore this bit. - - - - - - The number of time units remaining before the binding must be considered expired. - A value of zero indicates that the Binding Cache entry for the mobile node must be deleted. - One time unit is 4 seconds for Binding Update and 1 second for Fast Binding Update. - - - - - Creates an instance from next header, checksum, sequence number, acknowledge, home registration, link local address compatilibity, - key management mobility capability, lifetime and options. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. - - - Set by the sending mobile node to request a Binding Acknowledgement be returned upon receipt of the Binding Update. - For Fast Binding Update this must be set to one to request that PAR send a Fast Binding Acknowledgement message. - - - Set by the sending mobile node to request that the receiving node should act as this node's home agent. - The destination of the packet carrying this message must be that of a router sharing the same subnet prefix as the home address - of the mobile node in the binding. - For Fast Binding Update this must be set to one. - - - Set when the home address reported by the mobile node has the same interface identifier as the mobile node's link-local address. - - - If this is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent - does not survive movements. - It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) - If manual IPsec configuration is used, the bit must be cleared. - - - The number of time units remaining before the binding must be considered expired. - A value of zero indicates that the Binding Cache entry for the mobile node must be deleted. - One time unit is 4 seconds for Binding Update and 1 second for Fast Binding Update. - - - Zero or more TLV-encoded mobility options. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - RFCs 791, 2460. - Represents an IP datagram. - 
-            +-----+---------+
-            | Bit | 0-3     |
-            +-----+---------+
-            | 0   | Version |
-            +-----+---------+
-            | 4   |         |
-            | ... |         |
-            +-----+---------+
-
- - - - - Calculates the Transport checksum field value. - - The calculated checksum value. - - - - Indicates the format of the internet header (Internet Protocol version). - - - - - The total length - header and payload according to the IP header. - - - - - Returns whether the TCP or UDP checksum is correct. - The protocol must be TCP or UDP. - For UDP, the checksum is optional, so 0 checksum is still correct. - - - - - The payload of the datagram. - - - - - The payload of the datagram as an IPv4 datagram (IP over IP). - - - - - The payload of the datagram as an IPv6 datagram (IP over IP). - - - - - Returns the inner IP Datagram. - This is either an IPv4 Datagram or an IPv6 Datagram (according to the Payload Protocol). - - - - - The payload of the datagram as an ICMP datagram. - - - - - The payload of the datagram as an IGMP datagram. - - - - - The payload of the datagram as a TCP datagram. - - - - - The payload of the datagram as a GRE datagram. - - - - - The payload of the datagram as a UDP datagram. - - - - - Returns the Tranposrt Datagram. - This is either a TCP Datagram or a UDP Datagram (according to the payload protocol). - - - - - RFC 792. - - - - - RFC 792. - Represents an ICMP Timestamp layer. - - - - - - Writes the ICMP payload to the buffer. - Doesn't include payload in the next layers. - - The buffer to write the ICMP payload to. - The offset in the buffer to start writing the payload at. - - - - True iff the OriginateTimestamp, ReceiveTimestamp and the TransmitTimestamp fields are equal. - - - - - True iff the OriginateTimestamp, ReceiveTimestamp and the TransmitTimestamp fields are equal. - - - - - The time the sender last touched the message before sending it. - - - - - The time the echoer first touched it on receipt. - - - - - The time the echoer last touched the message on sending it. - - - - - The value of this field determines the format of the remaining data. - - - - - The number of bytes the ICMP payload takes. - - - - - The value of this field determines the format of the remaining data. - - - - - RFC 792. - Represents an ICMP Redirect message layer. - - - - - - A sub-type of the message. Specific method of this message type. - - - - - Address of the gateway to which traffic for the network specified in the internet destination network field of the original datagram's data should be sent. - - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - A value that should be interpreted according to the specific message. - - - - - The different ICMP code values for Security Failures ICMP type. - - - - - RFC 2521. - Indicates that a received datagram includes a Security Parameters Index (SPI) that is invalid or has expired. - - - - - RFC 2521. - Indicates that a received datagram failed the authenticity or integrity check for a given SPI. - - - Note that the SPI may indicate an outer Encapsulating Security Protocol when a separate Authentication Header SPI is hidden inside. - - - - - - RFC 2521. - Indicates that a received datagram failed a decompression check for a given SPI. - - - - - RFC 2521. - Indicates that a received datagram failed a decryption check for a given SPI. - - - - - RFC 2521. - Indicates that a received datagram will not be accepted without additional authentication. - - - In this case, either no SPI is present, or an unsuitable SPI is present. - For example, an encryption SPI without integrity arrives from a secure operating system with mutually suspicious users. - - - - - - RFC 2521. - Indicates that a received datagram will not be accepted because it has insufficient authorization. - - - In this case, an authentication SPI is present that is inappropriate for the target transport or application. - The principle party denoted by the SPI does not have proper authorization for the facilities used by the datagram. - For example, the party is authorized for Telnet access, but not for FTP access. - - - - - - Known HTTP request method. - RFC 2616. - - - - - RFC 2616. - - The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. - This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. - - - Responses to this method are not cacheable. - - - If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), - then the media type MUST be indicated by a Content-Type field. - Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. - A server that does not support such an extension MAY discard the request body. - - - If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. - Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; - it does nothing beyond allowing the client to test the capabilities of the server. - For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). - - - If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource. - - - A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), - possibly including extensions not defined by this specification. - The response body, if any, SHOULD also include information about the communication options. - The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. - Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0". - - - The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. - When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. - If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. - If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. - If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field. - - - - - - RFC 2616. - - The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. - If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, - unless that text happens to be the output of the process. - - - The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. - A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). - The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client. - - - The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. - A partial GET requests that only part of the entity be transferred. - The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client. - - - The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching. - - - - - - RFC 2616. - - The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. - The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. - This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. - This method is often used for testing hypertext links for validity, accessibility, and recent modification. - - - The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. - If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), - then the cache MUST treat the cache entry as stale. - - - - - - RFC 2616. - - The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. - POST is designed to allow a uniform method to cover the following functions: - - Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation. - - - - The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. - The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, - a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. - - - The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, - depending on whether or not the response includes an entity that describes the result. - - - If a resource has been created on the origin server, - the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header. - - - Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. - However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. - - - POST requests MUST obey the message transmission requirements. - - - - - - RFC 2616. - - The PUT method requests that the enclosed entity be stored under the supplied Request-URI. - If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. - If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. - If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. - If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. - If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. - The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases. - - - If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. - Responses to this method are not cacheable. - - - The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. - The URI in a POST request identifies the resource that will handle the enclosed entity. - That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. - In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. - If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; - the user agent MAY then make its own decision regarding whether or not to redirect the request. - - - A single resource MAY be identified by many different URIs. - For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. - In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server. - - - HTTP/1.1 does not define how a PUT method affects the state of an origin server. - - - PUT requests MUST obey the message transmission requirements. - - - Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT. - - - - - - RFC 2616. - - The DELETE method requests that the origin server delete the resource identified by the Request-URI. - This method MAY be overridden by human intervention (or other means) on the origin server. - The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. - However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. - - - A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, - or 204 (No Content) if the action has been enacted but the response does not include an entity. - - - If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. - Responses to this method are not cacheable. - - - - - - RFC 2616. - - The TRACE method is used to invoke a remote, application-layer loop-back of the request message. - The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. - The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). - A TRACE request MUST NOT include an entity. - - - TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. - The value of the Via header field is of particular interest, since it acts as a trace of the request chain. - Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop. - - - If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". - Responses to this method MUST NOT be cached. - - - - - - RFC 2616. - - This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling). - - - - - - Unknown request method. - - - - - Eastlake. - - - - - Undefined value. - - - - - The SNMP subset of ASN.1. - Basic Encoding Rules. - - - - - The SNMP subset of ASN.1. - Distinguished Encoding Rules. - - - - - The SNMP subset of ASN.1. - Packed Encoding Rules Aligned. - - - - - The SNMP subset of ASN.1. - Packed Encoding Rules Unaligned. - - - - - The SNMP subset of ASN.1. - Canonical Encoding Rules. - - - - - The SNMP subset of ASN.1. - An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding. - - - - - OSI ASN.1 1990 [ASN.1]. - Basic Encoding Rules. - - - - - OSI ASN.1 1990 [ASN.1]. - Distinguished Encoding Rules. - - - - - OSI ASN.1 1990 [ASN.1]. - Packed Encoding Rules Aligned. - - - - - OSI ASN.1 1990 [ASN.1]. - Packed Encoding Rules Unaligned. - - - - - OSI ASN.1 1990 [ASN.1]. - Canonical Encoding Rules. - - - - - OSI ASN.1 1990 [ASN.1]. - An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding. - - - - - OSI ASN.1 1994. - Basic Encoding Rules. - - - - - OSI ASN.1 1994. - Distinguished Encoding Rules. - - - - - OSI ASN.1 1994. - Packed Encoding Rules Aligned. - - - - - OSI ASN.1 1994. - Packed Encoding Rules Unaligned. - - - - - OSI ASN.1 1994. - Canonical Encoding Rules. - - - - - OSI ASN.1 1994. - An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding. - - - - - Private abstract syntax notations. - This coding value will not be assigned to a standard abstract syntax notation. - An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used. - Basic Encoding Rules. - - - - - Private abstract syntax notations. - This coding value will not be assigned to a standard abstract syntax notation. - An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used. - Distinguished Encoding Rules. - - - - - Private abstract syntax notations. - This coding value will not be assigned to a standard abstract syntax notation. - An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used. - Packed Encoding Rules Aligned. - - - - - Private abstract syntax notations. - This coding value will not be assigned to a standard abstract syntax notation. - An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used. - Packed Encoding Rules Unaligned. - - - - - Private abstract syntax notations. - This coding value will not be assigned to a standard abstract syntax notation. - An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used. - Canonical Encoding Rules. - - - - - Private abstract syntax notations. - This coding value will not be assigned to a standard abstract syntax notation. - An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used. - An OID preceded by a one byte unsigned length appears in the data area just after the coding OID. - - - - - MIME structured data [RFC 2045, 2046]. - The data portion is a MIME structured message. - The "MIME-Version:" header line may be omitted unless the version is other than "1.0". - Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. - 7 bit. - - - - - MIME structured data [RFC 2045, 2046]. - The data portion is a MIME structured message. - The "MIME-Version:" header line may be omitted unless the version is other than "1.0". - Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. - 8 bit. - - - - - MIME structured data [RFC 2045, 2046]. - The data portion is a MIME structured message. - The "MIME-Version:" header line may be omitted unless the version is other than "1.0". - Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. - Binary. - - - - - MIME structured data [RFC 2045, 2046]. - The data portion is a MIME structured message. - The "MIME-Version:" header line may be omitted unless the version is other than "1.0". - Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. - Quoted-printable. - - - - - MIME structured data [RFC 2045, 2046]. - The data portion is a MIME structured message. - The "MIME-Version:" header line may be omitted unless the version is other than "1.0". - Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. - Base 64. - - - - - MIME structured data [RFC 2045, 2046]. - The data portion is a MIME structured message. - The "MIME-Version:" header line may be omitted unless the version is other than "1.0". - Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism. - The data portion must start with an "x-" token denoting the private content-transfer-encoding immediately followed by one null (zero) octet - followed by the remainder of the MIME object. - - - - - Text tagged data. - The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item - is considered to be a tag labeling the immediately following text item. - If there are an odd number of text items overall, then the last is considered to label a null text item. - Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). - Thus any organization with a domain name can assign tags without fear of conflict. - ASCII. - - - - - Text tagged data. - The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item - is considered to be a tag labeling the immediately following text item. - If there are an odd number of text items overall, then the last is considered to label a null text item. - Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). - Thus any organization with a domain name can assign tags without fear of conflict. - UTF-7 [RFC 1642]. - - - - - Text tagged data. - The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item - is considered to be a tag labeling the immediately following text item. - If there are an odd number of text items overall, then the last is considered to label a null text item. - Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). - Thus any organization with a domain name can assign tags without fear of conflict. - UTF-8 [RFC 2044]. - - - - - Text tagged data. - The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item - is considered to be a tag labeling the immediately following text item. - If there are an odd number of text items overall, then the last is considered to label a null text item. - Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). - Thus any organization with a domain name can assign tags without fear of conflict. - ASCII with MIME header escapes [RFC 2047]. - - - - - Text tagged data. - The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item - is considered to be a tag labeling the immediately following text item. - If there are an odd number of text items overall, then the last is considered to label a null text item. - Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). - Thus any organization with a domain name can assign tags without fear of conflict. - Each text item must start with a domain name [RFC 1034] denoting the private text encoding immediately followed by one null (zero) octet - followed by the remainder of the text item. - - - - - RFC 2845. - 
-            +------+-------------+----------+-----------+
-            | bit  | 0-15        | 16-31    | 32-47     |
-            +------+-------------+----------+-----------+
-            | 0    | Algorithm Name                     |
-            | ...  |                                    |
-            +------+------------------------------------+
-            | X    | Time Signed                        |
-            +------+-------------+----------+-----------+
-            | X+48 | Fudge       | MAC Size | MAC       |
-            +------+-------------+----------+           |
-            | ...  |                                    |
-            +------+-------------+----------+-----------+
-            | Y    | Original ID | Error    | Other Len |
-            +------+-------------+----------+-----------+
-            | Y+48 | Other Data                         |
-            | ...  |                                    |
-            +------+------------------------------------+
-
- - - - - Constructs an instance out of the algorithm time signed, fudge, message authentication code, original ID, error and other fields. - - Name of the algorithm in domain name syntax. - Seconds since 1-Jan-70 UTC. - Seconds of error permitted in Time Signed. - Defined by Algorithm Name. - Original message ID. - RCODE covering TSIG processing. - Empty unless Error == BADTIME. - - - - Two DnsResourceDataTransactionSignature are equal iff their algorithm time signed, fudge, message authentication code, original ID, error - and other fields are equal. - - - - - Two DnsResourceDataTransactionSignature are equal iff their algorithm time signed, fudge, message authentication code, original ID, error - and other fields are equal. - - - - - A hash code of the combination of the algorithm time signed, fudge, message authentication code, original ID, error and other fields. - - - - - Name of the algorithm in domain name syntax. - - - - - Seconds since 1-Jan-70 UTC. - - - - - Seconds of error permitted in Time Signed. - - - - - Defined by Algorithm Name. - - - - - Original message ID. - - - - - RCODE covering TSIG processing. - - - - - Empty unless Error == BADTIME. - - - - - RFC 2671. - 
-            0 Or more of:
-            +-----+---------------+
-            | bit | 0-15          |
-            +-----+---------------+
-            | 0   | OPTION-CODE   |
-            +-----+---------------+
-            | 16  | OPTION-LENGTH |
-            +-----+---------------+
-            | 32  | OPTION-DATA   |
-            | ... |               |
-            +-----+---------------+
-
- - - - - Constructs an instance from options. - - - - - Two DnsResourceDataOptions are equal if the options are equal. - - - - - Two DnsResourceDataOptions are equal if the options are equal. - - - - - The hash code of the options. - - - - - The list of options. - - - - - RFCs 1035, 2136, 2671, 2845, 2930, 4635. - - - - - RFC 1035. - No error condition - - - - - RFC 1035. - Format error - The name server was unable to interpret the query. - - - - - RFC 1035. - Server failure - The name server was unable to process this query due to a problem with the name server. - - - - - RFC 1035. - Name Error - Meaningful only for responses from an authoritative name server, - this code signifies that the domain name referenced in the query does not exist. - - - - - RFC 1035. - Not Implemented - The name server does not support the requested kind of query. - - - - - RFC 1035. - Refused - The name server refuses to perform the specified operation for policy reasons. - For example, a name server may not wish to provide the information to the particular requester, - or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. - - - - - RFC 2136. - YXDomain. Name Exists when it should not. - - - - - RFC 2136. - YXRRSET - RR Set Exists when it should not. - - - - - RFC 2136. - NXRRSET - RR Set that should exist does not (NX). - - - - - RFC 2136. - Server Not Authoritative for zone. - - - - - RFC 2136. - Name not contained in zone. - - - - - RFCs 2671, 2845. - Bad OPT Version or TSIG Signature Failure. - - - - - RFC 2845. - Key not recognized. - - - - - RFC 2845. - Signature out of time window. - - - - - RFC 2930. - Bad TKEY Mode. - - - - - RFC 2930. - Duplicate key name. - - - - - RFC 2930. - Algorithm not supported. - - - - - RFC 4635. - BADTRUNC - Bad Truncation. - - - - - RFC 2535. - - - - - Indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. - The coding of the owner name is that used for the responsible individual mailbox in the SOA and RP RRs: - The owner name is the user name as the name of a node under the entity name. - For example, "j_random_user" on host.subdomain.example could have a public key associated through a KEY RR with name j_random_user.host.subdomain.example. - It could be used in a security protocol where authentication of a user was desired. - This key might be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. - - - - - Indicates that this is a zone key for the zone whose name is the KEY RR owner name. - This is the public key used for the primary DNS security feature of data origin authentication. - Zone KEY RRs occur only at delegation points. - - - - - Indicates that this is a key associated with the non-zone "entity" whose name is the RR owner name. - This will commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as a telephone number [RFC 1530] or numeric IP address. - This is the public key used in connection with DNS request and transaction authentication services. - It could also be used in an IP-security protocol where authentication at the host, rather than user, level was desired, such as routing, NTP, etc. - - - - - A gateway that is represented using a domain name. - - - - - Creates the gateway using the given domain name. - - - - - Two DnsGatewayDomainName are equal if their domain name values are equal. - - - - - Two gateway representations are equal if they are of the same type and the value is the same. - - - - - Returns the domain name value. - - - - - The gateway represnetation type. - - - - - The number of bytes the gateway represnetation takes. - - - - - The ATM address format values. - - - - - ATM End System Address (AESA) format. - - - - - E.164 format. - - - - - RFC 1035. - 
-            +------+-------------------------------------------------+
-            | byte | 0-1                                             |
-            +------+-------------------------------------------------+
-            | 0    | Name                                            |
-            | ...  |                                                 |
-            +------+-------------------------------------------------+
-            |      | Type                                            |
-            +------+-------------------------------------------------+
-            |      | Class                                           |
-            +------+-------------------------------------------------+
-
- - - - - Creates a DNS query record from a domain name, type and class. - - An owner name, i.e., the name of the node to which this resource record pertains. - Two octets containing one of the RR TYPE codes. - Two octets containing one of the RR CLASS codes. - - - - Two query records are equal if they have the same domain name, type and class. - - - - - Two query records are equal if they have the same domain name, type and class. - - - - - A hash code based on the query record's domain name, type and class. - - - - - There's no TTL in a query record. - - - - - There's no data in a query record. - - - - - A domain name represented as a series of labels, and terminated by a label with zero length. - - - - - The number of bytes a root ('.') domain name takes. - - - - - Creates a domain name out of a string. - - - - - Returns a string representation of the domain name. - - - - - Two domain names are equal if their labels are equal ignoring any casing. - - - - - Two domain names are equal if their labels are equal ignoring any casing. - - - - - Returns the hash code of the domain name. - - - - - The root ('.') domain name. - - - - - The number of labels the domain name has. - For example, root ('.') has 0 labels. - - - - - Returns true iff the domain name is the root ('.') domain name. - - - - - The number of bytes the domain name takes assuming it won't be compressed. - - - - - Window Scale Option (RFC 1323) - The three-byte Window Scale option may be sent in a SYN segment by a TCP. - It has two purposes: (1) indicate that the TCP is prepared to do both send and receive window scaling, - and (2) communicate a scale factor to be applied to its receive window. - Thus, a TCP that is prepared to scale windows should send the option, even if its own scale factor is 1. - The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. - - 
-            +-----+-----------+
-            | Bit | 0-7       |
-            +-----+-----------+
-            | 0   | Kind      |
-            +-----+-----------+
-            | 8   | Length    |
-            +-----+-----------+
-            | 16  | shift.cnt |
-            +-----+-----------+
-
- - - This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. - If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift.cnt' bits - for transmission in SEG.WND. - The value 'shift.cnt' may be zero (offering to scale, while applying a scale factor of 1 to the receive window). - - - - This option may be sent in an initial SYN segment (i.e., a segment with the SYN bit on and the ACK bit off). - It may also be sent in a SYN,ACK segment, but only if a Window Scale option was received in the initial SYN segment. - A Window Scale option in a segment without a SYN bit should be ignored. - - - - The Window field in a SYN (i.e., a SYN or SYN,ACK) segment itself is never scaled. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Create a scale factor option using the given scale factor log. - - - - - The default scale factor log is 0 (scale factor is 1). - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The log of the window scale factor. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - Extension methods for byte[]. - - - - - Compares all the bytes in the two ranges of the arrays. - Returns the first non-zero compare value of the bytes in the ranges or zero if the ranges have the same byte values. - - The first array to compare. - The offset of the first byte to compare in the first array. - The second array to compare. - The offset of the first byte to compare in the second array. - The number of bytes to compare. - The first non-zero compare value of the bytes in the ranges or zero if the ranges have the same byte values. - - - - Compares all the bytes in the two ranges of the arrays. - Returns true iff the ranges have the same byte values. - - The first array to compare. - The offset of the first byte to compare in the first array. - The second array to compare. - The offset of the first byte to compare in the second array. - The number of bytes to compare. - True iff the ranges have the same byte values. - - - - Creates a DataSegment of the given byte array starting from a given offset in the segment taking a given number of bytes. - - The array to build the data segment on. - The offset in the array to start taking. - The number of bytes to take from the array. - A new DataSegment that is part of the given array. - - - - Returns the first offset in the array where the other array's range sequence of bytes can be found or the length of the array if no match exists. - - The array to search for the sequence of bytes. - The offset of the first byte in the array that should be compared to the sequence to find. - The number of bytes in the array that the sequence can be searched in. - The array that contains the sequence of bytes to search. - The offset in the array containing the sequence of the first byte of the sequence. - The number of bytes of the sequence. - The first offset in the array where the other array's range sequence of bytes can be found or the length of the array if no match exists. - - - - Returns the first offset in the array where the other array sequence of bytes can be found or the length of the array if no match exists. - - The array to search for the sequence of bytes. - The offset of the first byte in the array that should be compared to the sequence to find. - The number of bytes in the array that the sequence can be searched in. - The array that contains the sequence of bytes to search. - The first offset in the array where the other array sequence of bytes can be found or the length of the array if no match exists. - - - - Copies a specified number of bytes from a source array starting at a particular offset to a destination array starting at a particular offset. - - The source buffer. - The byte offset into source. - The destination buffer. - The byte offset into destination. - The number of bytes to copy. - - - - Reads a byte from a specific offset. - - The buffer to read the byte from. - The offset in the buffer to start reading. - The value read from the buffer. - - - - Reads a byte from a specific offset and increments the offset by 1. - - The buffer to read the byte from. - The offset in the buffer to start reading and to increment. - The value read from the buffer. - - - - Reads bytes from a specific offset. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The number of bytes to read. - The value read from the buffer. - - - - Reads bytes from a specific offset and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading and to increment. - The number of bytes to read. - The value read from the buffer. - - - - Reads 2 bytes from a specific offset as a short with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 2 bytes from a specific offset as a ushort with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 2 bytes from a specific offset as a ushort with a given endianity and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 3 bytes from a specific offset as a UInt24 with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 3 bytes from a specific offset as a UInt24 with a given endianity and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset as an int with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset as a uint with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset as a uint with a given endianity and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 6 bytes from a specific offset as a UInt48 with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 6 bytes from a specific offset as a UInt48 with a given endianity and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 8 bytes from a specific offset as a long with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 8 bytes from a specific offset as a ulong with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 16 bytes from a specific offset as a UInt128 with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads a given amount of bytes from a specific offset as an unsigned BigInteger with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The number of bytes to read. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 6 bytes from a specific offset as a MacAddress with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 6 bytes from a specific offset as a MacAddress with a given endianity and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset as an IPv4 address with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset as an IPv4 address with a given endianity and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset as an IPv4 time of day with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 4 bytes from a specific offset as an IPv4 time of day with a given endianity and increments the offset by the number of bytes read. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Reads 16 bytes from a specific offset as an IPv6 address with a given endianity. - - The buffer to read the bytes from. - The offset in the buffer to start reading. - The endianity to use to translate the bytes to the value. - The value converted from the read bytes according to the endianity. - - - - Writes the given value to the buffer. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - - - - Writes the given value to the buffer and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - - - - Writes the given value to the buffer and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given amount of least significant bytes of the value to the buffer using the given endianity. - Doesn't write leading zero bytes. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The maximum amount of bytes to write. - The endianity to use when converting the value to bytes. - - - - Writes a string to a byte array in a specific offset using the given encoding. - Increments the offset by the number of bytes written. - - The buffer to write the string in. - The offset in the buffer to start writing the string in. Incremented by the number of bytes written. - The string to write in the buffer. - The encoding to use to translate the string into a sequence of bytes. - - - - Writes the given value to the buffer. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - - - - Writes the given value to the buffer and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the given value to the buffer using the given endianity and increments the offset by the number of bytes written. - - The buffer to write the value to. - The offset in the buffer to start writing. - The value to write. - The endianity to use when converting the value to bytes. - - - - Writes the endline bytes (CRLF) in the buffer in the given offset. - Increments the offset by the number of bytes written (2). - - The buffer to write the CRLF in. - The offset to start writing the CRLF in. Incremented by the number of bytes written (2). - - - - Writes an integer as a decimal string in ASCII encoding to a buffer of bytes in a specific offset. - The offset is incremented by the number of bytes (digits) written. - - The buffer to write the integer in. - The offset in the buffer to start writing the integer. Incremented by the number of bytes (digits) written. - The integer value to write in the buffer. - - - - This field specifies the (U.S.) classification level at which the datagram must be protected. - The information in the datagram must be protected at this level. - The bit string values in this table were chosen to achieve a minimum Hamming distance of four (4) between any two valid values. - This specific assignment of classification level names to values has been defined for compatibility - with security devices which have already been developed and deployed. - - - - - An invalid value for a classification level. - - - - - Top Secret - - - - - Secret - - - - - Confidential - - - - - Unclassified - - - - - Loose Source and Record Route - 
-            +--------+--------+--------+---------//--------+
-            |10000011| length | pointer|     route data    |
-            +--------+--------+--------+---------//--------+
-             Type=131
-
- - - The loose source and record route (LSRR) option provides a means for the source of an internet datagram - to supply routing information to be used by the gateways in forwarding the datagram to the destination, - and to record the route information. - - - - The option begins with the option type code. - The second octet is the option length which includes the option type code and the length octet, - the pointer octet, and length-3 octets of route data. - The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. - The pointer is relative to this option, and the smallest legal value for the pointer is 4. - - - - A route data is composed of a series of internet addresses. - Each internet address is 32 bits or 4 octets. - If the pointer is greater than the length, the source route is empty (and the recorded route full) - and the routing is to be based on the destination address field. - If the address in destination address field has been reached and the pointer is not greater than the length, - the next address in the source route replaces the address in the destination address field, - and the recorded route address replaces the source address just used, and pointer is increased by four. - - - - The recorded route address is the internet module's own internet address - as known in the environment into which this datagram is being forwarded. - - - - This procedure of replacing the source route with the recorded route - (though it is in the reverse of the order it must be in to be used as a source route) means the option (and the IP header as a whole) - remains a constant length as the datagram progresses through the internet. - - - - This option is a loose source route because the gateway or host IP - is allowed to use any route of any number of other intermediate gateways to reach the next address in the route. - - - - Must be copied on fragmentation. - Appears at most once in a datagram. - - - - - - The base class for route tracking options (loose, strict, record). - - - - - The minimum option length in bytes (type, length, pointer). - - - - - The minimum option value length in bytes (pointer). - - - - - The maximum value for the index pointed the route. - - - - - Two routes options are equal iff they have the same type, same pointed address index and same route. - - - - - Two routes options are equal iff they have the same type, same pointed address index and same route. - - - - - Tries to read the value of the route option from the given buffer. - - The route read from the buffer. - The index pointed in the route read from the buffer. - The buffer to read the value from. - The offset in the buffer to start reading the value from. - The number of bytes that the value should be. - True iff the read was successful. - - - - Construct a route option from the given values. - - - - - The pointed index in the route. - - - - - The route tracked - the collection of addresses written. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - Constructs the option from the given values. - - The route addresses values. - The pointed index in the route. - - - - Empty loose source routing. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - Contains common QuickStart option parameters. - - - - - The maximum value for the rate field. - - - - - The maximum value for the nonce field. - - - - - RFC 6553. - Routing Protocol for Low-Power and Lossy Networks option. - 
-            +-----+---+---+---+-----+---------------+
-            | Bit | 0 | 1 | 2 | 3-7 | 8-15          |
-            +-----+---+---+---+-----+---------------+
-            | 0   | Option Type     | Opt Data Len  |
-            +-----+---+---+---+-----+---------------+
-            | 16  | O | R | F | 0   | RPLInstanceID |
-            +-----+---+---+---+-----+---------------+
-            | 32  | SenderRank                      |
-            +-----+---------------------------------+
-            | 48  | (sub-TLVs)                      |
-            | ... |                                 |
-            +-----+---------------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from down, rank error, forwarding error, RPL instance id, sender rank and sub TLVs. - - - Indicating whether the packet is expected to progress Up or Down. - A router sets the Down flag when the packet is expected to progress Down (using DAO routes), - and clears it when forwarding toward the DODAG root (to a node with a lower Rank). - A host or RPL leaf node must set the Down flag to 0. - - - Indicating whether a Rank error was detected. - A Rank error is detected when there is a mismatch in the relative Ranks and the direction as indicated in the Down flag. - A host or RPL leaf node must set the Rank Error flag to 0. - - - Indicating that this node cannot forward the packet further towards the destination. - The Forward Error flag might be set by a child node that does not have a route to destination for a packet with the Down flag set. - A host or RPL leaf node must set the Forwarding error flag to 0. - - Indicating the DODAG instance along which the packet is sent. - Set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network. - - A RPL device must skip over any unrecognized sub-TLVs and attempt to process any additional sub-TLVs that may appear after. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - Indicating whether the packet is expected to progress Up or Down. - A router sets the Down flag when the packet is expected to progress Down (using DAO routes), - and clears it when forwarding toward the DODAG root (to a node with a lower Rank). - A host or RPL leaf node must set the Down flag to 0. - - - - - Indicating whether a Rank error was detected. - A Rank error is detected when there is a mismatch in the relative Ranks and the direction as indicated in the Down flag. - A host or RPL leaf node must set the Rank Error flag to 0. - - - - - Indicating that this node cannot forward the packet further towards the destination. - The Forward Error flag might be set by a child node that does not have a route to destination for a packet with the Down flag set. - A host or RPL leaf node must set the Forwarding error flag to 0. - - - - - Indicating the DODAG instance along which the packet is sent. - - - - - Set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network. - - - - - A RPL device must skip over any unrecognized sub-TLVs and attempt to process any additional sub-TLVs that may appear after. - - - - - RFC 4866. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Signature                  |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - Creates an option from the given signature. - - Contains the mobile or correspondent node's signature, generated with the mobile or correspondent node's private key. - - - - Contains the mobile or correspondent node's signature, generated with the mobile or correspondent node's private key. - - - - - RFC 3963. - 
-            +-----+--------------+---------------+
-            | Bit | 0-7          | 8-15          |
-            +-----+--------------+---------------+
-            | 0   | Option Type  | Opt Data Len  |
-            +-----+--------------+---------------+
-            | 16  | Reserved     | Prefix Length |
-            +-----+--------------+---------------+
-            | 32  | Mobile Network Prefix        |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            +-----+------------------------------+
-
- - - - - RFC 3963, 5213. - 
-            +-----+--------------+---------------+
-            | Bit | 0-7          | 8-15          |
-            +-----+--------------+---------------+
-            | 0   | Option Type  | Opt Data Len  |
-            +-----+--------------+---------------+
-            | 16  | Reserved     | Prefix Length |
-            +-----+--------------+---------------+
-            | 32  | Network Prefix               |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            +-----+------------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Indicates the prefix length of the IPv6 prefix contained in the option. - - - - - Contains the Network Prefix. - - - - - Create an instance from prefix length and mobile network prefix. - - Indicates the prefix length of the IPv6 prefix contained in the option. - Contains the Mobile Network Prefix. - - - - RFC 6463. - 
-            +-----+-------------+--------------+----------+
-            | Bit | 0-7         | 8-15         | 16-31    |
-            +-----+-------------+--------------+----------+
-            | 0   | Option Type | Opt Data Len | Priority |
-            +-----+-------------+--------------+----------+
-            | 32  | Sessions in Use                       |
-            +-----+---------------------------------------+
-            | 64  | Maximum Sessions                      |
-            +-----+---------------------------------------+
-            | 96  | Used Capacity                         |
-            +-----+---------------------------------------+
-            | 128 | Maximum Capacity                      |
-            +-----+---------------------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from priority, sessions in use, maximum sessions, used capacity and maximum capacity. - - - Represents the priority of an LMA. - The lower value, the higher the priority. - The priority only has meaning among a group of LMAs under the same administration, for example, determined by a common LMA FQDN, a domain name, - or a realm. - - Represents the number of parallel mobility sessions the LMA has in use. - Represents the maximum number of parallel mobility sessions the LMA is willing to accept. - Represents the used bandwidth/throughput capacity of the LMA in kilobytes per second. - Represents the maximum bandwidth/throughput capacity in kilobytes per second the LMA is willing to accept. - - - - Represents the priority of an LMA. - The lower value, the higher the priority. - The priority only has meaning among a group of LMAs under the same administration, for example, determined by a common LMA FQDN, a domain name, - or a realm. - - - - - Represents the number of parallel mobility sessions the LMA has in use. - - - - - Represents the maximum number of parallel mobility sessions the LMA is willing to accept. - - - - - Represents the used bandwidth/throughput capacity of the LMA in kilobytes per second. - - - - - Represents the maximum bandwidth/throughput capacity in kilobytes per second the LMA is willing to accept. - - - - - An IPv6 Mobility option with an empty data. - - - - - The number of bytes this option data takes. - - - - - RFC 6275. - 
-            +-----+--------------+--------------+
-            | Bit | 0-7          | 8-15         |
-            +-----+--------------+--------------+
-            | 0   | Option Type  | Opt Data Len |
-            +-----+--------------+--------------+
-            | 16  | Authenticator               |
-            | ... |                             |
-            +-----+-----------------------------+
-
- - - - - Creates an option from the given authenticator. - - - Contains a cryptographic value that can be used to determine that the message in question comes from the right authority. - Rules for calculating this value depends on the used authorization procedure. - - - - - - Contains a cryptographic value that can be used to determine that the message in question comes from the right authority. - Rules for calculating this value depends on the used authorization procedure. - - - For the return routability procedure, this option can appear in the Binding Update and Binding Acknowledgements. - Rules for calculating the Authenticator value are the following: - - - Mobility Data = care-of address | correspondent | MH Data - Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) - - - Where | denotes concatenation. - "Care-of address" is the care-of address that will be registered for the mobile node if the Binding Update succeeds, - or the home address of the mobile node if this option is used in de-registration. - Note also that this address might be different from the source address of the Binding Update message, - if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero. - - - The "correspondent" is the IPv6 address of the correspondent node. - Note that, if the message is sent to a destination that is itself mobile, the "correspondent" address may not be the address found in the - Destination Address field of the IPv6 header; instead, the home address from the type 2 Routing header should be used. - - - "MH Data" is the content of the Mobility Header, excluding the Authenticator field itself. - The Authenticator value is calculated as if the Checksum field in the Mobility Header was zero. - The Checksum in the transmitted packet is still calculated in the usual manner, - with the calculated Authenticator being a part of the packet protected by the Checksum. - Kbm is the binding management key, which is typically created using nonces provided by the correspondent node. - Note that while the contents of a potential Home Address destination option are not covered in this formula, - the rules for the calculation of the Kbm do take the home address in account. - This ensures that the MAC will be different for different home addresses. - - - The first 96 bits from the MAC result are used as the Authenticator field. - - - - - - RFC 6089. - - - - - RFC 6089. - 
-            +-----+--------------+
-            | Bit | 0-7          |
-            +-----+--------------+
-            | 0   | Sub-Opt Type |
-            +-----+--------------+
-
- - - - - RFC 6089. - - - - - True iff the two options are equal. - - - - - True iff the two options are equal. - - - - - Returns a hash code of the option. - - - - - The type of the option. - - - - - The number of bytes this option takes. - - - - - The number of bytes this option takes. - - - - - The number of bytes this option take. - - - - - Constructs the option. - - - - - RFC 6757. - - - - - RFC 6757. - 
-            +-----+-------------------+
-            | Bit | 0-7               |
-            +-----+-------------------+
-            | 0   | ANI Type          |
-            +-----+-------------------+
-            | 8   | ANI Length        |
-            +-----+-------------------+
-            | 16  | Latitude Degrees  | 
-            |     |                   | 
-            |     |                   | 
-            +-----+-------------------+
-            | 40  | Longitude Degrees |
-            |     |                   | 
-            |     |                   | 
-            +-----+-------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from latitude and longitude degrees using integer numbers encoded as a two's complement, fixed point number with 9 whole bits. - See for using real numbers for the degrees. - - - A 24-bit latitude degree value encoded as a two's complement, fixed point number with 9 whole bits. - Positive degrees correspond to the Northern Hemisphere and negative degrees correspond to the Southern Hemisphere. - The value ranges from -90 to +90 degrees. - - - A 24-bit longitude degree value encoded as a two's complement, fixed point number with 9 whole bits. - The value ranges from -180 to +180 degrees. - - - - - Creates an instance from latitude and longitude degrees using real numbers. - - - Positive degrees correspond to the Northern Hemisphere and negative degrees correspond to the Southern Hemisphere. - The value ranges from -90 to +90 degrees. - - - The value ranges from -180 to +180 degrees. - - An instance created from the given real degrees values. - - - - A 24-bit latitude degree value encoded as a two's complement, fixed point number with 9 whole bits. - Positive degrees correspond to the Northern Hemisphere and negative degrees correspond to the Southern Hemisphere. - The value ranges from -90 to +90 degrees. - - - - - Positive degrees correspond to the Northern Hemisphere and negative degrees correspond to the Southern Hemisphere. - The value ranges from -90 to +90 degrees. - - - - - A 24-bit longitude degree value encoded as a two's complement, fixed point number with 9 whole bits. - The value ranges from -180 to +180 degrees. - - - - - The value ranges from -180 to +180 degrees. - - - - - RFC 1112. - - - - - RFC 1112. - Represents an IGMP version 1 layer. - - - - - - The actual time allowed, called the Max Resp Time. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - RFC 2236. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - The IGMP version of a Membership Query message. - If the type is not a query, None will be returned. - - - - - RFC 2236. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - Represents a datalink. - - - - - The kind of the datalink. - - - - - RFC 792. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-            | 64  | Originate Timestamp           |
-            +-----+-------------------------------+
-            | 96  | Receive Timestamp             |
-            +-----+-------------------------------+
-            | 128 | Transmit Timestamp            |
-            +-----+-------------------------------+
-
- - - - - The number of bytes this datagram should take. - - - - - The number of bytes this ICMP payload should take. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if the datagram's length is OK, the checksum is correct and the code is in the expected range. - - - - - The time the sender last touched the message before sending it. - - - - - The time the echoer first touched it on receipt. - - - - - The time the echoer last touched the message on sending it. - - - - - RFC 792. - 
-            +-----+------+------+-----------+
-            | Bit | 0-7  | 8-15 | 16-31     |
-            +-----+------+------+-----------+
-            | 0   | Type | Code | Checksum  |
-            +-----+------+------+-----------+
-            | 32  | unused                  |
-            +-----+-------------------------+
-            | 64  | Internet Header         |
-            |     | + 64 bits of            |
-            |     | Original Data Datagram  |
-            +-----+-------------------------+
-
- - - - - 
-            +-----+------+------+-----------+
-            | Bit | 0-7  | 8-15 | 16-31     |
-            +-----+------+------+-----------+
-            | 0   | Type | Code | Checksum  |
-            +-----+------+------+-----------+
-            | 32  | unused                  |
-            +-----+-------------------------+
-            | 64  | IpV4 datagram           |
-            +-----+-------------------------+
-
- - - - - ICMP with IPv4 payload is valid if the datagram's length is OK, the checksum is correct, the code is in the expected range, - and the IPv4 payload contains at least an IPv4 header. - - - - - The ICMP payload as an IPv4 datagram. - - - - - The number of bytes this payload includes from the original data datagram. - - - - - ICMP with IPv4 payload and 64 bits IPv4 payload is valid if the datagram's length is OK, the checksum is correct, the code is in the expected range, - the IPv4 payload contains at least an IPv4 header and the IPv4's payload is in the expected size. - - - - - RFC 792. - - - - - If, according to the information in the gateway's routing tables, - the network specified in the internet destination field of a datagram is unreachable, - e.g., the distance to the network is infinity, - the gateway may send a destination unreachable message to the internet source host of the datagram. - - - - - RFC 792. - In some networks, the gateway may be able to determine if the internet destination host is unreachable. - Gateways in these networks may send destination unreachable messages to the source host when the destination host is unreachable. - - - - - RFC 792. - If, in the destination host, the IP module cannot deliver the datagram because the indicated protocol module is not active, - the destination host may send a destination unreachable message to the source host. - - - - - RFC 792. - If, in the destination host, the IP module cannot deliver the datagram because the indicated process port is not active, - the destination host may send a destination unreachable message to the source host. - - - - - RFC 792. - A datagram must be fragmented to be forwarded by a gateway yet the Don't Fragment flag is on. - In this case the gateway must discard the datagram and may return a destination unreachable message. - - - - - RFC 792. - - - - - RFC 1393. - Represents an ICMP Trace Route message layer. - - - - - - Writes the ICMP payload to the buffer. - Doesn't include payload in the next layers. - - The buffer to write the ICMP payload to. - The offset in the buffer to start writing the payload at. - - - - True iff the OutboundHopCount, ReturnHopCount, OutputLinkSpeed and OutputLinkMaximumTransmissionUnit fields are equal to the other layer fields. - - - - - True iff the OutboundHopCount, ReturnHopCount, OutputLinkSpeed and OutputLinkMaximumTransmissionUnit fields are equal to the other layer fields. - - - - - A sub-type of the message. Specific method of this message type. - - - - - The ID Number as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. - This is NOT related to the ID number in the IP header. - - - - - The Outbound Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. - - - - - The Return Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. - - - - - The speed, in OCTETS per second, of the link over which the Outbound/Return Packet will be sent. - Since it will not be long before network speeds exceed 4.3Gb/s, and since some machines deal poorly with fields longer than 32 bits, octets per second was chosen over bits per second. - If this value cannot be determined, the field should be set to zero. - - - - - The MTU, in bytes, of the link over which the Outbound/Return Packet will be sent. - MTU refers to the data portion (includes IP header; excludes datalink header/trailer) of the packet. - If this value cannot be determined, the field should be set to zero. - - - - - The value of this field determines the format of the remaining data. - - - - - The number of bytes the ICMP payload takes. - - - - - A sub-type of the message. Specific method of this message type. - - - - - A value that should be interpreted according to the specific message. - - - - - RFC 2616. - Represents an HTTP response layer. - - - - - Two HTTP response layers are equal iff they have the same version, header, body, status code and reason phrase. - - - - - Two HTTP response layers are equal iff they have the same version, header, body, status code and reason phrase. - - - - - false since this is a response. - - - - - The status code of the response. - null if no status code exists. - - - - - The data of the reason phrase. - Example: OK - - - - - RFC 2616. - Represents an HTTP request. - - - - - RFC 2616 - - Message: - 
-             HTTP-message     = Request | Response
-             
-             generic-message  = start-line
-                                *(message-header CRLF)
-                                CRLF
-                                [ message-body ]
-             
-             start-line       = Request-Line | Status-Line
-             
-             message-header   = field-name ":" [ field-value ]
-             field-name       = token
-             field-value      = *( field-content | LWS )
-             field-content    = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string>
-             
-             message-body     = entity-body
-                              | <entity-body encoded as per Transfer-Encoding>
-             general-header   = Cache-Control          
-                              | Connection             
-                              | Date                   
-                              | Pragma                 
-                              | Trailer                
-                              | Transfer-Encoding      
-                              | Upgrade                
-                              | Via                    
-                              | Warning                
-
- - Request: - 
-             Request          = Request-Line             
-                                *(( general-header       
-                                 | request-header        
-                                 | entity-header ) CRLF) 
-                                CRLF
-                                [ message-body ]         
-             
-             Request-Line     = Method SP Request-URI SP HTTP-Version CRLF
-             
-             Method           = "OPTIONS"              
-                              | "GET"                  
-                              | "HEAD"                 
-                              | "POST"                 
-                              | "PUT"                  
-                              | "DELETE"               
-                              | "TRACE"                
-                              | "CONNECT"              
-                              | extension-method
-             
-             extension-method = token
-             
-             Request-URI      = "*" | absoluteURI | abs_path | authority
-             absoluteURI      = scheme ":" ( hier_part | opaque_part )
-             scheme           = alpha *( alpha | digit | "+" | "-" | "." )
-             hier_part        = ( net_path | abs_path ) [ "?" query ]
-             opaque_part      = uric_no_slash *uric
-             net_path         = "//" authority [ abs_path ]
-             abs_path         = "/"  path_segments
-             query            = *uric
-             uric_no_slash    = unreserved | escaped | ";" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
-             uric             = reserved | unreserved | escaped
-             authority        = server | reg_name
-             path_segments    = segment *( "/" segment )
-             unreserved       = alphanum | mark
-             escaped          = "%" hex hex
-             reserved         = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
-             server           = [ [ userinfo "@" ] hostport ]
-             reg_name         = 1*( unreserved | escaped | "$" | "," | ";" | ":" | "@" | "&" | "=" | "+" )
-             segment          = *pchar *( ";" param )
-             mark             = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
-             userinfo         = *( unreserved | escaped | ";" | ":" | "&" | "=" | "+" | "$" | "," )
-             hostport         = host [ ":" port ]
-             pchar            = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | ","
-             param            = *pchar
-             host             = hostname | IPv4address
-             port             = *digit
-             hostname         = *( domainlabel "." ) toplabel [ "." ]
-             IPv4address      = 1*digit "." 1*digit "." 1*digit "." 1*digit
-             domainlabel      = alphanum | alphanum *( alphanum | "-" ) alphanum
-             toplabel         = alpha | alpha *( alphanum | "-" ) alphanum
-             alphanum         = alpha | digit
-             alpha            = lowalpha | upalpha
-             lowalpha         = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" |
-                                "w" | "x" | "y" | "z"
-             upalpha          = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" |
-                                "W" | "X" | "Y" | "Z"
-             digit            = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
-             
-             request-header   = Accept                  
-                              | Accept-Charset          
-                              | Accept-Encoding         
-                              | Accept-Language         
-                              | Authorization           
-                              | Expect                  
-                              | From                    
-                              | Host                    
-                              | If-Match                
-                              | If-Modified-Since       
-                              | If-None-Match           
-                              | If-Range                
-                              | If-Unmodified-Since     
-                              | Max-Forwards            
-                              | Proxy-Authorization     
-                              | Range                   
-                              | Referer                 
-                              | TE                      
-                              | User-Agent              
-
- - Response: - 
-             Response         = Status-Line             
-                                *(( general-header      
-                                 | response-header      
-                                 | entity-header ) CRLF)
-                                CRLF
-                                [ message-body ]        
-             
-             Status-Line      = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
-             
-             Status-Code      = "100"  
-                              | "101"  
-                              | "200"  
-                              | "201"  
-                              | "202"  
-                              | "203"  
-                              | "204"  
-                              | "205"  
-                              | "206"  
-                              | "300"  
-                              | "301"  
-                              | "302"  
-                              | "303"  
-                              | "304"  
-                              | "305"  
-                              | "307"  
-                              | "400"  
-                              | "401"  
-                              | "402"  
-                              | "403"  
-                              | "404"  
-                              | "405"  
-                              | "406"  
-                              | "407"  
-                              | "408"  
-                              | "409"  
-                              | "410"  
-                              | "411"  
-                              | "412"  
-                              | "413"  
-                              | "414"  
-                              | "415"  
-                              | "416"  
-                              | "417"  
-                              | "500"  
-                              | "501"  
-                              | "502"  
-                              | "503"  
-                              | "504"  
-                              | "505"  
-                              | extension-code
-             
-             extension-code   = 3DIGIT
-             Reason-Phrase    = *<TEXT, excluding CR, LF>
-             
-             response-header  = Accept-Ranges       
-                              | Age                 
-                              | ETag                
-                              | Location            
-                              | Proxy-Authenticate  
-                              | Retry-After         
-                              | Server              
-                              | Vary                
-                              | WWW-Authenticate    
-            
-             entity-header    = Allow               
-                              | Content-Encoding    
-                              | Content-Language    
-                              | Content-Length      
-                              | Content-Location    
-                              | Content-MD5         
-                              | Content-Range       
-                              | Content-Type        
-                              | Expires             
-                              | Last-Modified       
-                              | extension-header
-            
-             extension-header = message-header
-             
-             entity-body      = *OCTET
-             
-             entity-body     := Content-Encoding( Content-Type( data ) )
-
- - - - - True iff the message is a request and iff the message is not a response. - - - - - True iff the message is a response and iff the message is not a request. - - - - - The version of this HTTP message. - - - - - The header of the HTTP message. - - - - - Message Body. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - True since the message is a request. - - - - - The HTTP Request Method. - - - - - The HTTP Request URI. - - - - - The Ethernet payload as an IPv4 datagram. - - - - - The Ethernet payload as an IPv6 datagram. - - - - - The Ethernet payload as an ARP datagram. - - - - - The Ethernet payload. - - - - - RFC 5155. - - - - - Undefined value. - - - - - RFC 5155. - - - - - RFC 2930. - 
-            +------+------------+------------+
-            | bit  | 0-15       | 16-31      |
-            +------+------------+------------+
-            | 0    | Algorithm               |
-            | ...  |                         |
-            +------+-------------------------+
-            | X    | Inception               |
-            +------+-------------------------+
-            | X+32 | Expiration              |
-            +------+------------+------------+
-            | X+64 | Mode       | Error      |
-            +------+------------+------------+
-            | X+96 | Key Size   |            |
-            +------+------------+ Key Data   |
-            | ...  |                         |
-            +------+------------+------------+
-            |      | Other Size |            |
-            +------+------------+ Other Data |
-            | ...  |                         |
-            +------+-------------------------+
-
- - - - - Constructs an instance out of the algorithm, inception, expiration, mode, error, key and other fields. - - - Name of the algorithm in domain name syntax. - The algorithm determines how the secret keying material agreed to using the TKEY RR is actually used to derive the algorithm specific key. - - - Number of seconds since the beginning of 1 January 1970 GMT ignoring leap seconds treated as modulo 2**32 using ring arithmetic. - In messages between a DNS resolver and a DNS server where this field is meaningful, - it is either the requested validity interval start for the keying material asked for or - specify the validity interval start of keying material provided. - - To avoid different interpretations of the inception time in TKEY RRs, - resolvers and servers exchanging them must have the same idea of what time it is. - One way of doing this is with the NTP protocol [RFC 2030] but that or any other time synchronization used for this purpose must be done securely. - - - Number of seconds since the beginning of 1 January 1970 GMT ignoring leap seconds treated as modulo 2**32 using ring arithmetic. - In messages between a DNS resolver and a DNS server where this field is meaningful, - it is either the requested validity interval end for the keying material asked for or - specify the validity interval end of keying material provided. - - To avoid different interpretations of the expiration time in TKEY RRs, - resolvers and servers exchanging them must have the same idea of what time it is. - One way of doing this is with the NTP protocol [RFC 2030] but that or any other time synchronization used for this purpose must be done securely. - - - Specifies the general scheme for key agreement or the purpose of the TKEY DNS message. - Servers and resolvers supporting this specification must implement the Diffie-Hellman key agreement mode and the key deletion mode for queries. - All other modes are optional. - A server supporting TKEY that receives a TKEY request with a mode it does not support returns the BADMODE error. - - - When the TKEY Error Field is non-zero in a response to a TKEY query, the DNS header RCODE field indicates no error. - However, it is possible if a TKEY is spontaneously included in a response the TKEY RR and DNS header error field - could have unrelated non-zero error codes. - - The key exchange data. The meaning of this data depends on the mode. - May be used in future extensions. - - - - Two DnsResourceDataTransactionKey are equal iff their algorithm, inception, expiration, mode, error, key and other fields are equal. - - - - - Two DnsResourceDataTransactionKey are equal iff their algorithm, inception, expiration, mode, error, key and other fields are equal. - - - - - A hash code of the combination of the algorithm, inception, expiration, mode, error, key and other fields. - - - - - Name of the algorithm in domain name syntax. - The algorithm determines how the secret keying material agreed to using the TKEY RR is actually used to derive the algorithm specific key. - - - - - Number of seconds since the beginning of 1 January 1970 GMT ignoring leap seconds treated as modulo 2**32 using ring arithmetic. - In messages between a DNS resolver and a DNS server where this field is meaningful, - it is either the requested validity interval start for the keying material asked for or - specify the validity interval start of keying material provided. - - To avoid different interpretations of the inception time in TKEY RRs, - resolvers and servers exchanging them must have the same idea of what time it is. - One way of doing this is with the NTP protocol [RFC 2030] but that or any other time synchronization used for this purpose must be done securely. - - - - - Number of seconds since the beginning of 1 January 1970 GMT ignoring leap seconds treated as modulo 2**32 using ring arithmetic. - In messages between a DNS resolver and a DNS server where this field is meaningful, - it is either the requested validity interval end for the keying material asked for or - specify the validity interval end of keying material provided. - - To avoid different interpretations of the expiration time in TKEY RRs, - resolvers and servers exchanging them must have the same idea of what time it is. - One way of doing this is with the NTP protocol [RFC 2030] but that or any other time synchronization used for this purpose must be done securely. - - - - - Specifies the general scheme for key agreement or the purpose of the TKEY DNS message. - Servers and resolvers supporting this specification must implement the Diffie-Hellman key agreement mode and the key deletion mode for queries. - All other modes are optional. - A server supporting TKEY that receives a TKEY request with a mode it does not support returns the BADMODE error. - - - - - When the TKEY Error Field is non-zero in a response to a TKEY query, the DNS header RCODE field indicates no error. - However, it is possible if a TKEY is spontaneously included in a response the TKEY RR and DNS header error field - could have unrelated non-zero error codes. - - - - - The key exchange data. - The meaning of this data depends on the mode. - - - - - May be used in future extensions. - - - - - RFC 1035. - 
-            +-----+------+
-            | bit | 0-31 |
-            +-----+------+
-            | 0   | IP   |
-            +-----+------+
-
- - - - - Constructs an IPv4 resource data from the given IP. - - - - - Two IPv4 resource datas are equal if their IP is equal. - - - - - Two IPv4 resource datas are equal if their IP is equal. - - - - - Returns the hash code of the IPv4 value. - - - - - The IPv4 value. - - - - - Indicates the format of the information that is stored in the gateway field. - - - - - No gateway is present. - - - - - A 4-byte IPv4 address is present. - - - - - A 16-byte IPv6 address is present. - - - - - A wire-encoded domain name is present. - The wire-encoded format is self-describing, so the length is implicit. - The domain name must not be compressed. - - - - - An option that can hold any data. - - - - - RFC 2671. - A single option. - - - - - The minimum number of bytes an option can take. - - - - - Two options are equal if they are of the same type, have the same code and have equal data. - - - - - Two options are equal if they are of the same type, have the same code and have equal data. - - - - - Returns a hash code based on the option code and data. - - - - - The option code. - - - - - The number of bytes the option takes. - - - - - The number of bytes the option data takes. - - - - - Constructs the option from a code and data. - - The option code. - The option data. - - - - The option data. - - - - - The number of bytes the option data takes. - - - - - The header length in bytes for the option (type and size). - - - - - The type of the timestamp ip option. - - - - - Time stamps only, stored in consecutive 32-bit words. - - - - - Each timestamp is preceded with internet address of the registering entity. - - - - - The internet address fields are prespecified. - An IP module only registers its timestamp if it matches its own address with the next specified internet address. - - - - - Represents a timestamp IPv4 option with only the timestamps. - - - - - Create the option by giving it all the data. - - The number of IP modules that cannot register timestamps due to lack of space. Maximum value is 15. - The index in the timestamp that points to the for next timestamp. - The timestamps as time passed since midnight UT. - - - - Create the option by giving it all the data. - - The number of IP modules that cannot register timestamps due to lack of space. Maximum value is 15. - The index in the timestamp that points to the for next timestamp. - The timestamps as time passed since midnight UT. - - - - Compares the values of the options. - - - - - Writes the value of the option to the buffer. - - - - - The number of timestamps this option holds (or can hold). - - - - - The timestamps as time passed since midnight UT. - - - - - The number of bytes the value of the option take. - - - - - RFC 6463. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance. - - - - - RFC 5844. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-            | 32  | IPv4 home address          |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from default router address. - - - The mobile node's default router address. - - - - - The mobile node's default router address. - - - - - RFC 5555. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-            | 32  | IPv4 Care-of address       |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from a care-of address. - - - Contains the mobile node's IPv4 care-of address. - The IPv4 care-of address is used when the mobile node is located in an IPv4-only network. - - - - - Contains the mobile node's IPv4 care-of address. - The IPv4 care-of address is used when the mobile node is located in an IPv4-only network. - - - - - RFC 5213. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved    | ATT          |
-            +-----+----------------------------+
-
- - - - - RFC 5213. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved    | Value        |
-            +-----+-------------+--------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an option according to the given access technology type. - - Specifies the access technology through which the mobile node is connected to the access link on the mobile access gateway. - - - - Specifies the access technology through which the mobile node is connected to the access link on the mobile access gateway. - - - - - RFC 5570. - CALIPSO Domain of Interpretation (DOI) - - - - - RFC 5570. - Must not appear in any IPv6 packet on any network. - - - - - RFC 6757. - - - - - Invalid value. - - - - - Network-Identifier sub-option. - - - - - Geo-Location sub-option. - - - - - Operator-Identifier sub-option. - - - - - RFC-ietf-netext-pmip-lr-10. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Sequence #                            |
-            +-----+---------------------------------------+
-            | 64  | Reserved                              |
-            +-----+---------------------------------------+
-            | 80  | Lifetime                              |
-            +-----+---------------------------------------+
-            | 96  | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Indicates an infinite lifetime. - - - - - The minimum number of bytes the message data takes. - - - - - In initiation, a monotonically increasing integer. Set by a sending node in a request message, and used to match a reply to the request. - In acknowledgement, copied from the sequence number field of the LRI message being responded to. - - - - - In initiation, the requested time in seconds for which the sender wishes to have local forwarding. - A value of 0xffff (all ones) indicates an infinite lifetime. - When set to 0, indicates a request to stop localized routing. - In acknowledgement, the time in seconds for which the local forwarding is supported. - Typically copied from the corresponding field in the LRI message. - - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Reserved                              |
-            +-----+---------------------------------------+
-            | 64  | Home Init Cookie                      |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            +-----+---------------------------------------+
-            | 128 | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, home init cookie and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Contains a random value, the home init cookie. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Contains a random value, the home init cookie. - - - - - RFC 792. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-            | 64  | Originate Timestamp           |
-            +-----+-------------------------------+
-            | 96  | Receive Timestamp             |
-            +-----+-------------------------------+
-            | 128 | Transmit Timestamp            |
-            +-----+-------------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - RFC 2521. - Represents an ICMP Security Failures layer. - - - - - - A sub-type of the message. Specific method of this message type. - - - - - An offset into the Original Internet Headers that locates the most significant octet of the offending SPI. - Will be zero when no SPI is present. - - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - A value that should be interpreted according to the specific message. - - - - - RFC 792. - - - - - The value of this field determines the format of the remaining data. - - - - - RFC 792 and RFC 1191. - - - - - - A sub-type of the message. Specific method of this message type. - - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - The size in octets of the largest datagram that could be forwarded, - along the path of the original datagram, without being fragmented at this router. - The size includes the IP header and IP data, and does not include any lower-level headers. - - - - - A value that should be interpreted according to the specific message. - - - - - The different ICMP code values for Time Exceeded ICMP type. - - - - - RFC 792. - If the gateway processing a datagram finds the time to live field is zero it must discard the datagram. - The gateway may also notify the source host via the time exceeded message. - - - - - RFC 792. - If a host reassembling a fragmented datagram cannot complete the reassembly due to missing fragments within its time limit it discards the datagram, - and it may send a time exceeded message. - If fragment zero is not available then no time exceeded need be sent at all. - - - - - RFC 950. - Represents an ICMP Trace Route message layer. - - - - - - Writes the ICMP payload to the buffer. - Doesn't include payload in the next layers. - - The buffer to write the ICMP payload to. - The offset in the buffer to start writing the payload at. - - - - True iff the address mask is equal to the other address mask. - - - - - True iff the address mask is equal to the other address mask. - - - - - A 32-bit mask. - - - - - The value of this field determines the format of the remaining data. - - - - - The number of bytes the ICMP payload takes. - - - - - Represents HTTP header. - The header is a container for HTTP fields. - Insensitive to the case of HTTP field names. - - - - - Creates a header from an enumerable of fields. - - - - - Creates a header from an array of fields. - - - - - Two HTTP headers are equal if they have the same fields with the same values. - - - - - Two HTTP headers are equal if they have the same fields with the same values. - - - - - Xor of the hash codes of the fields. - - - - - Returns a string of all the fields with endline separators. - - - - - Enumerates over the HTTP fields. - - - - - Writes the HTTP header to the given buffer in the given offset. - - The buffer to write the header to. - The offset in the given buffer to start writing the header. - - - - Writes the HTTP header to the given buffer in the given offset. - Increments the offset by the number of bytes written. - - The buffer to write the header to. - The offset in the given buffer to start writing the header. Incremented by the number of bytes written. - - - - An empty HTTP header. - - - - - The number of bytes the header takes. - - - - - Returns the field with the given field name or null if it doesn't exist. - Case insensitive. - - The case insensitive name of the field. - The field with the matching case insensitive name or null if it doesn't exist. - - - - The HTTP Transfer Encoding field if it exists (null otherwise). - - - - - The HTTP Content Length field if it exists (null otherwise). - - - - - The HTTP Content Type field if it exists (null otherwise). - - - - - The HTTP Trailer field if it exists (null otherwise). - - - - - Ethernet MacAddress struct. - - - - - The number of bytes the struct takes. - - - - - Constructs the address from a 48 bit integer. - - The 48 bit integer to create the address from. - - - - Create the address from a string in the format XX:XX:XX:XX:XX:XX. - - The string value in hexadecimal format. Every two digits are separated by a colon. - - - - Converts the address to a 48 bit integer. - - A 48 bit integer representing the address. - - - - Two addresses are equal if they have the exact same value. - - - - - Two addresses are equal if they have the exact same value. - - - - - Two addresses are equal if they have the exact same value. - - - - - Two addresses are different if they have different values. - - - - - The hash code of the address is the hash code of its 48 bit integer value. - - - - - Converts the address to a string in the format XX:XX:XX:XX:XX:XX. - - - - - A MAC Address of all zeros (00:00:00:00:00:00). - - - - - A base class for any resource data that contains a 16 bit unsigned integer followed by a domain name. - 
-            +-----+--------+
-            | bit | 0-15   |
-            +-----+--------+
-            | 0   | Value  |
-            +-----+--------+
-            | 16  | Domain |
-            | ... |        |
-            +-----+--------+
-
- - - - - Two DnsResourceDataUShortDomainName are equal iff their of the same type and their ushort values and domain names are equal. - - - - - Two DnsResourceDataUShortDomainName are equal iff their of the same type and their ushort values and domain names are equal. - - - - - A hash code based on the type, ushort value and domain name. - - - - - Contains a single DNS domain name. - 
-            +------+
-            | NAME |
-            +------+
-
- - - - - Constructs an instance from the domain name data. - - - - - Two DnsResourceDataDomainName are equal iff their domain name values are equal. - - - - - Two DnsResourceDataDomainName are equal iff their domain name values are equal. - - - - - The hash code of the domain name value. - - - - - The domain name value. - - - - - RFC 3658. - 
-            0 Or more of:
-            +-----+---------+-----------+-------------+
-            | bit | 0-15    | 16-23     | 24-31       |
-            +-----+---------+-----------+-------------+
-            | 0   | key tag | algorithm | Digest type |
-            +-----+---------+-----------+-------------+
-            | 32  | digest                            |
-            | ... |                                   |
-            +-----+-----------------------------------+
-
- - - - - Constructs an instance out of the key tag, algorithm, digest type and digest fields. - - - Lists the key tag of the DNSKEY RR referred to by the DS record. - The Key Tag used by the DS RR is identical to the Key Tag used by RRSIG RRs. - Calculated as specified in RFC 2535. - - Algorithm must be allowed to sign DNS data. - An identifier for the digest algorithm used. - - Calculated over the canonical name of the delegated domain name followed by the whole RDATA of the KEY record (all four fields). - digest = hash(canonical FQDN on KEY RR | KEY_RR_rdata) - KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key - The size of the digest may vary depending on the digest type. - - - - - Two DnsResourceDataDelegationSigner are equal iff their key tag, algorithm, digest type and digest fields are equal. - - - - - Two DnsResourceDataDelegationSigner are equal iff their key tag, algorithm, digest type and digest fields are equal. - - - - - A hash code of the combination of the key tag, algorithm, digest type and digest fields. - - - - - Lists the key tag of the DNSKEY RR referred to by the DS record. - The Key Tag used by the DS RR is identical to the Key Tag used by RRSIG RRs. - Calculated as specified in RFC 2535. - - - - - Algorithm must be allowed to sign DNS data. - - - - - An identifier for the digest algorithm used. - - - - - Calculated over the canonical name of the delegated domain name followed by the whole RDATA of the KEY record (all four fields). - digest = hash(canonical FQDN on KEY RR | KEY_RR_rdata) - KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key - The size of the digest may vary depending on the digest type. - - - - - The extra digest bytes after number of bytes according to the digest type. - - - - - RFC 1183. - - - - - An invalid value. - - - - - The host has an AFS version 3.0 Volume Location Server for the named AFS cell. - - - - - The host has an authenticated name server holding the cell-root directory node for the named DCE/NCA cell. - - - - - CC.ECHO Option (RFC 1644). - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | Connection    |
-            |     | Count         |
-            +-----+---------------+
-
- - - This option must be sent (in addition to a CC option) in a segment containing both a SYN and an ACK bit, - if the initial SYN segment contained a CC or CC.NEW option. - Its SEG.CC value is the SEG.CC value from the initial SYN. - - - - A CC.ECHO option should be sent only in a <SYN,ACK> segment and should be ignored if it is received in any other segment. - - - - - - The base class for connection count TCP options. - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates a connection count option according to the given option type and given connection count value. - - - - - Reads the connection count value from the buffer. - - The result connection count. - The buffer to read the connection count from. - The offset to start reading the connection byte from. - The number of bytes available for read in this buffer. - True iff the connection count could be read (there were enough bytes to read). - - - - The connection count value. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - Creates the option using the given connection count value. - - - - - The default connection count value is 0. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - RFC 6275. - Home Address Option. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Home Address               |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from home address. - - - The home address of the mobile node sending the packet. - This address must be a unicast routable address. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - The home address of the mobile node sending the packet. - This address must be a unicast routable address. - - - - - Charles Lynn. - http://ana-3.lcs.mit.edu/~jnc/nimrod/eidoption.txt - Endpoint Identifier Option. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Src Len     | Dst Len      |
-            +-----+-------------+--------------+
-            | 32  | Source EID                 |
-            | ... |                            |
-            +-----+----------------------------+
-            |     | Destination EID            |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from source endpoint identifier and destination endpoint identifier. - - - The endpoint identifier of the source. - Nimrod EIDs begin with the five bits 00100. - - - The endpoint identifier of the destination. - Nimrod EIDs begin with the five bits 00100. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - The endpoint identifier of the source. - Nimrod EIDs begin with the five bits 00100. - - - - - The endpoint identifier of the destination. - Nimrod EIDs begin with the five bits 00100. - - - - - RFC 5094. - 
-            +-----+--------------+
-            | Bit | 0-7          |
-            +-----+--------------+
-            | 0   | Option Type  |
-            +-----+--------------+
-            | 8   | Opt Data Len |
-            +-----+--------------+
-            | 16  | Vendor ID    |
-            |     |              |
-            |     |              |
-            |     |              |
-            +-----+--------------+
-            | 48  | Sub-Type     |
-            +-----+--------------+
-            | 56  | Data         |
-            | ... |              |
-            +-----+--------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from vendor id, subtype and data. - - - The SMI Network Management Private Enterprise Code of the IANA- maintained Private Enterprise Numbers registry. - See http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers - - - Indicating the type of vendor-specific information carried in the option. - The administration of the Sub-type is done by the Vendor. - - Vendor-specific data that is carried in this message. - - - - The SMI Network Management Private Enterprise Code of the IANA- maintained Private Enterprise Numbers registry. - See http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers - - - - - Indicating the type of vendor-specific information carried in the option. - The administration of the Sub-type is done by the Vendor. - - - - - Vendor-specific data that is carried in this message. - - - - - RFC 5949. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-            | 32  | Request 1                  |
-            | ... | Request 2                  |
-            |     | ...                        |
-            |     | Request n                  |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from an array of requests. - - The requests types and options. - - - - Creates an instance from a list of requests. - - The requests types and options. - - - - Creates an instance from a collection of requests. - - The requests types and options. - - - - The requests types and options. - - - - - RFC 4283. - - - - - Invalid value. - - - - - RFC 4283. - Uses an identifier of the form user@realm (RFC 4282). - - - - - RFCs 6088, 6089. - - - - - Invalid value. - - - - - IPv4 binary traffic selector. - - - - - IPv6 binary traffic selector. - - - - - RFC 6089. - 
-            +-----+--------------+-------------+
-            | Bit | 0-7          | 8-15        |
-            +-----+--------------+-------------+
-            | 0   | Sub-Opt Type | Sub-Opt Len | 
-            +-----+--------------+-------------+
-            | 16  | TS Format    | Reserved    |
-            +-----+--------------+-------------+
-            | 32  | Traffic Selector           |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - RFC 6089. - 
-            +-----+--------------+-------------+
-            | Bit | 0-7          | 8-15        |
-            +-----+--------------+-------------+
-            | 0   | Sub-Opt Type | Sub-Opt Len |
-            +-----+--------------+-------------+
-            | 16  | Option Data                |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The number of bytes this option takes. - - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from traffic selector format and traffic selector. - - Indicates the Traffic Selector Format. - The traffic selector formatted according to TrafficSelectorFormat. - - - - Indicates the Traffic Selector Format. - - - - - The traffic selector formatted according to TrafficSelectorFormat. - - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+--------------+---------------+
-            | Bit | 0-7         | 8-15                    | 16-23        | 24-31         |
-            +-----+-------------+-------------------------+--------------+---------------+
-            | 0   | Next Header | Header Extension Length | Routing Type | Segments Left |
-            +-----+-------------+-------------------------+--------------+---------------+
-            | 32  | Reserved                                                             |
-            +-----+----------------------------------------------------------------------+
-            | 64  | Address[1]                                                           |
-            |     |                                                                      |
-            |     |                                                                      |
-            |     |                                                                      |
-            +-----+----------------------------------------------------------------------+
-            | 192 | Address[2]                                                           |
-            |     |                                                                      |
-            |     |                                                                      |
-            |     |                                                                      |
-            +-----+----------------------------------------------------------------------+
-            | .   | .                                                                    |
-            | .   | .                                                                    |
-            | .   | .                                                                    |
-            +-----+----------------------------------------------------------------------+
-            |     | Address[n]                                                           |
-            |     |                                                                      |
-            |     |                                                                      |
-            |     |                                                                      |
-            +-----+----------------------------------------------------------------------+
-
- - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+--------------+---------------+
-            | Bit | 0-7         | 8-15                    | 16-23        | 24-31         |
-            +-----+-------------+-------------------------+--------------+---------------+
-            | 0   | Next Header | Header Extension Length | Routing Type | Segments Left |
-            +-----+-------------+-------------------------+--------------+---------------+
-            | 32  | Routing Data - type-specific data                                    |
-            | ... |                                                                      |
-            +-----+----------------------------------------------------------------------+
-
- - - - - The minimum number of bytes the extension header data takes. - - - - - True iff the extension header parsing didn't encounter an issue. - - - - - Identifier of a particular Routing header variant. - - - - - Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. - - - - - Identifies the type of this extension header. - - - - - The minimum number of bytes the routing data takes. - - - - - Creates an instance from next header, segments left and addresses. - - Identifies the type of header immediately following this extension header. - - Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. - - Routing addresses. - - - - Identifier of a particular Routing header variant. - - - - - Routing addresses. - - - - - RFC 5568. - Code of a Handover Initiate Message IPv6 Mobility Extension Header. - - - - - The Previous Access Router uses this code value when it processes a Fast Binding Update with the Previous Care of Address as source IP address. - - - - - The Previous Access Router uses this Code value when it processes a Fast Binidng Update whose source IP address is not the Previous Care of Address. - - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Reserved                              |
-            +-----+---------------------------------------+
-            | 64  | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - The different ICMP message types. - - - - - RFC 792. - - The data received in the echo message must be returned in the echo reply message. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. - The echoer returns these same values in the echo reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792 - - - If, according to the information in the gateway's routing tables, - the network specified in the internet destination field of a datagram is unreachable, e.g., the distance to the network is infinity, - the gateway may send a destination unreachable message to the internet source host of the datagram. - In addition, in some networks, the gateway may be able to determine if the internet destination host is unreachable. - Gateways in these networks may send destination unreachable messages to the source host when the destination host is unreachable. - - - - If, in the destination host, the IP module cannot deliver the datagram because the indicated protocol module or process port is not active, - the destination host may send a destination unreachable message to the source host. - - - - Another case is when a datagram must be fragmented to be forwarded by a gateway yet the Don't Fragment flag is on. - In this case the gateway must discard the datagram and may return a destination unreachable message. - - - - Codes 0, 1, 4, and 5 may be received from a gateway. - Codes 2 and 3 may be received from a host. - - - - - - RFC 792. - - - A gateway may discard internet datagrams if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network. - If a gateway discards a datagram, it may send a source quench message to the internet source host of the datagram. - A destination host may also send a source quench message if datagrams arrive too fast to be processed. - The source quench message is a request to the host to cut back the rate at which it is sending traffic to the internet destination. - The gateway may send a source quench message for every message that it discards. - On receipt of a source quench message, the source host should cut back the rate at which it is sending traffic to the specified destination - until it no longer receives source quench messages from the gateway. - The source host can then gradually increase the rate at which it sends traffic to the destination until it again receives source quench messages. - - - - The gateway or host may send the source quench message when it approaches its capacity limit rather than waiting until the capacity is exceeded. - This means that the data datagram which triggered the source quench message may be delivered. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792. - - - The gateway sends a redirect message to a host in the following situation. - A gateway, G1, receives an internet datagram from a host on a network to which the gateway is attached. - The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the datagram's internet destination network, X. - If G2 and the host identified by the internet source address of the datagram are on the same network, a redirect message is sent to the host. - The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination. - The gateway forwards the original datagram's data to its internet destination. - - - - For datagrams with the IP source route options and the gateway address in the destination address field, - a redirect message is not sent even if there is a better route to the ultimate destination than the next address in the source route. - - - - Codes 0, 1, 2, and 3 may be received from a gateway. - - - - - - RFC 792. - - The data received in the echo message must be returned in the echo reply message. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. - The echoer returns these same values in the echo reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 1256. - - - - - RFC 1256. - - - - - RFC 792. - - - If the gateway processing a datagram finds the time to live field is zero it must discard the datagram. - The gateway may also notify the source host via the time exceeded message. - - - - If a host reassembling a fragmented datagram cannot complete the reassembly due to missing fragments within its time limit it discards the datagram, - and it may send a time exceeded message. - If fragment zero is not available then no time exceeded need be sent at all. - - - - Code 0 may be received from a gateway. - Code 1 may be received from a host. - - - - - - RFC 792. - - - If the gateway or host processing a datagram finds a problem with the header parameters such that it cannot complete processing the datagram it must discard the datagram. - One potential source of such a problem is with incorrect arguments in an option. - The gateway or host may also notify the source host via the parameter problem message. - This message is only sent if the error caused the datagram to be discarded. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792 - - The data received (a timestamp) in the message is returned in the reply together with an additional timestamp. - The timestamp is 32 bits of milliseconds since midnight UT. - - - - If the time is not available in miliseconds or cannot be provided with respect to midnight UT - then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792 - - The data received (a timestamp) in the message is returned in the reply together with an additional timestamp. - The timestamp is 32 bits of milliseconds since midnight UT. - - - - If the time is not available in miliseconds or cannot be provided with respect to midnight UT - then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792. - - This message may be sent with the source network in the IP header source and destination address fields zero (which means "this" network). - The replying IP module should send the reply with the addresses fully specified. - This message is a way for a host to find out the number of the network it is on. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792. - - This message may be sent with the source network in the IP header source and destination address fields zero (which means "this" network). - The replying IP module should send the reply with the addresses fully specified. - This message is a way for a host to find out the number of the network it is on. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 950. - - - A gateway receiving an address mask request should return it with the address mask field set to the 32-bit mask of the bits identifying the subnet and network, - for the subnet on which the request was received. - - - - If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. - However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. - Even when the replies are broadcast, since there is only one possible address mask for a subnet, there is no need to match requests with replies. - The "Identifier" and "Sequence Number" fields can be ignored. - - - - - - RFC 950. - - - A gateway receiving an address mask request should return it with the address mask field set to the 32-bit mask of the bits identifying the subnet and network, - for the subnet on which the request was received. - - - - If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. - However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. - Even when the replies are broadcast, since there is only one possible address mask for a subnet, there is no need to match requests with replies. - The "Identifier" and "Sequence Number" fields can be ignored. - - - - - - RFC 1393. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1788. - - - - - RFC 1788. - Parsing of this datagram isn't supported because its parsing is not clear from the RFC. - - - - - RFC 2521. - - - - - RFC 1475. - 
-            +-----+------+------+-----------+
-            | Bit | 0-7  | 8-15 | 16-31     |
-            +-----+------+------+-----------+
-            | 0   | Type | Code | Checksum  |
-            +-----+------+------+-----------+
-            | 32  | pointer to problem area |
-            +-----+-------------------------+
-            | 64  | copy of datagram that   |
-            |     | could not be converted  |
-            |     | ...                     |
-            +-----+-------------------------+
-
- - - - - The number of bytes that should be taken from the original datagram for an unsupported transport protocol ICMP code. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if the datagram's length is OK, the checksum is correct, the code is in the expected range - and the IPv4 payload contains at least an IPv4 header and the transport header. - If the code is for unsupported transport protocol, the IPv4 payload should contain 256 bytes of the original datagram. - - - - - An offset from the start of the original datagram to the beginning of the offending field. - - - - - The minimum valid ICMP code for this type of ICMP datagram. - - - - - The maximum valid ICMP code for this type of ICMP datagram. - - - - - RFC 792. - - - - - The value of this field determines the format of the remaining data. - - - - - Represents a set of HTTP field parameters. - Used for some of HTTP fields. - All parameters must have different names. - - - - - Creates the parameters from an array of parameters. Keys are the parameters names and values are the parameters values. - - - - - Creates the parameters from an enumerable of parameters. Keys are the parameters names and values are the parameters values. - - - - - Enumerates over the parameters. - - - - - Two HTTP field parameters are equal if all of their parameters are equal. - - - - - Two HTTP field parameters are equal if all of their parameters are equal. - - - - - Xor of all of the hash codes of the parameters names and values. - - - - - - Returns a string of parameters beginning and separated by semicolon and equal sign between keys and values. - - - - - Number of parameters. - - - - - Returns the value of the given parameter name. - - The name of the parameter. - The value of the parameter. - - - - Represents a source route entry consisting of an unknown data. - - - - - Initializes using an address family, data, and offset to the first octet of the active entry in Source Route Entry to be examined. - - The Address Family field contains a two octet value which indicates the syntax and semantics of the Routing Information field. - The data of the entry source route. - The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined. - - - - True iff the payloads a are equal. - - - - - Writes the payload to the given buffer in the given offset. - - The buffer to write the payload to. - The offset in the buffer to start writing. - - - - The Address Family field contains a two octet value which indicates the syntax and semantics of the Routing Information field. - - - - - The SRE Length field contains the number of octets in the SRE. - - - - - The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined. - - - - - The data of the entry source route. - - - - - The hash code of the payload. - - - - - Eastlake. - 
-            +-----+--------+-----------+
-            | bit | 0-7    | 8-15      |
-            +-----+--------+-----------+
-            | 0   | coding | subcoding |
-            +-----+--------+-----------+
-            | 16  | data               |
-            | ... |                    |
-            +-----+--------------------+
-
- - - - - Construct an instance out of the coding subcoding and data fields. - - - A combination of coding and subcoding. - Has a valid enum value if the subcoding is defined specifically for the coding. - - Variable length and could be null in some cases. - - - - Constructs an instance out of the coding, subcoding and data fields. - - Gives the general structure of the data. - Provides additional information depending on the value of the coding. - Variable length and could be null in some cases. - - - - Two are equal iff their coding, subcoding and data fields are equal. - - - - - Two are equal iff their coding, subcoding and data fields are equal. - - - - - A hash code based on the coding, subcoding and data fields. - - - - - Gives the general structure of the data. - - - - - Provides additional information depending on the value of the coding. - - - - - Returns a combination of coding and subcoding. - Has a valid enum value if the subcoding is defined specifically for the coding. - - - - - Variable length and could be null in some cases. - - - - - RFC 2535. - 
-            +------------------+
-            | next domain name |
-            |                  |
-            +------------------+
-            | type bit map     |
-            |                  |
-            +------------------+
-
- - - - - The maximum length in bytes of the type bitmap. - - - - - The maximum DNS type that can be in the type bitmap. - - - - - Constructs an instance from next domain name and type bitmap. - - The next domain name according to the canonical DNS name order. - - One bit per RR type present for the owner name. - A one bit indicates that at least one RR of that type is present for the owner name. - A zero indicates that no such RR is present. - All bits not specified because they are beyond the end of the bit map are assumed to be zero. - Note that bit 30, for NXT, will always be on so the minimum bit map length is actually four octets. - Trailing zero octets are prohibited in this format. - The first bit represents RR type zero (an illegal type which can not be present) and so will be zero in this format. - This format is not used if there exists an RR with a type number greater than 127. - If the zero bit of the type bit map is a one, it indicates that a different format is being used which will always be - the case if a type number greater than 127 is present. - - - - - True iff the given type exists in the bitmap. - - - - - Creates a type bitmap from a given list of DNS types. - - - - - Two DnsResourceDataNextDomain are equal iff their next domain name and type bitmap fields are equal. - - - - - Two DnsResourceDataNextDomain are equal iff their next domain name and type bitmap fields are equal. - - - - - A hash code based on the next domain name and type bitmap fields. - - - - - The next domain name according to the canonical DNS name order. - - - - - One bit per RR type present for the owner name. - A one bit indicates that at least one RR of that type is present for the owner name. - A zero indicates that no such RR is present. - All bits not specified because they are beyond the end of the bit map are assumed to be zero. - Note that bit 30, for NXT, will always be on so the minimum bit map length is actually four octets. - Trailing zero octets are prohibited in this format. - The first bit represents RR type zero (an illegal type which can not be present) and so will be zero in this format. - This format is not used if there exists an RR with a type number greater than 127. - If the zero bit of the type bit map is a one, it indicates that a different format is being used which will always be - the case if a type number greater than 127 is present. - - - - - Returns all the types that exist in the type bitmap. - - - - - http://files.dns-sd.org/draft-sekar-dns-ul.txt. - 
-            +-----+-------+
-            | bit | 0-31  |
-            +-----+-------+
-            | 0   | LEASE |
-            +-----+-------+
-
- - - - - The number of bytes this option data can take. - - - - - Builds - - - - - - Indicating the lease life, in seconds, desired by the client. - In Update Responses, this field contains the actual lease granted by the server. - Note that the lease granted by the server may be less than, greater than, or equal to the value requested by the client. - To reduce network and server load, a minimum lease of 30 minutes (1800 seconds) is recommended. - Note that leases are expected to be sufficiently long as to make timer discrepancies (due to transmission latency, etc.) - between a client and server negligible. - Clients that expect the updated records to be relatively static may request appropriately longer leases. - Servers may grant relatively longer or shorter leases to reduce network traffic due to refreshes, or reduce stale data, respectively. - - - - - The number of bytes the option data takes. - - - - - http://files.dns-sd.org/draft-sekar-dns-llq.txt. - 
-            +-----+------------+
-            | bit | 0-15       |
-            +-----+------------+
-            | 0   | VERSION    |
-            +-----+------------+
-            | 16  | LLQ-OPCODE |
-            +-----+------------+
-            | 32  | ERROR-CODE |
-            +-----+------------+
-            | 48  | LLQ-ID     |
-            |     |            |
-            |     |            |
-            |     |            |
-            +-----+------------+
-            | 112 | LEASE-LIFE |
-            |     |            |
-            +-----+------------+
-
- - - - - Constructs an instance out of the version, opcode, error code, id and lease life fields. - - Version of LLQ protocol implemented. - Identifies LLQ operation. - Identifies LLQ errors. - Identifier for an LLQ. - Requested or granted life of LLQ, in seconds. - - - - Version of LLQ protocol implemented. - - - - - Identifies LLQ operation. - - - - - Identifies LLQ errors. - - - - - Identifier for an LLQ. - - - - - Requested or granted life of LLQ, in seconds. - - - - - The number of bytes the option data takes. - - - - - Represents the DataLink type. - - - - - Create the DataLink from a kind. - - - - - Two DataLinks are equal if they are of the same kind. - - - - - Two DataLinks are equal if they are of the same type and the same kind. - - - - - Two DataLinks are equal if they are of the same kind. - - - - - Two DataLinks are different if they have different kinds. - - - - - The hash code of the datalink is the hash code of its kind. - - - - - The string is the kind's string. - - - - - Etherent DataLink. - - - - - IPv4 DataLink. - - - - - The kind of the DataLink. - - - - - RFC 2018. - The SACK option is to be used to convey extended acknowledgment information from the receiver to the sender over an established TCP connection. - - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | Left Edge of  |
-            |     | 1st Block     |
-            +-----+---------------+
-            | 48  | Right Edge of |
-            |     | 1st Block     |
-            +-----+---------------+
-            ...
-            +-----+---------------+
-            |     | Left Edge of  |
-            |     | nth Block     |
-            +-----+---------------+
-            |     | Right Edge of |
-            |     | nth Block     |
-            +-----+---------------+
-
- - - The SACK option is to be sent by a data receiver to inform the data sender of non-contiguous blocks of data that have been received and queued. - The data receiver awaits the receipt of data (perhaps by means of retransmissions) to fill the gaps in sequence space between received blocks. - When missing segments are received, the data receiver acknowledges the data normally by advancing - the left window edge in the Acknowledgement Number Field of the TCP header. - The SACK option does not change the meaning of the Acknowledgement Number field. - - - - This option contains a list of some of the blocks of contiguous sequence space occupied by data that has been received and queued within the window. - Each contiguous block of data queued at the data receiver is defined in the SACK option by two 32-bit unsigned integers in network byte order: - - Left Edge of Block - This is the first sequence number of this block. - Right Edge of Block - This is the sequence number immediately following the last sequence number of this block. - - - Each block represents received bytes of data that are contiguous and isolated; - that is, the bytes just below the block, (Left Edge of Block - 1), and just above the block, (Right Edge of Block), have not been received. - - A SACK option that specifies n blocks will have a length of 8*n+2 bytes, so the 40 bytes available for TCP options can specify a maximum of 4 blocks. - It is expected that SACK will often be used in conjunction with the Timestamp option used for RTTM [Jacobson92], - which takes an additional 10 bytes (plus two bytes of padding); thus a maximum of 3 SACK blocks will be allowed in this case. - - The SACK option is advisory, in that, while it notifies the data sender that the data receiver has received the indicated segments, - the data receiver is permitted to later discard data which have been reported in a SACK option. - - - - - The minimum number of bytes this option take. - - - - - The minimum number of bytes this option's value take. - - - - - Creates the option from the given list of selective ack blocks. - - - - - The default is no blocks. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The collection of selective ack blocks. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | MD5 digest    |
-            |     |               |
-            |     |               |
-            |     |               |
-            |     |               |
-            |     |               |
-            |     |               |
-            |     |               |
-            +-----+---------------+
-
- - - The MD5 digest is always 16 bytes in length, and the option would appear in every segment of a connection. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates the option using the given signature data. - - - - - The default signature is all zeroes. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The signature value. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - TCP Echo Reply Option: - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | 4 bytes of    |
-            |     | echoed info   |
-            +-----+---------------+
-
- - - A TCP that receives a TCP Echo option containing four information bytes will return these same bytes in a TCP Echo Reply option. - - - - This TCP Echo Reply option must be returned in the next segment (e.g., an ACK segment) that is sent. - If more than one Echo option is received before a reply segment is sent, the TCP must choose only one of the options to echo, - ignoring the others; specifically, it must choose the newest segment with the oldest sequence number. - - - - To use the TCP Echo and Echo Reply options, a TCP must send a TCP Echo option in its own SYN segment - and receive a TCP Echo option in a SYN segment from the other TCP. - A TCP that does not implement the TCP Echo or Echo Reply options must simply ignore any TCP Echo options it receives. - However, a TCP should not receive one of these options in a non-SYN segment unless it included a TCP Echo option in its own SYN segment. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates the option using the given echo info. - - - - - The default echo info is 0. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The echoed info. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - RFC 5841. - TCP Mood Option: - 
-            +-----+--------+
-            | Bit | 0-7    |
-            +-----+--------+
-            | 0   | Kind   |
-            +-----+--------+
-            | 8   | Length |
-            +-----+--------+
-            | 16  | ASCII  |
-            | ... | Mood   |
-            +-----+--------+
-
- - - It is proposed that option 25 (released 2000-12-18) be used to define packet mood. - This option would have a length value of 4 or 5 bytes. - All the simple emotions described as expressible via this mechanism can be displayed with two or three 7-bit, ASCII-encoded characters. - Multiple mood options may appear in a TCP header, so as to express more complex moods than those defined here (for instance if a packet were happy and surprised). - - - - It is proposed that common emoticons be used to denote packet mood. - Packets do not "feel" per se. The emotions they could be tagged with are a reflection of the user mood expressed through packets. - So the humanity expressed in a packet would be entirely sourced from humans. - To this end, it is proposed that simple emotions be used convey mood as follows. - - 
-            ASCII                Mood
-            =====                ====
-            :)                   Happy
-            :(                   Sad
-            :D                   Amused
-            %(                   Confused
-            :o                   Bored
-            :O                   Surprised
-            :P                   Silly
-            :@                   Frustrated
-            >:@                  Angry
-            :|                   Apathetic
-            ;)                   Sneaky
-            >:)                  Evil
-
- - Proposed ASCII character encoding - 
-            Binary          Dec  Hex     Character
-            ========        ===  ===     =========
-            010 0101        37   25      %
-            010 1000        40   28      (
-            010 1001        41   29      )
-            011 1010        58   3A      :
-            011 1011        59   3B      ;
-            011 1110        62   3E      >
-            100 0000        64   40      @
-            100 0100        68   44      D
-            100 1111        79   4F      O
-            101 0000        80   50      P
-            110 1111        111  6F      o
-            111 1100        124  7C      |
-
- - - - - - The minimum number of bytes this option take. - - - - - The maximum number of bytes this option take. - - - - - The minimum number of bytes this option value take. - - - - - The maximum number of bytes this option value take. - - - - - Creates the option using the given emotion. - - - - - The default emotion is confused. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The emotion of the option. - - - - - The ASCII string of the emotion. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - Represents the time passed since midnight UT. - - - - - Create the time from milliseconds since midnight UT. - - - - - Create the time from TimeSpan since midnight UT. - - - - - Two times are equal if the have the exact same value. - - - - - Two times are equal if the have the exact same value. - - - - - Two times are equal if the have the exact same value. - - - - - Two times are different if the have different values. - - - - - The hash code of a time is the hash code of the milliseconds since midnight UT value. - - - - - Number of milliseconds passed since midnight UT. - - - - - Time passed since midnight UT. - - - - - Represents an IPv4 address. - - - - - The number of bytes the address take. - - - - - Create an address from a 32 bit integer. - 0 -> 0.0.0.0 - 1 -> 0.0.0.1 - 256 -> 0.0.1.0 - - - - - Creates an address from an address string (1.2.3.4). - - - - - Converts the string representation of an IPv4 address (1.2.3.4) to its IPv4 address equivalent. - A return value indicates whether the conversion succeeded. - - A string containing the IPv4 address to convert (1.2.3.4). - - When this method returns, contains the IPv4 address value equivalent of the IPv4 address contained in s, if the conversion succeeded, - or zero IPv4 address if the conversion failed. - The conversion fails if the s parameter is null or String.Empty or is not of the correct format. This parameter is passed uninitialized. - - True iff parsing was successful. - - - - Gets the address value as a 32 bit integer. - - - - - Two addresses are equal if the have the exact same value. - - - - - Two addresses are equal if the have the exact same value. - - - - - Two addresses are equal if the have the exact same value. - - - - - Two addresses are different if the have different values. - - - - - The hash code of an address is the hash code of its 32 bit integer value. - - - - - Translates the address to a string (1.2.3.4). - - - - - The zero address (0.0.0.0). - - - - - The all-hosts group. - If you ping that group, all multicast capable hosts on the network should answer, - as every multicast capable host must join that group at start-up on all it's multicast capable interfaces. - - - - - RFC 2460. - Represents an IPv6 datagram. - 
-            +-----+---------+---------------+-------+-------------+-----------+
-            | Bit | 0-3     | 4-11          | 12-15 | 16-23       | 24-31     |
-            +-----+---------+---------------+-------+-------------+-----------+
-            | 0   | Version | Traffic Class | Flow Label                      |
-            +-----+---------+---------------+-------+-------------+-----------+
-            | 32  | Payload Length                  | Next Header | Hop Limit |
-            +-----+---------------------------------+-------------+-----------+
-            | 64  | Source Address                                            |
-            |     |                                                           |
-            |     |                                                           |
-            |     |                                                           |
-            +-----+-----------------------------------------------------------+
-            | 192 | Destination Address                                       |
-            |     |                                                           |
-            |     |                                                           |
-            |     |                                                           |
-            +-----+-----------------------------------------------------------+
-            | 320 | Extension Headers (optional)                              |
-            | ... |                                                           |
-            +-----+-----------------------------------------------------------+
-
- - - - - The number of bytes the header takes in bytes (not including extension headers). - - - - - Maximum flow label value. - - - - - The version (6). - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if all extension headers are valid and payload is valid. - - - - - Calculates the Transport checksum field value. - - The calculated checksum value. - - - - Available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of - IPv6 packets. - - - - - May be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, - such as non-default quality of service or "real-time" service. - Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, - pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet. - - - - - Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets. - Note that any extension headers present are considered part of the payload, i.e., included in the length count. - - - - - The actual payload length - - - - - Identifies the type of header immediately following the IPv6 header. - Uses the same values as the IPv4 Protocol field. - - - - - Decremented by 1 by each node that forwards the packet. - The packet is discarded if Hop Limit is decremented to zero. - - - - - Address of the originator of the packet. - - - - - Address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). - - - - - The IPv6 extension headers. - - - - - The total length - header and payload according to the IP header. - - - - - RFC ietf-6man-lineid-08. - http://tools.ietf.org/html/draft-ietf-6man-lineid-08 - Line Identification Destination Option. - 
-            +-----+---------------------+
-            | Bit | 0-7                 |
-            +-----+---------------------+
-            | 0   | Option Type         |
-            +-----+---------------------+
-            | 8   | Opt Data Len        |
-            +-----+---------------------+
-            | 16  | LineIDLen           |
-            +-----+---------------------+
-            | 24  | Line Identification |
-            | ... |                     |
-            +-----+---------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from line identification. - - - Variable length data inserted by the AN describing the subscriber agent circuit identifier - corresponding to the logical access loop port of the AN from which the RS was initiated. - The line identification must be unique across all the ANs that share a link to the edge router. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - Variable length data inserted by the AN describing the subscriber agent circuit identifier - corresponding to the logical access loop port of the AN from which the RS was initiated. - The line identification must be unique across all the ANs that share a link to the edge router. - - - - - RFC 6463. - 
-            +-----+---+---+-----+--------------+
-            | Bit | 0 | 1 | 2-7 | 8-15         |
-            +-----+---+---+-----+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+---+---+-----+--------------+
-            | 16  | K | N | Reserved           |
-            +-----+---+---+--------------------+
-            | 32  | r2LMA Address              |
-            |     |                            |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from an IPv4 local mobility address. - - The IPv4 address of the r2LMA. - - - - Creates an instance from an IPv6 local mobility address. - - The unicast IPv6 address of the r2LMA. - - - - The IPv4 address of the r2LMA. - This value is present when the corresponding PBU was sourced from an IPv4 address. - - - - - The unicast IPv6 address of the r2LMA. - This value is present when the corresponding PBU was sourced from an IPv6 address. - - - - - RFC 5555. - 
-            +-----+---+---------+--------------+
-            | Bit | 0 | 1-7     | 8-15         |
-            +-----+---+---------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+---+---------+--------------+
-            | 16  | F | Reserved               |
-            +-----+---+------------------------+
-            | 32  | Refresh time               |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - Recommended value for Refresh Time. - - - - - The number of bytes the option data takes. - - - - - Creates an instance from UDP encapsulated required and refresh time. - - - Indicates to the mobile node that UDP encapsulation is required. - When set, this flag indicates that the mobile node must use UDP encapsulation even if a NAT is not located between the mobile node and home agent. - This flag should not be set when the mobile node is assigned an IPv6 care-of address with some exceptions. - - - A suggested time (in seconds) for the mobile node to refresh the NAT binding. - If set to zero, it is ignored. - If this field is set to uint.MaxValue, it means that keepalives are not needed, i.e., no NAT was detected. - The home agent must be configured with a default value for the refresh time. - The recommended value is RecommendedRefreshTime. - - - - - Indicates to the mobile node that UDP encapsulation is required. - When set, this flag indicates that the mobile node must use UDP encapsulation even if a NAT is not located between the mobile node and home agent. - This flag should not be set when the mobile node is assigned an IPv6 care-of address with some exceptions. - - - - - A suggested time (in seconds) for the mobile node to refresh the NAT binding. - If set to zero, it is ignored. - If this field is set to uint.MaxValue, it means that keepalives are not needed, i.e., no NAT was detected. - The home agent must be configured with a default value for the refresh time. - The recommended value is RecommendedRefreshTime. - - - - - RFC 6602. - 
-            +-----+-------------+----------------+
-            | Bit | 0-7         | 8-15           |
-            +-----+-------------+----------------+
-            | 0   | Option Type | Opt Data Len   |
-            +-----+-------------+----------------+
-            | 16  | Sub-type    | Reserved       |
-            +-----+-------------+----------------+
-            | 32  | Mobile Node Group Identifier |
-            |     |                              |
-            +-----+------------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from sub type and mobile node group identifier. - - - Identifies the specific mobile node's group type. - - - Contains the mobile node's group identifier. - The value of (0) is reserved and should not be used. - The value of (1) ALL-SESSIONS is the default group of all mobility sessions established between a given local mobility anchor and a mobile access - gateway. - - - - - Identifies the specific mobile node's group type. - - - - - Contains the mobile node's group identifier. - The value of (0) is reserved and should not be used. - The value of (1) ALL-SESSIONS is the default group of all mobility sessions established between a given local mobility anchor and a mobile access - gateway. - - - - - RFC 4866. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Care-of Keygen Token       |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Value                      |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an instance from care of keygen token. - - Contains the care-of keygen token generated by the correspondent node. - - - - Contains the care-of keygen token generated by the correspondent node. - - - - - RFC 2406. - 
-            +-----+------------+-------------+
-            | Bit | 0-7        | 8-15        |
-            +-----+------------+-------------+
-            | 0   | Security Parameters      |
-            |     | Index (SPI)              |
-            +-----+--------------------------+
-            | 32  | Sequence Number          |
-            |     |                          |
-            +-----+--------------------------+
-            | 64  | Payload Data             |
-            | ... |                          |
-            +-----+--------------------------+
-            |     | Padding                  |
-            | ... |                          |
-            +-----+------------+-------------+
-            |     | Pad Length | Next Header |
-            +-----+------------+-------------+
-            |     | Authentication Data      |
-            | ... |                          |
-            +-----+--------------------------+
-
- - 
-            +-----+------------+-------------+
-            | Bit | 0-7        | 8-15        |
-            +-----+------------+-------------+
-            | 0   | Security Parameters      |
-            |     | Index (SPI)              |
-            +-----+--------------------------+
-            | 32  | Sequence Number          |
-            |     |                          |
-            +-----+--------------------------+
-            | 64  | Encrypted Data           |
-            | ... |                          |
-            +-----+--------------------------+
-            |     | Authentication Data      |
-            | ... |                          |
-            +-----+--------------------------+
-
- - - - - The minimum number of bytes the extension header takes. - - - - - Creates an instance from security parameter index, sequence number and encrypted data and authentication data. - - - The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), - uniquely identifies the Security Association for this datagram. - The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; - a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. - It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). - The SPI field is mandatory. - - - Contains a monotonically increasing counter value (sequence number). - It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. - Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender must always transmit this field, - but the receiver need not act upon it. - - - Contains the encrypted Payload Data, Padding, Pad Length and Next Header and the Authentication Data. - - - - - True iff the given extension header is equal to this extension header. - - - - - True iff the given extension header is equal to this extension header. - - - - - Returns a hash code of the extension header. - - - - - Identifies the type of this extension header. - - - - - The number of bytes this extension header takes. - - - - - True iff the extension header parsing didn't encounter an issue. - - - - - - The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), - uniquely identifies the Security Association for this datagram. - The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; - a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. - It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). - The SPI field is mandatory. - - - The SPI value of zero (0) is reserved for local, implementation-specific use and must not be sent on the wire. - For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" - during the period when the IPsec implementation has requested that its key management entity establish a new SA, - but the SA has not yet been established. - - - - - - - Contains a monotonically increasing counter value (sequence number). - It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. - Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender must always transmit this field, - but the receiver need not act upon it. - - - The sender's counter and the receiver's counter are initialized to 0 when an SA is established. - (The first packet sent using a given SA will have a Sequence Number of 1.) - If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. - Thus, the sender's counter and the receiver's counter must be reset (by establishing a new SA and thus a new key) - prior to the transmission of the 2^32nd packet on an SA. - - - - - - Contains the encrypted Payload Data, Padding, Pad Length and Next Header and the Authentication Data. - - Payload Data is a variable-length field containing data described by the Next Header field. - The Payload Data field is mandatory and is an integral number of bytes in length. - If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), - then this data may be carried explicitly in the Payload field. - Any encryption algorithm that requires such explicit, per-packet synchronization data must indicate the length, any structure for such data, - and the location of this data as part of an RFC specifying how the algorithm is used with ESP. - If such synchronization data is implicit, the algorithm for deriving the data must be part of the RFC. - - - The sender may add 0-255 bytes of padding. - Inclusion of the Padding field in an ESP packet is optional, but all implementations must support generation and consumption of padding. - - - The Pad Length field indicates the number of pad bytes immediately preceding it. - The range of valid values is 0-255, where a value of zero indicates that no Padding bytes are present. - The Pad Length field is mandatory. - - - The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, - e.g., an extension header in IPv6 or an upper layer protocol identifier. - The Next Header field is mandatory. - - - The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) - computed over the ESP packet minus the Authentication Data. - The length of the field is specified by the authentication function selected. - The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. - The authentication algorithm specification must specify the length of the ICV and the comparison rules and processing steps for validation. - - - - - - RFC 5846. - The Per-MN Revocation Trigger values are less than 128. - The Per-MN Revocation Trigger is used when the BRI message intends to revoke one or more bindings for the same mobile node. - The Global Revocation Trigger values are greater than 128 and less than 250 and used in the BRI message - when the Global (G) bit is set for global revocation. - The values 250-255 are reserved for testing purposes only. - - - - - Unspecified. - - - - - Administrative Reason. - - - - - Inter-MAG Handover - same Access Type. - - - - - Inter-MAG Handover - different Access Type. - - - - - Inter-MAG Handover - Unknown. - - - - - User-Initiated Session(s) Termination - - - - - Access Network Session(s) Termination - - - - - Possible Out-of-Sync BCE State. - - - - - Global Revocation Trigger Value. - Per-Peer Policy. - - - - - Global Revocation Trigger Value. - Revoking Mobility Node Local Policy. - - - - - RFC 3963, 5213, 5845, 6275. - 
-            +-----+-------------+---+---+----+----+---------+
-            | Bit | 0-7         | 8 | 9 | 10 | 11 | 12-15   |
-            +-----+-------------+---+---+----+----+---------+
-            | 0   | Next Header | Header Extension Length   |
-            +-----+-------------+---------------------------+
-            | 16  | MH Type     | Reserved                  |
-            +-----+-------------+---------------------------+
-            | 32  | Checksum                                |
-            +-----+-------------+---+---+---+----+----------+
-            | 48  | Status      | K | R | P | T  | Reserved |
-            +-----+-------------+---+---+---+----+----------+
-            | 64  | Sequence #                              |
-            +-----+-----------------------------------------+
-            | 80  | Lifetime                                |
-            +-----+-----------------------------------------+
-            | 96  | Mobility Options                        |
-            | ... |                                         |
-            +-----+-----------------------------------------+
-
- - - - - RFCs 5568, 6275. - 
-            +-----+-------------+---+---------------------+
-            | Bit | 0-7         | 8 | 9-15                |
-            +-----+-------------+---+---------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+-------------+---+---------------------+
-            | 48  | Status      | K | Reserved            |
-            +-----+-------------+---+---------------------+
-            | 64  | Sequence #                            |
-            +-----+---------------------------------------+
-            | 80  | Lifetime                              |
-            +-----+---------------------------------------+
-            | 96  | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Indicating the disposition of the Binding Update. - Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. - Values greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. - - - - - - If this is cleared, the protocol used by the home agent for establishing the IPsec security associations between the mobile node and the home agent - does not survive movements. - It may then have to be rerun. - (Note that the IPsec security associations themselves are expected to survive movements.) - - - Correspondent nodes must set the K bit to 0. - - - - - - Copied from the Sequence Number field in the Binding Update. - It is used by the mobile node in matching this Binding Acknowledgement with an outstanding Binding Update. - - - - - - The granted lifetime, in time units of 4 seconds for Binding Acknowledgement and 1 second for Fast Binding Acknowledgement, - for which this node should retain the entry for this mobile node in its Binding Cache. - - - The value of this field is undefined if the Status field indicates that the Binding Update was rejected. - - - - - - Creates an instance from next header, checksum, status, key management mobility capability, mobile router, proxy registration, TLV header format, - sequence number, lifetime and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Indicating the disposition of the Binding Update. - Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. - Values greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. - - - If this is cleared, the protocol used by the home agent for establishing the IPsec security associations between the mobile node and the home agent - does not survive movements. - It may then have to be rerun. - (Note that the IPsec security associations themselves are expected to survive movements.) - - - Indicates that the Home Agent that processed the Binding Update supports Mobile Routers. - True only if the corresponding Binding Update had the Mobile Router set to true. - - - Indicates that the local mobility anchor that processed the corresponding Proxy Binding Update message supports proxy registrations. - True only if the corresponding Proxy Binding Update had the Proxy Registration set to true. - - - Indicates that the sender of the Proxy Binding Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4 using TLV-header format. - - - Copied from the Sequence Number field in the Binding Update. - It is used by the mobile node in matching this Binding Acknowledgement with an outstanding Binding Update. - - - The granted lifetime, in time units of 4 seconds for Binding Acknowledgement and 1 second for Fast Binding Acknowledgement, - for which this node should retain the entry for this mobile node in its Binding Cache. - - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Indicates that the Home Agent that processed the Binding Update supports Mobile Routers. - True only if the corresponding Binding Update had the Mobile Router set to true. - - - - - Indicates that the local mobility anchor that processed the corresponding Proxy Binding Update message supports proxy registrations. - True only if the corresponding Proxy Binding Update had the Proxy Registration set to true. - - - - - Indicates that the sender of the Proxy Binding Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4 using TLV-header format. - - - - - RFC 1112. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - The IGMP version of a Membership Query message. - If the type is not a query, None will be returned. - - - - - RFC 2616. - Represents an HTTP request layer. - - - - - Two HTTP Request layers are equal iff they have the same version, header, body, method and uri. - - - - - Two HTTP Request layers are equal iff they have the same version, header, body, method and uri. - - - - - True since the message is a request. - - - - - The HTTP Request Method. - - - - - The HTTP Request URI. - - - - - RFC 1035. - 
-            +-----+----------+---------+
-            | bit | 0-7      | 8-31    |
-            +-----+----------+---------+
-            | 0   | Address            |
-            +-----+----------+---------+
-            | 32  | Protocol | Bit Map | (Bit Map is variable multiple of 8 bits length)
-            +-----+----------+---------+
-
- - - - - Constructs an instance from the address, protocol and bitmap fields. - - The service address. - Specifies an IP protocol number. - Has one bit per port of the specified protocol. - - - - Two DnsResourceDataWellKnownService are equal iff their address, protocol and bitmap fields are equal. - - - - - Two DnsResourceDataWellKnownService are equal iff their address, protocol and bitmap fields are equal. - - - - - A hash code based on the address, protocol and bitmap fields. - - - - - The service address. - - - - - Specifies an IP protocol number. - - - - - Has one bit per port of the specified protocol. - - - - - RFC 1183. - 
-            +-----+----------+
-            | bit | 0-15     |
-            +-----+----------+
-            | 0   | subtype  |
-            +-----+----------+
-            | 16  | hostname |
-            | ... |          |
-            +-----+----------+
-
- - - - - Constructs an AFS database resource data from the given subtype and host name. - - The subtype of the resource data. - A host that has a server for the cell named by the owner name of the RR. - - - - The subtype of the resource data. - - - - - A host that has a server for the cell named by the owner name of the RR. - - - - - RFC 2874. - 
-            +-------------+----------------+-----------------+
-            | Prefix len. | Address suffix | Prefix name     |
-            | (1 octet)   | (0..16 octets) | (0..255 octets) |
-            +-------------+----------------+-----------------+
-
- - - - - The maximum value for the prefix length. - - - - - Constructs the resource data from the prefix length, address suffix and prefix name fields. - - Encoded as an eight-bit unsigned integer with value between 0 and 128 inclusive. - - An IPv6 address suffix, encoded in network order (high-order octet first). - There must be exactly enough octets in this field to contain a number of bits equal to 128 minus prefix length, - with 0 to 7 leading pad bits to make this field an integral number of octets. - Pad bits, if present, must be set to zero when loading a zone file and ignored (other than for SIG verification) on reception. - - The name of the prefix, encoded as a domain name. This name must not be compressed. - - - - Two A6 resource datas are equal iff their prefix length, address suffix and prefix name fields are equal. - - - - - Two A6 resource datas are equal iff their prefix length, address suffix and prefix name fields are equal. - - - - - The combined hash code of the prefix length, address suffix and prefix name fields. - - - - - Encoded as an eight-bit unsigned integer with value between 0 and 128 inclusive. - - - - - An IPv6 address suffix, encoded in network order (high-order octet first). - There must be exactly enough octets in this field to contain a number of bits equal to 128 minus prefix length, - with 0 to 7 leading pad bits to make this field an integral number of octets. - Pad bits, if present, must be set to zero when loading a zone file and ignored (other than for SIG verification) on reception. - - - - - The number of bytes the address suffix takes. - - - - - The name of the prefix, encoded as a domain name. - This name must not be compressed. - - - - - Represents an IPv6 gateway to which an IPsec tunnel may be created in order to reach the entity named by an IPsec resource record. - - - - - Creates a gateway using the given IPv6 address. - - - - - Two DnsGatewayIpV6 are equal if their IPv6 addresses are equal. - - - - - Two gateway representations are equal if they are of the same type and the value is the same. - - - - - The IPv6 address value of the gateway. - - - - - The gateway represnetation type. - - - - - The number of bytes the gateway represnetation takes. - - - - - RFCs 1035, 1996, 2136, 3425. - Specifies kind of query in this message. - This value is set by the originator of a query and copied into the response. - - - - - RFC 1035. - A standard query (QUERY). - - - - - RFC 3425. - An inverse query (IQUERY). - - - - - RFC 1035. - A server status request (STATUS). - - - - - RFC 1996. - - - - - RFC 2136. - - - - - Sack-Permitted Option (RFC 2018) - This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) - the SACK option once the connection has opened. - It MUST NOT be sent on non-SYN segments. - - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-
- - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates a selective ack permitted option. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - CC Option (RFC 1644). - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | Connection    |
-            |     | Count         |
-            +-----+---------------+
-
- - - This option may be sent in an initial SYN segment, and it may be sent in other segments if a CC or CC.NEW option - has been received for this incarnation of the connection. - Its SEG.CC value is the TCB.CCsend value from the sender's TCB. - - - - - - Create a connection count tcp option by a given connection count. - - - - - The default connection count is 0. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - This option identifies the U.S. classification level at which the datagram is to be protected - and the authorities whose protection rules apply to each datagram. - - - This option is used by end systems and intermediate systems of an internet to: - - Transmit from source to destination in a network standard representation the common security labels required by computer security models. - Validate the datagram as appropriate for transmission from the source and delivery to the destination. - - Ensure that the route taken by the datagram is protected to the level required by all protection authorities indicated on the datagram. - In order to provide this facility in a general Internet environment, interior and exterior gateway protocols must be augmented - to include security label information in support of routing control. - - - - - - The DoD Basic Security option must be copied on fragmentation. - This option appears at most once in a datagram. - Some security systems require this to be the first option if more than one option is carried in the IP header, - but this is not a generic requirement levied by this specification. - - - - The format of the DoD Basic Security option is as follows: - 
-             +------------+------------+------------+-------------//----------+
-             |  10000010  |  XXXXXXXX  |  SSSSSSSS  |  AAAAAAA[1]    AAAAAAA0 |
-             |            |            |            |         [0]             |
-             +------------+------------+------------+-------------//----------+
-               TYPE = 130     LENGTH   CLASSIFICATION         PROTECTION
-                                            LEVEL              AUTHORITY
-                                                                 FLAGS
-
- - - - - - The minimum number of bytes this option take. - - - - - The minimum number of bytes this option's value take. - - - - - Create the security option from the different security field values. - - - This field specifies the (U.S.) classification level at which the datagram must be protected. - The information in the datagram must be protected at this level. - - - This field identifies the National Access Programs or Special Access Programs - which specify protection rules for transmission and processing of the information contained in the datagram. - - - The number of bytes this option will take. - - - - - Create the security option with only classification level. - - - This field specifies the (U.S.) classification level at which the datagram must be protected. - The information in the datagram must be protected at this level. - - - - - Creates unclassified security option. - - - - - Two security options are equal iff they have the exact same field values. - - - - - Two security options are equal iff they have the exact same field values. - - - - - The hash code is the xor of the base class hash code - with the hash code of the combination of the classification level, protection authority and length. - - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - This field specifies the (U.S.) classification level at which the datagram must be protected. - The information in the datagram must be protected at this level. - - - - - This field identifies the National Access Programs or Special Access Programs - which specify protection rules for transmission and processing of the information contained in the datagram. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - Represents IPv4 layer. - - - - - - Creates an IPv4 layer with all zero values. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Finalizes the layer data in the buffer. - Used for fields that must be calculated according to the layer's payload (like checksum). - - The buffer to finalize the layer in. - The offset in the buffer the layer starts. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes after this layer. null if this is the last layer. - - - - True iff the two IPv4 layers have the same TypeOfService, Identification, Fragmentation, Ttl, Protocol, HeaderChecksum, Source, Destination and Options. - - - - - True iff the two IPv4 layers have the same TypeOfService, Identification, Fragmentation, Ttl, Protocol, HeaderChecksum, Source, Destination and Options. - - - - - Returns a hash code for the layer. - The hash code is a XOR of the TypeOfService and Identification combined and the hash codes of the layer length, data link, Fragmentation, Protocol, HeaderChecksum, Source, Destination, Options. - - - - - Contains the Source, Destination and Protocol. - - - - - Type of Service field. - - - - - The value of the IPv4 ID field. - - - - - The fragmentation information field. - - - - - The TTL field. - - - - - The IPv4 (next) protocol field. - null means that this value should be calculated according to the next layer. - - - - - The header checksum value. - null means that this value should be calculated to be correct according to the data. - - - - - The source address. - - - - - The current destination address. - This might not be the final destination when source routing options exist. - - - - - The final destination address. - Takes into account the current destination and source routing options if they exist. - - - - - The options field with all the parsed options if any exist. - - - - - The Ethernet Type the Ethernet layer should write when this layer is the Ethernet payload. - - - - - The protocol that should be written in the previous (IPv4) layer (in this case: IP). - - - - - The default MAC Address value when this layer is the Ethernet payload. - null means there is no default value. - - - - - The number of bytes this layer will take. - - - - - The kind of the data link of the layer. - Can be null if this is not the first layer in the packet. - - - - - RFC 2460. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Option Data                |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - Creates an unknown option according to the given type and data. - - The type of the IP option. - The data of the IP option. - - - - The data of the option. - - - - - RFC 2473. - 
-            +-----+----------------------------+--------+
-            | Bit | 0-7                        | 8-15   |
-            +-----+----------------------------+--------+
-            | 0   | Option Type                | 1      |
-            +-----+----------------------------+--------+
-            | 16  | Tunnel Encapsulation Limit |
-            +-----+----------------------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an option from the given tunnel encapsulation limit. - - How many further levels of encapsulation are permitted for the packet. - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - How many further levels of encapsulation are permitted for the packet. - - - - - RFC 6275. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Option Data                |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from type and data. - - The type of the option. - The data of the option. - - - - The data of the option. - - - - - RFC 5949. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-            | 32  | Interface Identifier       |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from interface identifier. - - - The Interface Identifier value used for the mobile node's IPv6 Link-local address in the P-AN. - - - - - The Interface Identifier value used for the mobile node's IPv6 Link-local address in the P-AN. - - - - - RFC 5213. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved    | HI           |
-            +-----+----------------------------+
-
- - - - - Creates an instance from the given handoff indicator. - - Specifies the type of handoff. - - - - Specifies the type of handoff. - - - - - RFC 5026. - 
-            +-----+-------------+---+----------+
-            | Bit | 0-7         | 8 | 9-15     |
-            +-----+-------------+---+----------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+---+----------+
-            | 16  | Status      | R | Reserved |
-            +-----+-------------+---+----------+
-            | 32  | MN identity (FQDN)         |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from status, remove and mobile node identity. - - - Indicating the result of the dynamic DNS update procedure. - This field must be set to 0 and ignored by the receiver when the DNS Update mobility option is included in a Binding Update message. - When the DNS Update mobility option is included in the Binding Acknowledgement message, - values of the Status field less than 128 indicate that the dynamic DNS update was performed successfully by the Home Agent. - Values greater than or equal to 128 indicate that the dynamic DNS update was not completed by the HA. - - - Whether the Mobile Node is requesting the HA to remove the DNS entry identified by the FQDN specified in this option and the HoA of the Mobile Node. - If false, the Mobile Node is requesting the HA to create or update a DNS entry with its HoA and the FQDN specified in the option. - - - The identity of the Mobile Node in FQDN format to be used by the Home Agent to send a Dynamic DNS update. - - - - - Indicating the result of the dynamic DNS update procedure. - This field must be set to 0 and ignored by the receiver when the DNS Update mobility option is included in a Binding Update message. - When the DNS Update mobility option is included in the Binding Acknowledgement message, - values of the Status field less than 128 indicate that the dynamic DNS update was performed successfully by the Home Agent. - Values greater than or equal to 128 indicate that the dynamic DNS update was not completed by the HA. - - - - - Whether the Mobile Node is requesting the HA to remove the DNS entry identified by the FQDN specified in this option and the HoA of the Mobile Node. - If false, the Mobile Node is requesting the HA to create or update a DNS entry with its HoA and the FQDN specified in the option. - - - - - The identity of the Mobile Node in FQDN format to be used by the Home Agent to send a Dynamic DNS update. - - - - - RFC 4866. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-
- - - - - Creates an instance. - - - - - RFCs 5648, 6089. - 
-            +-----+-------------+---+-----------+
-            | Bit | 0-7         | 8 | 9-15      |
-            +-----+-------------+---+-----------+
-            | 0   | Option Type | Opt Data Len  |
-            +-----+-------------+---------------+
-            | 16  |  Binding ID (BID)           |
-            +-----+-------------+---+-----------+
-            | 32  |  Status     | H | BID-PRI   |
-            +-----+-------------+---+-----------+
-            | 48  | IPv4 or IPv6                |
-            | ... | care-of address (CoA)       |
-            +-----+-----------------------------+
-
- - - - - The maximum value for Priority. - - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from binding id, status, simulatneous home and foreign binding, priority and IPv4 care of address. - - - The BID that is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. - The value of zero is reserved and should not be used. - - - When the Binding Identifier mobility option is included in a Binding Acknowledgement, - this field overwrites the Status field in the Binding Acknowledgement only for this BID. - If this field is set to zero, the receiver ignores this field and uses the registration status stored in the Binding Acknowledgement message. - The receiver must ignore this field if the Binding Identifier mobility option is not carried within either the Binding Acknowledgement - or the Care-of Test messages. - The possible status codes are the same as the status codes of the Binding Acknowledgement. - This Status field is also used to carry error information related to the care-of address test in the Care-of Test message. - - - Indicates that the mobile node registers multiple bindings to the home agent while it is attached to the home link. - This flag is valid only for a Binding Update sent to the home agent. - - - Places each BID to a relative priority (PRI) with other registered BIDs. - Value '0' is reserved and must not be used. - A lower number in this field indicates a higher priority, while BIDs with the same BID-PRI value have equal priority meaning that, - the BID used is an implementation issue. - This is consistent with current practice in packet classifiers. - - - The IPv4 care-of address for the corresponding BID. - - - - - Creates an instance from binding id, status, simulatneous home and foreign binding, priority and IPv6 care of address. - - - The BID that is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. - The value of zero is reserved and should not be used. - - - When the Binding Identifier mobility option is included in a Binding Acknowledgement, - this field overwrites the Status field in the Binding Acknowledgement only for this BID. - If this field is set to zero, the receiver ignores this field and uses the registration status stored in the Binding Acknowledgement message. - The receiver must ignore this field if the Binding Identifier mobility option is not carried within either the Binding Acknowledgement - or the Care-of Test messages. - The possible status codes are the same as the status codes of the Binding Acknowledgement. - This Status field is also used to carry error information related to the care-of address test in the Care-of Test message. - - - Indicates that the mobile node registers multiple bindings to the home agent while it is attached to the home link. - This flag is valid only for a Binding Update sent to the home agent. - - - Places each BID to a relative priority (PRI) with other registered BIDs. - Value '0' is reserved and must not be used. - A lower number in this field indicates a higher priority, while BIDs with the same BID-PRI value have equal priority meaning that, - the BID used is an implementation issue. - This is consistent with current practice in packet classifiers. - - - The IPv6 care-of address for the corresponding BID. - - - - - Creates an instance from binding id, status, simulatneous home and foreign binding and priority. - - - The BID that is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. - The value of zero is reserved and should not be used. - - - When the Binding Identifier mobility option is included in a Binding Acknowledgement, - this field overwrites the Status field in the Binding Acknowledgement only for this BID. - If this field is set to zero, the receiver ignores this field and uses the registration status stored in the Binding Acknowledgement message. - The receiver must ignore this field if the Binding Identifier mobility option is not carried within either the Binding Acknowledgement - or the Care-of Test messages. - The possible status codes are the same as the status codes of the Binding Acknowledgement. - This Status field is also used to carry error information related to the care-of address test in the Care-of Test message. - - - Indicates that the mobile node registers multiple bindings to the home agent while it is attached to the home link. - This flag is valid only for a Binding Update sent to the home agent. - - - Places each BID to a relative priority (PRI) with other registered BIDs. - Value '0' is reserved and must not be used. - A lower number in this field indicates a higher priority, while BIDs with the same BID-PRI value have equal priority meaning that, - the BID used is an implementation issue. - This is consistent with current practice in packet classifiers. - - - - - The BID that is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. - The value of zero is reserved and should not be used. - - - - - When the Binding Identifier mobility option is included in a Binding Acknowledgement, - this field overwrites the Status field in the Binding Acknowledgement only for this BID. - If this field is set to zero, the receiver ignores this field and uses the registration status stored in the Binding Acknowledgement message. - The receiver must ignore this field if the Binding Identifier mobility option is not carried within either the Binding Acknowledgement - or the Care-of Test messages. - The possible status codes are the same as the status codes of the Binding Acknowledgement. - This Status field is also used to carry error information related to the care-of address test in the Care-of Test message. - - - - - Indicates that the mobile node registers multiple bindings to the home agent while it is attached to the home link. - This flag is valid only for a Binding Update sent to the home agent. - - - - - Places each BID to a relative priority (PRI) with other registered BIDs. - Value '0' is reserved and must not be used. - A lower number in this field indicates a higher priority, while BIDs with the same BID-PRI value have equal priority meaning that, - the BID used is an implementation issue. - This is consistent with current practice in packet classifiers. - - - - - The IPv4 care-of address for the corresponding BID, or null if no IPv4 care-of address is stored. - - - - - The IPv6 care-of address for the corresponding BID, or null if no IPv6 care-of address is stored. - - - - - If a Binding Identifier mobility option is included in a Binding Update for the home registration, - either IPv4 or IPv6 care-of addresses for the corresponding BID can be stored in this field. - For the binding registration to correspondent nodes (i.e., route optimization), only IPv6 care-of addresses can be stored in this field. - If no address is specified in this field, returns null. - If the option is included in any messages other than a Binding Update, returns null. - - - - - RFC 6463. - 
-            +-----+-------------+------------------+
-            | Bit | 0-7         | 8-15             |
-            +-----+-------------+------------------+
-            | 0   | Option Type | Opt Data Len     |
-            +-----+-------------+------------------+
-            | 16  | Alternate IPv4 Care-of Address |
-            |     |                                |
-            +-----+--------------------------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an instance from the given alternative care of address. - - - An IPv4 equivalent of the RFC 6275 Alternate Care-of Address option for IPv6. - In the context of PMIPv6, its semantic is equivalent to the Alternate Care-of Address option for IPv6. - - - - - An IPv4 equivalent of the RFC 6275 Alternate Care-of Address option for IPv6. - In the context of PMIPv6, its semantic is equivalent to the Alternate Care-of Address option for IPv6. - - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+-----------------+-------+----+
-            | Bit | 0-7         | 8-15                    | 16-28           | 29-30 | 31 |
-            +-----+-------------+-------------------------+-----------------+-------+----+
-            | 0   | Next Header | Header Extension Length | Fragment Offset | Res   | M  |
-            +-----+-------------+-------------------------+-----------------+-------+----+
-            | 32  | Identification                                                       |
-            +-----+----------------------------------------------------------------------+
-
- - - - - The number of bytes the extension header data takes. - - - - - The maximum value for the fragment offset. - - - - - Creates an instance from next header, fragment offset, more fragments and identification. - - Identifies the type of header immediately following this extension header. - - The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part of the original packet. - - - True - more fragments. - False - last fragment. - - - For every packet that is to be fragmented, the source node generates an Identification value. - The Identification must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. - If a Routing header is present, the Destination Address of concern is that of the final destination. - - - - - The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part of the original packet. - - - - - True - more fragments. - False - last fragment. - - - - - For every packet that is to be fragmented, the source node generates an Identification value. - The Identification must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. - If a Routing header is present, the Destination Address of concern is that of the final destination. - - - - - Identifies the type of this extension header. - - - - - True iff the extension header parsing didn't encounter an issue. - - - - - RFC 2402. - 
-            +-----+-------------+-------------+----------+
-            | Bit | 0-7         | 8-15        | 16-31    |
-            +-----+-------------+-------------+----------+
-            | 0   | Next Header | Payload Len | RESERVED |
-            +-----+-------------+-------------+----------+
-            | 32  | Security Parameters Index (SPI)      |
-            +-----+--------------------------------------+
-            | 64  | Sequence Number Field                |
-            +-----+--------------------------------------+
-            | 96  | Authentication Data (variable)       |
-            | ... |                                      |
-            +-----+--------------------------------------+
-
- - - - - The minimum number of bytes the extension header takes. - - - - - Creates an instance from next header, security parameter index, sequence number and authenticator. - - - Identifies the type of header immediately following this extension header. - - - The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), - uniquely identifies the Security Association for this datagram. - The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; - a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. - It is ordinarily selected by the destination system upon establishment of an SA. - - - Contains a monotonically increasing counter value (sequence number). - It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. - Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender must always transmit this field, - but the receiver need not act upon it. - - - This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. - The field must be an integral multiple of 32 bits in length. - This field may include explicit padding. - This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). - All implementations must support such padding. - The authentication algorithm specification must specify the length of the ICV and the comparison rules and processing steps for validation. - - - - - True iff the given extension header is equal to this extension header. - - - - - True iff the given extension header is equal to this extension header. - - - - - Returns a hash code of the extension header. - - - - - - The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), - uniquely identifies the Security Association for this datagram. - The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; - a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. - It is ordinarily selected by the destination system upon establishment of an SA. - - - The SPI value of zero (0) is reserved for local, implementation-specific use and must not be sent on the wire. - For example, a key management implementation may use the zero SPI value to mean "No Security Association Exists" - during the period when the IPsec implementation has requested that its key management entity establish a new SA, - but the SA has not yet been established. - - - - - - - Contains a monotonically increasing counter value (sequence number). - It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. - Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender must always transmit this field, - but the receiver need not act upon it. - - - The sender's counter and the receiver's counter are initialized to 0 when an SA is established. - (The first packet sent using a given SA will have a Sequence Number of 1.) - If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. - Thus, the sender's counter and the receiver's counter must be reset (by establishing a new SA and thus a new key) - prior to the transmission of the 2^32nd packet on an SA. - - - - - - This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. - The field must be an integral multiple of 32 bits in length. - This field may include explicit padding. - This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). - All implementations must support such padding. - The authentication algorithm specification must specify the length of the ICV and the comparison rules and processing steps for validation. - - - - - Identifies the type of this extension header. - - - - - The number of bytes this extension header takes. - - - - - True iff the extension header parsing didn't encounter an issue. - - - - - RFC-ietf-netext-pmip-lr-10. - - - - - Success. - - - - - Localized Routing Not Allowed. - - - - - MN not attached. - - - - - RFC 950. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-            | 64  | Address Mask                  |
-            +-----+-------------------------------+
-
- - - - - The number of bytes this Datagram should take. - - - - - The number of bytes this ICMP payload should take. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - ICMP is valid if the datagram's length is OK, the checksum is correct and the code is in the expected range. - - - - - A 32-bit mask. - - - - - RFC 792. - 
-            +-----+------+------+-----------+
-            | Bit | 0-7  | 8-15 | 16-31     |
-            +-----+------+------+-----------+
-            | 0   | Type | Code | Checksum  |
-            +-----+------+------+-----------+
-            | 32  | unused                  |
-            +-----+-------------------------+
-            | 64  | Internet Header         |
-            |     | + 64 bits of            |
-            |     | Original Data Datagram  |
-            +-----+-------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - The minimum valid ICMP code for this type of ICMP datagram. - - - - - The maximum valid ICMP code for this type of ICMP datagram. - - - - - RFC 1256. - 
-            +-----+------+------+-----------+
-            | Bit | 0-7  | 8-15 | 16-31     |
-            +-----+------+------+-----------+
-            | 0   | Type | Code | Checksum  |
-            +-----+------+------+-----------+
-            | 32  | reserved                |
-            +-----+-------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - RFC 950. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-            | 64  | Address Mask                  |
-            +-----+-------------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - RFC 1701, RFC 1702, RFC 2637, RFC 2784. - 
-            +-----+---+---+---+---+---+-------+---+-------+---------+-------------------+
-            | Bit | 0 | 1 | 2 | 3 | 4 | 5-7   | 8 | 9-12  | 13-15   | 16-31             |
-            +-----+---+-----------+---+-------+---+-------+---------+-------------------+
-            | 0   | C | R | K | S | s | Recur | A | Flags | Version | Protocol Type     |
-            +-----+---+-----------+---+-------+---+-------+---------+-------------------+
-            | 32  | Checksum (optional)                             | Offset (optional) |
-            +-----+-------------------------------------------------+-------------------+
-            | 32  | Key (optional)                                                      |
-            +-----+---------------------------------------------------------------------+
-            | 32  | Sequence Number (optional)                                          |
-            +-----+---------------------------------------------------------------------+
-            | 32  | Acknowledgment Number (optional)                                    |
-            +-----+---------------------------------------------------------------------+
-            | 32  | Routing (optional)                                                  |
-            +-----+---------------------------------------------------------------------+
-
- - - - - The minimum number of bytes the GRE header can contain. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - A GRE Datagram is valid if its length is enough for the GRE header, its routing information is valid, - the bits for future use are set to 0, it has acknowledgment sequence number only if it's Enhanced GRE, - if it has checksum the checksum is correct and its payload is correct. - - true iff the datagram is valid. - - - - The length of the full GRE header on bytes. - - - - - Ethernet type (next protocol). - - - - - If the Checksum Present bit is set to 1, then the Checksum field is present and contains valid information. - If either the Checksum Present bit or the Routing Present bit are set, BOTH the Checksum and Offset fields are present in the GRE packet. - - - - - If the Routing Present bit is set to 1, then it indicates that the Offset and Routing fields are present and contain valid information. - If either the Checksum Present bit or the Routing Present bit are set, BOTH the Checksum and Offset fields are present in the GRE packet. - - - - - If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. - Otherwise, the Key field is not present in the GRE header. - - - - - If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. - Otherwise, the Sequence Number field is not present in the GRE header. - - - - - If the source route is incomplete, then the Strict Source Route bit is checked. - If the source route is a strict source route and the next IP destination or autonomous system is NOT an adjacent system, the packet MUST be dropped. - - - - - Recursion control contains a three bit unsigned integer which contains the number of additional encapsulations which are permissible. - This SHOULD default to zero. - - - - - Set to one (1) if packet contains Acknowledgment Number to be used for acknowledging previously transmitted data. - - - - - Must be set to zero (0). - - - - - The GRE Version Number. - - - - - The Protocol Type field contains the protocol type of the payload packet. - These Protocol Types are defined in [RFC1700] as "ETHER TYPES" and in [ETYPES]. - An implementation receiving a packet containing a Protocol Type which is not listed in [RFC1700] or [ETYPES] SHOULD discard the packet. - - - - - The Checksum field contains the IP (one's complement) checksum sum of the all the 16 bit words in the GRE header and the payload packet. - For purposes of computing the checksum, the value of the checksum field is zero. - This field is present only if the Checksum Present bit is set to one. - - - - - True iff the checksum value is correct according to the datagram data. - Valid only if the Checksum Present bit is set to one. - - - - - The offset field indicates the octet offset from the start of the Routing field to the first octet of the active Source Route Entry to be examined. - This field is present if the Routing Present or the Checksum Present bit is set to 1, and contains valid information only if the Routing Present bit is set to 1. - - - - - The index in the Routing collection of the active source route entry. - - - - - The active Source Route Entry to be examined. - Contains valid information only if the Routing Present bit is set to 1. - if the offset points to the end of the routing information, returns null. - - - - - The Key field contains a four octet number which was inserted by the encapsulator. - It may be used by the receiver to authenticate the source of the packet. - The Key field is only present if the Key Present field is set to 1. - - - - - (High 2 octets of Key) Size of the payload, not including the GRE header - - - - - (Low 2 octets of Key) Contains the Peer's Call ID for the session to which this packet belongs. - - - - - The Sequence Number field contains an unsigned 32 bit integer which is inserted by the encapsulator. - It may be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. - - - - - Contains the sequence number of the highest numbered GRE packet received by the sending peer for this user session. - Present if A bit (Bit 8) is one (1). - - - - - The Routing field is optional and is present only if the Routing Present bit is set to 1. - The Routing field is a list of Source Route Entries (SREs). - Each SRE has the form: - 
-            +-----+----------------+------------+------------+
-            | Bit | 0-15           | 16-23      | 24-31      |
-            +-----+----------------+------------+------------+
-            | 0   | Address Family | SRE Offset | SRE Length |
-            +-----+----------------+------------+------------+
-            | 32  | Routing Information ...                  |
-            +-----+------------------------------------------+
-
- The routing field is terminated with a "NULL" SRE containing an address family of type 0x0000 and a length of 0. - - - - - RFCs 4034, 5155. - - - - - RFC 1035. - 
-            +-------+---------+
-            | bit   | 0-31    |
-            +-------+---------+
-            | 0     | MNAME   |
-            | ...   |         |
-            +-------+---------+
-            | X     | RNAME   |
-            | ...   |         |
-            +-------+---------+
-            | Y     | SERIAL  |
-            +-------+---------+
-            | Y+32  | REFRESH |
-            +-------+---------+
-            | Y+64  | RETRY   |
-            +-------+---------+
-            | Y+96  | EXPIRE  |
-            +-------+---------+
-            | Y+128 | MINIMUM |
-            +-------+---------+
-
- - - - - Constructs an instance out of the main name server, responsible mailbox, serial, refresh, retry, expire and minimum TTL fields. - - The domain-name of the name server that was the original or primary source of data for this zone. - A domain-name which specifies the mailbox of the person responsible for this zone. - - The unsigned 32 bit version number of the original copy of the zone. - Zone transfers preserve this value. - This value wraps and should be compared using sequence space arithmetic. - - A 32 bit time interval before the zone should be refreshed. - A 32 bit time interval that should elapse before a failed refresh should be retried. - - A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative. - - The unsigned 32 bit minimum TTL field that should be exported with any RR from this zone. - - - - Two DnsResourceDataStartOfAuthority are equal iff their main name server, responsible mailbox, serial, refresh, retry, expire - and minimum TTL fields are equal. - - - - - Two DnsResourceDataStartOfAuthority are equal iff their main name server, responsible mailbox, serial, refresh, retry, expire - and minimum TTL fields are equal. - - - - - A hash code based on the main name server, responsible mailbox, serial, refresh, retry, expire and minimum TTL fields - - - - - The domain-name of the name server that was the original or primary source of data for this zone. - - - - - A domain-name which specifies the mailbox of the person responsible for this zone. - - - - - The unsigned 32 bit version number of the original copy of the zone. - Zone transfers preserve this value. - This value wraps and should be compared using sequence space arithmetic. - - - - - A 32 bit time interval before the zone should be refreshed. - - - - - A 32 bit time interval that should elapse before a failed refresh should be retried. - - - - - A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative. - - - - - The unsigned 32 bit minimum TTL field that should be exported with any RR from this zone. - - - - - RFC 4034. - 
-            +------------------+
-            | next domain name |
-            |                  |
-            +------------------+
-            | type bit map     |
-            |                  |
-            +------------------+
-
- - - - - Constructs an instance from the next domain name and types exist fields. - - - Contains the next owner name (in the canonical ordering of the zone) that has authoritative data or contains a delegation point NS RRset; - The value of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR). - This indicates that the owner name of the NSEC RR is the last name in the canonical ordering of the zone. - - Owner names of RRsets for which the given zone is not authoritative (such as glue records) must not be listed in the Next Domain Name - unless at least one authoritative RRset exists at the same owner name. - - Identifies the RRset types that exist at the NSEC RR's owner name. - - - - True iff the given dns type exists. - - - - - Two DnsResourceDataNextDomainSecure are equal iff their next domain name and types exist fields are equal. - - - - - Two DnsResourceDataNextDomainSecure are equal iff their next domain name and types exist fields are equal. - - - - - A hash code of the combined next domain name and types exist fields. - - - - - Contains the next owner name (in the canonical ordering of the zone) that has authoritative data or contains a delegation point NS RRset; - The value of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR). - This indicates that the owner name of the NSEC RR is the last name in the canonical ordering of the zone. - - Owner names of RRsets for which the given zone is not authoritative (such as glue records) must not be listed in the Next Domain Name - unless at least one authoritative RRset exists at the same owner name. - - - - - Identifies the RRset types that exist at the NSEC RR's owner name. - Ordered by the DnsType value. - - - - - RFCs 2915, 3403. - 
-            +-----+-------+------------+
-            | bit | 0-15  | 16-31      |
-            +-----+-------+------------+
-            | 0   | Order | Preference |
-            +-----+-------+------------+
-            | 32  | FLAGS              |
-            | ... |                    |
-            +-----+--------------------+
-            |     | SERVICES           |
-            | ... |                    |
-            +-----+--------------------+
-            |     | REGEXP             |
-            | ... |                    |
-            +-----+--------------------+
-            |     | REPLACEMENT        |
-            | ... |                    |
-            +-----+--------------------+
-
- - - - - Constructs an instance out of the order, preference, flags, services, regular expression and replacement fields. - - - A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed - in order to accurately represent the ordered list of Rules. - The ordering is from lowest to highest. - If two records have the same order value then they are considered to be the same rule and should be selected - based on the combination of the Preference values and Services offered. - - - Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm. - It specifies the order in which NAPTR records with equal Order values should be processed, low numbers being processed before high numbers. - This is similar to the preference field in an MX record, - and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. - A client may look at records with higher preference values if it has a good reason to do so such - as not supporting some protocol or service very well. - The important difference between Order and Preference is that once a match is found the client must not consider records - with a different Order but they may process records with the same Order but different Preferences. - The only exception to this is noted in the second important Note in the DDDS algorithm specification - concerning allowing clients to use more complex Service determination between steps 3 and 4 in the algorithm. - Preference is used to give communicate a higher quality of service to rules that are considered the same from an authority standpoint - but not from a simple load balancing standpoint. - - It is important to note that DNS contains several load balancing mechanisms and if load balancing among otherwise equal services - should be needed then methods such as SRV records or multiple A records should be utilized to accomplish load balancing. - - - Flags to control aspects of the rewriting and interpretation of the fields in the record. - Flags are single characters from the set A-Z and 0-9. - The case of the alphabetic characters is not significant. - The field can be empty. - - It is up to the Application specifying how it is using this Database to define the Flags in this field. - It must define which ones are terminal and which ones are not. - - - Specifies the Service Parameters applicable to this this delegation path. - It is up to the Application Specification to specify the values found in this field. - - - A substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. - See the DDDS Algorithm specification for the syntax of this field. - - As stated in the DDDS algorithm, The regular expressions must not be used in a cumulative fashion, - that is, they should only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite. - The latter is tempting in some applications but experience has shown such use to be extremely fault sensitive, very error prone, - and extremely difficult to debug. - - - The next domain-name to query for depending on the potential values found in the flags field. - This field is used when the regular expression is a simple replacement operation. - Any value in this field must be a fully qualified domain-name. - Name compression is not to be used for this field. - - This field and the Regexp field together make up the Substitution Expression in the DDDS Algorithm. - It is simply a historical optimization specifically for DNS compression that this field exists. - The fields are also mutually exclusive. - If a record is returned that has values for both fields then it is considered to be in error and SHOULD be either ignored or an error returned. - - - - - Two DnsResourceDataNamingAuthorityPointer are equal iff their order, preference, flags, services, regular expression and replacement fields - are equal. - - - - - Two DnsResourceDataNamingAuthorityPointer are equal iff their order, preference, flags, services, regular expression and replacement fields - are equal. - - - - - A hash code of the combination of the order, preference, flags, services, regular expression and replacement fields. - - - - - A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed - in order to accurately represent the ordered list of Rules. - The ordering is from lowest to highest. - If two records have the same order value then they are considered to be the same rule and should be selected - based on the combination of the Preference values and Services offered. - - - - - Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm. - It specifies the order in which NAPTR records with equal Order values should be processed, low numbers being processed before high numbers. - This is similar to the preference field in an MX record, - and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. - A client may look at records with higher preference values if it has a good reason to do so such - as not supporting some protocol or service very well. - The important difference between Order and Preference is that once a match is found the client must not consider records - with a different Order but they may process records with the same Order but different Preferences. - The only exception to this is noted in the second important Note in the DDDS algorithm specification - concerning allowing clients to use more complex Service determination between steps 3 and 4 in the algorithm. - Preference is used to give communicate a higher quality of service to rules that are considered the same from an authority standpoint - but not from a simple load balancing standpoint. - - It is important to note that DNS contains several load balancing mechanisms and if load balancing among otherwise equal services - should be needed then methods such as SRV records or multiple A records should be utilized to accomplish load balancing. - - - - - Flags to control aspects of the rewriting and interpretation of the fields in the record. - Flags are single characters from the set A-Z and 0-9. - The case of the alphabetic characters is not significant. - The field can be empty. - - It is up to the Application specifying how it is using this Database to define the Flags in this field. - It must define which ones are terminal and which ones are not. - - - - - Specifies the Service Parameters applicable to this this delegation path. - It is up to the Application Specification to specify the values found in this field. - - - - - A substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. - See the DDDS Algorithm specification for the syntax of this field. - - As stated in the DDDS algorithm, The regular expressions must not be used in a cumulative fashion, - that is, they should only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite. - The latter is tempting in some applications but experience has shown such use to be extremely fault sensitive, very error prone, - and extremely difficult to debug. - - - - - The next domain-name to query for depending on the potential values found in the flags field. - This field is used when the regular expression is a simple replacement operation. - Any value in this field must be a fully qualified domain-name. - Name compression is not to be used for this field. - - This field and the Regexp field together make up the Substitution Expression in the DDDS Algorithm. - It is simply a historical optimization specifically for DNS compression that this field exists. - The fields are also mutually exclusive. - If a record is returned that has values for both fields then it is considered to be in error and SHOULD be either ignored or an error returned. - - - - - RFC 5205. - 
-            +-----+------------+--------------+-----------+
-            | bit | 0-7        | 8-15         | 16-31     |
-            +-----+------------+--------------+-----------+
-            | 0   | HIT Length | PK Algorithm | PK Length |
-            +-----+------------+--------------+-----------+
-            | 32  | HIT                                   |
-            | ... |                                       |
-            +-----+---------------------------------------+
-            |     | Public Key                            |
-            | ... |                                       |
-            +-----+---------------------------------------+
-            |     | Rendezvous Servers                    |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Constructs an instance out of the host identity tag, public key algorithm, public key and rendezvous servers fields. - - Stored as a binary value in network byte order. - Identifies the public key's cryptographic algorithm and determines the format of the public key field. - Contains the algorithm-specific portion of the KEY RR RDATA. - - Indicates one or more domain names of rendezvous server(s). - Must not be compressed. - The rendezvous server(s) are listed in order of preference (i.e., first rendezvous server(s) are preferred), - defining an implicit order amongst rendezvous servers of a single RR. - When multiple HIP RRs are present at the same owner name, - this implicit order of rendezvous servers within an RR must not be used to infer a preference order between rendezvous servers stored in different RRs. - - - - - Two DnsResourceDataHostIdentityProtocol are equal iff their host identity tag, public key algorithm, public key and rendezvous servers fields - are equal. - - - - - Two DnsResourceDataHostIdentityProtocol are equal iff their host identity tag, public key algorithm, public key and rendezvous servers fields - are equal. - - - - - A hash code of the combination of the host identity tag, public key algorithm, public key and rendezvous servers fields. - - - - - Stored as a binary value in network byte order. - - - - - Identifies the public key's cryptographic algorithm and determines the format of the public key field. - - - - - Contains the algorithm-specific portion of the KEY RR RDATA. - - - - - Indicates one or more domain names of rendezvous server(s). - Must not be compressed. - The rendezvous server(s) are listed in order of preference (i.e., first rendezvous server(s) are preferred), - defining an implicit order amongst rendezvous servers of a single RR. - When multiple HIP RRs are present at the same owner name, - this implicit order of rendezvous servers within an RR must not be used to infer a preference order between rendezvous servers stored in different RRs. - - - - - RFC 3123. - 
-            0 Or more of:
-            +-----+--------+---+-----------+
-            | bit | 0-7    | 8 | 9-15      |
-            +-----+--------+---+-----------+
-            | 0   | ADDRESSFAMILY          |
-            +-----+--------+---+-----------+
-            | 16  | PREFIX | N | AFDLENGTH |
-            +-----+--------+---+-----------+
-            | 32  | AFDPART                |
-            | ... |                        |
-            +-----+------------------------+
-
- - - - - Constructs an instance from a sequence of DnsAddressPrefix. - - - - - Constructs an instance from a sequence of DnsAddressPrefix. - - - - - Two DnsResourceDataAddressPrefixList are equal iff their items are equal and in the same order. - - - - - Two DnsResourceDataAddressPrefixList are equal iff their items are equal and in the same order. - - - - - A hash code based on the items. - - - - - The DnsAddressPrefix items in the list. - - - - - The number of bytes the resource data takes. - - - - - The option code for a DNS option. - - - - - No code defined. - Should not be used. - - - - - http://files.dns-sd.org/draft-sekar-dns-llq.txt. - LLQ. - - - - - http://files.dns-sd.org/draft-sekar-dns-ul.txt. - UL. - - - - - RFC 5001. - NSID. - - - - - A gateway representation that represents that no gateway is present. - - - - - Two DnsGatewayNone are always equal. - - - - - Two gateway representations are equal if they are of the same type and the value is the same. - - - - - The gateway represnetation type. - - - - - The number of bytes the gateway represnetation takes. - - - - - RFC 1035, 2136. - Other sources: Dyer 1987, Moon 1981. - CLASS fields appear in resource records. - - - - - Represents no class. - - - - - RFC 1035. - IN - Internet. - - - - - Moon 1981 1035. - The CHAOS class. - - - - - Dyer 87. - HS - Hesiod. - - - - - RFC 2136. - None. - Query class. - - - - - RFC 1035. - *. - Any class. - Query class. - - - - - TCP POC-service-profile Option (RFC 1693). - - 
-            +-----+------------+----------+--------+
-            | Bit | 0          | 1        | 2-7    |
-            +-----+------------+----------+--------+
-            | 0   | Kind                           |
-            +-----+--------------------------------+
-            | 8   | Length                         |
-            +-----+------------+----------+--------+
-            | 16  | Start_flag | End_flag | Filler |
-            +-----+------------+----------+--------+
-
- - - Contains two 1-bit flags necessary to handle the case where the service profile does not fit in a single TCP segment. - The "Start_flag" indicates that the information in the data section represents the beginning of the service profile - and the "End_flag" represents the converse. - For service profiles which fit completely in a single segment, both flags will be set to 1. - Otherwise, the Start_flag is set in the initial segment and the End_flag in the final segment - allowing the peer entity to reconstrcut the entire service profile (using the normal sequence numbers in the segment header). - The "Filler" field serves merely to complete the third byte of the option. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates the option using the given isStart and isEnd values. - - - - - The default is for service profiles which fit completely in a single segment. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - Indicates that the information in the data section represents the beginning of the service profile. - - - - - Indicates that the information in the data section represents the end of the service profile. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - TCP control bits format - 
-            +-----+-----+----+-----+-----+-----+-----+-----+-----+-----+-----+
-            | Bit | 0-6 | 7  | 8   | 9   | 10  | 11  | 12  | 13  | 14  | 15  |
-            +-----+-----+----+-----+-----+-----+-----+-----+-----+-----+-----+
-            | 0   |     | NS | CWR | ECE | URG | ACK | PSH | RST | SYN | FIN |
-            +-----+-----+----+-----+-----+-----+-----+-----+-----+-----+-----+
-
- - - - - No control bits are turned on. - - - - - No more data from sender. - - - - - Synchronize sequence numbers. - - - - - Reset the connection. - - - - - Push Function. - - - - - Acknowledgment field significant. - - - - - Urgent Pointer field significant. - - - - - RFC 3168. - - - - - RFC 3168. - - - - - RFC 3540. - - - - - Indicates the next level IPv4 protocol used in the pyaload of the IPv4 datagram. - - - - - IPv6 Hop-by-Hop Option RFC 2460 - - - - - Internet Control Message Protocol RFC 792 - - - - - Internet Group Management Protocol RFC 1112 - - - - - Gateway-to-Gateway Protocol RFC 823 - - - - - IP in IP (encapsulation) RFC 2003 - - - - - Internet Stream Protocol RFC 1190, RFC 1819 - - - - - Transmission Control Protocol RFC 793 - - - - - CBT - - - - - Exterior Gateway Protocol RFC 888 - - - - - Interior Gateway Protocol (any private interior gateway (used by Cisco for their IGRP)) - - - - - BBN RCC Monitoring - - - - - Network Voice Protocol RFC 741 - - - - - Xerox PUP - - - - - ARGUS - - - - - EMCON - - - - - Cross Net Debugger IEN 158 - - - - - Chaos - - - - - User Datagram Protocol RFC 768 - - - - - Multiplexing IEN 90 - - - - - DCN Measurement Subsystems - - - - - Host Monitoring Protocol RFC 869 - - - - - Packet Radio Measurement - - - - - XEROX NS IDP - - - - - Trunk-1 - - - - - Trunk-2 - - - - - Leaf-1 - - - - - Leaf-2 - - - - - Reliable Datagram Protocol RFC 908 - - - - - Internet Reliable Transaction Protocol RFC 938 - - - - - ISO Transport Protocol Class 4 RFC 905 - - - - - Bulk Data Transfer Protocol RFC 998 - - - - - MFE Network Services Protocol - - - - - MERIT Internodal Protocol - - - - - Datagram Congestion Control Protocol RFC 4340 - - - - - Third Party Connect Protocol - - - - - Inter-Domain Policy Routing Protocol RFC 1479 - - - - - Xpress Transport Protocol - - - - - Datagram Delivery Protocol - - - - - IDPR Control Message Transport Protocol - - - - - TP++ Transport Protocol - - - - - IL Transport Protocol - - - - - RFC 2460. - IPv6. - - - - - Source Demand Routing Protocol. - - - - - RFC 2460. - Routing Header for IPv6. - - - - - RFC 2460. - Fragment Header for IPv6. - - - - - Inter-Domain Routing Protocol - - - - - Resource Reservation Protocol - - - - - Generic Routing Encapsulation - - - - - Mobile Host Routing Protocol - - - - - BNA - - - - - ESP. Encapsulating Security Payload RFC 2406. - - - - - Authentication Header RFC 2402 - - - - - Integrated Net Layer Security Protocol TUBA - - - - - IP with Encryption. - - - - - NBMA Address Resolution Protocol RFC 1735 - - - - - IP Mobility (Min Encap) RFC 2004 - - - - - Transport Layer Security Protocol (using Kryptonet key management) - - - - - Simple Key-Management for Internet Protocol RFC 2356 - - - - - ICMP for IPv6 RFC 2460 - - - - - No Next Header for IPv6 RFC 2460 - - - - - Destination Options for IPv6 RFC 2460 - - - - - Any host internal protocol - - - - - CFTP - - - - - Any local network - - - - - SATNET and Backroom EXPAK - - - - - Kryptolan - - - - - MIT Remote Virtual Disk Protocol - - - - - Internet Pluribus Packet Core - - - - - Any distributed file system - - - - - SATNET Monitoring - - - - - VISA Protocol - - - - - Internet Packet Core Utility - - - - - Computer Protocol Network Executive - - - - - Computer Protocol Heart Beat - - - - - Wang Span Network - - - - - Packet Video Protocol - - - - - Backroom SATNET Monitoring - - - - - SUN ND PROTOCOL-Temporary - - - - - WIDEBAND Monitoring - - - - - WIDEBAND EXPAK - - - - - International Organization for Standardization Internet Protocol - - - - - Versatile Message Transaction Protocol RFC 1045 - - - - - Secure Versatile Message Transaction Protocol RFC 1045 - - - - - VINES - - - - - TTP - - - - - NSFNET-IGP - - - - - Dissimilar Gateway Protocol - - - - - TCF - - - - - Enhanced Interior Gateway Routing Protocol - - - - - Open Shortest Path First RFC 1583 - - - - - Sprite RPC Protocol - - - - - Locus Address Resolution Protocol - - - - - Multicast Transport Protocol - - - - - AX.25 - - - - - IP-within-IP Encapsulation Protocol - - - - - Mobile Internetworking Control Protocol - - - - - Semaphore Communications Sec. Pro - - - - - Ethernet-within-IP Encapsulation RFC 3378 - - - - - Encapsulation Header RFC 1241 - - - - - Any private encryption scheme - - - - - GMTP - - - - - Ipsilon Flow Management Protocol - - - - - PNNI over IP - - - - - Protocol Independent Multicast - - - - - ARIS - - - - - SCPS (Space Communications Protocol Standards) - - - - - QNX - - - - - Active Networks - - - - - IP Payload Compression Protocol RFC 3173 - - - - - Sitara Networks Protocol - - - - - Compaq Peer Protocol - - - - - IPX in IP - - - - - Virtual Router Redundancy Protocol, Common Address Redundancy Protocol (not IANA assigned) VRRP:RFC 3768 - - - - - PGM Reliable Transport Protocol RFC 3208 - - - - - Any 0-hop protocol - - - - - Layer Two Tunneling Protocol - - - - - D-II Data Exchange (DDX) - - - - - Interactive Agent Transfer Protocol - - - - - Schedule Transfer Protocol - - - - - SpectraLink Radio Protocol - - - - - UTI - - - - - Simple Message Protocol - - - - - SM - - - - - Performance Transparency Protocol - - - - - IS-IS over IPv4 - - - - - - - - - - Combat Radio Transport Protocol - - - - - Combat Radio User Datagram - - - - - - - - - - - - - - - Secure Packet Shield - - - - - Private IP Encapsulation within IP Expired I-D draft-petri-mobileip-pipe-00.txt - - - - - Stream Control Transmission Protocol - - - - - Fibre Channel - - - - - RSVP-E2E-IGNORE RFC 3175 - - - - - Mobility Header RFC 3775 - - - - - UDP Lite RFC 3828 - - - - - MPLS-in-IP RFC 4023 - - - - - MANET Protocols I-D draft-ietf-manet-iana-07.txt - - - - - Host Identity Protocol RFC 5201 - - - - - Shim6. RFC 5533. - - - - - Represents IPv4 Options. - The options may appear or not in datagrams. - They must be implemented by all IP modules (host and gateways). - What is optional is their transmission in any particular datagram, not their implementation. - - - - - The maximum number of bytes the options may take. - - - - - Creates options from a list of options. - - The list of options. - - - - Creates options from a list of options. - - The list of options. - - - - No options instance. - - - - - The Router Alert option has the semantic "routers should examine this packet more closely". - By including the Router Alert option in the IP header of its protocol message, - RSVP can cause the message to be intercepted while causing little or no performance - penalty on the forwarding of normal data packets. - - - Routers that support option processing in the fast path already demultiplex processing based on the option type field. - If all option types are supported in the fast path, then the addition of another option type to process is unlikely to impact performance. - If some option types are not supported in the fast path, - this new option type will be unrecognized and cause packets carrying it to be kicked out into the slow path, - so no change to the fast path is necessary, and no performance penalty will be incurred for regular data packets. - - - - Routers that do not support option processing in the fast path will cause packets carrying this new option - to be forwarded through the slow path, so no change to the fast path is necessary and no performance penalty - will be incurred for regular data packets. - - - - The Router Alert option has the following format: - 
-            +--------+--------+--------+--------+
-            |10010100|00000100|  2 octet value  |
-            +--------+--------+--------+--------+
-
- - - - - - The number of bytes this option take. - - - - - The number of bytes this option's value take. - - - - - Create the option according to the given value. - - - - - Creates a 0 value router alert option - - - - - Two stream identifier options are equal if they have the same identifier. - - - - - Two stream identifier options are equal if they have the same identifier. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The value of the alert. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - RFC 4782. - The Quick-Start Option for IPv4 - - The Quick-Start Request for IPv4 is defined as follows: - 
-            +--------+----------+-------+---------+-------+-------+
-            | 0-7    | 8-15     | 16-19 | 20-23   | 24-29 | 30-31 |
-            +--------+----------+-------+---------+-------+-------+
-            | Option | Length=8 | Func. | Rate    | QS TTL        |
-            |        |          | 0000  | Request |               |
-            +--------+----------+-------+---------+-------+-------+
-            | QS Nonce                                    | R     |
-            +---------------------------------------------+-------+
-
- - - - - - The number of bytes this option take. - - - - - The number of bytes this option's value take. - - - - - The maximum value for the rate field. - - - - - Create a quick start option according to the given field values. - - The function of this quick start option. - Either the rate requested or reported. - - The Quick-Start TTL (QS TTL) field. - The sender MUST set the QS TTL field to a random value. - Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. - The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. - - - The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. - - - - - Creates a request with 0 fields. - - - - - Two quick start options are equal iff they have the exact same field values. - - - - - Two trace route options are equal iff they have the exact same field values. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The function of this quick start option. - - - - - If function is request then this field is the rate request. - If function is report then this field is the rate report. - - - - - The rate translated to KBPS. - - - - - The Quick-Start TTL (QS TTL) field. - The sender MUST set the QS TTL field to a random value. - Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. - The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option. - - - For a Rate Request, the transport sender MUST calculate and store the TTL Diff, - the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows: - TTL Diff = ( IP TTL - QS TTL ) mod 256 - - - - - - The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. - This is particularly important if the receiver knows the original value of the Rate Request - (e.g., when the sender always requests the same value, and the receiver has a long history of communication with that sender). - Without the QS Nonce, there is nothing to prevent the receiver from reporting back to the sender a Rate Request of K, - when the received Rate Request was, in fact, less than K. - - - The format for the 30-bit QS Nonce. - - - Bits - Purpose - - Bits 0-1Rate 15 -> Rate 14 - Bits 2-3Rate 14 -> Rate 13 - Bits 4-5Rate 13 -> Rate 12 - Bits 6-7Rate 12 -> Rate 11 - Bits 8-9Rate 11 -> Rate 10 - Bits 10-11Rate 10 -> Rate 9 - Bits 12-13Rate 9 -> Rate 8 - Bits 14-15Rate 8 -> Rate 7 - Bits 16-17Rate 7 -> Rate 6 - Bits 18-19Rate 6 -> Rate 5 - Bits 20-21Rate 5 -> Rate 4 - Bits 22-23Rate 4 -> Rate 3 - Bits 24-25Rate 3 -> Rate 2 - Bits 26-27Rate 2 -> Rate 1 - Bits 28-29Rate 1 -> Rate 0 - - - - - The transport sender MUST initialize the QS Nonce to a random value. - If the router reduces the Rate Request from rate K to rate K-1, - then the router MUST set the field in the QS Nonce for "Rate K -> Rate K-1" to a new random value. - Similarly, if the router reduces the Rate Request by N steps, - the router MUST set the 2N bits in the relevant fields in the QS Nonce to a new random value. - The receiver MUST report the QS Nonce back to the sender. - - - - If the Rate Request was not decremented in the network, then the QS Nonce should have its original value. - Similarly, if the Rate Request was decremented by N steps in the network, - and the receiver reports back a Rate Request of K, then the last 2K bits of the QS Nonce should have their original value. - - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - RFC 791. - Represents an IPv4 datagram. - 
-            +-----+---------+-----+-----------------+-------+-----------------+
-            | Bit | 0-3     | 4-7 | 8-15            | 16-18 | 19-31           |
-            +-----+---------+-----+-----------------+-------+-----------------+
-            | 0   | Version | IHL | Type of Service | Total Length            |
-            +-----+---------+-----+-----------------+-------+-----------------+
-            | 32  | Identification                  | Flags | Fragment Offset |
-            +-----+---------------+-----------------+-------+-----------------+
-            | 64  | Time to Live  | Protocol        | Header Checksum         |
-            +-----+---------------+-----------------+-------------------------+
-            | 96  | Source Address                                            |
-            +-----+-----------------------------------------------------------+
-            | 128 | Destination Address                                       |
-            +-----+-----------------------------------------------------------+
-            | 160 | Options with padding                                      |
-            +-----+-----------------------------------------------------------+
-            | 160 | Data                                                      |
-            | to  |                                                           |
-            | 360 |                                                           |
-            +-----+-----------------------------------------------------------+
-
- - - - - The minimum length of the header in bytes. - - - - - The maximum length of the header in bytes. - - - - - The version (4). - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - An IPv4 datagram is valid if its length is big enough for the header, the header checksum is correct and the payload is valid. - - - - - Calculates the Transport checksum field value. - - The calculated checksum value. - - - - The header length in bytes. - - - - - The real number of bytes in the header (different than HeaderLength when the datagram is too small). - - - - - Type of Service field. - - - - - The length of the entire datagram as stated in the total length field. - - - - - The value of the IPv4 ID field. - - - - - The fragmentation information field. - - - - - The TTL field. - - - - - The IPv4 (next) protocol field. - - - - - The header checksum value. - - - - - True iff the header checksum value is correct according to the header. - - - - - The source address. - - - - - The current destination address. - This might not be the final destination when source routing options exist. - - - - - The final destination address. - Takes into account the current destination and source routing options if they exist. - - - - - The options field with all the parsed options if any exist. - - - - - The type of an IPv6 option. - - - - - RFC 2460. - - - - - RFC 2460. - - - - - RFC 2675. - - - - - RFC 2473. - - - - - RFC 2711. - - - - - RFC 4782, Errata 2034. - - - - - RFC 5570. - - - - - RFC 6621. - - - - - RFC 6275. - - - - - Charles Lynn. - - - - - RFC 6553. - - - - - RFC irtf-rrg-ilnp-noncev6-06. - - - - - RFC ietf-6man-lineid-08. - - - - - RFC 6621. - Simplified Multicast Forwarding Duplicate Packet Detection. - Sequence-based approach. - IPv6 tagger ID. - 
-            +-----+---+-------+--------+
-            | Bit | 0 | 1-3   | 4-7    |
-            +-----+---+-------+--------+
-            | 0   | Option Type        |
-            +-----+--------------------+
-            | 8   | Opt Data Len       |
-            +-----+---+-------+--------+
-            | 16  | 0 | TidTy | TidLen |
-            +-----+---+-------+--------+
-            | 24  | TaggerId           |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            +-----+--------------------+
-            | 152 | Identifier         |
-            | ... |                    |
-            +-----+--------------------+
-
- - - - - RFC 6621. - Simplified Multicast Forwarding Duplicate Packet Detection. - Sequence-based approach. - 
-            +-----+---+-------+--------+
-            | Bit | 0 | 1-3   | 4-7    |
-            +-----+---+-------+--------+
-            | 0   | Option Type        |
-            +-----+--------------------+
-            | 8   | Opt Data Len       |
-            +-----+---+-------+--------+
-            | 16  | 0 | TidTy | TidLen |
-            +-----+---+-------+--------+
-            | 24  | TaggerId           |
-            | ... |                    |
-            +-----+--------------------+
-            |     | Identifier         |
-            | ... |                    |
-            +-----+--------------------+
-
- - - - - RFC 6621. - Simplified Multicast Forwarding Duplicate Packet Detection. - 
-            +-----+---+------------------+
-            | Bit | 0 | 1-7              |
-            +-----+---+------------------+
-            | 0   | Option Type          |
-            +-----+----------------------+
-            | 8   | Opt Data Len         |
-            +-----+---+------------------+
-            | 16  | H | DPD Identifier   |
-            +-----+---+ Option Fields    |
-            | ... | or Hash Assist Value |
-            +-----+----------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Identifying DPD marking type. - 0 == sequence-based approach with optional TaggerId and a tuple-based sequence number. See . - 1 == indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions. - - - - - The length of the Tagger Id. - - - - - DPD packet Identifier. - When the TaggerId field is present, the Identifier can be considered a unique packet identifier - in the context of the TaggerId:srcAddr:dstAddr tuple. - When the TaggerId field is not present, then it is assumed that the source applied the SMF_DPD option - and the Identifier can be considered unique in the context of the IPv6 packet header srcAddr:dstAddr tuple. - - - - - Identifying DPD marking type. - 0 == sequence-based approach with optional TaggerId and a tuple-based sequence number. See . - 1 == indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions. - - - - - Indicating the presence and type of the optional TaggerId field. - - - - - Creates an instance from tagger id and identifier. - - - Used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. - - - DPD packet Identifier. - When the TaggerId field is present, the Identifier can be considered a unique packet identifier - in the context of the TaggerId:srcAddr:dstAddr tuple. - When the TaggerId field is not present, then it is assumed that the source applied the SMF_DPD option - and the Identifier can be considered unique in the context of the IPv6 packet header srcAddr:dstAddr tuple. - - - - - Used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. - - - - - The length of the Tagger Id. - - - - - Indicating the presence and type of the optional TaggerId field. - - - - - RFC 6621. - Simplified Multicast Forwarding Duplicate Packet Detection. - Sequence-based approach. - Default Tagger ID. - 
-            +-----+---+-------+--------+
-            | Bit | 0 | 1-3   | 4-7    |
-            +-----+---+-------+--------+
-            | 0   | Option Type        |
-            +-----+--------------------+
-            | 8   | Opt Data Len       |
-            +-----+---+-------+--------+
-            | 16  | 0 | TidTy | TidLen |
-            +-----+---+-------+--------+
-            | 24  | TaggerId           |
-            | ... |                    |
-            +-----+--------------------+
-            |     | Identifier         |
-            | ... |                    |
-            +-----+--------------------+
-
- - - - - Creates an instance from tagger id and identifier. - - - Used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. - Non-specific context. - - - DPD packet Identifier. - When the TaggerId field is present, the Identifier can be considered a unique packet identifier - in the context of the TaggerId:srcAddr:dstAddr tuple. - When the TaggerId field is not present, then it is assumed that the source applied the SMF_DPD option - and the Identifier can be considered unique in the context of the IPv6 packet header srcAddr:dstAddr tuple. - - - - - Used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. - Non-specific context. - - - - - The length of the Tagger Id. - - - - - Indicating the presence and type of the optional TaggerId field. - - - - - RFC 5213. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-            | 32  | Link-layer Identifier      |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from link layer identifier. - - - Contains the mobile node's link-layer identifier. - - - - - Contains the mobile node's link-layer identifier. - - - - - 
-            +-----+--------------+--------------+
-            | Bit | 0-7          | 8-15         |
-            +-----+--------------+--------------+
-            | 0   | Option Type  | Opt Data Len |
-            +-----+--------------+--------------+
-            | 16  | Address                     |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            +-----+-----------------------------+
-
- - - - - The number of bytes the option data takes. - - - - - RFC 5844. - 
-            +-----+-------------+----------+-------+
-            | Bit | 0-7         | 8-13     | 14-15 |
-            +-----+-------------+----------+-------+
-            | 0   | Option Type | Opt Data Len     |
-            +-----+-------------+----------+-------+
-            | 16  | Status      | Pref-len | Res   |
-            +-----+-------------+----------+-------+
-            | 32  | IPv4 home address              |
-            |     |                                |
-            +-----+--------------------------------+
-
- - - - - The maximum value for Prefix Length. - - - - - The number of bytes this option data takes. - - - - - Creates an instance from status, Prefix Length and Home Address. - - - Indicates success or failure for the IPv4 home address assignment. - Values from 0 to 127 indicate success. - Higher values (128 to 255) indicate failure. - - - Used to carry the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option. - - - Used to carry the IPv4 home address assigned to the mobile node. - - - - - Indicates success or failure for the IPv4 home address assignment. - Values from 0 to 127 indicate success. - Higher values (128 to 255) indicate failure. - - - - - Used to carry the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option. - - - - - Used to carry the IPv4 home address assigned to the mobile node. - - - - - RFC 5844. - 
-            +-----+-------------+------+-------+
-            | Bit | 0-7         | 8-14 | 15    |
-            +-----+-------------+------+-------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+------+-------+
-            | 16  | Reserved           | S     |
-            +-----+--------------------+-------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from IsServer. - - - Specifies the DHCP support mode. - This flag indicates whether the mobile access gateway should function as a DHCP Server or a DHCP Relay for the attached mobile node. - If false, the mobile access gateway should act as a DHCP Relay and if true, it should act as a DHCP Server. - - - - - Specifies the DHCP support mode. - This flag indicates whether the mobile access gateway should function as a DHCP Server or a DHCP Relay for the attached mobile node. - If false, the mobile access gateway should act as a DHCP Relay and if true, it should act as a DHCP Server. - - - - - RFC 5845. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Reserved                   |
-            +-----+----------------------------+
-            | 32  | GRE Key Identifier         |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from GRE key identifier. - - - Contains the downlink or the uplink GRE key. - This field is present in the GRE Key option only if the GRE keys are being exchanged using the Proxy Binding Update and Proxy Binding - Acknowledgement messages. - - - - - Contains the downlink or the uplink GRE key. - This field is present in the GRE Key option only if the GRE keys are being exchanged using the Proxy Binding Update and Proxy Binding - Acknowledgement messages. - - - - - RFC 5213. - - - - - Invalid value. - - - - - Attachment over a new interface. - - - - - Handoff between two different interfaces of the mobile node. - - - - - Handoff between mobile access gateways for the same interface. - - - - - Handoff state unknown. - - - - - Handoff state not changed (Re-registration). - - - - - RFC 5026. - - - - - DNS update performed. - - - - - Reason unspecified. - - - - - Administratively prohibited. - - - - - DNS update failed. - - - - - RFC 6757. - 
-            +-----+---+---------------------------------+
-            | Bit | 0 | 6-7                             |
-            +-----+---+---------------------------------+
-            | 0   | ANI Type                            |
-            +-----+-------------------------------------+
-            | 8   | ANI Length                          |
-            +-----+---+---------------------------------+
-            | 16  | E | Reserved                        | 
-            +-----+---+---------------------------------+
-            | 24  | Net-Name Len                        |
-            +-----+-------------------------------------+
-            | 32  | Network Name (e.g., SSID or PLMNID) |
-            | ... |                                     |
-            +-----+-------------------------------------+
-            |     | AP-Name Len                         |       
-            +-----+-------------------------------------+
-            |     | Access-Point Name                   |
-            | ... |                                     |
-            +-----+-------------------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from is network name UTF8, network name and access point name. - - - Indicates whether the Network Name is encoded in UTF-8. - If true, then the Network Name is encoded using UTF-8. - If false, this indicates that the encoding is undefined and is determined by out-of-band mechanisms. - - - The name of the access network to which the mobile node is attached. - The type of the Network Name is dependent on the access technology to which the mobile node is attached. - If it is 802.11 access, the Network Name must be the SSID of the network. - If the access network is 3GPP access, the Network Name is the PLMN Identifier of the network. - If the access network is 3GPP2 access, the Network Name is the Access Network Identifier. - - When encoding the PLMN Identifier, both the Mobile Network Code (MNC) and Mobile Country Code (MCC) must be 3 digits. - If the MNC in use only has 2 digits, then it must be preceded with a '0'. - Encoding must be UTF-8. - - - The name of the access point (physical device name) to which the mobile node is attached. - This is the identifier that uniquely identifies the access point. - While Network Name (e.g., SSID) identifies the operator's access network, - Access-Point Name identifies a specific network device in the network to which the mobile node is attached. - In some deployments, the Access-Point Name can be set to the Media Access Control (MAC) address of the device or some unique identifier - that can be used by the policy systems in the operator network to unambiguously identify the device. - The string is carried in UTF-8 representation. - - - - - Indicates whether the Network Name is encoded in UTF-8. - If true, then the Network Name is encoded using UTF-8. - If false, this indicates that the encoding is undefined and is determined by out-of-band mechanisms. - - - - - The name of the access network to which the mobile node is attached. - The type of the Network Name is dependent on the access technology to which the mobile node is attached. - If it is 802.11 access, the Network Name must be the SSID of the network. - If the access network is 3GPP access, the Network Name is the PLMN Identifier of the network. - If the access network is 3GPP2 access, the Network Name is the Access Network Identifier. - - When encoding the PLMN Identifier, both the Mobile Network Code (MNC) and Mobile Country Code (MCC) must be 3 digits. - If the MNC in use only has 2 digits, then it must be preceded with a '0'. - Encoding must be UTF-8. - - - - - The name of the access point (physical device name) to which the mobile node is attached. - This is the identifier that uniquely identifies the access point. - While Network Name (e.g., SSID) identifies the operator's access network, - Access-Point Name identifies a specific network device in the network to which the mobile node is attached. - In some deployments, the Access-Point Name can be set to the Media Access Control (MAC) address of the device or some unique identifier - that can be used by the policy systems in the operator network to unambiguously identify the device. - The string is carried in UTF-8 representation. - - - - - Values of the Status field less than 128 indicate that the Binding Revocation Indication was processed successfully by the responder. - Values greater than or equal to 128 indicate that the Binding Revocation Indication was rejected by the responder. - - - - - Success. - - - - - Partial success. - - - - - Binding Does NOT Exist. - - - - - IPv4 Home Address Option Required. - - - - - Global Revocation NOT Authorized. - - - - - Revoked Mobile Nodes Identity Required. - - - - - Revocation Failed - MN is Attached. - - - - - Revocation Trigger NOT Supported. - - - - - Revocation Function NOT Supported. - - - - - Proxy Binding Revocation NOT Supported. - - - - - RFC 5847. - 
-            +-----+----------------+------+----+-------------+
-            | Bit | 0-7            | 8-13 | 14 | 15          |
-            +-----+----------------+------+----+-------------+
-            | 0   | Next Header    | Header Extension Length |
-            +-----+----------------+-------------------------+
-            | 16  | MH Type        | Reserved                |
-            +-----+----------------+-------------------------+
-            | 32  | Checksum                                 |
-            +-----+-----------------------+----+-------------+
-            | 48  | Reserved              | U  | R           |
-            +-----+-----------------------+----+-------------+
-            | 64  | Sequence Number                          |
-            |     |                                          |
-            +-----+------------------------------------------+
-            | 96  | Mobility Options                         |
-            | ... |                                          |
-            +-----+------------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, is unsolicited heartbeat response, is response, sequence number and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Set to true in Unsolicited Heartbeat Response. - - Indicates whether the message is a request or a response. - When it's set to false, it indicates that the Heartbeat message is a request. - When it's set to true, it indicates that the Heartbeat message is a response. - - Sequence number used for matching the request to the reply. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Set to true in Unsolicited Heartbeat Response. - - - - - Indicates whether the message is a request or a response. - When it's set to false, it indicates that the Heartbeat message is a request. - When it's set to true, it indicates that the Heartbeat message is a response. - - - - - Sequence number used for matching the request to the reply. - - - - - The type of the IGMP message. - - - - - Illegal type. - - - - - Create Group Request (RFC988). - - - - - Create Group Reply (RFC988). - - - - - Join Group Request (RFC988). - - - - - Join Group Reply (RFC988). - - - - - Leave Group Request (RFC988). - - - - - Leave Group Reply (RFC988). - - - - - Confirm Group Request (RFC988). - - - - - Confirm Group Reply (RFC988). - - - - - Membership Query (RFC3376). - - - - - Version 3 Membership Report (RFC3376). - - - - - Version 1 Membership Report (RFC1112). - - - - - Version 2 Membership Report (RFC2236). - - - - - Version 2 Leave Group (RFC2236). - - - - - Multicast Traceroute Response. - - - - - Multicast Traceroute. - - - - - The ICMP code values for Traceroute ICMP type. - - - - - RFC 1393. - - - - - RFC 1393. - - - - - The GRE Version Number. - - - - - RFC 1701, RFC 2784 - - - - - RFC 2637 - - - - - Hallam-Baker. - 
-            +-----+----------+----------+------------+
-            | bit | 0        | 1-7      | 8-15       |
-            +-----+----------+----------+------------+
-            | 0   | Critical | Reserved | Tag Length |
-            +-----+----------+----------+------------+
-            | 16  | Tag                              |
-            | ... |                                  |
-            +-----+----------------------------------+
-            | ... | Value                            |
-            +-----+----------------------------------+
-
- - - - - Constructs an instance out of the flags, tag and value fields. - - Flags of the record. - - The property identifier, a sequence of ASCII characters. - Tag values may contain ASCII characters a through z and the numbers 0 through 9. - Tag values must not contain any other characters. - Matching of tag values is case insensitive. - - Represents the property value. Property values are encoded as binary values and may employ sub-formats. - - - - Two DnsResourceDataCertificationAuthorityAuthorization are equal iff their flags, tag and value fields are equal. - - - - - Two DnsResourceDataCertificationAuthorityAuthorization are equal iff their flags, tag and value fields are equal. - - - - - A hash code of the combination of the flags, tag and value fields. - - - - - Flags of the record. - - - - - The property identifier, a sequence of ASCII characters. - Tag values may contain ASCII characters a through z and the numbers 0 through 9. - Tag values must not contain any other characters. - Matching of tag values is case insensitive. - - - - - Represents the property value. - Property values are encoded as binary values and may employ sub-formats. - - - - - Represents an IPv4 gateway to which an IPsec tunnel may be created in order to reach the entity named by an IPsec resource record. - - - - - Creates a gateway using the given IPv4 address. - - - - - Two DnsGatewayIpV4 are equal if their IPv4 addresses are equal. - - - - - Two gateway representations are equal if they are of the same type and the value is the same. - - - - - The IPv4 address value of the gateway. - - - - - The gateway represnetation type. - - - - - The number of bytes the gateway represnetation takes. - - - - - Hallam-Baker. - - - - - If set, the critical flag is asserted and the property must be understood if the CAA record is to be correctly processed by a certificate issuer. - A Certification Authority must not issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property type that has the issuer flag set. - - - - - Represents the different data links kinds. - See http://www.tcpdump.org/linktypes.html for more data link kinds. - - - - - Ethernet data link kind. - - - - - IPv4 data link kind. - - - - - Data Over Cable Service Interface Specification. - - - - - PPP With Directional Info. - PPP, as per RFC 1661 and RFC 1662, preceded with a one-byte pseudo-header with a zero value meaning "received by this host" - and a non-zero value meaning "sent by this host". - - - - - Linux cooked-mode capture. - - - - - The data link layer protocol of the ARP protocol. - - - - - Invalid hardware type - - - - - Ethernet (10Mb) - - - - - Experimental Ethernet (3Mb) - - - - - Amateur Radio AX.25 - - - - - Proteon ProNET Token Ring - - - - - Chaos - - - - - IEEE 802 Networks - - - - - ARCNET - - - - - Hyperchannel - - - - - Lanstar - - - - - Autonet Short Address - - - - - LocalTalk - - - - - LocalNet (IBM PCNet or SYTEK LocalNET) - - - - - Ultra link - - - - - SMDS - - - - - Frame Relay - - - - - Asynchronous Transmission Mode (ATM) - - - - - HDLC - - - - - Fibre Channel - - - - - Asynchronous Transmission Mode (ATM) - - - - - Serial Line - - - - - Asynchronous Transmission Mode (ATM) - - - - - MIL-STD-188-220 - - - - - Metricom - - - - - IEEE 1394.1995 - - - - - MAPOS - - - - - Twinaxial - - - - - EUI-64 - - - - - HIPARP - - - - - IP and ARP over ISO 7816-3 - - - - - ARPSec - - - - - IPsec tunnel - - - - - InfiniBand (TM) - - - - - TIA-102 Project 25 Common Air Interface (CAI) - - - - - Wiegand Interface - - - - - Pure IP - - - - - HW_EXP1 - - - - - HW_EXP2 - - - - - Represents an ARP protocol layer. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - True iff the two ARP layers have equal protocol type, operation and addresses. - - The ARP layer to compare the layer to. - True iff the two layers are equal. - - - - True iff the two ARP layers have equal protocol type, operation and addresses. - - The ARP layer to compare the layer to. - True iff the two layers are equal. - - - - Returns a hash code for the layer. - The hash code is a XOR of a combination of the protocol type and operation and the hash codes of the layer length and data link. - - - - - Each protocol is assigned a number used in this field. - - - - - Specifies the operation the sender is performing. - - - - - Hardware address of the sender. - - - - - Protocol address of the sender. - - - - - Hardware address of the intended receiver. - This field is ignored in requests. - - - - - Protocol address of the intended receiver. - - - - - The Ethernet Type the Ethernet layer should write when this layer is the Ethernet payload. - - - - - The default MAC Address value when this layer is the Ethernet payload. - null means there is no default value. - - - - - The number of bytes this layer will take. - - - - - An emotion that can be set in a TCP mood option. - - - - - :) - - - - - :( - - - - - :D - - - - - %( - - - - - :o - - - - - :O - - - - - :P - - - - - :@ - - - - - >:@ - - - - - :| - - - - - ;) - - - - - >:) - - - - - An unknown emotion. - - - - - Represents a layer that adds a simple payload. - Actually can be any buffer of bytes. - - - - - Creates an empty payload. - - - - - Two payload layers are equal if they have same data. - - - - - Two payload layers are equal if they have same data. - - - - - Writes the layer to the buffer. - This method ignores the payload length, and the previous and next layers. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - The Payload data. - - - - - The number of bytes this layer will take. - - - - - Strict Source and Record Route - 
-            +--------+--------+--------+---------//--------+
-            |10001001| length | pointer|     route data    |
-            +--------+--------+--------+---------//--------+
-             Type=137
-
- - - The strict source and record route (SSRR) option provides a means for the source of an internet datagram - to supply routing information to be used by the gateways in forwarding the datagram to the destination, - and to record the route information. - - - - The option begins with the option type code. - The second octet is the option length which includes the option type code and the length octet, - the pointer octet, and length-3 octets of route data. - The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. - The pointer is relative to this option, and the smallest legal value for the pointer is 4. - - - - A route data is composed of a series of internet addresses. - Each internet address is 32 bits or 4 octets. - If the pointer is greater than the length, the source route is empty (and the recorded route full) - and the routing is to be based on the destination address field. - - - - If the address in destination address field has been reached and the pointer is not greater than the length, - the next address in the source route replaces the address in the destination address field, - and the recorded route address replaces the source address just used, and pointer is increased by four. - - - - The recorded route address is the internet module's own internet address as known in the environment - into which this datagram is being forwarded. - - - - This procedure of replacing the source route with the recorded route - (though it is in the reverse of the order it must be in to be used as a source route) - means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. - - - - This option is a strict source route because the gateway or host IP - must send the datagram directly to the next address in the source route through only the directly connected network - indicated in the next address to reach the next gateway or host specified in the route. - - - - Must be copied on fragmentation. - Appears at most once in a datagram. - - - - - - Create the option according to the given values. - - - - - Creates an empty strict source routing option. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - RFC 2460. - 
-            +-----+-------------+
-            | Bit | 0-7         |
-            +-----+-------------+
-            | 0   | Option Type |
-            +-----+-------------+
-            | 8   | N           |
-            +-----+-------------+
-            | 16  | 0           |
-            | ... |             |
-            +-----+-------------+
-
- - - - - Creates an option from padding data length. - - The size of the padding in bytes. - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - The size of the padding in bytes. - - - - - RFC 6058. - 
-            +-----+----------+---+--------------+
-            | Bit | 0-6      | 7 | 8-15         |
-            +-----+----------+---+--------------+
-            | 0   | Option Type  | Opt Data Len |
-            +-----+----------+---+--------------+
-            | 16  | Reserved | L | Lifetime     |
-            +-----+----------+---+--------------+
-
- - - - - The number of bytes this option data takes. - - - - - Creates an instance from late path switch and lifetime. - - - Indicates that the Local Mobility Anchor (LMA) applies late path switch according to the transient BCE state. - If true, the LMA continues to forward downlink packets towards the pMAG. - Different setting of this flag may be for future use. - - - Maximum lifetime of a Transient-L state in multiple of 100 ms. - - - - - Indicates that the Local Mobility Anchor (LMA) applies late path switch according to the transient BCE state. - If true, the LMA continues to forward downlink packets towards the pMAG. - Different setting of this flag may be for future use. - - - - - Maximum lifetime of a Transient-L state in multiple of 100 ms. - - - - - RFC 5949. - 
-            +-----+-------------+-----------------+
-            | Bit | 0-7         | 8-15            |
-            +-----+-------------+-----------------+
-            | 0   | Option Type | Opt Data Len    |
-            +-----+-------------+-----------------+
-            | 16  | Option-Code | Reserved        |
-            +-----+-------------+-----------------+
-            | 32  | Local Mobility Anchor Address |
-            |     |                               |
-            | ... |                               |
-            +-----+-------------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from IPv4 local mobility anchor address with IPv4 code. - - The LMA IPv4 address (IPv4-LMA). - - - - Creates an instance from IPv6 local mobility anchor address with IPv6 code. - - The LMA IPv6 address (LMAA). - - - - Determines the type of the local mobility anchor address. - - - - - If the Code IPv6, the LMA IPv6 address (LMAA), otherwise null. - - - - - If the Code is IPv4, the LMA IPv4 address (IPv4-LMA), otherwise null. - - - - - RFC 6089. - 
-            +-----+--------------+-------------+
-            | Bit | 0-7          | 8-15        |
-            +-----+--------------+-------------+
-            | 0   | Sub-Opt Type | Sub-Opt Len |
-            +-----+--------------+-------------+
-            | 16  | Option Data                |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from type and data. - - The type of the option. - The data of the option. - - - - The data of the option. - - - - - RFC 6089. - - - - - RFC 6089. - - - - - RFC 6089. - - - - - RFC 6089. - - - - - RFC 6089. - - - - - Binding Revocation Type of a Binding Revocation Message IPv6 Extension Header. - The specific type of the extension header is decided according to this type. - - - - - Invalid value. - - - - - Binding Revocation Indication. - - - - - Binding Revocation Acknowledgement. - - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Home Nonce Index                      |
-            +-----+---------------------------------------+
-            | 64  | Home Init Cookie                      |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            +-----+---------------------------------------+
-            | 128 | Home Keygen Token                     |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            +-----+---------------------------------------+
-            | 192 | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, home nonce index, home init cookie, home keygen token and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update. - Contains the home init cookie. - Contains the 64-bit home keygen token used in the return routability procedure. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update. - - - - - Contains the home init cookie. - - - - - Contains the 64-bit home keygen token used in the return routability procedure. - - - - - The different ICMP message types and codes. - Each of the values is a combination of the message type and a code values that is legal with this message type. - - - - - RFC 792. - If, according to the information in the gateway's routing tables, - the network specified in the internet destination field of a datagram is unreachable, - e.g., the distance to the network is infinity, - the gateway may send a destination unreachable message to the internet source host of the datagram. - - - - - RFC 792. - In some networks, the gateway may be able to determine if the internet destination host is unreachable. - Gateways in these networks may send destination unreachable messages to the source host when the destination host is unreachable. - - - - - RFC 792. - If, in the destination host, the IP module cannot deliver the datagram because the indicated protocol module is not active, - the destination host may send a destination unreachable message to the source host. - - - - - RFC 792. - If, in the destination host, the IP module cannot deliver the datagram because the indicated process port is not active, - the destination host may send a destination unreachable message to the source host. - - - - - RFC 792. - A datagram must be fragmented to be forwarded by a gateway yet the Don't Fragment flag is on. - In this case the gateway must discard the datagram and may return a destination unreachable message. - - - - - RFC 792. - - - - - RFC 792. - If the gateway processing a datagram finds the time to live field is zero it must discard the datagram. - The gateway may also notify the source host via the time exceeded message. - - - - - RFC 792. - If a host reassembling a fragmented datagram cannot complete the reassembly due to missing fragments within its time limit it discards the datagram, - and it may send a time exceeded message. - If fragment zero is not available then no time exceeded need be sent at all. - - - - - RFC 792. - If the gateway or host processing a datagram finds a problem with the header parameters such that it cannot complete processing the datagram it must discard the datagram. - One potential source of such a problem is with incorrect arguments in an option. - The gateway or host may also notify the source host via the parameter problem message. - This message is only sent if the error caused the datagram to be discarded. - - - - - RFC 792. - - - A gateway may discard internet datagrams if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network. - If a gateway discards a datagram, it may send a source quench message to the internet source host of the datagram. - A destination host may also send a source quench message if datagrams arrive too fast to be processed. - The source quench message is a request to the host to cut back the rate at which it is sending traffic to the internet destination. - The gateway may send a source quench message for every message that it discards. - On receipt of a source quench message, the source host should cut back the rate at which it is sending traffic to the specified destination - until it no longer receives source quench messages from the gateway. - The source host can then gradually increase the rate at which it sends traffic to the destination until it again receives source quench messages. - - - - The gateway or host may send the source quench message when it approaches its capacity limit rather than waiting until the capacity is exceeded. - This means that the data datagram which triggered the source quench message may be delivered. - - - - - - RFC 792. - - - - - RFC 792. - - - - - RFC 792. - - - - - RFC 792. - - - - - RFC 792. - - The data received in the echo message must be returned in the echo reply message. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. - The echoer returns these same values in the echo reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792. - - The data received in the echo message must be returned in the echo reply message. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. - The echoer returns these same values in the echo reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792 - - The data received (a timestamp) in the message is returned in the reply together with an additional timestamp. - The timestamp is 32 bits of milliseconds since midnight UT. - - - - If the time is not available in miliseconds or cannot be provided with respect to midnight UT - then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792 - - The data received (a timestamp) in the message is returned in the reply together with an additional timestamp. - The timestamp is 32 bits of milliseconds since midnight UT. - - - - If the time is not available in miliseconds or cannot be provided with respect to midnight UT - then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792. - - This message may be sent with the source network in the IP header source and destination address fields zero (which means "this" network). - The replying IP module should send the reply with the addresses fully specified. - This message is a way for a host to find out the number of the network it is on. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 792. - - This message may be sent with the source network in the IP header source and destination address fields zero (which means "this" network). - The replying IP module should send the reply with the addresses fully specified. - This message is a way for a host to find out the number of the network it is on. - - - - The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. - For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. - The destination returns these same values in the reply. - - - - Code 0 may be received from a gateway or a host. - - - - - - RFC 1256. - - - - - RFC 1256. - - - - - RFC 950. - - - A gateway receiving an address mask request should return it with the address mask field set to the 32-bit mask of the bits identifying the subnet and network, - for the subnet on which the request was received. - - - - If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. - However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. - Even when the replies are broadcast, since there is only one possible address mask for a subnet, there is no need to match requests with replies. - The "Identifier" and "Sequence Number" fields can be ignored. - - - - - - RFC 950. - - - A gateway receiving an address mask request should return it with the address mask field set to the 32-bit mask of the bits identifying the subnet and network, - for the subnet on which the request was received. - - - - If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. - However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. - Even when the replies are broadcast, since there is only one possible address mask for a subnet, there is no need to match requests with replies. - The "Identifier" and "Sequence Number" fields can be ignored. - - - - - - RFC 1393. - - - - - RFC 1393. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1475. - The introduction of network layer conversion requires a new message type, to report conversion errors. - Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. - This message is only sent when a valid datagram cannot be converted. - - - - - RFC 1788. - - - - - RFC 1788. - Parsing of this datagram isn't supported because its parsing is not clear from the RFC. - - - - - RFC 2521. - Indicates that a received datagram includes a Security Parameters Index (SPI) that is invalid or has expired. - - - - - RFC 2521. - Indicates that a received datagram failed the authenticity or integrity check for a given SPI. - - - Note that the SPI may indicate an outer Encapsulating Security Protocol when a separate Authentication Header SPI is hidden inside. - - - - - - RFC 2521. - Indicates that a received datagram failed a decompression check for a given SPI. - - - - - RFC 2521. - Indicates that a received datagram failed a decryption check for a given SPI. - - - - - RFC 2521. - Indicates that a received datagram will not be accepted without additional authentication. - - - In this case, either no SPI is present, or an unsuitable SPI is present. - For example, an encryption SPI without integrity arrives from a secure operating system with mutually suspicious users. - - - - - - RFC 2521. - Indicates that a received datagram will not be accepted because it has insufficient authorization. - - - In this case, an authentication SPI is present that is inappropriate for the target transport or application. - The principle party denoted by the SPI does not have proper authorization for the facilities used by the datagram. - For example, the party is authorized for Telnet access, but not for FTP access. - - - - - - RFC 792 and RFC 1191. - 
-            +-----+------+------+--------------+
-            | Bit | 0-7  | 8-15 | 16-31        |
-            +-----+------+------+--------------+
-            | 0   | Type | Code | Checksum     |
-            +-----+------+------+--------------+
-            | 32  | unused      | Next-Hop MTU |
-            +-----+-------------+--------------+
-            | 64  | Internet Header            |
-            |     | + 64 bits of               |
-            |     | Original Data Datagram     |
-            +-----+----------------------------+
-
- - - - - The minimum value of the maximum transmission unit for FragmentationNeededAndDoNotFragmentSet code. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if the datagram's length is OK, the checksum is correct, the code is in the expected range, - the IPv4 payload contains at least an IPv4 header, the IPv4's payload is in the expected size - and if the NextHopMaximumTransmissionUnit is at least 68 for FragmentationNeededAndDoNotFragmentSet code or exactly 0 for other codes. - - - - - The size in octets of the largest datagram that could be forwarded, - along the path of the original datagram, without being fragmented at this router. - The size includes the IP header and IP data, and does not include any lower-level headers. - - - - - The minimum valid ICMP code for this type of ICMP datagram. - - - - - The maximum valid ICMP code for this type of ICMP datagram. - - - - - RFC 950. - - - - - The value of this field determines the format of the remaining data. - - - - - The two possible endianities. - - - - - Small endianity - bytes are read from the high offset to the low offset. - - - - - Big endianity - bytes are read from the low offset to the high offset. - - - - - RFC 1183. - 
-            +---------------+
-            | ISDN-address  |
-            +---------------+
-            | sa (optional) |
-            +---------------+
-
- - - - - Constructs an ISDN resource data without a subaddress from the ISDN address. - - - Identifies the ISDN number of the owner and DDI (Direct Dial In) if any, as defined by E.164 and E.163, - the ISDN and PSTN (Public Switched Telephone Network) numbering plan. - E.163 defines the country codes, and E.164 the form of the addresses. - - - - - Constructs an ISDN resource data from the ISDN address and subaddress. - - - Identifies the ISDN number of the owner and DDI (Direct Dial In) if any, as defined by E.164 and E.163, - the ISDN and PSTN (Public Switched Telephone Network) numbering plan. - E.163 defines the country codes, and E.164 the form of the addresses. - - Specifies the subaddress (SA). - - - - Identifies the ISDN number of the owner and DDI (Direct Dial In) if any, as defined by E.164 and E.163, - the ISDN and PSTN (Public Switched Telephone Network) numbering plan. - E.163 defines the country codes, and E.164 the form of the addresses. - - - - - Specifies the subaddress (SA). - - - - - 
-            +-----+---------+
-            | bit | 0-7     |
-            +-----+---------+
-            | 0   | FORMAT  |
-            +-----+---------+
-            | 8   | ADDRESS |
-            | ... |         |
-            +-----+---------+
-
- - - - - Constructs an instance from the format and address fields. - - The format of Address. - - Variable length string of octets containing the ATM address of the node to which this RR pertains. - When the format is AESA, the address is coded as described in ISO 8348/AD 2 using the preferred binary encoding of the ISO NSAP format. - When the format value is E.164, the Address/Number Digits appear in the order in which they would be entered on a numeric keypad. - Digits are coded in IA5 characters with the leftmost bit of each digit set to 0. - This ATM address appears in ATM End System Address Octets field (AESA format) or the Address/Number Digits field (E.164 format) of the Called party number information element [ATMUNI3.1]. - Subaddress information is intentionally not included because E.164 subaddress information is used for routing. - - - - - Two DnsResourceDataAtmAddress are equal iff their format and address fields are equal. - - - - - Two DnsResourceDataAtmAddress are equal iff their format and address fields are equal. - - - - - A hash code based on the format and address fields. - - - - - The format of Address. - - - - - Variable length string of octets containing the ATM address of the node to which this RR pertains. - When the format is AESA, the address is coded as described in ISO 8348/AD 2 using the preferred binary encoding of the ISO NSAP format. - When the format value is E.164, the Address/Number Digits appear in the order in which they would be entered on a numeric keypad. - Digits are coded in IA5 characters with the leftmost bit of each digit set to 0. - This ATM address appears in ATM End System Address Octets field (AESA format) or the Address/Number Digits field (E.164 format) of the Called party number information element [ATMUNI3.1]. - Subaddress information is intentionally not included because E.164 subaddress information is used for routing. - - - - - RFC 2671. - The implementation level of whoever sets it for the OPT resource record. - - - - - Full conformance with the specification. - - - - - Represents an VLAN Tagged Frame layer. - - - - - - Creates an instance with zero values. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Two VLAN Tagged Frame layers are equal iff their PriorityCodePoint, CanonicalFormatIndicator, VLanIdentifier and EtherType are equal. - - - - - Two VLAN Tagged Frame layers are equal iff their PriorityCodePoint, CanonicalFormatIndicator, VLanIdentifier and EtherType are equal. - - - - - Returns a hash code for the layer. - The hash code is a XOR of the hash codes of the layer length, data link, TagControlInformation and the ethernet type. - - - - - Indicates the frame priority level. - Values are from 0 (best effort) to 7 (highest); 1 represents the lowest priority. - These values can be used to prioritize different classes of traffic (voice, video, data, etc.). - - - - - If reset, all MAC Address information that may be present in the MSDU is in Canonical format and the tag comprises solely the TPID and TCI fields, - i.e., the tag does not contain an Embedded Routing Information Field (E-RIF). - - - - - A VLAN-aware Bridge may not support the full range of VID values but shall support the use of all VID values in the range 0 through a maximum N, - less than or equal to 4094 and specified for that implementation. - - - - - A combination of pcp (PriorityCodePoint), cfi (CanonicalFormatIndicator) and vid (VLanIdentifier). - - - - - The number of bytes this layer will take. - - - - - The Ethernet Type the Ethernet layer should write when this layer is the Ethernet payload. - - - - - The default MAC Address value when this layer is the Ethernet payload. - null means there is no default value. - - - - - RFC 768. - Represents the UDP layer. - - - - - - Contains the common part of UDP and TCP layers. - - - - - - Two Transport layers are equal if they have they have the same previous layer protocol value, checksum, source and destination ports, - and if the specific transport protocol fields are equal. - - - - - Two Transport layers are equal if they have they have the same previous layer protocol value, checksum, source and destination ports, - and if the specific transport protocol fields are equal. - - - - - Returns a hash code for the layer. - The hash code is a XOR of the combination of the source and destination ports and the hash codes of the layer length, data link and checksum. - - - - - True iff the specific transport layer fields are equal. - - - - - Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, - the Transport header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. - - - - - Indicates the port of the sending process. - In UDP, this field is optional and may only be assumed to be the port - to which a reply should be addressed in the absence of any other information. - If not used in UDP, a value of zero is inserted. - - - - - Destination Port has a meaning within the context of a particular internet destination address. - - - - - The protocol that should be written in the previous (IPv4) layer. - - - - - Whether the checksum should be calculated. - Can be false in UDP because the checksum is optional. false means that the checksum will be left zero. - - - - - The offset in the layer where the checksum should be written. - - - - - Whether the checksum is optional in the layer. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Whether the checksum should be calculated. - Can be false in UDP because the checksum is optional. false means that the checksum will be left zero. - - - - - Whether the checksum should be calculated. - Can be false in UDP because the checksum is optional. false means that the checksum will be left zero. - - - - - The protocol that should be written in the previous (IPv4) layer. - - - - - The offset in the layer where the checksum should be written. - - - - - Whether the checksum is optional in the layer. - - - - - The number of bytes this layer will take. - - - - - Represents a block to ack when using the selective ack option. - - - - - The number of bytes this struct take. - - - - - Creates a selective ack block. - - The sequence number of the first byte to ack. - The sequence number of the byte after the last byte to ack. - - - - Creates a string that represents the selective block. - - - - - Two blocks are equal if the have the same left and right edges. - - - - - Two blocks are equal if the have the same left and right edges. - - - - - Two blocks are equal if the have the same left and right edges. - - - - - Two blocks are different if the have the different left or right edge. - - - - - The hash code of a block is the xor between the hash code of left and right edges. - - - - - The sequence number of the first byte to ack. - - - - - The sequence number of the byte after the last byte to ack. - - - - - RFC 793. - Represents the TCP layer. - - - - - - Default constructor. - No TCP options. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - True iff the SequenceNumber, AcknowledgmentNumber, ControlBits, Window, UrgentPointer and Options fields are equal. - - - - - True iff the SequenceNumber, AcknowledgmentNumber, ControlBits, Window, UrgentPointer and Options fields are equal. - - - - - The sequence number of the first data octet in this segment (except when SYN is present). - If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1. - - - - - If the ACK control bit is set this field contains the value of the next sequence number - the sender of the segment is expecting to receive. - Once a connection is established this is always sent. - - - - - A collection of bits for the TCP control. - - - - - The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept. - - - - - This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. - The urgent pointer points to the sequence number of the octet following the urgent data. - This field is only be interpreted in segments with the URG control bit set. - - - - - The TCP options contained in this TCP Datagram. - - - - - The protocol that should be written in the previous (IPv4) layer. - - - - - The offset in the layer where the checksum should be written. - - - - - Whether the checksum is optional in the layer. - - - - - The number of bytes this layer will take. - - - - - Record Route - 
-            +--------+--------+--------+---------//--------+
-            |00000111| length | pointer|     route data    |
-            +--------+--------+--------+---------//--------+
-             Type=7
-
- - - The record route option provides a means to record the route of an internet datagram. - - - - The option begins with the option type code. - The second octet is the option length which includes the option type code and the length octet, - the pointer octet, and length-3 octets of route data. - The third octet is the pointer into the route data indicating the octet which begins the next area to store a route address. - The pointer is relative to this option, and the smallest legal value for the pointer is 4. - - - - A recorded route is composed of a series of internet addresses. - Each internet address is 32 bits or 4 octets. - If the pointer is greater than the length, the recorded route data area is full. - The originating host must compose this option with a large enough route data area to hold all the address expected. - The size of the option does not change due to adding addresses. - The intitial contents of the route data area must be zero. - - - - When an internet module routes a datagram it checks to see if the record route option is present. - If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded - into the recorded route begining at the octet indicated by the pointer, - and increments the pointer by four. - - - - If the route data area is already full (the pointer exceeds the length) - the datagram is forwarded without inserting the address into the recorded route. - If there is some room but not enough room for a full address to be inserted, - the original datagram is considered to be in error and is discarded. - In either case an ICMP parameter problem message may be sent to the source host. - - - - Not copied on fragmentation, goes in first fragment only. - Appears at most once in a datagram. - - - - - - Constructs the option from the given values. - - The route addresses values. - The pointed index in the route. - - - - Constructs the option from the given values. - - The route addresses values. - The pointed index in the route. - - - - Constructs an empty record route option. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - RFC 4782. - Defines the possible quick start functions. - - - - - Request for a specific rate. - - - - - Reports on a specific rate that was agreed (or disagreed). - - - - - Represents IPv4 Fragmentation information. - - - - - Creates fragmentation field value according to the given information. - - Options for fragmentation (must be one of the values of the enum). - This field indicates where in the complete datagram this fragment belongs. Measured in bytes but must divide by 8. - - - - Two framentations are equal if they are exactly the same fragmentation (options and offset). - - - - - Two framentations are equal if they are exactly the same fragmentation (options and offset). - - - - - Two framentations are equal if they are exactly the same fragmentation (options and offset). - - - - - Two framentations are different if they are different fragmentation (options or offset). - - - - - The hash code of the fragmentation is the hash code of its combined flags and offset 16 bit field. - - - - - - No fragmentation. - - - - - Options for fragmentation. - - - - - This field indicates where in the complete datagram this fragment belongs. Measured in bytes but must divide by 8. - - - - - An unknown IPv4 option. - - - - - A factory interface for an unknown option. - - The option type enum type. - - - - Creates an unknown option from its type and by reading a buffer for its value. - - The type of the unknown option. - The buffer of bytes to read the value of the unknown option. - The offset in the buffer to start reading the bytes. - The number of bytes to read from the buffer. - An option created from the given type and buffer. - - - - The minimum number of bytes this option take. - - - - - The minimum number of bytes this option's value take. - - - - - Creates an unknown IPv4 option by the given type and data. - - - - - The default unknown option is with type 255 and no data. - - - - - Two unknown options are equal iff they are of equal type and equal data. - - - - - Two unknown options are equal iff they are of equal type and equal data. - - - - - Creates an unknown option from its type and by reading a buffer for its value. - - The type of the unknown option. - The buffer of bytes to read the value of the unknown option. - The offset in the buffer to start reading the bytes. - The number of bytes to read from the buffer. - An option created from the given type and buffer. - - - - The hash code for an unknown option is the hash code for the option type xored with the hash code of the data. - - - - - Returns the Data of the option. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - RFC 6621. - Simplified Multicast Forwarding Duplicate Packet Detection. - Sequence-based approach. - Null Tagger ID. - 
-            +-----+---+-------+--------+
-            | Bit | 0 | 1-3   | 4-7    |
-            +-----+---+-------+--------+
-            | 0   | Option Type        |
-            +-----+--------------------+
-            | 8   | Opt Data Len       |
-            +-----+---+-------+--------+
-            | 16  | 0 | TidTy | TidLen |
-            +-----+---+-------+--------+
-            | 24  | Identifier         |
-            | ... |                    |
-            +-----+--------------------+
-
- - - - - Creates an instance from an identifier. - - - DPD packet Identifier. - When the TaggerId field is present, the Identifier can be considered a unique packet identifier - in the context of the TaggerId:srcAddr:dstAddr tuple. - When the TaggerId field is not present, then it is assumed that the source applied the SMF_DPD option - and the Identifier can be considered unique in the context of the IPv6 packet header srcAddr:dstAddr tuple. - - - - - The length of the Tagger Id. - - - - - Indicating the presence and type of the optional TaggerId field. - - - - - RFC 6621. - Simplified Multicast Forwarding Duplicate Packet Detection. - Sequence-based approach. - IPv4 tagger ID. - 
-            +-----+---+-------+--------+
-            | Bit | 0 | 1-3   | 4-7    |
-            +-----+---+-------+--------+
-            | 0   | Option Type        |
-            +-----+--------------------+
-            | 8   | Opt Data Len       |
-            +-----+---+-------+--------+
-            | 16  | 0 | TidTy | TidLen |
-            +-----+---+-------+--------+
-            | 24  | TaggerId           |
-            |     |                    |
-            |     |                    |
-            |     |                    |
-            +-----+--------------------+
-            | 56  | Identifier         |
-            | ... |                    |
-            +-----+--------------------+
-
- - - - - Creates an instance from tagger id and identifier. - - - Used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. - - - DPD packet Identifier. - When the TaggerId field is present, the Identifier can be considered a unique packet identifier - in the context of the TaggerId:srcAddr:dstAddr tuple. - When the TaggerId field is not present, then it is assumed that the source applied the SMF_DPD option - and the Identifier can be considered unique in the context of the IPv6 packet header srcAddr:dstAddr tuple. - - - - - Used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. - - - - - The length of the Tagger Id. - - - - - Indicating the presence and type of the optional TaggerId field. - - - - - RFC 5570. - 
-            +-----+-------------+-----------------+
-            | Bit | 0-7         | 8-15            |
-            +-----+-------------+-----------------+
-            | 0   | Option Type | Opt Data Len    |
-            +-----+-------------+-----------------+
-            | 16  | Domain of Interpretation      |
-            |     |                               |
-            +-----+-------------+-----------------+
-            | 48  | Cmpt Lengt  | Sens Level      |
-            +-----+-------------+-----------------+
-            | 64  | Checksum (CRC-16)             |
-            +-----+-------------------------------+
-            | 80  | Compartment Bitmap (Optional) |
-            | ... |                               |
-            +-----+-------------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - The maximum length for the compartment bitmap. - - - - - Creates an instance from domain of interpretation, sensitivity level, checksum and compartment bitmap. - - Identifies the rules under which this datagram must be handled and protected. - - Contains an opaque octet whose value indicates the relative sensitivity of the data contained in this datagram in the context of the indicated DOI. - The values of this field must be ordered, with 00000000 being the lowest Sensitivity Level and 11111111 being the highest Sensitivity Level. - However, in a typical deployment, not all 256 Sensitivity Levels will be in use. - So the set of valid Sensitivity Level values depends upon the CALIPSO DOI in use. - This sensitivity ordering rule is necessary so that Intermediate Systems (e.g., routers or MLS guards) will be able to apply MAC policy - with minimal per-packet computation and minimal configuration. - - - Contains the a CRC-16 checksum as defined in RFC 1662. - The checksum is calculated over the entire CALIPSO option in this packet, including option header, zeroed-out checksum field, option contents, - and any required padding zero bits. - The checksum must always be computed on transmission and must always be verified on reception. - This checksum only provides protection against accidental corruption of the CALIPSO option in cases where neither the underlying medium - nor other mechanisms, such as the IP Authentication Header (AH), are available to protect the integrity of this option. - Note that the checksum field is always required, even when other integrity protection mechanisms (e.g., AH) are used. - If null is given, it would be automatically calculated. - - - Each bit represents one compartment within the DOI. - Each "1" bit within an octet in the Compartment Bitmap field represents a separate compartment under whose rules the data in this packet - must be protected. - Hence, each "0" bit indicates that the compartment corresponding with that bit is not applicable to the data in this packet. - The assignment of identity to individual bits within a Compartment Bitmap for a given DOI is left to the owner of that DOI. - This specification represents a Releasability on the wire as if it were an inverted Compartment. - So the Compartment Bitmap holds the sum of both logical Releasabilities and also logical Compartments for a given DOI value. - The encoding of the Releasabilities in this field is described elsewhere in this document. - The Releasability encoding is designed to permit the Compartment Bitmap evaluation to occur without the evaluator necessarily knowing - the human semantic associated with each bit in the Compartment Bitmap. - In turn, this facilitates the implementation and configuration of Mandatory Access Controls based on the Compartment Bitmap - within IPv6 routers or guard devices. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - Identifies the rules under which this datagram must be handled and protected. - - - - - Specifies the size of the Compartment Bitmap field in 32-bit words. - The minimum value is zero, which is used only when the information in this packet is not in any compartment. - (In that situation, the CALIPSO Sensitivity Label has no need for a Compartment Bitmap). - - - - - Specifies the size of the Compartment Bitmap field in bytes. - The minimum value is zero, which is used only when the information in this packet is not in any compartment. - (In that situation, the CALIPSO Sensitivity Label has no need for a Compartment Bitmap). - - - - - Contains an opaque octet whose value indicates the relative sensitivity of the data contained in this datagram in the context of the indicated DOI. - The values of this field must be ordered, with 00000000 being the lowest Sensitivity Level and 11111111 being the highest Sensitivity Level. - However, in a typical deployment, not all 256 Sensitivity Levels will be in use. - So the set of valid Sensitivity Level values depends upon the CALIPSO DOI in use. - This sensitivity ordering rule is necessary so that Intermediate Systems (e.g., routers or MLS guards) will be able to apply MAC policy - with minimal per-packet computation and minimal configuration. - - - - - Contains the a CRC-16 checksum as defined in RFC 1662. - The checksum is calculated over the entire CALIPSO option in this packet, including option header, zeroed-out checksum field, option contents, - and any required padding zero bits. - The checksum must always be computed on transmission and must always be verified on reception. - This checksum only provides protection against accidental corruption of the CALIPSO option in cases where neither the underlying medium - nor other mechanisms, such as the IP Authentication Header (AH), are available to protect the integrity of this option. - Note that the checksum field is always required, even when other integrity protection mechanisms (e.g., AH) are used. - - - - - True iff the checksum is correct. - - - - - Each bit represents one compartment within the DOI. - Each "1" bit within an octet in the Compartment Bitmap field represents a separate compartment under whose rules the data in this packet - must be protected. - Hence, each "0" bit indicates that the compartment corresponding with that bit is not applicable to the data in this packet. - The assignment of identity to individual bits within a Compartment Bitmap for a given DOI is left to the owner of that DOI. - This specification represents a Releasability on the wire as if it were an inverted Compartment. - So the Compartment Bitmap holds the sum of both logical Releasabilities and also logical Compartments for a given DOI value. - The encoding of the Releasabilities in this field is described elsewhere in this document. - The Releasability encoding is designed to permit the Compartment Bitmap evaluation to occur without the evaluator necessarily knowing - the human semantic associated with each bit in the Compartment Bitmap. - In turn, this facilitates the implementation and configuration of Mandatory Access Controls based on the Compartment Bitmap - within IPv6 routers or guard devices. - - - - - RFC 5847. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Restart Counter            |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an option from the given restart counter. - - Indicates the current Restart Counter value. - - - - Indicates the current Restart Counter value. - - - - - RFC 6275. - +-----+-----+ - | Bit | 0-7 | - +-----+-----+ - | 0 | 0 | - +-----+-----+ - - - - - The number of bytes the option takes. - - - - - Constructs an instance. - - - - - The number of bytes this option will take. - - - - - RFC 4283. - 
-            +-----+--------------+
-            | Bit | 0-7          |
-            +-----+--------------+
-            | 0   | Option Type  |
-            +-----+--------------+
-            | 8   | Opt Data Len |
-            +-----+--------------+
-            | 16  | Subtype      |
-            +-----+--------------+
-            | 24  | Identifier   |
-            | ... |              |
-            +-----+--------------+
-
- - - - - The minimum length for identifier. - - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from subtype and identifier. - - - Defines the specific type of identifier included in the Identifier field. - - - A variable length identifier of type, as specified by the Subtype field of this option. - - - - - Defines the specific type of identifier included in the Identifier field. - - - - - A variable length identifier of type, as specified by the Subtype field of this option. - - - - - RFC 5555. - 
-            +-----+-------------+--------------+----------+
-            | Bit | 0-7         | 8-13         | 14-15    |
-            +-----+-------------+--------------+----------+
-            | 0   | Option Type | Opt Data Len            |
-            +-----+-------------+--------------+----------+
-            | 16  | Status      | Prefix-len   | Reserved |
-            +-----+-------------+--------------+----------+
-            | 32  | IPv4 home address                     |
-            |     |                                       |
-            +-----+---------------------------------------+
-
- - - - - Maximum value for Prefix Length. - - - - - Number of bytes this option data takes. - - - - - Creates an instance from status, Prefix Length and Home Address. - - - Indicates success or failure for the IPv4 home address binding. - Values from 0 to 127 indicate success. - Higher values indicate failure. - - - The prefix length of the address allocated. - This field is only valid in case of success and must be set to zero and ignored in case of failure. - This field overrides what the mobile node requested (if not equal to the requested length). - - - The IPv4 home address that the home agent will use in the binding cache entry. - This could be a public or private address. - This field must contain the mobile node's IPv4 home address. - If the address were dynamically allocated, the home agent will add the address to inform the mobile node. - Otherwise, if the address is statically allocated to the mobile node, the home agent will copy it from the binding update message. - - - - - Indicates success or failure for the IPv4 home address binding. - Values from 0 to 127 indicate success. - Higher values indicate failure. - - - - - The prefix length of the address allocated. - This field is only valid in case of success and must be set to zero and ignored in case of failure. - This field overrides what the mobile node requested (if not equal to the requested length). - - - - - The IPv4 home address that the home agent will use in the binding cache entry. - This could be a public or private address. - This field must contain the mobile node's IPv4 home address. - If the address were dynamically allocated, the home agent will add the address to inform the mobile node. - Otherwise, if the address is statically allocated to the mobile node, the home agent will copy it from the binding update message. - - - - - RFC 6089. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | FID ...                    |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from an array of flow identifiers. - - - Indicating a registered FID. - One or more FID fields can be included in this option. - - - - - Creates an instance from an enumerable of flow identifiers. - - - Indicating a registered FID. - One or more FID fields can be included in this option. - - - - - Creates an instance from a list of flow identifiers. - - - Indicating a registered FID. - One or more FID fields can be included in this option. - - - - - Creates an instance from a collection of flow identifiers. - - - Indicating a registered FID. - One or more FID fields can be included in this option. - - - - - Indicating a registered FID. - One or more FID fields can be included in this option. - - - - - RFC 6089. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | FID                        |
-            +-----+----------------------------+
-            | 32  | FID-PRI                    |
-            +-----+-------------+--------------+
-            | 48  | Reserved    | Status       |
-            +-----+-------------+--------------+
-            | 64  | Sub-options (optional)     |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from flow identifier, priority, status and sub options. - - - Includes the unique identifier for the flow binding. - This field is used to refer to an existing flow binding or to create a new flow binding. - The value of this field is set by the mobile node. - FID = 0 is reserved and must not be used. - - - Indicates the priority of a particular option. - This field is needed in cases where two different flow descriptions in two different options overlap. - The priority field decides which policy should be executed in those cases. - A lower number in this field indicates a higher priority. - Value '0' is reserved and must not be used. - Must be unique to each of the flows pertaining to a given MN. - In other words, two FIDs must not be associated with the same priority value. - - - indicates the success or failure of the flow binding operation for the particular flow in the option. - This field is not relevant to the binding update message as a whole or to other flow identification options. - This field is only relevant when included in the Binding Acknowledgement message and must be ignored in the binding update message. - - Zero or more sub-options. - - - - Includes the unique identifier for the flow binding. - This field is used to refer to an existing flow binding or to create a new flow binding. - The value of this field is set by the mobile node. - FID = 0 is reserved and must not be used. - - - - - Indicates the priority of a particular option. - This field is needed in cases where two different flow descriptions in two different options overlap. - The priority field decides which policy should be executed in those cases. - A lower number in this field indicates a higher priority. - Value '0' is reserved and must not be used. - Must be unique to each of the flows pertaining to a given MN. - In other words, two FIDs must not be associated with the same priority value. - - - - - indicates the success or failure of the flow binding operation for the particular flow in the option. - This field is not relevant to the binding update message as a whole or to other flow identification options. - This field is only relevant when included in the Binding Acknowledgement message and must be ignored in the binding update message. - - - - - Zero or more sub-options. - - - - - True iff parsing of this option didn't encounter issues. - - - - - RFC 6089. - 
-            +-----+--------------+
-            | Bit | 0-7          |
-            +-----+--------------+
-            | 0   | Sub-Opt Type |
-            +-----+--------------+
-            | 8   | N            |
-            +-----+--------------+
-            | 16  | 0            |
-            | ... |              |
-            +-----+--------------+
-
- - - - - Creates an instance from padding data length. - - The size of the padding in bytes. - - - - The size of the padding in bytes. - - - - - RFC 6554. - 
-            +-----+-------+-------+------+------------------+--------------+---------------+
-            | Bit | 0-3   | 4-7   | 8-11 | 12-15            | 16-23        | 24-31         |
-            +-----+-------+-------+------+------------------+--------------+---------------+
-            | 0   | Next Header   | Header Extension Length | Routing Type | Segments Left |
-            +-----+-------+-------+------+------------------+--------------+---------------+
-            | 32  | CmprI | CmprE | Pad  | Reserved                                        |
-            +-----+-------+-------+------+-------------------------------------------------+
-            | 64  | Address[1]                                                             |
-            | ... |                                                                        |
-            +-----+------------------------------------------------------------------------+
-            |     | Address[2]                                                             |
-            | ... |                                                                        |
-            +-----+------------------------------------------------------------------------+
-            | .   | .                                                                      |
-            | .   | .                                                                      |
-            | .   | .                                                                      |
-            +-----+------------------------------------------------------------------------+
-            |     | Address[n]                                                             |
-            | ... |                                                                        |
-            +-----+------------------------------------------------------------------------+
-            |     | Padding                                                                |
-            | ... |                                                                        |
-            +-----+------------------------------------------------------------------------+
-
- - - - - The minimum number of bytes the routing data takes. - - - - - The maximum common prefix length. - - - - - The maximum padding size. - - - - - Creates an instance from next header, segments left, common prefix length for non last addresses, common prefix length for last address and addresses. - - Identifies the type of header immediately following this extension header. - - Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. - - - Number of prefix octets from each segment, except than the last segment, (i.e., segments 1 through n-1) that are elided. - For example, a header carrying full IPv6 addresses in Addresses[1..n-1] sets this to 0. - - - Number of prefix octets from the last segment (i.e., segment n) that are elided. - For example, a header carrying a full IPv6 address in Addresses[n] sets this to 0. - - Routing addresses. - - - - Identifier of a particular Routing header variant. - - - - - Number of prefix octets from each segment, except than the last segment, (i.e., segments 1 through n-1) that are elided. - For example, a header carrying full IPv6 addresses in Addresses[1..n-1] sets this to 0. - - - - - Number of prefix octets from the last segment (i.e., segment n) that are elided. - For example, a header carrying a full IPv6 address in Addresses[n] sets this to 0. - - - - - Number of octets that are used for padding after Address[n] at the end of the header. - - - - - Routing addresses. - - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+--------------+---------------+
-            | Bit | 0-7         | 8-15                    | 16-23        | 24-31         |
-            +-----+-------------+-------------------------+--------------+---------------+
-            | 0   | Next Header | Header Extension Length | Routing Type | Segments Left |
-            +-----+-------------+-------------------------+--------------+---------------+
-            | 32  | Reserved                                                             |
-            +-----+----------------------------------------------------------------------+
-            | 64  | Home Address                                                         |
-            |     |                                                                      |
-            |     |                                                                      |
-            |     |                                                                      |
-            +-----+----------------------------------------------------------------------+
-
- - - - - The number of bytes the routing data takes. - - - - - Creates an instance from next header, segments left and home address. - - - Identifies the type of header immediately following this extension header. - - - Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. - - - The home address of the destination mobile node. - - - - - Identifier of a particular Routing header variant. - - - - - The home address of the destination mobile node. - - - - - RFC 2460. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | Options                               |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Creates an instance from next header and options. - - Identifies the type of header immediately following this extension header. - Options for the extension header. - - - - Identifies the type of this extension header. - - - - - RFC 6757. - 
-            +-----+----------+------------+
-            | Bit | 0-7      | 8-15       |
-            +-----+----------+------------+
-            | 0   | ANI Type | ANI Length |
-            +-----+----------+------------+
-            | 16  | Option Data           |
-            | ... |                       |
-            +-----+-----------------------+
-
- - - - - Creates an instance from type and data. - - The type of the option. - The data of the option. - - - - The data of the option. - - - - - RFC-ietf-netext-pmip-lr-10. - 
-            +-----+---+----------+-------------------------+
-            | Bit | 0 | 3-7      | 8-15                    |
-            +-----+---+----------+-------------------------+
-            | 0   | Next Header  | Header Extension Length |
-            +-----+--------------+-------------------------+
-            | 16  | MH Type      | Reserved                |
-            +-----+--------------+-------------------------+
-            | 32  | Checksum                               |
-            +-----+----------------------------------------+
-            | 48  | Sequence #                             |
-            +-----+---+----------+-------------------------+
-            | 64  | U | Reserved | Status                  |
-            +-----+---+----------+-------------------------+
-            | 80  | Lifetime                               |
-            +-----+----------------------------------------+
-            | 96  | Mobility Options                       |
-            | ... |                                        |
-            +-----+----------------------------------------+
-
- - - - - Creates an instance from next header, checksum, sequence number, unsolicited, status, lifetime and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Copied from the sequence number field of the LRI message being responded to. - - When true, the LRA message is sent unsolicited. - The Lifetime field indicates a new requested value. - The MAG must wait for the regular LRI message to confirm that the request is acceptable to the LMA. - - The acknowledgement status. - - The time in seconds for which the local forwarding is supported. - Typically copied from the corresponding field in the LRI message. - - Zero or more TLV-encoded mobility options. - - - - When true, the LRA message is sent unsolicited. - The Lifetime field indicates a new requested value. - The MAG must wait for the regular LRI message to confirm that the request is acceptable to the LMA. - - - - - The acknowledgement status. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - RFC 5142. - 
-            +-----+----------------+-------------------------+
-            | Bit | 0-7            | 8-15                    |
-            +-----+----------------+-------------------------+
-            | 0   | Next Header    | Header Extension Length |
-            +-----+----------------+-------------------------+
-            | 16  | MH Type        | Reserved                |
-            +-----+----------------+-------------------------+
-            | 32  | Checksum                                 |
-            +-----+----------------+-------------------------+
-            | 48  | # of Addresses | Reserved                |
-            +-----+----------------+-------------------------+
-            | 64  | Home Agent Addresses                     |
-            | ... |                                          |
-            +-----+------------------------------------------+
-            |     | Mobility Options                         |
-            | ... |                                          |
-            +-----+------------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, home agent addresses and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - A list of alternate home agent addresses for the mobile node. - Zero or more TLV-encoded mobility options. - - - - Creates an instance from next header, checksum, home agent addresses and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - A list of alternate home agent addresses for the mobile node. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - A list of alternate home agent addresses for the mobile node. - - - - - RFCs 3963, 4140, 5213, 5380, 5555, 5845, 6275, 6602. - 
-            +-----+---+---+---+---+---+---+---+---+---+---+-----------------+
-            | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10-15           |
-            +-----+---+---+---+---+---+---+---+---+---+---+-----------------+
-            | 0   | Next Header                   | Header Extension Length |
-            +-----+-------------------------------+-------------------------+
-            | 16  | MH Type                       | Reserved                |
-            +-----+-------------------------------+-------------------------+
-            | 32  | Checksum                                                |
-            +-----+---------------------------------------------------------+
-            | 48  | Sequence #                                              |
-            +-----+---+---+---+---+---+---+---+---+---+---+-----------------+
-            | 64  | A | H | L | K | M | R | P | F | T | B | Reserved        |
-            +-----+---+---+---+---+---+---+---+---+---+---+-----------------+
-            | 80  | Lifetime                                                |
-            +-----+---------------------------------------------------------+
-            | 96  | Mobility Options                                        |
-            | ... |                                                         |
-            +-----+---------------------------------------------------------+
-
- - - - - Creates an instance from next header, checksum, sequence number, acknowledge, home registration, link local address compatibility, - key management mobiltiy capability, map registration, mobile router, proxy registration flag, forcing UDP encapsulation, TLV header format, - bulk binding update, lifetime and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. - - - Set by the sending mobile node to request a Binding Acknowledgement be returned upon receipt of the Binding Update. - For Fast Binding Update this must be set to one to request that PAR send a Fast Binding Acknowledgement message. - - - Set by the sending mobile node to request that the receiving node should act as this node's home agent. - The destination of the packet carrying this message must be that of a router sharing the same subnet prefix as the home address - of the mobile node in the binding. - For Fast Binding Update this must be set to one. - - - Set when the home address reported by the mobile node has the same interface identifier as the mobile node's link-local address. - - - If this is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent - does not survive movements. - It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) - If manual IPsec configuration is used, the bit must be cleared. - - - Indicates MAP registration. - When a mobile node registers with the MAP, the MapRegistration and Acknowledge must be set to distinguish this registration - from a Binding Update being sent to the Home Agent or a correspondent node. - - - Indicates to the Home Agent that the Binding Update is from a Mobile Router. - If false, the Home Agent assumes that the Mobile Router is behaving as a Mobile Node, - and it must not forward packets destined for the Mobile Network to the Mobile Router. - - - Indicates to the local mobility anchor that the Binding Update message is a proxy registration. - Must be true for proxy registrations and must be false direct registrations sent by a mobile node. - - - Indicates a request for forcing UDP encapsulation regardless of whether a NAT is present on the path between the mobile node and the home agent. - May be set by the mobile node if it is required to use UDP encapsulation regardless of the presence of a NAT. - - - Indicates that the mobile access gateway requests the use of the TLV header for encapsulating IPv6 or IPv4 packets in IPv4. - - - If true, it informs the local mobility anchor to enable bulk binding update support for the mobility session associated with this message. - If false, the local mobility anchor must exclude the mobility session associated with this message from any bulk-binding-related operations - and any binding update, or binding revocation operations with bulk-specific scope will not be relevant to that mobility session. - This flag is relevant only for Proxy Mobile IPv6 and therefore must be set to false when the ProxyRegistration is false. - - - The number of time units remaining before the binding must be considered expired. - A value of zero indicates that the Binding Cache entry for the mobile node must be deleted. - One time unit is 4 seconds for Binding Update and 1 second for Fast Binding Update. - - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Indicates MAP registration. - When a mobile node registers with the MAP, the MapRegistration and Acknowledge must be set to distinguish this registration - from a Binding Update being sent to the Home Agent or a correspondent node. - - - - - Indicates to the Home Agent that the Binding Update is from a Mobile Router. - If false, the Home Agent assumes that the Mobile Router is behaving as a Mobile Node, - and it must not forward packets destined for the Mobile Network to the Mobile Router. - - - - - Indicates to the local mobility anchor that the Binding Update message is a proxy registration. - Must be true for proxy registrations and must be false direct registrations sent by a mobile node. - - - - - Indicates a request for forcing UDP encapsulation regardless of whether a NAT is present on the path between the mobile node and the home agent. - May be set by the mobile node if it is required to use UDP encapsulation regardless of the presence of a NAT. - - - - - Indicates that the mobile access gateway requests the use of the TLV header for encapsulating IPv6 or IPv4 packets in IPv4. - - - - - If true, it informs the local mobility anchor to enable bulk binding update support for the mobility session associated with this message. - If false, the local mobility anchor must exclude the mobility session associated with this message from any bulk-binding-related operations - and any binding update, or binding revocation operations with bulk-specific scope will not be relevant to that mobility session. - This flag is relevant only for Proxy Mobile IPv6 and therefore must be set to false when the ProxyRegistration is false. - - - - - Binding Error Status for Mobility Binding Error IPv6 Extension Header. - - - - - Invalid value. - - - - - RFC 6275. - - - - - RFC 6275. - Unrecognized MH Type value. - - - - - Each Group Record is a block of fields containing information pertaining - to the sender's membership in a single multicast group on the interface from which the Report is sent. - A Group Record has the following internal format: - 
-            +-----+-------------+--------------+--------+--------------+
-            | Bit | 0-7         | 8-15         | 16-31  |              |
-            +-----+-------------+--------------+--------+--------------+
-            | 0   | Record Type | Aux Data Len | Number of Sources (N) |
-            +-----+-------------+--------------+--------+--------------+
-            | 32  | Multicast Address                                  |
-            +-----+----------------------------------------------------+
-            | 64  | Source Address [1]                                 |
-            +-----+----------------------------------------------------+
-            | 96  | Source Address [2]                                 |
-            +-----+----------------------------------------------------+
-            .     .                         .                          .
-            .     .                         .                          .
-            +-----+----------------------------------------------------+
-            | 32  | Source Address [N]                                 |
-            | +   |                                                    |
-            | 32N |                                                    |
-            +-----+----------------------------------------------------+
-            | 64  | Auxiliary Data                                     |
-            . +   .                                                    .
-            . 32N .                                                    .
-            .     .                                                    .
-            |     |                                                    |
-            +-----+----------------------------------------------------+
-
- - - - - The number of bytes the group record header takes (without the source addresses and auxiliary data). - - - - - Creates an IGMP group record from the given datagram. - Useful to create a new IGMP packet with group records. - - - - - The record is valid if the length is correct according to the header fields. - - - - - The type of group record included in the report message. - - - - - The Aux Data Len field contains the length of the Auxiliary Data field in this Group Record, in bytes (after a translation from 32 bit words length). - It may contain zero, to indicate the absence of any auxiliary data. - - - - - The Number of Sources (N) field specifies how many source addresses are present in this Group Record. - - - - - The Multicast Address field contains the IP multicast address to which this Group Record pertains. - - - - - The Source Address [i] fields are a vector of n IP unicast addresses, - where n is the value in this record's Number of Sources (N) field. - - - - - The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. - The protocol specified in this document, IGMPv3, does not define any auxiliary data. - Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, - and MUST ignore any auxiliary data present in any received Group Record. - The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field. - - - - - Echo - RFC 792. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 0   | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-            | 32  | Data...                       |
-            +-----+-------------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - RFC 1256. - Represents an entry in Router Advertisement ICMP message. - - - - - Creates an instance using the given router address and preference. - - The sending router's IP address(es) on the interface from which this message is sent. - The preferability of each Router Address[i] as a default router address, relative to other router addresses on the same subnet. A signed, twos-complement value; higher values mean more preferable. - - - - Two entries are equal if they have the same router address and preference. - - - - - Two entries are equal if they have the same router address and preference. - - - - - A xor of the hash codes of the router address and preference. - - - - - The sending router's IP address(es) on the interface from which this message is sent. - - - - - The preferability of each Router Address[i] as a default router address, relative to other router addresses on the same subnet. A signed, twos-complement value; higher values mean more preferable. - - - - - RFC 792. - - - - - The value of this field determines the format of the remaining data. - - - - - A DNS string. - Any segment of bytes up to 255 characters is valid. - The format is one byte for the length of the string and then the specified number of bytes. - - - - - Creates the resource data from the given string. - - - - - Two string resource datas are equals if they have the same string. - - - - - Two string resource datas are equals if they have the same string. - - - - - The hash code of the string. - - - - - The value of the data. - - - - - RFC 4255. - - - - - Undefined value. - - - - - RFC 4255. - - - - - RFCs 2453, 2858, 4761, 6074. - - - - - No address family defined. - - - - - IP (IP version 4). - - - - - IP6 (IP version 6). - - - - - NSAP - Network Service Access Point. - - - - - High-Level Data Link (8-bit multidrop). - - - - - BBN Report 1822. - - - - - 802 (includes all 802 media plus Ethernet "canonical format"). - - - - - E.163. - - - - - E.164 (SMDS, Frame Relay, ATM). - - - - - F.69 (Telex). - - - - - X.121 (X.25, Frame Relay). - - - - - IPX. - - - - - Appletalk. - - - - - Decnet IV. - - - - - Banyan Vines. - - - - - E.164 with NSAP format subaddress. - ATM Forum UNI 3.1. October 1995. - Andy Malis. - - - - - DNS (Domain Name System). - - - - - Distinguished Name. - Charles Lynn. - - - - - AS Number. - Charles Lynn. - - - - - XTP over IP version 4. - Mike Saul. - - - - - XTP over IP version 6. - Mike Saul. - - - - - XTP native mode XTP. - Mike Saul. - - - - - Fibre Channel World-Wide Port Name. - Mark Bakke. - - - - - Fibre Channel World-Wide Node Name. - Mark Bakke. - - - - - GWID. - Subra Hegde. - - - - - RFCs 4761, 6074. - AFI for L2VPN information. - - - - - EIGRP Common Service Family. - Donnie Savage. - - - - - EIGRP IPv4 Service Family. - Donnie Savage. - - - - - EIGRP IPv6 Service Family. - Donnie Savage. - - - - - LISP Canonical Address Format (LCAF). - David Meyer. - - - - - Defines when and how to compress DNS domain names when creating a DNS datagram. - - - - - Compress any domain name if possible. - - - - - Never compress domain names. - - - - - IEEE 802.1Q. - 
-            +-----+-----+-----+------+------------------+
-            | bit | 0-2 | 3   | 4-15 | 16-31            |
-            +-----+-----+-----+------+------------------+
-            | 0   | TCI              | EtherType/Length |
-            +-----+-----+-----+------+------------------+
-            | 0   | PCP | CFI | VID  | EtherType/Length |
-            +-----+-----+-----+------+------------------+
-
- - - - - The number of bytes in the header takes. - - - - - The null VLAN ID. - Indicates that the tag header contains only priority information; no VLAN identifier is present in the frame. - This VID value shall not be configured as a PVID or a member of a VID Set, or configured in any Filtering Database entry, - or used in any Management operation. - - - - - The default PVID value used for classifying frames on ingress through a Bridge Port. - The PVID value of a Port can be changed by management. - - - - - Reserved for implementation use. - This VID value shall not be configured as a PVID or a member of a VID Set, or transmitted in a tag header. - This VID value may be used to indicate a wildcard match for the VID in management operations or Filtering Database entries. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - The datagram is valid if the length is correct according to the header. - - - - - Header length in bytes. - - - - - Indicates the frame priority level. - Values are from 0 (best effort) to 7 (highest); 1 represents the lowest priority. - These values can be used to prioritize different classes of traffic (voice, video, data, etc.). - - - - - If reset, all MAC Address information that may be present in the MSDU is in Canonical format and the tag comprises solely the TPID and TCI fields, - i.e., the tag does not contain an Embedded Routing Information Field (E-RIF). - - - - - A VLAN-aware Bridge may not support the full range of VID values but shall support the use of all VID values in the range 0 through a maximum N, - less than or equal to 4094 and specified for that implementation. - - - - - A combination of pcp (PriorityCodePoint), cfi (CanonicalFormatIndicator) and vid (VLanIdentifier). - - - - - Ethernet type (next protocol). - - - - - An unknown TCP option. - - - - - The minimum number of bytes this option take. - - - - - The minimum number of bytes this option's value take. - - - - - Creates an unknown TCP option by the given type and data. - - - - - The default unknown option is with type 255 and no data. - - - - - Creates an unknown option from its type and by reading a buffer for its value. - - The type of the unknown option. - The buffer of bytes to read the value of the unknown option. - The offset in the buffer to start reading the bytes. - The number of bytes to read from the buffer. - An option created from the given type and buffer. - - - - The data of the unknown option. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - RFC 1323. - TCP Timestamps Option (TSopt): - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | TS Value      |
-            |     | (TSval)       |
-            +-----+---------------+
-            | 48  | TS Echo Reply |
-            |     | (TSecr)       |
-            +-----+---------------+
-
- - - The Timestamps option carries two four-byte timestamp fields. - The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option. - - - - The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; - if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. - When TSecr is not valid, its value must be zero. - The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below. - - - - A TCP may send the Timestamps option (TSopt) in an initial <SYN> segment (i.e., segment containing a SYN bit and no ACK bit), - and may send a TSopt in other segments only if it received a TSopt in the initial <SYN> segment for the connection. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates the option from the given timestamp value and echo reply. - - - - - The default values for the timestamp value and echo reply are 0. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The timestamp value. - - - - - The echo reply value. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - TCP Echo Option: - 
-            +-----+------+----------+
-            | Bit | 0-7  | 8-15     |
-            +-----+------+----------+
-            | 0   | Kind | Length   |
-            +-----+------+----------+
-            | 16  | 4 bytes of info |
-            |     | to be echoed    |
-            +-----+-----------------+
-
- - - This option carries four bytes of information that the receiving TCP may send back in a subsequent TCP Echo Reply option. - A TCP may send the TCP Echo option in any segment, but only if a TCP Echo option was received in a SYN segment for the connection. - - - - When the TCP echo option is used for RTT measurement, it will be included in data segments, - and the four information bytes will define the time at which the data segment was transmitted in any format convenient to the sender. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates the option using the given echo info. - - - - - The default info is 0. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The info value of the option to be echoed. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - RFC 793. - TCP Header Format - 
-            +-----+-------------+----------+----+-----+-----+-----+-----+-----+-----+-----+-----+------------------+
-            | Bit | 0-3         | 4-6      | 7  | 8   | 9   | 10  | 11  | 12  | 13  | 14  | 15  | 16-31            |
-            +-----+-------------+----------+----+-----+-----+-----+-----+-----+-----+-----+-----+------------------+
-            | 0   | Source Port                                                                 | Destination Port |
-            +-----+-----------------------------------------------------------------------------+------------------+
-            | 32  | Sequence Number                                                                                |
-            +-----+------------------------------------------------------------------------------------------------+
-            | 64  | Acknowledgment Number                                                                          |
-            +-----+-------------+----------+----+-----+-----+-----+-----+-----+-----+-----+-----+------------------+
-            | 96  | Data Offset | Reserved | NS | CWR | ECE | URG | ACK | PSH | RST | SYN | FIN | Window           |
-            +-----+-------------+----------+----+-----+-----+-----+-----+-----+-----+-----+-----+------------------+
-            | 128 | Checksum                                                                    | Urgent Pointer   |
-            +-----+-----------------------------------------------------------------------------+------------------+
-            | 160 | Options + Padding                                                                              |
-            | ... |                                                                                                |
-            +-----+------------------------------------------------------------------------------------------------+
-
- - - - - The minimum number of bytes the header takes. - - - - - The maximum number of bytes the header takes. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - The datagram is valid if the length is correct according to the header and the options are valid. - - - - - The sequence number of the first data octet in this segment (except when SYN is present). - If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1. - - - - - The sequence number of the data that will come after this data. - - - - - If the ACK control bit is set this field contains the value of the next sequence number - the sender of the segment is expecting to receive. - Once a connection is established this is always sent. - - - - - The number of bytes in the TCP Header. - This indicates where the data begins. - The TCP header (even one including options) is an integral number of 32 bits (4 bytes) long. - - - - - Returns the actual header length. - - - - - Reserved for future use. - Must be zero. - - - - - A collection of bits for the TCP control. - - - - - The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept. - - - - - The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. - If a segment contains an odd number of header and text octets to be checksummed, - the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. - The pad is not transmitted as part of the segment. - While computing the checksum, the checksum field itself is replaced with zeros. - - The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. - This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. - This gives the TCP protection against misrouted segments. - This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls - by the TCP on the IP. - - +--------+--------+--------+--------+ - | Source Address | - +--------+--------+--------+--------+ - | Destination Address | - +--------+--------+--------+--------+ - | zero | PTCL | TCP Length | - +--------+--------+--------+--------+ - - The TCP Length is the TCP header length plus the data length in octets (this is not an explicitly transmitted quantity, but is computed), - and it does not count the 12 octets of the pseudo header. - - - - - True iff the checksum for the transport type is optional. - - - - - This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. - The urgent pointer points to the sequence number of the octet following the urgent data. - This field is only be interpreted in segments with the URG control bit set. - - - - - Returns the TCP options contained in this TCP Datagram. - - - - - The length of the TCP payload. - - - - - True iff the NonceSum control bit is turned on. - - - - - True iff the CongestionWindowReduced control bit is turned on. - - - - - True iff the ExplicitCongestionNotificationEcho control bit is turned on. - - - - - True iff the Urgent control bit is turned on. - - - - - True iff the Acknowledgment control bit is turned on. - - - - - True iff the Push control bit is turned on. - - - - - True iff the Reset control bit is turned on. - - - - - True iff the Synchronize control bit is turned on. - - - - - True iff the Fin control bit is turned on. - - - - - The first HTTP message in this TCP datagram. - - - - - All of the available HTTP messages in this TCP datagram. - - - - - The payload of the TCP datagram. - - - - - A raw packet. - Includes all packet layers as taken from an adapter including the type of the datalink. - Immutable. - - - - - Creates a packet from a string that represents bytes in a hexadecimal format. - - - - - Creates a packet from a string that represents bytes in a hexadecimal format. - - - - - Create a packet from an array of bytes. - - The bytes of the packet. This array should not be changed after creating the packet until the packet is no longer used. - A timestamp of the packet - when it was captured. - The type of the datalink of the packet. - - - - Create a packet from an array of bytes. - - The bytes of the packet. This array should not be changed after creating the packet until the packet is no longer used. - A timestamp of the packet - when it was captured. - The type of the datalink of the packet. - - - - Equals means that the packets have equal data. - - The packet to compare this packet to. - True iff the packets have equal data. - - - - Equals means that the packets have equal data. - - The packet to compare this packet to. - True iff the packets have equal data. - - - - The hash code of a packet is the xor of all its bytes. Each byte is xored with the next 8 bits of the integer. - - - - - The Packet string contains the datalink and the length. - - - - - Returns an enumerator that iterates through the bytes of the packet. - - - - - Returns the first offset in the packet that contains the given byte. - - - - - This operation is invalid because the object is immutable. - - - - - This operation is invalid because the object is immutable. - - - - - This operation is invalid because the object is immutable. - - - - - This operation is invalid because the object is immutable. - - - - - Determines whether the packet contains a specific byte. - - - - - Copies the bytes of the packet to a buffer, starting at a particular offset. - - - - - This operation is invalid because the object is immutable. - - - - - The number of bytes this packet take. - - - - - The time this packet was captured. - - - - - The type of the datalink of the device this packet was captured from. - - - - - The underlying array of bytes. - When taking this array the caller is responsible to make sure this array will not be modified while the packet is still in use. - - - - - Returns the value of the byte in the given offset. - Set operation is invalid because the object is immutable. - - - - - Returns the number of bytes in this packet. - - - - - True since this object is read only. - - - - - True iff the packet is valid. - The packet is valid unless an invalid part of it was found. - Examples for invalid parts: - * Bad checksum. - * An illegal value for a field. - * Length of packet is too short for a header or according to a length field. - - - - - Takes the entire packet as an Ethernet datagram. - Please note that if the DataLink is not Ethernet, this should make no sense. - - - - - Takes the entire packet as an IPv4 datagram. - Please note that if the DataLink is not IPv4, this should make no sense. - - - - - Stream Identifier option. - 
-            +--------+--------+--------+--------+
-            |10001000|00000010|    Stream ID    |
-            +--------+--------+--------+--------+
-             Type=136 Length=4
-
- - This option provides a way for the 16-bit SATNET stream identifier to be carried through networks that do not support the stream concept. - - Must be copied on fragmentation. - Appears at most once in a datagram. - - - - - The number of bytes this option take. - - - - - Create the option according to the given identifier. - - - - - Creates a 0 stream identifier - - - - - Two stream identifier options are equal if they have the same identifier. - - - - - Two stream identifier options are equal if they have the same identifier. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The identifier of the stream. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - Fragmentation information flags for IPv4 datagram. - - - - - May Fragment, Last Fragment. - - - - - More Fragments. - - - - - Don't Fragment. - - - - - RFC 2711. - - - - - RFC 2710. - Datagram contains a Multicast Listener Discovery message. - - - - - RFC 2711. - Datagram contains RSVP message. - - - - - RFC 2711. - Datagram contains an Active Networks message. - - - - - RFC 3175. - 1 depth of nesting of aggregation. - - - - - RFC 3175. - 2 depth of nesting of aggregation. - - - - - RFC 3175. - 3 depth of nesting of aggregation. - - - - - RFC 3175. - 4 depth of nesting of aggregation. - - - - - RFC 3175. - 5 depth of nesting of aggregation. - - - - - RFC 3175. - 6 depth of nesting of aggregation. - - - - - RFC 3175. - 7 depth of nesting of aggregation. - - - - - RFC 3175. - 8 depth of nesting of aggregation. - - - - - RFC 3175. - 9 depth of nesting of aggregation. - - - - - RFC 3175. - 10 depth of nesting of aggregation. - - - - - RFC 3175. - 11 depth of nesting of aggregation. - - - - - RFC 3175. - 12 depth of nesting of aggregation. - - - - - RFC 3175. - 13 depth of nesting of aggregation. - - - - - RFC 3175. - 14 depth of nesting of aggregation. - - - - - RFC 3175. - 15 depth of nesting of aggregation. - - - - - RFC 3175. - 16 depth of nesting of aggregation. - - - - - RFC 3175. - 17 depth of nesting of aggregation. - - - - - RFC 3175. - 18 depth of nesting of aggregation. - - - - - RFC 3175. - 19 depth of nesting of aggregation. - - - - - RFC 3175. - 20 depth of nesting of aggregation. - - - - - RFC 3175. - 21 depth of nesting of aggregation. - - - - - RFC 3175. - 22 depth of nesting of aggregation. - - - - - RFC 3175. - 23 depth of nesting of aggregation. - - - - - RFC 3175. - 24 depth of nesting of aggregation. - - - - - RFC 3175. - 25 depth of nesting of aggregation. - - - - - RFC 3175. - 26 depth of nesting of aggregation. - - - - - RFC 3175. - 27 depth of nesting of aggregation. - - - - - RFC 3175. - 28 depth of nesting of aggregation. - - - - - RFC 3175. - 29 depth of nesting of aggregation. - - - - - RFC 3175. - 30 depth of nesting of aggregation. - - - - - RFC 3175. - 31 depth of nesting of aggregation. - - - - - RFC 3175. - 32 depth of nesting of aggregation. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 0. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 1. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 2. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 3. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 4. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 5. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 6. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 7. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 8. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 9. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 10. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 11. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 12. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 13. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 14. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 15. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 16. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 17. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 18. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 19. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 20. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 21. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 22. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 23. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 24. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 25. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 26. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 27. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 28. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 29. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 30. - - - - - RFC 5974. - QualityOfService NSLP Aggregation Level 31. - - - - - RFC 5973. - NSIS NATFW NSLP. - - - - - RFC 4285. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Timestamp                  |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from timestamp. - - 64 bit timestamp. - - - - 64 bit timestamp. - - - - - RFC 4866. - 
-            +-----+-------------+---------------+
-            | Bit | 0-7         | 8-15          |
-            +-----+-------------+---------------+
-            | 0   | Option Type | Opt Data Len  |
-            +-----+-------------+---------------+
-            | 16  | Permanent Home Keygen Token |
-            | ... |                             |
-            +-----+-----------------------------+
-
- - - - - Creates an option from the given permanent home keygen token. - - - Contains the permanent home keygen token generated by the correspondent node. - The content of this field must be encrypted with the mobile node's public key. - The length of the permanent home keygen token is 8 octets before encryption, though the ciphertext and, hence, - the Permanent Home Keygen Token field may be longer. - - - - - Contains the permanent home keygen token generated by the correspondent node. - The content of this field must be encrypted with the mobile node's public key. - The length of the permanent home keygen token is 8 octets before encryption, though the ciphertext and, hence, - the Permanent Home Keygen Token field may be longer. - - - - - RFC 6275. - 
-            +-----+--------------+--------------+
-            | Bit | 0-7          | 8-15         |
-            +-----+--------------+--------------+
-            | 0   | Option Type  | Opt Data Len |
-            +-----+--------------+--------------+
-            | 16  | Home Nonce Index            |
-            +-----+-----------------------------+
-            | 32  | Care-of Nonce Index         |
-            +-----+-----------------------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an instance from home nounce index and care of nonce index. - - - Tells the correspondent node which nonce value to use when producing the home keygen token. - - - Ignored in requests to delete a binding. - Otherwise, it tells the correspondent node which nonce value to use when producing the care-of keygen token. - - - - - Tells the correspondent node which nonce value to use when producing the home keygen token. - - - - - Ignored in requests to delete a binding. - Otherwise, it tells the correspondent node which nonce value to use when producing the care-of keygen token. - - - - - RFC 5568. - 
-            +-----+-------------+---------------+
-            | Bit | 0-7         | 8-15          |
-            +-----+-------------+---------------+
-            | 0   | Option Type | Opt Data Len  |
-            +-----+-------------+---------------+
-            | 16  | Option-Code | Prefix Length |
-            +-----+-------------+---------------+
-            | 32  | IPv6 Address/Prefix         |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            +-----+-----------------------------+
-
- - - - - The maximum value for prefix length. - - - - - The number of bytes this option data takes. - - - - - Creates an instance from code, prefix length and address or prefix. - - Describes the kind of the address or the prefix. - - Indicates the length of the IPv6 Address Prefix. - The value ranges from 0 to 128. - - The IP address/prefix defined by the Option-Code field. - - - - Describes the kind of the address or the prefix. - - - - - Indicates the length of the IPv6 Address Prefix. - The value ranges from 0 to 128. - - - - - The IP address/prefix defined by the Option-Code field. - - - - - RFC 6089. - 
-            +-----+--------------+-------------+
-            | Bit | 0-7          | 8-15        |
-            +-----+--------------+-------------+
-            | 0   | Sub-Opt Type | Sub-Opt Len | 
-            +-----+--------------+-------------+
-            | 16  | BIDs                       |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from a list of binding ids. - - - Indicates the BIDs that the mobile node wants to associate with the flow identification option. - One or more BID fields can be included in this sub-option. - - - - - Creates an instance from an array of binding ids. - - - Indicates the BIDs that the mobile node wants to associate with the flow identification option. - One or more BID fields can be included in this sub-option. - - - - - Creates an instance from an enumerable of binding ids. - - - Indicates the BIDs that the mobile node wants to associate with the flow identification option. - One or more BID fields can be included in this sub-option. - - - - - Creates an instance from a collection of binding ids. - - - Indicates the BIDs that the mobile node wants to associate with the flow identification option. - One or more BID fields can be included in this sub-option. - - - - - Indicates the BIDs that the mobile node wants to associate with the flow identification option. - One or more BID fields can be included in this sub-option. - - - - - RFC 6757. - - - - - Creates options from a list of options. - - The list of options. - - - - Creates options from a list of options. - - The list of options. - - - - No options instance. - - - - - RFC 792. - 
-            +-----+------+------+------------+
-            | Bit | 0-7  | 8-15 | 16-31      |
-            +-----+------+------+------------+
-            | 0   | Type | Code | Checksum   |
-            +-----+------+------+------------+
-            | 0   | Gateway Internet Address |
-            +-----+--------------------------+
-            | 32  | Internet Header          |
-            |     | + 64 bits of             |
-            |     | Original Data Datagram   |
-            +-----+--------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Address of the gateway to which traffic for the network specified in the internet destination network field of the original datagram's data should be sent. - - - - - The minimum valid ICMP code for this type of ICMP datagram. - - - - - The maximum valid ICMP code for this type of ICMP datagram. - - - - - RFC 792. - - - - - The value of this field determines the format of the remaining data. - - - - - RFC 792. - - - - - The pointer identifies the octet of the original datagram's header where the error was detected (it may be in the middle of an option). - For example, 1 indicates something is wrong with the Type of Service, and (if there are options present) 20 indicates something is wrong with the type code of the first option. - - - - - The value of this field determines the format of the remaining data. - - - - - A value that should be interpreted according to the specific message. - - - - - RFC 792. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Echo Reply - RFC 792. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 0   | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-            | 32  | Data...                       |
-            +-----+-------------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - The different ICMP code values for Redirect ICMP type. - - - - - RFC 792. - - - - - RFC 792. - - - - - RFC 792. - - - - - RFC 792. - - - - - HTTP request method. - Example: GET - - - - - Creates a method from a method string. - - - - - Creates a method from a known method. - - - - - Two methods are equal iff they have the same method string. - - - - - Two methods are equal iff they have the same method string. - - - - - The hash code of the method string. - - - - - The method string. - - - - - Returns the known method that matches the method string. - Returns HttpRequestKnownMethod.Unknown if no matching known method could be found. - - - - - The number of bytes this method takes. - - - - - RFC 1702. - Represents a source route entry consisting of a list of IP addresses and indicates an IP source route. - - - - - Initializes using the given IP addresses and the next as number index. - - IP addresses of the source route. - The next IP address index in the source route. - - - - True iff the IP addresses are equal. - - - - - Writes the payload to the given buffer in the given offset. - - The buffer to write the payload to. - The offset in the buffer to start writing. - - - - The Address Family field contains a two octet value which indicates the syntax and semantics of the Routing Information field. - - - - - The SRE Length field contains the number of octets in the SRE. - - - - - The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined. - - - - - The xor of the hash code of the IP addresses. - - - - - IP addresses of the source route. - - - - - The next IP address index in the source route. - - - - - The next IP address. - - - - - Represents an Ethernet datagram. - - 
-            +------+-----------------+------------+------------------+
-            | Byte | 0-5             | 6-11       | 12-13            |
-            +------+-----------------+------------+------------------+
-            | 0    | MAC Destination | MAC Source | EtherType/Length |
-            +------+-----------------+------------+------------------+
-            | 14   | Data                                            |
-            +------+-------------------------------------------------+
-
- - - - - Ethernet header length in bytes. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - An Ethernet datagram is valid iff its length is big enough for the header and its payload is valid. - - - - - Header length in bytes. - - - - - The broadcast MAC address (FF:FF:FF:FF:FF:FF). - - - - - The Ethernet payload length in bytes. - - - - - Ethernet source address. - - - - - Ethernet destination address. - - - - - Ethernet type (next protocol). - - - - - Represents an Ethernet layer. - - - - - - Creates an instance with zero values. - - - - - Writes the layer to the buffer. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - The length of the layer's payload (the number of bytes after the layer in the packet). - The layer that comes before this layer. null if this is the first layer. - The layer that comes after this layer. null if this is the last layer. - - - - Two Ethernet layers are equal if they have the same source, destination and ethernet type. - - - - - Two Ethernet layers are equal if they have the same source, destination and ethernet type. - - - - - Returns a hash code for the layer. - The hash code is a XOR of the hash codes of the layer length, data link, source and destination addresses and the ethernet type. - - - - - Contains the source, destination and ether type. - - - - - - Ethernet source address. - - - - - Ethernet destination address. - - - - - The number of bytes this layer will take. - - - - - The kind of the data link of the layer. - Can be null if this is not the first layer in the packet. - - - - - RFC 2163. - 
-            +-----+------------+
-            | bit | 0-15       |
-            +-----+------------+
-            | 0   | Preference |
-            +-----+------------+
-            | 16  | MAP822     |
-            | ... |            |
-            +-----+------------+
-            |     | MAPX400    |
-            | ... |            |
-            +-----+------------+
-
- - - - - Constructs an instance out of the preference, map822 and mapX400 fields. - - The preference given to this RR among others at the same owner. Lower values are preferred. - RFC 822 domain. The RFC 822 part of the MCGAM. - The value of x400-in-domain-syntax derived from the X.400 part of the MCGAM. - - - - Two DnsResourceDataX400Pointer are equal iff their preference, map822 and mapX400 fields are equal. - - - - - Two DnsResourceDataX400Pointer are equal iff their preference, map822 and mapX400 fields are equal. - - - - - A hash code of the combination of the preference, map822 and mapX400 fields. - - - - - The preference given to this RR among others at the same owner. - Lower values are preferred. - - - - - RFC 822 domain. - The RFC 822 part of the MCGAM. - - - - - The value of x400-in-domain-syntax derived from the X.400 part of the MCGAM. - - - - - A resource data that contains 0 or more DNS strings. - Each DNS string is a segment of up to 255 bytes. - The format of each DNS string is one byte for the length of the string and then the specified number of bytes. - - - - - Constructs the resource data from the given list of strings, each up to 255 bytes. - - - - - The list of strings, each up to 255 bytes. - - - - - RFC 2782. - 
-            +-----+----------+
-            | bit | 0-15     |
-            +-----+----------+
-            | 0   | Priority |
-            +-----+----------+
-            | 16  | Weight   |
-            +-----+----------+
-            | 32  | Port     |
-            +-----+----------+
-            | 48  | Target   |
-            | ... |          |
-            +-----+----------+
-
- - - - - Constructs an instance out of the priority, weight, port and target fields. - - - The priority of this target host. - A client must attempt to contact the target host with the lowest-numbered priority it can reach; - target hosts with the same priority should be tried in an order defined by the weight field. - - - A server selection mechanism. - The weight field specifies a relative weight for entries with the same priority. - Larger weights should be given a proportionately higher probability of being selected. - Domain administrators should use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy). - In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected. - - In the absence of a protocol whose specification calls for the use of other weighting information, a client arranges the SRV RRs of the same Priority in the order in which target hosts, - specified by the SRV RRs, will be contacted. - The following algorithm SHOULD be used to order the SRV RRs of the same priority: - To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. - Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. - Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. - The target host specified in the selected SRV RR is the next one to be contacted by the client. - Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. - Continue the ordering process until there are no unordered SRV RRs. - This process is repeated for each Priority. - - The port on this target host of this service. This is often as specified in Assigned Numbers but need not be. - - The domain name of the target host. - There must be one or more address records for this name, the name must not be an alias (in the sense of RFC 1034 or RFC 2181). - Implementors are urged, but not required, to return the address record(s) in the Additional Data section. - Unless and until permitted by future standards action, name compression is not to be used for this field. - - A Target of "." means that the service is decidedly not available at this domain. - - - - - Two DnsResourceDataServerSelection are equal iff their priority, weight, port and target fields are equal. - - - - - Two DnsResourceDataServerSelection are equal iff their priority, weight, port and target fields are equal. - - - - - A hash code of the combination of the priority, weight, port and target fields. - - - - - The priority of this target host. - A client must attempt to contact the target host with the lowest-numbered priority it can reach; - target hosts with the same priority should be tried in an order defined by the weight field. - - - - - A server selection mechanism. - The weight field specifies a relative weight for entries with the same priority. - Larger weights should be given a proportionately higher probability of being selected. - Domain administrators should use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy). - In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected. - - In the absence of a protocol whose specification calls for the use of other weighting information, a client arranges the SRV RRs of the same Priority in the order in which target hosts, - specified by the SRV RRs, will be contacted. - The following algorithm SHOULD be used to order the SRV RRs of the same priority: - To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. - Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. - Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. - The target host specified in the selected SRV RR is the next one to be contacted by the client. - Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. - Continue the ordering process until there are no unordered SRV RRs. - This process is repeated for each Priority. - - - - - The port on this target host of this service. - This is often as specified in Assigned Numbers but need not be. - - - - - The domain name of the target host. - There must be one or more address records for this name, the name must not be an alias (in the sense of RFC 1034 or RFC 2181). - Implementors are urged, but not required, to return the address record(s) in the Additional Data section. - Unless and until permitted by future standards action, name compression is not to be used for this field. - - A Target of "." means that the service is decidedly not available at this domain. - - - - - RFC 1183. - 
-            +-----+-------------------+
-            | bit | 0-15              |
-            +-----+-------------------+
-            | 0   | preference        |
-            +-----+-------------------+
-            | 16  | intermediate-host |
-            | ... |                   |
-            +-----+-------------------+
-
- - - - - Constructs a route through resource data from the given preference and intermediate host. - - - Representing the preference of the route. - Smaller numbers indicate more preferred routes. - - - The domain name of a host which will serve as an intermediate in reaching the host specified by the owner. - The DNS RRs associated with IntermediateHost are expected to include at least one A, X25, or ISDN record. - - - - - Representing the preference of the route. - Smaller numbers indicate more preferred routes. - - - - - The domain name of a host which will serve as an intermediate in reaching the host specified by the owner. - The DNS RRs associated with IntermediateHost are expected to include at least one A, X25, or ISDN record. - - - - - RFC 1712. - 
-            +-----------+
-            | LONGITUDE |
-            +-----------+
-            | LATITUDE  |
-            +-----------+
-            | ALTITUDE  |
-            +-----------+
-
- - - - - Constructs an instnace from the longitude, latitude and altitude fields. - - - The real number describing the longitude encoded as a printable string. - The precision is limited by 256 charcters within the range -90..90 degrees. - Positive numbers indicate locations north of the equator. - - - The real number describing the latitude encoded as a printable string. - The precision is limited by 256 charcters within the range -180..180 degrees. - Positive numbers indicate locations east of the prime meridian. - - - The real number describing the altitude (in meters) from mean sea-level encoded as a printable string. - The precision is limited by 256 charcters. - Positive numbers indicate locations above mean sea-level. - - - - - Two DnsResourceDataGeographicalPosition are equal if their longitude, latitude and altitude fields are equal. - - - - - Two DnsResourceDataGeographicalPosition are equal if their longitude, latitude and altitude fields are equal. - - - - - A hash code of the combined longitude, latitude and altitude fields. - - - - - The real number describing the longitude encoded as a printable string. - The precision is limited by 256 charcters within the range -90..90 degrees. - Positive numbers indicate locations north of the equator. - - - - - The real number describing the latitude encoded as a printable string. - The precision is limited by 256 charcters within the range -180..180 degrees. - Positive numbers indicate locations east of the prime meridian. - - - - - The real number describing the altitude (in meters) from mean sea-level encoded as a printable string. - The precision is limited by 256 charcters. - Positive numbers indicate locations above mean sea-level. - - - - - A collection of TCP options. - - - - - The maximum number of bytes the options can take. - - - - - Creates the options collection from the given list of options. - - - - - Creates options from a list of options. - - The list of options. - - - - An empty options collection. - - - - - The type of the checksum to be used. - - - - - TCP checksum. - - - - - 8-bit Fletcher's algorithm. - - - - - 16-bit Fletcher's algorithm. - - - - - The presence of this option in an ICMP Echo (or any other) packet, hereinafter referred to as the Outbound Packet, - will cause a router to send the newly defined ICMP Traceroute message to the originator of the Outbound Packet. - In this way, the path of the Outbound Packet will be logged by the originator with only n+1 (instead of 2n) packets. - This algorithm does not suffer from a changing path and allows the response to the Outbound Packet, - hereinafter refered to as the Return Packet, to be traced - (provided the Outbound Packet's destination preserves the IP Traceroute option in the Return Packet). - - - IP Traceroute option format - 
-             0               8              16              24
-            +-+---+---------+---------------+-------------------------------+
-            |F| C |  Number |    Length     |          ID Number            |
-            +-+---+-------------------------+-------------------------------+
-            |      Outbound Hop Count       |       Return Hop Count        |
-            +-------------------------------+-------------------------------+
-            |                     Originator IP Address                     |
-            +---------------------------------------------------------------+
-
- - - - F (copy to fragments): 0 (do not copy to fragments) - C (class): 2 (Debugging and Measurement) - Number: 18 (F+C+Number = 82) - - - - - - The number of bytes this option take. - - - - - The number of bytes this option's value take. - - - - - Create the trace route option from the trace route option values. - - - An arbitrary number used by the originator of the Outbound Packet to identify the ICMP Traceroute messages. - It is NOT related to the ID number in the IP header. - - - Outbound Hop Count (OHC) - The number of routers through which the Outbound Packet has passed. - This field is not incremented by the Outbound Packet's destination. - - - Return Hop Count (RHC) - The number of routers through which the Return Packet has passed. - This field is not incremented by the Return Packet's destination. - - The IP address of the originator of the Outbound Packet. - This isneeded so the routers know where to send the ICMP Traceroute message for Return Packets. - It is also needed for Outbound Packets which have a Source Route option. - - - - - Creates empty trace route option. - - - - - Two trace route options are equal iff they have the exact same field values. - - - - - Two trace route options are equal iff they have the exact same field values. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - An arbitrary number used by the originator of the Outbound Packet to identify the ICMP Traceroute messages. - It is NOT related to the ID number in the IP header. - - - - - The IP address of the originator of the Outbound Packet. - This isneeded so the routers know where to send the ICMP Traceroute message for Return Packets. - It is also needed for Outbound Packets which have a Source Route option. - - - - - Outbound Hop Count (OHC) - The number of routers through which the Outbound Packet has passed. - This field is not incremented by the Outbound Packet's destination. - - - - - Return Hop Count (RHC) - The number of routers through which the Return Packet has passed. - This field is not incremented by the Return Packet's destination. - /// - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - A simple IPv4 option - holds only the type. - - - - - The number of bytes this option will take. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - TCP Authentication Option (RFC 5925). - - - The format of the TCP Authentication Option is: - 
-            +-----+------------+
-            | Bit | 0-7        |
-            +-----+------------+
-            | 0   | Kind       | 
-            +-----+------------+
-            | 8   | Length     |
-            +-----+------------+
-            | 16  | KeyId      |
-            +-----+------------+
-            | 24  | RNextKeyId |
-            +-----+------------+
-            | 32  | MAC        |
-            | ... |            |
-            +-----+------------+
-
- - - - The TCP Authentication Option provides a superset of the capabilities of TCP MD5. - - - - The contents of the Message Authentication Code (MAC), are determined by the particulars of the security association. - Typical MACs are 96-128 bits (12-16 bytes), but any length that fits in the header of the segment being authenticated is allowed. - - - - - - - The minimum number of bytes this option takes. - - - - - The minimum number of bytes this option's value takes. - - - - - Creates the option using the given values. - - The Master Key Tuple used to generate the Message Authentication Code that authenticates this segment. - The desired Master Key Tuple that the sender would like to use to authenticate future received segments. - The Message Authentication Code (MAC). The contents of the MAC are determined by the particulars of the security association. - - - - The default option values are zero for each key id field and no Message Authentication Code data. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The Master Key Tuple used to generate the Message Authentication Code that authenticates this segment. - - - - - The desired Master Key Tuple that the sender would like to use to authenticate future received segments. - - - - - The Message Authentication Code (MAC). The contents of the MAC are determined by the particulars of the security association. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - List of IPv6 options for some of the IPv6 extension headers. - - - - - Creates the list of options from a given IList of otpions. - - List of options to build the set from. - - - - Creates the list of options from a given IEnumerable of otpions. - - List of options to build the set from. - - - - Creates the list of options from a given array of otpions. - - List of options to build the set from. - - - - Empty set of options. - - - - - RFC 2675. - 
-            +-----+-------------+--------+
-            | Bit | 0-7         | 8-15   |
-            +-----+-------------+--------+
-            | 0   | Option Type | 4      |
-            +-----+-------------+--------+
-            | 16  | Jumbo Payload Length |
-            |     |                      |
-            +-----+----------------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an option from the given jumbo payload length. - - - Length of the IPv6 packet in octets, excluding the IPv6 header but including the Hop-by-Hop Options header and any other extension headers present. - Must be greater than 65,535. - - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - Length of the IPv6 packet in octets, excluding the IPv6 header but including the Hop-by-Hop Options header and any other extension headers present. - Must be greater than 65,535. - - - - - RFC irtf-rrg-ilnp-noncev6-06. - http://tools.ietf.org/html/draft-irtf-rrg-ilnp-noncev6-06 - IPv6 Nonce Destination Option for ILNPv6. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Nonce Value                |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from nonce. - - An unpredictable cryptographically random value used to prevent off-path attacks on an ILNP session. - - - - Parses an option from the given data. - - The data to parse. - The option if parsing was successful, null otherwise. - - - - An unpredictable cryptographically random value used to prevent off-path attacks on an ILNP session. - - - - - RFC 5149. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Identifier                 |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The minimum value that Identifier can be set to. - - - - - The maximum value that Identifier can be set to. - - - - - Creates an instance from the given identifier. - - - Encoded service identifier string used to identify the requested service. - The identifier string length is between 1 and 255 octets. - This specification allows international identifier strings that are based on the use of Unicode characters, encoded as UTF-8, - and formatted using Normalization Form KC (NFKC). - - 'ims', 'voip', and 'voip.companyxyz.example.com' are valid examples of Service Selection option Identifiers. - At minimum, the Identifier must be unique among the home agents to which the mobile node is authorized to register. - - - - - Encoded service identifier string used to identify the requested service. - The identifier string length is between 1 and 255 octets. - This specification allows international identifier strings that are based on the use of Unicode characters, encoded as UTF-8, - and formatted using Normalization Form KC (NFKC). - - 'ims', 'voip', and 'voip.companyxyz.example.com' are valid examples of Service Selection option Identifiers. - At minimum, the Identifier must be unique among the home agents to which the mobile node is authorized to register. - - - - - RFC 5213. - 
-            +-----+--------------+---------------+
-            | Bit | 0-7          | 8-15          |
-            +-----+--------------+---------------+
-            | 0   | Option Type  | Opt Data Len  |
-            +-----+--------------+---------------+
-            | 16  | Reserved     | Prefix Length |
-            +-----+--------------+---------------+
-            | 32  | Mobile Network Prefix        |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            +-----+------------------------------+
-
- - - - - Creates an instance from prefix length and home network prefix. - - Indicates the prefix length of the IPv6 prefix contained in the option. - Contains the Home Network Prefix. - - - - RFC 4866. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-
- - - - - Creates an instance. - - - - - RFC 6089. - - - - - Flow binding successful. - - - - - Administratively prohibited - - - - - Flow binding rejected, reason unspecified - - - - - Flow identification mobility option malformed. - - - - - BID not found. - - - - - FID not found. - - - - - Traffic selector format not supported. - - - - - RFC 5555. - - - - - Success. - - - - - Failure, reason unspecified. - - - - - Administratively prohibited. - - - - - Incorrect IPv4 home address. - - - - - Invalid IPv4 address. - - - - - Dynamic IPv4 home address assignment not available. - - - - - Prefix allocation unauthorized. - - - - - RFCs 4068, 5568. - Deprecated. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Reserved                              |
-            +-----+---------------------------------------+
-            | 64  | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum and options. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Zero or more TLV-encoded mobility options. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - RFC 5096. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+-------------+-------------------------+
-            | 48  | Message Data                          |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Creates an instance from next header, checksum and message data. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Carries the data specific to the experimental protocol extension. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Carries the data specific to the experimental protocol extension. - - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Care-of Nonce Index                   |
-            +-----+---------------------------------------+
-            | 64  | Care-of Init Cookie                   |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            +-----+---------------------------------------+
-            | 128 | Care-of Keygen Token                  |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            +-----+---------------------------------------+
-            | 192 | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, care of nonce index, care of init cookie, care of keygen token and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update. - Contains the care-of init cookie. - Contains the 64-bit care-of keygen token used in the return routability procedure. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update. - - - - - Contains the care-of init cookie. - - - - - Contains the 64-bit care-of keygen token used in the return routability procedure. - - - - - RFC 792. - - - - - The value of this field determines the format of the remaining data. - - - - - A value representing the syntax and semantics of the Routing Information field. - - - - - No address family - - - - - The Routing Information field will consist of a list of IP addresses and indicates an IP source route. - - - - - the Routing Information field will consist of a list of Autonomous System numbers and indicates an AS source route. - - - - - RFC 2930. - - - - - Undefined value. - - - - - RFC 2930. - - - - - RFC 2930. - - - - - RFC 2930. - - - - - RFC 2930. - - - - - RFC 2930. - - - - - RFC 5155. - - - - - Undefined value. - - - - - RFC 5155. - Indicates whether this NSEC3 RR may cover unsigned delegations. - If set, the NSEC3 record covers zero or more unsigned delegations. - If clear, the NSEC3 record covers zero unsigned delegations. - - - - - RFCs 2535, 4034. - 
-            +-----+--------------+-----------+--------+
-            | bit | 0-15         | 16-23     | 24-31  |
-            +-----+--------------+-----------+--------+
-            | 0   | type covered | algorithm | labels |
-            +-----+--------------+-----------+--------+
-            | 32  | original TTL                      |
-            +-----+-----------------------------------+
-            | 64  | signature expiration              |
-            +-----+-----------------------------------+
-            | 96  | signature inception               |
-            +-----+--------------+--------------------+
-            | 128 | key tag      |                    |
-            +-----+--------------+ signer's name      |
-            | ... |                                   |
-            +-----+-----------------------------------+
-            |     | signature                         |
-            | ... |                                   |
-            +-----+-----------------------------------+
-
- - - - - Constructs an instance out of the type covered, algorithm, labels, original TTL, signature expiration, signature inception, key tag, - signer's name and signature fields. - - The type of the other RRs covered by this SIG. - The key algorithm. - - An unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. - If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. - This field makes it easy to determine the original form. - - If, on retrieval, the RR appears to have a longer name than indicated by "labels", the resolver can tell it is the result of wildcard substitution. - If the RR owner name appears to be shorter than the labels count, the SIG RR must be considered corrupt and ignored. - The maximum number of labels allowed in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. - - - The "original TTL" field is included in the RDATA portion to avoid - (1) authentication problems that caching servers would otherwise cause by decrementing the real TTL field and - (2) security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. - This original TTL is protected by the signature while the current TTL field is not. - - NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified. - This generaly implies that all RRs for a particular type, name, and class, that is, all the RRs in any particular RRset, must have the same TTL to start with. - - - The last time the signature is valid. - Numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. - Ring arithmetic is used. - This time can never be more than about 68 years after the inception. - - - The first time the signature is valid. - Numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. - Ring arithmetic is used. - This time can never be more than about 68 years before the expiration. - - - Used to efficiently select between multiple keys which may be applicable and thus check that a public key about to be used - for the computationally expensive effort to check the signature is possibly valid. - For algorithm 1 (MD5/RSA) as defined in RFC 2537, - it is the next to the bottom two octets of the public key modulus needed to decode the signature field. - That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order. - For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR. - - - The domain name of the signer generating the SIG RR. - This is the owner name of the public KEY RR that can be used to verify the signature. - It is frequently the zone which contained the RRset being authenticated. - Which signers should be authorized to sign what is a significant resolver policy question. - The signer's name may be compressed with standard DNS name compression when being transmitted over the network. - - - The actual signature portion of the SIG RR binds the other RDATA fields to the RRset of the "type covered" RRs with that owner name and class. - This covered RRset is thereby authenticated. - To accomplish this, a data sequence is constructed as follows: - - data = RDATA | RR(s)... - - where "|" is concatenation, - - RDATA is the wire format of all the RDATA fields in the SIG RR itself (including the canonical form of the signer's name) before but not including the signature, - and RR(s) is the RRset of the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order. - - How this data sequence is processed into the signature is algorithm dependent. - - - - - Two DnsResourceDataSignature are equal iff their type covered, algorithm, labels, original TTL, signature expiration, signature inception, key tag, - signer's name and signature fields are equal. - - - - - Two DnsResourceDataSignature are equal iff their type covered, algorithm, labels, original TTL, signature expiration, signature inception, key tag, - signer's name and signature fields are equal. - - - - - A hash code of the combination of the type covered, algorithm, labels, original TTL, signature expiration, signature inception, key tag, - signer's name and signature fields - - - - - The type of the other RRs covered by this SIG. - - - - - The key algorithm. - - - - - An unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. - If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. - This field makes it easy to determine the original form. - - If, on retrieval, the RR appears to have a longer name than indicated by "labels", the resolver can tell it is the result of wildcard substitution. - If the RR owner name appears to be shorter than the labels count, the SIG RR must be considered corrupt and ignored. - The maximum number of labels allowed in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. - - - - - The "original TTL" field is included in the RDATA portion to avoid - (1) authentication problems that caching servers would otherwise cause by decrementing the real TTL field and - (2) security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. - This original TTL is protected by the signature while the current TTL field is not. - - NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified. - This generaly implies that all RRs for a particular type, name, and class, that is, all the RRs in any particular RRset, must have the same TTL to start with. - - - - - The last time the signature is valid. - Numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. - Ring arithmetic is used. - This time can never be more than about 68 years after the inception. - - - - - The first time the signature is valid. - Numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. - Ring arithmetic is used. - This time can never be more than about 68 years before the expiration. - - - - - Used to efficiently select between multiple keys which may be applicable and thus check that a public key about to be used - for the computationally expensive effort to check the signature is possibly valid. - For algorithm 1 (MD5/RSA) as defined in RFC 2537, - it is the next to the bottom two octets of the public key modulus needed to decode the signature field. - That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order. - For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR. - - - - - The domain name of the signer generating the SIG RR. - This is the owner name of the public KEY RR that can be used to verify the signature. - It is frequently the zone which contained the RRset being authenticated. - Which signers should be authorized to sign what is a significant resolver policy question. - The signer's name may be compressed with standard DNS name compression when being transmitted over the network. - - - - - The actual signature portion of the SIG RR binds the other RDATA fields to the RRset of the "type covered" RRs with that owner name and class. - This covered RRset is thereby authenticated. - To accomplish this, a data sequence is constructed as follows: - - data = RDATA | RR(s)... - - where "|" is concatenation, - - RDATA is the wire format of all the RDATA fields in the SIG RR itself (including the canonical form of the signer's name) before but not including the signature, - and RR(s) is the RRset of the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order. - - How this data sequence is processed into the signature is algorithm dependent. - - - - - RFC 2230. - 
-            +-----+-------------------+
-            | bit | 0-15              |
-            +-----+-------------------+
-            | 0   | PREFERENCE        |
-            +-----+-------------------+
-            | 16  | EXCHANGER         |
-            | ... |                   |
-            +-----+-------------------+
-
- - - - - Constructs a key exchanger resource data from the given preference and key exchanger domain. - - - Specifies the preference given to this RR among other KX records at the same owner. - Lower values are preferred. - - - Specifies a host willing to act as a key exchange for the owner name. - - - - - Specifies the preference given to this RR among other KX records at the same owner. - Lower values are preferred. - - - - - Specifies a host willing to act as a key exchange for the owner name. - - - - - RFC 4025. - 
-            +-----+--------------+
-            | bit | 0-7          |
-            +-----+--------------+
-            | 0   | precedence   |
-            +-----+--------------+
-            | 8   | gateway type |
-            +-----+--------------+
-            | 16  | algorithm    |
-            +-----+--------------+
-            | 24  | gateway      |
-            | ... |              |
-            +-----+--------------+
-            |     | public key   |
-            | ... |              |
-            +-----+--------------+
-
- - - - - Constructs an instance out of the precedence, gateway, algorithm and public key fields. - - - Precedence for this record. - Gateways listed in IPSECKEY records with lower precedence are to be attempted first. - Where there is a tie in precedence, the order should be non-deterministic. - - - Indicates a gateway to which an IPsec tunnel may be created in order to reach the entity named by this - resource record. - - Identifies the public key's cryptographic algorithm and determines the format of the public key field. - Contains the algorithm-specific portion of the KEY RR RDATA. - - - - Two DnsResourceDataIpSecKey are equal iff their precedence, gateway, algorithm and public key fields are equal. - - - - - Two DnsResourceDataIpSecKey are equal iff their precedence, gateway, algorithm and public key fields are equal. - - - - - A hash code of the combination of the precedence, gateway, algorithm and public key fields. - - - - - Precedence for this record. - Gateways listed in IPSECKEY records with lower precedence are to be attempted first. - Where there is a tie in precedence, the order should be non-deterministic. - - - - - Indicates the format of the information that is stored in the gateway field. - - - - - Indicates a gateway to which an IPsec tunnel may be created in order to reach the entity named by this resource record. - - - - - Identifies the public key's cryptographic algorithm and determines the format of the public key field. - - - - - Contains the algorithm-specific portion of the KEY RR RDATA. - - - - - RFC 4255. - Describes the algorithm of the public key. - - - - - Undefined value. - - - - - RSA algorithm. - - - - - DSS algorithm. - - - - - RFC 3123. - 
-            +-----+--------+---+-----------+
-            | bit | 0-7    | 8 | 9-15      |
-            +-----+--------+---+-----------+
-            | 0   | ADDRESSFAMILY          |
-            +-----+--------+---+-----------+
-            | 16  | PREFIX | N | AFDLENGTH |
-            +-----+--------+---+-----------+
-            | 32  | AFDPART                |
-            | ... |                        |
-            +-----+------------------------+
-
- - - - - Constructs an instance out of the address family, prefix length, negation and address family dependent part fields. - - The address family value. - - Prefix length. - Upper and lower bounds and interpretation of this value are address family specific. - - For IPv4, specifies the number of bits of the IPv4 address starting at the most significant bit. - Legal values range from 0 to 32. - - For IPv6, specifies the number of bits of the IPv6 address starting at the most significant bit. - Legal values range from 0 to 128. - - Negation flag, indicates the presence of the "!" character in the textual format. - - For IPv4, the encoding follows the encoding specified for the A RR by RFC 1035. - Trailing zero octets do not bear any information (e.g., there is no semantic difference between 10.0.0.0/16 and 10/16) in an address prefix, - so the shortest possible AddressFamilyDependentPart can be used to encode it. - However, for DNSSEC (RFC 2535) a single wire encoding must be used by all. - Therefore the sender must not include trailing zero octets in the AddressFamilyDependentPart regardless of the value of PrefixLength. - This includes cases in which AddressFamilyDependentPart length times 8 results in a value less than PrefixLength. - The AddressFamilyDependentPart is padded with zero bits to match a full octet boundary. - An IPv4 AddressFamilyDependentPart has a variable length of 0 to 4 octets. - - For IPv6, the 128 bit IPv6 address is encoded in network byte order (high-order byte first). - The sender must not include trailing zero octets in the AddressFamilyDependentPart regardless of the value of PrefixLength. - This includes cases in which AddressFamilyDependentPart length times 8 results in a value less than PrefixLength. - The AddressFamilyDependentPart is padded with zero bits to match a full octet boundary. - An IPv6 AddressFamilyDependentPart has a variable length of 0 to 16 octets. - - - - - Two DnsAddressPrefix are equal iff their address family, prefix length, negation and address family dependent part are equal. - - - - - Two DnsAddressPrefix are equal iff their address family, prefix length, negation and address family dependent part fields are equal. - - - - - A hash code based on the address family, prefix length, negation and address family dependent part fields. - - - - - The address family value. - - - - - Prefix length. - Upper and lower bounds and interpretation of this value are address family specific. - - For IPv4, specifies the number of bits of the IPv4 address starting at the most significant bit. - Legal values range from 0 to 32. - - For IPv6, specifies the number of bits of the IPv6 address starting at the most significant bit. - Legal values range from 0 to 128. - - - - - Negation flag, indicates the presence of the "!" character in the textual format. - - - - - For IPv4, the encoding follows the encoding specified for the A RR by RFC 1035. - Trailing zero octets do not bear any information (e.g., there is no semantic difference between 10.0.0.0/16 and 10/16) in an address prefix, - so the shortest possible AddressFamilyDependentPart can be used to encode it. - However, for DNSSEC (RFC 2535) a single wire encoding must be used by all. - Therefore the sender must not include trailing zero octets in the AddressFamilyDependentPart regardless of the value of PrefixLength. - This includes cases in which AddressFamilyDependentPart length times 8 results in a value less than PrefixLength. - The AddressFamilyDependentPart is padded with zero bits to match a full octet boundary. - An IPv4 AddressFamilyDependentPart has a variable length of 0 to 4 octets. - - For IPv6, the 128 bit IPv6 address is encoded in network byte order (high-order byte first). - The sender must not include trailing zero octets in the AddressFamilyDependentPart regardless of the value of PrefixLength. - This includes cases in which AddressFamilyDependentPart length times 8 results in a value less than PrefixLength. - The AddressFamilyDependentPart is padded with zero bits to match a full octet boundary. - An IPv6 AddressFamilyDependentPart has a variable length of 0 to 16 octets. - - - - - The number of bytes this resource data takes. - - - - - RFCs 2671, 3225. - - - - - RFC 3225. - Setting the this bit to one in a query indicates to the server that the resolver is able to accept DNSSEC security RRs. - Cleareing (setting to zero) indicates that the resolver is unprepared to handle DNSSEC security RRs - and those RRs must not be returned in the response (unless DNSSEC security RRs are explicitly queried for). - The bit of the query MUST be copied in the response. - - - - - The following is the packet structure used for ARP requests and replies. - On Ethernet networks, these packets use an EtherType of 0x0806, and are sent to the broadcast MAC address of FF:FF:FF:FF:FF:FF. - Note that the EtherType (0x0806) is used in the Ethernet header, and should not be used as the PTYPE of the ARP packet. - The ARP type (0x0806) should never be used in the PTYPE field of an ARP packet, since a hardware protocol address should never be linked to the ARP protocol. - Note that the packet structure shown in the table has SHA and THA as 48-bit fields and SPA and TPA as 32-bit fields but this is just for convenience — - their actual lengths are determined by the hardware & protocol length fields. - 
-            +-----+------------------------+------------------------+-----------------------------------------------+
-            | bit | 0-7                    | 8-15                   | 16-31                                         |
-            +-----+------------------------+------------------------+-----------------------------------------------+
-            | 0   |	Hardware type (HTYPE)                           | Protocol type (PTYPE)                         |
-            +-----+------------------------+------------------------+-----------------------------------------------+
-            | 32  | Hardware length (HLEN) | Protocol length (PLEN) | Operation (OPER)                              |
-            +-----+------------------------+------------------------+-----------------------------------------------+
-            | 64  | Sender hardware address (SHA) (first 32 bits)                                                   |
-            +-----+-------------------------------------------------+-----------------------------------------------+
-            | 96  | Sender hardware address (SHA) (last 16 bits)    | Sender protocol address (SPA) (first 16 bits) |
-            +-----+-------------------------------------------------+-----------------------------------------------+
-            | 128 | Sender protocol address (SPA) (last 16 bits)    | Target hardware address (THA) (first 16 bits) |
-            +-----+-------------------------------------------------+-----------------------------------------------+
-            | 160 |	Target hardware address (THA) (last 32 bits)                                                    |
-            +-----+-------------------------------------------------------------------------------------------------+
-            | 192 | Target protocol address (TPA)                                                                   |
-            +-----+-------------------------------------------------------------------------------------------------+
-
- - - - - The number of bytes in the ARP header without the addresses (that vary in size). - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - The datagram is valid if the length is correct according to the header. - - - - - The number of bytes in the ARP header. - - - - - Each data link layer protocol is assigned a number used in this field. - - - - - Each protocol is assigned a number used in this field. - - - - - Length in bytes of a hardware address. Ethernet addresses are 6 bytes long. - - - - - Length in bytes of a logical address. IPv4 address are 4 bytes long. - - - - - Specifies the operation the sender is performing. - - - - - Hardware address of the sender. - - - - - Protocol address of the sender. - - - - - Protocol IPv4 address of the sender. - - - - - Hardware address of the intended receiver. - This field is ignored in requests. - - - - - Protocol address of the intended receiver. - - - - - Protocol IPv4 address of the intended receiver. - - - - - CC.NEW Option (RFC 1644). - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | Connection    |
-            |     | Count         |
-            +-----+---------------+
-
- - - This option may be sent instead of a CC option in an initial <SYN> segment (i.e., SYN but not ACK bit), - to indicate that the SEG.CC value may not be larger than the previous value. - Its SEG.CC value is the TCB.CCsend value from the sender's TCB. - - - - - - Creates the option using the given connection count value. - - - - - The default connection count value is 0. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The type of the Tagger ID for - - - - - No TaggerId field is present. - - - - - A TaggerId of non-specific context is present. - - - - - A TaggerId representing an IPv4 address is present. - - - - - A TaggerId representing an IPv6 address is present. - - - - - RFC 6621. - Simplified Multicast Forwarding Duplicate Packet Detection. - Hash assist value. - 
-            +-----+---+----------+
-            | Bit | 0 | 1-7      |
-            +-----+---+----------+
-            | 0   | Option Type  |
-            +-----+--------------+
-            | 8   | Opt Data Len |
-            +-----+---+----------+
-            | 16  | 1 | Hash     |
-            +-----+---+ Assist   |
-            | ... | Value (HAV)  |
-            +-----+--------------+
-
- - - - - Creates an instance from data. - - - The first bit of the data is ignored, and the rest are considered to be the Hash assist value (HAV) used to facilitate H-DPD operation. - - - - - Hash assist value (HAV) used to facilitate H-DPD operation. - - - - - True since the hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions. - - - - - RFC 5213. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | Timestamp                  |
-            |     |                            |
-            |     |                            |
-            |     |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from timestamp. - - - Timestamp. - The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. - In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second. - - - - - Timestamp. - The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. - In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second. - - - - - Timestamp. - The value indicates the number of seconds since January 1, 1970, 00:00 UTC calculated from the ulong Timestamp field. - - - - - Timestamp. - The value indicates the Timestamp date calculated from the Timestamp ulong field. - - - - - Handover Acknowledge Code for IPv6 Mobility Handover Acknowledge Message Extension Header. - - - - - Handover Accepted, NCoA valid. - - - - - Handover Accepted, NCoA not valid or in use. - - - - - Handover Accepted, NCoA assigned (used in Assigned Addressing). - - - - - Handover Accepted, use PCoA. - - - - - Message sent unsolicited, usually to trigger an HI message. - - - - - Handover Not Accepted, reason unspecified. - - - - - Administratively prohibited. - - - - - Insufficient resources. - - - - - RFC-ietf-netext-pmip-lr-10. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Sequence #                            |
-            +-----+---------------------------------------+
-            | 64  | Reserved                              |
-            +-----+---------------------------------------+
-            | 80  | Lifetime                              |
-            +-----+---------------------------------------+
-            | 96  | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Creates an instance from next header, checksum, sequence number, lifetime and options. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - A monotonically increasing integer. Set by a sending node in a request message, and used to match a reply to the request. - - - The requested time in seconds for which the sender wishes to have local forwarding. - A value of 0xffff (all ones) indicates an infinite lifetime. - When set to 0, indicates a request to stop localized routing. - - - Zero or more TLV-encoded mobility options. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - RFC 5568. - 
-            +-----+-------------+---+---------------------+
-            | Bit | 0-7         | 8 | 9-15                |
-            +-----+-------------+---+---------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+-------------+---+---------------------+
-            | 48  | Status      | K | Reserved            |
-            +-----+-------------+---+---------------------+
-            | 64  | Sequence #                            |
-            +-----+---------------------------------------+
-            | 80  | Lifetime                              |
-            +-----+---------------------------------------+
-            | 96  | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - Creates an instance from next header, checksum, status, key management mobility capability, sequence number, lifetime and options. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Indicating the disposition of the Binding Update. - Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. - Values greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. - - - If this is cleared, the protocol used by the home agent for establishing the IPsec security associations between the mobile node and the home agent - does not survive movements. - It may then have to be rerun. - (Note that the IPsec security associations themselves are expected to survive movements.) - - - Copied from the Sequence Number field in the Binding Update. - It is used by the mobile node in matching this Binding Acknowledgement with an outstanding Binding Update. - - - The granted lifetime, in time units of 4 seconds for Binding Acknowledgement and 1 second for Fast Binding Acknowledgement, - for which this node should retain the entry for this mobile node in its Binding Cache. - - - Zero or more TLV-encoded mobility options. - - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - The Binidng Acknowledgement status in an IPv6 Mobility Binding Acknowledgement extension header. - - - - - RFCs 5213, 5568, 6275. - - - - - RFCs 5568, 6275. - Binding Acknowledgement: Prefix discovery necessary. - Fast Binding Acknowledgement: NCoA is invalid. Use NCoA supplied in "alternate" CoA. - - - - - RFC 5845. - - - - - RFC 5845. - - - - - RFC 5648. - - - - - RFC 5648. - - - - - RFC 6058. - PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH. - - - - - RFCs 5568, 6275. - - - - - RFCs 5568, 6275. - - - - - RFCs 5568, 6275. - - - - - RFCs 5568, 6275. - Binding Acknowledgement: Home registration not supported. - Fast Binding Acknowledgement: Incorrect interface identifier length. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 3963. - - - - - RFC 3963. - - - - - RFC 3963. - - - - - RFC 3963. - - - - - RFC 4285. - - - - - RFC 4285. - - - - - RFC 4285. - - - - - RFC 4866. - - - - - RFC 4866. - - - - - RFC 4866. - - - - - RFC 4866. - - - - - RFC 5149. - - - - - RFC 5213. - - - - - RFC 5213. - NOT_LMA_FOR_THIS_MOBILE_NODE. - - - - - RFC 5213. - - - - - RFC 5213. - - - - - RFC 5213. - - - - - RFC 5213. - TIMESTAMP_LOWER_THAN_PREV_ACCEPTED. - - - - - RFC 5213. - - - - - RFC 5213. - - - - - RFC 5213. - MISSING_MN_IDENTIFIER_OPTION. - - - - - RFC 5213. - - - - - RFC 5213. - - - - - RFC 5845. - - - - - RFC 5648. - - - - - RFC 5648. - - - - - RFC 5648. - - - - - RFC 5648. - - - - - RFC 5648. - - - - - RFC 5648. - - - - - RFC 5844. - - - - - RFC 5844. - - - - - RFC 5844. - - - - - RFC 5844. - - - - - RFC 6275. - - - - - RFC 6602. - - - - - RFC 6618. - REINIT_SA_WITH_HAC. - - - - - RFC 792. - 
-            +-----+---------+------+-----------+
-            | Bit | 0-7     | 8-15 | 16-31     |
-            +-----+---------+------+-----------+
-            | 0   | Type    | Code | Checksum  |
-            +-----+---------+------+-----------+
-            | 32  | Pointer | unused           |
-            +-----+---------+------------------+
-            | 64  | Internet Header            |
-            |     | + 64 bits of               |
-            |     | Original Data Datagram     |
-            +-----+----------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if the datagram's length is OK, the checksum is correct, the code is in the expected range, - the IPv4 payload contains at least an IPv4 header, the IPv4's payload is in the expected size - and the pointer points to a byte within the IPv4 header. - - - - - The pointer identifies the octet of the original datagram's header where the error was detected (it may be in the middle of an option). - For example, 1 indicates something is wrong with the Type of Service, and (if there are options present) 20 indicates something is wrong with the type code of the first option. - - - - - Represents an HTTP version. - - - - - Creates a version from the major and minor version numbers. - - The major version number. 0 for 0.9, 1 for 1.0 or 1.1. - The minor version number. 9 for 0.9, 0, for 1.0 and 1 for 1.1. - - - - A string represneting the version. - Example: "HTTP/1.1". - - - - - - Two HTTP versions are equal iff they have the same major and minor versions. - - - - - Two HTTP versions are equal iff they have the same major and minor versions. - - - - - The hash code of an http version is the xor of the hash codes of the minor version and the major version. - - - - - A built version for HTTP/1.0. - - - - - A built version for HTTP/1.1. - - - - - The major version number. - - - - - The minor version number. - - - - - The number of bytes this version takes. - - - - - RFC 2616. - Represents an HTTP response. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - False since this is message is a response. - - - - - The status code of the response. - null if no status code exists. - - - - - The data of the reason phrase. - Example: OK - - - - - Reid. - 
-            +-----+-------+----------+-----------+
-            | bit | 0-15  | 16-23    | 24-31     |
-            +-----+-------+----------+-----------+
-            | 0   | flags | protocol | algorithm |
-            +-----+-------+----------+-----------+
-            | 32  | public key                   |
-            | ... |                              |
-            +-----+------------------------------+
-
- - - - - Constructs an instance out of the flags, protocol, algorithm and public key fields. - - Reserved and must be zero. - Must be set to 1. - The key algorithm parallel to the same field for the SIG resource. - The public key value. - - - - Two DnsResourceDataRKey are equal iff their flags, protocol, algorithm and public key fields are equal. - - - - - Two DnsResourceDataRKey are equal iff their flags, protocol, algorithm and public key fields are equal. - - - - - A hash code based on the flags, protocol, algorithm and public key fields. - - - - - Reserved and must be zero. - - - - - Must be set to 1. - - - - - The key algorithm parallel to the same field for the SIG resource. - - - - - The public key value. - - - - - RFC 4398. - 
-            +-----+-----------+------+------------+
-            | bit | 0-7       | 8-15 | 16-31      |
-            +-----+-----------+------+------------+
-            | 0   | type             | key tag    |
-            +-----+-----------+------+------------+
-            | 32  | algorithm | certificate or CRL|
-            +-----+-----------+                   |
-            |     |                               |
-            | ... |                               |
-            +-----+-------------------------------+
-
- - - - - Constructs an instance from the certificate type, key tag, algorithm and certificate fields. - - The certificate type. - - Value computed for the key embedded in the certificate, using the RRSIG Key Tag algorithm. - This field is used as an efficiency measure to pick which CERT RRs may be applicable to a particular key. - The key tag can be calculated for the key in question, and then only CERT RRs with the same key tag need to be examined. - Note that two different keys can have the same key tag. - However, the key must be transformed to the format it would have as the public key portion of a DNSKEY RR before the key tag is computed. - This is only possible if the key is applicable to an algorithm and complies to limits (such as key size) defined for DNS security. - If it is not, the algorithm field must be zero and the tag field is meaningless and should be zero. - - - Has the same meaning as the algorithm field in DNSKEY and RRSIG RRs, - except that a zero algorithm field indicates that the algorithm is unknown to a secure DNS, - which may simply be the result of the algorithm not having been standardized for DNSSEC. - - The certificate data according to the type. - - - - Two DnsResourceDataCertificate are equal iff their certificate type, key tag, algorithm and certificate fields are equal. - - - - - Two DnsResourceDataCertificate are equal iff their certificate type, key tag, algorithm and certificate fields are equal. - - - - - A hash code of the combination of the certificate type, key tag, algorithm and certificate fields. - - - - - The certificate type. - - - - - Value computed for the key embedded in the certificate, using the RRSIG Key Tag algorithm. - This field is used as an efficiency measure to pick which CERT RRs may be applicable to a particular key. - The key tag can be calculated for the key in question, and then only CERT RRs with the same key tag need to be examined. - Note that two different keys can have the same key tag. - However, the key must be transformed to the format it would have as the public key portion of a DNSKEY RR before the key tag is computed. - This is only possible if the key is applicable to an algorithm and complies to limits (such as key size) defined for DNS security. - If it is not, the algorithm field must be zero and the tag field is meaningless and should be zero. - - - - - Has the same meaning as the algorithm field in DNSKEY and RRSIG RRs, - except that a zero algorithm field indicates that the algorithm is unknown to a secure DNS, - which may simply be the result of the algorithm not having been standardized for DNSSEC. - - - - - The certificate data according to the type. - - - - - A resource data that can hold any data. - - - - - An empty resource data. - - - - - Constructs the resource data from the given data. - - - - - Two resource datas are equal if their data is equal. - - - - - Two resource datas are equal if their data is equal. - - - - - The hash code of the data. - - - - - The data of the resource data. - - - - - The certificate type for cetificate DNS resource records. - - - - - No certificate type defined. - Should not be used. - - - - - RFC 4398. - Indicates an X.509 certificate conforming to the profile defined by the IETF PKIX working group. - The certificate section will start with a one-octet unsigned OID length and then an X.500 OID indicating the nature of the remainder of the certificate section. - Note: X.509 certificates do not include their X.500 directory-type-designating OID as a prefix. - - - - - RFC 4398. - SPKI certificate. - - - - - RFC 4398. - PGP - Indicates an OpenPGP packet. - This is used to transfer public key material and revocation signatures. - The data is binary and must not be encoded into an ASCII armor. - An implementation should process transferable public keys, but it may handle additional OpenPGP packets. - - - - - RFC 4398. - The URL of an X.509 data object. - Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion. - Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet. - - - - - RFC 4398. - ISPKI - The URL of an SPKI certificate. - Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion. - Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet. - - - - - RFC 4398. - Contains both an OpenPGP fingerprint for the key in question, as well as a URL. - The certificate portion of the IPgp CERT RR is defined as a one-octet fingerprint length, followed by the OpenPGP fingerprint, followed by the URL. - The OpenPGP fingerprint is calculated as defined in RFC 2440. - A zero-length fingerprint or a zero-length URL are legal, and indicate URL-only IPGP data or fingerprint-only IPGP data, respectively. - A zero-length fingerprint and a zero-length URL are meaningless and invalid. - Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion. - Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet. - - - - - RFC 4398. - ACPKIX - Attribute Certificate. - - - - - RFC 4398. - IAcPkix - The URL of an Attribute Certificate. - Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion. - Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet. - - - - - RFC 4398. - Indicates a certificate format defined by an absolute URI. - The certificate portion of the CERT RR must begin with a null-terminated URI, and the data after the null is the private format certificate itself. - The URI should be such that a retrieval from it will lead to documentation on the format of the certificate. - Recognition of private certificate types need not be based on URI equality but can use various forms of pattern matching so that, for example, subtype or version information can also be encoded into the URI. - - - - - RFC 4398. - Indicates a private format certificate specified by an ISO OID prefix. - The certificate section will start with a one-octet unsigned OID length and then a BER-encoded OID indicating the nature of the remainder of the certificate section. - This can be an X.509 certificate format or some other format. - X.509 certificates that conform to the IETF PKIX profile should be indicated by the PKIX type, not the OID private type. - Recognition of private certificate types need not be based on OID equality but can use various forms of pattern matching such as OID prefix. - - - - - This field identifies the National Access Programs or Special Access Programs - which specify protection rules for transmission and processing of the information contained in the datagram. - Protection authority flags do NOT represent accreditation authorities, though the semantics are superficially similar. - - - - - No protection authorities. - - - - - Designated Approving Authority per DOD 5200.28 - - - - - Single Integrated Operational Plan - Extremely Sensitive Information (SIOP-ESI). - Department of Defense Organization of the Joint Chiefs of Staff - Attn: J6 Washington, DC 20318-6000 - - - - - Sensitive Compartmented Information (SCI). - Director of Central Intelligence - Attn: Chairman, Information Handling Committee, Intelligence Community Staff Washington, D.C. 20505 - - - - - National Security Agency (NSA). - 9800 Savage Road Attn: T03 Ft. Meade, MD 20755-6000 - - - - - Department of Energy (DOE). - Attn: DP343.2 Washington, DC 20545 - - - - - RFC 1662. - - - - - Calculates FCS16. - - - - - Calculates FCS16. - - - - - RFC 6705. - 
-            +-----+-------------+----------------+
-            | Bit | 0-7         | 8-15           |
-            +-----+-------------+----------------+
-            | 0   | Option Type | Opt Data Len   |
-            +-----+-------------+----------------+
-            | 16  | Reserved    | Address Length |
-            +-----+-------------+----------------+
-            | 32  | MAG IPv6 Address             |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            |     |                              |
-            +-----+------------------------------+
-
- - - - - The number of bytes the address field takes. - - - - - The number of bytes this option data takes. - - - - - Creates an instance from address. - - Contains the MAG's IPv6 address. - - - - Contains the MAG's IPv6 address. - - - - - RFC 5568. - 
-            +-----+--------------+
-            | Bit | 0-7          |
-            +-----+--------------+
-            | 0   | Option Type  |
-            +-----+--------------+
-            | 8   | Opt Data Len |
-            +-----+--------------+
-            | 16  | Option-Code  |
-            +-----+--------------+
-            | 24  | LLA          |
-            | ... |              |
-            +-----+--------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from code and link layer address. - - The type of link layer address option. - Variable-length link-layer address. - - - - The type of link layer address option. - - - - - Variable-length link-layer address. - - - - - RFC 5949. - 
-            +-----+----------+------------+
-            | Bit | 0-7      | 8-15       |
-            +-----+----------+------------+
-            | 0   | Req-type | Req-length |
-            +-----+----------+------------+
-            | 16  | Req-option            |
-            | ... |                       |
-            +-----+-----------------------+
-
- - - - - Creates a context request entry according to the given request type and option. - - The type value for the requested option. - The optional data to uniquely identify the requested context for the requested option. - - - - Two entries are equal iff their type and option are equal. - - - - - Two entries are equal iff their request type and option are equal. - - - - - A hash code based on the request type and option. - - - - - The total length of the request in bytes. - - - - - The type value for the requested option. - - - - - The length of the requested option, excluding the Request Type and Request Length fields. - - - - - The optional data to uniquely identify the requested context for the requested option. - - - - - RFC 4285. - 
-            +-----+---------------------+
-            | Bit | 0-7                 |
-            +-----+---------------------+
-            | 0   | Option Type         |
-            +-----+---------------------+
-            | 8   | Opt Data Len        |
-            +-----+---------------------+
-            | 16  | Subtype             |
-            +-----+---------------------+
-            | 24  | Mobility SPI        |
-            |     |                     |
-            |     |                     |
-            |     |                     |
-            +-----+---------------------+
-            | 56  | Authentication Data |
-            | ... |                     |
-            +-----+---------------------+
-
- - - - - The minimum number of bytes this option data takes. - - - - - Creates an instance from subtype, mobility security parameter index and authentication data. - - A number assigned to identify the entity and/or mechanism to be used to authenticate the message. - - A number in the range [0-4294967296] used to index into the shared-key-based mobility security associations. - - - Has the information to authenticate the relevant mobility entity. - This protects the message beginning at the Mobility Header up to and including the mobility SPI field. - - - - - A number assigned to identify the entity and/or mechanism to be used to authenticate the message. - - - - - A number in the range [0-4294967296] used to index into the shared-key-based mobility security associations. - - - - - Has the information to authenticate the relevant mobility entity. - This protects the message beginning at the Mobility Header up to and including the mobility SPI field. - - - - - RFC 6275. - 
-            +-----+--------------+--------------+
-            | Bit | 0-7          | 8-15         |
-            +-----+--------------+--------------+
-            | 0   | Option Type  | Opt Data Len |
-            +-----+--------------+--------------+
-            | 16  | Alternate Care-of Address   |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            +-----+-----------------------------+
-
- - - - - Creates an instance from an alternative care of address. - - - Contains an address to use as the care-of address for the binding, rather than using the Source Address of the packet as the care-of address. - - - - - Contains an address to use as the care-of address for the binding, rather than using the Source Address of the packet as the care-of address. - - - - - RFC 5845. - - - - - Invalid value. - - - - - Old Care-of Address. - - - - - New Care-of Address. - - - - - NAR's IP address. - - - - - NAR's Prefix, sent in PrRtAdv. - The Prefix Length field contains the number of valid leading bits in the prefix. - The bits in the prefix after the prefix length are reserved and must be initialized to zero by the sender and ignored by the receiver. - - - - - RFC 6757. - - - - - Undefined value. - - - - - Operator-Identifier as a variable-length Private Enterprise Number (PEN) encoded in a network-byte order. - The maximum PEN value depends on the ANI Length and is calculated using the formula: maximum PEN = 2^((ANI_length-1)*8)-1. - For example, the ANI Length of 4 allows for encoding PENs from 0 to 2^24-1, i.e., from 0 to 16777215, - and uses 3 octets of Operator-Identifier space. - - - - - Realm of the operator. - Realm names are required to be unique and are piggybacked on the administration of the DNS namespace. - Realms meet the syntactic requirements of the "Preferred Name Syntax". - They are encoded as US-ASCII. - 3GPP specifications also define realm names that can be used to convey PLMN Identifiers. - - - - - RFC 6275. - 
-            +-----+-------------+-------------------------+
-            | Bit | 0-7         | 8-15                    |
-            +-----+-------------+-------------------------+
-            | 0   | Next Header | Header Extension Length |
-            +-----+-------------+-------------------------+
-            | 16  | MH Type     | Reserved                |
-            +-----+-------------+-------------------------+
-            | 32  | Checksum                              |
-            +-----+---------------------------------------+
-            | 48  | Reserved                              |
-            +-----+---------------------------------------+
-            | 64  | Care-of Init Cookie                   |
-            |     |                                       |
-            |     |                                       |
-            |     |                                       |
-            +-----+---------------------------------------+
-            | 128 | Mobility Options                      |
-            | ... |                                       |
-            +-----+---------------------------------------+
-
- - - - - The minimum number of bytes the message data takes. - - - - - Creates an instance from next header, checksum, care of init cookie and options. - - Identifies the type of header immediately following this extension header. - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - Contains a random value, the care-of init cookie. - Zero or more TLV-encoded mobility options. - - - - Identifies the particular mobility message in question. - An unrecognized MH Type field causes an error indication to be sent. - - - - - Contains a random value, the care-of init cookie. - - - - - RFC 5846. - 
-            +-----+---+---+---+-----+-------------------------+
-            | Bit | 0 | 1 | 2 | 3-7 | 8-15                    |
-            +-----+---+---+---+-----+-------------------------+
-            | 0   | Next Header     | Header Extension Length |
-            +-----+-----------------+-------------------------+
-            | 16  | MH Type         | Reserved                |
-            +-----+-----------------+-------------------------+
-            | 32  | Checksum                                  |
-            +-----+-----------------+-------------------------+
-            | 48  | B.R. Type       | Status                  |
-            +-----+-----------------+-------------------------+
-            | 64  | Sequence #                                |
-            +-----+---+---+---+-------------------------------+
-            | 80  | P | V | G | Reserved                      |
-            +-----+---+---+---+-------------------------------+
-            | 96  | Mobility options                          |
-            | ... |                                           |
-            +-----+-------------------------------------------+
-
- - - - - Creates an instance from next header, checksum, status, sequence number, proxy binding, IPv4 home address binding only, global and options. - - - Identifies the type of header immediately following this extension header. - - - Contains the checksum of the Mobility Header. - The checksum is calculated from the octet string consisting of a "pseudo-header" - followed by the entire Mobility Header starting with the Payload Proto field. - The checksum is the 16-bit one's complement of the one's complement sum of this string. - - - Indicating the result of processing the Binding Revocation Indication message by the responder. - - - Copied from the Sequence Number field in the Binding Revocation Indication. - It is used by the initiator, e.g., HA, LMA, MAG, in matching this Binding Revocation Acknowledgement - with the outstanding Binding Revocation Indication. - - - Set if set in the corresponding Binding Revocation Indication message. - - - Set if the it is set in the corresponding Binding Revocation Indication message. - - - Set if it is set in the corresponding Binding Revocation Indication message. - - - Zero or more TLV-encoded mobility options. - - - - - Defines the type of the Binding Revocation Message. - - - - - Indicating the result of processing the Binding Revocation Indication message by the responder. - - - - - RFC 3376. - Represents an IGMP Report version 3 layer. - - - - - - Creates an instance of an IGMP Report Version 3 Layer with a default of no Group Records. - - - - - Writes the layer to the buffer. - This method ignores the payload length, and the previous and next layers. - - The buffer to write the layer to. - The offset in the buffer to start writing the layer at. - - - - Xor of the hash codes of the layer length, datalink, message type, query version and the group records. - - - - - true iff the group records are equal. - - - - - true iff the group records are equal. - - - - - Each Group Record is a block of fields containing information pertaining to the sender's membership in a single multicast group on the interface from which the Report is sent. - - - - - The number of bytes this layer will take. - - - - - The type of the IGMP message of concern to the host-router interaction. - - - - - The actual time allowed, called the Max Resp Time. - - - - - RFC 792. - - - - - A sub-type of the message. Specific method of this message type. - - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - RFC 1475. - Represents a Conversion Failed ICMP layer. - - - - - - A sub-type of the message. Specific method of this message type. - - - - - An offset from the start of the original datagram to the beginning of the offending field. - - - - - The value of this field determines the format of the remaining data. - - - - - A sub-type of the message. Specific method of this message type. - - - - - A value that should be interpreted according to the specific message. - - - - - RFC 2616. - The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded - with chunked transfer-coding. - 
-            Trailer  = "Trailer" ":" 1#field-name
-
- An HTTP/1.1 message should include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. - Doing so allows the recipient to know which header fields to expect in the trailer. - - If no Trailer header field is present, the trailer should not include any header fields. - - Message header fields listed in the Trailer header field must not include the following header fields: - * Transfer-Encoding. - * Content-Length. - * Trailer. - - - - - The field name. - - - - - The field name in uppercase. - - - - - Creates a Trailer Field according to the given field names. - - The names of the fields that should be encoded in the chunked body trailer. - - - - True iff the two fields are equal. - Two trailer fields are equal iff they have the fields names in the same order. - - - - - True iff the two fields are equal. - Two trailer fields are equal iff they have the fields names in the same order. - - - - - The names of the fields that should be encoded in the chunked body trailer. - - - - - RFC 2616. - The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, - the media type that would have been sent had the request been a GET. - - 
-            Content-Type   = "Content-Type" ":" media-type
-
- - An example of the field is - 
-            Content-Type: text/html; charset=ISO-8859-4
-
- - - - - The field name. - - - - - The field name in uppercase. - - - - - Creates a Content Type Field according to the given media type, media subtype and parameters. - - The main type of the content of this HTTP message. - The subtype of the content of this HTTP message. - Parameters on the specific type. - - - - True iff the two fields are equal. - Two content type fields are equal if they have the same media type and subtype and same parameters. - - - - - True iff the two fields are equal. - Two content type fields are equal if they have the same media type and subtype and same parameters. - - - - - The main type of the content of this HTTP message. - - - - - The subtype of the content of this HTTP message. - - - - - Parameters on the specific type. - - - - - RFC 2065, 2535. - 
-            +-----+---+---+--------------+----+----------+------+--------+-------+-------+----------+-------+
-            | bit | 0 | 1 | 2            | 3  | 4        | 5    | 6-7    | 8     | 9     | 10-11    | 12-15 |
-            +-----+---+---+--------------+----+----------+------+--------+-------+-------+----------+-------+
-            | 0   | A | C | experimental | XT | Reserved | user | NAMTYP | IPSEC | email | Reserved | SIG   |
-            +-----+---+---+--------------+----+----------+------+--------+-------+-------+----------+-------+
-            | 16  | protocol                                             | algorithm                        |
-            +-----+------------------------------------------------------+----------------------------------+
-            | 32  | Flags extension (optional)                                                              |
-            +-----+-----------------------------------------------------------------------------------------+
-            | 32  | public key                                                                              |
-            | or  |                                                                                         |
-            | 48  |                                                                                         |
-            | ... |                                                                                         |
-            +-----+-----------------------------------------------------------------------------------------+
-
- - - - - Constructs an instance out of the authentication prohibited, confidentiality prohibited, experimental, user associated, IPSec, email, name type, - signatory, protocol, algorithm, flags extension and public key fields. - - Use of the key is prohibited for authentication. - Use of the key is prohibited for confidentiality. - - Ignored if the type field indicates "no key" and the following description assumes that type field to be non-zero. - Keys may be associated with zones, entities, or users for experimental, trial, or optional use, in which case this bit will be one. - If this bit is a zero, it means that the use or availability of security based on the key is "mandatory". - Thus, if this bit is off for a zone key, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. - If this bit is a one for a host or end entity, it might sometimes operate in a secure mode and at other times operate without security. - The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. - The experimental bit must be zero for safe secure operation and should only be a one for a minimal transition period. - - - Indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. - The coding of the owner name is that used for the responsible individual mailbox in the SOA and RP RRs: - The owner name is the user name as the name of a node under the entity name. - For example, "j.random_user" on host.subdomain.domain could have a public key associated through a KEY RR - with name j\.random_user.host.subdomain.domain and the user bit a one. - It could be used in an security protocol where authentication of a user was desired. - This key might be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. - - - Indicates that this key is valid for use in conjunction with that security standard. - This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR - if the entity or user bits are on. - The presence of a KEY resource with the IPSEC and entity bits on and experimental and no-key bits off is an assertion that the host speaks IPSEC. - - - Indicates that this key is valid for use in conjunction with MIME security multiparts. - This key could be used in connection with secured communication on behalf of an end entity or user - whose name is the owner name of the KEY RR if the entity or user bits are on. - - The name type. - - If non-zero, indicates that the key can validly sign things as specified in DNS dynamic update. - Note that zone keys always have authority to sign any RRs in the zone regardless of the value of the signatory field. - - - It is anticipated that keys stored in DNS will be used in conjunction with a variety of Internet protocols. - It is intended that the protocol octet and possibly some of the currently unused (must be zero) bits in the KEY RR flags - as specified in the future will be used to indicate a key's validity for different protocols. - - The key algorithm parallel to the same field for the SIG resource. - - Optional second 16 bit flag field after the algorithm octet and before the key data. - Must not be non-null unless one or more such additional bits have been defined and are non-zero. - - The public key value. - - - - Two DnsResourceDataKey are equal iff their authentication prohibited, confidentiality prohibited, experimental, user associated, IPSec, email, - name type, signatory, protocol, algorithm, flags extension and public key fields are equal. - - - - - Two DnsResourceDataKey are equal iff their authentication prohibited, confidentiality prohibited, experimental, user associated, IPSec, email, - name type, signatory, protocol, algorithm, flags extension and public key fields are equal. - - - - - A hash code out of the combination of the authentication prohibited, confidentiality prohibited, experimental, user associated, IPSec, email, - name type, signatory, protocol, algorithm, flags extension and public key fields. - - - - - Use of the key is prohibited for authentication. - - - - - Use of the key is prohibited for confidentiality. - - - - - Ignored if the type field indicates "no key" and the following description assumes that type field to be non-zero. - Keys may be associated with zones, entities, or users for experimental, trial, or optional use, in which case this bit will be one. - If this bit is a zero, it means that the use or availability of security based on the key is "mandatory". - Thus, if this bit is off for a zone key, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. - If this bit is a one for a host or end entity, it might sometimes operate in a secure mode and at other times operate without security. - The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. - The experimental bit must be zero for safe secure operation and should only be a one for a minimal transition period. - - - - - Indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. - The coding of the owner name is that used for the responsible individual mailbox in the SOA and RP RRs: - The owner name is the user name as the name of a node under the entity name. - For example, "j.random_user" on host.subdomain.domain could have a public key associated through a KEY RR - with name j\.random_user.host.subdomain.domain and the user bit a one. - It could be used in an security protocol where authentication of a user was desired. - This key might be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. - - - - - Indicates that this key is valid for use in conjunction with that security standard. - This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR - if the entity or user bits are on. - The presence of a KEY resource with the IPSEC and entity bits on and experimental and no-key bits off is an assertion that the host speaks IPSEC. - - - - - Indicates that this key is valid for use in conjunction with MIME security multiparts. - This key could be used in connection with secured communication on behalf of an end entity or user - whose name is the owner name of the KEY RR if the entity or user bits are on. - - - - - The name type. - - - - - If non-zero, indicates that the key can validly sign things as specified in DNS dynamic update. - Note that zone keys always have authority to sign any RRs in the zone regardless of the value of the signatory field. - - - - - It is anticipated that keys stored in DNS will be used in conjunction with a variety of Internet protocols. - It is intended that the protocol octet and possibly some of the currently unused (must be zero) bits in the KEY RR flags - as specified in the future will be used to indicate a key's validity for different protocols. - - - - - The key algorithm parallel to the same field for the SIG resource. - - - - - Optional second 16 bit flag field after the algorithm octet and before the key data. - Must not be non-null unless one or more such additional bits have been defined and are non-zero. - - - - - The public key value. - - - - - RFCs 3757, 4034, 5011. - 
-            +-----+----------+----------+--------+----------+--------------------+
-            | bit | 0-6      | 7        | 8      | 9-14     | 15                 |
-            +-----+----------+----------+--------+----------+--------------------+
-            | 0   | Reserved | Zone Key | Revoke | Reserved | Secure Entry Point |
-            +-----+----------+----------+--------+----------+--------------------+
-            | 16  | Protocol            | Algorithm                              |
-            +-----+---------------------+----------------------------------------+
-            | 32  | Public Key                                                   |
-            | ... |                                                              |
-            +-----+--------------------------------------------------------------+
-
- - - - - The expected value for the protocol field. - - - - - Constructs an instance from the zone key, revoke, secure entry point, protocol, algorithm and public key fields. - - - If true, the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name must be the name of a zone. - If false, then the DNSKEY record holds some other type of DNS public key and must not be used to verify RRSIGs that cover RRsets. - - - If true, and the resolver sees an RRSIG(DNSKEY) signed by the associated key, - then the resolver must consider this key permanently invalid for all purposes except for validating the revocation. - - - RFC 3757. - If true, then the DNSKEY record holds a key intended for use as a secure entry point. - This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; - validators must not alter their behavior during the signature validation process in any way based on the setting of this bit. - This also means that a DNSKEY RR with the SEP bit set would also need the Zone Key flag set in order to be able to generate signatures legally. - A DNSKEY RR with the SEP set and the Zone Key flag not set MUST NOT be used to verify RRSIGs that cover RRsets. - - - Must have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3. - - Identifies the public key's cryptographic algorithm and determines the format of the Public Key field. - The public key material. The format depends on the algorithm of the key being stored. - - - - Two DnsResourceDataDnsKey are equal iff their zone key, revoke, secure entry point, protocol, algorithm and public key fields are equal. - - - - - Two DnsResourceDataDnsKey are equal iff their zone key, revoke, secure entry point, protocol, algorithm and public key fields are equal. - - - - - The hash code based on the zone key, revoke, secure entry point, protocol, algorithm and public key fields. - - - - - If true, the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name must be the name of a zone. - If false, then the DNSKEY record holds some other type of DNS public key and must not be used to verify RRSIGs that cover RRsets. - - - - - If true, and the resolver sees an RRSIG(DNSKEY) signed by the associated key, - then the resolver must consider this key permanently invalid for all purposes except for validating the revocation. - - - - - RFC 3757. - If true, then the DNSKEY record holds a key intended for use as a secure entry point. - This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; - validators must not alter their behavior during the signature validation process in any way based on the setting of this bit. - This also means that a DNSKEY RR with the SEP bit set would also need the Zone Key flag set in order to be able to generate signatures legally. - A DNSKEY RR with the SEP set and the Zone Key flag not set MUST NOT be used to verify RRSIGs that cover RRsets. - - - - - Must have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3. - - - - - Identifies the public key's cryptographic algorithm and determines the format of the Public Key field. - - - - - The public key material. - The format depends on the algorithm of the key being stored. - - - - - Specifies the operation the ARP sender is performing. - - - - - Invalid operation. - - - - - [RFC826][RFC5227] - - - - - [RFC826][RFC5227] - - - - - [RFC903] - - - - - [RFC903] - - - - - [RFC1931] - - - - - [RFC1931] - - - - - [RFC1931] - - - - - [RFC1293] - - - - - [RFC1293] - - - - - [RFC1577] - - - - - [RFC2176] - - - - - [RFC5494] - - - - - [RFC5494] - - - - - Maximum Segment Size (RFC 793) - 
-            +-----+------+--------+
-            | Bit | 0-7  | 8-15   |
-            +-----+------+--------+
-            | 0   | Kind | Length |
-            +-----+------+--------+
-            | 16  | max seg size  |
-            +-----+---------------+
-
- - - If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. - This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). - If this option is not used, any segment size is allowed. - - - - - - The number of bytes this option take. - - - - - The number of bytes this option value take. - - - - - Creates the option using the given maximum segment size. - - - - - The default maximum segment size is 0. - - - - - Tries to read the option from a buffer starting from the option value (after the type and length). - - The buffer to read the option from. - The offset to the first byte to read the buffer. Will be incremented by the number of bytes read. - The number of bytes the option value should take according to the length field that was already read. - On success - the complex option read. On failure - null. - - - - The maximum segment size value. - - - - - The number of bytes this option will take. - - - - - True iff this option may appear at most once in a datagram. - - - - - A pair of address and its time in the day. - - - - - Create a timed address accroding to the given values. - - The address in the pair. - The time passed since midnight UT. - - - - Two options are equal if they have the same address and time passed since midnight UT. - - - - - Two options are equal if they have the same address and time passed since midnight UT. - - - - - Two options are equal if they have the same address and time passed since midnight UT. - - - - - Two options are different if they have different addresses or time passed since midnight UT. - - - - - Returns the xor of the address hash code and the time in the day hash code. - - - - - The address. - - - - - The time passed since midnight UT. - - - - - RFC 5213. - 
-            +-----+--------------+--------------+
-            | Bit | 0-7          | 8-15         |
-            +-----+--------------+--------------+
-            | 0   | Option Type  | Opt Data Len |
-            +-----+--------------+--------------+
-            | 16  | Link-local Address          |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            |     |                             |
-            +-----+-----------------------------+
-
- - - - - Creates an instance from link local address. - - - Contains the link-local address. - - - - - Contains the link-local address. - - - - - RFC 4866. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | CGA Parameters             |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - The maximum option data length in bytes. - - - - - Creates an instance from the given CGA parameters. - - - Contains up to 255 bytes of the CGA Parameters data structure defined in RFC 3972. - The concatenation of all CGA Parameters options in the order they appear in the Binding Update message - must result in the original CGA Parameters data structure. - All CGA Parameters options in the Binding Update message except the last one must contain exactly 255 bytes in the CGA Parameters field, - and the Option Length field must be set to 255 accordingly. - All CGA Parameters options must appear directly one after another, that is, - a mobility option of a different type must not be placed in between two CGA Parameters options. - - - - - Contains up to 255 bytes of the CGA Parameters data structure defined in RFC 3972. - The concatenation of all CGA Parameters options in the order they appear in the Binding Update message - must result in the original CGA Parameters data structure. - All CGA Parameters options in the Binding Update message except the last one must contain exactly 255 bytes in the CGA Parameters field, - and the Option Length field must be set to 255 accordingly. - All CGA Parameters options must appear directly one after another, that is, - a mobility option of a different type must not be placed in between two CGA Parameters options. - - - - - RFC 6275. - 
-            +-----+--------------+--------------+
-            | Bit | 0-7          | 8-15         |
-            +-----+--------------+--------------+
-            | 0   | Option Type  | Opt Data Len |
-            +-----+--------------+--------------+
-            | 16  | Refresh Interval            |
-            +-----+-----------------------------+
-
- - - - - The number of bytes the option data takes. - - - - - Creates an option from the given refresh interval. - - - Measured in units of four seconds, and indicates remaining time until the mobile node should send a new home registration to the home agent. - The Refresh Interval must be set to indicate a smaller time interval than the Lifetime value of the Binding Acknowledgement. - - - - - Measured in units of four seconds, and indicates remaining time until the mobile node should send a new home registration to the home agent. - The Refresh Interval must be set to indicate a smaller time interval than the Lifetime value of the Binding Acknowledgement. - - - - - RFC 6757. - 
-            +-----+-------------+--------------+
-            | Bit | 0-7         | 8-15         |
-            +-----+-------------+--------------+
-            | 0   | Option Type | Opt Data Len |
-            +-----+-------------+--------------+
-            | 16  | ANI Sub-option(s)          |
-            | ... |                            |
-            +-----+----------------------------+
-
- - - - - Creates an instance from sub options. - - Sub options. - - - - Sub options. - - - - - True iff parsing of this option didn't encounter issues. - - - - - RFC 5949. - - - - - Invalid value. - - - - - IPv6 address of the local mobility anchor (LMAA). - - - - - IPv4 address of the local mobility anchor (IPv4-LMAA). - - - - - The type of the IPv6 mobility header. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275 - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 6275. - - - - - RFC 5568. - - - - - RFC 5568. - - - - - RFCs 4068, 5568. - Deprecated. - - - - - RFC 5096. - - - - - RFC 5142. - - - - - RFC 5847. - - - - - RFC 5568. - - - - - RFC 5568. - - - - - RFC 5846. - - - - - RFC-ietf-netext-pmip-lr-10. - - - - - RFC-ietf-netext-pmip-lr-10. - - - - - The code of the IGMP message for Create Group Request (RFC988). - - - - - Request Granted. - - - - - Request Denied - No Resources. - - - - - Request Denied - Invalid Code. - - - - - Request Denied - Invalid Group Address. - - - - - Request Denied - Invalid Access Key. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - Request Pending - Retry in this value many seconds. - - - - - The code of the IGMP message for Create Group Request (RFC988). - - - - - Public. - - - - - Private. - - - - - RFC 2521. - 
-            +-----+------+------+----------+
-            | Bit | 0-7  | 8-15 | 16-31    |
-            +-----+------+------+----------+
-            | 0   | Type | Code | Checksum |
-            +-----+------+------+----------+
-            | 32  | Reserved    | Pointer  |
-            +-----+-------------+----------+
-            | 64  | Internet Header        |
-            |     | + 64 bits of           |
-            |     | Original Data Datagram |
-            +-----+------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - Valid if the datagram's length is OK, the checksum is correct, the code is in the expected range, - the IPv4 payload contains at least an IPv4 header, the IPv4's payload is in the expected size and the Pointer points to a byte in the IPv4 payload. - - - - - An offset into the Original Internet Headers that locates the most significant octet of the offending SPI. - Will be zero when no SPI is present. - - - - - The minimum valid ICMP code for this type of ICMP datagram. - - - - - The maximum valid ICMP code for this type of ICMP datagram. - - - - - RFC 792. - 
-            +-----+------+------+-----------+
-            | Bit | 0-7  | 8-15 | 16-31     |
-            +-----+------+------+-----------+
-            | 0   | Type | Code | Checksum  |
-            +-----+------+------+-----------+
-            | 32  | unused                  |
-            +-----+-------------------------+
-            | 64  | Internet Header         |
-            |     | + 64 bits of            |
-            |     | Original Data Datagram  |
-            +-----+-------------------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - RFC 1256. - - - - - The value of this field determines the format of the remaining data. - - - - - RFC 1788. - 
-            +-----+------+------+-----------------+
-            | Bit | 0-7  | 8-15 | 16-31           |
-            +-----+------+------+-----------------+
-            | 0   | Type | Code | Checksum        |
-            +-----+------+------+-----------------+
-            | 32  | Identifier  | Sequence Number |
-            +-----+-------------+-----------------+
-
- - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - EtherType is a two-octet field in an Ethernet frame, as defined by the Ethernet II framing networking standard. - It is used to indicate which protocol is encapsulated in the payload. - - - - - No Ethernet type - - - - - Internet Protocol, Version 4 (IPv4) - - - - - Address Resolution Protocol (ARP) - - - - - Reverse Address Resolution Protocol (RARP) - - - - - AppleTalk (Ethertalk) - - - - - AppleTalk Address Resolution Protocol (AARP) - - - - - VLAN-tagged frame (IEEE 802.1Q) - - - - - Novell IPX (alt) - - - - - Novell - - - - - Internet Protocol, Version 6 (IPv6) - - - - - MAC Control - - - - - PPP, Point-to-Point Protocol - - - - - CobraNet - - - - - MPLS unicast - - - - - MPLS multicast - - - - - PPPoE Discovery Stage - - - - - PPPoE Session Stage - - - - - EAP over LAN (IEEE 802.1X) - - - - - HyperSCSI (SCSI over Ethernet) - - - - - ATA over Ethernet - - - - - EtherCAT Protocol - - - - - Provider Bridging (IEEE 802.1ad) - - - - - AVB Transport Protocol (AVBTP) - - - - - SERCOS III - - - - - Circuit Emulation Services over Ethernet (MEF-8) - - - - - HomePlug - - - - - MAC security (IEEE 802.1AE) - - - - - Precision Time Protocol (IEEE 1588) - - - - - IEEE 802.1ag Connectivity Fault Management (CFM) Protocol / ITU-T Recommendation Y.1731 (OAM) - - - - - Fibre Channel over Ethernet - - - - - FCoE Initialization Protocol - - - - - Q-in-Q - - - - - Veritas Low Latency Transport (LLT) - - - - - RFC 1183. - 
-            +------------+
-            | mbox-dname |
-            +------------+
-            | txt-dname  |
-            +------------+
-
- - - - - Constructs a responsible person resource data from the given mailbox and text domain. - - - A domain name that specifies the mailbox for the responsible person. - Its format in master files uses the DNS convention for mailbox encoding, identical to that used for the RNAME mailbox field in the SOA RR. - The root domain name (just ".") may be specified for Mailbox to indicate that no mailbox is available. - - - A domain name for which TXT RR's exist. - A subsequent query can be performed to retrieve the associated TXT resource records at TextDomain. - This provides a level of indirection so that the entity can be referred to from multiple places in the DNS. - The root domain name (just ".") may be specified for TextDomain to indicate that the TXT_DNAME is absent, and no associated TXT RR exists. - - - - - A domain name that specifies the mailbox for the responsible person. - Its format in master files uses the DNS convention for mailbox encoding, identical to that used for the RNAME mailbox field in the SOA RR. - The root domain name (just ".") may be specified for Mailbox to indicate that no mailbox is available. - - - - - A domain name for which TXT RR's exist. - A subsequent query can be performed to retrieve the associated TXT resource records at TextDomain. - This provides a level of indirection so that the entity can be referred to from multiple places in the DNS. - The root domain name (just ".") may be specified for TextDomain to indicate that the TXT_DNAME is absent, and no associated TXT RR exists. - - - - - RFC 5155. - 
-            +-----+-------------+----------+--------+------------+
-            | bit | 0-7         | 8-14     | 15     | 16-31      |
-            +-----+-------------+----------+--------+------------+
-            | 0   | Hash Alg    | Reserved | OptOut | Iterations |
-            +-----+-------------+----------+--------+------------+
-            | 32  | Salt Length | Salt                           |
-            +-----+-------------+                                |
-            | ... |                                              |
-            +-----+-------------+--------------------------------+
-            |     | Hash Length | Next Hashed Owner Name         |
-            +-----+-------------+                                |
-            | ... |                                              |
-            +-----+----------------------------------------------+
-            |     | Type Bit Maps                                |
-            | ... |                                              |
-            +-----+----------------------------------------------+
-
- - - - - Constructs an instance out of the hash algorithm, flags, iterations, salt, next hashed owner name and types exist fields. - - Identifies the cryptographic hash algorithm used to construct the hash-value. - Can be used to indicate different processing. All undefined flags must be zero. - - Defines the number of additional times the hash function has been performed. - More iterations result in greater resiliency of the hash value against dictionary attacks, - but at a higher computational cost for both the server and resolver. - - Appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks. - - Contains the next hashed owner name in hash order. - This value is in binary format. - Given the ordered set of all hashed owner names, the Next Hashed Owner Name field contains the hash of an owner name that immediately follows the owner name of the given NSEC3 RR. - The value of the Next Hashed Owner Name field in the last NSEC3 RR in the zone is the same as the hashed owner name of the first NSEC3 RR in the zone in hash order. - Note that, unlike the owner name of the NSEC3 RR, the value of this field does not contain the appended zone name. - - Identifies the RRSet types that exist at the original owner name of the NSEC3 RR. - - - - Two DnsResourceDataNextDomainSecure3 are equal iff their hash algorithm, flags, iterations, salt, next hashed owner name and types exist fields - are equal. - - - - - Two DnsResourceDataNextDomainSecure3 are equal iff their hash algorithm, flags, iterations, salt, next hashed owner name and types exist fields - are equal. - - - - - A hash code of the combination of the hash algorithm, flags, iterations, salt, next hashed owner name and types exist fields. - - - - - Contains the next hashed owner name in hash order. - This value is in binary format. - Given the ordered set of all hashed owner names, the Next Hashed Owner Name field contains the hash of an owner name that immediately follows the owner name of the given NSEC3 RR. - The value of the Next Hashed Owner Name field in the last NSEC3 RR in the zone is the same as the hashed owner name of the first NSEC3 RR in the zone in hash order. - Note that, unlike the owner name of the NSEC3 RR, the value of this field does not contain the appended zone name. - - - - - Identifies the RRSet types that exist at the original owner name of the NSEC3 RR. - - - - - RFC 1035. - 
-            +-----+------------+
-            | bit | 0-15       |
-            +-----+------------+
-            | 0   | PREFERENCE |
-            +-----+------------+
-            | 16  | EXCHANGE   |
-            | ... |            |
-            +-----+------------+
-
- - - - - Constructs mail exchange resource data from preference and host. - - - Specifies the preference given to this RR among others at the same owner. - Lower values are preferred. - - - Specifies a host willing to act as a mail exchange for the owner name. - - - - - Specifies the preference given to this RR among others at the same owner. - Lower values are preferred. - - - - - Specifies a host willing to act as a mail exchange for the owner name. - - - - - RFCs 1035, 1183, 1348, 1706, 1712, 1876, 1995, 2065, 2163, 2168, 2230, 2535, 2671, 2672, 2782, 2845, 2874, 2915, 2930, 3123, 3226, 3403, 3596, 3658, - 3755, 4025, 4034, 4255, 4398, 4408, 4431, 4701, 5011, 5155, 5205, 5864, 5936. - Other sources: ATMDOC, Barwood, Eastlake, Faltstrom, Hallam-Baker, PATTON, Reid, Weiler, Wijngaards. - Type fields are used in resource records. - - - - - Undefined value. - - - - - RFC 1035. - A host address. - Payload type: DnsResourceDataIpV4. - - - - - RFC 1035. - An authoritative name server. - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - A mail destination (Obsolete - use MX). - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - MF - A mail forwarder (Obsolete - use MX). - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - The canonical name for an alias. - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - SOA - Marks the start of a zone of authority. - Payload type: DnsResourceDataStartOfAuthority. - - - - - RFC 1035. - MB - A mailbox domain name (EXPERIMENTAL). - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - MG - A mail group member (EXPERIMENTAL). - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - MR - A mail rename domain name (EXPERIMENTAL). - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - A null RR (EXPERIMENTAL). - Payload type: DnsResourceDataAnything. - - - - - RFC 1035. - A well known service description.. - Payload type: DnsResourceDataWellKnownService. - - - - - RFC 1035. - A domain name pointer. - Payload type: DnsResourceDataDomainName. - - - - - RFC 1035. - Host information. - Payload type: DnsResourceDataHostInformation. - - - - - RFC 1035. - mailbox or mail list information. - Payload type: DnsResourceDataMailingListInfo. - - - - - RFC 1035. - MX - Mail exchange. - Payload type: DnsResourceDataMailExchange. - - - - - RFC 1035. - Text strings. - Payload type: DnsResourceDataText. - - - - - RFC 1183. - RP - For Responsible Person. - Payload type: DnsResourceDataResponsiblePerson. - - - - - RFCs 1183, 5864. - AFSDB - For AFS Data Base location. - Payload type: DnsResourceDataAfsDb. - - - - - RFC 1183. - For X.25 PSDN address. - Payload type: DnsResourceDataString. - - - - - RFC 1183. - For ISDN address. - Payload type: DnsResourceDataIsdn. - - - - - RFC 1183. - RT - For Route Through. - Payload type: DnsResourceDataRouteThrough. - - - - - RFC 1706. - NSAP - Network Service Access Point. - For NSAP address, NSAP style A record. - Payload type: DnsResourceDataNetworkServiceAccessPoint. - - - - - RFC 1348. - NSAPPTR - For domain name pointer, NSAP style. - Payload type: DnsResourceDataDomainName. - - - - - RFCs 2535, 3755, 4034. - SIG - For security signature. - Payload type: DnsResourceDataSignature. - - - - - RFCs 2065, 2535, 3755, 4034. - For security key. - Payload type: DnsResourceDataKey. - - - - - RFC 2163. - PX - X.400 mail mapping information. - Payload type: DnsResourceDataX400Pointer. - - - - - RFC 1712. - Geographical Position. - Payload type: DnsResourceDataGeographicalPosition. - - - - - RFC 3596. - IP6 Address. - Payload type: DnsResourceDataIpV6. - - - - - RFC 1876. - Location Information. - Payload type: DnsResourceDataLocationInformation. - - - - - RFC 2535, 3755. - NXT - Next Domain - OBSOLETE. - Payload type: DnsResourceDataNextDomain. - - - - - Patton. - Nimrod Endpoint Identifier. - Payload type: DnsResourceDataAnything. - - - - - Patton. - NimLoc - Nimrod Locator. - Payload type: DnsResourceDataAnything. - - - - - RFC 2782. - SRV - Server Selection. - Payload type: DnsResourceDataServerSelection. - - - - - ATMDOC. - ATM Address. - Payload type: DnsResourceDataAtmAddress. - - - - - RFCs 2168, 2915, 3403. - Naming Authority Pointer. - Payload type: DnsResourceDataNamingAuthorityPointer. - - - - - RFC 2230. - KX - Key Exchanger. - Payload type: DnsResourceDataKeyExchanger. - - - - - RFC 4398. - CERT. - Payload type: DnsResourceDataCertificate. - - - - - RFCs 2874, 3226. - A6 (Experimental). - Payload type: DnsResourceDataA6. - - - - - RFC 2672. - DNAME. - Payload type: DnsResourceDataDomainName. - - - - - Eastlake. - SINK. - Payload type: DnsResourceDataSink. - - - - - RFC 2671. - OPT. - Payload type: DnsResourceDataOptions. - - - - - RFC 3123. - Address Prefix List. - Payload type: DnsResourceDataAddressPrefixList. - - - - - RFCs 3658, 4034. - DS - Delegation Signer. - Payload type: DnsResourceDataDelegationSigner. - - - - - RFC 4255. - SSHFP - SSH Key Fingerprint. - Used to store a fingerprint of an SSH public host key that is associated with a Domain Name System (DNS) name. - Payload type: DnsResourceDataSshFingerprint. - - - - - RFC 4025. - IPSECKEY. - Payload type: DnsResourceDataIpSecKey. - - - - - RFCs 3755, 4034. - RRSIG. - Payload type: DnsResourceDataSignature. - - - - - RFCs 3755, 4034. - NSEC. - Payload type: DnsResourceDataNextDomainSecure. - - - - - RFCs 3755, 4034, 5011. - DNSKEY. - Represents the public key. - Payload type: DnsResourceDataDnsKey. - - - - - RFC 4701. - DHCID. - Dynamic Host Configuration Information. - Payload type: DnsResourceDataAnything. - - - - - RFC 5155. - NSEC3. - Payload type: DnsResourceDataNextDomainSecure3. - - - - - RFC 5155. - NSEC3PARAM. - Payload type: DnsResourceDataNextDomainSecure3Parameters. - - - - - RFC 5205. - Host Identity Protocol. - Payload type: DnsResourceDataHostIdentityProtocol. - - - - - Reid. - NINFO. - Payload type: DnsResourceDataNInfo. - - - - - Reid. - RKEY. - Can be used to encrypt NAPTR record. - Payload type: DnsResourceDataRKey. - - - - - Wijngaards. - TALINK - DNSSEC Trust Anchor LINK. - Payload type: DnsResourceDataTrustAnchorLink. - - - - - Barwood. - Child DS. - Payload type: DnsResourceDataDelegationSigner. - - - - - RFC 4408. - Sender Policy Framework. - Payload type: DnsResourceDataText. - - - - - IANA-Reserved. - Not documented. - - - - - IANA-Reserved. - Not documented. - - - - - IANA-Reserved. - Not documented. - - - - - IANA-Reserved. - UNSPEC - Not documented. - - - - - RFC 2930. - Transaction Key. - Payload type: DnsResourceDataTransactionKey. - - - - - RFC 2845. - TSIG - Transaction Signature. - Payload type: DnsResourceDataTransactionSignature. - - - - - RFC 1995. - Incremental transfer. - Query Type. - - - - - RFCs 1035, 5936. - Transfer of an entire zone. - Query Type. - - - - - RFC 1035. - Mailbox-related RRs (MB, MG or MR). - Query Type. - - - - - RFC 1035. - Mail agent RRs (Obsolete - see MX). - Query Type. - - - - - *. - A request for all records - Query Type. - - - - - Faltstrom. - URI. - Payload type: DnsResourceDataUri. - - - - - Hallam-Baker. - CAA - Certification Authority Authorization. - Payload type: DnsResourceDataCertificationAuthorityAuthorization. - - - - - Weiler. 2005-12-13. - TA - DNSSEC Trust Authorities or Trust Anchor. - Payload type: DnsResourceDataDelegationSigner. - - - - - RFC 4431. - DLV - DNSSEC Lookaside Validation. - Payload type: DnsResourceDataDelegationSigner. - - - - - The DNS LLQ Error code values. - - - - - The LLQ Setup Request was successful. - - - - - The server cannot grant the LLQ request because it is overloaded, - or the request exceeds the server's rate limit (see Section 8 "Security Considerations"). - Upon returning this error, the server MUST include in the LEASE-LIFE field a time interval, in seconds, - after which the client may re-try the LLQ Setup. - - - - - The data for this name and type is not expected to change frequently, and the server therefore does not support the requested LLQ. - The client must not poll for this name and type, nor should it re-try the LLQ Setup, and should instead honor the normal resource record TTLs returned. - To reduce server load, an administrator MAY return this error for all records with types other than PTR and TXT as a matter of course. - - - - - The LLQ was improperly formatted. - Note that if the rest of the DNS message is properly formatted, the DNS header error code must not include a format error code, - as this would cause confusion between a server that does not understand the LLQ format, and a client that sends malformed LLQs. - - - - - The client attempts to refresh an expired or non-existent LLQ (as determined by the LLQ-ID in the request). - - - - - The protocol version specified in the client's request is not supported by the server. - - - - - The LLQ was not granted for an unknown reason. - - - - - RFC 1035, 4035. - All communications inside of the domain protocol are carried in a single format called a message. - The top level format of message is divided into 5 sections (some of which are empty in certain cases) shown below: - 
-            +-----+----+--------+----+----+----+----+---+----+----+-------+
-            | bit | 0  | 1-4    | 5  | 6  | 7  | 8  | 9 | 10 | 11 | 12-15 |
-            +-----+----+--------+----+----+----+----+---+----+----+-------+
-            | 0   | ID                                                    |
-            +-----+----+--------+----+----+----+----+---+----+----+-------+
-            | 16  | QR | Opcode | AA | TC | RD | RA | Z | AD | CD | RCODE |
-            +-----+----+--------+----+----+----+----+---+----+----+-------+
-            | 32  | QDCOUNT                                               |
-            +-----+-------------------------------------------------------+
-            | 48  | ANCOUNT                                               |
-            +-----+-------------------------------------------------------+
-            | 64  | NSCOUNT                                               |
-            +-----+-------------------------------------------------------+
-            | 80  | ARCOUNT                                               |
-            +-----+-------------------------------------------------------+
-            | 96  | Question - the question for the name server           |
-            +-----+-------------------------------------------------------+
-            |     | Answer - RRs answering the question                   |
-            +-----+-------------------------------------------------------+
-            |     | Authority - RRs pointing toward an authority          |
-            +-----+-------------------------------------------------------+
-            |     | Additional - RRs holding additional information       |
-            +-----+-------------------------------------------------------+
-
- The header section is always present. - The header includes fields that specify which of the remaining sections are present, - and also specify whether the message is a query or a response, a standard query or some other opcode, etc. - The names of the sections after the header are derived from their use in standard queries. - The question section contains fields that describe a question to a name server. - These fields are a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). - The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). - The answer section contains RRs that answer the question; the authority section contains RRs that point toward an authoritative name server; - the additional records section contains RRs which relate to the query, but are not strictly answers for the question. - - - - - The number of bytes the DNS header takes. - - - - - Creates a Layer that represents the datagram to be used with PacketBuilder. - - - - - A DNS datagram is valid if parsing of all sections was successful. - - - - - A 16 bit identifier assigned by the program that generates any kind of query. - This identifier is copied the corresponding reply and can be used by the requester to match up replies to outstanding queries. - - - - - A one bit field that specifies whether this message is a query (0), or a response (1). - - - - - Specifies whether this message is a query or a response. - - - - - Specifies kind of query in this message. - This value is set by the originator of a query and copied into the response. - - - - - This bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section. - Note that the contents of the answer section may have multiple owner names because of aliases. - The AA bit corresponds to the name which matches the query name, or the first owner name in the answer section. - - - - - Specifies that this message was truncated due to length greater than that permitted on the transmission channel. - - - - - This bit may be set in a query and is copied into the response. - If RD is set, it directs the name server to pursue the query recursively. - Recursive query support is optional. - - - - - This bit is set or cleared in a response, and denotes whether recursive query support is available in the name server. - - - - - Reserved for future use. - Must be false in all queries and responses. - - - - - The name server side of a security-aware recursive name server must not set the AD bit in a response - unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. - The name server side should set the AD bit if and only if the resolver side considers all RRsets in the Answer section - and any relevant negative response RRs in the Authority section to be authentic. - The resolver side must follow the Authenticating DNS Responses procedure to determine whether the RRs in question are authentic. - However, for backward compatibility, a recursive name server may set the AD bit when a response includes unsigned CNAME RRs - if those CNAME RRs demonstrably could have been synthesized from an authentic DNAME RR that is also included in the response - according to the synthesis rules described in RFC 2672. - - - - - Exists in order to allow a security-aware resolver to disable signature validation - in a security-aware name server's processing of a particular query. - - The name server side must copy the setting of the CD bit from a query to the corresponding response. - - The name server side of a security-aware recursive name server must pass the state of the CD bit to the resolver side - along with the rest of an initiating query, - so that the resolver side will know whether it is required to verify the response data it returns to the name server side. - If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires. - Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response. - When the CD bit is set, the recursive name server should, if possible, return the requested data to the originating resolver, - even if the recursive name server's local authentication policy would reject the records in question. - That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, - and the recursive name server should not interfere. - - If the resolver side implements a BAD cache and the name server side receives a query that matches an entry in the resolver side's BAD cache, - the name server side's response depends on the state of the CD bit in the original query. - If the CD bit is set, the name server side should return the data from the BAD cache; - if the CD bit is not set, the name server side must return RCODE 2 (server failure). - - The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks - while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks. - Several of the possible reasons why signature validation might fail involve conditions - that may not apply equally to the recursive name server and the client that invoked it. - For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security - that the recursive name server does not share. - In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client. - - - - - A response of the server that can sign errors or other messages. - - - - - An unsigned 16 bit integer specifying the number of entries in the question section. - - - - - An unsigned 16 bit integer specifying the number of resource records in the answer section. - - - - - An unsigned 16 bit integer specifying the number of name server resource records in the authority records section. - - - - - An unsigned 16 bit integer specifying the number of resource records in the additional records section. - - - - - The queries resource records. - The amount of records here should be equal to . - Typically exactly one query will exist. - - - - - The answers resource records. - The amount of records here should be equal to . - - - - - The authorities resource records. - The amount of records here should be equal to . - - - - - The additionals resource records. - The amount of records here should be equal to . - - - - - All the resource records in the datagram by order of appearance. - - - - - All the data resource records (all resource records but the queries) in the datagram by order of appearance. - - - - - The special OPT resource record. - This takes the first OPT resource record in additional section. - - - - diff --git a/Contralto/readme-mono.txt b/Contralto/readme-mono.txt new file mode 100644 index 0000000..7e92b76 --- /dev/null +++ b/Contralto/readme-mono.txt @@ -0,0 +1,460 @@ +Readme-mono.txt for Contralto v1.2: + +1. Introduction and Overview +============================ + +ContrAlto aspires to be a faithful emulation of the Xerox Alto II series of +pioneering graphical workstations developed at Xerox PARC in 1973. + +This document covers installation and use on Unix and Mac OS platforms under +the Mono runtime. See readme.txt for instructions for Windows platforms. + +1.1 What's Emulated +------------------- + +ContrAlto currently emulates the following Alto hardware: + - Alto I and Alto II XM CPU + - Microcode RAM (in 1K RAM, 1K RAM/2K ROM, or 3K RAM configurations) + - 256KW of main memory (in 64KW banks) + - Two Diablo Model 31 or 44 drives + - Ethernet (encapsulated in UDP datagrams on the host machine) + - Standard Keyboard/Mouse/Video + - Audio DAC (used with the Smalltalk Music System) + +1.2 What's Not +-------------- + +At this time, ContrAlto does not support more exotic hardware such as Trident +disks, printers or audio using the utility port, the Orbit printer interface, or the +keyset input device. + +The Audio DAC is technically emulated, but output is not connected to an audio +device on non-Windows platforms at this time. + + +2.0 Requirements +================ + +ContrAlto is a .NET application and will run under Mono (http://www.mono-project.com/) +on Unix and MacOS. + +Ensure you have the latest Mono environment installed on your system. ContrAlto was +developed and tested on 5.0.1 and while it will work on earlier versions, it has not +been well tested on them. You can find download links and instructions at +http://www.mono-project.com/download/. + +Additionally, ContrAlto relies on SDL (Simple Directmedia Layer) 2.0 for the Alto's +display, keyboard and mouse. On OS X, the native SDL library is included with the +ContrAlto archive. On Linux, you will want to ensure that the SDL 2.0 libraries +built for your distribution are installed. + +A three-button mouse is essential for using most Alto software. On most mice, +the mousewheel can be clicked to provide the third (middle) button. Laptops +with trackpads may have configuration options to simulate multiple buttons but +will likely be clumsy to use. + + +3.0 Getting Started +=================== + +Installation of ContrAlto on Unix and Mac OS machines is straightforward -- +unpack the ContrAlto-Mono.zip archive to a directory on your machine (a +subdirectory of your home directory will work fine). Ensure you've installed +the prerequisites outlined in Section 2.0 and you should be good to go. + + +3.1 Starting the Alto +===================== + +To launch ContrAlto, run "mono ContrAlto.exe" from a terminal window. A window +for the Alto's display labeled "ContrAlto" will appear -- this is where you will +interact with your virtual Alto. (Note that on the first run of ContrAlto, it may +take several seconds for this window to appear.) The terminal window will provide +you with a command-line console for configuring and controlling the emulated Alto. + +On a real Alto, the system is booted by loading a 14" disk pack into the front +of a Diablo 31 drive, waiting for it to spin up for 20 seconds and then +pressing the "Reset" button on the back of the keyboard. + +Booting an emulated Alto under ContrAlto is slightly less time-consuming. +To load a disk pack into the virtual Diablo drive, you use the "Load Disk" +command at the console -- this allows selection of the disk image (effectively +a "virtual disk pack") to be loaded. Disk images are not included with ContrAlto +but may be found in various places on the Internet -- see Section 3.1.3 for details. +For example "Load Disk 0 Smalltalk.dsk" will load a disk image named Smalltalk.dsk +into drive 0. + +Once the pack has been loaded, you can start the Alto by using the "Start" command +at the console. The display will turn white and after 5-10 seconds a mouse cursor +will appear, followed shortly by the banner of the Xerox Alto Executive. +Congratulations, your Alto is now running! Click on the display window to start +interacting with it using the keyboard and mouse (and if you need your mouse back +for other things, press either "Alt" key on your keyboard.) See Section 3.1 for +details on using ContrAlto. + + +3.1 Using the Alto +================== + +3.1.1 Mouse +----------- + +ContrAlto uses your computer's mouse to simulate the one the Alto uses. +In order to accurately simulate the mouse, ContrAlto must "capture" the real +mouse, which effectively makes your system's mouse exclusive to the ContrAlto +window. (If you've ever used virtualization software like VMWare, VirtualBox, +Virtual PC, or Parallels, you may be familiar with this behavior.) + +Clicking on the ContrAlto display window will cause ContrAlto to capture the +mouse. Once the mouse has been captured, any mouse movements will be reflected +by the Alto's mouse cursor. While ContrAlto has control of the mouse, you will +not be able to use the mouse for other programs running on your computer. To release +ContrAlto's control, press either "Alt" key (the "Option" key on Macintosh) +on your keyboard. Mouse movements will return to normal, and you will not be +able to control the Alto's mouse or keyboard until you click on the ContrAlto +display window again. + +The Alto mouse is a three-button mouse. Alto mouse buttons are mapped as you +would expect. If you have a real three-button mouse then this is completely +straightforward. If you have a two button mouse with a "mousewheel" then +a mousewheel click maps to a click of the Alto's middle mouse button. + +If you have a trackpad or other pointing device, using the middle mouse button +may be more complicated. See what configuration options your operating system +and/or drivers provide you for mapping mouse buttons. + + +3.1.2 Keyboard +-------------- + +ContrAlto emulates the 61-key Alto II keyboard. The vast majority of keys +(the alphanumerics and punctuation) work as you would expect them to, but the +Alto has a few special keys, which are described below: + +Alto Key PC Key +-------- ---------- +LF Down Arrow +BS Backspace +Blank-Top F1 +Blank-Middle F2 +Blank-Bottom F3 +<- (arrow) Left Arrow +DEL Del +LOCK F4 + + +3.1.3 Disk Packs +---------------- + +A real Alto uses large 14" disk packs for disk storage, each containing +approximately 2.5 megabytes (for Diablo 31) or 5 megabytes (for Diablo 44) of +data. ContrAlto uses files, referred to as "disk images" or just "images" +that contain a bit-for-bit copy of these original packs. These are a lot +easier to use with a modern PC. + +Disk images can be loaded and unloaded via the "Load Disk" command. (See Section +5 for details on this and other commands.) + +If you modify the contents of a loaded disk (for example creating new files or +deleting existing ones) the changes will be written back out to the disk image +when a new image is loaded or when ContrAlto exits. For this reason it may be +a good idea to make backups of packs from time to time (just like on the real +machine.) + +ContrAlto does not come with any disk images, however an assortment of Alto +programs can be found on Bitsavers.org, at +http://www.bitsavers.org/bits/Xerox/Alto/disk_images/. Images include: + +AllGames.dsk - A collection of games and toys for the Alto +Bcpl.dsk - A set of BCPL development tools +Diags.dsk - Diagnostic tools +NonProg.dsk - The "Non-Programmer's Disk," containing Bravo +Xmsmall.dsk - Smalltalk-76 + + +3.1.4 Startup, Reset and Shutdown +--------------------------------- + +The system can be started at any time by using the "Start" command, though +in general having a pack image loaded first is a good idea. Similarly, the +"Reset" command will reset the Alto. + +You can shut down the Alto by closing the ContrAlto window or using the +"Quit" console command. Either will commit disk changes made to the +currently loaded disks back to the disk image files before exiting. +However, you will want to be sure the software running on the Alto is ready +to be shutdown first, or else you may lose work or corrupt your disk. + + +3.2 Additional Reading Materials +---------------------------------- + +The Bitsavers Alto archive at http://http://bitsavers.org/pdf/xerox/alto is an +excellent repository of original Alto documentation, here are a few documents to +get you started: + +- The "Alto User's Handbook" is indispensable and contains an overview of the + Alto Executive (the OS "shell"), Bravo (great-granddaddy of Microsoft Word) + and other utilities. + http://bitsavers.org/pdf/xerox/alto/Alto_Users_Handbook_Sep79.pdf + +- "Alto Subsystems" documents many of the common Alto programs and tools + ("subsystems" in Alto parlance) in detail. + http://bitsavers.org/pdf/xerox/alto/AltoSubsystems_Oct79.pdf + +- "Alto Operating System Reference Manual" is useful if you are going to do + any programming for the Alto. + http://bitsavers.org/pdf/xerox/alto/AltoSWRef.part1.pdf + http://bitsavers.org/pdf/xerox/alto/AltoSWRef.part2.pdf + +- "BCPL Reference Manual" is definitely required if you are going to do any + programming on the Alto (in BCPL, anyway...) + http://bitsavers.org/pdf/xerox/alto/bcpl/AltoBCPLdoc.pdf + +- "Bravo Course Outline" is a tutorial that will show you how to use the Bravo + editor. + http://bitsavers.org/pdf/xerox/alto/BravoCourse.pdf + +- The "Alto Hardware Manual" is fun to read through if you're planning on + writing an Alto emulator of your own. If you're into that sort of thing. + http://bitsavers.org/pdf/xerox/alto/AltoHWRef.part1.pdf + http://bitsavers.org/pdf/xerox/alto/AltoHWRef.part2.pdf + +- "A Field Guide to Alto-Land" is a casual perspective on Alto use (and + the culture that grew around it) at Xerox PARC. + http://xeroxalto.computerhistory.org/_cd8_/altodocs/.fieldguide.press!2.pdf + + +4.0 Configuration +================= + +ContrAlto can be configured through the use of configuration files. These +are simple text files with sets of parameters and their values in the form: + + ParameterName = Value + +By default, ContrAlto looks for configuration data in a file named +ContrAlto.cfg. Alternate configuration files can be specified as a +command-line argument at startup via: + mono ContrAlto.exe + +An example configuration file looks something like: + + # contralto.cfg: + # + # This file contains configuration parameters for ContrAlto. + # All integers are specified in octal. + # + + # System configuration + SystemType = TwoKRom + HostAddress = 42 + + # Disk configuration + Disk0Image = alto.dsk + Disk1Image = bcpl.dsk + + # Host networking configuration + HostPacketInterfaceType = UDPEncapsulation + HostPacketInterfaceName = eth0 + + # Emulation Options + BootAddress = 0 + BootFile = 0 + AlternateBootType = Ethernet + + +The following parameters are configurable: + +SystemType: Selects the type of Alto system to emulate. One of: + - AltoI : an Alto I, with 64KW memory, 1K ROM, and 1K CRAM + - OneKRom : an Alto II XM system with 1K ROM, 1K CRAM + - TwoKRom : an Alto II XM system with 2K ROM, 1K CRAM + - ThreeKRam : an Alto II XM system with 1K ROM, 3K CRAM + The default is TwoKRom. + +HostAddress: Specifies the Alto's Ethernet address (in octal). Any value + between 1 and 376 is allowed. + +Drive0Image and Drive1Image: Specifies a disk image to be loaded into the + specified drive. These parameters are optional. + +HostPacketInterfaceType: Specifies the type of interface to be used on the + host for Ethernet emulation. One of: + - UDPEncapsulation: Transmits Alto Ethernet packets over UDP broadcasts + - RAWEncapsulation: Transmits Alto Ethernet packets over raw Ethernet packets. + (not yet available on Unix / OS X platforms.) + - None: No packet encapsulation. + +HostPacketInterfaceName: Specifies the name of the host network interface + to use for Ethernet emulation. (e.g. "eth0"") If no network + interface is to be used, this parameter can be omitted. + +BootAddress: The address to use with a Keyboard Disk Boot (See section 5.0) +BootFile: The file number to use with a Keyboard Net Boot (again, Section 5.0) +AlternateBootType: The type of boot to default to (Section 5.0) + + +5.0 Console Interface +===================== + +After startup, you will be at the ContrAlto console prompt (a '>' character). + +ContrAlto provides a somewhat-context-sensitive input line. Press TAB at any +point during input to see possible completions for the command you're entering. + +The "show commands" command provides a brief synopsis of available commands, +these are described in greater detail in Section 5.1. + +All numeric arguments are specified in Octal by default. A number may be +prefixed with 'b', 'o', 'd', or 'x' to specify binary, octal, decimal or +hexadecimal, respectively. + +All numeric outputs are presented in Octal. + +At any point while the emulator is running is running the console is active +and commands may be entered. + + +5.1 Console Commands +-------------------- + +Quit - Exits ContrAlto. Any modifications to loaded disk images are saved. + +Start - Starts the emulated Alto system. + +Stop - Stops the emulated Alto. + +Reset - Resets the emulated Alto. + +Start With Keyboard Disk Boot - Starts the emulated Alto with the keyboard disk boot address specified + either in the configuration file or by the Set Keyboard Disk Boot Address + command. + +Start With Keyboard Net Boot - Starts the emulated Alto with the keyboard ethernet boot number specified + either in the configuration file or by the Set Keyboard Net Boot File + command. + +Load Disk - Loads the specified drive (0 or 1) with the requested disk image. + +Unload Disk - Unloads the specified drive (0 or 1). Changes to disk contents are saved. + +Show Disk - Displays the currently loaded image for the specified drive (0 or 1). + +Show System Type - Displays the Alto system type as configured by the configuration file. + +Set Ethernet Address - Sets the Alto's host Ethernet address. Values between 1 and 376 (octal) are + allowed. + +Show Ethernet Address - Displays the Alto's host Ethernet address. + +Show Host Network Interface Name - Displays the host network interface used for Ethernet emulation. + +Show Host Network Interface Type - Displays the host network interface type. + +Set Keyboard Net Boot File - Sets the boot file used for net booting. Values between 0 and 177777 + are allowed. + +Set Keyboard Disk Boot Address - Sets the boot address used for disk booting. Values between 0 and + 177777 are allowed. + +Show Commands - Shows debugger commands and their descriptions. + + +5.2 Alternate ("keyboard") Boots +-------------------------------- + +The Alto allowed the specification of alternate boot addresses by holding down +a set of keys on the keyboard while hitting the "reset" switch on the back of +the keyboard. Since this would be difficult to pull off by hand on the emulator +due to the UI involved, ContrAlto provides a set of console commands to select the +alternate address to boot. When the "Start With Keyboard Net|Disk Boot" command is +used, the system will be started (or restarted) with these keys held down on +your behalf. + +Ethernet booting will only work if another host on the network is providing boot services. + +The "Set Keyboard Disk Boot Address" command accepts a 16-bit octal value (from 0 to 177777) +specifying the address to be booted from disk. + +The "Set Keyboard Net Boot Address" command accepts a 16-bit octal value (from 0 to 177777) +specifying the file to be net booted. + + +6.0 Known Issues +================ + +At the moment, the following issues are known and being worked on. If you find +an issue not listed here, see section 7.0 to report a new bug. + +- Smalltalk-80 does not run. +- Audio and RAW ethernet packets are not available on Unix / OS X. + + +7.0 Reporting Bugs +================== + +If you believe you have found a new issue (or have a feature request) please +send an e-mail to joshd@livingcomputers.org with a subject line starting +with "ContrAlto Bug". + +When you send a report, please be as specific and detailed as possible: +- What issue are you seeing? +- What Alto software are you running? +- What operating system are you running ContrAlto on? +- What are the exact steps needed to reproduce the issue? + +The more detailed the bug report, the more possible it is for me to track down +the cause. + + +8.0 Source Code +=============== + +The complete source code is available under the GPLv3 license on GitHub at: + +https://github.com/livingcomputermuseum/ContrAlto + +Contributions are welcome! + + +9.0 Thanks and Acknowledgements +=============================== + +ContrAlto would not have been possible without the amazing preservation work of +the Computer History Museum. + +Audio output and capture on Windows is provided using the NAudio libraries, see: +https://github.com/naudio/NAudio. + +On Unix and OS X, display and keyboard/mouse input is provided through SDL, see: +https://www.libsdl.org/ and is accessed using the SDL2# wrapper, see: +https://github.com/flibitijibibo/SDL2-CS. + + +10.0 Change History +=================== + +V1.2 +---- +- First release supporting Unix / OS X +- Audio DAC for use with Smalltalk Music system implemented +- Initial implementation of Orbit rasterization device; Dover ROS is implemented + but not working properly. +- Added ability to load a configuration file at startup + +V1.1 +---- +- A few minor performance tweaks, adding to a 10-15% speed increase. +- Switched back to targeting .NET 4.5.3 rather than 4.6; this works better under Mono + and avoids odd issues on Windows machines running pre-4.6 frameworks. +- Microcode disassembly improved slightly, annotated microcode source updated. +- Nova disassembler now handles BRI, DIR, EIR, DIRS instructions rather than treating + them all as TRAPs. +- Fixed serious bugs in memory state machine, BravoX now runs. +- Fixed minor bug in Constant ROM selection. +- Raw Ethernet packets sent as broadcasts (matching IFS encapsulation behavior) + +V1.0 +---- +Initial release. diff --git a/Contralto/readme.txt b/Contralto/readme.txt index f1c5572..54725a1 100644 --- a/Contralto/readme.txt +++ b/Contralto/readme.txt @@ -1,11 +1,13 @@ -Readme.txt for Contralto v1.1: +Readme.txt for Contralto v1.2: 1. Introduction and Overview ============================ ContrAlto aspires to be a faithful emulation of the Xerox Alto II series of -pioneering graphical workstations developed at Xerox PARC in 1973. +pioneering graphical workstations developed at Xerox PARC in 1973. +This document covers installation and use on Windows platforms. See +readme-mono.txt for instructions for Unix and OS X platforms. 1.1 What's Emulated ------------------- @@ -18,6 +20,7 @@ ContrAlto currently emulates the following Alto hardware: - Ethernet (encapsulated in either UDP datagrams or raw Ethernet frames on the host machine) - Standard Keyboard/Mouse/Video + - Audio DAC (used with the Smalltalk Music System) 1.2 What's Not -------------- @@ -35,10 +38,10 @@ ContrAlto will run on any Windows PC running Windows Vista or later, with versio on Windows Vista and later; if it is not installed on your computer it can be obtained at https://www.microsoft.com/net. -As ContrAlto is a .NET application and has no Windows-specific dependencies, -it will also run under Mono (http://www.mono-project.com/) on Unix and MacOS, -however this usage has many rough edges at the moment -- please file bugs if -you find them (see Section 7 for details). +As ContrAlto is a .NET application it will also run under Mono +(http://www.mono-project.com/) on Unix and OS X -- please see the readme-mono.txt +file for details on using ContrAlto on these platforms as there are some +differences. A three-button mouse is essential for using most Alto software. On most mice, the mousewheel can be clicked to provide the third (middle) button. Laptops @@ -304,8 +307,23 @@ The "Interlaced Display" checkbox attempts to simulate the Alto's original interlaced display. Depending on your monitor and the speed of your computer this may or may not work well. +4.4 DAC +------- -4.4 Alternate ("keyboard") Boots +The DAC tab provides options controlling the Audio DAC used by the Smalltalk +Music System. The "Enable Audio DAC" does what you'd expect -- it enables +or disables audio output (and audio capture). If this option is enabled, +the "DAC Options" fields become available. + +"Enable DAC output capture" enables the capture of audio generated by the DAC +to be captured to one or more WAV files in the directory specified by the +"Output capture path" box. This box specifies a directory, not a file -- +when the Alto starts generating audio a new WAV file will be created in this +directory. If the Alto is restarted or if ContrAlto exits, this file will +be closed. WAV files created by ContrAlto are 16-bit, mono at 13Khz. + + +4.5 Alternate ("keyboard") Boots -------------------------------- The Alto allowed the specification of alternate boot addresses by holding down @@ -475,10 +493,25 @@ Contributions are welcome! ContrAlto would not have been possible without the amazing preservation work of the Computer History Museum. +Audio output and capture on Windows is provided using the NAudio libraries, see: +https://github.com/naudio/NAudio. + +On Unix and OS X, display and keyboard/mouse input is provided through SDL, see: +https://www.libsdl.org/ and is accessed using the SDL2# wrapper, see: +https://github.com/flibitijibibo/SDL2-CS. + 10.0 Change History =================== +V1.2 +---- +- First release officially supporting Unix / OS X +- Audio DAC for use with Smalltalk Music system implemented +- Initial implementation of Orbit rasterization device; Dover ROS is implemented + but not working properly. +- Added ability to load a configuration file at startup + V1.1 ---- - A few minor performance tweaks, adding to a 10-15% speed increase. diff --git a/ContraltoSetup/Product.wxs b/ContraltoSetup/Product.wxs index 0e0d745..a51a29b 100644 --- a/ContraltoSetup/Product.wxs +++ b/ContraltoSetup/Product.wxs @@ -107,7 +107,11 @@ - + + + +