idnits 2.17.1 draft-savola-v6ops-mechv2-interop-impl-template-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 183 has weird spacing: '... * If the I...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 30, 2004) is 7392 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) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-01 ** Downref: Normative reference to an Informational RFC: RFC 2983 (ref. '3') Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Savola 2 Internet-Draft CSC/FUNET 3 Expires: July 30, 2004 Jan 30, 2004 5 Basic Transition Mechanisms (RFC 2893bis) Implementation and 6 Interoperability Report Template 7 draft-savola-v6ops-mechv2-interop-impl-template-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on July 30, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This memo is a checklist and a template to verify the implementation 38 status and the interoperability of implemented features of Basic 39 Transition Mechanisms for IPv6 Hosts and Routers (RFC 2893bis), to 40 gather the implementation results to advance, and revise if 41 necessary, RFC 2893bis to Draft Standard. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Part I: Information about the Implementation . . . . . . . . 3 47 3. Part II: Implementantation of the Features . . . . . . . . . 3 48 3.1 Support for Dual Stack . . . . . . . . . . . . . . . . . . . 3 49 3.1.1 DNS Resolver Support . . . . . . . . . . . . . . . . . . . . 3 50 3.2 Configured Tunneling . . . . . . . . . . . . . . . . . . . . 4 51 3.2.1 Fragmentation and MTU . . . . . . . . . . . . . . . . . . . 4 52 3.2.2 Hop Limit Handling . . . . . . . . . . . . . . . . . . . . . 5 53 3.2.3 ICMPv4 Errors . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.2.4 IPv4 Header Construction . . . . . . . . . . . . . . . . . . 6 55 3.2.5 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2.6 Link-local Addresses . . . . . . . . . . . . . . . . . . . . 8 57 3.2.7 Neighbor Discovery over Tunnels . . . . . . . . . . . . . . 8 58 3.3 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 8 59 4. Part III: Interoperability of the Features . . . . . . . . . 8 60 4.1 MTU and Fragmentation . . . . . . . . . . . . . . . . . . . 8 61 4.2 ICMP Error Messages . . . . . . . . . . . . . . . . . . . . 9 62 4.3 Encapsulation and Decapsulation . . . . . . . . . . . . . . 9 63 4.4 Link-local Addresses and Neighbor Discovery . . . . . . . . 10 64 5. Security Considerations . . . . . . . . . . . . . . . . . . 10 65 Normative References . . . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 67 Intellectual Property and Copyright Statements . . . . . . . 12 69 1. Introduction 71 This memo is a checklist and a template to verify the implementation 72 status and the interoperability of implemented features of Basic 73 Transition Mechanisms for IPv6 Hosts and Routers (RFC 2893bis) [1], 74 to gather the implementation results to advance, and revise if 75 necessary, RFC 2893bis to Draft Standard [2]. 77 This memo has three templates: the contact information and basic 78 details of an implementation, the implementation status, and the 79 interoperability. 81 Hints for filling the template are given, when appropriate, in square 82 brackets. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are 86 used only to refer to the requirement level specified in RFC 2893bis 87 [1]. 89 2. Part I: Information about the Implementation 91 Name of the implementation: 93 Version number, if appropriate: 95 Organization: 97 Origin of code: [developed from scratch, adapted, etc.?] 99 Information from: [name and email address] 101 3. Part II: Implementantation of the Features 103 3.1 Support for Dual Stack 105 Is a configuration switch provided to disable either stack? (MAY) 107 * IPv4: [YES/NO] 108 * IPv6: [YES/NO] 110 Does DNS resolver implementation support AAAA records: [YES/NO] 112 3.1.1 DNS Resolver Support 114 (Only filled if AAAA records are supported.) 115 When a query locates both AAAA and A records, 117 Does the library filter or order (or provide the capability to do 118 so) the results returned to the application to influence the 119 selection of IP version? (MAY) 121 * filter: [YES/NO] 122 o Is this configurable on the system level? [YES/NO] 123 * order: [YES/NO] 124 o Is this configurable on the system level? [YES/NO] 126 If the results are ordered, which records are ordered first: (MAY) 127 [AAAA/A] 129 If the results are filtered or ordered, is application allowed to 130 control whether or not filtering takes place? (MUST): [YES/NO] 132 3.2 Configured Tunneling 134 Is configured tunneling supported? [YES/NO] 136 3.2.1 Fragmentation and MTU 138 Does the implementation treat the tunnel as an interface with MTU 139 of about 64 kilobytes? (MUST NOT) [YES/NO] 141 Does the implementation support static MTU determination? [YES/NO] 143 Does the implementation support dynamic MTU determination? 144 (OPTIONAL) [YES/NO] 146 If yes to both, is it possible to choose between static and 147 dynamic MTU on a per-tunnel basis? (SHOULD) [YES/NO] 149 3.2.1.1 Static MTU 151 (Please only fill in if implemented.) 153 Is the default MTU be between 1280 and 1480 bytes (inclusive)? 154 (MUST) [YES/NO] 156 Is the default MTU 1280 bytes? (SHOULD) [YES/NO] 157 Is there a configuration knob to change the MTU value? (MUST if 158 not 1280 by default) [YES/NO] 160 Is IPv4 Don't Fragment bit set used when encapsulating? (MUST NOT) 161 [YES/NO] 163 3.2.1.2 Dynamic MTU Determination 165 (Please only fill in if implemented.) 167 oes dynamic MTU determination behave as described in the algorithm 168 described in Section 3.2.2? (SHOULD) [YES/NO] 170 In particular, 172 * Are IPv6 packet too big messages sent if IPv6 packet 173 is larger than 1280 and does not fit into the IPv4 174 path MTU? [YES/NO] 175 * If the IPv6 packet is not larger than 1280 bytes, but 176 the IPv4 path MTU is less than equal to 1300, is the 177 encapsulation done without setting the Don't Fragment 178 bit in the IPv4 header? [YES/NO] 179 * If the IPv4 path MTU is larger than 1300, and an IPv6 180 packet which does not fit into the IPv4 path MTU is 181 to be tunneled, is ICMv6 "packet too big" sent back, 182 pointing to the maximum available MTU? [YES/NO] 183 * If the IPv4 path MTU is larger than 1300, and the 184 IPv6 packet fits in it, is Don't Fragment bit set in 185 the encapsulation? [YES/NO] 187 If "no" to any one of these, please elaborate (optional): 189 3.2.2 Hop Limit Handling 191 Is Hop Limit decreased by one only when forwarding the IPv6 192 packet, as with any regular datalink? [YES/NO] 194 Is it possible to administratively configure IPv4 TTL of a tunnel? 195 [YES/NO] 197 * If so, is it possible using IP Tunnel MIB? [YES/NO] 199 Is the default TTL 255? [YES/NO] 201 3.2.3 ICMPv4 Errors 203 (Do not respond if only static MTU is supported, and ICMP errors are 204 not relayed.) 206 Are IPv4 packet too big ICMP errors relayed as IPv6 ICMP packet 207 too big errors? [YES/NO] 209 Are other kind of ICMP errors relayed as ICMPv6 messages if the 210 ICMPv4 messages include enough payload? [YES/NO] 212 * If yes, is Destination Unreachable - 213 Address Unreachable code used? [YES/NO] 215 3.2.4 IPv4 Header Construction 217 Is ToS byte, when encapsulating, zero by default? [YES/NO] 219 * If not, does the behaviour comply to 220 RFC 2983 [3] 222 and 223 3168 [4] 224 section 9.1? [YES/NO] 226 Is the source address the outgoing interface address unless 227 otherwise configured? [YES/NO] 229 Can the source address of be administratively set to something 230 else (SHOULD)? [YES/NO] 232 3.2.5 Decapsulation 234 Does the node receive and process tunneled packets which have not 235 been addressed to one of its own IPv4 addresses (e.g. 236 255.255.255.255 or a directed broadcast address)? (must not) [YES/ 237 NO] 239 Is source address of the packets arriving at the interface 240 verified to be the tunnel endpoint configured at this node? (MUST) 241 [YES/NO] 243 * Are packets failing that check discarded (MUST)? [YES/NO] 244 * Are any ICMP messages generated (SHOULD NOT)? [YES/NO] 245 * Does the implementation generate ICMP destination 246 unreachable packets for unknown protocols? [YES/NO] 247 o If yes, is the same ICMP code used here? 248 (MAY) [YES/NO] 250 Is "Strict RPF" -like mechanism implemented for incoming IPv4 251 packets? (MAY) [YES/NO] 253 * If so, is it disabled by default (RECOMMENDED)? [YES/NO] 254 * Are packets failing this check discarded (SHOULD)? [YES/NO] 255 o Are any ICMP messages generated by default 256 (SHOULD NOT)? [YES/NO] 258 Is the IPv6 MRU on the tunnel interfaces (at least) the maximum of 259 1500 bytes and the largest (IPv6) interface MTU on the 260 decapsulator? (MUST) [YES/NO] 262 Is IPv4 tunnel packet reassembly supported up to (at least) the 263 maximum of 1500 bytes and the largest MTU of the IPv4 interfaces? 264 (MUST) [YES/NO] 266 * Is there a knob to set a larger value? [YES/NO] 267 * Is it possible to set a smaller value (MUST NOT)? [YES/NO] 269 Are the IPv6 ToS bits modified when decapsulating? [YES/NO] 271 * If so, is this conformant with RFC 2983 and 272 RFC3168 section 9.1? [YES/NO] 274 Is the IPv6 packet length determined from the IPv6 payload length 275 (and not e.g., IPv4 length)? (MUST) [YES/NO] 277 After decapsulation, are packets with invalid IPv6 source 278 addresses discarded (MUST)? [YES/NO] 280 * Are all of the following discarded (SHOULD): [YES/NO] 281 1. IPv6 multicast addresses (FF00::/8) 282 2. The loopback address (::1) 283 3. IPv4 compatible addresses (::/96) except ::/128 284 (the unspecified address) 285 4. IPv4-mapped IPv6 addresses (::ffff:0:0/96) 287 * If not, what's missing: 289 * If more are discarded, please elaborate (optional): 291 Are the resulting IPv6 packets subjected to a strict RPF -like 292 ingress filter (should)? [YES/NO] 294 3.2.6 Link-local Addresses 296 Does every IPv6 tunnel interface have a link-local address (MUST)? 297 [YES/NO] 299 What method is used to form the identifier: 301 * IPv4 address as described in the document? [YES/NO] 302 o If there are multiple addresses on an interface, 303 is just one chosen in some fashion? [YES/NO] 305 * If some other mechanism, please describe (optional): 307 3.2.7 Neighbor Discovery over Tunnels 309 Does the implementation at least accept and respond to NUD probes? 310 (MUST) [YES/NO] 312 Does the implementation send NUD probes? (SHOULD) [YES/NO] 314 * If yes, can NUD probes be omitted on router-to-router 315 links if a routing protocol tracks bidirectional 316 reachability? [YES/NO] 318 Are Source or Target Link Layer Address options sent with Neighbor 319 Discovery? (SHOULD NOT) [YES/NO] 321 Is the content of such options silently ignored? (MUST) [YES/NO] 323 3.3 Miscellaneous 325 Are interfaces to different links treated as separate (e.g., from 326 Discovery point-of-view)? (must) [YES/NO] 328 4. Part III: Interoperability of the Features 330 (When describing the tested interoperability of a feature with 331 another implementation, please include the name of the implementation 332 and date, even, or place (as appropriate). Abbreviations should be 333 used and explained as appropriate.) 335 4.1 MTU and Fragmentation 336 Static MTU tested against Static MTU: 338 * same MTU at each end: 339 * different MTUs at each end: 340 * a lower IPv6 MTU on the path than 341 configured: 342 * all of these also work with IPv4 343 fragmentation: 345 Static MTU tested against Dynamic MTU: 347 * When Dynamic MTU sends larger packets than 348 the static MTU at the other end: 349 * all of these also work with IPv4 350 fragmentation: 351 * all the four branches of the dynamic 352 algorithm tested: 354 Dynamic MTU tested against Dynamic MTU: 356 * all the four branches of the dynamic 357 algorithm tested: 359 4.2 ICMP Error Messages 361 Can relay ICMPv4 Packet Too Big errors to ICMPv6 so that the other 362 implementations process them: 364 Can receive and process ICMPv6 messages generated from ICMPv4 365 Packet Too Big messages: 367 Do both of these also work for other kind of ICMP errors? 369 4.3 Encapsulation and Decapsulation 371 If implemented, has ToS byte modification been tested: 373 * Our encapsulation is understood: 374 * We understand what others encapsulate: 376 If "Strict RPF" -like mechanism is implemented for IPv4, it has 377 been tested to work with: 379 IPv4 packet reassembly, up to the largest MTU of IPv4 interfaces, 380 has been tested: 382 The implementation can defend its interface address with DAD (the 383 unspecified address not filtered out): 385 If "Strict RPF" -like mechanism is implemented for IPv6, it has 386 been tested to work with: 388 4.4 Link-local Addresses and Neighbor Discovery 390 Link-local addresses are tested to be generated in a unique-enough 391 fashion: 393 Does the implementation accept and respond to NUD probes: 395 Does the implementation send NUD probes which are responded to: 397 Does the implementation ignore the content (and not the whole 398 message) of received SLLA/TLLA options: 400 Does the implementation send SLLA/TLLA options, and the content is 401 properly ignored: 403 5. Security Considerations 405 This memo provides a template for checking the implementation and 406 interoperability status of a standard, and as such has no security 407 issues. 409 Normative References 411 [1] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 412 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in 413 progress), October 2003. 415 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 416 9, RFC 2026, October 1996. 418 [3] Black, D., "Differentiated Services and Tunnels", RFC 2983, 419 October 2000. 421 [4] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 422 Explicit Congestion Notification (ECN) to IP", RFC 3168, 423 September 2001. 425 Author's Address 427 Pekka Savola 428 CSC/FUNET 430 Espoo 431 Finland 433 EMail: psavola@funet.fi 435 Intellectual Property Statement 437 The IETF takes no position regarding the validity or scope of any 438 intellectual property or other rights that might be claimed to 439 pertain to the implementation or use of the technology described in 440 this document or the extent to which any license under such rights 441 might or might not be available; neither does it represent that it 442 has made any effort to identify any such rights. Information on the 443 IETF's procedures with respect to rights in standards-track and 444 standards-related documentation can be found in BCP-11. Copies of 445 claims of rights made available for publication and any assurances of 446 licenses to be made available, or the result of an attempt made to 447 obtain a general license or permission for the use of such 448 proprietary rights by implementors or users of this specification can 449 be obtained from the IETF Secretariat. 451 The IETF invites any interested party to bring to its attention any 452 copyrights, patents or patent applications, or other proprietary 453 rights which may cover technology that may be required to practice 454 this standard. Please address the information to the IETF Executive 455 Director. 457 Full Copyright Statement 459 Copyright (C) The Internet Society (2004). All Rights Reserved. 461 This document and translations of it may be copied and furnished to 462 others, and derivative works that comment on or otherwise explain it 463 or assist in its implementation may be prepared, copied, published 464 and distributed, in whole or in part, without restriction of any 465 kind, provided that the above copyright notice and this paragraph are 466 included on all such copies and derivative works. However, this 467 document itself may not be modified in any way, such as by removing 468 the copyright notice or references to the Internet Society or other 469 Internet organizations, except as needed for the purpose of 470 developing Internet standards in which case the procedures for 471 copyrights defined in the Internet Standards process must be 472 followed, or as required to translate it into languages other than 473 English. 475 The limited permissions granted above are perpetual and will not be 476 revoked by the Internet Society or its successors or assignees. 478 This document and the information contained herein is provided on an 479 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 480 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 481 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 482 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 483 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Acknowledgment 487 Funding for the RFC Editor function is currently provided by the 488 Internet Society.