RE: I-D ACTION:draft-ietf-v6ops-nap-01.txt

["Tony Hain" <alh-ietf@tndh.net>]

To be clear, the NAP draft is offering host routes as one option for
topology opaqueness, and I recall a discussion about text suggesting there
would be scaling concerns with the IGP. Maybe that didn't make it in the
current version of the draft. The other option is to use mipv6 without route
optimization. The external nodes are talking to the home agent for the
virtual subnet and it uses the tunnel mode to get to the current care-of for
the device. This has a scaling impact on internal traffic volume due to the
tunnel header, but has absolutely no impact on routing. 

Tony 


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of Mark Smith
> Sent: Friday, July 01, 2005 8:44 AM
> To: Fred Baker
> Cc: alain@tycool.net; v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt
> 
> Hi Fred,
> 
> On Fri, 1 Jul 2005 08:25:03 -0700
> Fred Baker <fred@cisco.com> wrote:
> 
> >
> > On Jul 1, 2005, at 4:03 AM, Mark Smith wrote:
> >
> > > (2) Running a fully fledged routing protocol on the end-node is
> > > relatively heavy handed for what is being achieved. I'd think a
> > > simple, light-weight announcement style availability protocol for the
> > > node's address, that is part of IPv6 itself, would be useful.
> >
> > It was standard practice on DECNET, XNS, and Novell equipment; Novell
> > did it twice, once for the routes and once for the services that the
> > servers offered. If you have only one interface, as you say it didn't
> > accomplish much. But if you have multiple interfaces on a server, it
> > provides something akin to what multihoming does for a network. As you
> > say, it is expensive in address count to put a /64 on a host, though.
> >
> 
> It took many years for me to realise why there was an "internal network
> number" on Novell servers :-) I think it probably co-incided with me
> learning how /32s on loopbacks pushed into a routing cloud could be
> useful for maintaining routers.
> 
> > In general, if you're interested in routing scaling, using the tools
> > that make it scale are a good thing. Host routes are the exception, I
> > should think, not the rule.
> 
> I generally agree, I personally don't really see all that much security
> value in attempting to make the internal subnet topology opaque to
> external devices at the cost of scalabilty. However, people seem to
> like NAT because that is one if its properties, and I could see them
> wanting to preserve it with IPv6. The NAP draft is suggesting
> using host routes to do this, and how that will work in IPv6 has
> intersected a bit with my somewhat academic interest in how it works on
> broadcast interfaces with IPv4.
> 
> For those who do place value on topology hiding, I'd imagine it would
> most likely to be "all-or-nothing" approach, meaning that all their
> hosts within their assigned /48(s) would be host routed, rather than a
> minor subset. If they think topology hiding is important, they're
> probably also prepared to think it is important for all their nodes,
> rather than a minor subset, and be willing to wear the scalability cost.
> 
> Regards,
> Mark.