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

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

Pekka,

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

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

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

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

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

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

Thanks,

Fred
[e-mail]