idnits 2.17.1 draft-stenberg-mif-mpvd-dns-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 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 100 has weird spacing: '...purpose a gl...' -- The document date (October 15, 2015) is 3116 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 7556 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group M. Stenberg 3 Internet-Draft S. Barth 4 Intended status: Standards Track Independent 5 Expires: April 17, 2016 October 15, 2015 7 Multiple Provisioning Domains using Domain Name System 8 draft-stenberg-mif-mpvd-dns-00 10 Abstract 12 This document describes a mechanism to transmit and secure 13 provisioning domain information for IPv6 and IPv4 addresses by using 14 reverse DNS resolution. In addition it specifies backwards- 15 compatible extensions to IPv6 host configuration to support special- 16 purpose global IPv6 prefixes which can only be used to access certain 17 isolated services. 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 April 17, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. PVD information discovery using DNS . . . . . . . . . . . . . 3 57 3.1. PVD TXT Record Fomat . . . . . . . . . . . . . . . . . . 4 58 3.2. PVD TXT Record Keys . . . . . . . . . . . . . . . . . . . 4 59 3.2.1. Reachable Services . . . . . . . . . . . . . . . . . 4 60 3.2.2. DNS Configuration . . . . . . . . . . . . . . . . . . 5 61 3.2.3. Connectivity Characteristics . . . . . . . . . . . . 5 62 3.2.4. Private Extensions . . . . . . . . . . . . . . . . . 6 63 4. Special-purpose IPv6 prefixes . . . . . . . . . . . . . . . . 6 64 4.1. Extensions to Stateless Address Autoconfiguration . . . . 6 65 4.2. Extensions to DHCPv6 . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative references . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative references . . . . . . . . . . . . . . . . . 11 71 Appendix A. This solution compared to doing this in DHCPv6/NDP 72 [RFC Editor: please remove] . . 11 73 Appendix B. Discussion Points [RFC Editor: please remove] . . . 12 74 Appendix C. Changelog [RFC Editor: please remove] . . . . . . . 13 75 Appendix D. Draft Source [RFC Editor: please remove] . . . . . . 13 76 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Given multiple address prefixes or multiple interfaces, hosts require 82 more information to make educated choices about the interfaces and 83 addresses to use. [RFC7556] describes the provision domains (PVDs) 84 that provide the additional information the hosts need. 86 This document describes where and how the provision domain 87 information is encoded in the Domain Name System (DNS). For optional 88 authentication DNSSEC is used. 90 A backwards compatible way of adding IPv6 prefixes without generic 91 internet connectivity is also provided so that the hosts that are not 92 aware of the provisioning domain prefixes do not inadvertly use those 93 for general network access. 95 2. Terminology 97 PVD a provisioning domain, usually with a set of 98 provisioning domain information; for more 99 information, see [RFC7556]. 100 special-purpose a global IPv6 source prefix that cannot be used to 101 IPv6 prefix reach the public IPv6 internet but instead only 102 allows access to certain special services (e.g., 103 VoIP, IPTV). 105 2.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in RFC 110 2119 [RFC2119]. 112 3. PVD information discovery using DNS 114 Each PVD is stored within the DNS, encoded as a single TXT record 115 [RFC1035]. Section 3.1 describes the syntax and Section 3.2 the 116 semantics of the enclosed data. 118 To find the per-PVD TXT records that apply to a source address, the 119 host queries the DNS for PTR records of the domain _pvd.. 120 is a .arpa domain for reverse lookups derived from the 121 respective prefix or subnet the source address is assigned from and 122 generated as specified in [RFC3596] for IPv6 addresses and [RFC1034] 123 for IPv4 addresses respectively. If the query returned any PTR 124 records the host then subsequently queries the DNS for TXT records 125 located in each domain indicated in the PTR records and handles their 126 contents as individual PVDs. 128 As prefixes can be sub-delegated arbitrarily, PTR records SHOULD be 129 provided for any subprefixes contained within a particular prefix. 130 For example, given a prefix 2001:db8:8765:4321::/64, a host with an 131 address of 2001:db8:8765:4321:1234:5678:abcd:beef queries for PTR 132 records in _pvd.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.2.3.4.5.6.7.8.8.b.d 133 .0.1.0.0.2.ip6.arpa However, if the address is assigned from 134 2001:db8:8765:4321:1234::/80, the request would be made for _pvd.0.0. 135 0.0.0.0.0.0.0.0.0.0.4.3.2.1.1.2.3.4.5.6.7.8.8.b.d.0.1.0.0.2.ip6.arpa 136 instead. 138 If for example, the retrieved PTR record is assumed to point at the 139 FQDN _pvd.example.com. The next query is then sent for TXT records 140 in this domain, and if successful, the node has retrieved up-to-date 141 information about PVDs applicable to that particular address. 143 A host MUST support handling multiple PTR records for the initial 144 .arpa domain as well as multiple TXT records for all domains pointed 145 to by the PTR records. This facilitates handling of multiple PVDs 146 with minimal amount of state in the network. A host MUST honor both 147 the time-to-live of the received records, and negative replies that 148 conform to [RFC2308]. A host MUST NOT use addresses from a prefix as 149 the source for new packet flows once the TTL has passed until it did 150 successfully retrieve updated PVD information. 152 3.1. PVD TXT Record Fomat 154 PVD information within DNS is encoded using TXT records, similar to 155 those of DNS-SD [RFC6763] and defined as follows. TXT records 156 consist of key/value pairs, each encoded as a string of up to 255 157 octets preceded by a length byte storing the number of octets. The 158 strings are in the form "key=value" or simply "key" (without 159 quotation marks) where everything up to the first '=' character (if 160 any, otherwise the whole string) is the key and everything after it 161 (if any, including subsequent '=' characters) is the value. Due to 162 the use of a length byte, quotation marks or similar are not required 163 around the value. Keys are case-sensitive. Hosts MUST ignore TXT 164 records which do not conform to these rules. 166 3.2. PVD TXT Record Keys 168 The following keys are defined to be used inside PVD TXT records. 169 Unknown keys inside PVD Information MUST be ignored. 171 3.2.1. Reachable Services 173 The following set of keys can be used to specify the set of services 174 for which the respective PVD should be used. If present they MUST be 175 honored by the client, i.e., if the PVD is marked as not usable for 176 internet access it MUST NOT be used for internet access, if the 177 usability is limited to a certain set of domain or address prefixes, 178 then a different PVD MUST be used for other destinations. 180 +-----+---------------+-----------------+---------------------------+ 181 | Key | Description | Value | Example | 182 +-----+---------------+-----------------+---------------------------+ 183 | n | User-visible | human-readable | n=Foobar Service | 184 | | service name | UTF-8 string | | 185 | s | Internet | (none) | s | 186 | | inaccessible | | | 187 | z | DNS zones | comma-separated | z=foo.com,sub.bar.com | 188 | | accessible | list of DNS | | 189 | | | zone | | 190 | 6 | IPv6-prefixes | comma-separated | 6=2001:db8:a::/48,2001:db | 191 | | accessible | list of IPv6 | 8:b:c::/64 | 192 | | | prefixes | | 193 | 4 | IPv4-prefixes | comma-separated | 4=1.2.3.0/24,2.3.0.0/16 | 194 | | accessible | list of IPv4 | | 195 | | | prefixes in | | 196 | | | CIDR | | 197 +-----+---------------+-----------------+---------------------------+ 199 3.2.2. DNS Configuration 201 The following set of keys can be used to specify the DNS 202 configuration for the respective PVD. If present, they MUST be 203 honored and used by the client whenever it wishes to access a 204 resource of the PVD. 206 +-----+-------------+---------------------+-------------------------+ 207 | Key | Description | Value | Example | 208 +-----+-------------+---------------------+-------------------------+ 209 | r | Recursive | comma-separated | r=2001:db8::1,192.0.2.2 | 210 | | DNS server | list of IPv6 and | | 211 | | | IPv4 addresses | | 212 | d | DNS search | comma-separated | d=foo.com,sub.bar.com | 213 | | domains | list of search | | 214 | | | domains | | 215 +-----+-------------+---------------------+-------------------------+ 217 3.2.3. Connectivity Characteristics 219 The following set of keys can be used to signal certain 220 characteristics of the connection towards the PVD. 222 +-----+------------------+---------------------------+--------------+ 223 | Key | Description | Value | Example | 224 +-----+------------------+---------------------------+--------------+ 225 | bw | Maximum | 1 symmetrical or 2 comma- | bw=5000 or | 226 | | achievable | separated ingress, egress | bw=1000,100 | 227 | | bandwidth | values in kilobits per | | 228 | | | second | | 229 | lt | Minimum | 1 symmetrical or 2 comma- | lt=20 ot | 230 | | achievable | separated ingress, egress | lt=20,100 | 231 | | latency | values in milliseconds | | 232 | rl | Maximum | 1 symmetrical or 2 comma- | rl=1000 or | 233 | | achievable | separated ingress, egress | rl=900,800 | 234 | | reliability | values in 1/1000 | | 235 | tm | Traffic metered | (none) or traffic | tm or | 236 | | (cut-off / | threshold in kilobytes | tm=1000000 | 237 | | limited over | | | 238 | | threshold) | | | 239 | cp | Captive portal | (none) | cp | 240 | nat | IPv4 NAT in | (none) | nat | 241 | | place | | | 242 +-----+------------------+---------------------------+--------------+ 244 3.2.4. Private Extensions 246 keys starting with "x-" are reserved for private use and can be 247 utilized to provide vendor-, user- or enterprise-specific 248 information. It is RECOMMENDED to use one of the patterns "x-FQDN- 249 KEY[=VALUE]" or "x-PEN-KEY[=VALUE]" where FQDN is a fully qualified 250 domain name or PEN is a private enterprise number [PEN] under control 251 of the author of the extension to avoid collisions. 253 4. Special-purpose IPv6 prefixes 255 A service provider might wish to assign certain global unicast 256 address prefixes which can be used to reach a limited set of services 257 only. In the presence of legacy hosts it must be ensured however 258 that these prefixes are not mistakenly used as source addresses for 259 other destinations. This section therefore defines optional 260 extensions to NDP [RFC4861], DHCPv6 [RFC3315] and DHCPv6-PD [RFC3633] 261 to indicate this state. 263 4.1. Extensions to Stateless Address Autoconfiguration 265 NDP [RFC4861] defines the Prefix Information option to announce 266 prefixes for stateless address configuration. The "A-bit" is set, 267 whenever hosts may autonomously derive addresses from a given prefix. 268 For special-purpose prefixes this document defines the first bit of 269 the Reserved1-field as the "S-Bit". 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | Prefix Length |L|A|S|Reserved1| 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | ... | 278 The following additional requirements apply to hosts intending to 279 support global special-purpose IPv6 prefixes: 281 Upon reception of a Prefix Information Option with the S-Bit set, 282 it should behave as if the A-Bit was set, however (unless the 283 A-Bit was actually set by the sending router) it MUST delay using 284 any addresses derived from the prefix until it has queried, 285 retrieved and honored (see Section 3) at least all mandatory 286 provisioning domain information related to the given prefix. 288 A host SHOULD NOT interpret the S-Bit being clear as an indicator 289 that no provisioning domain information is available for a given 290 prefix. 292 The following additional requirements apply to routers: 294 A router MUST NOT set the A-Bit for global unicast address 295 prefixes which cannot be used to reach the public IPv6 internet. 297 A router SHOULD use the S-Bit to indicate that PVD-aware hosts can 298 statelessly assign themselves addresses from a given prefix. It 299 MAY use the S-Bit in addition to the A-Bit to indicate that a 300 prefix usable to reach the public IPv6 internet has additional 301 (optional) provisioning domain information. 303 A router announcing one or more Prefix Information options with 304 the S-Bit set MUST also announce one or more recursive DNS servers 305 using a Recursive DNS Server Option [RFC6106]. If none of the 306 Prefix Information Options it announces have the A-Bit set then at 307 least one of these recursive DNS servers MUST be reachable using a 308 link-local address. 310 4.2. Extensions to DHCPv6 312 Using DHCPv6 [RFC3315] and DHCPv6-PD [RFC3633] servers can actively 313 decide which addresses or prefixes are assigned to clients and 314 requesting routers, however a mechanism is needed to distinguish PVD- 315 aware devices and in the same sense PVD-aware devices need to be able 316 to detect which prefixes and addresses are special-purpose. 317 Therefore, a zero-length DHCPv6 option OPTION_SPECIAL_PURPOSE is 318 defined to be added as a suboption to OPTION_IAADDR and 319 OPTION_IAPREFIX options. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | OPTION_SPECIAL_PURPOSE (TBD) | 0 | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 The following additional requirements apply to clients and requesting 328 routers intending to support global special-purpose IPv6 prefixes via 329 DHCPv6: 331 A client or requesting router MUST include the option code 332 OPTION_SPECIAL_PURPOSE in an option OPTION_ORO in its SOLICIT and 333 REQUEST messages, whenever it wishes to accept special-purpose 334 prefixes in its identity associations. 336 Upon reception of an OPTION_IAADDR or OPTION_IAPREFIX option 337 having an embedded OPTION_SPECIAL_PURPOSE option it MUST delay 338 using any addresses derived from the prefix as source address for 339 its own communication until it has queried, retrieved and honored 340 (see Section 3) at least all mandatory provisioning domain 341 information related to the given prefix or address. If it is a 342 requesting router, it MAY however subdelegate prefixes or assign 343 addresses from special-purpose prefixes to clients without doing 344 so as long as the requirements in the following paragraph are 345 honored. 347 The following additional requirements apply to routers assigning 348 addresses from or delegating (parts of) special-purpose prefixes 349 using DHCPv6: 351 A router MUST include a zero-length suboption of type 352 OPTION_SPECIAL_PURPOSE in every OPTION_IAADDR and OPTION_IAPREFIX 353 option it assigns or delegates containing a global unicast address 354 or prefix which cannot be used to reach the public IPv6 internet. 355 It MUST NOT assign or delegate such an address or prefix to a 356 client or requesting router not including the option code of 357 OPTION_SPECIAL_PURPOSE inside an OPTION_ORO option. 359 A router announcing one or more addresses or prefixes with an 360 embedded OPTION_SPECIAL_PURPOSE option MUST also announce one or 361 more recursive DNS servers using a OPTION_DNS_SERVERS option 362 [RFC3646]. If all of the addresses in a DHCPv6 reply carry the 363 embedded OPTION_SPECIAL_PURPOSE option then at least one of the 364 announced recursive DNS servers MUST be reachable using a link- 365 local address. 367 5. Security Considerations 369 The security implications of using PVDs in general depend on two 370 factors: what they are allowed to do, and whether or not the 371 authentication and authorization of the PVD information received is 372 sufficient for the particular usecase. As the defined scheme uses 373 DNS for retrieval of the connection parameters, the retrieval of both 374 the PTR and the TXT records should be secured, if they are to be 375 trusted. The PVD information allows for the following types of 376 attacks: 378 o Traffic redirection, both by providing custom DNS server, as well 379 as actual potentially different next-hop and/or source address 380 selection. 382 o Faking of connection capabilities to e.g. prefer some connection 383 fraudulently over others. 385 If a host requires DNSSEC authentication and the retrieved 386 information is not sufficiently secured, they MUST be ignored as the 387 defined way of using them in Section 3.2 requires honoring the 388 supplied information. 390 Security properties of NDP and DHCPv6 are inherited for the 391 respective extensions, therefore relevant sections of [RFC4861] and 392 [RFC3315] should be consulted. In any case, signaling addresses and 393 prefixes to be special-purpose does not have a significant impact on 394 the underlying assignment and delegation mechanisms. 396 6. IANA Considerations 398 IANA is requested to setup a PVD DNS TXT Record Key registry with the 399 initial types: s, z, 6, 4 (Section 3.2.1); r, d (Section 3.2.2); bw, 400 lt, rl, tm, cp, nat (Section 3.2.3) and a prefix x- (Section 3.2.4) 401 for Private Use [RFC5226]. The policy for further additions to the 402 registry is requested to be RFC Required [RFC5226]. 404 This document defines a new bit for the NDP Prefix Information Option 405 (the S-bit). There is currently no registration procedure for such 406 bits, so IANA should not take any action on this matter. 408 IANA should assign a DHCPv6 option code OPTION_SPECIAL_PURPOSE to the 409 DHCPv6 option code space defined in [RFC3315]. 411 7. References 413 7.1. Normative references 415 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 416 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 417 . 419 [RFC1035] Mockapetris, P., "Domain names - implementation and 420 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 421 November 1987, . 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 425 RFC2119, March 1997, 426 . 428 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 429 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 430 . 432 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 433 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 434 DOI 10.17487/RFC4861, September 2007, 435 . 437 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 438 C., and M. Carney, "Dynamic Host Configuration Protocol 439 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 440 2003, . 442 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 443 Host Configuration Protocol (DHCP) version 6", RFC 3633, 444 DOI 10.17487/RFC3633, December 2003, 445 . 447 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 448 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 449 DOI 10.17487/RFC3646, December 2003, 450 . 452 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 453 "IPv6 Router Advertisement Options for DNS Configuration", 454 RFC 6106, DOI 10.17487/RFC6106, November 2010, 455 . 457 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 458 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 459 DOI 10.17487/RFC5226, May 2008, 460 . 462 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 463 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 464 . 466 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 467 "DNS Extensions to Support IP Version 6", RFC 3596, DOI 468 10.17487/RFC3596, October 2003, 469 . 471 7.2. Informative references 473 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 474 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 475 . 477 [PEN] IANA, "Private Enterprise Numbers", 478 . 480 Appendix A. This solution compared to doing this in DHCPv6/NDP [RFC 481 Editor: please remove] 483 The angle of attack of the MIF work to date (autumn 2015) has been to 484 add container options and their transfer mechanisms to DHCPv6 and 485 NDP. This document details a different approach, and therefore it is 486 sensible to compare it to to the existing solutions in terms of 487 (highly subjective) pros and cons. The authors consider pros of this 488 proposal to be: 490 o No overhead for hosts that do not care (possibly most; no spurious 491 RA options, ...) 493 o No problems with relaying data; if the first-hop device does not 494 care, DNS requests propagate onward. 496 o Little/no changes to DHCP, DHCPv6, DHCPv6-PD or RA. 498 o Much more scalable; no worries about multicast packet size limits. 500 o No duplication of specifications / TLVs for DHCP, DHCPv6 and RA. 502 o Solves m:n prefix <-> PVD elegantly: no need to either duplicate 503 applying prefix for each PVD or duplicate each PVD for each 504 applying prefix. 506 o Easily extensible (TXT records, no TLV definitions, parsing and 507 generation necessary) 509 o Probably not affected by IPR on draft-ietf-mif-mpvd-dhcp-support 511 o Reuses the existing reverse DNS infrastructure 513 The authors consider cons of this proposal to be: 515 o This scheme requires DNS servers 'close' on the path to the user, 516 if changed information is to be sent; otherwise centralized 517 solution would work (with some synthesized records). 519 o Security using either DNSSEC or in-band hashes is rather painful 520 (but possibly not more than the scheme in the current DHCP/RA 521 drafts), so the default would most likely be insecure. That is 522 not much different from DHCP*/RA, which are also 99.999...% of the 523 time not secured. 525 Appendix B. Discussion Points [RFC Editor: please remove] 527 o Besides special purpose prefixes, it might be desirable to have 528 special purpose routers which only provide access to certain 529 services but not the entire internet. These services could be 530 announced by only using more-specific routes, however if the 531 destination addresses are possibly changing, extension of the RIO 532 mechanism might be needed. One possibility would be to add a new 533 RIO S-flag with semantics like: "When the host receives a Route 534 Information Option with the S-Bit set, it MUST ignore the value in 535 the Prf-field (even if it is (10)) and instead assume the 536 preference to have a value greater than (11). However, it MUST 537 only use the route for packets having a source prefix announced by 538 the same router.". This would allow selective routes (Prf=(10)) 539 only applying to MIF-hosts. 541 o DNSSEC delegation of reverse zones might be difficult in some 542 cases. It is debatable, whether we want a complementary in-band 543 signing mechanism as well, e.g., pre-shared public keys associated 544 the domain name of the TXT records and "sig-X=..." keys (where X 545 identifies the specific key) and ... is an EdDSA or ECDSA 546 signature over all records not starting with "sig-". Care would 547 need to be taken wrt. TTL and negative caching though. 549 o Should PVD-aware hosts be recommended or even required to always 550 prefer routers that announced the respective source address in a 551 PIO over those that didn't when making routing decisions? This 552 takes on the points made in draft-baker-6man-multi-homed-host. 554 Appendix C. Changelog [RFC Editor: please remove] 556 draft-stenberg-mif-mpvd-dns-00: 558 o Initial version. 560 Appendix D. Draft Source [RFC Editor: please remove] 562 As usual, this draft is available at https://github.com/fingon/ietf- 563 drafts/ in source format (with nice Makefile too). Feel free to send 564 comments and/or pull requests if and when you have changes to it! 566 Appendix E. Acknowledgements 568 Thanks to Eric Vyncke for the original idea of using DNS for 569 transmitting PVD information. 571 Authors' Addresses 573 Markus Stenberg 574 Independent 575 Helsinki 00930 576 Finland 578 Email: markus.stenberg@iki.fi 580 Steven Barth 581 Independent 582 Halle 06114 583 Germany 585 Email: cyrus@openwrt.org