Proposed changes to mDNS -02 draft

[Bernard Aboba <[e-mail]>]

Proposed changes to draft-ietf-dnsext-mdns-02.txt
(and comment disposition from previous revisions)

---------------------------------------------------------------
Section 2.1.3:

Submitted by: Brian Zill
Justification: Use of the solicited node multicast addresses for
mDNS in IPv6 would reduce the multicast traffic handled by=20
any particular node.=20

Change:

"Namely, this extension allows multicast DNS queries to be sent to and
received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6
(below referred as the LINKLOCAL address), which are yet to be assigned
by IANA."

To:

"This extension allows multicast DNS queries to be sent to and=20
received on port 53 using a LINKLOCAL address [2] for IPv4 and
the "solicited node" LINKLOCAL multicast addresses for IPv6.
The IPv6 LINKLOCAL address a given responder listens to, and to which=20
a sender sends, is a link-local multicast address formed as follows:=20
The name of the resource record in question is expressed in its canonical f=
orm=20
(see RFC 2535, section 8.1), which is uncompressed with all alphabetic char=
acters=20
in lower case.  The first label of the resource record name is then hashed =
using=20
the MD5 algorithm (see RFC 1321).  The first 32 bits of the resultant 128-b=
it hash=20
is then appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit=20
"solicited name multicast address".  (Note: this procedure is intended to b=
e the=20
same as that specified in section 3 of [x])  A responder that listens for q=
ueries=20
for multiple names will necessarily listen to multiple of these solicited n=
ame=20
multicast addresses.

[x] Crawford, Matt, "IPv6 Node Information Queries", Internet draft (work
in progress), draft-ietf-ipngwg-icmp-name-lookups-07.txt, August 2000.

Proposed resolution: accept

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Changes to mDNS -01:

--------------------------------------------------------------------
Section 5.1 and 5.2
Submitted by: Dave Thaler
Justification: current text is unclear about API issues

Modify text starting near end of 5.1 as follows:

=2E..  Therefore
it will continue using its name.  Indeed, host myhost cannot=20
distinguish between the situation shown in Figure 2, and that=20
shown in Figure 3 where no conflict exists.

             [A]
             | |
         ----- -----
             | |   =20
           [myhost]=20

   Figure 3. Multiple paths to same host

This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts on=20
different subnets.  This problem ... (rest of 5.1 from change doc)

5.2 Alternatives for solving the multihomed name ambiguity problem

RFC 2553 [RFC 2553] provides an API which can partially solve the name=20
ambiguity problem for applications written to use this API, since the=20
sockaddr_in6 structure exposes the scope within which each scoped=20
address exists, and this structure can be used for both IPv4 (using=20
v4-mapped IPv6 addresses) and IPv6 addresses.

Following the example in Figure 2, an application on 'myhost'
issues the request getaddrinfo("A", ...) with ai_family=3DAF_INET6 and
ai_flags=3DAI_ALL|AI_V4MAPPED.  mDNS requests will be sent from both=20
interfaces and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6=20
structure.  This list will thus contain the IPv4 and IPv6 addresses=20
of both hosts responding to the name 'A'.  Link-local addresses will=20
have a sin6_scope_id value that disambiguates which interface is used=20
to reach the address.  Of course, to the application, Figures 2 and 3
are still indistinguishable, but this API allows the application to
communicate successfully with any address in the list.

Resolution: Accept
Change reflected in mDNS -02 draft.
----------------------------------------------------------------------
Section 5.2
Submitted by: Erik Guttman

Add the following section:

"5.2 Alternatives for solving the multihomed name ambiguity problem

  Unfortunately, simple solutions to this problem do not exist.=20
  Existing APIs for name resolution and communicating between hosts
  via the socket interface do not expose which interface information
  pertains to. [S]  Following the example in Figure 2, if an application
  on 'myhost' issues the request gethostbyname("A").  mDNS requests will
  be sent from both interfaces and the resolver library will return a=20
  struct hostent data structure:

     struct hostent {
         char    *h_name;         /* canonical name of host */
         char    **h_aliases;     /* alias list */
         int     h_addrtype;      /* host address type */
         int     h_length;        /* length of address */
         char    **h_addr_list;   /* list of addresses */
     };

  This will include the addresses for both hosts responding to the name
  'A'.  There is no way to determine or influence which interface was=20
  used to retrieve which address, given the above interface.

  There are some non-solutions to the ambiguous name problem:

   - disallowing multihomed hosts to use mDNS on more than one interface   =
