idnits 2.17.1 draft-ietf-ipngwg-ipv6-anycast-analysis-02.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: ---------------------------------------------------------------------------- ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Hinden,1998]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 28, 2003) is 7606 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 section? 'Hinden' on line 70 looks like a reference -- Missing reference section? '1998' on line 70 looks like a reference -- Missing reference section? 'Partridge' on line 84 looks like a reference -- Missing reference section? '1993' on line 84 looks like a reference -- Missing reference section? 'Hardie' on line 94 looks like a reference -- Missing reference section? '2002' on line 453 looks like a reference -- Missing reference section? 'Haberman' on line 330 looks like a reference -- Missing reference section? 'Elz' on line 406 looks like a reference -- Missing reference section? '1997' on line 406 looks like a reference -- Missing reference section? 'Sollins' on line 411 looks like a reference -- Missing reference section? '1992' on line 411 looks like a reference -- Missing reference section? 'Crawford' on line 453 looks like a reference -- Missing reference section? 'Stewart' on line 457 looks like a reference -- Missing reference section? '2000' on line 457 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jun-ichiro itojun Hagino 3 INTERNET-DRAFT IIJ Research Laboratory 4 Expires: December 28, 2003 K. Ettikan 5 Intel ASG, Malaysia 6 June 28, 2003 8 An analysis of IPv6 anycast 9 draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as ``work in progress.'' 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 The internet-draft will expire in 6 months. The date of expiration will 31 be December 28, 2003. 33 Abstract 35 The memo tries to identify the problems and issues in the use of IPv6 36 anycast [Hinden, 1998] defined as of today. The goals of the draft are 38 (1) to understand the currently-defined IPv6 anycast better, 40 (2) to provide guidelines for people trying to deploy anycast services, 41 and 43 (3) to suggest updates to IPv6 anycast protocol specification. 45 The document was made possible by input from ipngwg DNS discovery design 46 team. 48 1. IPv6 anycast 50 "Anycast" is a communication model for IP, just like unicast and 51 multicast are. 53 Anycast can be understood best by comparing with unicast and multicast. 54 IP unicast allows a source node to transmit IP datagrams to a single 55 destination node. The destination node is identified by a unicast 56 address. IP multicast allows a source node to transmit IP datagrams to 57 a group of destination nodes. The destination nodes are identfied by a 58 multicast group, and we use a multicast address to identify the 59 multicast group. 61 IP anycast allows a source node to transmit IP datagrams to a single 62 destination node, out of a group of destination nodes. IP datagrams 63 will reach the closest destination node in the set of destination nodes, 64 based on the routing measure of distance. The source node does not need 65 to care about how to pick the closest destination node, as the routing 66 system will figure it out (in other words, the source node has no 67 control over the selection). The set of destination nodes is identified 68 by an anycast address. 70 Anycast was adopted by IPv6 specification suite. RFC2373 [Hinden, 1998] 71 defines the IPv6 anycast address, and its constraints in the usage. The 72 following sections try to analyze RFC2373 rules, and understand 73 limitations with them. At the end of the draft we compile a couple of 74 suggestions to exisitng proposals, for extending the usage of the IPv6 75 anycast. 77 2. Existing practices 79 There are multiple examples of anycast in IPv4. The section tries to 80 summarize those practices. 82 2.1. RFC1546 anycast 84 RFC1546 [Partridge, 1993] defines an experimental anycast service for 85 IPv4. With RFC1546, anycast address is distinguishable from unicast 86 address (unlike RFC2373 anycast), as they are allocated from separate 87 range. The authors have no knowledge whether RFC1546 anycast is widely 88 practiced or not; our bet is that it is not. 90 2.2. Shared-unicast address: multiple hosts with single unicast address 92 There are existing practices of using a single unicast address at 93 multiple different locations, for load balancing purposes, for DNS 94 servers and web servers (1992 Olympic games) [Hardie, 2002] . We call 95 the technique "shared-unicast address" for clarity in this document. 96 The shared-unicast address technique works as follows: 98 o A provider-independent IPv4 address prefix is allocated from an RIR. 100 o The address prefix is configured at multiple distant locations on the 101 Internet. 103 o A host route, or a route that covers the address prefix is advertised 104 from all of the locations. 106 o Clients will reach the nearest location based on the routing table 107 setup. 109 Shared-anycast address technique must not be confused with the one we 110 discuss in the document (RFC2373 anycast), as the problem domain is 111 different. 113 Shared-unicast address technique tries to replicate unicast servers. 114 The distribution of servers is worldwide. Shared-unicast address is 115 being used for specific upper-layer protocols only, like DNS and HTTP. 116 There is no consideration given for the cases when a client contacts 117 multiple servers by chance (transport layer protocol will get confused), 118 since it is unlikely to see routing table changes during the short 119 lifetime of the upper-layer protocols being used. 121 RFC2373 anycast is defined in more generic manner, and does not limit 122 the routing infrastructure nor upper-layer protocol. Therefore, RFC2373 123 imposes certain limitation to the packet header contents (like IPv6 124 source address), to prevent confusions due to routing changes during the 125 lifetime of a transport-layer connection. 127 This document tries to analyze RFC2373 anycast to understand if we can 128 use it for site-scoped server replication, upper-layer protocols other 129 than DNS or HTTP, and such. Still, it is possible to apply shared- 130 unicast address technique to IPv6. Issues with shared-unicast address 131 on IPv6 are outside of the scope of the document. 133 2.3. Route scaling issues 135 The use of anycast addresses has route scalaing issues. If anycast 136 addresses are drawn from the unicast address space (as is the case in 137 RFC2373 anycast and the shared-unicast address used for anycast DNS 138 servers) the routing scaling impact can potentially be limited by 139 aggregating the anycast addresses as part of the regular unicast routing 140 prefixes. But this aggregation can only be applied when all members in 141 the anycast group remaing within the piece of toplogy whose routes get 142 aggregated. For instance having an anycast address where all the 143 members belong to one ISP means it the anycast address can be drawn from 144 the ISPs address space and be aggregated at the ISP boundary with no 145 effect on route scaling outside that domain. But having e.g. anycast 146 groups with members across the whole Internet will have effect on the 147 size of the routing tables globally. 149 3. Limitations/properties of RFC2373 anycast 151 The section tries to list limitations and properties of RFC2373 anycast. 152 Some of the properties listed herein applies to IPv4/v6 shared-unicast 153 address technique as well. 155 3.1. Identifying anycast destination 157 For anycast addresses, RFC2373 uses the same address format as unicast 158 addresses. Therefore, without other specific configurations, a sender 159 usually cannot identify if the sender is sending a packet to anycast 160 destination, or unicast destination. This is different from RFC1546 161 IPv4 anycast, where anycast address is distinguishable from unicast 162 addresses. 164 This item applies to shared-unicast address technique as well. 166 3.2. Nondeterministic packet delivery 168 If multiple packets carry an anycast address in IPv6 destination address 169 header, these packets may not reach the same destination node, depending 170 on stability of the routing table. This property leads to a couple of 171 interesting symptoms. 173 If we can assume that the routing table is stable enough during a 174 protocol exchanges, multiple packets (with anycast address in 175 destination address field) will reach the same destination node just 176 fine. However, there is no such guarantee. 178 If routing table is not stable enough or you would like to take a more 179 strict approach, a client can only send one packet with anycast address 180 in the destination address field. For example, consider the following 181 packet exchange. The following exchange can lead us to failure, as we 182 are not sure if the 1st and 2nd anycast packet have reached the same 183 destination. 185 query: client unicast (Cu) -> server anycast (Sa) 186 reply: server unicast (Su) -> client unicast (Cu) 187 query: client unicast (Cu) -> server anycast (Sa) 188 It may reach a different server! 189 reply: server unicast (Su) -> client unicast (Cu) 191 Because of the non-determinism, if we take a strict approach, we can use 192 no more than 1 packet with anycast destination address, in a set of 193 protocol exchange. If we use more than 2 packets, 1st and 2nd packet 194 may reach different server and may cause unexpected results. If the 195 protocol is completely stateless, and we can consider the first 196 roundtrip and second roundtrip separate, it is okay. For stateful 197 protocols, it is suggested to use anycast for the first packet in the 198 exchange, to discover unicast address of the (nearest) server. After we 199 have discovered the unicast address of the server, we should use the 200 server's unicast address for the protocol exchange (note that there is 201 some security implication here - see Security Consideration section). 203 Also because of non-determinism, if we are to assign an IPv6 anycast 204 address to servers, those servers must provide uniform services. For 205 example, if server A and server B provide different services, and people 206 wants to differentiate between A and B, we cannot use single IPv6 207 anycast address to identify both A and B. 209 Note that, this is not a bad feature of anycast; this property lets us 210 use anycast addresses for load balancing. Also, packets will 211 automatically be delivered to the nearest node with anycast address 212 assigned. Anaycast will ease service locating problem by pusing the 213 task to network layer rather than handled by upper layers. 215 Here are situations where multiple packets with anycast destination 216 address can lead us to problems: 218 o Fragmented IPv6 packets. Fragments may reach multiple different 219 destinations, and will prevent reassembly. 221 Because the sending node cannot differentiate between anycast addresses 222 and unicast addresses, it is hard for the sending node to control the 223 use of fragmentation. 225 This item applies to shared-unicast address technique as well. 227 3.3. Anycast address assignment to hosts 229 RFC2373 suggests to assign anycast addresses to a node, only when the 230 node is a router. This is because there was no standard way for hosts 231 to announce their intention to accept packets toward anycast addresses. 232 If no hosts have anycast address on them, it is easier for us to route 233 an IP datagram to anycast destination. We just need to follow existing 234 routing entries, and we will eventually hit a router that has the 235 anycast address. If we follow RFC2373 restriction strictly, we could 236 only assign anycast addresses onto routers. 238 However, note that there is no inherent difference between IPv4 and IPv6 239 with respect to the use of anycast address on hosts; we can certainly 240 run shared-unicast address technique with IPv6, with certain 241 limitation/caveats as described previously. 243 3.4. Anycast address in source address 245 Under RFC2373, IPv6 anycast address can not be put into IPv6 source 246 address. This is basically because an IPv6 anycast address does not 247 identify a single source node. 249 o Incorrect reassembly of fragmented packets due to multiple anycast 250 members sending packets with the same fragment ID to the same 251 destination at about the same time; the same the source IP address, 252 destination IP address, nextheader, and fragment ID numbers might be 253 accidentally used at the same time by different senders. 255 o Errors and other response packets might be delivered to a different 256 anycast member than sent the packet. This might be very likely since 257 asymmetric routing is rather prevalent on the Internet. 259 Particular cases of such errors that are known to cause protocol 260 problems are (1) ICMP packet too big making path MTU discovery 261 impossible. (2) (could be more) The misdelivery of other errors might 262 cause operational problems - making the network harder to trouble- 263 shoot when anycast source addresses are used. 265 The above items apply to shared-unicast address technique as well. In 266 the actual shared-unicast IPv4 operation, path MTU discovery is avoided 267 by setting DF bit to 0 for the packets from servers that share the 268 shared-unicast address (it is not possible to do the same thing for 269 IPv6, however, as DF bit is no longer present). 271 3.5. IPsec 273 IPsec and IKE identify nodes by using source/destination address pairs. 274 Due to the combination of issues presented above, it is difficult to use 275 IPsec on packets with anycast address in source address, destination 276 address, or both. 278 Even with manual keying, IPsec trust model with anycast address is 279 confusing. As IPsec uses IPv6 destination address to identify which 280 IPsec key to be used, we need to use the same IPsec key for all of the 281 anycast destinations that share an anycast address. 283 IPsec protocol has replay protection mechanism. If IPsec is used with 284 an anycast address, it will not work well as replay counter will not be 285 updated consistently due to the anycast packet delivery. 287 Dynamic IPsec key exchange (like IKE) is almost impossible. First of 288 all, to run IKE session between two nodes, the two nodes need to be able 289 to communicate with each other stably. With nondeterministic packet 290 delivery provided by anycast, it is not quite easy. Even if we could 291 circumvent the issue with IKE, we have exactly the same problem as 292 manual keying case for actual communication. 294 This item applies to shared-unicast address technique as well. 296 4. Possible improvements and protocol changes 298 4.1. Assigning anycast address to hosts (non-router nodes) 300 Under RFC2373 rule, we can only assign anycast addresses to routers, not 301 to hosts. The restriction was put into the RFC because it was felt 302 insecure to permit hosts to inject host routes to anycast address. 304 If we try to ease the restriction and assign anycast addresses to IPv6 305 hosts (non-routers), we would need to inject host routes for the anycast 306 addresses, with prefix length set to /128, into the IPv6 routing system. 307 We will inject host routes from each of the nodes with anycast 308 addresses, to make packets routed to a topologically-closest node. Or, 309 we may be able to inject host routes from routers adjacent to the 310 servers (not from the servers themselvers). 312 Here are possible ways to allow anycast addresses to be assigned to 313 hosts. We would need to diagnose each of the following proposals 314 carefully, as they have different pros and cons. The most serious issue 315 would be the security issue with service blackhole attack (malicious 316 party can blackhole packets toward anycast addresses, by making false 317 advertisement). 319 o Let the host with anycast address to participate into routing 320 information exchange. The host does not need to fully participate; it 321 only needs to announce the anycast address to the routing system. To 322 secure routing exchange, administrators need to configure secret 323 information that protects the routing exchange to the host, as well as 324 other routers. 326 o Develop a protocol for a router, to discover hosts with anycast 327 address on the same link. The router will then advertise the anycast 328 address to the routing system. This could be done by an extension to 329 IPv6 Neighbor Discovery or an extension to IPv6 Multicast Listener 330 Discovery [Haberman, 2002] . 332 As described in section 2.3, the impact of host routes depends on the 333 scope of the anycast address usage. If we deploy nodes with an RFC2373 334 anycast address worldwide, host route for RFC2373 anycast would impact 335 the global routing table. If we deploy nodes with an RFC2373 anycast 336 address in a single aggregatable address domain (such as a /48 site), 337 host route will impact the aggregatable address domain only. 339 4.2. Anycast address in destination address 341 By using anycast in IPv6 layer, upper-layer protocols may be able to 342 enjoy redundancy and higher availability of servers. However, for 343 stateful upper-layer protocols, a client may need to specify a single 344 node out of nodes that share an anycast address. Suppose a client C 345 would like to communicate a specific server with anycast address, Si. 346 Si shares the same anycast address with other servers, S1 to Sn. It is 347 hard for C to selectively communicate with Si. 349 One possible workaround is to use IPv6 routing header. By specifying a 350 unicast address of Si as an intermediate hop, C can deliver the packet 351 to Si, not to other Sn. 353 Note that, however, by specifying Si explicitly, C now have lost the 354 server redundancy provided by the use of anycast address in IPv6 layer. 355 If Si goes down, the communication between C and Si will be lost. C 356 cannot enjoy the failure resistance provided by redundant servers, S1 to 357 Sn. Protocol designers should carefully diagnose if any state is 358 managed by C and/or Si, and decide how the protocol should take 359 advantage of anycast addresses and their characteristics. 361 4.3. Anycast address in source address 363 Under RFC2373 rule, anycast address cannot be put into source address. 364 Here is a possible workaround, however, it did not win a consensus in 365 the past ipngwg meetings: 367 o When we try to use anycast address in the source address, use a (non- 368 anycast) unicast address as the IPv6 source address, and attach home 369 address option with anycast address. In ipngwg discussions, however, 370 there seem to be a consensus that the home address option should have 371 the same semantics as the source address in the IPv6 header, so we 372 cannot put anycast address into the home address option. 374 5. Upper layer protocol issues 376 5.1. Use of UDP with anycast 378 Many of the UDP-based protocols use source and destination address pair 379 to identify the traffic. One example would be DNS over UDP; most of the 380 DNS client implementation checks if the source address of the reply is 381 the same as the destination address of the query, in the fear of the 382 fabricated reply from a bad guy. 384 query: client unicast (Cu) -> server unicast (Su*) 385 reply: server unicast (Su*) -> client unicast (Cu) 387 addresses marked with (*) must be equal. 389 If we use server's anycast address as the destination of the query, we 390 cannot meet the requirement due to RFC2373 restriction (anycast address 391 cannot be used as the source address of packets). Effectively, client 392 will consider the reply is fabricated (hijack attempt), and drops the 393 packet. 395 query: client unicast (Cu) -> server anycast (Sa) 396 reply: server unicast (Su) -> client unicast (Cu) 398 Note that, however, bad guys can still inject fabricated results to the 399 client, even if the client checks the source address of the reply. The 400 check does not improve security of the exchange at all. 402 If we check the existing protocol descriptions, in many cases, it is not 403 possible to perform sanity checks against IP source address for UDP 404 exchanges. Either they are not specified on the protocol documents, or 405 it is an implementation mistake to check the IP source address. For 406 example, from RFC2181 [Elz, 1997] section 4.1, the source address of 407 response could be different from the destination address of the query if 408 the destination address of the query is an anycast address. Therefore, 409 we cannot check IP source address matches for UDP DNS packets. There is 410 no wording available on the selection of source address, in TFTP 411 protocol specification [Sollins, 1992] . 413 So, regarding to this issue, we conclude as follows: 415 o There is an issue with the use of anycast addresses with UDP traffic 416 due to the prohibitation against using anycast as a source address. 417 New application protocols which use UDP and want to take advantage of 418 anycast should take this into account by not identifying the response 419 based on the source IP address, without compromising any security that 420 might be present from verifying that the source IP address of the 421 response is the same as the destination address in the request. 423 o If you need to secure UDP protocol exchange, it is suggested to verify 424 the authenticity of the reply, by using upper-layer security 425 mechanisms like DNSSEC (note that we cannot use IPsec with anycast). 427 o Existing UDP-based protocols that perform IP address verification 428 between requests and responses, such as DNS lookups, are more 429 problematic. If the transaction is covered by higher-layer security 430 mechanisms it makes sense exploring protocol modifications in IETF 431 working groups to relax or remove the the IP address checks. In other 432 cases it makes sense to explore whether the IP address checks provide 433 any real security in the appropriate IETF working groups. 435 5.2. Use of TCP with anycast 437 We cannot simply use anycast for TCP exchanges, as we identify a TCP 438 connection by using address/port pair for the source/destination node. 439 It is desired to implement some of the following, to enable the use of 440 IPv6 anycast in TCP. Note, however, security requirement is rather 441 complicated for the following protocol modifications. In particular, we 442 are unsure about the relationship between the anycast address we contact 443 first, and the unicast address we subsequently contact. 445 o Define a TCP option which lets us to switch peer's address from IPv6 446 anycast address, to IPv6 unicast address. There have been a couple of 447 proposals in the past. 449 o Define an additional connection setup protocol that resolves IPv6 450 unicast address from IPv6 anycast address. We first resolve IPv6 451 unicast address using the new protocol, and then, make a TCP 452 connection using the IPv6 unicast address. IPv6 node information 453 query/reply [Crawford, 2002] could be used for this. 455 5.3. Use of SCTP with Anycast 457 SCTP [Stewart, 2000] is a bit more interesting. An SCTP endpoint is 458 defined as: 460 The logical sender/receiver of SCTP packets. 461 On a multi-homed host, an SCTP endpoint is represented to its 462 peers as a combination of a set of eligible destination transport 463 addresses to which SCTP packets can be sent and a set of eligible 464 source transport addresses from which SCTP packets can be received. 465 All transport addresses used by an SCTP endpoint must use the same 466 port number, but can use multiple IP addresses. 468 Therefore, it is legal to send packets to a unicast address of an SCTP 469 peer endpoint, as long as the SCTP peer endpoint replies using a unicast 470 address which is part of the association. 472 In summary, anycast should work with SCTP, as long as the SCTP endpoint 473 contains a valid unicast address. 475 6. Summary 477 The draft tried to diagnose the limitation in currently-specified IPv6 478 anycast, and explored couple of ways to extend its use. Some of the 479 proposed changes affects IPv6 anycast in general, some are useful in 480 certain use of IPv6 anycast. To take advantage of anycast addresses, 481 protocol designers would need to diagnose their requirements to anycast 482 address, and introduce some of the tricks described in the draft. 484 Use of IPsec with anycast address still needs a great amount of 485 analysis. 487 7. Security consideration 489 The document should introduce no new security issues. 491 When we use an anycast address to discover a server and then switch to 492 unicast adddress for the server, upper-layer protocols need to make sure 493 that the two addresses actually belong to the same node. Otherwise, 494 there could be a chance for malicious nodes to hijack the communciation. 495 One possible way to achieve this is to use public-key based 496 authentication in the upper-layer protocol. 498 For secure anycast operation, we may need to enable security mechanisms 499 in other protocols. For example, if we were to inject /128 routes from 500 end hosts by using a routing protocol, we may need to configure the 501 routing protocol to exchange routes securely, to prevent malicious 502 parties from injecting bogus routes. 504 References 506 Hinden, 1998. 507 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 508 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 510 Partridge, 1993. 511 C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting Service" in 512 RFC1546 (November 1993). ftp://ftp.isi.edu/in-notes/rfc1546.txt. 514 Hardie, 2002. 515 T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast 516 Addresses" in RFC3258 (April 2002). ftp://ftp.isi.edu/in- 517 notes/rfc3258.txt. 519 Haberman, 2002. 520 B. Haberman and D. Thaler, "Host-based Anycast using MLD" in draft- 521 haberman-ipngwg-host-anycast-01.txt (May 2002). work in progress 522 material. 524 Elz, 1997. 525 R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181 526 (July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt. 528 Sollins, 1992. 529 K. Sollins, "The TFTP Protocol (Revision 2)" in RFC1350 (July 1992). 530 ftp://ftp.isi.edu/in-notes/rfc1350.txt. 532 Crawford, 2002. 533 Matt Crawford, "IPv6 Node Information Queries" in draft-ietf-ipngwg- 534 icmp-name-lookups-09.txt (May 2002). work in progress material. 536 Stewart, 2000. 537 R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, 538 I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream Control 539 Transmission Protocol" in RFC2960 (October 2000). ftp://ftp.isi.edu/in- 540 notes/rfc2960.txt. 542 Change history 544 individual submission, 00 -> 01 545 Improve security considerations section. Remove an invalid use of 546 home address option from UDP section. Improve wording on IPsec. 548 individual submission, 01 -> 02 549 Split sections for current status analysis, and future protocol 550 design suggestions. 552 02 -> 00 553 Distinguish RFC2373 anycast and BGP anycast. Ettikan's new 554 address. 556 00 -> 01 557 Reflect IESG comments. BGP anycast is now called "pseudo anycast" 558 for clarity. SCTP section contributed by John Loughney. 560 01 -> 02 561 Typo and grammar fixes from Richard Dawe. Many comments from Erik 562 Nordmark, including: (1) use "shared-unicast address" isntead of 563 "pseudo anycast", (2) remove mention of BGP as RFC3258 is not 564 specifically tied to BGP, and (3) clarify the impact of host route 565 injection. IIJ office have moved. Some additional notes wrt 566 difference between shared-unicast approach. 568 Authors' addresses 570 Jun-ichiro itojun Hagino 571 Research Laboratory, Internet Initiative Japan Inc. 572 Jinbocho Mitsui Buildling, 1-105, 573 Kanda-Jinbocho, Chiyoda-ku, Tokyo 101-0051 JAPAN 574 Tel: +81-3-5205-6464 575 Fax: +81-3-5205-6465 576 E-mail: itojun@iijlab.net 578 Ettikan Kandasamy Karupiah 579 ASG Penang & Shannon Operations, 580 Intel Microelectronis (M) Sdn. Bhd., 581 Bayan Lepas Free Trade Zone III, 582 Penang, Malaysia. 583 Tel: +60-4-859-2591 584 Fax: +60-4-859-7899 585 Email: ettikan.kandasamy.karuppiah@intel.com