idnits 2.17.1 draft-chen-softwire-4rd-u-comment-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 473 has weird spacing: '... double trans...' -- The document date (April 10, 2012) is 4396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-02 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwires Working Group M. Chen 3 Internet-Draft FreeBit 4 Intended status: Informational April 10, 2012 5 Expires: October 12, 2012 7 A Commentary on 4rd-U Architecture and Semantics 8 draft-chen-softwire-4rd-u-comment-00 10 Abstract 12 4rd-U is proposed as an effort of unifying encapsulation and double 13 translation solutions for the softwire of IPv4 over IPv6 domain. 14 This attempt introduces new behaviors in the Internet transition 15 architecture as well as semantics other than that of well-known 16 Internet protocols. This documents provides a commentary on the 17 semantic changes and their impacts. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 12, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. 4rd-U Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. General motivations . . . . . . . . . . . . . . . . . . . 6 58 4.2. Technical problems to solve . . . . . . . . . . . . . . . 6 59 4.3. Technical means of the solution . . . . . . . . . . . . . 7 60 5. Semantic Changes of 4rd-U and Potential Impacts . . . . . . . 9 61 5.1. Semantics: existence of fragment header . . . . . . . . . 9 62 5.2. Semantics: IPv6 packet identification . . . . . . . . . . 9 63 5.3. Semantics: Hop Limit of IPv6 . . . . . . . . . . . . . . . 10 64 5.4. Semantics: IP/ICMP relationship . . . . . . . . . . . . . 11 65 6. On Tunnel as Architectural Building Block . . . . . . . . . . 13 66 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 1. Introduction 74 The 4rd-U [I-D.despres-softwire-4rd-u] is proposed with the goal of 75 unifying encapsulation and double translation into a single standard. 76 That effort identifies its technical objective to realize the full 77 transparency as in encapsultion and meanwhile the visibility of L4 78 protocol data unit (PDU) as in double translation. The designers of 79 4rd-U expect it plays the role of a replacement of the MAP suites, 80 including MAP [I-D.mdt-softwire-mapping-address-and-port], MAP-E 81 [I-D.mdt-softwire-map-encapsulation], MAP-T 82 [I-D.mdt-softwire-map-translation] and the DHCP option for MAP 83 [I-D.mdt-softwire-map-dhcp-option]. Throughout this document, the 84 term "MAP", unless explicitly specified, refers to the suite of MAP 85 documents, as an entire description of the MAP architecture. 87 This commentary is purposed in sharing the observation on 4rd-U 88 proposal. It covers part of the 4rd-U principles, focusing on its 89 major semantics changes, especially those that possibly impact the 90 architecture of the Internet and its transition. The commentary 91 itself doesn't conclude if 4rd-U is or isn't a deployable 92 architecture for transition. It provides information for those who 93 would like to do such a judgement. The commentry can be referenced 94 by 1) implementors/testers of 4rd-U to cover the architectural 95 concerns when they set the test scenarios; 2) operators to evaluate 96 if 4rd-U is a safe choice fitting their own networking environment 97 and practice experiences; 3) the community of the Internet 98 engineering to evaluate 4rd-U technology. 100 This commentary sticks to the newest, currectly version -06, of the 101 4rd-U draft. Unless explicitly specified, the discussion doesn't 102 cover the feasures once involved into the 4rd-U early versions but 103 now already deprecated or obsolteted by other mechanisms. 105 This commentary covers only topics that the author(s) have 106 investigated. Co-authorship is welcome and input of further 107 investigations is expected. 109 2. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 3. Acknowledgements 117 The author(s) thank Remi Despres for his efforts in continuously 118 improving 4rd-U design and discussions through maillist and private 119 communication. No matter if the 4rd-U will or will not become 120 standard, such an effort would be significantly valuable for the 121 collective understanding. A lot of contents of this commentary are 122 illuminated by the maillist discussion in the softwire WG, including 123 the view points contributed by Congxiao Bao, Wojciech Dec, Xing Li, 124 Satoru Matsushima, Wentao Shang, Ole Troan and others. 126 4. 4rd-U Overview 128 4rd-U draft contains a lot of features overlapping the problems that 129 MAP also having addressed. The following analysis on 4rd-U 130 motivations, major technical objectives and exclusive solutions is 131 based on the understanding of the commentary author(s) through 132 reading 4rd-U drafts, comparing 4rd-U and MAP suites, and discussing 133 with the 4rd-U designers. 135 4.1. General motivations 137 Generally, 4rd-U is motivated with the purposes of 139 (M1) unification of encapsulation and double translation for IPv4 140 residual deployment; 142 (M2) simplification of L4 protocol treatment; 144 (M3) simplification of address distinguishment in the environment 145 where there are also native IPv6 communications. 147 4.2. Technical problems to solve 149 Trying to solve the following problems makes 4rd-U different from 150 MAP. 152 (O1) DF=1/MF=1 transparency: [RFC6145], whose header processing of 153 translation is applied in MAP-T, doesn't cover the case where 154 IPv4 packet with both "Don't Fragment" (DF) and "More Fragment" 155 (MF) flags set. MAP-T points out that this corner case is very 156 minor and some literature (e.g., [IMC07]) argues such a case is 157 considered abnormal regarding IPv4 protocol [RFC0791], followed 158 by statistics on this abnormaly. 4rd-U argues it should be 159 supported no matter how minor it is observed in practice. 161 (O2) ToS transparency: DiffServ architecture ([RFC2475]) points out 162 that, (regarding the IPSec tunnel consideration,) whether DSCP 163 change in tunneling domain should be visible to the tunneled 164 protocol or not, depends upon the role of "tunnel" in the 165 architectural perspective. MAP-E follows [RFC2473] and keeps 166 it as unchanged. MAP-T follows [RFC6145] and copies the IPv4 167 ToS into IPv6 TrafficClass and vice versa. 4rd-U argues ToS 168 should be kept unchanged when the packet traverses the IPv6 169 domain, except the ECN bits. 171 (O3) IPv6 O&A tools fully functioning: when IPv4 packet is 172 encapsulated, IPv4 protocol details is hidden and existing IPv6 173 O&A tools are unable to view these hidden details, and 174 accordingly functions like filtering is not able to be 175 performed. 4rd-U argues this "drawback" of MAP-E should and 176 could be overcome without losing the full transparency of 177 encapsulation. 179 (O4) Deep L4 inspection: when IPv4 packet is encapsulated with IPv6, 180 typically middle boxes in the IPv6 domain doesn't have the 181 functionality of deep inspection on the Layer-4 protocol data 182 unit (PDU) in the encapsulated packet. This makes MAP-E 183 traffic is unable to be filtered with the existing IPv6 L4 184 filter rules . 4rd-U argues this "drawback" of MAP-E should and 185 could be overcome without losing the full transparency of 186 encapsulation. 188 (O5) Checksum transparency: MAP-T, along with [RFC6145], adjust L4 189 protocol checksum at the translator. 4rd-U argues [RFC6145] 190 optionally supporting DCCP checksum adjustment may cause wrong 191 checksum for receiver of MAP-T if IPv4-to-IPv6 translator does 192 the adjustment while the IPv6-to-IPv4 one doesn't. It also 193 argues checksum validity should be ensured through address in 194 order to simplify L4 processing. 196 4.3. Technical means of the solution 198 In order to achieve the goal of (M1) and to solve the problems listed 199 above, 4rd-U proposes a series of technical means. Essentially, a 200 "reversible header mapping" is defined through these means, having 201 IPv4 header fields (except options) reserved but the header is not 202 embedded as a whole. This is to achieve the support for deep L4 203 inspection as translation can, meanwhile to keep the IPv4 header 204 information unchanged the IPv6 domain. In details, these means 205 include: 207 (T1) Always-on fragment header: as a container preserving not only 208 the fragmentation-related information but also some other 209 fields. 211 (T2) DF preserver: at the leftmost bit of IPv6 packet identification 212 field of the fragment header, carrying the original IPv4 213 packet's DF bit. 215 (T3) ToS preserver: at the bits 8~15 of IPv6 packet identification 216 field of the fragment header, carrying the original value of 217 IPv4 packet's ToS field. 219 (T4) TTL preservers: TTL first bit preserved at the leftmost bit of 220 IPv6 HopLimit; TTL bits 1~7 preserved at bit 1~7 of IPv6 packet 221 identification field of the fragment header. 223 (T5) ICMPv4 being carried by IPv6: providing full transparency for 224 ICMPv4 messages traversing the IPv6 domain; also as a required 225 solution to deal with the problem that [RFC6145] has identified 226 regarding the PTB message with MTU less than 1280 bytes 227 (translated), and meanwhile keep the DF=1 transparent. 229 (T6) ICMPv6 being translated: with the same logic that [RFC6145] 230 defines for the ICMPv6 error messages generated by the middle 231 boxes in the IPv6 domain. 233 4rd-U also defines techinal means for (M2) and (M3), respectively. 235 Checksum neutrality preserver (CNP): in the end of IPv6 interface 236 identifier, with the value ensuring the mapped IPv6 address 237 having the same checksum with the original IPv4 address. 239 V-octet: as a mark for 4rd-U address, (0x03 for bits 64~71) in IPv6 240 address generated by the 4rd-U CE or BR, as a means 241 distinguishing 4rd-U traffic from native usage. 243 The current version of this commentary focuses on the architecture 244 issue and therefore motivation (M1), technical objectives (O1)~(O5), 245 and technical means (T1) through (T6) are in scope. 247 5. Semantic Changes of 4rd-U and Potential Impacts 249 The above technical means more or less change the well-known Internet 250 protocol semantics. It is not the task of this commentary to judge 251 if these changes are serious concerns or not. It is the task of it 252 to identify what kind of semantic changes they are and to identify 253 what potential impacts they have. 255 Sometimes MAP-E or MAP-T semantics is also clarified when the 256 clarification is considered helpful to share understanding. In the 257 term of header processing semantics, MAP-E is based on [RFC2473] 258 while MAP-T on [RFC6145]. 260 5.1. Semantics: existence of fragment header 262 IPv6 semantics: 263 Indicating the source has fragmented the datagram. 265 RFC6145 semantics: 266 Indicating the source allows further fragmentation, informing 267 the IPv6-to-IPv4 translator clear the DF when making the IPv4 268 packet. 270 4rd-U semantics: 271 Indicating nothing specific to fragmentation facts, but always 272 being included. 274 Impact: 275 Always seeing fragment header is strange to middle boxes in the 276 IPv6 domain. The system administrators of any middle box 277 SHOULD be informed on the deployment of 4rd-U. 279 5.2. Semantics: IPv6 packet identification 281 IPv6 semantics: 282 32-bit packet identification. 284 RFC6145 semantics: 285 32-bit packet identification with, if translated from IPv4, 286 having the original IPv4 packet identification in lower 16 bits 287 while keeping the higher 16 bits zero. 289 4rd-U semantics: 290 If translated from IPv4, having the original IPv4 packet 291 identification in lower 16 bits while original DF in the 292 highest bit, TTL in the bits 1~7, DSCP in bits 8~13, ECN in 293 bits 14~15. 295 Impact: 297 a. Single translation, which is supported by RFC6145, 298 becomes incompatible in 4rd-U as the 32-bit full IPv6 299 identification cannot be distinguished (workaround: 300 V-octet may help the distinguishment with need of 301 verification.) 303 b. Session identification in middlex boxes (firewalls) is 304 confused because the same IPv4 datagrams might be 305 fragmented into packets and their value of TTL and ECN 306 may become different when entering the IPv6 domain, 307 causing different identification in IPv6. Therefore the 308 technical objective (O3) is not fully reached. 310 5.3. Semantics: Hop Limit of IPv6 312 IPv6 semantics: 313 One decrement per hop. In practice (e.g., some hop-security 314 mechanisms, like that is designed in RIPng ([RFC2080]), the 315 generic TTL-security ([RFC5082]), which is used in both OSPFv3 316 and BGP4+ products), Hop Limit is initialized to 255 and 317 receivers calculates the hop-distance from the source. 319 RFC2473 semantics: 320 Tunnel entry point initializes HopLimit to 255 in IPv6. Hop 321 Limit reaching 0 indicates that tunnel exit point is 322 unreachable due to, e.g., routing problems (count-to-infinity), 323 treated as an link failure. Therefore the "hop limit exceeded" 324 ICMPv6 error message generated in IPv6 domain is translated to 325 "host unreachable". 327 RFC6145 semantics: 328 Tunnel entry point copies TTL to Hop Limit in IPv6. Hop Limit 329 decrement in IPv6 domain is reflected to IPv4 TTL when packet 330 is translated back to IPv4, treated as multi-hop paticipant in 331 the end-to-end delivery path. Therefore the "hop limit 332 exceeded" ICMPv6 error message generated in IPv6 domain is 333 translated to "time to live exceeded in transit". 335 4rd-U semantics: 336 The leftmost bit of IPv4 TTL is copied to the leftmost bit of 337 Hop Limit field, while the bit 1~7 of Hop Limit is initialized 338 to 127. 4rd-U translates ICMPv6 "hop limit exceeded" message, 339 generated in the IPv6 domain, to "time to live exceeded" ICMPv4 340 message. 342 Impact: 344 a. The behavior of 4rd-U translation of "hop limit exceeded" 345 is contradictory to the behavior that IPv4 TTL is not 346 changed through the IPv6 domain. 348 b. The IPv6 domain maximum hop count must be limited below 349 127. (4rd-U draft considers it is not a problem in 350 practice.) 352 c. The criterion of IPv6 routing "count-to-infinity" is 353 changed. Even if the diameter of the IPv6 domain is 354 surely less than 127, considering the temporary route 355 loop often happens in dynamic routing, limiting hop below 356 127 is actually setting an allowed diameter far less than 357 this value. 359 d. IPv6 normal usage of Hop Limit larger than 127 is 360 confused. Impact involves the TTL-security mechanism for 361 IPv6 routing, application-layer hop count constraints, 362 etc. Host behind 4rd-U CE may generate attack packets 363 breaking the IPv6 TTL-security mechanism, through 364 spoofing CE's source address and applying any TTL value 365 with leftmost bit set. Wheter other mechanism of 4rd-U 366 (like V-octet) provides sufficient means of protection 367 needs to be further investigated and verified. 369 5.4. Semantics: IP/ICMP relationship 371 IPv4/v6 semantics: 372 ICMP is considered a companion of IP rather than a L4 protocol. 373 IPv4 [RFC0791] carries ICMPv4 [RFC0792] and served by ICMPv4; 374 IPv6 [RFC2460] carries ICMPv6 [RFC4443] and served by ICMPv6. 375 IPv4 address integrity is protected by IPv4 header checksum; 376 IPv6 address integrity is protected by ICMPv6 checksum, which 377 covers IPv6 pseudo-header. 379 RFC2473 semantics: 380 ICMPv4 is carried by IPv4 and the entire IPv4 PDU is 381 encapsulated by IPv6. The tunneled protocol contains header 382 checksum. As a tunnel link, the check on the tunneled protocol 383 is never supposed to be performed in the middle of the link but 384 only the tunnel end points. 386 RFC6145 semantics: 387 IPv4/ICMPv4 pair is translated to IPv6/ICMPv6 pair and vise 388 versa. Double translation may lose semantics accuracy for some 389 IPv4 error messages in acceptable level. 391 4rd-U semantics: 392 IPv4/ICMPv4 pair is mapped to IPv6/ICMPv4 pair and vise versa; 393 ICMPv6 generated in IPv6 domain (IPv6/ICMPv6 pair) is 394 translated to IPv4/ICMPv4 pair, following the same way as 395 RFC6145 does. 397 Impact: 399 a. IPv6 domain MUST set all filters in middle boxes to pass 400 protocol 1 (ICMP) as IPv6 payload in order to support 401 4rd-U functionality. 403 b. The IPv6 O&A tools that ensure ICMP error message being 404 destined to original source cannot function regarding 405 ICMPv4 as payload. This is not a mistake but doesn't 406 satisfy the technical objective (O3). 408 c. In the IPv6/ICMPv4 pair, both IPv6 header and ICMPv4 409 header doesn't contain checksum regarding addresses. 410 Integrity protection is totally lost. 412 6. On Tunnel as Architectural Building Block 414 Because 4rd-U calls it self a "tunneling" solution, it is necessary 415 to review the concept of "tunnel" and identify what kind of 4rd-U 416 tunnel is in the term of architectural building block in the Internet 417 transition. 419 In the background section of "A Scheme for an Internet Encapsulation 420 Protocol, Version 1" ([RFC1241]), it is stated: 422 A tunnel is essentially a Source Route that circumvents 423 conventional routing mechanisms. 425 It is further pointed out that the ways of making a tunnel includes 426 source routing option, new IP option, and IP encapsulation. 427 [RFC2475], mentioning different view of architectural building block 428 about "tunnel", also reflects such an understanding. In this 429 context, let's call it the tunnel of "general sense". General-sense 430 tunnel can be a one-hop virtual link or a multi-hop participant in 431 the delivery path. 433 On the other hand, the community has widely accepted "tunnel", unless 434 it is explicitly specified, as a conventional alias of the building 435 block provided by the technology of encapsulation. Let's call that 436 tunnel of "narrow sense". Narrow-sense tunnel, in architecture, 437 behaves as a one-hop virtual link. 439 With the understanding of "circumventing conventional routing 440 mechanism", surely double translation is also a sort of tunneling in 441 general sense, but behaves as the building block of multi-hop 442 participant. 444 4rd-U is surely a sort of general-sense tunneling technology. 445 However, when one claims 4rd-U having the advantages of tunnel in 446 comparison to translation approaches, the wording is obviously 447 talking about the narrow-sense tunneling. It needs further 448 investigation to ensure if 4rd-U is qualified to be called as a 449 tunnel in the narrow sense. 451 7. Summary 453 The observation is, 4rd-U introduces 3 types of behaviors: 455 Similar to encapsulation: 457 - IPv4 fields DF, ToS, TTL are kept unchanged, traversing the 458 IPv6 domain. 460 - Middle boxes in the tunnel are unable to check if ICMPv4 461 message is sent to correct destination. 463 Similar to double translation: 465 - Without protocol layering, position of IPv4 fields are 466 changed; 468 - IPv4 options are removed; 470 - Translation ICMPv6 messages generated in IPv6 domain to 471 ICMPv4 messages with the same logic of RFC6145. 473 Never seen in encapsulation nor in double translation: 475 - IPv6 carries ICMPv4 directly; 477 - TTL leftmost bit is copied to Hop Limit leftmost bit. 479 When setting the testing scenarios, it is recommended that the above 480 semantics changes and behaviors are fully considered. It is also 481 expected that the designer, implementator and tester provides 482 comprehensive evidence either to ensure those changes as well as new 483 behaviors are not of problem in practice or to clarify the boundary 484 conditions, with which as prerequisites 4rd-U can work safely and 485 reach its design objectives. 487 8. IANA Considerations 489 This specification does not require any IANA actions. 491 9. Security Considerations 493 There are no new security considerations pertaining to this document. 495 10. References 497 [I-D.despres-softwire-4rd-u] 498 Despres, R., Penno, R., Lee, Y., Chen, G., and J. Qin, 499 "IPv4 Residual Deployment via IPv6 - Unified Solution 500 (4rd)", draft-despres-softwire-4rd-u-06 (work in 501 progress), March 2012. 503 [I-D.mdt-softwire-map-dhcp-option] 504 Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C. 505 Bao, "DHCPv6 Options for Mapping of Address and Port", 506 draft-mdt-softwire-map-dhcp-option-02 (work in progress), 507 January 2012. 509 [I-D.mdt-softwire-map-encapsulation] 510 Troan, O., Matsushima, S., and T. Murakami, "MAP 511 Encapsulation (MAP-E) - specification", 512 draft-mdt-softwire-map-encapsulation-00 (work in 513 progress), January 2012. 515 [I-D.mdt-softwire-map-translation] 516 Bao, C., Li, X., Zhai, Y., Murakami, T., and W. Dec, "MAP 517 Translation (MAP-T) - specification", 518 draft-mdt-softwire-map-translation-01 (work in progress), 519 March 2012. 521 [I-D.mdt-softwire-mapping-address-and-port] 522 Bao, C., Troan, O., Matsushima, S., Murakami, T., and X. 523 Li, "Mapping of Address and Port (MAP)", 524 draft-mdt-softwire-mapping-address-and-port-03 (work in 525 progress), January 2012. 527 [IMC07] John, W. and S. Tafvlin, "Analysis of Internet Backbone 528 Traffic and Header Anomalies observed", Proc. of IMC 529 2007 , Aug 2007, . 531 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 532 September 1981. 534 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 535 RFC 792, September 1981. 537 [RFC1241] Woodburn, R. and D. Mills, "Scheme for an internet 538 encapsulation protocol: Version 1", RFC 1241, July 1991. 540 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 541 January 1997. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 547 (IPv6) Specification", RFC 2460, December 1998. 549 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 550 IPv6 Specification", RFC 2473, December 1998. 552 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 553 and W. Weiss, "An Architecture for Differentiated 554 Services", RFC 2475, December 1998. 556 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 557 Message Protocol (ICMPv6) for the Internet Protocol 558 Version 6 (IPv6) Specification", RFC 4443, March 2006. 560 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 561 Pignataro, "The Generalized TTL Security Mechanism 562 (GTSM)", RFC 5082, October 2007. 564 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 565 Algorithm", RFC 6145, April 2011. 567 Author's Address 569 Maoke Chen 570 FreeBit Co., Ltd. 571 13F E-space Tower, Maruyama-cho 3-6 572 Shibuya-ku, Tokyo 150-0044 573 Japan 575 Email: fibrib@gmail.com