idnits 2.17.1 draft-sarikaya-mif-6man-ra-route-02.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 : ---------------------------------------------------------------------------- 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 date (February 25, 2013) is 4078 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) == Unused Reference: 'RFC2629' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 268, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track February 25, 2013 5 Expires: August 29, 2013 7 IPv6 RA Options for Multiple Interface Next Hop Routes 8 draft-sarikaya-mif-6man-ra-route-02 10 Abstract 12 This draft defines new Router Advertisement options for configuring 13 next hop routes on the mobile or fixed nodes. Using these options, 14 an operator can easily configure nodes with multiple interfaces (or 15 otherwise multi-homed) to enable them to select the routes to a 16 destination. Each option is defined together with definitions of 17 host and router behaviors. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 29, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Default Route Configuration . . . . . . . . . . . . . . . . . . 4 56 4. Host Configuration . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Router Configuration . . . . . . . . . . . . . . . . . . . . . 4 58 6. Route Prefix option . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Next Hop Address option . . . . . . . . . . . . . . . . . . . . 5 60 8. Next Hop Address with Route Prefix option . . . . . . . . . . . 6 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 12.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 IPv6 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration 72 protocols can be used to configure fixed and mobile nodes with 73 various parameters related to addressing and routing [RFC4861], 74 [RFC4862], [RFC4191]. DNS Recursive Server Addresses and Domain Name 75 Search Lists are additional parameters that can be configured using 76 router advertisements [RFC6106]. 78 Router Advertisements can also be used to configure fixed and mobile 79 nodes in multi-homed scenarios with route information and next hop 80 address. Different scenarios exist such as the node is 81 simultaneously connected to multiple access network of e.g. WiFi and 82 3G. The node may also be connected to more than one gateway. Such 83 connectivity may be realized by means of dedicated physical or 84 logical links that may also be shared with other users nodes such as 85 in residential access networks. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Default Route Configuration 95 A host, usually a mobile host interested in obtaining routing 96 information usually sends a Router Solicitation (RS) message on the 97 link. The router, when configured to do so, provides the route 98 information using zero, one or more Next Hop Address and Route 99 Information options in the router advertisement (RA) messages sent in 100 response. 102 The route options are extensible, as well as convey detailed 103 information for routes. 105 RS and RA exchange is for next hop address and route information 106 determination and not for determining the link-layer address of the 107 router. Subsequent Neighbor Solicitation and Neighbor Advertisement 108 exchange can be used to determine link-layer address of the router. 110 It should be noted that the proposed options in this document will 111 need a central site-wide configuration mechanism. The required 112 values can not automatically be derived from routing tables. 114 Next hop address and related route information may be provided by 115 some other means such as directly by the next hop routers. In this 116 document we assume that next hop routers are not able to provide this 117 information. One solution would be to develop an inter-router 118 protocol to instigate the next hop routers to provide this 119 information. However, such a solution has been singled out due to 120 the complexities involved. 122 4. Host Configuration 124 Router advertisement options defined in this document are used by 125 Type C hosts. 127 As defined in [RFC4191] Type C host uses a Routing Table instead of a 128 Default Router List. 130 5. Router Configuration 132 The router MAY send one or more Next Hop Address options that specify 133 the IPv6 next hop addresses. Each Next Hop Address option may be 134 associated with zero, one or more Route Prefix options that represent 135 the IPv6 destination prefixes reachable via the given next hop. 136 Router includes Route Prefix option in message to indicate that given 137 prefix is available directly on- link. 139 Router MAY send a single Next Hop Address without any Route Prefix 140 options. When router sends Next Hop Address option that is 141 associated with Router Prefix option, the router MUST use Next Hop 142 and Route Prefix option defined in Section 8. The Route Prefix MAY 143 contain ::/0, i.e. with Prefix Length set to zero to indicate 144 available default route. 146 6. Route Prefix option 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Type | Length | Prefix Length |Resvd|Prf|Metric| 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Route Lifetime | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Prefix (Variable Length) | 156 . . 157 . . 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: Route Prefix option 162 Fields: 164 Type: TBD. 166 Length: The length of the option (including the Type and Length 167 fields) in units of 8 octets. 169 Other fields are as in [RFC4191] except: 171 Metric Route Metric. 3-bit signed integer. The Route Metric 172 indicates whether to prefer the next hop associated with this prefix 173 over others, when multiple identical prefixes (for different next 174 hops) have been received. 176 7. Next Hop Address option 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type | Length | Next Hop Address ... 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 2: Next Hop Address option 186 Fields: 188 Type: TBD. 190 Length: The length of the option (including the type and length 191 fields) in units of 8 octets. It's value is 3. 193 Next Hop Address: An IPv6 address that specifies IPv6 address of the 194 next hop. It is 16 octets in length. 196 8. Next Hop Address with Route Prefix option 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | Next Hop Address ... | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 + ... | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | ... | Prefix Length |Resvd|Prf|Metric| 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Route Lifetime | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Prefix (Variable Length) | 210 . . 211 . . 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 3: Next Hop Address with Route Prefix option 216 Fields: 218 Type: TBD. 220 Length: The length of the option (including the type and length 221 fields) in units of 8 octets. For example, the length for a prefix 222 of length 16 is 5. 224 Other fields are as in Section 6 and Section 7. 226 9. Security Considerations 228 Neighbor Discovery is subject to attacks that cause IP packets to 229 flow to unexpected places. Because of this, neighbor discovery 230 messages MUST be secured, possibly using Secure Neighbor Discovery 231 (SEND) protocol [RFC3971]. 233 10. IANA Considerations 235 Authors of this document request IANA to assign three new RA options: 237 +-----------------------------------+------+ 238 | Option Name | Type | 239 +-----------------------------------+------+ 240 | Route Prefix | | 241 | Next Hop Address | | 242 | Next Hop Address and Route Prefix | | 243 +-----------------------------------+------+ 245 Table 1: 247 11. Acknowledgements 249 Brian Carpenter provided comments that have led to improvements in 250 the document. We are also grateful to Zhen Cao for his comments. 252 12. References 254 12.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 260 June 1999. 262 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 263 Neighbor Discovery (SEND)", RFC 3971, March 2005. 265 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 266 More-Specific Routes", RFC 4191, November 2005. 268 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 269 "Internet Group Management Protocol (IGMP) / Multicast 270 Listener Discovery (MLD)-Based Multicast Forwarding 271 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 273 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 274 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 275 September 2007. 277 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 278 Address Autoconfiguration", RFC 4862, September 2007. 280 12.2. Informative References 282 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 283 "IPv6 Router Advertisement Options for DNS Configuration", 284 RFC 6106, November 2010. 286 Author's Address 288 Behcet Sarikaya 289 Huawei USA 290 5340 Legacy Dr. Building 175 291 Plano, TX 75024 293 Phone: 294 Email: sarikaya@ieee.org