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

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

> 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 :-(

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

> Now, we have a few choices: a) ignore this case, b) develop IPv6 NAT, 
> c) use ND proxying to give v6 access, to share the subnet, d) 
> something else, what?

If you believe we need to handle the /64 and /128 case, does that mean that
we also should develop workarounds for ISPs that filter port 25 in this WG?
As a standards organization can't prevent ISPs from filtering in whatever
bizarre way that think solves their business needs.

What we can do is specifying standards that make it easy for ISPs and
customers to do things in a way that preserves the transparency of the
network. DHCP prefix delegation is part of that picture.

http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html
is useful reading in this space.

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

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

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 :-(

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

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

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 feel the need to share this quote as this point in time:
  It's perfectly appropriate to be upset.  I thought of it in a slightly
  different way--like a space that we were exploring and, in the early days,
  we figured out this consistent path through the space: IP, TCP, and so on.
  What's been happening over the last few years is that the IETF is filling
  the rest of the space with every alternative approach, not necessarily any
  better.  Every possible alternative is now being written down.  And it's not
  useful.  -- Jon Postel

 Erik