ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt]

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 16 Mar 2004, Erik Nordmark wrote:
> First of all, I agree with you that removing reasons for NAT boxes
> needing to exist is something we should all do in the IETF; they
> make the network non-transparent and make it much harder to use some
> existing applications as well as creating/deploying new applications.
> 
> Our disagreements seem to be whether ndproxy is an effective and useful
> means for doing this.

Agree.

> > There is no stopping them if they want to get paid by the /128, of
> > course.  I'm thinking this from the perspective of the ISP: what's the
> > simplest thing for them to deploy.  It certainly doesn't seem to be
> > prefix delegation.  RA-based advertisement on a point-to-point link
> > seems like an obvious means.
> 
> I'd like to understand why DHCP prefix delegation isn't the simplest thing.
> Is this something you think is broken in our standards? Or in implementations
> of the standards?
> 
> As an aside I find it odd that when the car is broken one would look
> for parts in the garage and kitchen to try to build a bicycle and use that
> instead of the car. Shouldn't we try to fix the car instead?

See the "simpler prefix delegation" thread I just started on IPv6 WG 
list.

> >  I'm not even sure how one would go about
> > giving the user a /128 in the first place.
> 
> Easy.
> 
> Whether using stateless or stateful address configuration,
> the ISP can send RA's without any on-link prefixes to the customer's box.
> This means no prefix is made available to the pt-pt link between
> the ISP's router and the customer's box. Hence the customer's box
> can only use the configured IPv6 address.

But how does the customer's box get it's own (global) addess?  Do you 
assume you run something like PPPv6 on the link, which assigns one 
address and that's it?

> > Another angle here is how are you going to deal with the case where 
> > you have to have stacked gateways.  E.g., the home gateway is doing 
> > prefix delegation, and advertising /64's on its links.  One of the 
> > nodes at home is also a router, and behind it is a host.  How do you 
> > get v6 to that host behind the node?  That's a very common scenario 
> > today.  I think it in most cases you could probably move that node to 
> > the same link, but in some cases (e.g., mismatching media) it might 
> > not be possible.
> 
[...]
> The solution you want in this space is something which allows plug&play of
> the devices that glue together the stacking. And since you don't know how
> the customer will plug things together, I think you must deal with loops.
> 
> It is true that ndproxy as written can handle this, but it handles
> it by running IEEE 802.1D spanning tree protocol over all media - including
> non-IEEE 802 media - without specifying the details of how to carry IEEE 802 
> bridge PDUs over Avian Carriers, bluetooth, etc.
> That doesn't seem like the best approach.
> An approach like draft-perlman-zerouter-rbridge-00.txt, which builds
> a (very thin) overlay above the link layer between the rbridges look
> a lot more interesting to me; no need to carry bridge PDUs around etc.

Moved as a thread under a new thread on IPv6 WG list; seems like the 
best place to argue about the feature-set, as they're specifying it.

> But you seem to be talking about the ZEROUTER problem statement just as 
> much as I am; the problem is having multiple different L2 technologies 
> and wanting to plug those together without any explicit configuration of
> the boxes that connect the different L2 technologies together.

The number of boxes to be plugged together is also a factor.  How I 
interpreted the ZEROUTER scope (I could be wrong; I never looked it 
for long) was that any number of routers, in any topology would be in 
scope.

> > When you consider the applicability of SEND, it's probably highly
> > useful in environments like enterprise networks, server farms, etc.  
> > (in case someone breaks in there and would start hijacking etc.), in
> > public WLAN (and other) environments where you deal with untrusted
> > users, and similar cases.
> > 
> > It is probably not so necessary in a home network, or in the
> > point-to-point link between the ISP and a home network (where the ISP
> > can DoS/MitM/etc. you in any case).
> 
> What about a home network which is also a free public WLAN?
> Given that WEP is not adding much security, having SEND would make
> it possible to open up 802.11 home networks for public access
> (apart from resource management issues).

This is a good point.

SEND + CGA helps a bit in the local link, between the nodes; 
ND-proxy does not prevent that.  This is also possible in the local 
subnet (to a large degree), as long you're not running ND-proxy on the 
WLAN bridge (you should use bridging instead, because you can!).

On the other hand, SEND + certificates, for router verification, does 
not help here in any case, because I don't think the ISP offering only 
/64 would be supporting SEND (if they would, it would no longer be a 
"simple" setup -- and they'd be giving a /48).

So, I don't think this is all that critical issue in practice.

> > So, my gut feeling is that people think -- ok, it's fine that ND-proxy 
> > doesn't work with SEND. Let's not try to fix either SEND or ND-proxy.
> 
> I'd sure like to have that question be asked in the SEND, IPV6, and V6OPS
> WGs - my capacity for reading peoples minds is quite limited.

This should be brought up after the other threads in SEND and IPv6 WG 
cease.

> > The critical issue here, IMHO, is whether the hosts which are unaware
> > of whether ND-proxy is used or not can enable SEND or not.  That is,
> > we wouldn't want the vendors to turn SEND off by default if that meant
> > the hosts would not work with ND-proxy.
> > 
> > I don't think this is the case, but I could be wrong.  I think this
> > depends on what kind of "triggers" SEND-capable nodes get from the
> > network before generating CGA addresses etc. -- do the e.g., wait for
> > the first SEND-enabled RA/NA, or whatever -- or do they always start
> > immediately (which might be a bit redundant until SEND is commonly
> > deployed).
> 
> I don't see how this can be combined in a meaningful way.
> If a host has a default config to do SEND, then a packet from a ND proxy will
> look like an attacker (it will not look like an insecure node since the peer
> will have a CGA address AFAIK).

Right -- but what is the alternative?  The ISP would not be supporting 
SEND in any case.
 
> > Discussing its applicability in ZEROUTER etc. enviroments is out of
> > scope, but ND-proxy, in simpler setups, could be in scope here.
> 
> Could you specify the problem statement that covers "simpler setups"
> but where  loops are somehow impossible to create by the consumer?

We are not preventing the customer from shooting him/herself in the
foot in many other specifications either -- why is this relevant here?  
:)  They can plug their routers upside down, advertise prefixes which
don't work, forget to enable IPv6 forwarding, etc. -- a lot of
different ways to get yourself in a mess.  Further, I don't think
anyone is thinking of enabling proxy-ND by default. Just clearly state
that proxy-ND should not be combined, and if absolutely have to 
combine them, only plug them in series.

But this was included in the IPv6 ML thread.

> > > We already have DHCP prefix delegation as a solution to the problem at
> > > the connection to the ISP. How many solutions do we need in this space?
> > 
> > I believe this is a separate problem.
> 
> You must be having a problem statement in mind which is tailored to
> ndproxy as the solution. Such narrow problem statements are not very helpful
> IMHO - we need to understand the problem space here.

I believe the "simple home setup" is sufficiently common, but narrow
problem space.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings