Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:[email protected]] > Sent: Tuesday, November 24, 2009 10:33 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 1:13 PM, Templin, Fred L wrote: > > 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? > > 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 [email protected] _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
