From: Bob Fink (fink_at_no.spam)
Date: Wed Nov 28 2001 - 18:09:20 PST
Fred,
Thanks for outlining the issues for ISATAP. As such it is a good model for
how we should proceed with business in ngtrans, i.e., getting the
discussion going on the mail list before the IETF.
We will certainly be prepared to have ISATAP on the Salt Lake City agenda
to cover issues raised and not resolved here on the list.
Thanks,
Bob
===
At 05:31 PM 11/28/2001 -0800, Fred L. Templin wrote:
>Hello,
>
>I would like to report status and solicit discussion on open issues
>regarding ISATAP (draft-ietf-ngtrans-isatap-01.txt). Issues include those
>raised at IETF 51, issues reported via private e-mails since IETF 51, and
>issues identified by the author and his colleagues while developing an ISATAP
>implementation for Linux (see also my next ngtrans mailing entitled: "Linux
>ISATAP implementation".) Portions of Bob Fink's IETF 51 meeting minutes
>relating to ISATAP are attached at the bottom of this message for reference.
>The full set of IETF 51 NGTRANS meeting minutes are available at:
>
> http://www.6bone.net/ngtrans/minutes/IETF51-London.html
>
>I am currently in the process of producing a revised version of the draft
>to clear up some outstanding issues and incorporate a number of comments
>received from individuals since IETF 51. I also plan to incorporate comments
>resulting from any discussions on this list relative to the open issues
>which appear below:
>
>Fred Templin
>templin-at-erg.sri.com
>
>Open issues:
>************
>1) Clear definitions for "ISATAP link" and "Native link" needed:
>
>The current draft uses the terms "on-link" and "off-link" in ways that
>may lead a reader to ask "[on,off]-link with respect to WHAT?". Comments
>received since IETF 51 have suggested new definitions and language to clear
>up this confusion.
>
>2) Automatic discovery of ISATAP routers
>
>Comments on the draft received since IETF 51 indicate that section 5 currently
>intertwines the discussion of (at least) two different topics which should be
>more clearly delineated. Section 5 of the draft will be re-organized to
>clearly
>seperate the following sub-topics:
>
> - Discovering the IPv4 address of an ISATAP router
> - ISATAP Router Solicitation and Prefix Discovery
>
>3) Discovering the IPv4 address of an ISATAP router
>
>The draft currently suggests two different methods for discovering the IPv4
>address for an ISATAP router: a DNS well-known service name or an IPv4 anycast
>address. A third method would include static configuration. In essence, each
>method would provide the *same* information; an IPv4 address to be used as the
>IPv4 destination address to which clients send unicast Router Soliciatation
>messages (see ISATAP Router Discovery below). The draft should be updated to
>more authoritatively specify the preferred method or methods. Items for
>further
>consideration include the following, and I invite discussion on these:
>
> - Using a DNS well-known service name allows multiple IPv4 addresses in the
> DNS resource records for potential use in load balancing. Also, different
> DNS servers could provide different IPv4 addresses in name resolutions to
> provide a means for ISATAP cleints to discover the IPv4 address of the
> topologically closest ISATAP router. (This method is NOT guaranteed to
> provide the true closest ISATAP router, however.)
>
> - Using an IPv4 anycast address (i.e. an IANA-registered IPv4 prefix and
> a specific address belonging to that prefix) would allow implementations
> to hard-code a single IPv4 address and provide zero-configuration
> operation,
> since DNS resource record configuration is avoided
>
> - Whatever the method for discovering the IPv4 address, the IPv4 anycast
> capability is enabled ONLY by virtue of the administrative configuration
> of one or more ISATAP routers within the site that each assign the *same*
> IPv4 address to a physical link and (presumably) each advertise the *same*
> IPv4 prefix to the site. Thus, the IPv4 anycast capability is largely
> independent of the method for discovering the IPv4 address used for
> anycast
> (i.e. DNS name, IANA assignment, static configuration). Therefore the
> method
> for discovering an IPv4 address should be clearly seperated from
> discussion
> of the IPv4 anycast capability in the draft. In my opinion, the IPv4
> anycast
> capability should be advocated in all cases, since it allows discovery of
> the true closest ISATAP router.
>
>Questions to the group regarding the above:
>
> - Do we need an IANA IPv4 prefix registration for ISATAP?
> - Can ISATAP make use of some pre-existing IANA IPv4 prefix registration?
>
>4) ISATAP Router Solicitation and Prefix Discovery
>
>Since the site's IPv4 infrastructure is essentially treated as an NBMA
>link, ISATAP clients must periodically poll ISATAP routers (as opposed
>to ISATAP routers periodically sending beacons as described in RFC 2461
>and RFC 2462.) Several aspects of this polling process must be more clearly
>defined in the document. Again, discussion is invited with regards to these
>items:
>
> - The document needs to clearly state where the mechanisms used for ISATAP
> are identical to and where they depart from those specified in RFC 2461
> and RFC 2462
>
> - The polling interval should be proportional to prefix lifetimes received
> in Router Advertisements. A polling interval that is too long may allow
> prefixes to prematurely expire, while a polling interval that is too short
> could lead to traffic scaling issues. Aspects of selecting the polling
> interval must be more throroughly discussed in the document. Additionally,
> a small section discussing scaling considerations for polling interval
> selection should be added.
>
> - IPv6 prefix discovery methods for normal links allow multiple prefixes
> to be discovered and auto-configured on interfaces. ISATAP should be
> no different in this regard.
>
>5) Automatic deprecation of ISATAP interface
>
>Section 8 of the draft currently states:
>
> After the node's native IPv6 address is populated in the DNS, the node
> should eventually cease sending Rtsol's to the ISATAP router and
> discontinue
> use of its ISATAP pseudo-interface. In this way, ISATAP addresses will
> gradually (and automatically) disappear as IPv6 routers are widely
> deployed within sites.
>
>It has been pointed out that there may be reasons for nodes to continue
>to use an ISATAP link even after a native IPv6 link becomes available, thus
>the "should" in the above section is not appropriate. A better understanding
>of when it is acceptable for a node to discontinue use of its ISATAP link is
>required, and discussion of this subject is invited.
>
>6) Security considerations
>
>The security considerations section of the draft currently states:
>
> Additional security issues are called out in [6TO4] and probably
> apply here as well.
>
>This text will be replaced with text describing security considerations
>specific to ISATAP. The following items are currently under consideration
>and open for discussion within this forum:
>
> a. ISATAP IPv4 Anycast address filtering at border routers:
> Sites should configure filtering rules to disallow IPv4 packets which
> have the ISATAP IPv4 anycast address as either the v4_src or v4_dst from
> crossing the site's border routers. Otherwise, ISATAP clients may
> discover
> off-site ISATAP routers and/or ISATAP routers may respond to Router
> Solicitations from off-site clients
>
> b. Source address spoofing checks:
> For packets received on an ISATAP link, receivers should verify that the
> source address in the encapsulating IPv4 header is that of a node that is
> on-link with respect to the receiver's ISATAP interface. On-link nodes
> include other ISATAP nodes and any ISATAP router(s) with which the
> receiver
> has affiliated via ISATAP Router Solicitation and Prefix Discovery.
>
> In the case of packets originating from other ISATAP nodes that are
> on-link
> with the receiver's ISATAP interface, the IPv6 source address must be in
> ISATAP format (since the source is also using ISATAP), and the IPv4
> address
> embedded in the ISATAP address must match the IPv4 source address in the
> encapsulating IPv4 header.
>
> In the case of packets originating from an on-link ISATAP router, the
> source address in the encapsulating IPv4 header must be that of an
> on-link
> ISATAP router, and the IPv6 source address may be any IPv6 globally
> aggregatable unicast. The source address of an on-link ISATAP router
> is available in the unicast Router Advertisements sent by the router
> and may be cached for subsequent source address spoofing checks.
>
> Similar considerations for source address spoofing were presented in a
> thread of discussion initiated by Pekka Savola on 08/28/01 on the NGTRANS
> mailing list entitled: "practical 6to4 security rulesets". This thread
> indicated the possibility of a draft discussing security considerations.
> Such a draft could provide an appropriate venue for more detailed
> discussion
> of ISATAP security rulesets as well.
>
> c. Receiving link-local packets on ISATAP links:
> ISATAP treats the site's entire IPv4 infrastructure as an NBMA link.
> The draft currently specified link-local address autoconfiguration for
> the purpose of ISATAP router solicitation and prefix discovery only.
> Questions:
>
> - Should link-local addressing be expanded to allow for peer-peer
> communications between nodes that share and ISATAP link?
>
> - If so, are any filtering rules required at the site's border
> routers to disallow link-local ISATAP packets coming from
> off-site?
>
>*** end of open issues ***
>
>
>
>ISATAP IETF 51 meeting minutes:
>*******************************
>===
>ISATAP Issues - Fred Templin
><http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>
>
>SLIDES:
><http://www.6bone.net/ngtrans/IETF-51-London/isatap.ppt>
><http://www.6bone.net/ngtrans/IETF-51-London/isatap.pdf>
>
>Fred gave a brief overview of ISATAP, then listed the changes in ISATAP
>since IETF-50 (that were
>reported at the Interim in Seattle).
>
>• Name changed to ISATAP
>• Added "Terminology" section
>• Require ISATAP/non-ISATAP addresses use different /64 prefixes
>simplifies sending rules
>• Changed u/l bit in EUI-64 interface ID to indicate LOCAL scope
>
>He then describe developments since the interim meeting:
>
>• Linux implementation by Nathan Lutchansky:
> works with all kernel versions 2.2.16 2.4.6 (with/without USAGI)
> testing with stateful configuration complete
> multiple interface support (anticipated configuration scenario for NAT)
> code for stateless auto-configuration complete; testing begins after IETF51
> Stay tuned for code release announcements (TBD with Nathan)
>
>Fred concluded with open issues since the interim meeting:
>
>• When to deprecate ISATAP address?
> Old answer: when native IPv6 Rtadv's heard
> New answer: when native Rtadv's heard AND ISATAP interface usage drops
>below some threshold
> Not conclusive; more study needed
>
>• Will ISATAP addresses be preferred over native IPv6 addresses by longest
>prefix-match?
> No destination ordering will fix this (already addressed in
>source/destination selection draft)
>
>• Will ISATAP present any new security issues? (question from private e-mail)
> IPv6 source address spoofing seems like biggest issue
> Nearly finished enumerating cases; spoofing easy to detect in all cases
>examined thus far
> Claim: ISATAP secure IFF site's IPv4 network secure
> Will send analysis to mailing list when complete
>
>• Current draft expires 17 November 2001; new draft coming soon
>
>Steve D asked what supporting multiple i/f means. Fred said two virtual
>i/f might be used, i.e., two
>locales in one site.
>
>Alain asked why use it across two domains. Fred said you don't use on
>public address side, rather
>when NATs involved.
>
>Christian noted that it is used for partially converted sites where you
>don't use 6to4.
>
>Brian Zill asked if Nathan's Linux version inter-operates w/Windows yet.
>Fred said he had not tried
>that yet.
>
>===
>ISATAP Router Discovery - Dave Thaler
><http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>
>
>SLIDES:
><http://www.6bone.net/ngtrans/IETF-51-London/isatap-rtrdisc.ppt>
><http://www.6bone.net/ngtrans/IETF-51-London/isatap-rtrdisc.pdf>
>
>Problem Summary
>• ISATAP makes IPv4 site look like one NBMA link
>• Normal router discovery relies on multicast
>• Observation:
> Once you know the address of a router, you can unicast an RS and get a
>unicast RA
>• So how do you discover the address of a router?
>
>Robustness of RA's
>• Normally RAs are periodically multicast
>• If no RAs known (e.g., routers down)
> Send RSs at low frequency, say 15 mins
> Tradeoff between overhead and timeliness
> Should be a temporary condition
>• If RA known
> Send RS after half of lowest lifetime in RA, to a minimum of the low
>frequency value above
> Minimum intended to prevent overhead during renumbering
>
>Several choices were briefly covered with pros and cons: SLP, DHCPv4,
>well-known host name, SRV
>record lookup, well-known IPv4 anycast address, and hybrid
>approaches.
>
>Steve Deering queried that if RA is just one example of mcast, and given
>that we need to support
>NBMA links, why is RA specially handled? Dave responded
>that we need to know router ahead of time.
>Steve asked again, but why special case RA? Dave noted that it is stateless.
>
>Someone asked if he had onsidered using MARS. Dave replied yes, but that
>it is too complex and we
>only need something until native v6 connectivity occurs,
>not another special (and costly) service
>
>Alain asked about the randomization time choice? Dave replied he needs to
>add it (and it will be 15
>mins).
>
>Alain stated that if using well known router name, he doesn't like
>unqualified (short) names as
>going thru resolver it might end up outside of domain, and
>is vulnerable to DoS attacks.
>
>Fred noted that one could use different DNS responses to establish locality.
>
>Someone asked if anycast is in use. Dave noted it is widely used in v4
>today. It's just a host route
>Tony Hain noted.
>
>Dave asked if there is a preference for a given solution:
>
>Jim B, liked anycast but disagreed that v4 anycast is in wide use, and
>needs to be tested very
>thoroughly for v6 before it is specified/used.
>
>Alain noted that as ISATAP is a transition mechanism, it is temporary,
>thus easy to do is best, and
>not a hybrid; he wants to choose just one simple to
>implement approach.
>
>Dave thinks the well known host name is easiest. Alain thinks anycast is
>as easy. Dave agreed.
>
>Erik Nordmark asked if we want to discover one or more routers. Dave
>replied that this is something
>to think about.
>
>Tony cutoff the question queue due to time. He noted that the topic should
>be taken to the list. He
>encouraged everyone to actively participate in this
>discussion online.
This archive was generated by hypermail 2.1.7 : Fri Oct 06 2006 - 00:00:26 PDT