idnits 2.17.1 draft-wing-behave-learn-prefix-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 26, 2009) is 5290 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 (-02) exists of draft-huang-behave-rfc2767bis-00 == Outdated reference: A later version (-02) exists of draft-huang-behave-rfc3338bis-00 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-01 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-03 == Outdated reference: A later version (-06) exists of draft-savolainen-mif-dns-server-selection-01 == Outdated reference: A later version (-04) exists of draft-thomson-geopriv-res-gw-lis-discovery-02 == Outdated reference: A later version (-02) exists of draft-venaas-behave-mcast46-01 == Outdated reference: A later version (-03) exists of draft-venaas-behave-v4v6mc-framework-00 == Outdated reference: A later version (-02) exists of draft-wing-behave-http-ip-address-literals-00 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Standards Track October 26, 2009 5 Expires: April 29, 2010 7 Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator 8 draft-wing-behave-learn-prefix-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 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 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 29, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Some IPv6 applications obtain IPv4 address literals and want to 47 communicate with those IPv4 hosts through an IPv6/IPv4 translator. 48 The IPv6 application can send an IPv6 packet through the translator 49 if it knows the IPv6 prefix of the IPv6/IPv4 translator. In many 50 IPv6/IPv4 translation deployments, that IPv6 prefix is not fixed; 51 rather, the prefix is chosen by the network operator. This 52 specification provides three methods for a host to learn the IPv6 53 prefix of its IPv6/IPv4 translator. Unicast, any-source multicast 54 (ASM), and source-specific multicast (SSM) are supported. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Discussion on Mechanisms . . . . . . . . . . . . . . . . . . . 4 61 4. Mechanisms to Learn the Translator's IPv6 Prefix and Length . 5 62 4.1. Using DNS . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Using DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Authenticating the Learned Prefix . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Appendix A. For future study . . . . . . . . . . . . . . . . . . 11 72 A.1. multi-homed hosts . . . . . . . . . . . . . . . . . . . . 11 73 A.2. Unicast and multicast translators . . . . . . . . . . . . 11 74 Appendix B. IPv4 Address Literals on the Internet . . . . . . . . 11 75 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 12 76 C.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 12 77 C.2. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 12 78 C.3. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 12 79 C.4. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 12 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 AFT: Address Family Translator. A device that translates between IP 89 address families. 91 DNS64: The function of synthesizing an AAAA record from an A record 92 (also called "DNS rewriting" or "DNS-ALG"), described in 93 [I-D.ietf-behave-dns64]. 95 NSP (Network-Specific Prefix): A prefix assigned to an IPv6/IPv4 96 translator that uses a prefix belonging to the network operator. 98 2. Introduction 100 Certain applications, operating in certain translation scenarios, can 101 benefit from knowing the IPv6 prefix of their IPv6/IPv4 translator. 102 First, the host must be operating in an IPv6-initiated scenario with 103 a local translator. The Framework document 104 [I-D.ietf-behave-v6v4-framework] describes these as Scenario 1, "IPv6 105 network to IPv4 Internet", and Scenario 5, "An IPv6 network to an 106 IPv4 network". Learning the prefix is useful for both stateful 107 translation and stateless translation. 109 With those scenarios, the IPv6 host usually performs a DNS AAAA query 110 which is processed by a DNS64 server. The DNS64 server generates a 111 synthetic AAAA response, when necessary. This synthetic AAAA 112 response contains the prefix of the IPv6/IPv4 translator. When the 113 IPv6 host sends a packet to that address returned in the AAAA 114 response, the packet is routed to the translator which translates it 115 to IPv4. This functionality is transparent to the IPv6 host, for the 116 most part. 118 However, an IPv6 application can also obtain an IPv4 address literal 119 and wants to communicate with that IPv4 address. So far, several 120 scenarios have been identified where this occurs: 122 o host-based DNSSEC validation (Section 6 of 123 [I-D.ietf-behave-dns64]) 125 o BitTorrent (Section 2.2 of [I-D.wing-behave-nat64-referrals]) 127 o multicast translation ([I-D.venaas-behave-v4v6mc-framework] and 128 Section 4 of [I-D.venaas-behave-mcast46]) 130 o URI schemes with host IPv4 address literals rather than domain 131 names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, 132 ipp://192.0.2.1)). See also 133 [I-D.wing-behave-http-ip-address-literals] which describes a 134 different workaround than the solution described in this document. 136 o update the host's RFC3484 preference table to prefer translated 137 prefixes below native prefixes. 139 o allow the host to perform its own DNS64 function. This allows the 140 host to provide translation functions to IPv4 applications using, 141 for example, BIS [I-D.huang-behave-rfc2767bis] or BIA 142 [I-D.huang-behave-rfc3338bis]. 144 When an IPv6/IPv4 translator is used with a Network-Specific Prefix 145 (NSP), it is necessary for such applications to learn the IPv6 prefix 146 (and length) of the translator so that the application can create an 147 IPv6 packet that will be routed to the translator and be translated 148 to IPv4. 150 Issue-1: Even when the Well-Known Prefix (WKP) is used, it may be 151 useful for the host and/or the applications to know there is, in 152 fact, a translator operating on the network. The mechanisms 153 described in this draft could provide such an indication to the 154 host and its applications. The need for learning the prefix with 155 WKP is for future study. 157 3. Discussion on Mechanisms 159 Both DNS and DHCP are described in this document. It would be 160 desirable to use DHCPv6, as it is intended to configure network 161 settings such as the network's IPv6/IPv4 translator. However, there 162 is not ubiquitous support of DHCPv6. 164 DNS: 166 * available to all OSs and applications, without regard for OS 167 support or network device support. 169 DHCPv6: 171 * requires DHCPv6 support in host operating system and network. 172 Apple's OSX does not support DHCPv6. 174 * requires OS provide API for application to query the new DHCP 175 option described in this document. Microsoft's Windows Vista 176 provides such an API. Support in other OSs is unknown. 178 Issue-2: Should we pick DNS over DHCPv6? 180 4. Mechanisms to Learn the Translator's IPv6 Prefix and Length 182 Both the IPv6 prefix of the translator and the prefix length of the 183 translator need to be learned. With that information, the 184 application can generate an appropriate IPv6 address that will be 185 routed to the translator for the translator to process. 187 The host can learn the necessary information using DNS or DHCP as 188 described in the following sections. 190 Issue-3: If a conflict exists between DNS or DHCP which should 191 take precedence? 193 4.1. Using DNS 195 Issue-4: Should we just use a TXT record, perhaps like 196 "_TRANSLATE64", "_ASMTRANSLATE64", and "_SSMTRANSLATE64", instead 197 of using NAPTR? A simple TXT record would ensure immediate 198 ubiquitous support across all OSs and all DNS management systems. 200 This specification defines a new U-NAPTR [RFC4848] application to 201 discover the translator's IPv6 prefix and length. The input domain 202 name is the exact same as would be used for a reverse DNS lookup, 203 derived from the host's IPv6 in the ".ip6.arpa." tree and follows the 204 construction rules in Section 2.5 of [RFC3596]. This is shortened to 205 20 labels (representing a /64 network prefix) and, if DNS returns an 206 error is shortened to 16 labels (representing a /48 network prefix). 208 If an IPv6/IPv4 translator is present on the network, the successful 209 result of one of those queries will produce a NAPTR record with the 210 desired service tag "TRANSLATE64:" which contains the unicast IPv6 211 prefix and prefix length of the translator, separated by a "/" (the 212 same syntax as specified in Section 2.3 of [RFC4291]). The service 213 tags "ASMTRANSLATE64:" and "SSMTRANSLATE:" are used for ASM and SSM. 215 For example, a host with the IP address 2001:db8:1:2:3:4:567:89ab 216 would first send an NAPTR query for 217 3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements, 218 representing a /64 network prefix). If that fails (returns 219 NXDOMAIN), it would send an NAPTR query for 220 2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (16 elements, representing a 221 /48 network prefix). 223 Note: Both /64 and /48 prefix lengths are shown in this version 224 of the document for illustrative purposes. The number of elements 225 of this query will depend on the prefix length(s) defined by the 226 BEHAVE working group for a translator. If the BEHAVE working 227 group decides that all translators will have a certain prefix 228 length, then only one DNS query is sent. 230 If the host needs to authenticate the prefix it just learned (e.g., 231 because the host is running a DNSSEC validator) the host performs the 232 additional authentication steps described in Section 5. 234 4.2. Using DHCPv6 236 A new DHCP option, OPTION_AFT_PREFIX_DHCP, is defined. It contains 237 the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and 238 their lengths) for the IPv6/IPv4 translator on this network. 240 0 1 2 3 241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | OPTION_AFT_PREFIX_DHCP | option-length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | u-prefix-len | asm-prefix-len| ssm-prefix-len| : 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 247 : IPv6 unicast prefix : 248 : (up to 16 octets) : 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 : IPv6 ASM prefix : 251 : (up to 16 octets) : 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 : IPv6 SSM prefix : 254 : (up to 16 octets) : 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 option-code: OPTION_AFT_PREFIX_DHCP (TBD) 259 option-length: (varies) 261 u-prefix-length: Length for the unicast prefix in bits 263 IPv6 unicast prefix: The translator's IPv6 unicast prefix 265 IPv6 ASM prefix: The translator's IPv6 ASM prefix. If 266 none is provided, the length is 0. 268 IPv6 SSM prefix: The translator's IPv6 SSM prefix. If 269 none is provided, the length is 0. 271 Figure 1: DHCP option OPTION_AFT_PREFIX_DHCP 273 If the host needs to authenticate the prefix it just learned (e.g., 274 because the host is running a DNSSEC validator) the host performs the 275 additional authentication steps described in Section 5. 277 5. Authenticating the Learned Prefix 279 In some cases (e.g., a host performing DNSSEC validation), the host 280 needs to authenticate the translator's IPv6 prefix learned via one of 281 the mechanisms described earlier. To allow such authentication the 282 operator of the translator first creates a PTR record for the 283 translator (with 0's for the elements after the translator's IPv6 284 prefix) which points to a hostname. The hostname has a signed AAAA 285 record for the same 0-padded IPv6 address returned by the PTR query. 286 Once those configuration steps are done, a host can validate the 287 translator's IPv6 prefix by performing the following steps: 289 a. The host sends a DNS PTR query for the IPv6 address of the 290 translator (for "ipv6.arpa"), using 0 for the elements after the 291 prefix length. This will return the fully-qualified hostname of 292 that translator device. 294 b. Verify the full-qualified hostname is on the host's configured 295 list of authorized translators (e.g., 296 seattle.translator.example.net). 298 c. Send a DNS AAAA query for that hostname. 300 d. Verify the AAAA response matches the IPv6 address obtained in 301 step 1. 303 e. Perform DNSSEC validation of the AAAA response. 305 For example, if the translator's IPv6 prefix length is /48, the host 306 would send a PTR query for 2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA 307 which would return a hostname, seattle.translator.example.net. The 308 host verifies that seattle.translator.example.net is on its 309 configured list of authorized translators, as maintained in a text 310 file. The host sends an AAAA query for 311 seattle.translator.example.net and verifies the AAAA response 312 contains the same IPv6 address. The host then validates the DNSSEC 313 signature for seattle.translator.example.net. 315 6. Security Considerations 317 After learning the IPv6 prefix of its translator by following the 318 procedures in this specification, the IPv6 host will utilize this 319 information for subsequent actions (e.g., sending a packet to it, or 320 using that information to synthesize DNS records or to perform DNSSEC 321 validation). If an attacker provides a fraudulent IPv6 to the IPv6 322 host, the attacker can become on-path for traffic to/from that IPv6 323 host and preform passive or active eavesdropping or traffic analysis. 324 To protect against this attack, it is RECOMMENDED that IPv6 hosts be 325 configured with the names of authorized translators and RECOMMENDED 326 that IPv6 hosts uses DNSSEC to validate that name matches the IPv6 327 prefix learned via DNS or DHCPv6 as described in Section 5. 329 7. IANA Considerations 331 A new DHCPv6 option, OPTION_AFT_PREFIX_DHCP, needs to be assigned by 332 IANA. 334 The new NAPTR Application Service tag "TRANSLATE64" is registered 335 with IANA. 337 8. Acknowledgements 339 This draft was fostered by discussion on the 46translation mailing 340 list and at the v4v6 Interim in Montreal. Special thanks to Iljitsch 341 van Beijnum, Andrew Sullivan, Marcelo Bagnulo Braun, Fred Baker, and 342 Xing Li for their comments and suggestions. 344 The mechanism to perform a shortened NAPTR query was described first 345 by Martin Thomson [I-D.thomson-geopriv-res-gw-lis-discovery]. 347 Thanks to Ralph Droms for his help with DHCPv6. Thanks to John 348 Schnizlein for improving the DNS learning algorithm. Thanks to Keith 349 Moore and Scott Brim for suggesting HTTP IPv4 address literals. 350 Thanks to Stig Venaas for help with multicast. Thanks to Xuewei Wang 351 and Xiaohu Xu for suggesting IPv6 Router Advertisements. 353 9. References 355 9.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC4848] Daigle, L., "Domain-Based Application Service Location 361 Using URIs and the Dynamic Delegation Discovery Service 362 (DDDS)", RFC 4848, April 2007. 364 9.2. Informative References 366 [I-D.huang-behave-rfc2767bis] 367 Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts 368 using the "Bump-In-the-Stack" Technique (BIS)", 369 draft-huang-behave-rfc2767bis-00 (work in progress), 370 October 2009. 372 [I-D.huang-behave-rfc3338bis] 373 Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts 374 Using "Bump-in-the-API" (BIA)", 375 draft-huang-behave-rfc3338bis-00 (work in progress), 376 October 2009. 378 [I-D.ietf-behave-dns64] 379 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 380 "DNS64: DNS extensions for Network Address Translation 381 from IPv6 Clients to IPv4 Servers", 382 draft-ietf-behave-dns64-01 (work in progress), 383 October 2009. 385 [I-D.ietf-behave-v6v4-framework] 386 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 387 IPv4/IPv6 Translation", 388 draft-ietf-behave-v6v4-framework-03 (work in progress), 389 October 2009. 391 [I-D.savolainen-mif-dns-server-selection] 392 Savolainen, T., "DNS Server Selection on Multi-Homed 393 Hosts", draft-savolainen-mif-dns-server-selection-01 (work 394 in progress), October 2009. 396 [I-D.thomson-geopriv-res-gw-lis-discovery] 397 Thomson, M. and R. Bellis, "Location Information Server 398 (LIS) Discovery From Behind Residential Gateways", 399 draft-thomson-geopriv-res-gw-lis-discovery-02 (work in 400 progress), July 2009. 402 [I-D.van-beijnum-behave-ftp64] 403 Beijnum, I., "IPv6-to-IPv4 translation FTP 404 considerations", draft-van-beijnum-behave-ftp64-06 (work 405 in progress), October 2009. 407 [I-D.venaas-behave-mcast46] 408 Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An 409 IPv4 - IPv6 multicast translator", 410 draft-venaas-behave-mcast46-01 (work in progress), 411 July 2009. 413 [I-D.venaas-behave-v4v6mc-framework] 414 Venaas, S., "Framework for IPv4/IPv6 Multicast 415 Translation", draft-venaas-behave-v4v6mc-framework-00 416 (work in progress), July 2009. 418 [I-D.wing-behave-http-ip-address-literals] 419 Wing, D., "Coping with IP Address Literals in HTTP URIs 420 with IPv6/IPv4 Translators", 421 draft-wing-behave-http-ip-address-literals-00 (work in 422 progress), October 2009. 424 [I-D.wing-behave-nat64-referrals] 425 Wing, D., "Referrals Across an IPv6/IPv4 Translator", 426 draft-wing-behave-nat64-referrals-01 (work in progress), 427 October 2009. 429 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 430 "DNS Extensions to Support IP Version 6", RFC 3596, 431 October 2003. 433 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 434 Architecture", RFC 4291, February 2006. 436 Appendix A. For future study 438 A.1. multi-homed hosts 440 A multi-homed host may have different translation devices available 441 on each of its networks, and can learn those via DNS, DHCP. 443 When using DNS to learn the translator's prefix (Section 4.1) or 444 using DNS to authenticate the translator prefix (Section 5, it is 445 possible a split horizon DNS exists. Such a split DNS requires the 446 host to query the DNS server associated with that network prefix as 447 described in [I-D.savolainen-mif-dns-server-selection]. 449 A.2. Unicast and multicast translators 451 It may be necessary to use different prefixes for unicast, any source 452 multicast (ASM), and source-specific multicast (SSM) (Section 2 of 453 [I-D.venaas-behave-mcast46]). 455 Appendix B. IPv4 Address Literals on the Internet 457 There has been some doubt that IPv4 address literals occur on the 458 Internet. An examination of the top 1 million domains at the end of 459 August, 2009, showed 2.38% of the HTML in their home pages contained 460 IPv4 address literals. This can be verified by examining the output 461 of the following script: 463 wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip 464 unzip top-1m.csv.zip 465 cat top-1m.csv | 466 cut -d "," -f 2 | 467 xargs -I % -n 1 -t wget -nv % -O - --user-agent="Mozilla/5.0" | 468 grep -E "http://[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" 470 Of the top 1 million websites at the end of August, 2009, 3455 of 471 them are IPv4 address literals. This can be verified with the 472 following script: 474 wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip 475 unzip top-1m.csv.zip 476 grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" 477 top-1m.csv | wc 479 Appendix C. Changes 481 C.1. Changes from -03 to -04 483 o Provided examples of IPv4 address literals with HTTP on the 484 Internet (Appendix B). 486 o removed Router Advertisements. 488 C.2. Changes from -02 to -03 490 o Removed FTP interworking, because [I-D.van-beijnum-behave-ftp64] 491 proposes that FTP clients use the same IP address for the data 492 connection as the control connection. This eliminates the need 493 for the FTP client to learn the translator's prefix. 495 o Added multicast to DHCP and RA messages. 497 C.3. Changes from -01 to -02 499 o provided another method of using RA message for a host to learn 500 its translator's IPv6 prefix and length 502 o added IPv4 address literals in URIs and multicast as benefactors 503 for learning the translator's prefix. 505 o added FTP interworking using PASV 507 o clarified which Scenarios this applies to, and that this is for 508 stateful and stateless. 510 C.4. Changes from -00 to -01 512 o made clearer this is for NAT64 prefix (changed title and some 513 text). 515 o changed from querying for "_aft_prefix" TXT record to querying 516 ipv6.arpa NAPTR record. 518 o BitTorrent is another application that benefits from knowing the 519 NAT64 prefix; previously only DNSSEC was listed. 521 o changed to standards track. 523 Author's Address 525 Dan Wing 526 Cisco Systems, Inc. 527 170 West Tasman Drive 528 San Jose, CA 95134 529 USA 531 Email: dwing@cisco.com