Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

Odd that only you seem to feel it is worth-while to comment on
the need for proxynd; does nobody else care enough?

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.

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

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

> So, what I'm trying to see is the easiest way an ISP could deal with
> "basic IPv6 usage case" (seems to be a /64 advertisement), which would
> still encourage for the better service (/48 prefix delegation).  The
> case where the ISP absolutely wants just support one IP address is out
> of scope here.

I think RFC 3177 makes it clear that /48 should be the default.
And if the car (DHCP prefix delegation) isn't working well, let's work
on fixing 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.

But here you wander into the ZEROUTER domain which you've already said
is out of scope.
If I can discuss it with you using the word "rant" I'd do that.
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.

> > FWIW I take exception to you calling my explanation a "rant" - that
> > is pretty close to an ad-hominum attack IMHO. Perhaps I should complain
> > about your behavior to the WG co-chairs :-(
> 
> Discussing the applicability of ND-proxy in ZEROUTER environments
> appeared to be rather out of scope here.. because we're not discussing
> applying it in those environments.  So, the point of your anti-
> ND-proxying note was IMHO well written, but not something that
> belonged here -- rather maybe IPv6 WG which is working on ND-proxy.  
> Sorry if I called that "ranting"; I don't see that as a too negative
> term myself -- perhaps because I feel I'm ranting a lot myself on some
> occasions ;-)

Apology accepted.

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.


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

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

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

> (But this is something that should probably go to either SEND or IPv6 
> WG...)

Agreed.

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

  Erik