idnits 2.17.1 draft-richier-dstm-vpn-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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 81: '..., the DSTM server MUST be in charge of...' RFC 2119 keyword, line 104: '... server MUST authenticate the DSTM h...' RFC 2119 keyword, line 113: '... mapping in the TEP MUST be managed by...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 (-08) exists of draft-ietf-ngtrans-dstm-07 -- Possible downref: Normative reference to a draft: ref. '1' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jean-Luc Richier 2 NGTRANS Working Group IMAG 3 Expires August 2002 Octavio Medina 4 Laurent Toutain 5 ENST Bretagne 7 DSTM in a VPN Scenario 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 35 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Distribution of this memo is unlimited. 40 Abstract 42 In an implicit manner, the specification of DSTM focuses on a 43 scenario where DSTM nodes are inside an IPv6-only intranet. This 44 document describes a new usage for DSTM in which DSTM nodes are 45 located outside the intranet: the VPN scenario. 47 1. Introduction 49 In an implicit manner, the specification of DSTM[1] focuses on a 50 scenario where DSTM nodes are inside an IPv6-only intranet. In this 51 case, communication to IPv4 networks is assured by a Tunnel End Point 52 (TEP) which also belongs to the intranet. This document describes a 53 new usage for DSTM in which DSTM nodes are located outside the 54 intranet: the VPN scenario. 56 Note that the VPN scenario still considers the case where an IPv6 57 host requests an IPv4 address. This document does not cover the case 58 where an IPv4-only host wants to establish a communication with an 59 IPv6 host. 61 2. Service Description 63 DSTM[1] can be used to access IPv4 resources when only IPv6 64 connectivity is available. This capacity is not be limited to the 65 intranet scenario. For example, in wireless networks (like a 3G 66 network) the property of autoconfiguration makes it relatively easy 67 to allocate IPv6 addresses to equipments. The IPv4 address allocation 68 may be more problematic. In this case, the Service Provider can offer 69 IPv6 connectivity only; communication to the IPv4 Internet being 70 assured by DSTM. DSTM nodes may be placed anywhere in the network, as 71 long as IPv6 connectivity exists between the hosts and DSTM servers 72 and TEPs. DSTM can be used to justify the creation of a native IPv6 73 infrastructure, with TEPs and DSTM servers providing the access the 74 IPv4 Internet. 76 In the VPN scenario, we suppose that a DSTM node is located outside 77 his home domain on an IPv6-only infrastructure and that the node can 78 easely get an IPv6 address. The DSTM node can contact the DSTM server 79 of his home domain using the IPv6 connectivity. If autentication 80 succeeds, the DSTM server allocates a temporary IPv4 address to the 81 DSTM node. For this scenario, the DSTM server MUST be in charge of 82 TEP configuration. Only when the DSTM server has allocated an 83 address, the corresponding IPv4/IPv6 address mapping and time of the 84 lease are set up at the TEP. This is an important requirement that 85 avoids the use of IPv4 ressources by non authorized nodes. 87 The TEP and the DSTM server can be located inside the same home 88 domain, allowing either the use of private IPv4 addresses to access 89 only the company resources or the use of public IPv4 addresses for a 90 complete access to the Internet v4. 92 The investissement for sites is minimal, it requires an access to the 93 IPv6 Internet through native links or tunnels and the installation of 94 a TEP and a DSTM server. It can also be possible to locate this 95 mechanism in another part of the network, which may be runned by a 96 third party. 98 3. Security Considerations 100 The main difference between the intranet scenario and the VPN 101 scenario of DSTM is security. In the intranet scenario, the request 102 for a temporary IPv4 address may not be authenticated since DSTM 103 hosts are located inside an Intranet. In the VPN scenario, the DSTM 104 server MUST authenticate the DSTM host. This authentication cannot 105 rely on the IPv6 address since the address depends on the visiting 106 network, but can be based on some shared secret. 108 The mapping between the IPv4 and IPv6 address of the DSTM node in the 109 TEP is also a security concern. If the mapping is established 110 dynamically (no configuration by the DSTM server), it could be 111 possible for every intruder knowing a valid temporary IPv4 address to 112 use the TEP as an IPv4 relay or to access internal IPv4 ressources. 113 So, in the VPN scenario, the mapping in the TEP MUST be managed by 114 the DSTM server which authenticates the DSTM host and its IPv6 115 address. The tunnel between the DSTM host and the TEP can be 116 cyphered, but it is the authors' view that this is more an IPv6 117 feature (like the use of IPv6 mobility) than a DSTM feature. 119 From the authors' point of view, the use of DSTM under these 120 circumstances could be benefic for IPv6 networks: it can be a way to 121 install an IPv6 infrastructure and generate IPv6 traffic to access 122 IPv4 ressources through DSTM TEPs. 124 References 126 [1] Bound, Toutain, Medina et al. Dual Stack Transition Mechanism. 127 draft-ietf-ngtrans-dstm-07.txt; Work in Progress. 128 Expires August 2002.