=20
   - suggesting multihomed hosts to elect to act as IP bridges =20
   - suggesting multihomed hosts behave as routers to pass mDNS

  While a multihomed host could function as a bridge or router, this=20
  should be a configured behavior and has profound implications on
  network topology.  Forwarding packets should not be done simply to
  address a link-local protocol limitation.  Avoiding the use of mDNS=20
  on more than one interface of multihomed devices does, however,=20
  dissolve the problem:  One cure for double vision is removing the=20
  second eye.

  There are three possible solutions to the ambigious name problem:

  Approach               Solution                  Assessment

  Do not consider        Applications could        This 'breaks' DNS.
  ambiguity a problem.   come to expect that       It removes the
                         names may be ambiguous.   proper correspondence
                         They would have to        of a domain name=20
                         establish application     with a RR set from
                         layer naming mechanisms.  an application's=20
                                                   perspective.

  Resolve the problem.   Enhance mDNS to include   This would require
                         additional messages so    mDNS to deviate from
                         multihomed hosts can      DNS.  This entails
                         hosts of conflicting      further standards
                         names.                    development. =20

  The mDNS protocol specification already allows for 'gratuitous
  reply messages' (see Section 5).  It is not that much further to
  go to specify behavior by which a multihomed host could send
  gratuitous reply messages on behalf of mDNS servers on distinct
  links to which the host is attached.  This would entail changing
  the conflict resolution algorithm and has profound security
  implications.

  Cope with the problem. This can only be done by  This fails to=20
                         creating new APIs and     support existing
                         new application software  apps and requires
                         to make use of them.      a substantial API
                                                   standardization
                                                   effort.

  New APIs for name resolution would return the interface associated=20
  with the each item in the result.  Applications would have to use=20
  socket (XTI, etc.) interfaces to explicitly select which interfaces=20
  to use for communication.  From the perspective of a multihomed host=20
  neither names nor addresses are guaranteed to be unique, though the=20
  tuple {interface,name} and {interface,address} will be unique."

Resolution: Reject. Behavior in this circumstance is=20
largely implementation dependent, so we don't need to analyze it
in detail. API text contradicts text submitted by Dave Thaler,
accepted as indicated above.=20
--------------------------------------------------------------------
Operational recommendations

Submitted by: Erik Guttman, Levon Esibov, Robert Elz
Justification: Need section (or separate BCP document) on operational
recommendations.=20

Add the following section (or include this in a separate draft):

X.0 Operational Recommendations

X.1 Recommendations to IANA concerning the operation of the ARPA subdomain:

    DNS servers SHOULD NOT forward queries for domain names in the
    local.arpa domain - if the server cannot answer the query from
    its own database, it should reply with a non-authoritative NXDOMAIN.

X.2  Recommendations concerning the operation of the protocol  object regis=
try

    There are no protocol object registry requirements implied by the=20
    'local.arpa' namespace.  This 'arpa' sub-domain exists to support=20
    locally administered resources.  These resources are not protocol=20
    objects per se, unlike for example, PTR RRs in 'in-addr.arpa'.=20
    The resources constitute arbitrary DNS RRs served by mDNS servers
    themselves.

Proposed resolution: Accept (within a separate BCP document)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Changes to draft-ietf-dnsext-mdns-00.txt
------------------------------------------------------------------------
Section 1
Submitted by: Erik Guttman, Dave Thaler
Justification: existing language does not specify possible limitations
of the current approach.=20

Change:

" This extension to the DNS protocol consists of a single change to the
  method of use, and no change to the current format of DNS packets.
  Namely, this extension allows multicast DNS queries to be sent to and
  received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6
  (below referred as the LINKLOCAL address), which are yet to be assigned
  by IANA. LINKLOCAL addresses are used to prevent propagation of
  multicast DNS traffic across routers, potentially flooding the network.
  Propagation of multicast DNS packets within the local subnet is
  considered sufficient to enable DNS name resolution, since the
  expectation is that if a network has a router, then this router can
  function as a DNS proxy, possibly implementing dynamic DNS.  Thus there
  is not expected to be a need for multicast DNS in networks with multiple
  subnets."

