ISATAP draftietfngtransisatap03'txt

1
ISATAP(draft-ietf-ngtrans-isatap-03.txt)

• IETF 53 NGTRANS Meeting
• Minneapolis, MN - March 18, 2001
• Fred L. Templin SRI International
• Tim Gleeson - Cisco Systems K.K.
• Mohit Talwar - Microsoft Corporation
• Dave Thaler - Microsoft Corporation

2
Changes Since 02.txt

• Collaborative work of four co-authors
• Closer alignment with RFCs 2461, 2893
• New data structure Potential Router List (PRL)
• Two separate (but related) periodic processes
• PRL maintenance
• ISATAP router polling

3
TODO for 04.txt

• WKS RRs NOT USED for ISATAP (Remove text
  referring to DNS Well-Known Service)
• Several community suggestions for wording
  clarifications
• MAY vs. SHOULD discontinue router polling
  process when RAs acquired on native link
  (SHOULD proposed on list authors agree)

4
On Using a Name Service for Router Discovery

• ISATAP hosts deployed independently of routers
• PRL provides trust basis (cant use RFC 2461
  on-link test)
• PRL initially empty IPv4 addresses learned
  through name service lookups for ISATAP (or
  manual config.)
• Name service presumably managed by responsible
  authority for site - implies
• site manager aware of ISATAP router deployment
• site manager responsible for ip-proto-41
  filtering

5
On Registering the Name ISATAP

• IANA Protocol and Service Names registry not
  current
• RFC 2078, 2609 have references, but no
  registrations
• RFC 952 out of date
• RFC 2219 (Use of DNS Aliases for Network
  Services) Section 2 - new protocols must
  propose their own names
• Authors favor BCP example of RFC 2219 (i.e.,
  specify ISATAP directly in draft)

6
On Not Reserving an IPv4 Anycast Address with IANA

• spec already allows IPv4 anycast deployments
  as-written, (but RFC 2373 disallows IPv6 anycast
  as source address)
• IANA-reserved IPv4 anycast address would simply
  be a pre-loaded address in the PRL
• pre-loading PRL circumvents site-manager-in-the-l
  oop