Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:[email protected]] > Sent: Tuesday, November 24, 2009 9:45 AM > To: Templin, Fred L > Cc: [email protected]; dhc WG > Subject: Re: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt > > On Nov 24, 2009, at 12:21 PM, Templin, Fred L wrote: > > 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. > > 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.
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 [email protected] 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. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
