Subject: (ngtrans) Clarification of ISATAP Router Discovery issues

From: "Fred L. Templin" <[email-masked]>
Date: Sat, 15 Dec 2001 06:53:53 -0800 (PST)

Hello,

I would like to clarify some points that I made regarding ISATAP router
discovery during my presentation at the 12/13/01 IETF 52 NGTRANS session.
These points were either not covered in sufficient detail due to time
constrains or drew questions that indicated the need for further
discussion on the list. I will be away from e-mail until Dec. 19th,
but I welcome discussion from the group on these topics which I will
rejoin as soon as I return:

Fred Templin
[email-masked]

1. Means for finding an IPv4 address for ISATAP router discovery
****************************************************************
In the current draft version (draft-ietf-ngtrans-isatap-02.txt),
"DNS Well-Known Service Name" and "IPv4 Anycast for ISATAP Routers"
are presented as "two alternative methods for discovering V4ADDR_RTR".
The current text implies that an IANA-assigned "IPv4 anycast address"
would provide *different* functionality than an ordinary IPv4 address.
But, as I pointed out in my talk, "IPv4 anycast" is in reality a
*configuration option* which some sites may wish to employ while others
may not. Therefore, the means for finding an IPv4 address for ISATAP
router discovery is *independent* of a site's decision to deploy an
IPv4 anycast configuration. Thus, the term "ISATAP router anycast
address" used in the draft is misleading. I propose that a different
term (e.g. "ISATAP Service Address") be used, but welcome other
suggestions. I will refer to this term as "V4ADDR_ISATAP"
throughout the rest of this discussion.

Regarding a means for discovering V4ADDR_ISATAP, my presentation
suggested an IANA-assigned address as default - but the default could
be overriden by DNS. Hesham Soliman and Dave Thaler gave input on this
after the talk. Based on their input, I propose the following pseudo-code
for assigning V4ADDR_ISATAP (feedback is welcomed):

 if (V4ADDR_ISATAP manually configured on ISATAP interface)
    (a) use the manually configured address
 else
    if (name service lookup for V4ADDR_ISATAP succeeds)
      (b) use the address returned by name service lookup
    else
      (c) use the IANA-assigned address for V4ADDR_ISATAP

  Rationale:
  (a) "manual override" option; receives highest priority
  (b) site name service lookup (DNS, /etc/hosts file, etc) next priority
  (c) IANA-assigned address is last-resort

As I stated in the talk, the question of whether (c) is actually needed
still remains. I see an IANA-assigned address as being helpful from two
perspectives:

 - it allows minimal configuration deployment for sites that are able
   to advertise a route to the IANA-assigned prefix internally
 - it provides a "last resort" if V4ADDR_ISATAP is not discovered via
   (a) or (b)

I invite further input from the community on this topic.

2. Addresses used in ISATAP Router Solicitations and Router Advertisments
*************************************************************************
My presentation slides proposed IPv6 and IPv4 addresses to use for RSs
and RAs. (Francis Dupont correctly pointed out an error in the 'v4_src'
address for RAs.) I offer now more detail:

  An ISATAP host sends Router solicitations with:
    v6_src=FE80::0:5EFE:V4ADDR_HOST
    v6_dst=FF02::2
    v4_src=V4ADDR_HOST
    v4_dst=V4ADDR_ISATAP
  
  An ISATAP router sends solicited Router Advertisments with:
    v6_src=FE80::0:5EFE:V4ADDR_RTR
    v6_dst=FF02::2
    v4_src=V4ADDR_ISATAP
    v4_dst=V4ADDR_HOST

  where:
  V4ADDR_HOST:   an IPv4 address assigned to a physical link to which
                 the host's ISATAP interface attaches.
  V4ADDR_ISATAP: defined as in 1. above
  V4ADDR_RTR:    the IPv4 address of an ISATAP router. 'V4ADDR_RTR' MAY
                 be equal to 'V4ADDR_ISATAP', but *need not be*.

Francis Dupont asked why V4ADDR_ISATAP and V4ADDR_RTR might be
different.  I offer the following rationale, and invite further
discussion:

 - if V4ADDR_RTR == V4ADDR_ISATAP always, then an IPv4 anycast
   configuration is the *only* means for a site to provide load
   balancing and a path to the closest ISATAP router. This might
   not be an option for some sites.

 - if V4ADDR_RTR is allowed to be different than V4ADDR_ISATAP, then
   mechanisms described in RFC 2461 are supported with little/no
   modification. In particular, Redirects may be used in their native
   fashion to redirect a client to a better ISATAP router. IPv4
   anycast configurations are still supported, but other means for
   load balancing and discovering the closest ISATAP router are
   enabled. For example, a single node with V4ADDR_ISATAP configured
   could act as a redirector to the closest ISATAP router determined,
   for example, by analyzing the path back to the ISATAP host.

