Network Working Group M. Stenberg
Internet-Draft
Intended status: Standards Track June 26, 2013
Expires: December 28, 2013
Hybrid Unicast/Multicast DNS-Based Service Discovery Auto-Configuration
Using OSPFv3
draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-00
Abstract
This document describes how a proxy functioning between Unicast DNS-
Based Service Discovery and Multicast DNS can be automatically
configured using automatically configured routing protocol or some
other network-level state sharing mechanism. Zero-configuration
OSPFv3 is used to describe one concrete way to implement this scheme.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Stenberg Expires December 28, 2013 [Page 1]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. Hybrid proxy - what to configure . . . . . . . . . . . . . . 3
3.1. Conflict resolution with OSPFv3 . . . . . . . . . . . . . 4
3.2. Per-link DNS-SD forward zone names . . . . . . . . . . . 4
3.3. Reasonable defaults . . . . . . . . . . . . . . . . . . . 5
3.3.1. Network-wide unique link name (scheme 1) . . . . . . 5
3.3.2. Router name (scheme 2) . . . . . . . . . . . . . . . 5
3.3.3. Link name (scheme 2) . . . . . . . . . . . . . . . . 5
4. OSPFv3 auto-configuration TLVs . . . . . . . . . . . . . . . 6
4.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 6
4.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 7
4.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 8
4.4. DNS Server TLV . . . . . . . . . . . . . . . . . . . . . 8
5. Desirable router behavior . . . . . . . . . . . . . . . . . . 9
5.1. DNS search path . . . . . . . . . . . . . . . . . . . . . 9
5.2. Hybrid proxy . . . . . . . . . . . . . . . . . . . . . . 9
5.3. OSPFv3 daemon . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative references . . . . . . . . . . . . . . . . . . 11
8.2. Informative references . . . . . . . . . . . . . . . . . 11
Appendix A. Example configuration . . . . . . . . . . . . . . . 12
A.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. OSPFv3-DNS interaction . . . . . . . . . . . . . . . . . 12
A.3. OSPFv3 state . . . . . . . . . . . . . . . . . . . . . . 13
A.4. DNS zone . . . . . . . . . . . . . . . . . . . . . . . . 14
A.5. Interaction with hosts . . . . . . . . . . . . . . . . . 14
Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 15
Appendix C. Why not just proxy Multicast DNS? . . . . . . . . . 15
C.1. General problems . . . . . . . . . . . . . . . . . . . . 15
C.2. Stateless proxying problems . . . . . . . . . . . . . . . 16
C.3. Stateful proxying problems . . . . . . . . . . . . . . . 16
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Stenberg Expires December 28, 2013 [Page 2]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
1. Introduction
Section 3 ("Hybrid Proxy Operation") of [I-D.cheshire-mdnsext-hybrid]
describes how to translate queries from Unicast DNS-Based Service
Discovery described in [RFC6763] to Multicast DNS described in
[RFC6762], and how to filter the responses and translate them back to
unicast DNS.
This document describes what sort of configuration the participating
DNS servers require, as well as how it can be provided using auto-
configured OSPFv3 described in [I-D.ietf-ospf-ospfv3-autoconfig] and
a naming scheme which does not even need to be same across the whole
covered network. The scheme can be used to provision both forward
and reverse DNS zones which employ hybrid proxy for heavy lifting.
While this document describes the data to be transferred in auto-
configured OSPFv3 TLVs, in principle same scheme could work across
other routing protocols, or even some non-routing protocol, as long
as the consistent state for it is available across the whole covered
network (by for example site-scoped multicast, or some other flooding
scheme).
We go through the mandatory specification of the language used in
Section 2, then describe what needs to be configured in hybrid
proxies and participating DNS servers across the network in
Section 3. How the data is exchanged in OSPFv3 is described in
Section 4. Finally, some overall notes on desired behavior of
different router components is mentioned in Section 5.
2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
3. Hybrid proxy - what to configure
Beyond the low-level translation mechanism between unicast and
multicast service discovery, the hybrid proxy draft
[I-D.cheshire-mdnsext-hybrid] describes just that there have to be NS
records pointing to hybrid proxy responsible for each link within the
covered network.
The links to be covered is also non-trivial choice; we can use the
border discovery functionality (if available) to determine internal
and external links. Or we can use OSPFv3 presence (or lack of it) on
a link to determine internal links within the covered network, and
some other signs (depending on the deployment) such as DHCPv6 Prefix
Stenberg Expires December 28, 2013 [Page 3]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
Delegation (as described in [RFC3633] to determine external links
that should not be covered.
For each covered link we want forward DNS zone delegation to an
appropriate router which is connected to a link, and running hybrid
proxy. We also want to populate reverse DNS zone similarly per each
prefix in use. Links' forward DNS zone names should be unique.
There should be DNS-SD domain search list provided for the network's
domain which contains domain for each physical link only once,
regardless of how many routers and hybrid proxy implementations are
connected to it.
Yet another case to consider is the list of DNS-SD domains that we
want hosts to enumerate for domain lists. Typically, it contains
only that the network's domain, but there may be also other networks
we may want to pretend to be local but are in different scope, or
controlled by different organization. For example, a home user might
see both home domain's services (TBD-TLD), as well as ISP's services
under isp.example.com.
3.1. Conflict resolution with OSPFv3
Any naming-related choice on a router may have conflicts in the
network.
We use similar conflict resolution scheme as described in the prefix
assignment draft[I-D.arkko-homenet-prefix-assignment]. That is, if a
conflict is encountered, the router with highest router ID MUST keep
the name they have chosen. The one(s) with lower router ID MUST
either try different one (that is not in use at all according to the
current link state information), or choose not to publish the name
altogether.
If router needs to pick a different name, any algorithm works,
although simple algorithm choice is just like the one described in
Multicast DNS[RFC6762]: append -2, -3, and so forth, until there are
no conflicts in the network for the given name.
3.2. Per-link DNS-SD forward zone names
How to name the links of a whole network in automated fashion? Two
different approaches seem obvious:
1. Unique link name based - (unique-link).(domain).
2. Router and link name - (link).(router).(domain).
Stenberg Expires December 28, 2013 [Page 4]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
The first choice is appealing as it can be much more friendly
(especially given manual configuration). For example, it could mean
just lan.example.com and wlan.example.com for a simple home network.
The second choice, on the other hand, has a nice property of being
local choice as long as router name can be made unique.
The type of naming scheme to use can be left as implementation
option. And the actual names themselves SHOULD be also overridable,
if the end-user wants to customize them in some way.
3.3. Reasonable defaults
Note that any manual configuration, which SHOULD be possible, MUST
override the defaults provided here or chosen by the creator of the
implementation.
3.3.1. Network-wide unique link name (scheme 1)
It is not obvious how to produce network-wide unique link names for
the (unique-link).(domain) scheme. One option would be to base it on
type of physical network layer, and then hope that the number of the
networks won't be significant enough to confuse (e.g. "lan", or
"wlan").
In general network-wide unique link names should be only used in
small networks. Given larger network, after conflict resolution,
finding which network is 'lan-42.example.com' may be challenging.
3.3.2. Router name (scheme 2)
Recommendation is to use some short form which indicates the type of
router it is, for example, "openwrt.example.com". As the name is
visible to users, it should be kept as short as possible. If theory
even more exact model could be helpful, for example, "openwrt-
buffalo-wzr-600-dhr.example.com". In practise, though, providing
some other records indicating exact router information (and access to
management UI) might be more sensible.
If scheme 2 is used, and there is no desire to implement conflict
resolution related TLV described in Section 4.3, a safe default might
be to default to router ID; that is, use as router name value such as
r-(router ID as single 32-bit number). It is guaranteed to be unique
across the network, but not as user-friendly as the descriptive
router name promoted here.
3.3.3. Link name (scheme 2)
Stenberg Expires December 28, 2013 [Page 5]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
Recommendation for (link) portion of (link).(router).(domain) is to
use either physical network layer type as base, possibly even just
interface name on the router, if it's descriptive enough, for
example, eth0.router1.example.com and wlan0.router1.example.com may
be good enough.
4. OSPFv3 auto-configuration TLVs
To implement this specification fully, support for following three
different new OSPFv3 auto-configuration TLVs is needed. However,
only the DNS Delegated Zone TLVs MUST be supported, and the other two
SHOULD be supported.
4.1. DNS Delegated Zone TLV
This TLV is effectively a combined NS and A/AAAA record for a zone.
It MUST be supported by implementations conforming to this
specification. Implementations SHOULD provide forward zone per link
(or optimizing a bit, zone per link with Multicast DNS traffic).
Implementations MAY provide reverse zone per prefix using this same
mechanism. If multiple routers advertise same reverse zone, it
should be assumed that they all have access to the link with that
prefix. However, as noted in Section 5.3, mainly only the router
with highest router ID on the link should publish this TLV.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-BY-IANA-1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved |S|B| Zone (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNS Delegated Zone TLV
Address field is IPv6 address (e.g. 2001:db8::3) or IPv4 address
mapped to IPv6 address (e.g. ::FFFF:192.0.2.1) where the
authoritative DNS server for Zone can be found. If the address
field is all zeros, the Zone is under global DNS hierarchy and can
be found using normal recursive name lookup starting at the
authoritative root servers (This is mostly relevant with the S bit
below).
Stenberg Expires December 28, 2013 [Page 6]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
S indicates that this delegated zone consists of a full DNS-SD
domain, which should be used as base for DNS-SD domain enumeration
(that is, (field)._dns-sd._udp.(zone) exists). Forward zones MAY
have this set. Reverse zones MUST NOT have this set. This can be
used to provision DNS search path to hosts for non-local services
(such as those provided by ISP, or other manually configured
service providers).
B indicates that this delegated zone should be included in network's
DNS-SD list of domains recommended for browsing at b._dns-
sd._udp.(domain). Local forward zones SHOULD have this set.
Reverse zones SHOULD NOT have this set.
Zone is the label sequence of the zone, encoded according to section
3.1. ("Name space definitions") of [RFC1035]. Note that name
compression is not required here (and would not have any point in
any case), as we encode the zones one by one. The zone MUST end
with empty label.
4.2. Domain Name TLV
This TLV is used to indicate the base (domain) to be used for the
network. If multiple routers advertise different ones, the conflict
resolution rules in Section 3.1 should result in only the one with
highest router ID advertising one, eventually. In case of such
conflict, user SHOULD be notified somehow about this, if possible,
using the configuration interface or some other notification
mechanism for the routers.
This TLV SHOULD be supported if at all possible. It may be derived
using some future DHCPv6 option, or be set by manual configuration.
Even on routers without manual configuration options, being able to
read the domain name provided by a different router could make the
user experience better due to consistent naming of zones across the
network.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-BY-IANA-2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Domain Name TLV
Like the Zone field in Section 4.1, the Domain Name TLV's contents
are encoded as label sequence.
Stenberg Expires December 28, 2013 [Page 7]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
By default, if no router advertises domain name TLV, hard-coded
default (TBD) should be used.
4.3. Router Name TLV
This TLV is used to advertise a router's name. After the conflict
resolution procedure described in Section 3.1 finishes, there should
be exactly zero to one routers publishing each router name.
This TLV SHOULD be supported if at all possible. If not supported,
and another router chooses to use the (link).(router) naming scheme
with this router's name, the contents of the network's domain may
look misleading (but due to conflict resolution of per-link zones,
still functional).
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-BY-IANA-3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Name (not even null terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Name TLV
If the router name has been configured manually, and there is a
conflict, user SHOULD be notified somehow about this, if possible,
using the configuration interface or some other notification
mechanism for the routers.
4.4. DNS Server TLV
This TLV is used to announce address of a fallback recursive DNS
server (provided by e.g. ISP). If the DNS server implementations
used in the network are not full recursive resolver implementations,
they may respond to network-specific queries within network, and
forward the rest to the provided DNS servers. Even recursive
resolver implementations may want to use these servers, if available,
for better caching and therefore more responsive user experience.
Typically, these addresses are gleaned from (for example) a DHCPv4/
DHCPv6 exchange, or from Router Advertisements.
Any router on the home network can publish 0-N of these TLVs, and the
order in which they are used is not defined (we assume that the DNS
view of the world is consistent; this may not be true in all cases).
Stenberg Expires December 28, 2013 [Page 8]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
This TLV SHOULD be supported by routers, but the routers (and DNS
servers in the network) MUST be able to cope even in the absence of
the TLV. This can be handled by (for example) DNS servers providing
recursive resolving fallback functionality, or defaulting to some
known global recursive resolver.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-BY-IANA-4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNS Server TLV
The address may be again either IPv4 or IPv6 address, with the IPv4
address encoded under the ::FFFF:/96 prefix.
It is important to note that if the network's domain forward or
reverse resolution will not work globally, using network-external DNS
server directly is not good. Therefore the network's local DNS
servers should be announced to hosts in e.g. DHCPv4/DHCPv6/RA, and
then only those DNS servers can use the contents of this TLV as fall-
back for non-local resolution if so desired. How these local DNS
server addresses are propagated within home network is outside the
scope of this document
5. Desirable router behavior
5.1. DNS search path
The routers following this specification SHOULD provide the used
(domain) as one item in the search path to it's hosts, so that DNS-SD
browsing will work correctly. They also SHOULD include any DNS
Delegated Zone TLVs' zones, that have S bit set.
5.2. Hybrid proxy
Stenberg Expires December 28, 2013 [Page 9]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
The hybrid proxy implementation SHOULD support both forward zones,
and IPv4 and IPv6 reverse zones. It SHOULD also detect whether or
not there are any Multicast DNS entities on a link, and make that
information available to OSPFv3 daemon. This can be done by (for
example) passively monitoring traffic on all covered links, and doing
infrequent service enumerations on links that seem to be up, but
without any Multicast DNS traffic (if so desired).
Hybrid proxy SHOULD also publish it's own name via Multicast DNS
(both forward A/AAAA records, as well as reverse PTR records) to
facilitate applications that trace network topology.
5.3. OSPFv3 daemon
OSPFv3 daemon should avoid publishing TLVs about links that have no
Multicast DNS traffic to keep the DNS-SD browse domain list as
concise as possible. It also SHOULD NOT publish delegated zones for
links that it does not have highest router ID that supports this
specification. (Support for this specification can be deduced by
e.g. presence of any TLVs from this draft advertised by a router.)
OSPFv3 daemon (or other entity with access to the TLVs) SHOULD
generate zone information for DNS implementation that will be used to
serve the (domain) zone to hosts. Domain Name TLV described in
Section 4.2 should be used as base for the zone, and then all DNS
Delegated Zones described in Section 4.1 should be used to produce
the rest of the entries in zone (see Appendix A.4 for example
interpretation of the TLVs in Appendix A.3.
6. Security Considerations
There is a trade-off between security and zero-configuration in
general; if used routing protocol is not authenticated (and in zero-
configuration case, it most likely is not), it is vulnerable to local
spoofing attacks. We assume that this scheme is used either within
(lower layer) secured networks, or with not-quite-zero-configuration
routing protocol set-up which has authentication.
If some sort of dynamic inclusion of links to be covered using border
discovery or such is used, then effectively service discovery will
share fate with border discovery (and also security issues if any).
7. IANA Considerations
This document makes two allocations out of the OSPFv3 Auto-
Configuration (AC) LSA TLV namespace
[I-D.ietf-ospf-ospfv3-autoconfig]:
Stenberg Expires December 28, 2013 [Page 10]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
o The DNS Delegated Zone TLV in Section 4.1 takes the value TBD-BY-
IANA-1 (suggested value is 4).
o The Domain Name TLV in Section 4.2 takes the value TBD-BY-IANA-2
(suggested value is 5).
o The Router Name TLV in Section 4.3 takes the value TBD-BY-IANA-3
(suggested value is 6).
o The DNS Server TLV in Section 4.4 takes the value TBD-BY-IANA-4
(suggested value is 7).
8. References
8.1. Normative references
[I-D.cheshire-mdnsext-hybrid]
Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
Discovery", draft-cheshire-mdnsext-hybrid-01 (work in
progress), January 2013.
[I-D.ietf-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-ietf-ospf-ospfv3-autoconfig-02 (work in progress),
April 2013.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
8.2. Informative references
[I-D.arkko-homenet-prefix-assignment]
Arkko, J. and A. Lindem, "Prefix Assignment in a Home
Network", draft-arkko-homenet-prefix-assignment-01 (work
in progress), October 2011.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Stenberg Expires December 28, 2013 [Page 11]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
Appendix A. Example configuration
A.1. Topology
Let's assume home network that looks like this:
|[0]
+-----+
| CER |
+-----+
[1]/ \[2]
/ \
+-----+ +-----+
| IR1 |-| IR2 |
+-----+ +-----+
|[3]| |[4]|
We're not really interested about links [0], [1] and [2], or the
links between IRs. Given the optimization described in Section 4.1,
they should not produce anything to OSPF state (and therefore to DNS
either) as there isn't any Multicast DNS traffic there.
The user-visible set of links are [3] and [4]; each consisting of a
LAN and WLAN link. We assume that ISP provides 2001:db8::/48 prefix
to be delegated in the home via [0].
A.2. OSPFv3-DNS interaction
Given implementation that chooses to use the second naming scheme
(link).(router).(domain), and no configuration whatsoever, here's
what happens (the steps are interleaved in practise but illustrated
here in order):
1. OSPFv3 auto-configuration takes place, routers get their router
IDs. For ease of illustration, CER winds up with 2, IR1 with 3,
and IR2 with 1.
2. Prefix delegation takes place. IR1 winds up with 2001:db8:1:1::/
64 for LAN and 2001:db8:1:2::/64 for WLAN. IR2 winds up with
2001:db8:2:1::/64 for LAN and 2001:db8:2:2::/64 for WLAN.
3. IR1 is assumed to be reachable at 2001:db8:1:1::1 and IR2 at
2001:db8:2:1::1.
Stenberg Expires December 28, 2013 [Page 12]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
4. Each router wants to be called 'router' due to lack of branding
in drafts. They announce that using the router name TLV defined
in Section 4.3. They also advertise their local zones, but as
that information may change, it's omitted here.
5. Conflict resolution ensues. As IR1 has highest router ID, it
becomes "router". CER and IR2 have to rename, and (depending on
timing) one of them becomes "router-2" and other one "router-3".
Let us assume IR2 is "router-2". During conflict resolution,
each router publishes TLVs for it's own set of delegated zones.
6. CER learns ISP-provided domain "isp.example.com" using DHCPv6
domain list option defined in [RFC3646]. The information is
passed along as S-bit enabled delegated zone TLV.
A.3. OSPFv3 state
Once there is no longer any conflict in the system, we wind up with
following TLVs within OSPFv3 (RN is used as abbreviation for Router
Name, and DZ for Delegated Zone TLVs):
(from CER)
DZ {s=1,zone="isp.example.com"}
(from IR1)
RN {name="router"}
DZ {address=2001:db8:1:1::1, b=1,
zone="lan.router.example.com."}
DZ {address=2001:db8:1:1::1,
zone="1.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."}
DZ {address=2001:db8:1:1::1, b=1,
zone="wlan.router.example.com."}
DZ {address=2001:db8:1:1::1,
zone="2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."}
(from IR2)
RN {name="router-2"}
DZ {address=2001:db8:2:1::1, b=1,
zone="lan.router-2.example.com."}
DZ {address=2001:db8:2:1::1,
zone="1.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."}
DZ {address=2001:db8:2:1::1, b=1,
zone="wlan.router-2.example.com."}
DZ {address=2001:db8:2:1::1,
Stenberg Expires December 28, 2013 [Page 13]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
zone="2.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."}
A.4. DNS zone
In the end, we should wind up with following zone for (domain) which
is example.com in this case, available at all routers, just based on
dumping the delegated zone TLVs as NS+AAAA records, and optionally
domain list browse entry for DNS-SD:
b._dns_sd._udp PTR lan.router
b._dns_sd._udp PTR wlan.router
b._dns_sd._udp PTR lan.router-2
b._dns_sd._udp PTR wlan.router-2
router AAAA 2001:db8:1:1::1
router-2 AAAA 2001:db8:2:1::1
router NS router
router-2 NS router-2
1.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router.example.com.
2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router.example.com.
1.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router-2.example.com.
2.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router-2.example.com.
Internally, the router may interpret the TLVs as it chooses to, as
long as externally defined behavior follows semantics of what's given
in the above.
A.5. Interaction with hosts
So, what do the hosts receive from the routers? Using e.g. DHCPv6
DNS options defined in [RFC3646], DNS server address should be one
(or multiple) that point at DNS server that has the zone information
described in Appendix A.4. Domain list provided to hosts should
contain both "example.com" (the hybrid-enabled domain), as well as
the externally learned domain "isp.example.com".
When hosts start using DNS-SD, they should check both b._dns-
sd._udp.example.com, as well as b._dns-sd._udp.isp.example.com for
list of concrete domains to browse, and as a result services from two
different domains will seem to be available.
Stenberg Expires December 28, 2013 [Page 14]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
Appendix B. Implementation
There is an prototype implementation of this draft (and transitively
also of [I-D.cheshire-mdnsext-hybrid]) at hnet-core github repository
[1] which contains variety of other homenet WG-related things'
implementation too.
hp.lua binary can be used to start hybrid proxy either as one-router
stand-alone implementation (that can be used to e.g. use statically
configured DNS zones), or as part of zeroconf OSPFv3 configured set
of proxies.
Sample usage case:
# sudo lua hp.lua eth0 eth1
.. no output ..
Given the command, hybrid proxy is started for interfaces eth0 and
eth1, and it will publish DNS zones l-eth0.r-router.home,
l-eth1.r-router.home (and home zone with relevant DNS-SD sub-zone,
and default forward behavior) in DNS port. It has -h option for
seeing various options that can be set, notable one being --ospf (use
OSPFv3 autoconfigured hnet infrastructure).
Disclaimer: The set-up of third-party libraries etc to get the
implementation running may be painful and is omitted here. Use of
ready UML NetKit-based test environment or building image for a real
router using hnet github repository [2] is recommended.
Appendix C. Why not just proxy Multicast DNS?
Over the time number of people have asked me about how, why, and if
we should proxy (originally) link-local Multicast DNS over multiple
links.
At some point I meant to write a draft about this, but I think I'm
too lazy; so some notes left here for general amusement of people
(and to be removed if this ever moves beyond discussion piece).
C.1. General problems
There are two main reasons why Multicast DNS is not proxyable in the
general case.
First reason is the conflict resolution depends on ordering which
depends on the RRsets staying constant. That is not possible across
multiple links (due to e.g. link-local addresses having to be
Stenberg Expires December 28, 2013 [Page 15]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
filtered). Therefore, conflict resolution breaks, or at least
requires ugly hacks to work around.
A workaround for this is to make sure that in conflict resolution,
propagated resources always loses. Due to conflict handling ordering
logic, and the arbitrary order in which the original records may be
in, this is non-trivial.
Second reason is timing, which is relatively tight in the conflict
resolution phase, especially given lossy and/or high latency
networks.
C.2. Stateless proxying problems
In general, typical stateless proxy has to involve flooding, as
Multicast DNS assumes that most messages are received by every host.
And it won't scale very well, as a result.
The conflict resolution is also harder without state. It may result
in Multicast DNS responder being in constant probe-announce loop,
when it receives altered records, notes that it's the one that should
own the record. Given stateful proxying, this would be just a
transient problem but designing stateless proxy that won't cause this
is non-trivial exercise.
C.3. Stateful proxying problems
One option is to write proxy that learns state from one link, and
propagates it in some way to other links in the network.
A big problem with this case lies in the fact that due to conflict
resolution concerns above, it is easy to accidentally send packets
that will (possibly due to host mobility) wind up at the originator
of the service, who will then perform renaming. That can be
alleviated, though, given clever hacks with conflict resolution
order.
The stateful proxying may be also too slow to occur within the
timeframe allocated for announcing, leading to excessive later
renamings based on delayed finding of duplicate services with same
name
A work-around exists for this though; if the game doesn't work for
you, don't play it. One option would be simply not to propagate ANY
records for which conflict has seen even once. This would work, but
result in rather fragile, lossy service discovery infrastructure.
Stenberg Expires December 28, 2013 [Page 16]
Internet-Draft Hybrid Proxy OSPFv3 Zeroconf June 2013
There are some other small nits too; for example, Passive Observation
Of Failure (POOF) will not work given stateful proxying. Therefore,
it leads to requiring somewhat shorter TTLs, perhaps.
Appendix D. Acknowledgements
Thanks to Stuart Cheshire for the original hybrid proxy draft and
interesting discussion in Orlando, where I was finally convinced that
stateful Multicast DNS proxying is a bad idea.
Also thanks to Mark Baugher, Ole Troan and Shwetha Bhandari for
review comments.
Author's Address
Markus Stenberg
Helsinki 00930
Finland
Email: markus.stenberg@iki.fi
Stenberg Expires December 28, 2013 [Page 17]