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

["Fred L. Templin" <[e-mail]>]

Pekka,

Pekka Savola wrote:
> 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.)

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

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

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

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

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.

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

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

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

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.

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

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
[e-mail]