Re: Review: draft-ietf-v6ops-nap-01.txt

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

On Tue, 23 Aug 2005 09:29:40 +0100
Tim Chown <tjc@ecs.soton.ac.uk> wrote:

> On Tue, Aug 23, 2005 at 03:54:39PM +0800, Fred Baker wrote:
> > 
> > On Aug 23, 2005, at 3:17 PM, Gunter Van de Velde (gvandeve) wrote:
> > 
> > >Unfortunatly the industry need for having a tool to provide  
> > >topology hiding is
> > >real.... and is very easy to deploy in the IPv4 world by using  
> > >address translation, hence
> > >the IPv6 community better provides some solution for this and the  
> > >MIPv6
> > >one seems most appropriate to me at the moment. (The /128 ULA's is  
> > >a different
> > >story)
> > 
> > Compared to having an address space one doesn't advertise outside,  
> > mobile ip v6 seems really complex. I'm not fond of ULAs, but as I  
> > said in another context, simply having a prefix that is not  
> > advertised seems quite sufficient for hiding internal-only systems.  
> > And it's only the internal-only systems any of this hides; systems  
> > that can be seen from the outside can be seen from the outside, and  
> > the fact that they are on the same or different LANs is really window- 
> > dressing compared to that.
> 
> My view is along those of Stig and Fred.
> 

So is mine :-) I don't see much value it in it really either, I was
starting from the assumption that if somebody chose to do it, could the
be a possibly be another simpler or better solution. 

> Given how NAP is in itself a 're-education' tool, we could/should use it
> as an opportunity to highlight what can be done with IPv6.   The schemes
> for topology hiding proposed to date add back a lot of the complexity that
> IPv6 in principle removes.   I really don't agree with the NAP draft's
> approach on the topology hiding issue, though otherwise I think it's an 
> excellent document.  I think some simpler words can be said, and MIPv6
> or host routing avoided (or Mark's scheme, sorry :).
> 

One possibly big problem with my scheme, host routing or MIP is that I
think they all tend to give the IPv6 domain NBMA like characteristics,
meaning that multicasts probably have to be distributed via replicated
unicasts. Possibly in my scheme that could be solved by multicast
enabling the IPv4 "layer 2", and use that to distribute IPv6 multicasts
encapsulated in IPv4 multicast. I don't really know enough about MIP to
know exactly how multicasts are handled for that. The host routing
option might not have an alternative solution other than replicated
unicasts.

The other issue is that they all tend to introduce ambiguity into the
link multicast scope. As all the nodes are members of a single NBMA like
domain, does a link scoped multicast get sent to all of them, possibly
via unicast replication ? If not, where does a link scoped multicast get
sent to ? Does this mean that link and site scopes are now equal ? I
think that if the current topology hiding methods stay in the draft then
these multicast issues should also be mentioned in it.

I'm really starting to also agree that maybe it would be better to
identify the properties that the "toplogy hiding" nature the NAPT
provides, and both show they don't have much or any value or how other
IPv6 mechanisms can meet those features without having to rely on hiding
the toplogy from external entities (e.g., the lack of easy ping scanning
ability preventing hosts being found even if the subnet is known, packet
filtering to prevent traffic being sent to a subnet's router anycast
address.).

Regards,
Mark.