to:

" This extension to the DNS protocol consists of a single change to the
  method of use, and no change to the current format of DNS packets.
  Namely, this extension allows multicast DNS queries to be sent to and
  received on port 53.

  The messages are sent using the LINKLOCAL addresses [2] for IPv4 and IPv6
  (below referred as the LINKLOCAL address), which are yet to be assigned
  by IANA. LINKLOCAL addresses are used to prevent propagation of
  multicast DNS traffic across routers, potentially flooding the network.

  Propagation of multicast DNS packets within the local subnet is=20
  considered sufficient to enable DNS name resolution in small
  adhoc networks. The assumption is that if a network has a router,=20
  then the network either has a DNS server or the router can function=20
  as a DNS proxy, possibly implementing dynamic DNS.=20

  In the future, mDNS may be defined to support greater than LINKLOCAL=20
  multicast scope.  This would occur if LINKLOCAL mDNS deployment is=20
  successful, the assumption that mDNS is not needed in multiple=20
  subnets proves incorrect, and multicast routing becomes ubiquitous.
  For example, it is not clear that this
  assumption will be valid in large adhoc networking scenarios.=20

  Once we have experience in mDNS deployment=20
  in terms of administrative issues, usability and impact on the network
  it will be possible reevaluate which multicast scopes are appropriate
  for use with mDNS."

Resolution: Accept
Change reflected in -01 draft.
----------------------------------------------------------------
Submitted by: Erik Guttman, Dave Thaler, Robert Elz
Justification: Current language does not fully specify retransmission
behavior.=20

"If the multicast query is not positively resolved ("positively resolved"
refers in this document to a response with the RCODE set to 0) during a
limited amount of time, then a sender MAY repeat the transmission of a
query in order to assure themselves that the query has been received by
a host capable of responding to the query. Repetition MUST NOT be
attempted more than 5 times, and the repetition SHOULD NOT be repeated
more often than once per 0.1 seconds to reduce unnecessary network
traffic. Retry intervals SHOULD be exponentially increased."

Change to:

"If the multicast query is not positively resolved ("positively resolved"
refers in this document to a response with the RCODE set to 0) during a
limited amount of time, then a sender MAY repeat the transmission of a
query in order to assure themselves that the query has been received by
a host capable of responding to the query.=20

Repetition MUST NOT be attempted more than 3 times and SHOULD NOT
be repeated more often than once per second to reduce unnecessary
network traffic. The delay between attempts should be randomised=20
so as to avoid synchronisation effects."=20

Resolution: Accept
Change incorporated in -01 draft
----------------------------------------------------------------
Section 2.1
Submitted by: Erik Guttman, Levon Esibov
Justification: Error reply implosion possible with current text.

To the following paragraph:

"A response to a multicast query is composed in exactly the same manner
as a response to the unicast DNS query as specified in [4]. Responders
MUST never respond using cached data, and the AA (Authoritative Answer)
bit MUST be set. The response is sent to the sender via unicast."

add:

"A response to an mDNS query MUST have RCODE set to zero, since=20
mDNS responders MUST NOT send error replies in response to=20
multicast requests."

Resolution: Accept
Change reflected in -01 draft.
------------------------------------------------------------------------
Submitted by: Dave Thaler
Justification: Current text does not address the API issues involved
with setting and checking of TTL.=20

"The responder MUST set the Hop Limit field in the IPv6 header and
the TTL field in IPv4 header of all multicast DNS query responses to
255. The sender MUST verify that the Hop Limit field in the IPv6 header
and the TTL field in the IPv4 header of each response to the multicast
DNS query is set to 255. If it is not, then the sender MUST ignore such
a response."

Change to:

"For IPv4 LINKLOCAL addressing, section 2.4 of [6] lays out the rules
with respect to source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 LINKLOCAL addressing is
described in [9]. mDNS queries and responses MUST obey the rules laid
out in these documents.

