1. DNS Discovery Discussion draft-ietf-ipngwg-dns-discovery-00.txt
Dave Thaler
Microsoft
San Diego IPNGWG meeting

2. San Diego IPNGWG meeting
Problem
Enable name resolution in an environment with no DHCP server.
Use DNS, or mDNS if no DNS server
Need to know:
1 or more DNS server addresses
Domain name
Domain search path
San Diego IPNGWG meeting

3. San Diego IPNGWG meeting
Discussion Team
Bernard Aboba (Microsoft), Jim Bound (Compaq),
Steve Deering (Cisco), Erik Guttman (Sun),
Itojun Hagino (IIJ), Bob Hinden (Nokia),
Tatuya Jinmei (Toshiba), Atsushi Onoe (Sony),
Hesham Soliman (Ericsson), Dave Thaler (Microsoft)
Many 2-hour teleconference calls since Pittsburgh
San Diego IPNGWG meeting

4. San Diego IPNGWG meeting
Scope of Discussion
Only discover information within the local site.
However, there may be a relay at a site boundary. For example, in the home, to discover DNS servers in the ISP.
Goal of team:
Provide analysis, and ideally recommendation, as input to the WG
San Diego IPNGWG meeting

5. San Diego IPNGWG meeting
Taxonomy
Transport Mechanism:
How do discovery messages get from devices to servers?
Content Mechanism
What’s the format of the discovery messages?
San Diego IPNGWG meeting

6. San Diego IPNGWG meeting
Evaluation Criteria
Scalability: huge number of devices?
Security: what is auth mechanism? Key distribution?
Time to deploy: deployable now? What devices need upgrades vs. configuration?
Business motivation: do implementors/ deployers have an incentive over other options?
San Diego IPNGWG meeting

7. Evaluation Criteria (cont.)
Standardization: what else would have to be standardized? By which WG?
Fate sharing: does it introduce new dependencies on other protocols or devices that aren’t required for name resolution?
Convergence time: what if router, link, or DNS server fails?
Scenarios: does it work in difficult scenarios?
Isolated link with a DNS server but no routers
Site without multicast routing
NBMA links
San Diego IPNGWG meeting

8. Anycast for DNS server discovery only
Send some (non-TCP) query message to “nearest” DNS server
DNS server unicasts response with server list, domain name, search path
Pros:
No new dependencies
Deployable now
Cons:
“Limited” deployment scenarios w/o new protocol work
Have to manage server list on all DNS servers
San Diego IPNGWG meeting

9. Anycast for name resolution
Just send UDP to DNS server anycast address to resolve names
Pros:
No new dependencies
Already tried (but w/o domain name or search path)
Trivial to obtain & maintain “server list”
Cons:
Slower convergence time on server failure
Have to use another mechanism to get domain name & search path anyway
“Limited” deployment scenarios w/o new protocol work
San Diego IPNGWG meeting

10. Anycast deployment scenarios
Issue is how to securely inject anycast host route
Run DNS servers on routers
Run routing daemons on DNS servers to talk to routers
Run multiple servers on same link, configure servers’ routers with static route
Upgrade servers’ routers to advertise route based on ND responses for anycast address
Develop a real host-router anycast group joining protocol (e.g., use MLD)
San Diego IPNGWG meeting

11. Link-scoped multicast
With router-only responses (e.g. RAs)
Pro:
Easy to code and deploy
Cons:
Either: Management overhead of maintaining server list on all routers, or have to do one of the other mechanisms on the back end anyway
Doesn’t support “isolated link link with a DNS server but no routers”
With router assist, similar to DHCP relay idea
Can support isolated links
Con:
San Diego IPNGWG meeting

12. Site-scoped multicast
Send a query to all DNS servers
Each DNS server replies
Pro:
Managing “DNS server list” is simple
Con:
Requires multicast routing protocols to be present & enabled
San Diego IPNGWG meeting

13. San Diego IPNGWG meeting
Hybrid
Could have one mechanism by default, with the ability to specify another
For example: site-scoped multicast, with RA option to specify another address
Pro:
Can easily migrate to better solutions
Con:
Clients must be able to handle multiple destination address types
San Diego IPNGWG meeting

14. San Diego IPNGWG meeting
Transport Summary
|Any(Disc)|Any(Res)|LnkM(Rtr)|LnkM(Gen)|SiteM
SW upgrades |-/S/SR |-/S/SR |R |R |UR
Reconfig changes |S | |R |S |-
New dependencies | | |router, |linkmcast|multicast
| | |linkmcast| |routing,
| | | | |linkmcast
Convergence time |fast |per-rtg |fast |fast |fast
Can use IKE |no |no |no |no |no
Standards work |-/ipngwg |-/ipngwg|ipngwg |ipngwg |-
Deployable "now" |yes |yes |no |no |no
San Diego IPNGWG meeting

15. San Diego IPNGWG meeting
Team Preferences
|Any(Disc)|Any(Res)|LnkM(Rtr)|LnkM(Gen)|SiteM
Pittsburgh| | |
Nov | | | | | 3
Recount | | | | | 18
San Diego IPNGWG meeting

16. San Diego IPNGWG meeting
DHCP
DNS server functions as a mini-DHCPv6 server for DNS options only
Options for DNS server list, domain name, search path already defined
San Diego IPNGWG meeting

17. San Diego IPNGWG meeting
DNS
Simple heuristic possible using only NS and A* records
Optimizations could be done using SRV records or a new RR
Pros:
Devices already need a DNS parser anyway
DNS Servers already listening to DNS requests (best fate sharing)
Key dist mechanism included (DNSSEC)
Requires no new code beyond the new rules in clients
Cons:
Uses 2 round trips (without standardizing new record usage)
Optimizations under control of DNSEXT WG
San Diego IPNGWG meeting

18. Node Information Query
Define new Qtypes for DNS server list, domain name, search path
However, source of a NIQ would be querying for information about itself (or the site in general) rather than information about the destination node in particular
San Diego IPNGWG meeting

19. San Diego IPNGWG meeting
RA Extensions
Define new RA option(s) to hold DNS server list, domain name, & search path
Pros:
Simple to deploy
Devices already need RA parsers anyway
Cons:
Requires upgrading all routers
Either: Reconfigure all routers when server list changes, or use some protocol mechanism
Doesn’t support “isolated link link with a DNS server but no routers”
San Diego IPNGWG meeting

20. San Diego IPNGWG meeting
SLP
DNS is a service, domain name & search path are attributes
SLP as a protocol uses site-scoped multicast
Pros:
General, standards-track mechanism
Cons:
“New” parser in devices
Either modify the protocol to use other transport mechanism, or depend on multicast routing protocols
San Diego IPNGWG meeting

21. San Diego IPNGWG meeting
Something new
HTTP, SNMP, etc.
Pro:
Could at least confine work to IPNG WG
Con:
No perceived advantage over other mechanisms
San Diego IPNGWG meeting

22. San Diego IPNGWG meeting
Content Summary
|DHCP |DNS |NIQ |RA |SLP
Round trips used | |2/ | | |1
Has own signatures|yes |yes | | |yes
Has own key dist | |yes | | |-
Standards work |dhc |-/dnsext |ipngwg |ipngwg |svrloc
Need addl parser |in servers| |yes | |yes
Generalizable |yes |yes |yes | |yes
Deployable "now" |no |yes |no |no |no
San Diego IPNGWG meeting

23. San Diego IPNGWG meeting
Team Preferences
| DHCP | DNS | NIQ | RA | SLP
Pittsburgh | | | | |
Nov | | | | | 4
Recount | | | | | 27
San Diego IPNGWG meeting