Subject: RE: Call for v6ops agenda items

From: "Konrad Rosenbaum" <[email-masked]>
Date: Tue, 2 Mar 2010 14:05:52 +0100 (CET)

Hi,

On Thu, February 25, 2010 13:55, [email-masked] 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

---

From: <[email-masked]>
Date: Tue, 2 Mar 2010 15:59:43 +0100

Hi Konrad,

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

> just to make sure it stays unique (as also witnessed by 64bit host IDs

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

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

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

> 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

---

From: "Konrad Rosenbaum" <[email-masked]>
Date: Tue, 2 Mar 2010 18:45:15 +0100 (CET)

Hi,

> so (i.e. where do I need to clarify)?

Oooooops. That's embarassing: for some reason I assumed your protocol was
an extension of Router Advertisements.

Do I read it correctly now in that you plan to extend DHCPv6 and/or IPv6CP?

If so, a lot of my arguments just lost their teeth.

Could you make it clearer what exact protocols can carry your extension
and how they interact with it?

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

In that case they wouldn't.

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

Yes. Avoiding any extra code is less risky. As is avoiding any mix of layers.

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

This also has the upside of the provider and/or AC vendor being able to
impose any policy on prefix calculation without having to worry about the
state of implementations on the CPE side.

What I still worry about is a wholly different aspect of SPD:

Pseudo-stateful PD requires you to implement the calculation of prefixes
exactly once on the AC (DR) - even if it misinterprets some standard in
the calculation it will probably still work - the clients (RR) do not care
how their prefix was calculated, they just use it. As long as the RR works
with any single other implementation of DHCP server it will probably work
with almost all of them.

Stateless PD requires this calculation to be implemented exactly the same
way on the AC/DR (it has to calculate the routing table) and all the
variants of RR, with the RR having to implement several variants at once
since they do not know what network they will end up in. Especially the RR
implementers will be under a lot of pressure (CPE devices and mobile
phones are not exactly the most expensive network components). Per
Murphy's Law they will get it wrong. In many different ways. So we will
have a DR doing the calculation one way and several types of RR doing the
same calculation randomly the same way, a slightly different way, a very
different way or not at all.

I do not want to seem unnecessarily gloomy, but I suspect high support
costs are on the way if more than one way of calculation is supported and
if there is the slightest chance of misinterpreting the standard.

    Konrad

---

From: <[email-masked]>
Date: Wed, 3 Mar 2010 22:31:15 +0100

Hi,

> an extension of Router Advertisements.

Probably due "stateless"-wording. Maybe the "automatic prefix delegation" would have been better naming after all, but then again, dhcpv6 pd is also "automatic"...:)

> Do I read it correctly now in that you plan to extend DHCPv6 and/or

Right.

> and how they interact with it?

Yes, I'll keep that in mind.

> with any single other implementation of DHCP server it will probably

I was assuming working code, but that is a very good real-life consideration, thank you. I will add that as well as a risk, in addition to easier policy control if DR has all the intelligence. 
 
> if there is the slightest chance of misinterpreting the standard.

With the stateless proposal one aim I have is to have as cheap and easily deployable solution as possible available, which would help to ensure prefix delegation is available for nodes as often as possible (so that ND proxy etc would be needed less often)..

Best regards,

Teemu