Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

[Philip Homburg <[e-mail]>]

> There have been, I think, 2-4 (more?) ND-based PD or PD-like
> proposals.  The main argument against ND-PD, as I recall from PIO-X
> days, has been "we have DHCPv6 PD, ND PD will have to replicate
> most of the same semantics, why do we need two ways to do this?"
> 
> If, on the other hand, we are to understand that 3GPP operators
> are just not deploying DHCPv6 PD (for whatever reason), then I
> think a reasonable argument can be made that "we wouldn't have two,
> because we currently have zero."

We are creating 2 mechanisms, the fact that the mobile world doesn't use
it doesn't remove DHCP PD from the 3GPP standards.

Is there any guarantee that the mobile world will implement this new option
or will we be back here in a couple of years with the same discussion? I.e.,
if we do a new option when will it be part of 3GPP specs, when will routers
support it, when will telco's update routers and roll out this feature. When
will handset support it, etc.

That said, it seems to me that by and large DHCPv6 PD is the wrong model for
many of our current use cases. So if we can come up with something better,
then it is reasonable to have a newer mechanism that is better.

> If the above is true, I, for one, would be interested to evaluate
> a simple, clean draft that did things like:
> 
>     [1] define a PDIO, and its use in RAs and RSes (for requesting
>     a prefix length or refreshing/requesting a previously delegated
> prefix),

Yes

>     [2] define the scope of applicability (i.e. in contexts where
>     it can be guaranteed that only one client will receive the RA),

We may need to do the work in two steps. One is something that works only
links that are hardwired point-to-point such as ppp.

A second step would be to include point-to-point ethernet links.

>     [3] did not make unnecessary reference to link technologies,
> mobility architectures, or the like (just define the generic
> deployment requirements, however they may be met),

Indeed.

>     [4] did not try to make other unrelated changes (like redoing
>     the /64 SLAAC boundary; residential PD has been working fine
> for a while) and

Yes.

>     [5] define the relationship to any PIOs present (i.e. a PDIO
>     that covers or equals a PIO with L=0 can inform the client that
> it's in an RFC 8273-style environment whereas L=1 indicates an RFC
> 6603 situation).

I think we should be explicit. If part of the prefix is not avaiable then
there should be a field in the PDIO that says so. 

> I think it's possible to over-complicate the work, but if the
> deployment requirements are well-scoped I think it could be fairly
> clean and simple.

The hard part is coming up with a model such that we don't have to write
a series of drafts on how to deal with operational issues (such as
renumbering) as few years later.

I.e., the DHCPv6 PD model doesn't work for many cases, what model do we
agree on that does work.