Subject: Re: (ngtrans) Clarification of ISATAP Router Discovery issues

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 18 Jan 2002 15:18:34 -0500

Fred

I finally found the time to re-review this spec and the updated proposal
and have a few questions.

"Fred L. Templin" wrote:
> 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

I am actually a bit surprised as to why, in the Router Advertisement, the
'vs4_src'
and the V4ADDR part of 'v6_src' are different?

It looks like by your "trust relationship" you are saying that the source
address
spoofing checks do not need to be applied if the encapsulating (v4) source
address
is V4ADDR_ISATAP.  Is that right?

> 
> 3. Router Solicitation Interval
> *******************************
...
> 
> 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.

In this section I not sure if using only the Router Lifetime is the right way.
I think that using the minimum no-zero value of a set of {Router Lifetime,
Prefix
Preferred Lifetime, and Prefix Valid Lifetime} would provide greated
flexibility. 

This would allow the router to cause a switch to native IPv6 (when ready),
by modifying the lifetime values on the ISATAP interface and prefix.  The
default
route may be removed and the prefix depricated using the standard timers and
the node would just switch to using native IPv6.

As for the minimum retransmit factor of 0.5, that sounds reasonable to me.

-vlad

++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 18 Jan 2002 12:42:13 -0800

Hi Vlad,

> and the V4ADDR part of 'v6_src' are different?

I don't have much more rationale to add on this other than what I have
already offered in the original text quoted above. Note that I'm saying
the link layer (IPv4) source address MAY be different than the IPv4 address
embedded in the network layer (IPv6) source address - but, it *need not* be
different and very often the two IPv4 addresses will be the same.
 
> is V4ADDR_ISATAP.  Is that right?

Yes - V4ADDR_ISATAP is an IPv4 address that is discovered by a means
specified in the draft. (I'd rather not get into the details of what
I mean by "discovered", because a new draft is due out soon that MAY
have something different to say than what is in the current draft.)
Reasons for trusting V4ADDR_ISATAP are:

 - strong assumption that the site admistrator has published V4ADDR_ISATAP
   because he deems it to be the IPv4 address of a trusted ISATAP router
 - weak assumption that the site has configured anti-spoofing firewall
   filter rules
   
> the node would just switch to using native IPv6.

The points you raise here are under active consideration by myself and
a group of colleagues. I'll forward your message to my colleagues and
discuss with them whether your ideas confirm, dispel, or augment our
current line of thinking. 
 
> As for the minimum retransmit factor of 0.5, that sounds reasonable to me.

Thanks for the comments,

Fred
[email-masked]