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

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

On Isatap interfaces the purpose of the NC isn't to maintain mappings of
Neighbor Ipv6 addresses (which are always Isatap addresses) 
to link-layer addresses, since that is indeed achieved
by static computation from the interface identifier part of the neighbors Isatap Address.

The purpose of the NC on Isatap interface, in my understanding of the draft, is
to maintain reachability information used for NUD.

> -----Original Message-----
> From: Markku Savela [mailto:msa@burp.tkv.asdf.org]
> Sent: 20. april 2004 17:11
> To: Karen E. Nielsen (AH/TED)
> Cc: ftemplin@iprg.nokia.com; v6ops@ops.ietf.org; 
> dthaler@microsoft.com;
> mohitt@microsoft.com; tgleeson@cisco.com
> Subject: Re: draft-ietf-ngtrans-isatap-21.txt
> 
> 
> 
> I've some problem with section 8:
> 
>   ...
>   8. Neighbor Discovery for ISATAP Interfaces
> 
>    ISATAP nodes use the neighbor discovery mechanisms specified in
>    [RFC2461] to create/change neighbor cache entries. ISATAP 
> interfaces
>    also implement the following specifications:
>   ...
> 
> I don't see how a neighbor cache entries would get created. You cannot
> run normal RFC2461 neighbor discovery on ISATAP interface to detect
> link layer addresses: ISATAP interface does not support multicast!
> 
> I think all references to neighbor cache could be removed (there is no
> need for link layer addresses). Like, in section 8.4
> 
>   ...
>   8.4 Address Resolution
> 
>    The specification in ([RFC2461], section 7.2) is used. ISATAP
>    addresses for which the neighbor's link-layer address cannot
>    otherwise be determined (e.g., from a neighbor cache entry) are
>    resolved to link-layer addresses by a static computation, i.e., the
>    last four octets are treated as an IPv4 address.
>   ...
> 
> Change above just into
> 
>   ...
>   8.4 Address Resolution
> 
>    ISATAP addresses are resolved to link-layer addresses by a static
>    computation, i.e., the last four octets are treated as an IPv4
>    address.
>   ...
> 

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.

When I say in general this refer to the fact that step two may be
too resource demanding on some routers as well as it opens
up for the canionical DoS attack in this respect (4.3.2 of SENDPS).

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

Why ?

BR, Karen