In composing an mDNS response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the
multicast DNS response to 255. The sender MUST verify that the Hop Limit
field in IPv6 header and TTL field in IPv4 header of each response to
the multicast DNS query is set to 255. If it is not, then sender MUST
ignore the response.

   Implementation note:
   In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL
   socket options are used to specify the TTL of outgoing unicast
   and multicast packets.  The IP_RECVTTL socket option is available
   on some platforms to receive the IPv4 TTL of received packets with
   recvmsg().  RFC 2292 specifies similar options for specifying and
   receiving the IPv6 Hop Limit.
"

Resolution: Accept
Change reflected in 01 draft.=20

Note from Dave:
BTW, the IP_RECVTTL option seems
to exist currently in Linux but not in BSD.  Don't know about any other
OSess.  There's nothing referencable that I can find, but anyone who does
a search on the web for it can easily find the Linux man page that
covers it.

------------------------------------------------------------------------
Submitted by: Erik Guttman
Justification: Specification of the cache period is unnecessary.

Change:

"If no positive response is received, a resolver treats it as a response
that no records of the specified type and class for the specified name
exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT
exceed 5 seconds."

To:

"If no positive response is received, a resolver treats it as a response
that no records of the specified type and class for the specified name
exist (NXRRSET)."

Resolution: Accept
Change reflected in -01 draft
-------------------------------------------------------------------------
Section 3
Submitted by: Bernard Aboba
Justification: current text is confusing and contradictory

In the paragraph:

"If a DNS server is running on a host, the host MUST NOT listen for
multicast DNS queries, to prevent the host from listening on port 53 and
intercepting DNS queries directed to a DNS server. A DNS server MAY
listen and respond to multicast queries. By default, a DNS server MUST
NOT listen to multicast DNS queries. For a DNS server, the presence of
".local.arpa." in the domain search list MUST NOT enable multicast DNS."

Remove the sentence:

"A DNS server MAY listen and respond to multicast queries."=20

Resolution: Accept
Change reflected in 01 draft.
--------------------------------------------------------------------
Section 4
Submitted by: Bernard Aboba
Justification: Current text does not cover addressing limitations.

"3. Upon the reception of the response, the sender verifies that the Hop
   Limit field in IPv6 header or TTL field in IPv4 header (depending on
   the protocol used) of the response is set to 255.=20

Change to:

3. Upon the reception of the response, the sender verifies that the Hop
   Limit field in IPv6 header or TTL field in IPv4 header (depending on
   the protocol used) of the response is set to 255. If the destination
   address is a LINKLOCAL address, then the sender verifies use of a=20
   LINKLOCAL source address. If these conditions are met, then the sender=
=20
   uses and caches the returned response. If not, then the sender ignores=
=20
   the response and continues waiting for the response.=20

Resolution: Accept
Change reflected in 01 draft
-------------------------------------------------------------------
Section 5

Submitted by : Levon Esibov
Justification: Use of dynamic update for conflict detection is a
cleaner approach.=20

Change:

"The uniqueness of the host DNS name MUST be verified when a host boots,
when its name is changed, or when it is configured to use multicast DNS
(such as when the domain search option is changed to include
".local.arpa.").

A gratuitous name resolution query SHOULD be done to check for a name
conflict. This is done by having the resolver send a multicast query of
type SOA for its own name (i.e. for the name it is authoritative for).
If the query is not positively resolved then the host assumes authority
for the name. If the query is positively resolved, then the host should
verify that the name specified in the RDATA of the SOA record in the
answer section of the response is its own host name.  If the host
verifies this, then it assumes authority for its name.  If the returned
name does not match its host name, then a conflict has been detected. In
order to resolve the name conflict, the host will change its name.

A host that has detected a name conflict MUST NOT use the name. This
means that the host MUST NOT respond to multicast queries for that name
and MUST NOT respond to other multicast queries with resource records
within the RDATA field that contain the conflicted name (for example,
the PTR record).

Note that this name conflict detection mechanism doesn't prevent name
conflicts when previously partitioned segments are connected by a
bridge.  In such a situation, name conflicts are detected when a sender
receives more than one response to its multicast DNS query.  In this
case, the sender sends the first response that it received to all
responders that responded to this query except the first one, using
unicast. A host that receives a response to a query for its own name,
even if it didn't send such a query, sends a multicast query for the SOA
record of the name that it is authoritative for. Based on the response,
the host detects the name conflict and acts according to the description
above."

To:

"There are some scenarios when multiple responders MAY respond to the same=
=20
query. There are other scenarios when only one responder may respond to a=
=20
query. Resource records for which the latter queries are submitted are=20
referred as UNIQUE throughout this document.  The uniqueness of a resource=
=20
record depends on a nature of the name in the query and type of the query. =
For=20
example it is expected that

- multiple hosts may respond to a query for a SRV type record=20
- multiple hosts may respond to a query for an A type record for a cluster=
=20
name (assigned to multiple hosts in the cluster)=20

- only a single host may respond to a query for an A type record for a=20
hostname.=20

Every responder that responds to a multicast DNS query and/or dynamic updat=
e=20
request AND includes a UNIQUE record in the response MUST:

1. Verify that there is no other host within the scope of the multicast DNS=
=20
query propagation that can return a DNS record for the same name, type and=
=20
class.=20
2. Responders MUST NOT include a UNIQUE resource record in the=20
response without having verified its uniqueness.=20

Where a host is configured to respond to multicast DNS queries on more=20
than one interface, the host MUST verify resource record uniqueness on=20
each interface for each UNIQUE resource record that could be used on that=
=20
interface. To accomplish this, the host MUST multicast a dynamic

DNS update request as specified in RFC 2136 [RFC 2136] for each new UNIQUE=
=20
resource record. Uniqueness verification is carried out when the host:=20
  - host starts up or=20
  - is configured to respond to the multicast DNS queries on some interface=
 or=20
  - is configured to respond to the multicast DNS queries using additional=
=20
UNIQUE DNS records.=20

Below we describe the data to be specified in the dynamic update request=20
sections.=20

  Header section: contains values according to [RFC 2136].=20

  Zone Section=20
    The zone name in the zone section MUST be set to the name of the UNIQUE=
=20
record.=20
    The zone type in the zone section MUST be set to SOA.=20
    The zone class in the zone section MUST be set to the class of the UNIQ=
UE=20
record.=20

  Prerequisite Section=20
    This section MUST contain a record set whose semantics are described in=
=20
RFC 2136, Section 2.4.3 =93RRset Does Not Exist=94 of [RFC 2136] requesting=
 that=20
no RRs with a NAME and TYPE of the UNIQUE record can exist.

  Update Section=20
    This section MUST be left empty.=20

  Additional Section=20
    This section is set according to RFC 2136.=20

When a host that owns a UNIQUE record receives a dynamic=20
update request that requests that the UNIQUE resource record set does=20
not exist, the host MUST respond via unicast with the YXRRSET error,=20
according to the rules described in Section 3 of RFC 2136 [RFC 2136].=20

After client receives an YXRRSET response to its dynamic update request tha=
t a=20
UNIQUE resource record does not exist, the host MUST not use the UNIQUE=20
resource record in responses to multicast queries and dynamic update reques=
ts.

Note that this name conflict detection mechanism doesn't prevent name=20
conflicts when previously partitioned segments are connected by a=20
bridge.  In such a situation, name conflicts are detected when a sender=20
receives more than one response to its multicast DNS query.  In this=20
case, the sender sends the first response that it received to all=20
responders that responded to this query except the first one, using=20
unicast. A host that receives a query response containing a UNIQUE=20
resource record that it owns, even if it didn't send=20
such a query, MUST verify that no other host within the multicast DNS scope=
 is=20
authoritative for the same name, using the dynamic DNS update=20
request mechanism described above.=20

Based on the result, the host detects whether there is a name conflict and=
=20
acts as described above."=20

Resolution: Accept
Change reflected in 01 draft.
---------------------------------------------------------------------
Section 5.1
Submitted by: Bernard Aboba
Justification: Need additional text addressing name conflict scenarios
in multihomed hosts

Add the following section:

"5.1.  Considerations for Multiple Interfaces

A multi-homed host may elect to configure multicast DNS on only one of
its active interfaces. In many situations this will be adequate.
However, should a host wish to configure multicast DNS on more than one
of its active interfaces, there are some additional precautions it
MUST take. Implementers who are not planning to support multicast DNS
on multiple interfaces simultaneously may skip this section.

