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

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

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

Before we can answer those questions we shouldn't do anything in this space
IMHO.

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

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. 

  Erik