It is important to note that a *trust relationship* is required for
hosts receiving solicited RAs (*). I claim that the trust relationship
is satisfied IFF v4_src=V4ADDR_ISATAP in received RAs (discussion welcome).
Therefore, sufficient trust is established if v4_src=V4ADDR_ISATAP even
if V4ADDR_RTR != V4ADDR_ISATAP.

(*) This trust relationship is predicated on responsible site IPv4
    administration; in particular, ip-protocol-41 packets with either
    ip_src or ip_dst == V4ADDR_ISATAP SHOULD be filtered at the site's
    border

3. Router Solicitation Interval
*******************************
ISATAP treats the IPv4 site as an NBMA link layer that supports a
very limited multicast capability. In fact, the *only* multicast
capability enabled is that described in 2. above (i.e. RSs sent to
the "all-routers-multicast" address are automatically tunneled to
V4ADDR_ISATAP.) Therefore, ISATAP hosts will *not* receive unsolicited
Router Advertisments from ISATAP routers. This implies that ISATAP
hosts must send RSs to ISATAP routers periodically. But, this must
be reconciled with section 6.3.7 of RFC 2461, which states:

> Router Solicitations may be sent after any of the following events:
> 
>       - The interface is initialized at system startup time.
> 
>       - The interface is reinitialized after a temporary interface
>         failure or after being temporarily disabled by system
>         management.
> 
>       - The system changes from being a router to being a host, by
>         having its IP forwarding capability turned off by system
>         management.
> 
>       - The host attaches to a link for the first time.
> 
>       - The host re-attaches to a link after being detached for some
>         time.

When a host's ISATAP interface is initialized, it is permitted to send
RSs by the first criterion in the above list. However, there would
appear to be *no* criterion that allows for subsequent RSs after
initialization. I offer the following rationale for ISATAP hosts:

 - following initialization (i.e. solicited RAs are received), the
   host *deems it's ISATAP interface to be "detached" from the link*
   for the purpose of receiving unsolicited RAs. (Unicast messages
   MAY still be sent and received while the ISATAP interface is
   so "detached")

 - the host sets a variable MinDetachTime = (Router Lifetime * .5)
   where "Router Lifetime" is the most recently received (non-zero)
   Router Lifetime in a solicited RA. This variable is used to set
   an expiration timer.

 - at a random delay after 'MinDetachTime' expires, the host "re-attaches
   its ISATAP interface to the link after having been detached for some
   time". Thus, the final criterion in section 6.3.7 for sending RSs
   is met.

 - RSs are sent in accordance with section 6.3.7 of RFC 2461 whenever
   a host initializes an ISATAP interface for the first time or re-attaches
   its interface, i.e. the following introductory text from that section
   always applies:

     "When an interface becomes enabled, a host may be unwilling to wait
     for the next unsolicited Router Advertisement to locate default
     routers or learn prefixes.  To obtain Router Advertisements quickly,
     a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
     Solicitation messages each separated by at least
     RTR_SOLICITATION_INTERVAL seconds."

Note that this is not intended as an arbitrary abuse of the language of
RFC 2461. Justification lies in the fact that an ISATAP host KNOWS that
it will not receive unsolicited RAs due to the NBMA nature of ISATAP,
therefore it MUST re-issue RSs else it's prefixes will expire. Does the
group feel that the above language is acceptable, or must other measures
be taken to meet the requirements of RFC 2461?

Finally, the MinDetachTime = (Router Lifetime * .5) would seem to provide
the following desirable features:

  - Router Lifetimes will be refreshed before expiring

  - ISATAP router faults will be detected after a "reasonably" short
    delay

  - RS traffic will be kept to a minimum

It seems that 'MinDetachTime' being proportional to the most recently
received Router Lifetime is the right choice. But the choice of the
constant value of '.5' is open for discussion.

---

From: "Fred L. Templin" <[email-masked]>
Date: Sat, 15 Dec 2001 07:03:22 -0800 (PST)

Should be changed to read:

>     v6_dst=FE80::0:5EFE:V4ADDR_HOST
>     v4_src=V4ADDR_ISATAP
>     v4_dst=V4ADDR_HOST

Fred
[email-masked]