Subject: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Nov 2009 23:42:02 -0500

Section 1, Section 3: don't abbreviate "Potential Router List" as
"PRL" - it clashes violently with the existing DHCP "PRL", which is
the parameter request list.  Better to just spell it out - it appears
four or five times in the document, which is a pain, but not too bad.

Put the IP address and FQDN counts right before the data being
counted, not at the beginning of the option - the way the draft
currently does it violates common practice and will require a special
code path in conforming implementations.  So it should be option code,
len, anycast address, ip-addr-count, ip-addr-1, ..., ip-addr-n,
fqdn-count, fqdn-1, ..., fqdn-n.

Why are you specifying both IP addresses and FQDNs?  Standard practice
in DHCP is to just send FQDNs and let the DHCP server do name
resolution.  Sending both makes the implementation more complex - is
there some reason why this complexity is necessary?  It's going to be
difficult to specify in the DHCP server configuration, since most
existing DHCP servers accept FQDNs in any configuration field where an
IPv4 address is expected - how is the parser supposed to tell which
FQDNs to resolve and which to send to the client unresolved?

If you do actually need FQDNs for some reason, you need to specify how
they are encoded.  The standard practice for DHCP options would be to
have some text similar to section 8 of RFC3315.

The sample data for the FQDN option has a leading '.' fqdn before the
isatap.com fqdn, which makes the count wrong.

Why is this an informational draft?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Nov 2009 00:00:37 -0500

On Nov 23, 2009, at 11:42 PM, Ted Lemon wrote:
> resolution.

Sorry, that came out wrong.   I mean standard practice is to configure the DHCP server with FQDNs and have it do name resolution, sending IP addresses to the DHCP client, not FQDNs.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Nov 2009 09:21:45 -0800

Hi Ted,

Thanks for the comments. There was a question on this
on the softwires list also, so I'm cross-posting:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: Monday, November 23, 2009 8:42 PM
> To: Fred Templin
> Cc: dhc WG
> Subject: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt
> 

Thanks for catching that; I'll fix it.

> fqdn-count, fqdn-1, ..., fqdn-n.

Got it, and I'll fix this.
 
> FQDNs to resolve and which to send to the client unresolved?

The way ISATAP is currently specified, it expects to get a
connection-specific DNS suffix from the DHCP server (i.e.,
from a domain name option) and then self-constructs an FQDN
by prepending the well-known string "isatap" (e.g., as
"isatap.example.com" when the suffix is "example.com"). The
ISATAP client then resolves the FQDN itself by consulting
the DNS.

So, I want to preserve backward compatibility and maintain
the same administrative profile whereby the client gets
some information from DHCP and then consults the DNS on
its own behalf. The client then uses the DNS TTLs as an
indication of when it should re-resolve the FQDN. So
administrative changes normally touch only the DNS resource
records and only very rarely need to touch the DHCP config's,
and clients discover the updates via DNS.

> have some text similar to section 8 of RFC3315.

RFC3315 cites Section 3.1 of RFC1035. That is the same
normative reference I am citing in the current draft.
(Actually, it looks like I cited RFC1035 twice; I'll
fix that.)

> isatap.com fqdn, which makes the count wrong.

Good catch; I'll fix this.

> Why is this an informational draft?

No particular reason; should I try for PS?

Thanks - Fred
[email-masked]

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Nov 2009 12:45:08 -0500

> ISATAP client then resolves the FQDN itself by consulting

That makes sense.  You might want to mention it in the draft... :')

However, I will reiterate that the DHCP server configuration never changes if you just put FQDNs in the configuration and let the DHCP server resolve them.   The ISC server resolves them synchronously and caches them for an hour; the Nominum server resolves them asynchronously and assumes that you have a fast local DNS cache, so it doesn't cache them internally at all.   I don't know what other DNS servers do specifically, but my understanding is that thebehavior is similar.

So you get the same behavior whether you let the DHCP server resolve the FQDN, or whether you make the ISATAP implementation do it, unless you have really long leases or really short TTLs, neither of which I would expect to be common practice.

So by sending FQDNs it seems like you're setting up an unnecessary wrestling match between two styles of doing things; I would argue that for a DHCP-based implementation, you really ought not to do that, if only because sending FQDNs tends to consume more DHCP packet space, which is a scarce resource.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Nov 2009 12:45:30 -0500

> No particular reason; should I try for PS?

Yes.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Nov 2009 10:13:09 -0800

