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

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Jun 2002 14:22:35 +0300 (EEST)

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

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 27 Jun 2002 12:48:23 -0700

Pekka,

Thanks for your comments. I will address them in two seperate responses:

> claimed wrt. to ISATAP.  The conditions are quite unclear, but perhaps 

I believe this may have been mentioned in another WG mailing list
a while back. Yes, an IPR statement was filed with the IETF while
I was still an SRI employee in November 2001 and appears at:

   http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt

The statement grants royalty-free permission for use of any portions
of SRI's submission that become part of the IETF standard, and I see
no ambiguity in that statement. SRI's IPR claims date back to ISATAP's
ancestral beginnings as a personal draft and, to my knowledge, SRI's
US patent submissions have not tracked ISATAP's evolution as an NGTRANS
WG item. (Nor could they, since ISATAP is the collaborative work of
several contributers from different institutions.)

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 27 Jun 2002 12:59:35 -0700

Pekka,

Below are my responses to the technical points you raised. Again,
the comments are appreciated:

> configured to accept any ip-protocol-41 packet from any internal node to

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. This
scenario clearly requires more study, however.

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

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

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

Thanks,

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jun 2002 10:18:49 +0300 (EEST)

On Thu, 27 Jun 2002, Fred L. Templin wrote:
> no ambiguity in that statement. 

That is not clear at all.

"to the extent necessary for compliance with the standard" could be
interpreted to mean that anything that is not a MUST can be penalized with
patent infringements.

The similar clause was in TBRPF (Manet wg), and it got replaced; I haven't 
checked whether the new version is better, but it isn't in the IETF IPR 
archives at least.

> SRI's IPR claims date back to ISATAP's

That is another question.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jun 2002 11:36:03 +0300 (EEST)

On Thu, 27 Jun 2002, Fred L. Templin wrote:
> 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.)

> 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.)
 
> potential for misinterpretation?

My point was that the the sentence:

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:

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

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

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 28 Jun 2002 10:59:53 -0700

Pekka,

> be meshed in some fashion, perhaps with ISATAP :-) -- this may soon get 

Glad to know that you see this as an alternative approach. This
area clearly needs more study so the thoughts are appreciated.

> if ISP only gives you a /64 -- but this needs to be a separate item if 

I believe this point is *very* relevant from the standpoint of prefix
aggregation in IPv6 border routing protocols. If each of N hosts in
a site were to assign their own /64 prefix independently of the others,
as many as N different prefixes for the site might be advertised in
IPv6 border routing protocols instead of just one. It is true that if
host-based 6to4 were used, the prefixes would all just aggregate as
2002::/16. But, using host-based 6to4 would foster continued dependence
on IPv4 routing both within the site and in the global Internet 
backbone, while ISATAP only depends on the intra-site IPv4 routing
infrastructure; turning itself off when no longer necessary. (Also,
host-based 6to4 only works with globally unique IPv4 addresses,while
ISATAP works fine with privately-assigned addresses.)

>    fixes advertised by the routers.

I think we could probably live with this re-word. (It makes for a
shorter and easier-to-read section header as well.) Thanks for
suggesting it.

>    client uses which router, with ISATAP the default is to 

I agree - these are important points for us to add to the
applicability statement. Thanks for suggesting them.

> don't really are that happy about arbitrary load-balancing but some might 

Any load balancing advantage that might result from having multiple
ISATAP routers for a site (I assume this is what you are referring to)
would arise in an identical fashion as for the case of multiple native
IPv6 routers attached to a native IPv6 link. [RFC 2461, 6.3.4] provides
a host specification for processing router advertisments that covers
the case of multiple routers, and ISATAP works exactly the same way.
The RFC 2461 text does not specifically claim load balancing as an
advantage, but it seems intuitively obvious that having multiple
routers might be beneficial in some situations. The same is true
for ISATAP but, like RFC 2461, no specific claims are made.

> two routers advertise the same prefix.

I believe the behavior in this case would be identical to the case of
multiple native IPv6 routers advertising the same prefix, i.e., the
behavior would be identical to RFC 2461. Did you have any specific
concerns about this case?

Regards,

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jun 2002 22:15:05 +0300 (EEST)

> area clearly needs more study so the thoughts are appreciated.

Agreed -- this can become very complex.  It seems that ISATAP has a 
property (a good one) that the created IPv6 topology will be flat.

Two practical requirements for this kind of approach is that different
compartments have different subdomains, are using the subdomain first
in their DNS resolver search path and the ISATAP name is added (pointing 
to the local ISATAP router) in each subdomain where this behaviour is 
requested.  (Alternatively, some form of manual configuration is always 
possible.)

> IPv6 border routing protocols instead of just one. 

To where?  To upstream there would only be one aggregated prefix, to 
ISATAP routers and other components in the same all of them.

My point is that if there's no shortage of /64's, I don't think there's 
much loss to use a couple of them.

But I mostly agree; however, I thikn 4.2. should be reworded a bit to make 
it clearer we're talking about prefix aggregation.  (When talking about 
border gateway aggregation, one often regards this as access aggregation, 
like 500 T1-line customers in, Gigabit Ethernet out.)

> behavior would be identical to RFC 2461. 

Yes.

> Did you have any specific

Not really.  Only a notion that this scenario may come up more often with
ISATAP (esp. in larger organizations).