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

[Pekka Savola <[e-mail]>]

On Thu, 27 Jun 2002, Fred L. Templin wrote:
> Pekka Savola wrote:
> > 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.
> 
> Agreed regarding the potential for security compartments within an
> organization, but it is not clear that internal firewalls would need
> to accept all ip-protocol-41 packets. For example, if each security
> compartment is treated as a distinct ISATAP site, only those
> ip-protocol-41 packets sourced by the ISATAP router(s) within
> each compartment would need to be accepted by firewalls.

That is an alternative approach, yes. (However, if there are many of these 
compartments and each of them acts as one ISATAP site, the routers should 
be meshed in some fashion, perhaps with ISATAP :-) -- this may soon get 
more complex though.)

> > 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.
> 
> Yes, these are clearly two benefits provided by ISATAP but I believe
> you may be misinterpreting what is meant by "aggregation scaling" here.
> We are referring here to the fact that a single, fine-grained IPv6
> prefix (e.g., a /64) can be used to autoconfigure IPv6 addresses for
> up to 2^32 nodes. (Actually, only that portion of 2^32 that constitutes
> legitimate IPv4 unicast addresses of course.)

IMO the ability that one /64 can be used to configure very many nodes is 
rather irrelevant.  (Or, it may be more relevant in some scenarios, e.g. 
if ISP only gives you a /64 -- but this needs to be a separate item if 
deemed so.)
 
> > The only real way I see ISATAP addresses this scaling issue is by not
> > putting the internal traffic to this border router.
> 
> This perhaps sheds some light on the misinterpretation. The fact
> that internal traffic is tunneled directly peer-to-peer w/o going
> thru the ISATAP router (as in triangle routing) provides clear benefits
> for reducing message traffic as you observed. But the claim in question
> relates to prefix aggregation scaling; not scaling in terms of message
> traffic. Perhaps you could suggest some alternate text to clear up the
> potential for misinterpretation?

My point was that the the sentence:

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

does not take into account that ISATAP will have border gateways (which
may have an aggregation scalinig issue) too; the amount of local-local
traffic will define what is the benefit of "ISATAP route-optimization" 
compared to e.g. static tunnels.

Perhaps something to the effect of:

4.2.  Enables incremental deployment of IPv6 hosts within IPv4 sites

   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 (many nodes, different physical subnets can 
   use the same /64) when many hosts configure addresses from pre-
   fixes advertised by the routers.

4.3  Optimized site-internal traffic flow

   As the IPv4 address of an ISATAP node is embedded in the IPv6 address,
   every node in the ISATAP site will create an IPv4 tunnel automatically 
   when it wants to communicate with another ISATAP node in the site.  
   This optimizes the traffic so that there is no need to send it first to
   the ISATAP router(s); this is a very useful especially in scenarios
   where the traffic inside the site is significant.

4.4  Automatic adaptation to adding more border routers

   As ISATAP nodes check the DNS records for new ISATAP routers 
   periodically, it is possible to add or remove ISATAP routers 
   dynamically, without a need to reconfigure the ISATAP nodes;
   in the case of static tunnels, one would have to decide which
   client uses which router, with ISATAP the default is to 
   do load-balancing.

4.5 ...

[Note: load-balancing can result in unpredictable events which is why I 
don't really are that happy about arbitrary load-balancing but some might 
be..]
 
> > 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.
> 
> If the PRL contains multiple addresses, the situation is just like any
> other IPv6 link with multiple advertising routers. That is, the node
> will receive RA's from multiple routers and act on them exactly as
> specifed in RFC 2461. (The "scaling" question is addressed in the
> earlier discussion.)

I think, from the perspective of ISATAP, a crucial special case is when 
two routers advertise the same prefix.

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