A multi-homed host checks the uniqueness of UNIQUE records as described
in Section 5.=20

The situation is illustrated in figure 1 below:

     ----------  ----------
      |      |    |      |
     [A]    [myhost]   [myhost]

   Figure 1. Linklocal name conflict

In this situation, the multi-homed myhost will probe for, and defend,
its host name on both interfaces. A conflict will be detected on one
interface, but not the other, and as a result, the multi-homed myhost
will not be able to respond with a host RR for "myhost".=20

Since names are only unique per-link, hosts on different links could be
using the same name.  If an mDNS client sends requests over multiple=20
interfaces, and receives replies from more than one, the result returned=20
to the client is defined by the implementation.

The situation is illustrated in figure 2 below.

     ----------  ----------
      |      |    |     |
     [A]    [myhost]   [A]


   Figure 2. Off-segment name conflict

If host myhost is configured to use mDNS on both interfaces,
it will send mDNS queries on both interfaces.
When host myhost sends a query for the host RR for name "A"=20
it will receive a response from hosts on both interfaces.=20
Host myhost will then forward a response from the first responder
to the second responder, who will attempt to verify the uniqueness
of host RR for its name, but will not discover a conflict, since
the conflicting host resides on a different subnet. Therefore
it will continue using its name.=20

This illustrates that the proposed name conflict resolution mechanism
does not support resolution of conflicts between hosts on different
subnets. This problem can also occur with unicast DNS=20
when a multi-homed host is connected
to two different networks with separated name spaces. It is not the=20
intent of this document to address the issue of uniqueness of names
within DNS."

Resolution: Accept
Change reflected in 01 draft.

---------------------------------------------------------------------------
Section 7
Submitted by: Bernard Aboba
Justification: Addressing limitations should be discussed.

Change:

"In all received packets, the Hop Limit field in IPv6 and the
TTL field in IPv4 is verified to contain 255, the maximum legal value."

To:

"In all received responses, the Hop Limit field in IPv6 and the
TTL field in IPv4 are verified to contain 255, the maximum legal value.=20
Since routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated
from a neighbor. Packets destined for a LINKLOCAL address are=20
verified to have been sent from a LINKLOCAL source address."=20

Resolution: Accept
Change reflected in 01 draft.
---------------------------------------------------------------------
References
Submitted by: Erik Gutttman
Justification: Current spec does not cite these documents, which are
relevant.

Add:

  [A] Huston, G., "Management Guidelines & Operational Requirements for
   the Internet Infrastructure Domain ("ARPA")", draft-iab-arpa-02.txt,=20
   May 2001, A work in progress.

  [S] Stevens, W. R., "Unix Network Programming, Networking APIs: Sockets=
=20
  and XTI", Prentice Hall, Upper Saddle River, NJ, USA, 1998.

Resolution: accept
Change reflected in 01 draft.
----------------------------------------------------------------------
Section 6
Submitted by: Erik Guttman, Robert Elz
Justification: ARPA guidelines section is required.=20

Add the following text:

" This document specifies the use of a new sub-domain of the "ARPA"=20
  domain.  According to Section 2.1 of the ARPA Guidelines [A], this
  specification requires description and justification.

  The 'local.arpa' domain is used to distinguish a local namespace.
  This namespace differs from others in the following respects:

    - Name servers responding to requests for names in this=20
      domain have different rules concerning authority.  As
      explained in Section 2.1, mDNS servers have limited
      scope of authority, not extending to sub-domains of
      domain they are authoritative for.

    - DNS servers SHOULD NOT forward queries for domain names=20
      in the local.arpa domain - if the server cannot answer=20
      the query from its own database, it should reply with a =20
      non-authoritative NXDOMAIN.

    - Hosts may derive their own names in this namespace,=20
      independent of centralized authorization and registration
      (as defined in section 3 and section 5).

    - There is no delegation or administrative structure to=20
      sub-domains of '.local.arpa'. =20

  How protocol objects are mapped into lookup keys:

    Names are associated with resources which can be requested
    according to the DNS protocol.  However, recursive lookup
    is impossible.  Further, mDNS specifies only the use of
    multicast to transmit these requests.

Resolution: Accept
Change reflected in 01 document
----------------------------------------------------------------------






to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.