Hi Ted,

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Tuesday, November 24, 2009 9:45 AM
> To: Templin, Fred L
> Cc: [email-masked]; dhc WG
> Subject: Re: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt
> 
> However, I will reiterate that the DHCP server configuration never changes if you just put FQDNs in
> the configuration and let the DHCP server resolve them.   The ISC server resolves them synchronously
> and caches them for an hour; the Nominum server resolves them asynchronously and assumes that you
> have a fast local DNS cache, so it doesn't cache them internally at all.   I don't know what other
> DNS servers do specifically, but my understanding is that thebehavior is similar.
> 
> So you get the same behavior whether you let the DHCP server resolve the FQDN, or whether you make
> the ISATAP implementation do it, unless you have really long leases or really short TTLs, neither of
> which I would expect to be common practice.
>
> So by sending FQDNs it seems like you're setting up an unnecessary wrestling match between two styles
> of doing things; I would argue that for a DHCP-based implementation, you really ought not to do that,
> if only because sending FQDNs tends to consume more DHCP packet space, which is a scarce resource.

I think I understand what you are saying, but at the same
time it seems like there may be some delicate tradeoffs
involved. For example, wouldn't it be overloading the DHCP
lease lifetime to expect it to also apply to the lifetime
for ISATAP Potential Router List resolution? In other words,
in my understanding the lease lifetime is primarily about
how often one must refresh their IPv4 address delegation
lifetimes - so, shouldn't that be decoupled from how
often one must refresh their DNS FQDN resolutions?

Someone pointed me to "Principles of Internet Host
Configuration" [RFC5505] as a guide to understanding
some of these tradeoffs. Maybe now would be a good time
for me to go off and read that...

Fred

PS We have a tool called "isatapd" that we will soon
   be announcing. It takes as command line arguments
   a list of both IPv4 addresses and FQDNs, and
   constructs the ISATAP Potential Router List as the
   union of all IPv4 addresses. So, it's not very hard
   for app's to deal with an assorted list of items.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Nov 2009 10:14:12 -0800

> Sent: Tuesday, November 24, 2009 9:46 AM
> To: Templin, Fred L

OK; I'll fix that too.

Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Nov 2009 13:33:13 -0500

On Nov 24, 2009, at 1:13 PM, Templin, Fred L wrote:
> In other words,

In the abstract, sure, they should be decoupled.   However, that is not the only value that needs to be considered, and I think if you consider all the values, this one doesn't dominate.   Bear in mind that DNS TTLs don't specify a sharp edge when the data will be refreshed, so you don't get much benefit from relying on the DNS TTL rather than the lease time.   If you want to have a sharp edge, you need a new protocol that leases ISATAP Potential Router List lifetimes.

So given that you don't actually get that sharp edge from the DNS TTL, I just don't think it adds much value to prefer the DNS TTL over the lease time as a lifetime for the Potential Router List.   On a practical level, the network administrator is just going to have to be aware that there is going to be a period after changing the ISATAP router DNS entries when some clients will have the old addresses, and some clients will have the new addresses, and the network infrastructure will have to be configured to work correctly during that changeover period.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Nov 2009 11:25:57 -0800

Hi Ted,

> Sent: Tuesday, November 24, 2009 10:33 AM
> To: Templin, Fred L
> In the abstract, sure, they should be decoupled.   However, that is not the only value that needs to
> be considered, and I think if you consider all the values, this one doesn't dominate.   Bear in mind
> that DNS TTLs don't specify a sharp edge when the data will be refreshed, so you don't get much
> benefit from relying on the DNS TTL rather than the lease time.   If you want to have a sharp edge,
> you need a new protocol that leases ISATAP Potential Router List lifetimes.
> 
> So given that you don't actually get that sharp edge from the DNS TTL, I just don't think it adds
> much value to prefer the DNS TTL over the lease time as a lifetime for the Potential Router List.
> On a practical level, the network administrator is just going to have to be aware that there is going
> to be a period after changing the ISATAP router DNS entries when some clients will have the old
> addresses, and some clients will have the new addresses, and the network infrastructure will have to
> be configured to work correctly during that changeover period.

OK, now memories are coming back to me. It's not that I
want a sharp edge such that ISATAP clients would be
updated immediately upon administrative change actions;
I know that I won't get that in either the DHCP or DNS
cases. But, the reason I want the flexibility of getting
FQDNs is that some ISATAP sites might use a site-specific
name service other than the DNS (e.g., mDNS or LLMNR)
that may not even be accessible to the DHCP server.

In some cases, the DHCP server may be located far away
from the site (e.g., in a backhaul network and reachable
only by a chain of one or several DHCP relays) while
the Potential Router List for the site might be changing
rather dynamically. In such cases, the ISATAP client can
learn a rather static FQDN from the DHCP server (e.g.,
isatap.example.com) then give an mDNS/LLMNR shout-out
to discover the list of ISATAP routers in the site. In
highly-dynamic networks, the list may change rather
frequently such that the ISATAP clients (and not the
DHCP server) are in the best position to do the name
resolution.

Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Nov 2009 16:11:47 -0500

On Nov 24, 2009, at 2:25 PM, Templin, Fred L wrote:
> But, the reason I want the flexibility of getting

Bizarre.   But sure, okay, that's a good reason.   :')