Re: draft-ietf-ngtrans-isatap-21.txt

[Markku Savela <msa@burp.tkv.asdf.org>]

> From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
> 
> I on the other hand think that address resolution on Isatap interfaces
> in general should be a two step procedure consisting of
> address resolution performed by static computation followed by
> a unicast NS/NA exchange confirming reachability of the Ipv6 peer IPv6.

I was hoping that the ISATAP interface would look like standard IPv6
interface to the stack. The above procedure is not what stack would do
on any interface. The currently defined choices for "standard" IPv6
interfaces are:

  1) Point-to-point (no addresses on the link)

  2) "Ethernet type", link layer addresses, RFC2461 style neighbor
     discovery (which relies on multicast).

> 
> > A corollary to above is: ISATAP IPv6 "nexthop address" is always based
> > on one of the PRL addresses.
> > 
> 
> Why ?

Because, by my conclusion that you cannot run neighbor discovery on
the ISATAP link, the only known addresses associated with the
interface would be the ISATAP routers from PRL. There is no "standard"
process that would bring anything else into NC.

Actually, I would question, what use would there be for any other
addresses? The node can communicate with all potential "neigbors"
directly using normal IPv4. It needs ISATAP only to talk with
non-neighbor IPv6 destinations, for which the next-hop is the ISATAP
router.