Subject: SLAAC protocol improvements for flash renumbering (Fwd: New Version Notification for draft-gont-6man-slaac-renum-02.txt)

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 01:45:44 -0300

Folks,

We have posted a revision of our document with a proposal for SLAAC 
protocol tweaks to improve its robustness to renumbering events.

The revised I-D is available at: 
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-02.txt

This version should be way easier to read.

Besides, part of the contents in earlier versions of the draft have 
moved out into other (stand alone) documents:

* draft-gont-v6ops-slaac-renum: Problem statement & operational mitigations

* draft-gont-v6ops-cpe-slaac-renum: Recommendations for Customer Edge 
Routers

Your feedback will be highly appreciated.

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-slaac-renum-02.txt
Date: Sun, 16 Feb 2020 19:45:36 -0800
From: [email-masked]
To: Fernando Gont <[email-masked]>, Jan Zorz <[email-masked]>, 
Richard Patterson <[email-masked]>

A new version of I-D, draft-gont-6man-slaac-renum-02.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-slaac-renum
Revision:	02
Title:		Improving the Robustness of Stateless Address Autoconfiguration 
(SLAAC) to Flash Renumbering Events
Document date:	2020-02-16
Group:		Individual Submission
Pages:		18
URL: 
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
Htmlized:       https://tools.ietf.org/html/draft-gont-6man-slaac-renum-02
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-02

Abstract:
    In renumbering scenarios where an IPv6 prefix suddenly becomes
    invalid, hosts on the local network will continue using stale
    prefixes for an unacceptably long period of time, thus resulting in
    connectivity problems.  This document improves the reaction of IPv6
    Stateless Address Autoconfiguration to such renumbering scenarios.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 11:50:44 +0100

Hi, thank you for this.

I want to suggest that you move the section 4.3/4.4 to
draft-gont-v6ops-cpe-slaac-renum, but I can't find this document to be sure.
Maybe you are still posting it.

Then, this document is all about updates to the Host side only.

Note the section 4.1.1 updates what the valid values are, and while that seems
like advice to routers, it's rather advice to hosts as to what they should
accept as valid.

I think that 4.2, in the section about attacks, could suggest that when a
suspicious RA is seen (such as Lifetime=0), that the host might want to check
with a unicast RS (with a randomized delay).

I like section 4.4, and I really think it's actually the meat of this
document.  I think that the title of the document should be less about Flash
Renumbering, and just about "Improved Host Behaviour for Router Advertisements"
or some such.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 09:03:08 -0300

Hello, Michael,

Thanks for the great feedback and timely response! In-line....

> Then, this document is all about updates to the Host side only.

Note:
Section 4.4 is a host-side update. It does benefit from the router-side 
change proposed in Section 4.3, though.

> like advice to routers, it's rather advice to hosts as to what they should

Indeed, the default values are to be employed by routers. That said, 
Section 4.1.2 is about processing of such values by hosts, where we 
suggest to cap them.

At the end of the day, when routers use more appropriate values, even 
legacy systems would benefit from that. And even if routers don't use 
appropriate values, a host can do better by capping the received value 
to something that makes more sense.

> with a unicast RS (with a randomized delay).

My take is that modulo some sanity checks you can perform on some ND 
packets, since the protocol is inherently insecure, you trust the 
router, or you don't.

Note that, e.g. when you receive an RA with a Router Lifetime of 0, you 
just honor it without cheking with a unicast RS....

> Renumbering, and just about "Improved Host Behaviour for Router Advertisements"

I'd agree that most of the meet is in Section 4.4. That said, at the end 
of the day the goal is to improve the behaviour of SLAAC in renumbering 
scenarios... and doing the right thing at routers does help a bit. So 
I'd rather keep the router parts, too.

But we're certainly open for the wg to change our mind ;-)

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 13:37:24 +0100

Fernando Gont <[email-masked]> wrote:
    >> draft-gont-v6ops-cpe-slaac-renum, but I can't find this document to be
    >> sure.  Maybe you are still posting it.
    >>

    > Note: Section 4.4 is a host-side update. It does benefit from the
    > router-side change proposed in Section 4.3, though.

Yes, I think that the update should be split between which end needs to
implement it.

    >> document.  I think that the title of the document should be less about
    >> Flash Renumbering, and just about "Improved Host Behaviour for Router
    >> Advertisements" or some such.

    > I'd agree that most of the meet is in Section 4.4. That said, at the
    > end of the day the goal is to improve the behaviour of SLAAC in
    > renumbering scenarios... and doing the right thing at routers does help
    > a bit. So I'd rather keep the router parts, too.

The issue is that I want to have a separate checkbox on routers
and hosts for whether they include the updates.
Q: "Do you support RFCXXXX"?
A: Well, yes, but not sure what to do with section 4.3, since we aren't a router,
   so we aren't compliant.

Routers can include host functionality, so they might implement both.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 09:53:20 -0300

> A: Well, yes, but not sure what to do with section 4.3, since we aren't a router,

I see your point. HOw about if we were to re-arrange the sections into 
"Host specification" and "Router specification", so to speak, within the 
same document?

At the end of the day, e.g. both the host-side and the router-side of 
slaac are specified in the same document (RFC4862).

Thoughts?

Thanks!

Cheers,

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 23 Feb 2020 15:31:48 -0500

Fernando

The focus of this draft is primarily for the RFC 4941 privacy extension
temporary address current VL 7 PL 1 and future bis version VL 2 PL 1
employed for outgoing connections.

As for the network side RA sent my the router SLAAC PIO address given that
the VL is 30 days and PL 7 days since the last RA is periodic by default
the stable address never ages or gets renumbered as long as the host
endpoints NIC remains on the same subnet.  So for those apps using stable
address for “server like” are not impacted by renumbering event.  The
address can be considered permanent even as opposed to stable if the device
is not mobile or stationary always on and UP device.

When the flash renumbering occurs for outgoing client-like connections at
the VL expire time - at that time long lived connections still using the
now invalid address would be reset and so it’s those long lived connections
that are reset.

So the main goal of this draft is to address that renumbering event.

Maybe we should clarify that in the introduction and abstract.

Kind regards

Gyan

On Wed, Feb 19, 2020 at 11:46 PM Fernando Gont <[email-masked]>
wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Feb 2020 14:56:57 -0500

> I see your point. HOw about if we were to re-arrange the sections into "Host
    > specification" and "Router specification", so to speak, within the same
    > document?

I still would prefer separate documents, but I know the IESG is less fond of
more documents.   Maybe the router side stuff could into another document.

    > At the end of the day, e.g. both the host-side and the router-side of slaac
    > are specified in the same document (RFC4862).

I think that was a mistake, but I'm sure it made sense at the time.
I don't feel strongly about this though.