idnits 2.17.1 draft-tsou-softwire-bfd-ds-lite-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-vinokour-bfd-dhcp - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou, Ed. 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational March 5, 2012 5 Expires: September 7, 2012 7 BFD Support DS-Lite 8 draft-tsou-softwire-bfd-ds-lite-00 10 Abstract 12 In DS-Lite, there is no state information of the tunnel, which make 13 it difficult to mange and diagnose. BFD can be used in this case to 14 detect the state of the IPv4-in-IPv6 tunnel by creating BFD session 15 between CPE and AFTR. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 7, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. BFD for DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. DS-Lite Scenario . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Parameters for BFD . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.4. Failover . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.5. Implementation Considerations . . . . . . . . . . . . . . . 7 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 In DS-Lite [RFC6333], there is no status information about the IPv4- 70 in-IPv6 tunnel, no keep-alive mechanism available, it is difficult to 71 know whether the tunnle is up or down, which causes trouble to 72 operation and maintenance. Although administor can use ping to test 73 the connectivity, but that is not a commonly used keep-alive 74 mechanism. 76 BFD [RFC5880] is a mechanism intended to detect faults in the 77 bidirectional path. It is uaually used in conjunction with 78 applications like OSPF, IS-IS, etc, for fast fault recover -- fast 79 re-route. 81 BFD [RFC5880] can be used in DS-Lite, creating BFD session between 82 CPE and AFTR, to provide tunnel status information. If a fault is 83 detected CPE can try to create DS-Lite tunnel with another AFTR, and 84 terminate the existing one, so as to continue network service. 86 [I-D.vinokour-bfd-dhcp] proposes using DHCP option to distribute BFD 87 parameters to CPE. But in case of DS-Lite, some of the key BFD 88 parameters are already available, e.g. peer ip address is already 89 available, and other parameters can be negotiated by BFD signaling, 90 or statically configured, no extra DHCP option(s) need to be defined. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Terminology 100 BFD: Bidirectional Forwarding Detection. 102 AFTR: Address Family Transition Router. 104 CPE: Customer Premise Equipment. 106 FQDN Fully Qualified Domain Name 108 3. BFD for DS-Lite 109 3.1. DS-Lite Scenario 111 In DS-Lite [RFC6333], BFD packet SHOULD be sent through IPv6 tunnel, 112 as shown Figure 1. The IPv4 address of CPE and AFTR SHOULD be the 113 endpoint of a BFD session. 115 +--------------+ +--------------+ 116 +-----+ | | +------+ | | 117 | |-----+--------------+-----| | | | 118 | CPE | IPv6 Tunnel | AFTR |-----| IPv4 Network | 119 | |-----+--------------+-----| | | | 120 +-----+ | IPv6 Network | +------+ | | 121 192.0.0.2 +--------------+ 192.0.0.1 +--------------+ 123 Figure 1: DS-Lite Scenario 125 3.2. Parameters for BFD 127 In order to setup a BFD session, the following parameters are needed, 128 as shown in session 4.1 of [RFC5880]: 130 o Peer IP address 132 o My Discriminator 134 o Your Discriminator 136 o Desired Min TX Interval 138 o Required Min RX Interval 140 o Required Min Echo RX Interval 142 In DS-Lite [RFC6334], CPE WAN port IPv4 address is a well known 143 address 192.0.0.2, and AFTR's IPv4 address is 192.0.0.1, as defined 144 in section 5.7 of [RFC6333]. Because all the CPEs and AFTRs are 145 using well known IP address, IPv4 address is not suffient for setting 146 up a BFD session. From the CPE's point of view, CPE needs to create 147 an IPv6 tunnel to an AFTR so as to get network connectivity to the 148 AFTR, and send IPv4 BFD packets through the tunnel. From the AFTR's 149 point of view, a lot of CPEs with the same IPv4 address will setup 150 BFD session with itself, in order to distinguish the CPEs, AFTR needs 151 to combine both the IPv4 address and the IPv6 address of a CPE with a 152 BFD session. 154 When a CPE gets online, set up a tunnel with a AFTR, then it should 155 iniitate a BFD session with the AFTR, generating a local 156 discriminator, and send the first BFD packet to AFTR with peer 157 discriminator set to zero; when receiving the first BFD packet from 158 CPE, AFTR should get a local discriminator and put it in the response 159 BFD packet to the CPE. 161 Other parameters can be negotiated by BFD signaling; and initial 162 values can be set on CPE and AFTR. 164 3.3. Procedures 166 In DS-Lite [RFC6333], When a CPE gets online, it will be assigned an 167 IPv6 prefix/address, and also the FQDN of the AFTR, as defined in 168 [RFC6334]. The CPE will create an IPv6 tunnel to the AFTR, With 169 which, and also the well know CPE IPv4 address 192.168.0.0.2 and AFTR 170 IPv4 address 192.0.0.1, the CPE can initiate a BFD session to the 171 AFTR. BFD packets will be sent through DS-Lite tunnel. 173 When sending out the first BFD packet, the CPE can generate a unique 174 local discriminator, and set the remote discriminator to zero. When 175 the AFTR receive the first BFD packet from a CPE, the AFTR will also 176 generate a corresponding local discriminator, and put it in the 177 response packet to the CPE. This will finish the discriminator 178 negotiation, without any manual configuration. 180 When the AFTR receive the first packet from a CPE, AFTR will get the 181 IPv6 address and discriminator of the CPE, then AFTR can BFD session 182 of the other direction. 184 The procedures of setting up a BFD session is shown below: 186 CPE AFTR 187 | (CPE get online) | 188 | BFD DOWN | 189 | -------------------------------------------------------> | 190 | local discriminator = 1234 | 191 | remote discriminator = 0 | 192 | | 193 | BFD INIT | 194 | <------------------------------------------------------- | 195 | local discriminator = 5678 | 196 | remote discirminator = 1234 | 197 | | 198 | BFD UP | 199 | -------------------------------------------------------> | 200 | local discriminator = 1234 | 201 | remote discriminator = 5678 | 202 | | 203 | (BFD session in one direction is finished) | 204 | (Start BFD session in the other direction) | 205 | | 206 | BFD DOWN | 207 | <------------------------------------------------------- | 208 | local discriminator = 5678 | 209 | remote discriminator = 1234 | 210 | | 211 | BFD INIT | 212 | -------------------------------------------------------> | 213 | local discriminator = 1234 | 214 | remote discriminator = 5678 | 215 | | 216 | BFD UP | 217 | <------------------------------------------------------- | 218 | local discriminator = 5678 | 219 | remote discriminator = 1234 | 220 | | 221 | (Bidirectional session created!) | 222 | | 224 Figure 2: BFD session setup procedures 226 3.4. Failover 228 The FQDN of AFTR is sent to CPE via DHCP option, as defined in 229 [RFC6334]. Multiple IP addresses can be configured for a FQDN on the 230 DNS server. If BFD detect a fault on the link to an AFTR, CPE can 231 choose another AFTR address, use a different AFTR to provide network 232 sevice. 234 If anycast is used for loadbalance and failover, there might be a 235 ICMP error message problem, that is, when a packet is sent from AFTR 236 to CPE, one of the routers between them may generate a error ICMP 237 message, e.g. packet too big, and the error message is not sent back 238 to the source AFTR, but sent to another AFTR. 240 3.5. Implementation Considerations 242 BFD is usually used for quick fault detection, at a very small time 243 scale, e.g. milliseconds. But in DS-Lite, it may not be necessary to 244 detect fault in such a short time. On the other hand, an AFTR may 245 need to tens of thousand CPEs, which means the AFTR will need to 246 support the same number of BFD sessions. In order to performance 247 requirement to the AFTR, it may be necessary to reduce the time 248 period between BFD packets transmission to a longer time, e.g. 10s or 249 30s. 251 4. IANA Considerations 253 This memo includes no request to IANA. 255 5. Security Considerations 257 In DS-Lite [RFC6333], CPE may not be directly connected to AFTR, 258 there may be other routers between them. Then there are potential 259 spoofing problem, as described in [RFC5883], cryptographic 260 authentication should be used. 262 6. References 264 6.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 270 (BFD)", RFC 5880, June 2010. 272 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 273 (BFD) for Multihop Paths", RFC 5883, June 2010. 275 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 276 Stack Lite Broadband Deployments Following IPv4 277 Exhaustion", RFC 6333, August 2011. 279 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 280 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 281 RFC 6334, August 2011. 283 6.2. Informative References 285 [I-D.vinokour-bfd-dhcp] 286 Vinokour, V., "Configuring BFD with DHCP and Other 287 Musings", May 2008. 289 Author's Address 291 Tina Tsou (editor) 292 Huawei Technologies (USA) 293 2330 Central Expressway 294 Santa Clara CA 95050 295 USA 297 Phone: +1 408 330 4424 298 Email: tina.tsou.zouting@huawei.com