RE: Call for v6ops agenda items

["Konrad Rosenbaum" <konrad@silmor.de>]

Hi,

On Thu, February 25, 2010 13:55, teemu.savolainen@nokia.com wrote:
>> * there already is a well working protocol for PD: DHCPv6; although I
>> like the idea of finally getting rid of it
>
> Right. IMHO as is proven by 6RD, there's interest to have prefix
> delegation also without DHCPv6 if easily doable.

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.

>> * 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
>
> I don't agree, the draft intents to say unique-bits can be of about any
> length. For example:
> - if length of unique bits is 1, there can be two routers below the
> gateway, which both would get delegated prefix of:
> [SPD-prefix][0/1][subnet ID]. Now if the SPD prefix is say 40 bits, and
> V6UNIQUE is 1 bit, the router would get /41, right? Then this router could
> further choose to delegate say /56 by configuring downlink routers by
> provisioning them with: [SPD-prefix+1][V6UNIQUE of 14 bits of
> length][subnet ID]. Right?
>
> In fact, this unique bits could be minimum of 1 bit and maximum is many
> bits (I have to think about that), right?

Thinking about this again: regardless of how unique bits are assigned to
the customer, the minimum amount of them is the same (log2 of the amount
of customers on the (sub-)network). So there would be no problem if we
could use the minimum amount or an amount close to minimum.

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

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.

>> * 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
>
> With SLAAC you refer to the case where bits are taken from the /64 prefix
> configured with SLAAC?

Yes.

> Right, but what is the significant difference to
> 6RD that uses uplinks IPv4 address?

The 6RD encapsulation happens in a very different layer of the protocol:
the virtual interface level.

SLAAC happens on an established IPv6 link on the IPv6/ICMPv6 level. The
protocol only uses very abstract services from the lower layers of the
protocol stack (transmit/receive packet, give me the modified EUI-64 of
the interface). It does not care whether the lower layer constructs the
EUI-64 from a MAC, from some prior negotiation or the last 64bits of the
last crashes stack dump. It will never ask for a MAC address or an IPv4
address - because there might be none.

6RD (and for that matter 6to4) on the other hand is a collection of
protocols on several, well separated, layers:
* 6in4 knows how to encapsulate IPv6 packets in IPv4 packets and where to
send them - the latter because userspace told it the destination
* the route setup (usually a script written by a vendor or the local
admin) knows what IPv6 route happens to coincide with the local/remote
IPv4 endpoint address; this is the userspace that tells the virtual
interface what to do

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.

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

>> * 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
>
> True. On the requesting router side the savings are indeed less - the main
> benefits would be on the network side.

What would be the savings?

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.

Including reading and understanding the standard, writing the server and
client, and testing it with other implementations, it took me a weekend
and resulted in a few hundred lines of code (most of that code deals with
parsing command line arguments and handling its socket). I do not believe
that there is any significant gain in development time, binary size, CPU
cycles or memory consumption compared to SPD. In fact it would require CE
router vendors (and possibly provider side AC vendors) to support yet
another protocol.

I can imagine any number of (semi-)stateless DHCPv6 implementations that
do exactly what you propose within the bounds of established standards.

>> I/2: should be unified into just I, since it is guaranteed to exist and
>> is
>> dependent on layer 2 IDs anyway
>
> Done, but added "T": tunnel identifier. What I'm thinking here is that
> e.g. the GTP TEID of 3GPP access could be unique part. Each bearer has
> this locally unique 32bit identifier. I think this requires further
> clarification.

"T" represents the same mix of layers again.

>> 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
>
> What do you think about 6RD?

I think 6RD is a much needed and very fine _transition_mechanism_. See above.

In short: I think we would gain more by defining the minimum requirements
for provider Access Concentrators using existing standards as a complement
to the upcoming CPE-router standard.



     regards,
     Konrad