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

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 20 Apr 2004 19:58:47 +0200

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:[email-masked]]
> Sent: 20. april 2004 17:11
> To: Karen E. Nielsen (AH/TED)
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]
> 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

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Apr 2004 23:07:24 +0300

> From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
> 

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).

> > on one of the PRL addresses.

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.

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Apr 2004 23:13:15 +0300

Oh, additional thing: I did make an experimental implementaion based
on ISATAP-20 draft (or something), which used IPv6 multicast mapped to
IPv4 multicast (organisation scope). This worked just fine, as long as
the nodes "heard" the multicast. Even link local name resolution
(LLMNR) worked nicely over ISATAP interface, neighbors find each other
just fine.

But, it's really ugly looking to communicate with tunneled packets
between hosts on the same LAN :-)

---

From: Fred Templin <[email-masked]>
Date: Tue, 20 Apr 2004 16:03:31 -0700

Markku Savela wrote:

>IPv4 multicast (organisation scope).
>  
>
Please note that isatap-20 is now obsoleted by the 4/16/04
draft submission announcements.

Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Thu, 22 Apr 2004 12:09:42 -0700

Karen and Markku,

Thank you for your comments on the isatap-21 draft; they
have been added to the ISATAP Issue Tracker page at:

   www.geocities.com/osprey67/isatap/isatap_issues.htm

Fred Templin (for the ISATAP co-authors)
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Fri, 30 Apr 2004 10:35:44 -0700

Karen and Markku,

Thank you once again for your comments on isatap-21.
The co-authors have discussed the issues, and proposed
resolutions are now posted on the Issue Tracker page at:

The working group is now invited to examine and
comment on the proposed resolutions.

Fred L. Templin
[email-masked]