(ngtrans) Re: draft-ietf-ngtrans-isatap-scenario-00.txt

Pekka Savola <pekkas@netcore.fi> Thu, 27 June 2002 11:23 UTC

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11517 for <ngtrans-archive@odin.ietf.org>; Thu, 27 Jun 2002 07:23:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03883; Thu, 27 Jun 2002 05:23:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12638; Thu, 27 Jun 2002 04:23:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RBMak7005239 for <ngtrans-dist@sunroof.eng.sun.com>; Thu, 27 Jun 2002 04:22:36 -0700 (PDT)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RBMZiD005238 for ngtrans-dist; Thu, 27 Jun 2002 04:22:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RBMXk7005231 for <ngtrans@sunroof.eng.sun.com>; Thu, 27 Jun 2002 04:22:33 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v2.1p1) with ESMTP id EAA17398 for <ngtrans@sunroof.eng.sun.com>; Thu, 27 Jun 2002 04:22:38 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24045 for <ngtrans@sunroof.eng.sun.com>; Thu, 27 Jun 2002 05:22:36 -0600 (MDT)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5RBMZb24812 for <ngtrans@sunroof.eng.sun.com>; Thu, 27 Jun 2002 14:22:35 +0300
Date: Thu, 27 Jun 2002 14:22:35 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: ngtrans@sunroof.eng.sun.com
Subject: (ngtrans) Re: draft-ietf-ngtrans-isatap-scenario-00.txt
Message-ID: <Pine.LNX.4.44.0206271403180.24634-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Pekka Savola <pekkas@netcore.fi>

Hi,

A few comments.

First off, I think it should be appropriate to mention that IPR have been 
claimed wrt. to ISATAP.  The conditions are quite unclear, but perhaps 
sobering up..

Second, there are a few security considerations that may be relevant in
this Enterprise/Managed networks problem space.  For some organizations,
embedding a private address (if NAT is used) in IPv6 address may be
unacceptable.  Especially in Enterprise/Manged environments, there are
often security compartments also inside the organization, that is,
internal firewalls.  Basically with ISATAP, every firewall must be
configured to accept any ip-protocol-41 packet from any internal node to
any internal node.

And on one chapter of the draft:

4.2.  Enables incremental deployment of IPv6 hosts within IPv4 sites   
with no aggregation scaling issues at border gateways

   Additional hosts can be added with no need for manual configuration
   (though this is possible, if wanted). Such hosts will (when using the
   recommended mechanism) discover the set of ISATAP routers via a
   lookup of DNS resource record. These routers are polled (using ISATAP
   encapsulation) and auto-configuration can be performed, resulting in
   aggregation efficiency when many hosts configure addresses from pre- 
   fixes advertised by the routers.

==> I feel unconfortable with this 'no aggregation scaling issues' 
statement.  IMO Isatap is mostly useful for a) automatic the tunneling to 
to a border IPv6 router, and b) optimizing the direct tunneling between 
two ISATAP nodes in a site.

The only real way I see ISATAP addresses this scaling issue is by not
putting the internal traffic to this border router.

If RPL initialization returns more than one address, though, I guess an 
ISATAP node should round-robin (like with NDISC) between those that send 
router advertisements.  But really, I don't see how this makes the scaling 
issues go away; assuming manual configuration, the nodes could very well 
just be configured to use another router.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords