idnits 2.17.1 draft-gilbert-ipngwg-enterprise-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1025 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** There are 32 instances of lines with control characters in the document. ** The abstract seems to contain references ([IPv6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 2002) is 7863 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: 'RFC2026' is mentioned on line 12, but not defined == Missing Reference: 'IPv6-DIS' is mentioned on line 690, but not defined == Missing Reference: 'RFC2893' is mentioned on line 744, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Unused Reference: 'RFC-2893' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC-2874' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'IPv6-DISC' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'ADDRCONF' is defined on line 930, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Downref: Normative reference to an Historic RFC: RFC 2874 ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (ref. 'IPv6-DISC') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' ** Obsolete normative reference: RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) -- Possible downref: Non-RFC (?) normative reference: ref. 'NGTRANS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISATAP' Summary: 20 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Paul Gilbert, Cisco Systems 2 Expires October 2002 4 Implementing IPv6 Networks in the Enterprise 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of [RFC2026]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This document is not meant to be a primer on IPv6 [IPv6] or supply any 32 technical information about the protocol, it is meant to give network 33 engineers a place to start and to get ideas as to what to prepare for 34 when thinking about implementing IPv6, and also some changes that need 35 to be made when thinking about the addressing schema. 37 IPv6 brings some useful features that will help in making the 38 transition as painless as possible, things like auto-configuration and 39 renumbering. Particularly useful is the fact that both IPv4 and IPv6 40 can run concurrently on the network, on the same router interface and 41 on the same PC. This affords an evolutionary approach rather that a 42 revolutionary introduction of IPv6 technology. 44 For the purpose of this document the terms router and layer3 switch are 45 used interchangeably 47 1. Introduction. 48 2. Forwarding. 49 3. Forwarding Performance. 50 4. The WAN and the LAN. 51 5. Investment Protection 52 6. Headers. 53 7. Performance Testing. 54 8. Router Implementations. 55 9. Features and Functionalities. 56 9.1 Packet Filtering 57 9.2 IPSEC 58 9.3 Quality of service 59 9.4 Multicast 60 9.5 Urpf 61 10. Statistics 62 11. Basic Requirements. 63 12. Router Memory. 64 13. Management. 65 14. IPv6 Addressing. 66 14.1 Address Types 67 14.2 Address Schema 68 14.3 Address Configuration 69 14.4 Node Addressing 70 14.5 Router Addressing 71 14.6 IPv4compatible IPv6 address 72 14.7 Address Renumbering 73 14.8 Privacy Extensions for Stateless Address Autoconfiguration 74 in IPv6 75 15. ICMPv6 76 16. Path MTU Discovery 77 17. Neighbor Discovery 78 18. Multicast Listener Discovery 79 19. Tunneling 80 20. DNS 81 21. Operation Requirements. 82 22. The Lab. 83 23. References. 84 24. Authors name and address. 86 1. Introduction. 88 Implementing IPv6 typically involves the consideration of both software 89 and hardware, and in some cases both simultaneously. On some routers 90 you may need to upgrade both software and hardware to support the 91 protocol. As with every new application/protocol it is recommended 92 that you first implement in a lab of some kind. If that's not possible 93 then at least a non-critical part of the network should be selected. 95 This document attempts to outline some of the issues that enterprise 96 customers should aware of when looking to implement IPv6. It will 97 examine the differences that one will encounter and considers both 98 hardware and software. 100 2. Forwarding. 102 The forwarding of IPv6 packets from a router's point of view involves 103 nothing more than a longer lookup and possibly the processing of some 104 extension headers. The longer lookup is due to the fact that an IPv4 105 address is 32 bytes and an IPv6 address is 128 bytes. 107 There are 2 possible ways to forward IPv6 packets through a router, in 108 software, which is normally slow and processor intensive, or through 109 hardware, which is fast and is normally done with specialized ASICs or 110 Network Processors. There is also the notion of both, where the routes 111 and forwarding tables are calculated in software, these tables are then 112 downloaded locally to the linecards. It is here at these linecards 113 where the packets will either be forwarded by hardware or software. 115 There are 3 possible scenarios that a vendor could do to in order to 116 support IPv6 forwarding. 118 * Forward IPv6 in the software path on existing platforms. * Forward 119 IPv6 in the hardware path without any modifications to the hardware. * 120 Build new hardware to incorporate IPv6 forwarding 122 3. Forwarding Performance. 124 It is important to note that if the router today cannot forward IPv4 125 packets at wire rate is it most unlikely due to the longer lookups 126 required for IPv6 that they will be able to, without modification 127 forward IPv6 packets at wire rate. 129 If the interface can today, forward IPv4 packets at wire rate, and you 130 enable IPv6 forwarding on that same interface, which it can also 131 forward at wire rate, then the interface should still be wire rate for 132 the sum of both IPv4 and IPv6. 134 So this begs the question, is it important today to look only at 135 equipment that can forward IPv6 packets at wire rate. 137 Experience tells us that in reality most enterprise routers are more 138 than able to fill the pipes available to them, and if congestion is 139 experienced then you can try to deploy QOS and things like compression 140 or can you upgrade to a faster pipe. 142 If you did need to upgrade to a faster pipe then you would want the 143 existing router to be able to support those speeds, or if it didn't a 144 router with more performance and faster interfaces needs to be looked 145 at. 147 4. The WAN and the LAN. 149 In the enterprise there are really 2 types of routers, those that 150 service the LAN and those that service the WAN. 152 In the LAN the packet forwarding requirements are normally higher than 153 in the WAN, the routers used here normally are built with high speed 154 ASICs and can forward packets at a very high rate. Also you can always 155 add bandwidth cheaply, by means of another fiber run and some form of 156 channeling protocol. 158 In the WAN it is slightly different, most routers are almost always 159 faster than the pipe that they have to fill, and therefore features are 160 a little more important than how fast the router performs. There are 161 of course routers on the market that can achieve wire rate forwarding 162 at OC192 rates over multiple ports. These routers sit on the high end 163 of the scale and are required to fill each and every pipe. They are 164 normally found in the Service Provider arena, but may start to find 165 their way into Enterprises as the port speeds that are available 166 increase and the cost of bandwidth gets cheaper. 168 Currently adding bandwidth in the WAN is expensive, and therefore other 169 methods maybe looked at before spending money on increasing it, such as 170 compression and QOS. 172 Hopefully all of the fiber that providers are laying will eventually 173 drive the cost of bandwidth down allowing cheaper high-speed access. 175 5. Investment Protection. 177 Enterprises want to be able to upgrade the routers to have faster 178 backplanes, switching fabrics and linecards and they also want the 179 routers to have a lifetime of somewhere between 3-5 years. Enterprise 180 customers are pretty smart with regards to as to what to expect in 181 terms of investment protection. It would be wrong to expect a router 182 that terminated a whole bunch of ds-0s to now support an OC192 183 interface. 185 All this being said, it might be reasonable to assume - 187 * IPv4 traffic will still be the majority of the traffic for a long 188 period of time. * IPv6 traffic will initially be a small percentage of 189 the overall traffic volumes and grow as the number of applications and 190 users start deploying it. * As applications are written to leverage 191 the benefits of IPv6 the level of IPv6 traffic will increase quickly. 193 It would seem that if the current router could support IPv6 in the 194 "slow path" without requiring any hardware upgrades and if the router 195 did have on it's roadmap plans to support IPv6 with some hardware 196 modifications, such as a linecard or forwarding engine swap then this 197 would be acceptable to most enterprises. 199 It would seem reasonable to expect that if IPv6 takes hold over the 200 next year or two (2002-2004), then the routers deployed in the 201 enterprise today will be expected to forward both IPv4 and IPv6 202 traffic. 204 Of course the other scenario would be a new purchase outright, if this 205 were the case and the router in question did IPv4 at wire rate then it 206 would reasonable to expect the same performance for IPv6. 208 6. Headers. 210 The IPv4 header is 20 bytes and the IPv6 header is 40 bytes, in IPv6 211 all fields are 64 byte aligned, in IPv4 that is not the case because of 212 the options field. Because of the 64 byte alignment it maybe easier to 213 develop ASICs that can forward IPv6 as the routers will know exactly 214 where the bit boundaries are. Most vendors will use the same set of 215 ASICs to forward both IPv4 and IPv6 traffic so it will be interesting 216 to see how this pans out. The true test of exactly what the 217 differences will be should show up in the latency of actually 218 forwarding the packets. 220 7. Performance Testing. 222 One interesting note here is how vendors test the performance of their 223 routers, some use small packets because it suits them to do so, and 224 some use large packets for the very same reason. When testing IPv4 a 225 good weatherspoon is (IMIX) which stands for Internet Mix, e.g. a 226 sample of all the traffic on the Internet over a period of time. So 227 this testing involves packets of various sizes. 229 This is all well and good for IPv4 but as of yet there is no official 230 IMIX for IPv6 packets, but it would be expected to be IPv4 IMIX plus 20 231 bytes extra for the larger IPv6 header. 233 Another important aspect of hardware forwarding is what happens to 234 performance as features are turned on. It's fine purchasing a system 235 that forwards IPv6 at wire rate, but when you turn on a feature, such 236 as packet filtering that performance degenerates significantly. So 237 performance should be evaluated as both pure throughput as well as with 238 features and functionalities enabled. 240 8. Router Implementations. 242 With most router vendors you will either purchase the router with 243 software already installed on it that supports IPv6 or you will 244 install/upgrade you existing router to a newer version of software that 245 supports IPv6. Ideally you would want - 247 * The router to be able to run IPv4 with IPv6 concurrently. * Each 248 router interface should be able to run both IPv4 and IPv6 249 concurrently. * IPv4 routing should be independent of the IPv6 routing 250 and vice versa. * Configuration changes to one should not affect the 251 other. 253 9. Features and Functionalities. 255 When enterprises start to look at vendor support for IPv6 they will 256 need to look at the features and functionalities offered and make a 257 decision as to what is important to them and the network. It would 258 seem appropriate that the features and functionalities that are used 259 now by the company in it's current implementation of IPv4, will also be 260 required to be supported under IPv6. 262 In some cases this will be so, in others it will not. As happened with 263 IPv4 everything will not be delivered at once, this is due to a couple 264 of reasons - 266 * Time to market for router vendors, they need to get code out as a 267 check off item for RFP's and such. * Code for early adopters. * New 268 features and Functionalities will be added as requested by the end 269 users and as standards are developed. * As demand grows each vendor 270 will offer their own specialized versions of code that contain their 271 own particular value add. * As experience is gained, code is hardened 272 and customized. 274 9.1 Packet Filtering. 276 The focus here is security in the form of what a router can and cannot 277 do in terms of allowing or disallowing packets. 279 The Router needs to be programmed as to what packets are to be 280 processed and what packets should be dropped. To do this a router is 281 configured with a set of rules. These rules contain a list of 282 interesting addresses and an action if a packet string is matched. 283 These actions include drop, forward or perform the next lookup. 285 This set of rules could focus just on the source IP address of a host, 286 it could contain both a source and destination IP address, and also 287 possibly look deeper into the packet and care about things such as IP 288 socket numbers, port numbers next headers etc. You need to understand 289 what your requirements are and then ensure that the vendor can support 290 those requirements. 292 9.2 IPSEC. 294 IPSEC is a mandatory element of IPv6 and all implementations must offer 295 it. This enables end-to-end security. In IPv6 there are extension 296 headers, these replace the options field in IPv4. There are 2 297 extension headers that are used with IPSEC; they are the Authentication 298 Header (AH) and the Encapsulated Security Header (ESP). 300 The Authentication Header provides data authentication, data integrity 301 and anti-replay protection for the entire IPv6 packet. 303 The Encapsulated Security Header is used to provide confidentiality, 304 data origin authentication, connectionless integrity, an anti-replay 305 service (a form of partial sequence integrity), and limited traffic 306 flow confidentiality. 308 9.3 Quality of Service. 310 IPv6 brings no more functionality to QOS than IPv4. Both use an 8- 311 Bit field that could represent a DSCP value or a IP Precedence 312 value. 314 If the router supports QOS for IPv4, then the support for QOS for IPv6 315 should be no different. 317 Processes like queuing, policing, shaping, congestion management, 318 congestion control, signaling, and packet fragmentation, for low speed 319 links, should be transparent to the protocol. If they are supported 320 for IPv4 then they should be supported for IPv6. 322 Some interesting questions could be, 324 * Do packets for both IPv4 and IPv6 share queues? * Are the queues 325 configurable? * How do you differentiate between these queues? * Can 326 you configure different polices for each queue? * Is fragmentation 327 supported for low speed links? 329 It may be possible, if the vendor's implementation supports it to 330 define separate QOS policies for IPv4 and IPv6, and in some cases 331 even have different structures for each protocol, such as there own 332 set of queues. 334 9.4 Multicast 336 The defacto standard for multicast routing today is Protocol 337 Independent Multicast(PIM). PIM is covered in many RFC's that will not 338 be discussed in detail here. 340 At some point multicast may be a requirement in your network, if it 341 already isn't. There aren't a lot of IPv6 networks out there today, so 342 it goes without saying that there aren't a lot of IPv6 multicast 343 networks out there. 345 The forwarding of multicast packets is a lot more involved than the 346 forwarding of unicast or broadcast packets. Multicast packets need to 347 be replicated to a group of receivers, from a source via some kind of 348 distribution tree. Routers also need to keep a state of all receivers 349 and sources and to what interfaces it needs to forward interesting 350 packets. What would be important here is whether the replication is 351 done on the router using software or hardware and the amount of state a 352 router can hold. 354 Multicast packet replication tends to be highly processor intensive and 355 therefore must be handled by hardware to ensure that performance is not 356 negatively impacted. 358 If testing a vendor's implementation is a requirement then one should 359 test how the multicast would look in your network. Some vendor's 360 implementations performance will differ. Some may work well with a few 361 sources and lots of receivers; some may work well with lots of sources 362 and lots of receivers. The testing should not only look at packets per 363 second but also the amount of state that can be maintained in the 364 routers. 366 The enterprise as a whole, have been very slow to adopt multicast as a 367 technology that provides any real dollar benefit. Some corporations 368 are using it to provide training and distance learning. 370 IPv6 multicast includes additional fields: scope and flag. The flag 371 indicates if the multicast address is transient, (temporary) or if it 372 is a multicast address that has been permanently assigned by IANA. The 373 scope field indicates the scope of where the multicast traffic is 374 intended to go, eg link local, site local, global etc etc. 376 The basic requirements would seem to be the support of the PIM 377 protocol. PIM comes in many flavors - sparse mode, dense mode and 378 sparse/dense mode. There are also newer protocols that are being 379 developed, eg Source Specific multicast and Bi-Directional PIM. 381 What Multicast technology you deploy should depend on your particular 382 needs, do you have a few sources and lots of receivers, or 1 source and 383 lots of receivers, or is every node both a source and a receiver. 385 Enterprises should evaluate their multicast needs and then ensure that 386 the vendor supports the technology chosen. 388 9.5 Unicast Reverse Path Forwarding 390 Unicast Reverse Path Forwarding (Urpf) is key to stopping DDOS 391 attacks, the router examines all packets received at ingress on a 392 given interface to ensure that the source address and source 393 interface appear in the routing table and match the interface on 394 which the packet was received. There are at least 2 types of Urpf - 396 * strict - which checks that the IP address exists in the routing table 397 is reachable. 399 * loose or exist - Checks only to see if the address exists in the 400 routing table. 402 If Urpf was supported for IPv4 then it should be supported for 403 IPv6. It should be performed in hardware not software so as not too 404 negatively effect performance. 406 10. Statistics 408 Statistics gathering is important to a lot of enterprises. Data 409 captured can be used for charge back and billing purposes. Most router 410 vendors support some form of packet capture and sampling, this data is 411 then sent to a collection device for analysis. 413 Collecting statistics should not differ from Ipv4 to IPv6. IPv6 in 414 theory could need more space that IPv4 due to the size of the address, 415 eg 20 bytes versus 40 bytes, most of the analysis done on these packets 416 uses the header. 418 There are many tools out there today that collect and analyze 419 statistics gleaned from routers, most of these tools used are built 420 upon IPv4. Until these tools catch up and support IPv6 that they will 421 use IPv4 as a transport for IPv6 information. 423 11. Basic Requirements. 425 Some of the basic requirements that an IPv6 router should support could 426 be - 428 * Routing Protocols, both IGP's and EGP's * Multicast Routing * 429 Security in the form of ACL's * QOS * Management in the form of MIB's * 430 Management Tools such as Telnet, ping, traceroute etc etc * Syslog and 431 debugging tools * Network statistics gathering 433 A good tool to use for protocol compatibility is the configuration file 434 of the router. Look at each feature that you have turned on for IPv4 435 and check to see it is supported for IPv6. Obviously some of the 436 features may not be critical, in that case it should as least be on the 437 vendors roadmap 439 12. Router Memory 441 Bearing in mind that you are considering running at least one other 442 routing protocol on your routers it may be wise to ensure that you have 443 enough memory in the routers to do this. 445 At least two things need to be considered, do you have enough memory to 446 store the new software image that contains the new code and do you also 447 have enough memory to run the code. 449 As you begin to turn on features that enable IPv6 you will start to use 450 more memory, eg you may now have 2 routing tables that need to be 451 stored in memory, one for Ipv4 and one for IPv6. 453 Depending on the routers deployed you may need to upgrade memory on the 454 processors, and in a distributed system you may need to upgrade memory 455 on the linecards. 457 As noted in the hardware section, before you turn features on you 458 should know if those features are switched in hardware or software, and 459 will turning those features on effect IPv4 forwarding at all. 461 13. Management 463 The pro-active management of any network is key. Most enterprises have 464 multiple management tools in place. These tools could include things 465 that report on alerts, statistics, errors, utilization and so on. 467 Network Management tools could be supplied by the vendor or they could 468 be purchased from a third party. 470 The management of devices on the network, again should not differ. 471 Support for SNMP MIB's would be critical. Without support for this, it 472 would be extremely hard to gather any useful data from the routers. 474 Until network management software for native IPv6 is available it is 475 possible that IPv6 management and statistical information could be 476 collected from routers, but the transport for this collection would be 477 IPv4. 479 The drawback is that some vendors will not release this type of 480 functionality day one. 482 14. IPv6 Addressing 484 IPv6 addressing has some major differences relative to IPv4 and this 485 will have an effect on network engineering and management. 487 An IPv4 address is 32 bits; an IPv6 address is 128 bits. The text 488 representation of IPv6 address prefixes is similar to the way IPv4 489 addresses prefixes are written in CIDR [CIDR] notation. An IPv6 490 address prefix is represented by the notation: 492 IPv6-address/prefix-length 494 The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 495 Hexadecimal values of the eight 16-bit pieces of the address. 496 Examples: 498 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 500 1080:0:0:0:8:800:200C:417A 502 IPv6 addressing introduces the notion of an address scope. The scope 503 of the address refers to the boundaries as to where the packet can 504 travel. The packet could have a local scope only, which would mean a 505 router would not forward this packet, only nodes on this particular 506 link could see this packet. A site local scope means that the packet 507 can be routed within this network. This network typically will belong 508 to and administered by a single corporation. A global scope is an 509 address that is universally routable. 511 This memo is concerned mostly with the addressing of Routers and End 512 Stations. It is not intended to give a detailed explanation of IPv6 513 addressing, for a detailed discussion please refer to [ADDR] and 514 [RFC2373]. 516 14.1 Address Types. 518 In IPv6 addresses are assigned to interfaces not nodes. All interfaces 519 are required to have at least 1 link-local address, and in general case 520 will have multiple addresses (unlike IPv4 where a single address per 521 interface is most common). These addresses will not only be for the 522 different scopes (see below) but there is also a high likelihood of 523 multiple addresses of global scope. 525 In IPv6 there are 3 kinds of addresses - Unicast, Multicast and 526 Anycast. Unicast needs no explanation; Multicast was dealt with in an 527 earlier paragraph, which leaves anycast. An anycast address is an 528 address shared by a number of nodes (normally routers). A shared 529 anycast address is injected at different points in the routing fabric 530 by nodes providing a common service (like DNS, default route, or tunnel 531 termination). This address is syntactically no different from an IPv6 532 unicast address and it's up to the IP routing protocol to find the best 533 path. 535 There is no notion of broadcast in IPv6, the functions that normally 536 used broadcast in IPv4 to communicate now use multicast in IPv6. 538 14.2 Address schema. 540 Within the IPv6 address are 3 scopes of addresses - Link Local, Site 541 Local and Global. Link Local means only nodes on this link, similar to 542 a local subnet; routers do not forward link local packets. Site Local 543 would mean within this site or corporation. Site Local addresses are 544 routable and this is what would be used within an enterprise network. A 545 Global address is one that is routable in the Internet, eg a registered 546 address. 548 A link local address begins with a format prefix of FE80::/10 A site 549 local address begins with a format prefix of FEC0::/10 A multicast 550 address begins with a format prefix of FF00::/8 552 14.3 Address Configuration. 554 All interfaces are required to have a link local address, which can be 555 derived from the interface identifier. A link local address allows a 556 node to communicate with other nodes on the same link. This part of 557 the address accounts for the low order 64 bits and nodes may have more 558 than 1 link local address. The interface identifier is in turn 559 appended to a prefix to form a 128-bit IPv6 address. 561 Today most Ethernet MAC addresses are 48 bits, 24 bits for the company 562 ID and 24 bits for the Extension ID, they have no meaning as far as IP 563 address is concerned. Recently the IEEE changed this and expanded the 564 Extension ID to 40 bits. This provides for addresses that are 64 bits 565 long, this is called the EUI-64 [EUI64]. To make existing MAC addresses 566 compatible 16 bits are inserted between the company id and the 567 extension id, These bits are represented in hex as "FFFE" or 1111 1111 568 1111 1110 in binary. 570 The site local address is used for communication within a site; 571 normally that site would be the enterprise. 573 The global address is required for communication outside the 574 enterprise. 576 The site local and global addresses can be assigned automatically, 577 dynamically or statically. Stateless autoconfiguration applies to site 578 local and global addresses that are constructed automatically by the 579 end node. Stateless addressing normally involves a router, which 580 supplies the host with a site local and global address. This process 581 can happen two ways - 583 Hosts can request a router to supply network address information to it, 584 or the router at certain intervals will multicast this information via 585 Router Advertisements. A router could supply - 587 * One or more prefixes that are used on the link, thus enabling 588 auto-configuration * The life time of the prefix * Flags that indicate 589 the kind of auto-configuration that can be done by hosts * The default 590 router 592 Stateful addressing applies to site local and global addresses that are 593 obtained via a database, like DHCP or manually. 595 14.4 Node Addressing. 597 The points below are taken directly from 598 600 A node on an IPv6 network is required to have the following addresses 601 enabled 603 * Link-Local address for each interface * Any additional unicast and 604 anycast addresses that have been configured for the node's interfaces 605 (manually or automatically) * The loopback address * The all-nodes 606 multicast addresses * The solicited-node multicast address for each of 607 its unicast and anycast addresses * Multicast address of all other 608 groups to which the node belongs 610 14.5 Router Addressing. 612 A router is required to recognize all addresses that a host is required 613 to recognize, plus the following addresses as identifying itself: 615 * The Subnet-Router anycast addresses for all interfaces for which it 616 is configured to act as a router * All other Anycast addresses with 617 which the router has been configured * The All-Routers multicast 618 addresses 620 14.6 IPv4-compatible IPv6 address. 622 There exists an IPv6 address that is made up of the IPv4 address. The 623 first 96 bits of this address are 0's. The low order 32 bits contain 624 the IPv4 address. The format of a IPv4 compatible IPv6 address is 625 0:0:0:0:0:0:A.B.C.D The entire 128 bits is used as the IPv6 address of 626 a node, and the low order 32 bits is used as the IPv4 address of the 627 node. 629 14.7 Address Renumbering. 631 IPv6 brings a nice feature that will help when changing service 632 providers. If nodes are configured to get their site local and global 633 addresses from the router eg - stateless autoconfiguration, then those 634 advertisements that the routers use's to give the addresses can be 635 configured to advertise a new prefix. The prefix from the new service 636 provider is added to the router announcements, nodes will then use the 637 new and the old prefix on the link. Any nodes requesting addresses 638 will get the new prefix, nodes that already had a prefix will continue 639 to use the old prefix. 641 You can also configure a lifetime on the prefixes, both old and new. 642 Once the lifetime of a prefix has expired, the routers no longer 643 advertise it. Nodes will update their prefix once the one that they are 644 using has expired. 646 14.8 Privacy Extensions for Stateless Address Autoconfiguration in 647 IPv6. 649 IPv6 addresses can be formed using the interface identifier and the 650 prefix; once this address is formed it is pretty static. Even if the 651 global and site local addresses change, the interface identifier could 652 still be the same. 654 If the interface identifier were static it would be easy for someone to 655 gather information from the source, even if the global and site local 656 addresses changed. 658 [PRIVACY] talks about some extension headers that can change the 659 global-scope address over a period of time, this includes the interface 660 identifier. 662 Changing the interface identifier would make it harder for 663 eavesdroppers and information collectors to identify sources when 664 different addresses are used in different transactions that actually 665 corresponded to the same node. 667 15. ICMPv6. 669 ICMPv6 [ICMPv6] is similar to ICMPv4. It provides for diagnostics 670 (ping), problem reporting (redirects) and MTU discovery [RFC-1981]. 671 ICMP generates error messages such as destination unreachable and also 672 discovery messages like ICMP echo and reply. ICMP is also used in 673 neighbor discovery [IPv6-DIS] and the Multicast Listener Discovery 674 (MLD). 676 With IPv4 ICMP can be used to attack networks, therefore most 677 enterprises filter this protocol at a firewall. IPv6 could also be 678 used to spawn these attacks, but it does have the ability to use IPSEC 679 and create a security association between two parties. This service 680 should help decrease the possibility of a successful ICMP based 681 attack. 683 16. Path MTU Discovery. 685 The minimum link MTU in IPv4 is 68 octets; in IPv6 it is 1280 octets. 686 MTU path discovery is used to ensure that each node in the data path 687 supports the minimum MTU size. Fragmentation is handled by the end 688 nodes in IPv6 not the routers. 690 17. Neighbor Discovery [IPv6-DIS]. 692 The Neighbor Discovery is part of the ICMPv6 protocol suite. It is 693 used to 695 * Determine the link-layer address of a neighbor on the same link. * 696 Find routers * Keep track of neighbors * Uses multicast not broadcast 698 18. Multicast Listener Discovery. 700 MLD is based upon and works similar to IGMPv2. It is used by IPv6 701 routers to discover multicast listeners eg - nodes on the network that 702 Want to receive multicast from a group on that link. MLD is based upon 703 IGMPv2 messages. 705 19. Tunneling. 707 There will be a transition period, whereas enterprises will need to 708 support both IPv4 and IPv6 in their networks, and possibly will not 709 have end-to-end IPv6 connectivity, but rather IPv6 at the edges with 710 IPv4 in the core or maybe islands of IPv6 that need connecting and 711 these may need to transverse an IPv4 network at some point. This maybe 712 because of local policy, or because the Service Provider does not yet 713 provide a native IPv6 service. These IPv6 networks or nodes could be 714 connected using IPv4 as a transport; the IPv6 packet will be 715 encapsulated within an IPv4 packet. At each end of these tunnels will 716 be an IPv6 address and an IPv4 address. There are two modes of 717 tunnels, automatic and manual. 719 The type of tunnel used, automatic or manual could depend on the use of 720 the tunnel. Tunnels that are likely to be static and not change are a 721 good fit for manual configuration, whereas tunnels that are changing or 722 are temporary would be a good fit for automatic. When using automatic 723 tunnels the tunnel end points are automatically determined by using 724 IPv4 compatible IPv6 addresses. 726 Tunnels could exist between - 728 * Router-to-Router 729 * Host-to-Router 730 * Host-to-Host 731 * Router-to-Host 733 Tunneling Technologies - 735 * IPv6 Manually configured tunnel. 736 * IPv6 over IPv4 GRE tunnel. 737 * Tunnel Broker [RFC3053]. 738 * Automatic IPv4-compatible tunnel [NGTRANS] and [ADDR]. 739 * Automatic 6to4 tunnel [RFC3056]. 740 * ISATAP tunnels [ISATAP] 741 * 6over4 tunnels [RFC2529]. 743 This memo does not get into details regarding any of the possible 744 tunneling techniques see [NGTRANS] and [RFC2893]. 746 20. DNS. 748 IPv6 DNS performs the same purpose as IPv4 DNS: It maps IP addresses to 749 names and vica versa. 751 IPv6 bring a new DNS record type known as AAAA (pronounced quad A), 752 IPv4 record types are known as A, IPv6 addresses are 4 times the size 753 of IPv4 hence "AAAA". The records look like - 755 www.abc.test AAAA 2001:450:0:0:0:ce20::1 www.abc.test IN AAAA 756 2001:450:0:0:0:ce20::1 758 Nodes and Routers that support both IPv4 and IPv6 must be capable of 759 resolving both A and AAAA record types. 761 There is also another method of resolving IPv6 addresses to names, 762 which uses record types called A6. This method defines changes to the 763 Domain Name System to support renumberable and aggregatable IPv6 764 addressing. The idea here is to make it easier for Enterprises and 765 Service Providers to change DNS entries quickly and efficiently. The 766 idea is that the prefix of the IPv6 network address will be maintained 767 by the Service Providers DNS server. Therefore any change on the 768 enterprise's part requires only a change to the DNS prefix entry. 770 21. Operational Requirements. 772 If IPv6 is going to put into a production network then people will need 773 to know - 775 * The changes in the addressing schema * The automation of the 776 addressing * The scope of the addressing * The new protocols that 777 enable automatic addressing, address 778 resolution, error reporting and mtu discovery 779 * How to configure it * How to manage it * How to Troubleshoot it 781 The above points indicate that this could be achieved either by a CLI 782 or by a management interface. It would depend on the individuals and 783 possibly company policy as to which was used. Also if an existing 784 router was being used then the learning curve would probably just 785 entail some new commands, if however a new router was purchased it 786 could mean the need to learn a whole new command set. 788 The commands most commonly used on a router are - 790 * Commands that control how the router functions, they either add 791 or take away functionality. 793 * Commands that glean information from the router, eg - shows the 794 contents of the routing tables. 796 * Commands that help investigate a problem or abnormality, eg - 797 pings, debugging or traceroute. 799 All routers come with a set of manuals, these manuals are either on 800 soft copy, a CD or hard copy. These manuals should be updated and 801 carry the command set used for IPv6. Following a logical path the 802 command set available for IPv6 should really be no different than the 803 command set for IPv4, all except for the features that are new in 804 IPv6. 806 It would seem that to enable basic IPv6 functionality on a router you 807 would turn on IPv6 routing globally on the router and then on each 808 interface that you required IPv6 routing you would need an address 809 configured. The next step would be to enable a routing protocol and 810 provide this protocol some address information. 812 This is very similar as to what is required for basic IPv4 routing 813 today, the extra work needed for IPv6 could be just a few extra 814 characters. 816 22. Lab Requirements. 818 One of the main goals of the lab will be not only to test hardware and 819 software but it could also be used to train operations staff. These 820 people are the ones responsible for the day-to-day running of the 821 network, and because you are introducing a new protocol, then training 822 these people should be a top priority. 824 A lab should be built to resemble the live network, this way if the 825 test scripts are well written and the results recorded accurately and 826 analyzed accordingly, then when putting IPv6 into a live network it 827 should not produce any big surprises. 829 Note that along with testing the newer IPv6 applications and networking 830 you should alongside this also have the regular IPv4 applications 831 running, that way you can ensure that one does not effect the other. 832 What could a lab contain - 834 * The exact hardware used in the live network * The exact interfaces 835 used in the live network * The software that is expected to be used on 836 the production routers * Production applications * Testing Equipment * 837 A repository for configurations and screen dumps 839 Every enterprise's test plan will be very different and will depend on 840 there own requirements. Some will be concerned about functionalities, 841 some performance and others interoperability. It would be unwise to 842 try to cover all points that would be deemed important here. 844 The points listed below focus on basic operation of the protocol and 845 not performance or interoperability, as those would be very specialized 846 to the particular environment. The points below are also very 847 generic. 849 A test plan could include - 851 * Once the network is setup and stable, copy all of the configurations 852 of the routers to a tftp server. These will be useful to use as a 853 baseline. 855 * Throughout the testing use the CLI to collect information that will 856 be useful to operations staff, the idea here is to familiarize people 857 as to what the routing tables, ARP tables, traceroutes, debugs and so 858 on look like. It would also be useful to save these screen dumps to a 859 hard drive. 861 * Connectivity Testing - once the lab is setup, a routing protocol 862 chosen and the appropriate configuration applied, the next logical step 863 would be to test connectivity, eg is the routing protocol working as 864 expected. Not only should the routes be formed correctly but also 865 updates should take place at regular intervals. 867 * Convergence - When the network is stable and predictable fail a link 868 and watch the routing protocols converge. Did it work as expected? 869 Again capture screen dumps before and after. 871 * Test management tools such as pings, traceroutes and debugs. 873 * Multicast testing if appropriate. 875 * Testing of the appropriate applications. 877 The results and usefulness of those results will only be as good as the 878 test plan and data recorded. 880 If in the lab something does not work as expected or advertised then 881 further analyses is required. All too often important events are 882 overlooked or put down to a glitch. You can bet that if this glitch 883 did effect the operation of the network in the lab, that when you go 884 live, it will at some point come back to bite you. 886 23. REFERENCES 888 Normative References 890 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 891 6, (IPv6) Specification", RFC 2460, December 1998. 893 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless 894 Inter- 895 Domain Routing (CIDR): An Address Assignment and 896 Aggregation Strategy", RFC1519, September 1993. 898 [RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU 899 Discovery for IP version 6", RFC 1981, August 1996. 901 [RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing 902 Architecture", RFC 2373, July 1998. 904 [RFC-2893] R. Gilligan and E. Nordmark, "Transition Mechanisms for 905 IPv6 Hosts 906 and Routers", RFC2893, August 2000 908 [RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 909 Domains without Explicit Tunnels", RFC2529, March 1999. 911 [RFC-2874] M. Crawford, C. Huitema, DNS Extensions to Support IPv6 912 Address 913 Aggregation and Renumbering, RFC2874, July 2000 915 [RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento, 916 "IPv6 Tunnel Broker", RFC3053, February 2001 918 [RFC3056] B. Carpenter, K Moore, 919 "Connection of IPv6 Domains via IPv4 Clouds", RFC3056, 920 February 2001 922 [ICMPv6] Conta, A. and S. Deering, "Internet Control Message 923 Protocol (ICMPv6) for the Internet Protocol Version 6 924 (IPv6) Specification", RFC 2463, December 1998. 926 [IPv6-DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 927 Discovery for IP Version 6 (IPv6)", RFC 2461, December 928 1998. 930 [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address 931 Autoconfiguration", RFC 2462, December 1998. 933 [ADDR] Hinden, R and S. Deering 934 "" 935 November 20th 2001. 937 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 938 Registration Authority", 939 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 940 March 1997. 942 [PRIVACY] Narten, T., R. Draves, "Privacy Extensions for Stateless 943 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 945 [NGTRANS] W. Biemolt M. Kaat, T. Larder, H. Steenman, R. van der Pol, 946 G. Tsirtsis, A Durand, K. Yamamoto, Y. Sekiya, D. Finkerson, 947 A. Hazeltine. An overview of the introduction of IPv6 in the 948 Internet 949 951 [ISATAP] F. Templin, T Gleeson, M. Talwar, D. Thaler 952 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 953