RE: Call for v6ops agenda items

[<teemu.savolainen@nokia.com>]

Hi Konrad,

> 6RD, as I understand it, is not primarily a configuration protocol, but
> a
> transition mechanism from IPv4 to IPv6 on large already deployed
> networks.
> As that 6RD is an excellent idea. I personally expect it to fade away
> ten
> years from now, while SLAAC and DHCPv6 are likely to stay.

Nevertheless, people do not see problem for using IPv4 address as part of automatic prefix delegation..

> Unfortunately most sources of unique bits are made up of very large
> blocks
> of bits that have to be used completely. E.g. Link Layer is most often
> 48
> or 64 bits, which do not follow any schema that a network operator can
> influence (at least on Ethernet based setups), so you waste a lot of
> bits
> just to make sure it stays unique (as also witnessed by 64bit host IDs
> in
> IPv6).

It is true that such sources of uniqueness cannot be used. I probably need to clarify the applicability scenarios for the next revision.

> This leaves only sources that I can influence as a network operator:
> PPP
> interface ID, /64 prefix of the 1:1 link, very few others, none on
> shared
> ethernets.
>
> This severely limits the usability of SPD.

That is subjective. World's cellular networks are usually using 1:1 links (e.g. all 3GPP(2) networks), which from my point of view is population large enough to justify a technology. But it is true that this is not as widely applicable as DHCPv6 PD (and not even supposed to be so).
 
> My (rather philosophical) problem with your proposal is that you try to
> teach the SLAAC/ICMPv6 part of the protocol stack about protocols it
> does
> not need to know about. This makes the driver more complex and hence
> more
> error prone. In my opinion unnecessarily.

I don't think I'm trying to teach SLAAC/ICMPv6 anything? Why do you think so (i.e. where do I need to clarify)?

The user space software would use the Stateless DHCPv6 to learn the configuration information, and calculate the delegated prefixes as described. Why SLAAC/ICMPv6 would have to be touched?

> The normal reaction of prudent implementers will probably be to
> implement
> this part of the protocol in userspace in a separate process. Result:
> you
> have gained nothing over DHCPv6. I shudder to think what security
> bulletins I'll see if an implementer does not behave prudently...

This userspace process would ask for the configuration information with Stateless DHCPv6, and based on the response would calculate automatically delegated prefixes and configure routing and RAs of local interfaces. So less DHCPv6 functionality would be needed, right? Devices that currently do not implement DHCPv6 for anything else than parameter configuration would not need to implement more of DHCPv6, but could manage still with just Stateless DHCPv6. 

Avoiding new DHCPv6 code on a host should be less risky?

> I implemented a semi-stateless version of DHCPv6 for my internal
> experiments with IPv6 over PPP - it responds with the same prefix to
> any
> query from the same customer, so it did not need to store any states.

Yes, this lightweight DHCPv6 server (on a gateway) is an interesting option as well. It could indeed provide much of the functions I'm after as was discussed in another thread with Ole. I'm studying that as well.

Best regards,

Teemu