idnits 2.17.1 draft-durand-ngtrans-6to4-well-known-address-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 179 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 (February 2001) is 8471 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) ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Alain Durand, SUN Microsystems 3 NGTRANS WG George Tsirtsis, Flarion Technologies 4 February 2001 6 IPv6 well known address for a 6to4 router 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 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 Distribution of this memo is unlimited. 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC2119. 37 1. Introduction 39 A 6to4 [1] domain is derived from a single IPv4 address of a border 40 6to4 router. Although it is possible to have several 6to4 exit router 41 for outbound traffic, there can only be one 6to4 router for inbound 42 traffic. This router is called the 6to4 designated router. 44 Per the architecture of 6to4, it is trivial to find the IPv4 address 45 of the 6to4 designated router. As 6to4 requires a global IPv4 address, 46 this router is reachable from any host in the global IPv4 Internet. 47 Inside the 6to4 domain, it may be the case that private address space 48 is used, but the propagation of a specific route or a default route 49 can maintain the reachability of the designated router in IPv4. 51 Inside the 6to4 domain, the IPv6 routing system may propagate a default 52 route to one of the 6to4 exit router, but there is no way to discover 53 the IPv6 address of the 6to4 designated router. Outside the 6to4 domain, 54 there is no way to address the 6to4 designated router in IPv6. 56 This proposal aim at reserving a well known IPv6 address taken from the 57 6to4 derived prefix for the 6to4 designated router. 59 2. Reserving a well known address 61 SLAid = 0x0000 MUST be reserved as a virtual subnet for all 6to4 routers 62 within a 6to4 domain. 64 Per RFC2373 [2], section 2.6.1, a subnet router anycast address is 65 defined with the 64 remaining bits set to zero. This will be the anycast 66 address of any 6to4 router within that particular 6to4 domain. 68 However, as anycast addresses can not be used as source address and 69 this anycast address does not uniquely define the 6to4 designated router, 70 we will go one step further and reserved the address made of: 72 - the 16 bit TLA 0x2002 (the 6to4 TLA) 73 - the 32 bit NLA xxxx:yyyy, where xxxx:yyyy is the IPv4 address of 74 the 6to4 designated router 75 - the 16 bit SLA 0x0000 76 - the 64 bit Interface ID set to 0x0000000000000001 78 as the reserved, well known, IPv6 address for the 6to4 designated router. 80 All 6to4 routers within a 6to4 domain SHOULD be configured with the 6to4 81 router anycast address. 83 The 6to4 designated router MUST be configured with the well known 84 IPv6 6to4 designated address. 86 3. Example 88 If the IPv4 address of the designated 6to4 router is 201.202.203.204, 89 then: 90 - the 6to4 IPv6 prefix is 2002:C9CA:CBCC::/48 91 - the reserved subnet for all 6to4 routers is 2002:C9CA:CBCC::/64 92 - the anycast address for all the 6to4 router is 2002:C9CA:CBCC::0/128 93 - the well know IPv6 address for the designated 6to4 router 94 is 2002:C9CA:CBCC::1/128 96 4. Scaling issues 98 The well known address for the 6to4 designated router has the same 99 scaling issues as 6to4 itself, there can be several 6to4 outbound router, 100 but only a single inbound router. 102 5. Security issues 104 None. 106 6. Author's address 108 Alain Durand 109 SUN Microsystem, Inc. 110 901 San Antonio road 111 UMPK17-202 112 PALO ALTO, CA 94303-4900 113 USA 114 EMail: Alain.Durand@sun.com 116 George Tsirtsis 117 Flarion Technologies 118 G.Tsirtsis@Flarion.com 119 gtsirt@hotmail.com 121 7. References 123 [1] RFC3056, Connection of IPv6 Domains via IPv4 Clouds, Carpenter & Moore, 2001 125 [2] RFC2373, IPv6 Addressing Architecture, Hinden & Deering, 1998 127 8. Copyright Notice 129 Placeholder for ISOC copyright.