9th. Part:
編輯 IP6Datagram.msg
參考 IANA 上PROTOCOL NUMBERS 來改寫 IP6Datagram.msg
Protocol field -> Next Header field
因此 enum 名稱 IP6ProtocolFieldId 改成 IP6NextHeaderFieldId
IPv4 上叫 Protocol field, IPv6 上稱 Next Header field
為了相容性，將原本定義的 Protocol field 全保留之外，另外新增
- IP6_PROT_IPv6_Route = 43; //Routing Header for IPv6 [Deering]
- IP6_PROT_IPv6_Frag = 44; //Fragment Header for IPv6 [Deering]
- IP6_PROT_ESP = 50; //Encap Security Payload [RFC2406]
- IP6_PROT_AH = 51; //Authentication Header [RFC2402]
- IP6_PROT_IPv6_ICMP = 58; //ICMP for IPv6 [RFC1883]
IP6_PROT_NONE = 59; --> IP6_PROT_NoNxt = 59; //No Next Header for IPv6 [RFC1883]
- IP6_PROT_Opts = 60; //Destination Options for IPv6 [RFC1883]
- IP6_PROT_ENCAP = 98; //Encapsulation Header [RFC1241,RXB3]
除了這些之外，順便把一些 Routing protocol 的號也加了上去.
IP6_PROT_IPv6_MOBILITY 原本給 62, 改成
IP6_PROT_IPv6_MOBILITY = 135; //Mobility Header for IPv6 [RFC3775]
從一串配給號碼中發現比較特別的是
61 any host internal protocol [IANA]
63 any local network [IANA]
68 any distributed file system [IANA]
99 any private encryption scheme [IANA]
114 any 0-hop protocol [IANA]
剛開始看不知有何特別作用，後來想想這幾個保留位看起來對模擬工具好像不賴
--> 有新協定要試作？
不必改到標頭定義，暫時先用這幾個吧！
不過沒有標頭名稱怎麼辦？
Orz ..... 還是暫時不要加進去好了
本檔案編完的下一步應是編輯 IP6Address.h 或 IP6ControInfo.msg 吧
Ref: IP VERSION 6 PARAMETERS , ICMPv6 TYPE NUMBERS
10th. Part:
編輯 IP6Datagram.msg 中的 message IP6Datagram :
參考 IPv6Suite IP6Datagram.cc 來改寫 IP6Datagram.msg
ToDo:
1. 將相關各標頭定義在檔案裡.
2. 定義 flow_label 結構 (struct, 20 bit = double + short OR int + int + short OR?)
3. 訂 Options Types
IP6Datagram.cc 中標頭是如此定義出來的:
static const ipv6_hdr IPV6_INITIAL_HDR =
{
0x60000000, //version 6, traffic class of 0, flow label of 0
0, //payload of 0
59, //No next header yet
0, //Hop Limit set to uninitialised
IPv6_ADDR_UNSPECIFIED,
IPv6_ADDR_UNSPECIFIED
};
完整的標頭:
message IP6Datagram
{
properties:
//g Still unknown its func
omitGetVerb = true;
fields:
short version = 6; // version 6
int traffic_class = 0; // traffic class of 0
IP6FlowLabel flow_label; // flow label of 0
double payload_length = 0; // payload of 0
int next_header enum(IP6NextHeaderFieldId) = IP_PROT_NONxt; // No next header yet
int hop_limit = 0; //Hop Limit set to uninitialised
IP6Address srcAddress;
IP6Address destAddress;
}
即將碰到 day 3 提到的 延伸標頭處理 問題. RFC2460 上的敘述是這樣的
4.1 Extension Header Order [Page 6]
When more than one extension header is used in the same packet, it is
recommended that those headers appear in the following order:
IPv6 header
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
upper-layer header
Fragment header
填 class IP6Options,
碰到 Option_Data: Variable-length field. Option-Type-specific data 的問題
經 majorlee 學長指點
RFC 3493 Basic Socket Interface Extensions for IPv6.
RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6
裡可能會有答案.