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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 12 Mar 2004, Erik Nordmark wrote:
> > PPP doesn't support v6 prefix delegation, and there is no will to make
> > it so.  Does v4 either?  (I'm not sure -- but maybe that's some vendor
> > extension.)
> > 
> > This approach works in the case where the ISP is advertising you an
> > IPv6 prefix using RA, and you want to extend it to another subnet.
> > On the other hand, in IPv4, there are no such advertisements.  Either 
> > the prefix is delegated somehow, or you use NAT.
> 
> Ignoring the protocol aspects, I have an IPv4 (public) /29 prefix at home and
> it seems to work just fine. 
> 
> Why does IPv6 need to be different
> in this respect? What is broken or missing in IPv4 that needs to be
> fixed or added in IPv6?

I think this seems rather obvious.  IPv4 has NAT, IPv6 doesn't (and we 
hope it won't).

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.

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?

> > What would you suggest as an (easy) replacement for v4 NATs?  ND 
> > proxying seems like an obvious solution in a scenario like this (that 
> > is, when pure bridging does not work).
> 
> DHCPv6 prefix delegation takes care of things at the CPE router.

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

> ndproxy also claims to solve the ZEROUTER problem - allowing multiple
> links in a small site without any explicit configuration of routers
> and without having to bridge everything together.
> Firstly this is utterly out of scope for this draft and this v6.
> Secondly, it doesn't really solve anything in this space.
> Basically the choice is between building ndproxy boxes which can't prevent
> loops, or build boxes which implement IEEE 802.1D spanning tree protocol.
> In the first case you have ndproxy boxes that, when you plug them together 
> at home you can cause the equivalent of persistent L2 loops where packets
> circle  forever and never die.
> In the second case you end up doing exactly what IEEE 802 bridges do; bridge
> the whole network together by defining how to do IEEE 802 over non-802 media.
> But as I said, that part is out of scope for this draft. 

Well, this is a nice rant about ND-proxy, but a bit out of scope from
here.  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.  

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.

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