draft-ietf-dnssd-requirements-00.txt   draft-ietf-dnssd-requirements-01.txt 
DNS-SD/mDNS Extensions K. Lynn, Ed. DNS-SD/mDNS Extensions K. Lynn, Ed.
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Informational S. Cheshire Intended status: Informational S. Cheshire
Expires: July 10, 2014 Apple, Inc. Expires: August 17, 2014 Apple, Inc.
M. Blanchet M. Blanchet
Viagenie Viagenie
January 6, 2014 D. Migault
Orange
February 13, 2014
Requirements for Scalable DNS-SD/mDNS Extensions Requirements for Scalable DNS-SD/mDNS Extensions
draft-ietf-dnssd-requirements-00 draft-ietf-dnssd-requirements-01
Abstract Abstract
DNS-SD/mDNS is widely used today for discovery and resolution of DNS-SD/mDNS is widely used today for discovery and resolution of
services and names on a local link, but there are use cases to extend services and names on a local link, but there are use cases to extend
DNS-SD/mDNS to enable service discovery beyond the local link. This DNS-SD/mDNS to enable service discovery beyond the local link. This
document provides a problem statement and a list of requirements. document provides a problem statement and a list of requirements.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 10, 2014. This Internet-Draft will expire on August 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 14
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5
4. Internationalization Considerations . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Namespace Considerations . . . . . . . . . . . . . . . . . . 6 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 7
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
DNS-Based Service Discovery [DNS-SD] in combination with its DNS-Based Service Discovery [DNS-SD] in combination with its
companion technology Multicast DNS [mDNS] is widely used today for companion technology Multicast DNS [mDNS] is widely used today for
discovery and resolution of services and names on a local link. discovery and resolution of services and names on a local link.
However, as users move to multi-link home or campus networks they However, as users move to multi-link home or campus networks they
find that mDNS does not work across routers. DNS-SD can also be used find that mDNS does not work across routers. DNS-SD can also be used
in conjunction with conventional unicast DNS to enable wide-area in conjunction with conventional unicast DNS to enable wide-area
service discovery, but this capability is not yet widely deployed. service discovery, but this capability is not yet widely deployed.
skipping to change at page 3, line 15 skipping to change at page 3, line 15
This document defines the problem statement and gathers requirements This document defines the problem statement and gathers requirements
for Scalable DNS-SD/mDNS Extensions. for Scalable DNS-SD/mDNS Extensions.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119]. RFCs to Indicate Requirement Levels" [RFC2119].
1.2. Terminology [TBD] 1.2. Terminology and Acronyms
Discovery Scope Service: An endpoint (host and port) for a given application
protocol. Services are identified by Service Instance Names.
Zero Configuration DNS-SD: DNS-Based Service Discovery, as specified in [DNS-SD], is a
conventional application of DNS Resource Records and messages to
facilitate the discovery and location of services.
Incremental Deployment mDNS: Multicast DNS, as specified in [mDNS], is a transport protocol
that facilitates DNS-SD on a local link in the absence of DNS
infrastructure.
SSD: Scalable DNS-SD is a future extension of DNS-SD/mDNS that meets
the requirements set forth in this document.
Scope of Discovery: A node in a local or global namespace, e.g., a
DNS zone, that is the target of a given DNS-SD query.
Zero Configuration: A set of technologies including DNS-SD/mDNS that
enable local address and name assignment in the absence of DHCP or
DNS infrastructure. May also refer more generally to a deployment of
SSD that requires no administration.
Incremental Deployment: An orderly transition, as a network
installation evolves, from DNS-SD/mDNS to SSD.
2. Problem Statement 2. Problem Statement
Service discovery beyond the local link is perhaps the most important Service discovery beyond the local link is perhaps the most important
feature currently missing from the DNS-SD/mDNS framework. The issues feature currently missing from the DNS-SD/mDNS framework. Other
and requirements are summarized below. issues and requirements are summarized below.
2.1. Multilink Naming and Discovery 2.1. Multi-link Naming and Discovery
A list of desired DNS-SD/mDNS improvements from network A list of desired DNS-SD/mDNS improvements from network
administrators in the research and education community was issued in administrators in the research and education community was issued in
the form of the Educause petition [EP]. The following is a technical the form of the Educause petition [EP]. The following is a summary
summary of the issues: of the technical issues:
o Products that advertise services such as printing and multimedia o Products that advertise services such as printing and multimedia
streaming via DNS-SD/mDNS are not currently discoverable by streaming via DNS-SD/mDNS are not currently discoverable by
devices on other links. It is common practice for enterprises and devices on other links. It is common practice for enterprises and
institutions to use wireless links for client access and wired institutions to use wireless links for client access and wired
networks for server infrastructure, typically on different networks for server infrastructure, typically on different
subnets. DNS-SD used with conventional unicast DNS does work when subnets. DNS-SD used with conventional unicast DNS does work when
devices are on different links, but the resource records that devices are on different links, but the resource records that
describe the service must somehow be entered into the unicast DNS describe the service must somehow be entered into the unicast DNS
namespace. namespace.
o Entering DNS-SD records manually into a unicast DNS zone file o Entering DNS-SD records manually into a unicast DNS zone file
works, (as has been done for many years for the Terminal Room works, but requires a DNS administrator to do that and is fragile
printers at IETF meetings) but requires the DNS administrator to when IP addresses of devices change dynamically, as is common when
know how to do that [static] and is fragile when IP addresses of DHCP is used.
devices may change, as is common when DHCP is used.
o Automatically adding DNS-SD records using DNS Update works, but o Automatically adding DNS-SD records using DNS Update works, but
requires that the DNS server be configured to allow DNS Updates, requires that the DNS server be configured to allow DNS Updates,
and requires that devices be configured with the DNS Update and requires that devices be configured with the DNS Update
credentials to permit such updates, which has proven to be credentials to permit such updates, which has proven to be
onerous. onerous.
o Therefore, a mechanism is desired that populates the DNS namespace o Therefore, a mechanism is desired that populates the DNS namespace
with the appropriate DNS-SD records with less manual with the appropriate DNS-SD records with less manual
administration than typically needed for a unicast DNS server. administration than typically needed for a unicast DNS server.
The following is a technical summary of the requirements: The following is a summary of the technical requirements:
o It must scale to a range of hundreds or thousands of DNS-SD/mDNS o It must scale to a range of hundreds to thousands of DNS-SD/mDNS
enabled devices in a given environment. enabled devices in a given environment.
o It must work with wired and wireless networks from different o It must simultaneously operate over a variety of network link
vendors. technologies, such as wired and wireless networks.
o It must not significantly increase network traffic (wired or o It must not significantly increase network traffic (wired or
wireless). wireless).
o It must be easily managed at an enterprise scale. o It must be cost-effective to manage at up to enterprise scale.
o It must be provided at a reasonable cost. [CapEx + OpEx. KEL]
2.2. IEEE 802.11 Wireless LANs 2.2. IEEE 802.11 Wireless LANs
Multicast DNS was originally designed to run on Ethernet - the Multicast DNS was originally designed to run on Ethernet - the
dominant link-layer at the time. In shared Ethernet networks, dominant link-layer at the time. In shared Ethernet networks,
multicast frames place little additional demand on the shared network multicast frames place little additional demand on the shared network
medium above unicast frames. In IEEE 802.11 networks however, medium compared to unicast frames. In IEEE 802.11 networks however,
multicast frames are transmitted at a low data rate supported by all multicast frames are transmitted at a low data rate supported by all
receivers. In practice, this data rate leads to a larger fraction of receivers. In practice, this data rate leads to a larger fraction of
airtime being devoted to multicast transmission. Some network airtime being devoted to multicast transmission. Some network
administrators block multicast traffic or convert it to a series of administrators block multicast traffic or convert it to a series of
link-layer unicast frames. link-layer unicast frames.
Wireless links may be orders of magnitude less reliable than their Wireless links may be orders of magnitude less reliable than their
wired counterparts. To improve transmission reliability, the IEEE wired counterparts. To improve transmission reliability, the IEEE
802.11 MAC requires positive acknowledgement of unicast frames. It 802.11 MAC requires positive acknowledgement of unicast frames. It
does not, however, support positive acknowledgement of multicast does not, however, support positive acknowledgement of multicast
skipping to change at page 5, line 12 skipping to change at page 5, line 28
number of multicast frames be restricted to a suitably low value, or number of multicast frames be restricted to a suitably low value, or
replaced with unicast frames to use the MAC's reliability features. replaced with unicast frames to use the MAC's reliability features.
2.3. Low Power and Lossy Networks (LLNs) 2.3. Low Power and Lossy Networks (LLNs)
Emerging wireless mesh networking technologies such as RPL [RFC6550] Emerging wireless mesh networking technologies such as RPL [RFC6550]
and 6LoWPAN present several challenges for the current DNS-SD/mDNS and 6LoWPAN present several challenges for the current DNS-SD/mDNS
design. First, Link-Local multicast scope [RFC4291] is defined as a design. First, Link-Local multicast scope [RFC4291] is defined as a
single-hop neighborhood. A single subnet prefix in a wireless mesh single-hop neighborhood. A single subnet prefix in a wireless mesh
network may often span multiple links, therefore a larger multicast network may often span multiple links, therefore a larger multicast
scope is required to span it [I-D.ietf-6man-multicast-scopes]. scope is required to span it [I-D.ietf-6man-multicast-scopes]. mDNS
is not currently specified for greater than Link-Local scope.
Additionally, low-power nodes may be offline for significant periods Additionally, low-power nodes may be offline for significant periods
either because they are "sleeping" or due to connectivity problems. either because they are "sleeping" or due to connectivity problems.
In such cases LLN nodes might fail to respond to queries or defend In such cases LLN nodes might fail to respond to queries or defend
their names using the current design. their names using the current design.
3. Basic Use Cases 3. Basic Use Cases
The following use cases are defined with different constraints to The following use cases are defined with different characteristics to
help distinguish and classify the target requirements. help motivate, distinguish, and classify the target requirements.
They cover a spectrum of increasing deployment and administrative
complexity.
(A) Personal Area networks; e.g., one laptop and one printer. (A) Personal Area networks: the simplest example of a DNS-SD/mDNS
This is the simplest example of a DNS-SD/mDNS network. network may consist of a single client and server, e.g., one
laptop and one printer, on a common link. Such networks may not
contain a router, but instead use Zero Configuration to mitigate
the lack of infrastructure.
(B) Classic home networks, consisting of: (B) Classic home networks, consisting of:
* Single exit router: the network may have multiple upstream * Single exit router: the network may have multiple upstream
providers or networks, but all outgoing and incoming traffic providers or networks, but all outgoing and incoming traffic
goes through a single router. goes through a single router.
* One level depth: all links on the network are connected to the * One-level depth: multiple links on the network are bridged to
same default router. form a single subnet, which is connected to the default router.
* Single administrative domain: all nodes under the same admin * Single administrative domain: all nodes under the same admin
entity. entity. (However, this does not necessarily imply a network
administrator.)
(C) Advanced residential and small business networks (C) Advanced home and small business networks
[I-D.ietf-homenet-arch]: [I-D.ietf-homenet-arch]:
Like B but consist of two or more wired and/or wireless links, Like B but consist of multiple wired and/or wireless links,
connected by routers, behind the single exit router. However, the connected by routers, behind the single exit router. However, the
forwarding nodes are largely self-configuring and do not require forwarding nodes are largely self-configuring and do not require
routing protocol administration. routing protocol administration. Such networks should also not
require DNS administration.
(D) Enterprise networks: (D) Enterprise networks:
Like C but consist of arbitrary diameter under a single Like C but consist of arbitrary network diameter under a single
administrative domain. A large majority of the forwarding and administrative domain. A large majority of the forwarding and
security devices are configured. security devices are configured.
(E) Higher Education networks: (E) Higher Education networks:
Like D but core network may be under a central administrative Like D but core network may be under a central administrative
domain while leaf networks are under local administrative domains. domain while leaf networks are under local administrative domains.
(F) Mesh networks such as RPL/6LoWPAN: (F) Mesh networks such as RPL/6LoWPAN:
Multi-link subnets with prefixes defined by one or more border Multi-link subnets with prefixes defined by one or more border
routers. May comprise network B and any part of networks C, D, or routers. May comprise any part of networks C, D, or E.
E.
4. Internationalization Considerations
The solution should support rich international text, as do DNS-SD and
mDNS today. Users will not accept a solution that does not allow the
richness of service naming that they currently have with mDNS, manual
zone files, and DNS Update today.
5. Namespace Considerations
The unicast DNS namespace contains globally unique names. Naming
services over a local scope contain locally unique names. Clients
discovering services need to be able to differentiate global names
from local names.
6. Requirements 4. Requirements
[This is a straw man proposal. MB] Any successful SSD solution(s) will have to strike the proper balance
between competing goals such as scalability, deployability, and
usability. With that in mind, none of the requirements listed below
should be considered in isolation.
REQ1: The scope of the discovery should be either automatically REQ1: The scope of the discovery should be either automatically
found by the discovering devices and/or configured. determined by the discovering devices or configured (selected)
in the case of multiple choices.
REQ2: For use cases A, B, and C, there should be a zero REQ2: For use cases A, B, and C, there should be a zero
configuration mode of operation. configuration mode of operation.
REQ3: For use cases D and E, there should be a way to configure the REQ3: For use cases D and E, there should be a way to configure the
scope of the discovery and also support both smaller (ex: scope of the discovery and also support both smaller (e.g.,
department) and larger (ex: campus-wide) discovery scopes. department) and larger (e.g., campus-wide) discovery scopes.
REQ4: For use cases D and E, there should be an incremental way to REQ4: For use cases D and E, there should be an incremental way to
deploy the solution. deploy the solution.
REQ5: The new solution should integrate or at least should not break REQ5: SSD should integrate or at least should not break any current
any current link scope DNS-SD/mDNS protocols and deployments. link scope DNS-SD/mDNS protocols and deployments.
REQ6: The new solution MUST be capable of spanning multiple links REQ6: SSD must be capable of spanning multiple links (hops) and
(hops) and network technologies. network technologies.
REQ7: The new solution MUST be scalable to thousands of servers with REQ7: SSD must be scalable to thousands of nodes with minimal
minimal configuration and without degrading network configuration and without degrading network performance. A
performance. possible figure of merit is that, as the number of services
increases, the amount of traffic due to SSD on a given link
remains relatively constant.
REQ8: The new solution MUST provide a consistent user experience REQ8: SSD should enable a way to provide a consistent user
whether local or global services are being discovered. experience whether local or global services are being
discovered.
7. IANA Considerations REQ9: The information presented by SSD should reflect reality. That
is, new information should be available in a timely fashion
and stale information should not persist.
This document currently makes no request of IANA. 5. Namespace Considerations
Note to RFC Editor: this section may be removed on publication as an The unicast DNS namespace contains globally unique names. The mDNS
RFC. namespace contains locally unique names. Clients discovering
services may need to differentiate between local and global names or
to determine that names in different namespaces identify the same
service.
8. Security Considerations SSD should support rich internationalized labels within Service
Instance Names, as DNS-SD/mDNS does today. SSD must not negatively
impact the global DNS namespace or infrastructure.
[Not complete - initial ideas. MB/KEL] The problem of publishing local services in the global DNS namespace
may be generally viewed as exporting local resource records and their
associated labels into some DNS zone. The issues related to defining
labels that are interoperable between local and global namespaces are
discussed in [I-D.sullivan-dnssd-mdns-dns-interop].
6. Security Considerations
Insofar as SSD may automatically gather DNS-SD resource records and
publish them over a wide area, the security issues are likely to be
the union of those discussed in [mDNS] and [DNS-SD]. The following
sections highlight potential threats that are posed by deploying DNS-
SD over multiple links or by automating DNS-SD administration.
6.1. Scope of Discovery
As mDNS is currently restricted to a single link, the scope of the
advertisement is limited, by design, to the shared link between
client and server. In a multi-link scenario, the owner of the
advertised service may not have a clear indication of the scope of
its advertisement.
If the advertisement propagates to a larger set of links than
expected, this may result in unauthorized clients (from the
perspective of the owner) connecting to the advertised service. It
also discloses information (about the host and service) to a larger
set of potential attackers.
If the scope of the discovery is not properly setup or constrained, If the scope of the discovery is not properly setup or constrained,
then information leaks will happen outside the appropriate network. then information leaks will happen outside the appropriate network.
Visiting nodes on a network may discover more services than desired 6.2. Multiple Namespaces
by the network policies, if filtering of discovery packets was not
properly setup. [Is this a NAC or DNS problem? KL]
Depending on the chosen solution, there is a possibility of name There is a possibility of conflicts between the local and global DNS
space conflicts between the DNS tree and this solution. In this namespaces. Without adequate feedback, a client may not know if the
case, a node may not know if the target node or service is the right target service is the correct one, therefore enabling potential
one, therefore enabling ground for various attacks. attacks. [Example? KEL]
The DNS-SD/mDNS framework security considerations also apply. 6.3. Authorization
DNSSEC can assert the validity but not the veracity of records in a DNSSEC can assert the validity but not the veracity of records in a
zone file. The trust model of the global DNS relies on the fact that zone file. The trust model of the global DNS relies on the fact that
human administrators either a) manually enter resource records into a human administrators either a) manually enter resource records into a
zone file, or b) configure the DNS server to authenticate a trusted zone file, or b) configure the DNS server to authenticate a trusted
device (e.g., a DHCP server) that can automatically maintain such device (e.g., a DHCP server) that can automatically maintain such
records. records.
By contrast, the "plug-and-play" nature of mDNS devices has up to now An imposter may register on the local link and appear as a legitimate
depended only on physical connectivity. If a device is visible via service. Such "rogue" services may then be automatically registered
mDNS then it is assumed to be trusted. This is no longer likely to in wide area DNS-SD.
be the case in larger networks. Still, the new solution SHOULD
leverage existing security solutions and not invent new ones. 6.4. Authentication
Up to now, the "plug-and-play" nature of mDNS devices has relied only
on physical connectivity. If a device is visible via mDNS then it is
assumed to be trusted. This is no longer likely to be the case in
larger networks.
If there is a risk that clients may be fooled by the deployment of
rogue services, then application layer authentication should probably
be considered.
6.5. Privacy Considerations
Mobile devices such as smart phones that can expose the location of Mobile devices such as smart phones that can expose the location of
their owners by registering services in arbitrary zones pose a risk their owners by registering services in arbitrary zones pose a risk
to privacy. Such devices MUST NOT register their services in to privacy. Such devices must not register their services in
arbitrary zones without the approval of their operators. However, it arbitrary zones without the approval of their operators. However, it
SHOULD be possible to configure one or more "home" zones, e.g., based should be possible to configure one or more "safe" zones, e.g., based
on subnet prefix, in which mobile devices may automatically register on subnet prefix, in which mobile devices may automatically register
their services. their services.
9. Acknowledgments 7. IANA Considerations
This document currently makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as
an RFC.
8. Acknowledgments
We gratefully acknowledge contributions and review comments made by We gratefully acknowledge contributions and review comments made by
RJ Atkinson, Tim Chown, Ralph Droms, Educause, David Farmer, Matthew RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David
Gast, Peter Van Der Stok, and Thomas Narten. Farmer, Matthew Gast, Peter Van Der Stok, and Thomas Narten.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
skipping to change at page 9, line 30 skipping to change at page 10, line 16
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
10.2. Informative References 9.2. Informative References
[I-D.ietf-6man-multicast-scopes] [I-D.ietf-6man-multicast-scopes]
Droms, R., "IPv6 Multicast Address Scopes", draft-ietf- Droms, R., "IPv6 Multicast Address Scopes", draft-ietf-
6man-multicast-scopes-02 (work in progress), November 6man-multicast-scopes-02 (work in progress), November
2013. 2013.
[I-D.ietf-homenet-arch] [I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", draft- "IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-11 (work in progress), October 2013. ietf-homenet-arch-11 (work in progress), October 2013.
[I-D.sullivan-dnssd-mdns-dns-interop]
Sullivan, A., "Requirements for Labels to Interoperate
Between mDNS and DNS", draft-sullivan-dnssd-mdns-dns-
interop-00 (work in progress), January 2014.
[EP] "Educause Petition", https://www.change.org/petitions/ [EP] "Educause Petition", https://www.change.org/petitions/
from-educause-higher-ed-wireless-networking-admin-group, from-educause-higher-ed-wireless-networking-admin-group,
July 2012. July 2012.
[IEEE.802.11] [IEEE.802.11]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012, Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012,
skipping to change at page 10, line 38 skipping to change at page 11, line 25
1 Infinite Loop 1 Infinite Loop
Cupertino , California 95014 Cupertino , California 95014
USA USA
Phone: +1 408 974 3207 Phone: +1 408 974 3207
Email: cheshire@apple.com Email: cheshire@apple.com
Marc Blanchet Marc Blanchet
Viagenie Viagenie
246 Aberdeen 246 Aberdeen
Quebec , QC G1R 2E1 Quebec , Quebec G1R 2E1
CAN Canada
Email: Marc.Blanchet@viagenie.ca Email: Marc.Blanchet@viagenie.ca
URI: http://www.viagenie.ca URI: http://www.viagenie.ca
Daniel Migault
Orange
38-40 rue du General Leclerc
Issy-les-Moulineaux 92130
France
Phone: +33 1 45 29 60 52
Email: mglt.biz@gmail.com
 End of changes. 55 change blocks. 
104 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/