Subject: Re: draft-gont-6man-slaac-renum-01

From: Erik Kline <[email-masked]>
Date: Sun, 24 Mar 2019 21:47:19 +0100

To restate thoughts from IEPG this morning and from hallway
conversations thereafter, I think it would suffice to add some
"loopback detection".  Basically, if a host has cause to think a
router no longer routes a PIO onto a link it should start some prefix
unusability detection.

This would basically be a host sending a packet from itself to itself
via the router.  The destination address should be a GUA from the PIO
formed on the interface, but the contents and source address I'm less
sure of (could be from link-local or the same GUA or a different
on-link GUA, could be a ping or a unicast NS or a UDP packet to a port
the host opens, ...).

If a positive packet reflection occurs then that router still routes
the PIO onto the link. If there's no such response within $TRIES
across $SECONDS, then assume that router doesn't forwarding that PIO
onto the link.  (Note that the PIO might still be valid on-link as
specified by a 2nd router...)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Mar 2019 10:48:36 +1300

On 25-Mar-19 09:47, Erik Kline wrote:
> via the router.  

How do you make that happen if the prefix is on-link?

   Brian

> The destination address should be a GUA from the PIO
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Sun, 24 Mar 2019 22:49:23 +0100

Erik,

> On Mar 24, 2019, at 9:47 PM, Erik Kline <[email-masked]> wrote:
> 
> the host opens, …).

I think the challenge here is to avoid the hosts loosing a prefix that the host can use for local communication while there is a temporary problem with the router or the link to the router.  I can see a number of cases where the problem is the link to the router that at some point will be resolved.   As opposed that the router lost or forgot the prefix it had allocated.

> specified by a 2nd router…)

If the host has no other global prefix, I don’t see any reason to have the host stop using the prefix.

Bob

---

From: Sander Steffann <[email-masked]>
Date: Mon, 25 Mar 2019 00:13:47 +0100

Hi,

> How do you make that happen if the prefix is on-link?

Send it to the MAC address of the router and let the router bounce it back.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Mar 2019 12:10:09 +1100

> Send it to the MAC address of the router and let the router bounce it back.

That may not be as easy as it sounds.

Not sure about other OSes, however the Linux kernel by default drops
packets it receives over the network with source addresses match its
own local addresses.

It can be switched off, however that would mean changing a default on
a lot of hosts.

accept_local - BOOLEAN
Accept packets with local source addresses. In combination with
suitable routing, this can be used to direct packets between two
local interfaces over the wire and have them accepted properly.
default FALSE

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Mar 2019 10:45:30 +0900

On Mon, Mar 25, 2019 at 10:10 AM Mark Smith <[email-masked]> wrote:

> Accept packets with local source addresses.
>

I believe "local source address" means "IP address assigned to this node".

---

From: Erik Kline <[email-masked]>
Date: Mon, 25 Mar 2019 08:17:56 +0100

Rolling up replies.

I think all these concerns are addressable.

Yes, this kind of loopback testing might not currently be doable on
some operating systems without more control levers.  But the kernel
could easily arrange to permit and inspect loopback'd packets before
discarding them because the source address matched a local address.

And to Bob's point: I think it's correct to say that the policy
applied to the result of a "does this work" test is in fact a policy,
and is something that probably ought to be configurable.  But that
doesn't the negate the value of learning that the prefix has become
unusable (at a minimum it would be an administratively log-worthy
event, so someone can come along later and diagnose).

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 Mar 2019 08:53:51 +0100

Erik,

> On Mar 25, 2019, at 8:17 AM, Erik Kline <[email-masked]> wrote:
> 
> Rolling up replies.
> 

To address my concern, I think you need to first see if you can talk to the router at all, before attempting to verify the prefix.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Mar 2019 09:50:14 +0100

Hello, Erik,

Thanks for posting this. Inline....

> router no longer routes a PIO onto a link it should start some prefix

Would this be triggered upon receipt of, say, one (or two) RAs with PIOs
that don't include the previously-received prefix?

This seems to make sense...

> on-link GUA, could be a ping or a unicast NS or a UDP packet to a port

I'm not sure if a packet with a link-local address that would be bounced
back on the same link would be considered "source address out of scope"
by the router or not -- me thinking out loud (rather than making any
"statements").

> specified by a 2nd router...)

Agreed. If the packet does not bounce back, then the host should
"disassociate the prefix with this router" -- so to speak -- in the
context of RFC8028.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Mar 2019 09:51:42 +0100

> How do you make that happen if the prefix is on-link?

just force the destination link-layer address to be that of the
next-hope router -- i.e., bypass IPv6 routing for this packet...

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Mar 2019 09:55:27 +0100

Hi, Bob,

On 24/3/19 22:49, Bob Hinden wrote:
[...]>>
>> If a positive packet reflection occurs then that router still
>> routes the PIO onto the link. If there's no such response within
>> $TRIES across $SECONDS, then assume that router doesn't forwarding
>> that PIO onto the link.  (Note that the PIO might still be valid
>> on-link as specified by a 2nd router…)
> 

Agreed. That's why this "check" would be triggered by the receipt of
packets from the same router including PIOs for prefixes other than the
previously advertised one.

If the RA contains no PIOs, this check would not be triggered, and the
possibly-stale prefix would be kept.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Mar 2019 10:11:08 +0100

> To address my concern, I think you need to first see if you can talk to the router at all, before attempting to verify the prefix.

Wouldn't this verification being triggered by an "RA with PIOs that do
not advertise the previously-advertised prefix" address this?

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 Mar 2019 10:36:15 +0100

> On Mar 25, 2019, at 9:55 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bob,
> 

There has to be verified two way communication with the router.

Bob

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Mar 2019 10:06:00 +0000

Also, if source address ingress filtering being done by CPE or SP, wouldn’t there be icmp feedback to host that its source address is no longer good that can be used by host to perhaps trigger some action on address?

- Bernie

> On Mar 25, 2019, at 10:36 AM, Bob Hinden <[email-masked]> wrote:
> 
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 25 Mar 2019 11:18:07 +0100

>on-link GUA, could be a ping or a unicast NS or a UDP packet to a port

Assuming we are still talking about the problem introduced in 
draft-gont-6man-slaac-renum-01 (i.e. a CPE reboots and gets a new
prefix using DHCPv6-PD), this sounds like a rather heavy weight mechanism
for a relatively rare problem.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Mar 2019 10:37:37 +0000

Sorry, missed that this was covered in section C.1.

- Bernie

> On Mar 25, 2019, at 11:07 AM, Bernie Volz (volz) <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 25 Mar 2019 13:23:06 -0700

At Mon, 25 Mar 2019 09:50:14 +0100,
Fernando Gont <[email-masked]> wrote:

> by the router or not

It shouldn't be considered "source address out of scope", at least
protocol-wise.  See section 9 of RFC4007.  It doesn't explicitly show
an example of source=link-local and destination=global, but the
description of when the "beyond scope of source address" error applies
should be clear enough to understand this case shouldn't result in
that condition.  Most if not all BSD-variant OSes should fully conform
to this concept of RFC4007 and should forward the packet back to the
original link as expected.

I wouldn't be surprised, however, if there's a buggy implementation
that precludes any kind of forwarding simply when the source (or
destination for that matter) address is link-local.  I'd be
particularly curious if any Linux kernel version has this kind of bug,
since some widely deployed CPE routers may be developed on some flavor
of Linux.

--
JINMEI, Tatuya