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

[Vasilenko Eduard <[e-mail]>]

There is one principal question about "what additional functionality should be put inside RA to replace DHCP-PD":
How many hops this information should propagate? Or to be more precise: 1 or many?

Because currently, only the need for tethering is in discussion (1 hop).
What if would be the need to delegate prefix one hop more (to home router that could delegate next)?

DHCP-PD did not have such a challenge, because it could be recursively extended to next-next hop. If somebody not satisfied with tree topology - it is not the problem of DHCP-PD.
RA PIO would have additional challenge, because it would be connected to link status.
What if link down on 1st hop?
What if link down on 2nd hop? Who would inform whom? How?

If prefix is requested by one "second hop router", then it is not available for other. Equal split of any mathematical formula would not play well. Some request/response is needed (depends on toplogy).

Sorry to bring HomeNet again. But if something is in development - it is better to satisfy a little bigger "use case".
Of course, it is possible to fix on "tethering only" (1 hop) and do not complicate things too much.

Ed/
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: 24 ноября 2020 г. 17:50
> To: Philip Homburg <[e-mail]>
> Cc: 6man WG <[e-mail]>
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor
> handset supports PD?
> 
> Philip,
> 
> >> Neither do any implementation I'm aware do that.
> >> To be clear. If a link-type has no L2 address / is point to point,
> >> then no implementation I've touched does ND address resolution.
> >> It would be happy to respond to a NUD message.
> >
> > ND answers two questions, what is the L2 address of an address and is
> > the remote node alive.
> 
> ND has many functions.
> One is address resolution and another is NUD (neighbor unreachability
> detection).
> They use the same messages but have distinct functions.
> 
> > So from my point of view it is obvious to just send an NS, mark the
> > neighbor cache as incomplete until you get an NA back. Then you know
> > that neighbor is alive.
> 
> If you have a neighbor cache for neighbors for p2p links.
> 
> > Now, I wouldn't mind if other implementations would not send the NS
> > and just assume that their neighbors are alive.
> >
> > However I found that most sutff just doesn't reply with an NA at all.
> 
> Right. While NUD isn't a particularly effective keepalive/link state detection
> mechanism I would expect it to be supported.
> 
> >> The current behaviour of 64share does that (and gets the hack label
> >> for that reason).  What I'm saying is that 64share (and what I
> >> propose in p2p ethernet) is a lot closer to PD than it is to address
> >> assignment.  As soon as you stop thinking that a p2p link has a
> >> shared subnet, that's where you end up.
> >
> > From a 'bits on the wire' point of view, there is nothing magic to PD.
> > It is just a message that says: here is prefix, you can do with it as
> > you see fit.
> >
> > The devil is in the details. What if the down stream router then hands
> > out the prefix using DHCPv6 PD. Do we need to do anything special for
> homenet?
> > (I guess doing PD using RA would actually be the 3rd version of PD,
> > because homenet also does prefix delegation).
> 
> no, I can't see that the protocol external to the homenet matters.
> homenet does not do prefix delegation. homenet does prefix assignment.
> 
> > If we want this to work on ethernet, we may have to say something
> > specific, like 'a route will be installed that points to the (link
> > local) source address of the RS'. Which I guess implies that an RA
> > with a PDIO can only be sent in response to an RS (on ethernet). Then, what do
> we do on p2p links.
> 
> p2p links are simple. my proposal is also to treat Ethernet as a P2P link.
> But otherwise, yes, you would have to install the route with the LL as NH.
> 
> The biggest difference I see between DHCP PD and something we might do in RA
> is the coupling between interface state and prefix.
> DHCPv6 PD is essentially a fax-replacement. A delegation is independent of the
> upstream link-state, and in theory also which interface the delegation was
> received on. Although the realities of routing quickly sets in. If in RA the
> delegation's lifetime is restricted by the link-state/lifetime of RA, then that will
> have significant issues for downstream hosts/applications.
> 
> Cheers,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------