Re: Call for v6ops agenda items

["Konrad Rosenbaum" <[e-mail]>]

Hi,

On Mon, February 15, 2010 16:09, [e-mail] wrote:
> Would there be interest to hear about stateless IPv6 prefix delegation
> proposal - i.e. prefix delegation like in 6RD/6to4, but without
> encapsulation:
>
> http://tools.ietf.org/html/draft-savolainen-stateless-pd-00
>
> This approach would make it easy to delegate (mainly slightly) shorter
> than /64 prefixes for a large number of devices connected via
> point-to-point links (e.g. cellulars). The con is extra consumption on
> IPv6 address space. I think the approach would be useful if many devices
> would need few additional /64s, but would not compete with flexibility of
> RFC3633.

I see this from a SOHO perspective (ie. the one who uses the UMTS modem or
DSL router).

As a fan of self-organizing systems, self-organizing routing
infrastructure is akin to the holy grail for me, but unfortunately I don't
think this swallow can fly with a coconut in its beak. (SCNR)

I have a few points of contention:

* there already is a well working protocol for PD: DHCPv6; although I like
the idea of finally getting rid of it

* the unique-bits part is too large to work on more than one level, so it
would be reserved to the ISP-to-User-line, but then again SLAAC is also
reserved to the link level of routing

* semantically it's not the right protocol for this: SLAAC is transmitted
on the same link it configures, PD is transmitted on the upstream link of
those (different links) that are configured

* as a router admin I would never accept PD statelessly - i.e. without
having asked for it; this might be just too much paranoia on my part
though

* stateless also means that the router has to reserve enough space for
EVERY client, because it cannot know whether the client wants to use it;
with a stateful protocol it only needs to reserve space and route the
prefix once the client asks for it

* for most OSes it has to be implemented in a user-space program anyway,
since the kernel cannot know which interfaces to configure, but in
userspace it does not matter whether I implement DHCP rapid commit or
"stateless" PD with a request message - the complexity is the same

I also have a problem with some of the uniqueness-source bits:

P: should be restricted to prefixes announced in the same SLAAC message

I/2: should be unified into just I, since it is guaranteed to exist and is
dependent on layer 2 IDs anyway

4: I have a really big problem with this: it mixes protocols and requires
a lot of dual-stack logic to exist on the host - you can make it a MAY,
but then DHCPv6-PD has to exist as well as a backup

D: it shouldn't mention DHCP directly, but instead use the word "stateful"
as other RFCs do, but then again - how to know which IP is meant? The
interface can have multiple IPs all configured through different stateful
protocols and an independent process will not know through which protocol
they came. BTW: why would one use stateless PD if there is stateful
address assignment anyway?

If multiple bits are set - is that legal? What should the host do?

I also think the ping test should be a MUST, not a MAY.



   regards,
   Konrad