Subject: RE: (ngtrans) isatap-03

From: "Dave Thaler" <[email-masked]>
Date: Fri, 15 Feb 2002 13:55:54 -0800

> Please explain how then how an Isatap node can do DNS resolution over
> Ipv6 transport.

It doesn't, it uses name resolution over IPv4 to bootstrap.

-Dave

---

From: Alain Durand <[email-masked]>
Date: Fri, 15 Feb 2002 14:41:48 -0800

> It doesn't, it uses name resolution over IPv4 to bootstrap.

   When the node enables an ISATAP link, it initializes the PRL with
   IPv4 addresses discovered through name service lookups for the Well-
   Known Service name "ISATAP" (see "IANA Considerations"). Nodes
   periodically repeat this process after ResolveInterval to detect
   additions/deletions for the PRL.

==> So nodes periodicaly re-bootstrap the DNS to IPv4 transport....
        Nice instability.

    - Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 15 Feb 2002 17:01:14 -0800

Alain,

I don't understand your point here. An ISATAP node is looking for an
IPv4 address, and requires IPv4 transport to ship tunnel packets, so why
would it be so warped as to use IPv6 transport for the DNS query to
resolve what it knows to be an IPv4 node? The fact that it does so
periodically is no different than any other cached IPv4 response, and a
site can explicitly manage the lifetime. The only possible concern for
stability would be if a site changed the address more frequently than
the cached lifetime.

Tony

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alain Durand
> Sent: Friday, February 15, 2002 2:42 PM
> To: Dave Thaler
> Cc: Alain Durand; Fred L. Templin; Vladislav Yasevich; Mohit Talwar;
> [email-masked]; [email-masked]
> Subject: Re: (ngtrans) isatap-03
>
>
> Dave Thaler wrote:
>

---

From: Alain Durand <[email-masked]>
Date: Mon, 18 Feb 2002 16:29:37 -0800

>stability would be if a site changed the address more frequently than

ISATAP clearly mandates DNS resolution over IPv4 transport, at least
in its configuration phases.

Implementing a DNS stub resolver to do DNS resolution over IPv4 one particular
application and over IPv6 for the others is difficult, so clearly an ISATAP
node will very probably always perform DNS resolution over IPv4
and if ISATAP is deployed widely, it could become an obstacle to
the deployment of DNS resolution over IPv6.

This is a limitation to the model that would not be there if the discovery of
the ISATAP router was done using anycast instead. Also, this limitation is
not present in 6to4 nor in 6over4.

I'm also very concerned about having a NGtrans spec that "mandates" to
"reserved" a name in the DNS tree. I could not find any precedent for that.

	- Alain.

--

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Feb 2002 19:22:22 -0800

> Implementing a DNS stub resolver to do DNS resolution over IPv4 one
> particular application and over IPv6 for the others is difficult, so
> clearly an ISATAP node will very probably always perform DNS resolution
> over IPv4 and if ISATAP is deployed widely, it could become an obstacle
> to the deployment of DNS resolution over IPv6.

how would it be an obstacle?

randy

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 19 Feb 2002 10:36:21 -0800

Alain,

> in its configuration phases.

I appreciate the discussion you are bringing on this subject, but I don't
agree that the draft "clearly mandates" any particular configuration for the
name service lookups (discussed in the last paragraph of section 5.2.1). As
I have already mentioned in response to several messages on this thread, the
draft simply states that the name service is consulted periodically - name
service here could be a local '/etc/hosts' file, NIS, or the DNS. Static
IPv4 address assignments for initializing the PRL are also allowed. (Whether
static assignments are done in place of NS lookups or in addition to them
is left as an implementation decision.)   

> "reserved" a name in the DNS tree. I could not find any precedent for that.

I agree that the draft is seeking to reserve a name in the IANA "Protocol
and Service Names" assigned numbers document, but we believe we are following
"standard operating proceedures" here. Since the "Protocol and Service Names"
document is actively maintained at:

  http://www.iana.org/numbers.html

we assume that it meets the criterion of a "living document" as defined by
the following introductory text of that page:

  "... Since that time, the assignments have been listed in this directory as
   living documents, constantly updated and revised when new information is
   available and new assignments are made. They are listed alphabetically.
   Please check back periodically if you need up to date information from
   these files. Thank you."

Additionally, the first paragraph of the "Protocol and Service Names"
document itself states:

  "These are the Official Protocol Names as they appear in the Domain
   Name System WKS records and the NIC Host Table.  Their use is
   described in [RFC952]."

RFC 952 is clearly an historical document, but we could add it to the
list of informative references if you think it would help.

Thanks,

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Tue, 19 Feb 2002 14:13:50 -0800

RFC952 is DOD INTERNET HOST TABLE SPECIFICATION,
which status is "unknown'. I have noticed the reference to it in
http://www.iana.org/assignments/service-names
but I do not understand how it applies.
Could you please educate me?

    - Alain.