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

[Philip Homburg <[e-mail]>]

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

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.

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.

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

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.