Re: I-D Action: draft-smith-6man-link-locals-off-link-00.txt

[Mark Smith <[e-mail]>]

Hi Dennis,

What I'm really taking about is whether a host can reach a link local
destination attached to the same link instance directly.

The L-bit in a PIO indicates whether the host should try to reach the
destination directly, or to send the packet to a router.

For link-local destinations, hosts are to always co

On 20 Aug 2015 11:17, "Dennis Ferguson" <[e-mail]> wrote:
>
> Hello,
>
> On 19 Aug, 2015, at 00:41 , Mark Smith <[e-mail]> wrote:
> > On 19 August 2015 at 12:20, Brian E Carpenter
> > <[e-mail]> wrote:
> >> I have a question.
> >>
> >> How did the host that is attempting to send a packet to its
> >> unreachable neighbour learn the address of that neighbour
> >> in the first place? As far as I can see, neighbour discovery is
> >> clearly going to fail anyway, since neither Neighbor Solicitation
> >> nor Neighbor Advertisement will be delivered.
> >>
> >
> > Right. The failure to resolve the link-local address will cause the
> > application to fail to connect, unlike on a conventional
> > (unconstrained) broadcast multi-access, NBMA or point-to-point link
> > where link-locals work.
>
> I'm confused about how this answers the question, though.  If I write
> down the link-local address of a machine attached to my (unconstrained)
> broadcast multiaccess network at home, go to work and try to connect
> to the same machine using that address, it will fail to connect.  The
> reason it will fail to connect is that the host I'm trying to connect
> to using that link-local address is off-link, just like most other hosts
> on the planet are.  Link-local addresses don't work if the hosts are
> off-link, a fact that is entirely unsurprising and is not in need of
> fixing, so applications which need to talk to off-link destinations
> will need to avoid trying to use link-local addresses to do so.
>

So the trouble I've had is that I've had to adopt the "on-link"/"off-link"
terminology, because that is what the "L" bit in a PIO is theoretically
indicating.

In reality, what it is really indicating is whether a host should try to
directly send a packet to the destination covered by the PIO prefix, or to
send it to one it's default routers, either for transmission over another
link, or back onto the same link.

So when I've described enabling hosts to treat Link-Locals as "off-link",
all I'm really saying is that the host should send traffic to all
Link-Local destinations to one of its default routers. Currently, hosts
always try to send to Link-Local destinations directly, and that cannot be
changed.

The "L" bit would be better described as the "send direct to destination"
or "send via router" bit.


> So I think the question remains: what made the application trying to
> connect to an off-link destination using a link-local address think
> that this should work?
>
> What is "on-link" and what is "off-link" is neither arbitrarily determined
> nor defined by addressing, it is a property of the L2 connectivity that
> exists.  Once whatever is necessary for address resolution has been done
> a host can expect that a packet sent to an on-link neighbor with a TTL of
> 255 will arrive with a TTL of 255, that a packet sent with a TTL of 1
> will arrive, and that it may be able to continue to talk to an on-link
> neighbor even if the routers go away.  An application which doesn't care
> about any of this also needn't care what kind of address it uses to talk
> to its neighbor and can just pick one that works,

Actually, if there is a choice, LLs are listed first (preferred) over GUA
and ULA addresses in the return from the getaddrinfo() call, as smaller
scopes are preferred in the IPv6 address selection RFC.

> but an application which

> goes out its way to use a link-local address may very well rely on the
> nature of the service it expects to get by limiting itself to on-link
> neighbors this way and I think that connection should probably fail if the
> expected service can't be delivered.
>

Yes, and that failure will either be made visible to the end-user, even
though the destination is reachable via GUA/ULAs if they exist, or
applications will have to adopt happy-eyeball techniques to hide Link-Local
failures when GUA/ULAs are also available.


> I think I understand the bigger problem you are trying to solve.  The
hosts
> and the routers have asymmetric views of what is on-link and what is
off-link:
> from the point-of-view of a host it is on a link with a router or two but
> nothing else, while the routers see themselves as on-link with everything
> so behavior somewhere will need to change to deal with the asymmetry.

Yes.

If security is the motivation for the CBMA link, there is still a device
that can enforce security policy between hosts even if their applications
choose to use LLs instead of GUAs or ULAs to reach other hosts that are
connected to the same link (but not directly reachable).


> What I don't get is why you seem to want to change the host behavior to
> be more consistent with the router's view of the link, rather than just
> limiting the changes to make the router's behavior consistent with the
> hosts' view.

So the only alternative is for the router to perform ND Proxy for
Link-Local destinations.

So why is it necessary to use ND Proxy for LLs, but not for GUAs and ULAs?
Why wasn't ND proxy used to solve the problem for GUAs and ULAs too? PIOs
could have just been used for SLAAC operation, rather than also making a
statement about whether the GUA or ULA destination is directly reachable
over the link, or reachable indirectly via a default router.

>  Not only is the router the preferred place to deal with

> oddities, since there are usually fewer of them than hosts and we already
> expect to have to configure them to do stuff in any case, but in this
> case the changes in the router will involve making the router behave
> (from the hosts' point of view) as if the router has more limited L2
> connectivity than it actually does, which can sometimes be done, while
> making the host conform to the router's view requires making the hosts
> behave is if they have more extensive L2 connectivity than they actually
> do, which is impossible.  The L2 connectivity the hosts have is all
> they have to work with, so I think you must make the routers behave
> consistently with the host view of their link.
>
> To do that I think you would want to make modifications to the router
behavior
> like the following:
>
> - When the router forwards a packet from one host to another it should
>   not send a redirect pointing the source host directly at the
destination.
>   While doing so might be consistent with the router's view of the link
>   it is inconsistent with the host's.
>

Yes, on a CBMA link, routers' sending redirects has to be switched off.

> - When the router receives a packet from a host destined to a link-local
>   address of another host it should drop the packet.  While this might
>   be same-link forwarding from the router's view of the link it is
off-link
>   forwarding from the point of view of both hosts, so to be consistent
>   with the host view it shouldn't be done.
>

I consider that too big a hammer. Applications are permitted to use LLs,
and I think the IPv6 address selection RFC actually effectively courages it
because it prefers LLs over larger scoped addresses like GUAs/ULAs - if
they exist.

> - When the router receives an unrouted multicast from a host it should

>   not attempt to deliver that packet to other hosts.  Unrouted

>   multicasts don't leave the link they were sent on so doing this would
>   be inconsistent with the hosts' view of their links (not to mention
>   inconsistent with the router's view as well).
>
> - I think a multicast router is going to have a problem with this link
>   if it can't omit the originating host when flooding to the others.
>   You'll need to decide if you care or not.
>

So you're sort of describing all the problems that CBMA links create that
don't exist on BMA, NBMA and point-to-point links. I want to solve these
problems for CBMA links, while still giving people who want the "problems"
for security reasons the option to have them.

> I'm not positive, but I think most what you seem to want to do works (if
you

> don't need to deal with IPv4) without changes to the hosts if you just let
> each host believe it is alone on a link with a router or two, and don't
> let the routers do anything inconsistent with that.  Is there a reason
> not to do it this way?
>
> Dennis Ferguson
>


Regards,

Mark.