Re: Review of draft-ietf-v6ops-nap-02.txt

["Durand, Alain" <Alain_Durand@cable.comcast.com>]

Margaret,

I think I share some of your concerns that the suggested solution introduces real operational complexities for somehow doubtful benefits.

One could also observed that the solution only partially hide the internal topology, as, at the IP layer, the fact that multiple inside hosts are present is visible from the outside while with NAT, only one address was visible...

Although I subscribe to the original goal of the document to show that many of the alledged benefits from NAT can be achieved using simple techniques with IPv6, I think we are now way past the point of diminishing return and making detailed recommendations for a very complex topology hiding architecture defeat the purpose of this document.

IMHO, we'll be much better of listing topology hiding as a feature of NAT.

   - Alain.



----- Original Message -----
From: owner-v6ops@ops.ietf.org <owner-v6ops@ops.ietf.org>
To: v6ops@ops.ietf.org <v6ops@ops.ietf.org>
Cc: 'Tony Hain' <alh-ietf@tndh.net>; 'Tim Chown' <tjc@ecs.soton.ac.uk>; 'Radia Perlman' <Radia.Perlman@sun.com>; 'Alex Zinin' <zinin@psg.com>; 'Erik Nordmark' <erik.nordmark@sun.com>; Donald.Eastlake@motorola.com <Donald.Eastlake@motorola.com>; 'Dave Oran' <oran@cisco.com>; 'Bill Fenner' <fenner@research.att.com>; 'Jari Arkko' <jari.arkko@piuha.net>; david.kessens@nokia.com <david.kessens@nokia.com>
Sent: Wed Jun 28 17:17:16 2006
Subject: RE: Review of draft-ietf-v6ops-nap-02.txt


Hi All,

As I understand it, there is a current proposal in the v6ops WG (in
draft-ietf-v6ops-nap-03-draft0.txt) to publish the following recommendation:

   There are other possible scenarios for the extreme situation when a
   network manager also wishes to fully conceal the internal IPv6
   topology.  In these cases the goal in replacing the IPv4 NAT approach
   is to make all of the topology hidden nodes appear from the outside
   to exist at the edge of the network, just as they would when behind a
   NAT.

   o  One could use explicit host routes and remove the correlation
      between location and IPv6 address.  In the figure below the hosts
      would be allocated prefixes from one or more logical subnets, and
      would inject host routes to internally identify their real
      attachment point.  This solution does however show severe
      scalability issues and should be limited to uses with
      substantially fewer than the maximum number of routes that the IGP
      can support (generally about 50,000).

[...snip...]

                             Internet
                                 |
                                 \
                                 |
                       +------------------+
                       | Simple Gateway   |  Logical subnet
                       | or Home Agent    |-+-+-+-+-+-+-+-+--
                       +------------------+  for topology
                                 |           hidden nodes
                                 |
               Real internal  -------------+-
               topology       |            |
                              |           -+----------
                   -----------+--------+
                                       |



The more I think about this proposal, the more questions arise, such as:

(1) Do we really mean that the router in this picture would be a "simple
gateway or home agent"?  I don't think that is consistent with the idea that
it could handle 50,000 routes.  Or that it would run an IGP, for that
matter.

(2) What mechanism would hosts use to inject host routes into the IGP?  How
is that secured?

(3) How will local nodes know to use topology-specific ULA addresses for
local communication?  What happens if they don't?  Could this result in a
large amount of internal traffic bouncing off of the "simple gateway or home
agent"?

(4) How does this interact with multicast traffic and ND.  Can a node on the
"logical subnet" send a link-local multicast packet on the logical subnet
and safely assume that it will reach all of the nodes on that subnet and no
one else?  If not, how does this interact with ND?  

(5) Would autoconfiguration be used on the logical subnet, or would hosts be
expected to get those addresses through other means?

(6) What advantages (if any) does this approach have over using a single
subnet internally and using L2 switches and VLANs to handle internal packet
delivery?  What disadvantages does it have when compared to that approach?

(7) How does this proposal relate to the work currently underway in the
TRILL WG?

If we decide that we actually want to make this recommendation, I'd prefer
that we remove it from this document and make this recommendation in a
separate document that covers the scalability issues, the answers my
questions above, and any other factors that may affect the applicability of
this solution.

Margaret


> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com] 
> Sent: Wednesday, June 28, 2006 4:00 PM
> To: Margaret Wasserman; Dave Oran; radia.perlman@eng.sun.com
> Cc: 'Tony Hain'; 'Tim Chown'; v6ops@ops.ietf.org
> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt
> 
> Radia and Dave:
> 
> There is a dispute going on regarding the scalability of 
> topology hiding by what amounts to IS-IS level 1 routing 
> (identifying hosts in a multi-LAN network by their host 
> identifier and using a common subnet ID for the domain). Do 
> you know of available documentation of IS-IS level 1 routing 
> and its tested scalability?
> 
> As Radia knows, this question is also being looked at in IEEE 
> 802.1, which presumes that there is only a single 
> multi-LAN-LAN, and that MAC addresses are used to route within it.
> 
> Fred
> 
> On Jun 28, 2006, at 12:40 PM, Margaret Wasserman wrote:
> 
> > 50K is an order of magnitude higher than the analysis in 
> Alex Zinin's 
> > presentation would seem to indicate.  His presentation 
> indicates that 
> > flat
> > routing will only scale to something on the order of 1K nodes.   
> > Please feel
> > free to check with Alex, though, as he certainly has more 
> > understanding of IGP scaling than I do.
> > [snip]
> > If this document is going to recommend doing flat routing 
> for topology 
> > hiding, I think that the WG needs to do the analysis to 
> determine that 
> > this is a valid and scalable technique.
>