idnits 2.17.1 draft-troan-dhc-dhcpv4osw-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 12, 2013) is 3970 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 170, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-dhc-v4configuration-01 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-07 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC working Group O. Troan 3 Internet-Draft Cisco Systems 4 Intended status: Informational June 12, 2013 5 Expires: December 14, 2013 7 DHCPv4 over A+P softwires 8 draft-troan-dhc-dhcpv4osw-00 10 Abstract 12 A node getting IPv4 access via an A+P mechanism might need other IPv4 13 configuration information. This memo describes how DHCPv4 is 14 supported, on IPv4 over IPv6 tunnels with shared IPv4 addresses. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 14, 2013. 33 Copyright Notice 35 Copyright (c) 2013 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 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 56 7. Normative References . . . . . . . . . . . . . . . . . . . . . 3 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1. Introduction 61 A router connected to a IPv6 only network might get IPv4 connectivity 62 through an IPv4 over IPv6 tunnel. The router can be provisioned with 63 a single IPv4 address, a shared IPv4 address or an IPv4 prefix. The 64 tunnel provisioining mechanism may include provisioning of the IPv4 65 address/prefix and optional port set, or the IPv4 address may be 66 provisioned using DHCPv4 running over the tunnel. Even though the 67 addresses are provisioned as part of tunnel setup, there might be 68 other IPv4 configuration parameters that should be provisioned to the 69 host. 71 This memo describes how DHCPv4 can be supported over an IPv4 over 72 IPv6 tunnel. The mechanism is named "DHCPv4 over softwire" as 73 described here [I-D.ietf-dhc-v4configuration]. 75 MAP [I-D.ietf-softwire-map] is used as the example of the IPv4 over 76 IPv6 tunnel mechanism in this memo, while the mechanism described 77 here should equally apply to other IPv4 over IPv6 mechanisms. 79 Issues with running DHCPv4 over a softwire: 81 1. A DHCPv4 without an IPv4 address sends requests from the 82 unspecified address (0.0.0.0) the the IPv4 broadcast address 83 (255.255.255.255). 85 2. DHCPv4 clients send packets with UDP port 67 to UDP port 68 86 (server). 88 3. DHCPv4 uses hardware addresses (read Ethernet MAC addresses) as 89 the way to identify clients. 91 In MAP all nodes have a point to point tunnel to the MAP Border Relay 92 (BR). The MAP BR is responsible for connecting the MAP domain with 93 the IPv4 Internet. Given that the MAP Customer Edge (CE) router has 94 a point to point tunnel to the MAP BR, then that tunnel supports 95 broadcast already. 97 The MAP BR MUST either be a DHCPv4 relay or DHCPv4 server. If the 98 MAP BR is operating as a relay, it must insert option 82, with the 99 DHCPv4 clients source IPv6 address. 101 The DHCPv4 client and server MUST support [RFC4361] and [RFC6842]. 102 The client identifier is used instead of a hardware identifier. 104 A MAP BR does not consider the unspecified IPv4 address as a shared 105 IPv4 address. Or more correctly all MAP CEs can use the unspecified 106 IPv4 address with the full port set. The MAP BR routes IPv4 packets 107 using the option 82, just like any other DHCPv4 relay. 109 A DHCPv4 client that has its IPv4 address provisioned using the 110 tunnel setup mechanism, MAY send DHCPINFORMs using it's IPv4 unicast 111 address. In the case that this address is port restricted, a UDP 112 port within the assigned range MUST be used instead of port 67. 114 A DHCPv4 client communicates directly with the DHCPv4 server after it 115 has acquired addresses. That requires that the DHCPv4 server 116 supports clients using a different UDP port than 68. 118 If DHCPv4 is to be used for also assigning a port range, a new DHCPv4 119 option is required. 121 The tunnel provisioning mechanism SHOULD indicate if DHCPv4 is 122 required on the link or not. For links without a provisioning 123 mechanism, e.g. a manually configured tunnel, DHCPv4 SHOULD always 124 be tried. 126 2. Architecture 128 IPv4 over IPv6 129 o---------------o tunnel o-------------o o-------o 130 | DHCPv4 client |________________| MAP BR |____| DHCPv4| 131 | MAP CE |----------------| DHCPv4 relay| | server| 132 o---------------o o-------------o o-------o 134 Figure 1: DHCP 136 3. Summary 138 This is a simple mechanism that requires a minimum of changes to 139 existing implementations and deployment practice. The mechanism 140 requires port aware DHCPv4 clients and servers. That is, that the 141 client can use a different UDP port than 68. There is already some 142 support for that in the ISC DHCP implementation. In addition the 143 DHCPv4 relay must be aware of the link-layer type, and insert a 144 correct option-82, just like it does today for VLANs. 146 4. IANA Considerations 148 This specification does not require any IANA actions. 150 5. Security Considerations 152 6. Acknowledgements 154 7. Normative References 156 [I-D.ietf-dhc-v4configuration] 157 Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration 158 Over IPv6 Only Networks", draft-ietf-dhc- 159 v4configuration-01 (work in progress), May 2013. 161 [I-D.ietf-softwire-map] 162 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 163 Murakami, T., and T. Taylor, "Mapping of Address and Port 164 with Encapsulation (MAP)", draft-ietf-softwire-map-07 165 (work in progress), May 2013. 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 171 2131, March 1997. 173 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 174 Identifiers for Dynamic Host Configuration Protocol 175 Version Four (DHCPv4)", RFC 4361, February 2006. 177 [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client 178 Identifier Option in DHCP Server Replies", RFC 6842, 179 January 2013. 181 Author's Address 183 Ole Troan 184 Cisco Systems 185 Philip Pedersens vei 1 186 Lysaker 1366 187 Norway 189 Email: ot@cisco.com