idnits 2.17.1 draft-eromenko-ipff-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1166 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 606: '... the way should MUST process accordin...' RFC 2119 keyword, line 618: '...n unknown class A extension is a MUST....' RFC 2119 keyword, line 712: '...eceiving packets MAY ignore class A an...' RFC 2119 keyword, line 713: '... C or D options, Routers MAY skip over...' RFC 2119 keyword, line 930: '... SHOULD be treated by NAT Routers an...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 240 has weird spacing: '...sses in dotte...' == Line 290 has weird spacing: '...rything inclu...' == Line 908 has weird spacing: '... with code ...' -- The document date (2017-03-29) is 2583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Mobile TCP' is mentioned on line 166, but not defined == Missing Reference: 'RFC-1661' is mentioned on line 969, but not defined == Unused Reference: 'RFC-1700' is defined on line 1123, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMPFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFF-ADDRARCH' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol - Five Fields", 3 Alexey Eromenko, 2016-09-29, 4 5 expiration date: 2017-03-29 7 Intended status: Standards Track 8 A.Eromenko 9 September 2016 11 Internet Protocol, Version 5 (IPv5) 12 a.k.a Internet Protocol - Five Fields (IP-FF) 13 Specification Draft 15 Abstract 17 This document specifies version 5 of the Internet Protocol (IPv5). 18 a.k.a Internet Protocol Five Fields, that started as a hybrid 19 between IPv4 and IPv6, but solved problems in innovative ways, 20 and significantly improved on both. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction..................................................2 55 1.1. Motivation.................................................. 56 2. Terminology...................................................3 57 2.1. Relation to Other Protocols................................ 58 3. IPFF Header Format............................................4 59 3.1. Alternative meaning: Ports or Flow Label................... 60 3.2. Flow-based Routing......................................... 61 4. IP Extensions................................................ 62 4.1 Extension Classes........................................ 63 4.2 Extension Header Order................................... 64 4.3 Extension header......................................... 65 4.4 Standard Extension: Jumbogram............................ 66 4.5 Standard Extension: Virtual Router Forwarding, type 1.... 67 4.6 Standard Extension: Virtual Router Forwarding, type 2.... 68 4.7 No Extension............................................. 69 4.8 No Protocol............................................. 70 4.9 Future Transports....................................... 71 5. Packet Size Issues...........................................24 72 6. Type of Service..............................................25 73 7. Upper-Layer Protocol Issues..................................27 74 7.1 Upper-Layer Checksums...................................27 75 7.2 Maximum Packet Lifetime.................................28 76 7.3 Responding to Packets Carrying Routing Headers..........29 77 Appendix A. Formatting Guidelines for Options...................32 78 Security Considerations.........................................35 79 Acknowledgments.................................................35 80 Authors' Contacts...............................................35 81 References......................................................35 82 Full Copyright Statement........................................39 84 1. Introduction 86 IP version 5 "Five Fields" (IP-FF) is a new version of the Internet 87 Protocol, designed as the successor to IP version 4 (IPv4) [RFC-791] 88 and IP version 6 [RFC-2460], combining many features of both, 89 removing unnecessary bloat, and solved old problems in new ways. 90 Started as a hybrid between the two, but superior to both. 92 The changes from IPv4 to IPFF fall primarily into the following 93 categories: 95 o Expanded Addressing Capabilities 97 IPFF increases the IP address size from 32 bits to 50 bits, to 98 support more levels of addressing hierarchy, a much greater 99 number of addressable nodes, yet keeping the familiar way. 100 That over 230,000x times more than in IPv4 and should be enough 101 for the next several hundred years or so... 102 So even if humanity grows to 100 billion people in few hundred 103 years from now, each can have 10,000 devices, before we deplete 104 our address space. 106 o Header Format Simplification 108 Some IPv4 header fields have been dropped or made optional, to 109 reduce the common-case processing cost of packet handling and 110 to limit the bandwidth cost of the IPFF header. Derived from 111 IPv6. IPFF goes even further by eliminating "Fragmentation", 112 which improves NAT-router processing speeds, and simplifies 113 implementations. 115 o Improved Support for Extensions and Options 117 Extensions are much simplied, and went into several distinct 118 classes, either mandatory-to-process, or optional-to-process. 120 o Virtual Router Forwarding (VRF) / Layer 3 VPN extension 122 o Jumbogram support (large packets) 124 o Mobile IP problem has an order of magnitude simpler solution; 125 see [Mobile TCP] 127 o Ports are at layer 3, which accelerates Flow-Based Routing, 128 and Firewalling decisions. 130 Dropped features, compared to IPv4: 132 o Fragmentation, as it was proven (in IPv6) that it is cheaper to 133 do an MTU discovery, rather than fragment packets on each hop. 134 Hosts should use either MTU path discovery or fallback to 1280 135 MTU. In IPFF, fragmentation is completely eliminated. 136 This increases router processing speed and NAT performance, 137 and simplifies TCP/IP stack. 139 o IP Header checksums, as it was proven (in IPv6), that upper 140 layer protocols can handle it checksums and compute them 141 end-to-end, rather than hop-by-hop. This increases router 142 processing speed. 144 o Classes / classful networks. 146 o Internet Group Management Protocol, is now optional. 148 The changes from IPv6 to IPFF fall primarily into the following 149 categories: 151 o Human readable, simple addressing, similar to IPv4, in 5 152 fields. 10-bits per field. 50-bit addressing. 153 With 3 decimal digits in each field, and familiar dotted 154 decimal notation. examples: 10.0.0.0.1 and 382.201.769.25.133 156 o Easy migration from existing IPv4 networks. 158 o Improved efficiency: an IPFF packet is smaller than IPv6, at 20 159 bytes, same as in IPv4, saving bandwidth compared to IPv6. 161 o Virtual Router Forwarding (VRF) / Layer 3 VPN extension 163 o Jumbogram support, as a standard option 165 o Mobile IP problem has an order of magnitude simpler solution; 166 see [Mobile TCP] 168 o Ports are at layer 3, which accelerates Flow-Based Routing, 169 and Firewalling decisions. 171 o Flow Labeling Capability is totally redesigned; It is now 172 implicit, merged with ports. 174 Dropped features, compared to IPv6: 176 o Modularization: many components, that were the "core" of IPv6 177 specification now became optional or eliminated. 178 (NDP/IGMP/MLD/SLAAC/IPsec/Flow/Fragmentation/Link-Local...) 180 o Fragmentation. 181 In IPFF, fragmentation is completely eliminated. 182 This increases NAT performance and simplifies TCP/IP stack. 183 Hosts should use either MTU path discovery or fallback to 1280 184 MTU. 186 o Link-local addresses are optional; no longer needed. 188 o Neighbor Discovery Protocol (NDP). 190 o Stateless Auto-address configuration (SLAAC) is now optional. 191 Similar functionality should be provided by DHCPv5 or other 192 services. 194 o Internet Group Management Protocol, (IPv6 MLD) is now optional. 196 Other important changes in the IPFF stack, vs both IPv4 and IPv6: 198 o In UDPv5 removed "Length" field in order to reduce overhead. 200 o TCP now comes in multiple flavors; "Classic" and "Modern" 201 (TCP.64-bit) variations. 203 o DNSv5 defines a new "AA" record type. 205 o New Mode: "Silent Multicast Listeners", which combines some of 206 the benefits of multicasts and some of the benefits of 207 broadcasts. In this mode, Multicast listener accepts only 208 traffic targeted at his IP & Layer 2 address, but does not 209 advertise over IGMP. In this new multicast mode, IGMP protocol 210 is not needed. 211 Details in [IPFF-ADDRARCH] 213 o IP options / extensions mechanism was completely re-written. 215 This document specifies the basic IPFF header and the initially- 216 defined IPFF extension headers and options. It also discusses packet 217 size issues, the semantics of Type of Service, and 218 the effects of IPFF on upper-layer protocols. The format and 219 semantics of IPFF addresses are specified separately in 220 [IPFF-ADDRARCH]. The IPFF version of ICMP, which all IPFF 221 implementations are required to include, is specified in [ICMPFF]. 223 1.1. Motivation 225 1.1.1. Motivation: Usability 227 In short: Usability issues in IPv6. 229 IPv6 solved the scalability problems of IPv4, and simplified some 230 protocol details, but created a new problem. 232 The motivation to write a new TCP/IP stack is due to exhaustion of 233 IPv4 address space and also due to the "alien" nature of IPv6, where 234 network engineers are forced to use very-long addresses, that are 235 hexadecimal, hard to read & write, hard to compare, hard to memorize 236 and hard to debug, at least at the IP level. 238 Worse yet, forced link-local addresses, which adds needless 239 complexity. I figured, that just representing IPv6 very-long 128-bit 240 addresses in dotted decimal format would have not solved those 241 issues. 243 DNS (Domain Name System), while solves the usability problem at a 244 higher level of the stack, still leaves low level administration 245 issues unsolved. 247 Something like this: 249 2001:db8:2e1:1a73:149f:88ff:fe81:6116 251 ...is absolutely not readable by a human. Not memorizable either. 253 1.1.2. Motivation for "Five Fields" and 50-bits 255 I wanted something simpler, with a look & feel akin to IPv4. 256 Bigger address range requirements mandated adding an additional 257 field. 5 fields of 8-bits would have resulted in 40-bits, ~1 258 trillion addresses, or x256 times bigger than IPv4. Not good enough 259 for the next century. This is for 15 decimal digits in human memory. 260 But can I do better? Well, it turns out I can. 262 The trick is to make it short enough so that addresses are easy to 263 read/compare & memorize, a problem solved by IPv4, while long enough 264 to handle the future requirements of the Internet, a problem solved 265 by IPv6. 267 50-bit address range theoretically gives me 5 fields of 0...1023 in 268 each, but to improve human reading/typing/memorizing/comparing, 269 the fields were limited to 3 decimal digits each. 270 That is range was limited to 0...999 in each field. 271 i.e. Address range from 0.0.0.0.0 up to 1023.1023.1023.1023.1023 272 was artificially limited up to 999.999.999.999.999 to improve 273 usability. Sacrifice of ~12.5% of available address range for the 274 sake of usability. 275 Still gives us over 230,000x times more addresses than IPv4, more 276 than enough for the next several centuries or so... 277 And this is at a cost of only 15 decimal digits. 278 Same as five fields of 8-bits BTW, and only 3 digits more than IPv4. 280 With this kind of addressing, using IP and visualizing networks in 281 human brain memory becomes easy again ! 283 IP addresses, as used by millions of network engineers & 284 administrators on a daily basis, should be not just computer 285 friendly, but also human-friendly, as network engineers are humans. 287 1.1.3. Motivation: IPv6 is too complex 289 Another issue with IPv6 is that it has *too many* features, 290 everything including the kitchen sink. Theoretically it is 291 possible to design a network, that includes everything from 292 physical/data-link layer and up to transport, perhaps even 293 applications, but then it would be hard to understand, hard to 294 change and hard to evolve. 296 A monster like Neighbor Discovery Protocol (NDP) is very complex 297 indeed, and should be cut into pieces. Much of it's functionality 298 logically belongs to DHCP(or Auto-IP) and ARP, two separate pieces. 300 Same is true for IGMP / IPv6 MLD - unnecessary bloat, at least for 301 link-local Multicast implementations. Should become optional module. 303 Link-local addresses also add unnecessary complexity. 305 IPFF, in contrast, is more minimalistic, offloading features to 306 optional modules, allowing for simpler implementations. 308 IPFF also optimizes a bunch of features in new ways. 310 Fortunately TCP/IP (v4) protocol stack consists of digestible blocks. 312 P.S. I am aware that IPv5 was used for "Internet Stream Protocol" at 313 one point in time, but since it was not deployed, I think I can reuse 314 that number to indicate both "five fields" as well as a hybrid 315 between IPv4 and IPv6. IP-FF has nothing to do with "Internet Stream 316 Protocol". 318 "Perfection is achieved not when there is nothing more to add, but 319 when there is nothing left to take away". Antoine de Saint-Exupery. 321 2. Terminology 323 node - a device that implements IPFF. 325 router - a node that forwards IPFF packets not explicitly 326 addressed to itself. [See Note below]. 328 host - any node that is not a router. [See Note below]. 330 upper layer - a protocol layer immediately above IPFF. Examples are 331 transport protocols such as TCP and UDP, control 332 protocols such as ICMP, routing protocols such as OSPF. 334 link - a communication facility or medium over which nodes can 335 communicate at the link layer, i.e., the layer 336 immediately below IPFF. Examples are Ethernets (simple 337 or bridged); PPP links; X.25, Frame Relay, or ATM 338 networks; and internet (or higher) layer "tunnels", 339 such as tunnels over IPv4 or IPFF itself. 341 neighbors - nodes attached to the same link. 343 interface - a node's attachment to a link. 345 address - an IPFF-layer identifier for an interface. 347 packet - an IPFF header plus payload. 349 link MTU - the maximum transmission unit, i.e., maximum packet 350 size in bytes, that can be conveyed over a link. 352 path MTU - the minimum link MTU of all the links in a path between 353 a source node and a destination node. 355 byte - In IP-FF, as in most computing architectures, byte is 356 defined as 8-bits. = Octet. 358 Note: it is possible, though unusual, for a device with multiple 359 interfaces to be configured to forward non-self-destined packets 360 arriving from some set (fewer than all) of its interfaces, and to 361 discard non-self-destined packets arriving from its other interfaces. 362 Such a device must obey the protocol requirements for routers when 363 receiving packets from, and interacting with neighbors over, the 364 former (forwarding) interfaces. It must obey the protocol 365 requirements for hosts when receiving packets from, and interacting 366 with neighbors over, the latter (non-forwarding) interfaces. 368 2.1. Relation to Other Protocols 370 The following diagram illustrates the place of the internet protocol 371 in the protocol hierarchy: 373 +------+ +------+ +-----+ +-----+ +------+ 374 | HTTP | |Telnet| | SCP | | TFTP| ... | ping | 375 +------+ +------+ +-----+ +-----+ +------+ 376 | | | | | 377 | +-----+ +-----+ +-----+ 378 +---------| TCP | | UDP | ... | ... | 379 +-----+ +-----+ +-----+ 380 | | | 381 +--------------------------+----+ 382 | Internet Protocol & ICMP | 383 +--------------------------+----+ 384 | 385 +---------------------------+ 386 | Local Network Protocol | 387 +---------------------------+ 389 Protocol Relationships 391 Figure 1. 393 Internet protocol interfaces on one side to the higher level 394 host-to-host protocols and on the other side to the local network 395 protocol. In this context a "local network" may be a small network in 396 a building or a large network such as the Internet. 398 3. IPv5 Header Format 400 0 1 2 3 401 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 4|Version| Extension | Source Address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 405 8| | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 12| Protocol | Destination Address | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 409 16| | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 20| Source Port / Flow | Destination Port / Flow | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 24|Type of Service| Hops to Live | Payload Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Extensions ... (if any) | Padding | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 (bytes) 419 Version 4-bit Internet Protocol version number = 5. 421 Extension 10-bit selector. IP header extensions go here. 422 Zero value means "bottom-of-stack", and that 423 a protocol on top of IP will come next, as 424 specified in the "Protocol" field. See section 4 426 Source Address 50-bit address of the originator of the packet. 427 See [IPFF-ADDRARCH]. 429 Protocol 14-bit selector. Identifies the type of protocol 430 or extension header immediately following the 431 IPFF header. Uses a similar values as the IPv4 432 Protocol field [RFC-1700 et seq.], but with 433 a wider variety. 435 Destination Address 50-bit address of the intended recipient of the 436 packet (possibly not the ultimate recipient, if 437 a Routing header is present). 438 See [IPFF-ADDRARCH]. 440 Source and Destination ports or a single Flow Label 442 Two 16-bit port identifiers, used by most 443 Transport-layer Protocols, or a single 444 32-bit Flow label identifier. Either way they 445 are used for flow-based routing purposes. 446 See sections 3.1 and 3.2 448 Type of Service 8-bit type of service field. See section 6. 450 Hops to Live 10-bit unsigned integer. Decremented by 1 by 451 each node that forwards the packet. The packet 452 is discarded if Hops to Live is decremented to 453 zero. 455 Payload Length 14-bit unsigned integer. Length of the IPFF 456 payload, i.e., the rest of the packet following 457 this IPFF header, in bytes. (Note that any 458 extension headers [section 4] present are 459 considered part of the payload, i.e., included 460 in the length count.) 461 Value of zero and all-ones is reserved. 463 3.1. Alternative meaning: Ports or Flow Label 465 Many Transport-layer protocols (including TCP, UDP, and SCTP) 466 require 16-bit port identifiers, so they were moved to the IP layer. 467 It allows to do very fast firewalling and Flow-based routing. 469 For some Transport-layer protocols, that do not use 16-bit Ports, 470 our port fields can have a different meaning: Flow Label. 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Source Port | Destination Port | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 May become: 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Flow Label | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Despite a visual difference to the human, there is no logical 483 difference to the router. 485 From the router's perspective both achieve the same goal: 486 namely have all packets belonging to one Transport session 487 delivered in-order, which saves CPU time at the destination node. 489 Both ways, this field(s) is meant to be read-only, set by the source 490 node, and for the router it is Transport-layer indeterministic. 492 There is a difference for some middleboxes, (e.g. NAT Routers) 493 whom may want to write to this field, as it will trigger a 494 Transport-layer-specific checksum update. 495 Only the Transport-layer protocol decide the meaning. 497 Flow label can only be used by protocols, whom not use 16-bit ports. 498 Flow-label is meant to be a pseudo-random number set by the source 499 node, which, together with source and destination addresses, 500 specifies that same-flow packets must be forwarded through the same 501 path. 503 Some protocols may not use it at all. For example ICMP may set 504 both port fields to zero; which is the same as setting flow label 505 to zero. 507 3.2. Flow-based Routing 509 Flow-based routing is a type of policy-based routing, and it works 510 with any standard routing protocols. 512 With IP-FF, the router can use a 6-tuple to make Flow based 513 decisions in the following way: 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | Source Address | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Protocol | Destination Address | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 522 | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Source Port / Flow | Destination Port / Flow | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |Type of Service| | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Routing decision may be based on 6-tuple parameters, rather 530 than only "Destination address", which sorts packets correctly, 531 and prevents re-ordering, which is expensive to fix. 532 6-tuple means source + destination addresses and ports, protocol 533 and Type of Service (ToS). 534 5-tuple means the same, minus ToS. 536 As a bonus, having 5-tuple available leads to faster firewalls. 537 This 6-tuple gives us a 160-bit "virtual flow label" if you will. 538 It meant to be used as an implicit flow label. 540 Here is the procedure: 541 1. First packet in such a flow is routed via traditional method. 542 By Destination Address. 543 2. The 154-bit "virtual flow label" is cached in a Router's table. 544 3. All incoming packets matching this flow will be routed 545 according to the label cached earlier, via the same path. 547 If a link goes down, the router must invalidate a bunch of labels. 548 If a new link comes up, new flows may be redirected there, 549 existing flows typically should be kept flowing the old way. 550 (assuming equal-cost load-balancing) 552 NOTE: During Flow-based routing, some "Extensions" may be 553 relevant, including: Hop-by-Hop, Routing and VRF headers. 555 If some Transport layer protocol doesn't use 16-bit ports, it can 556 re-use those fields as an explicit flow label. 557 Flow-based routing decisions can happen either way, with 558 an explicit Flow Label or implicitly, with ports. 560 Why 6-tuple ? 562 ToS affects flow. This is useful for traffic engineering, 563 as this is the only field that meants to be read-write-capable, 564 and can change between hops along the path. 565 i.e. a VPN device that acts as a tunnel endpoint, 566 and has static 5-tuple, can give a different ToS number to two 567 internal Transport sessions, thus creating two flows. 568 In this example, ToS field is acting as a secondary "Flow label". 570 4. IP Extensions 572 In IPFF, optional internet-layer information is encoded in separate 573 headers that may be placed between the IPFF header and the upper- 574 layer header in a packet. There are a small number of such extension 575 headers, each identified by a distinct Extension value, ending with a 576 "bottom-of-stack", zero-extension. 578 As illustrated in these examples, an IPFF packet may carry zero, 579 one, or more extension headers, each identified by the Extension 580 field of the preceding header: 582 +---------------+------------------------ 583 | IPFF header | TCP header + data 584 | | 585 | Protocol = TCP| 586 | Extension = 0 | 587 +---------------+------------------------ 589 +---------------+----------------+------------------------ 590 | IPFF header | Routing header | TCP header + data 591 | | | 592 | Protocol = TCP| | 593 | Extension = | Extension = 0 | 594 | Routing | | 595 +---------------+----------------+------------------------ 597 +---------------+----------------+----------------+----------------- 598 | IPFF header | VRF header | Routing header | TCP header + data 599 | | | | 600 | Protocol = TCP| | | 601 | Extension = | Extension = | Extension = 0 | 602 | VRF | Routing | | 603 +---------------+----------------+----------------+----------------- 605 The VRF extension header (Class A option), which every router along 606 the way should MUST process according to its routing protocol, 607 and, if not supported by router implementation, drop the packet. 609 Each option header is an integer multiple of 4 bytes long, in 610 order to retain 4-bytes alignment for subsequent headers. Multi- 611 byte fields within each extension header are aligned on their 612 natural boundaries, i.e., fields of width n bytes are placed at an 613 integer multiple of n bytes from the start of the header, for n = 1, 614 2, or 4. 616 In IP-FF, implementing any extensions, including standard extensions, 617 is NOT mandatory, but implementing a mechanism, that will drop 618 packets with an unknown class A extension is a MUST. 620 4.1 Extension Classes 622 No Extension = 0 (Bottom-of-stack) 624 | Extension | | | 625 Extension Type | range |Total| Length (bits) | Class 626 -------------------------+-----------+-----+---------------+------- 627 Hop-by-Hop Mandatory | 1-63 | 63 | 32 | A3 628 Hop-by-Hop Mandatory | 64-127 | 64 | 64 | A2 629 Hop-by-Hop Mandatory | 128-255 | 128 | variable | A1 630 -------------------------+-----------+-----+---------------+------- 631 Hop-by-Hop Discretionary | 256-319 | 64 | 32 | B3 632 Hop-by-Hop Discretionary | 320-383 | 64 | 64 | B2 633 Hop-by-Hop Discretionary | 384-511 | 128 | variable | B1 634 -------------------------+-----------+-----+---------------+------- 635 Destination Mandatory | 512-639 | 128 | 64 | C2 636 Destination Mandatory | 640-767 | 128 | variable | C1 637 -------------------------+-----------+-----+---------------+------- 638 Destination Discretionary| 768-895 | 128 | 64 | D2 639 Destination Discretionary| 896-1023 | 128 | variable | D1 640 -------------------------+-----------+-----+---------------+------- 641 No Extension | 0 | | 0 | 642 -------------------------+-----------+-----+---------------+------- 644 Mandatory Hop-by-Hop Options means it is mandatory to process this 645 extension, and, if not implemented, drop packet. 646 It does NOT mean it is mandatory to implement. Class A options. 647 In fact, in IP-FF, no extension is mandatory to implement. 649 Discretionary Hop-by-Hop Options means: process it, but if not 650 implemented, skip over this option and continue processing 651 the header. Class B options. 653 In IP-FF, a Routing header is really just a special case of 654 "Hop-by-Hop" header, and must be of either Class A, or Class B. 656 If, as a result of processing a header, a node is required to proceed 657 to the Option but the Option value in the current header is 658 unrecognized by the node, for class A options it should discard the 659 packet and send an ICMP Parameter Problem message to the source of 660 the packet, with an ICMP Code value of 1 661 ("unrecognized Option type encountered"). 662 Unrecognized Class B and D options are just ignored, and traffic 663 routed in the standard fashion. 665 Destination options are meant to be useful for end-node. 666 All intermediate nodes (routers) may or may not process it. 668 Of those numbers; the first (3/4) extension numbers of each class 669 are IANA-assigned; remaining (1/4) extension values are for 670 private/research use. 672 Option Class Examples: 674 Class A: IPv4-style-fragmentation; IPv4-style-IP-checksum; IP-VRF; 675 Extended Hops / Length counters (Jumbograms support); 676 Mandatory Routing header / path selection. (source routing, ...) 677 Class B: UniMulticast group address, additional IP address, some 678 additional routing options. 679 Class C: IPv6-style-fragmentation; 680 Class D: Mobile Protocol Stack / Mobile TCP options. 682 4.2 Extension Header Order 684 When more than one extension option header is used in the same 685 packet, it required, that options appear and processed according 686 to their class. 688 IPFF header 689 Class A extensions (Mandatory Hop-by-Hop options) 690 Class B extensions (Discretionary Hop-by-Hop options) 691 Class C extensions (Mandatory Destination options) 692 Class D extensions (Discretionary Destination options) 693 No Extension; Bottom-of-Stack (Extension = 0) 695 Each option header may occur multiple times, except for No options 696 header, which always appears once in every packet. 698 Within each major class options may appear in any order, 699 but the standard sets priority, in which it should appear. 700 Subclasses can be mixed, i.e. options A2, then A1 then A3 may appear 701 in any order. 703 Priority, 8-bit unsigned integer, is not sent across the wire, 704 but are part of the standard, and have node-local significance, 705 local policy, as well as function as a recommendation in which 706 order packets should be sent and processed. 708 Only when previous class has listed ALL of it's options, the next 709 class may appear. It is not permitted to have a previous class, 710 i.e class A after Class B extension. 712 End-hosts receiving packets MAY ignore class A and B options. 713 When encountering class C or D options, Routers MAY skip over 714 them, just like when encountering option-zero. 716 If the upper-layer header is another IPFF header (in the case of IPFF 717 being tunneled over or encapsulated in IPFF), it may be followed by 718 its own extension headers, which are separately subject to the same 719 ordering recommendations. 721 4.3 Extension header 723 32-bits Extension: (Class A3, B3) 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Extension | (22-bits of data) | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 64-bits Extension: (Class A2, B2, C2, D2) 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Extension | (54-bits of data) | 731 +-+-+-+-+-+-+-+-+-+-+ + 732 | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Variable-length Extension: (Class A1, B1, C1, D1) 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Extension | Ext.Length| | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 739 . . 740 . . 741 . . 742 | | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 (must be padded to 32-bits) 746 Extension 10-bit selector. Identifies the next extension. 747 Must be terminated by zero "end-of-stack". 749 Extension Length 6-bit unsigned integer. Length of the Option 750 Data field of this option, in 32-bit words, 751 not including the first 32-bits. 753 Extension Data Variable-length field. Extension-Type-specific 754 data. 756 4.4 Standard Extension: Jumbogram 758 Proposed Option number = 2. (Class A3; to be assigned by IANA) 759 Proposed priority = 128 (average; to be assigned by IANA) 760 This extension can appear only once. 762 A "jumbogram" is an IPFF packet containing a payload longer than 763 16,383 bytes. Jumbograms are relevant only to IPFF nodes that may 764 be attached to links with a link MTU greater than 16,407 bytes 765 (16,383 + 24 for IPFF header), and need not be implemented or 766 understood by IPFF nodes that do not support attachment to links 767 with such large MTUs. 769 0 1 2 3 770 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 4| Extension | Extended Length | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 (bytes) 776 Extension 10-bit selector. Identifies the next extension. 778 Extended Length 22-bit unsigned integer. Length of the IPFF 779 jumbogram. 781 This options theoretically supports up to 4 MiB packets. 782 Standard Length is set to maximum value of 16,383 on transmission. 784 4.5 Standard Extension: Virtual Router Forwarding (VRF), type 1 786 Proposed Option number = 1. (Class A3; to be assigned by IANA) 787 Proposed priority = 1 (highest; to be assigned by IANA) 788 This extension can appear multiple times. 790 VRFs are basically a layer-3 equivalent of IEEE 802.1q VLANs. 792 VRF extension header should be used together with a VRF-compatible 793 routing protocol to form multiple routing tables and multiple 794 firewall tables, each for one VRF instance. This allows enterprises 795 and internet service providers using Layer 3 VPNs to drop your 796 dependency on L2-VLANs and MPLS, dramatically simplifying network 797 architecture. 799 How to use those labels is dependent on the routing protocols, that 800 support VRF, but the general rule of thumb is to forward traffic only 801 inside the same zone / VRF, unless explicitly configured. 802 Different VRFs may have duplicate IP addresses. 803 Routing protocols themselves will need to be modified to support 804 IP-VRFs, and to allow VRF trunking (i.e. sync of multiple VRF tables 805 via one routing process). 807 The VRF header is used by an IPFF to encapsulate a layer-3 virtual 808 private network information, similarly to an dot1q VLANs of layer-2 809 and to Multi-Protocol Label Switching (MPLS) labels, that can form 810 layer-3 VPNs, when combined with the right routing protocols. 811 A stacking multiple VRF extensions is possible, like Q-in-Q VLAN 812 encapsulation. 814 The type 1 VRF header has the following format: 816 0 1 2 3 817 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 4| Extension | Virtual Router Forwarding label | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 (bytes) 823 Extension 10-bit selector. Identifies the next extension. 825 Virtual Router Forwarding label. 827 22-bit selector. Described an Enterprise-wide 828 L3 VPN unique number, allowing to form 829 layer 3 VPNs, without dot1q VLANs or MPLS. 831 If a node or a router receives a packet with a VRF header and doesn't 832 know how to handle it, (for example, if VRF not configured), it 833 should discard it. 835 VRF label is mutable, and can be changed by any router along the way. 836 A single VRF packet leakage, due to a random bit swap in VRF label 837 field, is believed not to pose a security threat. 839 Recommended values: 840 0 = not enabled, same as "global VRF", should be treated the same as 841 packet without VRF header. 842 1 = admin domain. Recommended to be used for management interfaces 843 only for network equipment and embedded electronics. 845 4.6 Standard Extension: Virtual Router Forwarding (VRF), type 2 847 Proposed Option number = 32. (Class A1; to be assigned by IANA) 848 Proposed priority = 2 (to be assigned by IANA) 849 This extension can appear multiple times. 851 This is similar to the above type 1, but adds the often needed 852 information on the originating router (whom encapsulated into VRF, 853 and destination Router, that is supposed to decapsulate from VRF). 855 VRF header type 2 provides more information to Routing Protocols, 856 which may improve routing efficiency, and emulate MPLS cloud 857 more closely, at a heavier overhead cost. 858 Also VRF range is extended to full 32-bits. 860 The type 2 VRF header has the following format: 862 0 1 2 3 863 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 4| Extension | Ext.Len=5 | Reserved | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 8| Reserved | | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 869 12| Encapsulating Router Address | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 16| Reserved | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 873 20| Decapsulating Router Address | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 24| Virtual Router Forwarding label | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 (bytes) 879 Extension 10-bit selector. Identifies the next extension. 881 Length 5 (5x 32-bit words, plus 1st word) 883 Encapsulating Router 50-bit. This is an IP address of the router that 884 first encapsulated the packet into VRF instance. 885 A source IP/ingress of a VRF cloud, basically. 887 Decapsulating Router 50-bit. This is an IP address of the router that 888 is supposed to decapsulate the packet from VRF 889 instance. A destination IP/egress of a VRF 890 cloud, basically. 892 Virtual Router Forwarding label. 894 32-bit selector. Described an Enterprise-wide 895 L3 VPN unique number, allowing to form 896 layer 3 VPNs, without dot1q VLANs or MPLS. 898 Reserved fields Must be set to zero on transmit; ignored on 899 receive, unless specified otherwise by a 900 routing protocol. Optionally may be used as 901 an additional flow, ToS, or hops count. 903 If a node or a router receives a packet with a VRF header and 904 doesn't know how to handle it, (for example, if VRF not configured), 905 it should discard it. Otherwise it is a security issue. 907 Unlike type 1 VRF, an "ICMP Destination Unreachable" should be sent 908 with code "VRF table unreachable" to the Encapsulating Router. 910 4.7 No Extension 912 The value 0 in the Extension field of an IPv5 header or any 913 extension header indicates "Bottom-of-Stack", and that "Protocol" 914 data starts after this point. 916 4.8 No Protocol 918 The value 0 in the Protocol field of an IPv5 header indicates 919 this packet is invalid. 921 4.9 Future Transport protocols 923 Protocol values = 1-4095 are all custom protocols; 925 The problem is: new Transports are undeployable in IPv4 due to huge 926 amount of middleboxes, and some operating systems disallowing to use 927 non-standard protocol numbers by unprivileged users. 929 The fix: Protocol values between 4096-16383 At a minimum, 930 SHOULD be treated by NAT Routers and middle-boxes like UDP. 931 Additionally, unprivileged users on operating-systems should be able 932 to use protocol numbers 4096-16383, just like UDP is allowed. 933 NAT Routers MUST place a new, updated checksum ONLY IF 934 incoming checksum is non-zero. If it was zero, it is sent as-is. 936 Standard, even numbered, Future Transport protocols include 16-bit 937 ports and 32-bit CRC32 checksum. Even numbers between 4096-16383. 939 Odd-numbered Future Transport protocols also behave like UDP, 940 except they do not have CRC32 checksum field. 941 They can be used by future transports if you either don't need 942 checksum at all, or don't use IP pseudo-header as a starting point. 943 NAT Routers can forward them and can change port. 944 No checksum calculation is done. 945 Odd numbers between 4096-16383. 947 If your Future Transport doesn't use 16-bit port fields, those can 948 be used for a "Flow Label" purposes. 949 For unrecognized Protocols 4096-16383, NAT Router can change this 950 label, as if they were ports. 952 Of those last 1000 numbers are private. 953 Public, assigned by IANA = 4096-15383; 954 private & research: 15384-16383. 956 If you design a new Future Transport protocol, that uses a different 957 checksum mechanism from UDP's CRC32, and you still require IP 958 pseudo-header as a starting point, you SHOULD use custom protocol, 959 numbered between 1-4095. 960 For unknown protocol between 1-4095, NAT routers SHOULD drop packet. 962 5. Packet Size Issues 964 IPFF requires that every link in the internet have an MTU of 1280 965 bytes or greater. On any link that cannot convey a 1280-byte 966 packet in one piece, link-specific fragmentation and reassembly must 967 be provided at a layer below IPFF. 969 Links that have a configurable MTU (for example, PPP links [RFC- 970 1661]) must be configured to have an MTU of at least 1280 bytes; it 971 is recommended that they be configured with an MTU of 1500 bytes or 972 greater, to accommodate possible encapsulations (i.e., tunneling). 974 From each link to which a node is directly attached, the node must be 975 able to accept packets as large as that link's MTU. 977 It is strongly recommended that IPFF nodes implement Path MTU 978 Discovery [RFC-4821] similarly to IPv6, but at Transport Layer, 979 in order to discover and take advantage of path MTUs greater 980 than 1280 bytes. 981 However, a minimal IPFF implementation (e.g., in a boot ROM) may 982 simply restrict itself to sending packets no larger than 1280 983 bytes, and omit implementation of Path MTU Discovery. 985 6. Type of Service 987 The 8-bit Type of Service field in the IPFF header is available for 988 use by originating nodes and/or forwarding routers to identify and 989 distinguish between different classes or priorities of IP-FF packets. 991 Type of Service bits provide various forms of "differentiated 992 service" for IP packets. 993 This is similar to The "Traffic Class" field in the IPv6 header, 994 and to "Type of Service"/Precedence in IPv4. 996 The following general requirements apply to the Type of Service field: 998 o The service interface to the IPFF service within a node must 999 provide a means for an upper-layer protocol to supply the value 1000 of the Type of Service bits in packets originated by that upper- 1001 layer protocol. The default value must be zero for all 10 bits. 1003 o Nodes that support a specific (experimental or eventual 1004 standard) use of some or all of the Type of Service bits are 1005 permitted to change the value of those bits in packets that 1006 they originate, forward, or receive, as required for that 1007 specific use. Nodes should ignore and leave unchanged any bits 1008 of the Type of Service field for which they do not support a 1009 specific use. 1011 o An upper-layer protocol must not assume that the value of the 1012 Type of Service bits in a received packet are the same as the 1013 value sent by the packet's source. 1015 In flow-based routing, ToS affects flow as part of the 6-tuple. 1016 See "flow-based routing" for details. 1018 7. Upper-Layer Protocol Issues 1020 7.1 Upper-Layer Checksums 1022 Any transport or other upper-layer protocol that includes the 1023 addresses from the IP header in its checksum computation must be 1024 modified for use over IPFF, to include the 50-bit IPFF addresses 1025 instead of 32-bit IPv4 addresses. In particular, the following 1026 illustration shows the TCP and UDP "pseudo-header" for IPFF: 1028 0 1 2 3 1029 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Reserved | | 1032 +-------------------------Source Address + 1033 | | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Protocol | | 1036 +----------------------Destination Address + 1037 | | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Source Port | Destination Port | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Upper-Layer Packet Length | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 o Ports should be included by protocols, that use them. 1045 Else zero. 1047 o If Upper layer does not use ports (but uses Flow instead), 1048 those must be set to zero, for checksum calculation purposes. 1050 o The Upper-Layer Packet Length in the pseudo-header is the 1051 length of the upper-layer header and data (e.g., TCP header 1052 plus TCP data). It may be the standard 14-bit length, 1053 or the 22-bit "jumbogram" length. 1055 Protocols (such as TCP and UDPv5) do not carry their own 1056 length information, in which case the length used in the 1057 pseudo-header is the Payload Length from the IPFF header, minus 1058 the length of any extension headers present between the IPFF 1059 header and the upper-layer header. 1061 The IPFF version of ICMP (& IGMP) includes the above pseudo-header in 1062 its checksum computation; this is a change from the IPv4 version of 1063 ICMP, which does not include a pseudo-header in its checksum. The 1064 reason for the change is to protect ICMP from misdelivery or 1065 corruption of those fields of the IPFF header on which it depends, 1066 which, unlike IPv4, are not covered by an internet-layer checksum. 1068 7.2 Maximum Packet Lifetime 1070 Typically up to 1023 hops (= jumps between Routers). 1071 This is done to prevent routing loops. 1073 Unlike IPv4, IPFF nodes are not required to enforce maximum packet 1074 lifetime, that is "Hops to Live" field may be left unchanged by 1075 the router, if the operator or the routing protocol decides so. 1077 Security Considerations 1079 If some devices along the path do not implement VRF properly, 1080 it can result in data leak across VRF domains. 1082 Additionally a version of IPsec for IP-FF will provide IP-level 1083 encryption for those, who need it. 1084 A separate specification will be written on it. 1086 Acknowledgments 1088 Based on the hard work of "Stephen E. Deering" & "Robert M. Hinden", 1089 from IPv6 project, as well as all previous TCP/IP developers 1090 from DARPA. 1092 Also based on "IPv6 Jumbograms", RFC-2675, by "Stephen E. Deering", 1093 "Robert M. Hinden", & "D. Borman" 1095 While this document is largely based on [RFC-2460], forget not that 1096 the difference in D.N.A. between humans and monkeys is just 1%. 1098 Authors' Contacts 1100 Alexey Eromenko 1101 Israel 1103 Skype: Fenix_NBK_ 1104 EMail: al4321@gmail.com 1105 Facebook: https://www.facebook.com/technologov 1107 References 1109 [ICMPFF] "ICMP for the Internet Protocol Five Fields" by 1110 Alexey.E. 1112 [IPFF-ADDRARCH] "IP Five Fields Addressing Architecture" by Alexey.E. 1114 [RFC-4821] M. Mathis, J. Heffner, "Packetization 1115 Layer Path MTU Discovery", RFC 4821, March 2007. 1117 [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1118 September 1981. 1120 [RFC-2460] S. Deering, R. Hinden "Internet Protocol, Version 6", 1121 December 1998. 1123 [RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 1124 RFC 1700, October 1994. See also: 1125 http://www.iana.org/numbers.html 1127 INTERNET-DRAFT 1128 Alexey 1129 expiration date: 2017-03-29