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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 12 Mar 2004, Erik Nordmark wrote:
> > I think this seems rather obvious.  IPv4 has NAT, IPv6 doesn't (and we 
> > hope it won't).
> 
> I think things are a bit more subtle than that.
> My house has neither an IPv4 NAT or an IPv6 NAT.
> There are products that do IPv4 NAT and (I'm pretty sure) IPv6 NAT.
> The issue is under what circumstances one is required hence how
> prevalent they become.
> In IPv4 NATs are required due to issues related to the size of the
> address space, which we've removed as a reason in IPv6.
> Unfortunately that doesn't mean that other motivations for NAT go 
> away in IPv6 :-(

NAT is used for a lot more than just due to a lack of address space.  
They're also used as security devices (out of scope here), *AND* as an
easy means to extend a subnet.  A common example is a WLAN-capable
router, which is doing NAT.. just because it's a simple thing it can
do.  Similarly, if a host would want to connect to an another host,
and share the prefix (compared to manually delegating another
subprefix to the router?!!), NAT would be the simplest thing to
deploy.

We need to kill that conception.  Bridging is a nice way in many 
cases, and when it doesn't work, ND-proxying appears to 
work just as well.

> > Longer answer: assume that you have a gateway and a host behind it
> > (or, think of it as two chained hosts, the first of which acts as a
> > gateway).  A very common home set-up.
> > 
> > Now, let's assume IPv6 ISP would not want to do prefix delegation (for
> > any of a number of reasons), or the home user wouldn't want to deal
> > with the mess, or pay for the premium service to get it.
> 
> If an IPv6 ISP wants to get customers to pay per device/IP address,
> why would they hand out a /64 to begin with? They'd just hand out a
> /128.
> Unfortunately the only technical solution which can handle
> that is an IPv6 NAT.
> I question the benefit of having a solution for the /64 case that doesn't
> handle the /128 case.

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'm not even sure how one would go about
giving the user a /128 in the first place.

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.

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.

> > Yes -- but still NATs are being used in internal networks.  Prefix 
> > delegation / routing is applicable to an extent, but doesn't carry you 
> > far enough (IMHO).
> 
> The recommendation in RFC 3177 is one way to handle this.
> That doesn't solve the ease of having routers autoconfigure inside
> the home site. IEEE 802 bridging solves this, and so do some of
> the things discussed in the ZEROUTER context.
> But as I said this is out of scope of this WG as far as I know.
> (Please correct me if I am wrong.)

Autoconfiguring router networks inside the home site is IMHO out of
scope here.  But I think the point of ND proxying was precisely the 
fact that IEEE 802 bridging does not work in all the cases.  (And if 
it did, we wouldn't be needing ND-proxy in the first place.)

> > Well, this is a nice rant about ND-proxy, but a bit out of scope from
> > here.  
> 
> I already stated that it was out of scope in my note.
> I take it you then agree that we should remove all mention of ndproxy
> from the draft in question since you agree with me that it is out of
> scope :-)

I meant that discussing how ND-proxying is applicable in ZEROUTER etc.  
environments appears to be out of scope.  The scenario has identified
one specific case where it is useful.  That is an entirely different
scenario than plugging 5 ND-proxies in the network in any way one sees
fit and assuming they should work just fine (which seemed to be what
you were implying, but I could have read it wrong).

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

> > People have no doubt proposed something like ND-proxy in the
> > ZEROUTER problem space, but if there is overlap, it doesn't really
> > concern us that much.  The current spec states that spanning tree in
> > ND-proxy is optional.  I would personally want to get rid of it
> > altogether, to discourage its use in the more complex setups where it
> > shouldn't be used in the first place.  But that's beside the point
> > here.  What folks want is bridge two media together; the work is
> > already in progress and nearing completion -- it will be pushed out in
> > IPv6 WG whether we will it or not.  
> 
> Odd - when I was in the IPv6 WG last week there was some discussion
> about the fact that ndproxy and SEND can not be made to work together.
> (Conclusion seems to be that proxy NA can be secured using SEND in the case
> where there is a trust relationship between the host and the proxy, but
> there is no such relationship in ndproxy hence it can not be secured.)
> The odd thing is that there wasn't a groundswell reaction in the IPv6 WG saying
> "we really need ndproxy - how do we get SEND fixed" - there seemed to be
> almost complete disinterest in ndproxy as far as I could tell.

Well, I guess I interpreted the silence differently -- I thought "do 
we need SEND in the scenarios we're going to use ND-proxy?"

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

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.

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

(But this is something that should probably go to either SEND or IPv6 
WG...)
 
> > So, the only choice in this document we have is whether we mention its
> > usefulness in the specific problem space.  I personally think it may
> > be useful when the ISP (or you) for some reason doesn't want to do
> > full prefix delegation.
> 
> I though you said it was out of scope for the v6ops WG above, so it shouldn't
> be in the document.

Discussing its applicability in ZEROUTER etc. enviroments is out of
scope, but ND-proxy, in simpler setups, could be in scope here.
 
> 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.

(FWIW, I'd like to have something simpler than DHCP prefix delegation
in any case, maybe along the lines of draft-bykim-ipv6-hpd-01.txt, but
DHCPv6 probably has already gained too much momentum to make it worth
the effort..)

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