Subject: [v6ops] SLAAC host moving between networks

From: Florian Obser <[email-masked]>
Date: Tue, 6 Nov 2018 12:34:38 +0100

Hi,
When an IPv6 host moves between networks using SLAAC it accumulates
unusable addresses over time.

For example a laptop is used in the office where 2001:db8:23::/64 is
advertised and configures two IPs (RFC 7217 and RFC 4941). At the end
of the day the lid is shut, the laptop suspends and is taken home.

At home 2001:db8:42::/64 is advertised. The lid is opened and the
laptop wakes up. This is treated as a (re-)attachment to a link and a
router solicitation is send (RFC 4861 Section 6.3.7). Now the laptop
has 4 addresses, two from 2001:db8:23::/64 and two from 2001:db8:42::/64.

Only the addresses from 2001:db8:42::/64 are usable to reach the
Internet since the next hop for 2001:db8:23::/64 is unreachable.

If the host does not implement rule 5.5 "Prefer addresses in a prefix
advertised by the next-hop." of RFC 6274 Section 5 addresses from both
prefixes are treated equally valid and stay in the candidate set for
source address selection. Rule 8 is probably going to be the tie
breaker "Use longest matching prefix" meaning some destinations can be
reach while others can't.

A similar problem arises when the host moves to a network with
legacy-IP only.

While moving SLAAC from the original KAME kernel implementation to a
user land implementation ( slaacd(8) - https://man.openbsd.org/slaacd )
in OpenBSD I couldn't find any guidance in the RFCs regarding how to
handle this case.

The general spirit in the RFCs seems to be to keep the addresses
around until the valid lifetime expires (the address becomes invalid),
there is no other suggestion that one should delete addresses earlier.

So I asked the usual suspects at the 103 welcome reception and the
knee jerk reaction was:
Hum, interesting.
Delete the IPs when the interface goes down.
No wait, when the interface comes up.
No, hang on, when the interface comes up you send a solicitation and
if you don't get an answer from the old router delete the addresses
and form new ones, otherwise you might flood the neighbor table of the
router because you generate privacy addresses like crazy.

I note that my work Mac gets this right by some heuristic that deletes
addresses. There are no issues moving between networks - including
moving to legacy IP only.

In OpenBSD I'm setting the preferred lifetime to 0 when the link comes
up and restore it if a router advertisement is seen with that
prefix. This works nicely when moving between IPv6 networks but causes
problems when moving to legacy-IP only.

Anecdotal evidence suggests that FreeBSD just keeps the old IPs around
and on Linux it depends on what software you are using(?).

Network-manager seems to delete all the IPs and then restores them on wake
up, i.e. you don't get new privacy IPs. Kinda like the Mac behaviour
but the Mac seems to keep the IPs around at first and only deletes them
later while linux deletes the IPs on suspend.

Did I miss an RFC / RFCs that provides more guidance? If not, this
doesn't seem to be a completely trivial problem and I think we should
have some words on it. (I only mentioned the easiest case so far,
I have more complicated scenarios.)

Thanks,
Florian

-- 
I'm not entirely sure you are real.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 19:22:14 +0700

Hi Florian,

I just realized that this is the same problem we described in RIPE-690 to recommend persistent prefixes, because when a CPE has a power outage, if the ISP is changing the prefix, hosts may keep the original one, and not be able to communicate for a while ...

One CPE vendor seems to keep the prefix in flash, so if it gets changed across a reboot or WAN down/up, then can send RA with lifetime 0 to the LANs ...

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Florian Obser <[email-masked]>
Fecha: martes, 6 de noviembre de 2018, 18:35
Para: <[email-masked]>
Asunto: [v6ops] SLAAC host moving between networks

    Hi,

    

    

    

    

    Thanks,
    Florian

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Nov 2018 13:43:44 +0100

> I just realized that this is the same problem we described in
> RIPE-690 to recommend persistent prefixes, because when a CPE has
> a power outage, if the ISP is changing the prefix, hosts may keep
> the original one, and not be able to communicate for a while ...

To some extent, host support for multiple upstream routers should fix
this issue. I.e., a host should tie a SLAAC prefix to the default router
that announced the prefix. 

If the ISP changes the prefix then the host would notice that an existing
SLAAC prefix is no longer tied to any default router. 

In address selection, the host should then prefer the new prefix over
the old one.

This has no effect on exiting connections, but there is not much you can do
anyhow.

It also doesn't prevent stale addresses form staying around. I guess the
host can safely reduce the remaining lifetime to 2 hours. It should be safe to
do that on every link down event.

Some kind of link-change detection RFC might be useful. Though this ties
in with mac addess randomization.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 6 Nov 2018 12:57:53 +0000

> in with mac addess randomization.

+ adds state.  This is not a criticism, just an observation that there's 
a conflicting set of requirements here between maintaining state and not 
maintaining state.  In the case of e.g. CPEs rebooting and being 
assigned different prefixes, there isn't an existing way of doing this. 
Perhaps we need a mechanism to poll the issuing router to see if the 
prefix is still valid?

Nick

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Nov 2018 14:05:27 +0100

>Perhaps we need a mechanism to poll the issuing router to see if the 

In the context of mac address randomization, this is what I think ideally
a host should do:
- if a host attaches to a new link it should use a new mac address, new IIDs
  but also prevent any packets with old addresses from going out
- if a host re-attaches to the same link it was before it should keep all 
  addresses unchanged.

I think this is rather tricky to get right. 

Simply checking if an old prefix would work on the new link would violate
these principles.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 20:28:57 +0700

It is much better to educate ISP so they understand that with IPv6 there is no need to change prefixes, so they should not do that. They can also offer new services in an easier way if the prefix is persistent ...

Regars,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Nick Hilliard <[email-masked]>
Fecha: martes, 6 de noviembre de 2018, 19:58
Para: Philip Homburg <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    
    Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 6 Nov 2018 13:32:45 +0000

JORDI PALET MARTINEZ wrote on 06/11/2018 13:28:
> It is much better to educate ISP so they understand that with IPv6
> there is no need to change prefixes, so they should not do that. They
> can also offer new services in an easier way if the prefix is
> persistent ...

it's a question of where you want the state to reside in your network: 
at the ISP, at the CPE or on the host. Previously, NAT gave us the 
capability to abstract away the state from both the ISP and the host, by 
putting it into the CPE.

Nick

---

From: Clark Gaylord <[email-masked]>
Date: Tue, 6 Nov 2018 09:04:17 -0500

On Tue, Nov 6, 2018, 08:29 JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> It is much better to educate ISP so they understand that with IPv6 there
> is no need to change prefixes, so they should not do that. They can also
> offer new services in an easier way if the prefix is persistent ...
>
> Regars,
> Jordi
>

While this may be worthwhile (arguable) it is also irrelevant. Prefixes
change, even if you think you know the business of the errant ISP more than
they do. Hosts need to do something reasonable when they change. Neither
using invalid addresses nor growing the list of no-longer-valid-addresses
without bound qualify as "reasonable".

--ckg

-- 

--
Clark Gaylord
[email-masked]
... Autocorrect may have improved this message ...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 21:11:28 +0700

Not saying I don’t agree that host should be able to know it … and do something about that.

The point is that, is not the same if it changes and the CPE knows it (lifetime, same or new prefix), etc., or if it changes when the CPE is rebooting and the CPE doesn’t know that it has been changed, but in the LANs is still remembered the old one.

With persistent prefixes we solve that case at least.

Saludos,

Jordi

De: v6ops <[email-masked]> en nombre de Clark Gaylord <[email-masked]>
Fecha: martes, 6 de noviembre de 2018, 21:05
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

On Tue, Nov 6, 2018, 08:29 JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Regars,
Jordi

While this may be worthwhile (arguable) it is also irrelevant. Prefixes change, even if you think you know the business of the errant ISP more than they do. Hosts need to do something reasonable when they change. Neither using invalid addresses nor growing the list of no-longer-valid-addresses without bound qualify as "reasonable".

--ckg

-- 

--
Clark Gaylord
[email-masked]
.... Autocorrect may have improved this message ... 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Gert Doering <[email-masked]>
Date: Tue, 6 Nov 2018 15:53:59 +0100

Hi,

> It is much better to educate ISP so they understand that with IPv6 there is no need to change prefixes, so they should not do that. They can also offer new services in an easier way if the prefix i…

This does not help my laptop when it moves from office to home network
(which was the original question).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 22:18:06 +0700

Agree, I said that in the following post ("Not saying I don’t agree that host should be able to know it … and do something about that"), either I missed sending it because the jet lag, or it hasn't arrived to the list ...

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Gert Doering <[email-masked]>
Fecha: martes, 6 de noviembre de 2018, 21:54
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Hi,

    
    Gert Doering
            -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 00:54:46 +0700

> unusable addresses over time.

That sounds like an implementation bug. Widely-used implementations do not
do this.

This is what our implementation has been doing for several years.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 6 Nov 2018 21:47:28 +0000

> (which was the original question).

if your laptop does that, then surely it will see an interface flap on 
the interface used for its default route?  In this case, any existing 
ipv6 prefixes should be scrubbed from the interface.  If they aren't, 
this is an implementation bug.

If there aren't any interface flaps, then this would be ipv6 mobility.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Nov 2018 11:52:02 +1300

> this is an implementation bug.

Agreed. I routinely move my laptop between home and office, and I used
to sometimes see sticky addresses on Windows 7, but the source address
selection algorithm never picked them so it didn't  matter. I haven't
seen sticky addresses since I switched to Windows 10.

   Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 6 Nov 2018 23:10:47 +0000

Regars,
Jordi

--ckg

<bhs> Privacy experts (inside and outside IETF) recommend changing assigned prefixes about every day. Maybe IETF participants need to be better educated on privacy implications of static IPv6 prefix assignments.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 7 Nov 2018 10:33:38 +1100

It’s all trade offs.  You can have both static and dynamic prefix delegations driven by the client
with DHCPv6 today.  What would be nice is a RA option / flag to say that a prefix is expected to be dynamic so this can be signalled to the node.

Mark

> On 7 Nov 2018, at 10:10 am, STARK, BARBARA H <[email-masked]> wrote:
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 7 Nov 2018 10:43:26 +1100

> unusable addresses over time.
<snip>

> I have more complicated scenarios.)

It's a long time since I did something related and thought about this
(the CPE scenario Jordi mentioned).

I thought I'd read in an RFC somewhere that the one of the factors in
source address selection was the value of the preferred lifetime of an
address, so addresses with greater value preferred or valid lifetimes
would be preferred as a tie breaker.

However, I can't seem to remember which RFC, so maybe I just thought
it would be that way and then an implementation I looked at worked
that way.

Using higher value lifetimes to tie break isn't necessarily going to
work reliably - the preferred and valid lifetimes used on the new
network may be smaller than the past networks', so the past networks
addresses would be preferred. In my casual experiment the lifetime
values were all the same, so the newer learned prefixes/addresses
naturally had greater value lifetimes.

Perhaps an idea is that when a host's link comes up and it issues an
ND RS and receives corresponding ND RAs, it then uses the set of
received RA PIOs to determine which of the existing addresses on the
interface are valid.

For addresses outside of those RA PIO prefixes, it could either
immediately mark them as invalid or remove them. Applications using
them would get an immediate notification that communications using
those addresses has failed.

A more conservative approach could be to mark them as deprecated,
allowing applications to continue to try to use them (see RFC4862,
5.5.4.  "Address Lifetime Expiry" for some more discussion) although a
drawback would be that to end-user applications it would look like
packet loss and rely on relatively long multi-second timeouts to
determine that communications has failed for these addresses.

There is a corner case where using RA PIOs to validate wouldn't work,
and that is where there aren't PIOs in the RAs.

That can be valid if stateful DHCPv6 is used for address assignment
(i.e. no SLAAC used on the link), and all hosts are to send all
traffic to all destinations (except Link Local ones) via their default
router (i.e. no prefixes marked as on-link).  In other words, with no
SLAAC and no-link prefixes, hosts don't need to be provided with any
RA PIOs. In that scenario the hosts' existing SLAAC addresses could be
immediately removed/deprecated, and the existing stateful DHCPv6
addresses confirmed to be valid using a DHCPv6 mechanism, probably
Renew.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 7 Nov 2018 11:01:53 +1100

> this is an implementation bug.

Doing that blindly can be a mistake, an interface flap doesn't necessarily
indicate that the interface has been attached to a different network.

It was by accident, however a long time ago I moved a patch lead from one
switch to another unintentionally, with both switches part of the same LAN.
My Linux host didn't consider that to be fatal, and my telnet session
continued to work.

This makes sense as the host treated its interface flapping as though it
was a transient packet loss issue. It didn't place any significance on the
point of packet loss being at one of its direct interfaces instead of
somewhere else in the network.

So when the link came back up, the implementation assumes that all it
needed to do to recover to was to retransmit an packets that had been lost.
I think it is also generally consistent with the weak host model, where
addresses are "owned" by the host, rather than the specific interfaces
they're configured on, meaning that even if the interface goes down, the
host still considers the interface addresses valid, and can use the address
and receive traffic to it on any of its other interfaces.

The trick is to determine whether the same or different networks are being
attached to. That's the problem that RFC6059 - "Simple Procedures for
Detecting Network Attachment in IPv6" is addressing, although I don't know
if and how widely it is implemented:

"Detecting Network Attachment allows hosts to assess if its existing
   addressing or routing configuration is valid for a newly connected
   network.  This document provides simple procedures for Detecting
   Network Attachment in IPv6 hosts, and procedures for routers to
   support such services."

https://tools.ietf.org/html/rfc6059

Regards,
Mark.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 07 Nov 2018 07:48:44 +0700

I think basing privacy in the prefix is persistent or not is a broken concept.

It is one of the parameters for privacy, but there are better and more reliable ways to track users if someone want to do that, because they can’t be sure the prefix is persistent …

Just take a look to:

http://webkay.robinlinus.com/

or

https://panopticlick.eff.org

I feel that it is much more important to be able to define services by names, with stable addresses that anything else.

Of course, if the user prefers not to have a stable prefix, I’ve seen ISPs that in the “control panel” allow the user to choose that option.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
Fecha: miércoles, 7 de noviembre de 2018, 6:11
Para: 'Clark Gaylord' <[email-masked]>, JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

Regars,
Jordi

--ckg

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 7 Nov 2018 03:26:09 +0100 (CET)

On Wed, 7 Nov 2018, Mark Smith wrote:

> was a transient packet loss issue. It didn't place any significance on 
> the point of packet loss being at one of its direct interfaces instead 
> of somewhere else in the network.

My opinion on this is that for servers this makes sense, but for most 
users they're most helped by just taking away all addresses on an 
interface when it goes down and let application re-connect.

This is also what most connection managers do by default for desktop 
applications. Interface down -> remove addresses. If you attach again and 
then use the same address, that's fine. If you're using privacy addresses, 
most likely you won't have the same one again so outgoing connections will 
have to be re-established.

Now, I fully support all your suggestions on enhancements to detect if the 
same network comes back up again after the flap, but if one doesn't have 
that then it's better for desktop applications to remove the addresses at 
link-down and just re-start everything at link-up. To keep addresses on an 
interface that went down and do no detection of "did I connect to the same 
network again and if I didn't THEN wipe the addresses" will just harm 
users (as OP noticed).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jen Linkova <[email-masked]>
Date: Wed, 7 Nov 2018 13:34:34 +1100

> it would be that way and then an implementation I looked at worked

It wasn't an RFC, it was my draft:
https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00

It expired because nobody seems to be interested in implementing this.
If we can have an implementation I'd be more than happy to revive the
document.

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Wed, 7 Nov 2018 14:01:59 +1100

> unusable addresses over time.

It looks like a bug to me. The device gets disconnected from one
network and connects to another so addresses need to be reconfigured.
I've not seen such behavior for a while (but it reminds me a but
Windows used to have with 802.1x and IPv4, when 802.1x
re-authentication did not trigger IPv4 address reconfiguration).
The main question is 'how to tell if it's the same or different network'.
Do both network routers have the same LLA by any chance?

I wonder what happens with IPv4 config in those cases...Does your
laptop keep the same v4 address as well?

> there is no other suggestion that one should delete addresses earlier.

Well, I'd expect that disconnecting from one network and reconnecting
to another is a very clear signal
to re-initialize the network configuration. How does your laptop
behave when it is moved between VLANs as a result of 802.1x re-auth?
All sane implementations clear IPv[46] configuration (however I
remember that Network Manager used to have issues with it but  I was
told it's supposed to be fixed.)

> Did I miss an RFC / RFCs that provides more guidance?

I think what you are looking for is https://tools.ietf.org/html/rfc6059

> I'm not entirely sure you are real.

I'm not indeed.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 6 Nov 2018 22:35:45 -0800

We do have a RFC on the books which tried to address this:
RFC6059 Simple Procedures for Detecting Network Attachment in IPv6.

I don't know to what extent what's implemented matches what is in that 
RFC, but it does include forgetting about old prefixes and default 
routers when it detects the node is on a different link.

    Erik

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Nov 2018 10:20:05 +0100

> unusable addresses over time.

I do see this behaviour every now and then on some 4G modules on linux.

There are two reasons they accomulate unusable addresses:
- mid-way re-connection ('connection' on 4G has multiple intermediary
   states, as opposed to older 3G and 2.5G where only one state
   'connected' existed) brings a new prefix.
- privacy change of the Interface ID without deleting the old one.

Accumulating too many addresses is obviously a reason of concern.

There have been attacks on machines to overload them with too many 
addresses.

Alex

---

From: Gert Doering <[email-masked]>
Date: Wed, 7 Nov 2018 10:34:08 +0100

Hi,

> this is an implementation bug.

So, where is this written down?  (Which was part of the original question...)

Linux, for example, does not do that (unless some userland daemon takes
care of it).

I'm with you, though, that not doing this is causing annoyance - but 
doing this the way Windows does it ("all TCP sessions are killed right
away if the interface goes down") is causing even *more* annoyance...

> If there aren't any interface flaps, then this would be ipv6 mobility.

How can you get mobility without interface flaps?

(But that's a red herring, mobile IPv6 is even more dead)

Gert Doering
        -- NetMaster

---

From: Jen Linkova <[email-masked]>
Date: Wed, 7 Nov 2018 20:40:02 +1100

> So, where is this written down?  (Which was part of the original question...)

I believe it's  what https://tools.ietf.org/html/rfc6059 is about

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Nov 2018 18:32:57 +0700

> On Nov 7, 2018, at 5:52 AM, Brian E Carpenter <[email-masked]> wrote:
> 

I am been at the IETF all week, and have used several different links.  I only have three IPv6 address (link-local, global, global temporary), no old ones, nor the ones I get when at home.

Seems fine to me.

Bob

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 7 Nov 2018 13:17:18 +0000

> How can you get mobility without interface flaps?

openvpn, obviously :-)

Nick

---

From: Florian Obser <[email-masked]>
Date: Wed, 7 Nov 2018 15:27:59 +0100

Thanks Mark, Jen and Erik,
RFC6059 was indeed what I was looking for.
I'm going to implement this in slaacd(8) soonish.

---

From: Gert Doering <[email-masked]>
Date: Wed, 7 Nov 2018 20:40:11 +0100

Hi,

> > How can you get mobility without interface flaps?

OpenVPN is obviously the right answer to every problem related to
networking ("if all you have is a hammer...") - but I'm afraid the
IETF will frown upon it...

Like, no committees involved in the protocol design, no myriard of
negotiation options, useful debug output, and works across today's
real world networks.  (Though the list of openvpn cli options definitely
looks like it could have come out of an IETF standardization process)

Gert Doering
        -- NetMaster

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 7 Nov 2018 23:39:40 +0000

In-line with “<bhs>”.
Barbara

I think basing privacy in the prefix is persistent or not is a broken concept.
<bhs> The IP address is widely used by data aggregators when combining multiple data sets. Apparently, data aggregators don’t think using IP address to violate people’s privacy is a broken concept.

It is one of the parameters for privacy, but there are better and more reliable ways to track users if someone want to do that, because they can’t be sure the prefix is persistent …
<bhs> Persistence of the prefix varies per ISP, and data aggregators know which ISPs change users addresses and how frequently. But stating that varying the IP address makes it less useful to data aggregators as part of making a case for not varying the IP address is a bit strange to me. Your proposal is effectively that we should make the IP address more useful to data aggregators for dataset combination by making it persistent.

Just take a look to:
http://webkay.robinlinus.com/<https://urldefense.proofpoint.com/v2/url?u=http-3A__webkay.robinlinus.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=39IZ4gcvTh4yNIHao2YmGPldEzMPnJ6jX_y-ssHcGFk&s=4Kcb7WoUV31IuY_6TMrHPw5vqmxdekncbRhnKPxP1BA&e=>
or
https://panopticlick.eff.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__panopticlick.eff.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=39IZ4gcvTh4yNIHao2YmGPldEzMPnJ6jX_y-ssHcGFk&s=TfuvvRl8LchUuuu9iLjFFeUABFNwOHRbg9dMlK91FQU&e=>

<bhs> I disagree.

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 09:50:15 +0700

Hi Barbara,

If an ISP allows persistent prefixes depending on customer preference, the ISP don’t know if actually it is persistent or not.

This is like “believing” that people don’t change the MAC address. You don’t know, so you can’t be sure.

Technology has to be made to be useful and as simple as possible.

Using “extreme” privacy considerations for complicating the technology is a bad balance compared with laws that already disallow those data aggregators to collect the data. For example, in EU IP addresses are considered personal data, which means that data aggregators can’t collect them. This allows to use persistent prefixes and if somebody is doing something wrong, is not “against” the technology simplification (so you can have you own DNS services at home and no need for complex/expensive/slower dynamic DNS things), but “against” the law, with fines up to 20 million euros.

I wish it is not only fines, but jail for any repeated or massive action against GDPR , but this is what we have now.

Regards,

Jordi

De: "STARK, BARBARA H" <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 6:40
Para: 'JORDI PALET MARTINEZ' <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: [v6ops] SLAAC host moving between networks

In-line with “<bhs>”.

Barbara

Just take a look to:

or

<bhs> I disagree. 

Regards,

Jordi

---

From: Clark Gaylord <[email-masked]>
Date: Wed, 7 Nov 2018 21:59:07 -0500

On Wed, Nov 7, 2018, 21:51 JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

Using “extreme” privacy considerations for complicating the technology is a
> bad balance compared with laws that already disallow those data aggregators
> to collect the data. For example, in EU IP addresses are considered
> personal data, which means that data aggregators can’t collect them
>

Sigh.

"An address is an accident of geography” --me

:-)

--ckg

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 8 Nov 2018 03:38:48 +0000

As an example, here is how one data aggregator/broker describes how useful it is for them when IP addresses don’t change.
https://www.vicimediainc.com/often-ip-addresses-change/

You may have GDPR. Most of the world does not. I do not. If you want to create a recommendation that is specific to EU ISPs, go for it (assuming they all agree). But please make it very, very clear that it *only* applies to EU ISPs. I’m also still waiting to see just how successful GDPR will be in discouraging websites in non-EU countries from collecting any and all data from people behind European IP addresses. And foreign governments (which may be wanting to harm EU countries and citizens) are completely free to track EU citizens when they can lure those citizens to their “sponsored” websites.

I will continue to recommend IP address assignments *not* be static.
Barbara

From: JORDI PALET MARTINEZ <[email-masked]>
Sent: Wednesday, November 07, 2018 9:50 PM
To: STARK, BARBARA H <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] SLAAC host moving between networks

Hi Barbara,

Regards,
Jordi

De: "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Fecha: jueves, 8 de noviembre de 2018, 6:40
Para: 'JORDI PALET MARTINEZ' <[email-masked]<mailto:[email-masked]>>
CC: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: RE: [v6ops] SLAAC host moving between networks

In-line with “<bhs>”.
Barbara

Just take a look to:

Regards,
Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.theipv6company.com&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=dj_Hm63fn3uw0HsqgNYYWW2npGLGQVR2QC_OrZH5joU&s=nKRyUyhZEU-XH7lHLyLjbk0U2vN9VrxNJhlglZNrYck&e=>
The IPv6 Company

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Nov 2018 10:42:56 +0700

Jordi,

>  For example, in EU IP addresses are considered personal data, which means that data aggregators can’t collect them.

Does this apply to Street addresses too?  If someone lives in the EU, can they move and keep the same street address?

Bob

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 10:47:08 +0700

GDPR affects anyone willing to do business with EU citizens or residents.

Not that I’ve any relation with this site or the blog author, just google for it:

https://blog.returnpath.com/gdpr-impact-for-non-eu-companies/

Regards,

Jordi

Fecha: jueves, 8 de noviembre de 2018, 10:39

Barbara

Hi Barbara,

Regards,

Jordi

In-line with “<bhs>”.

Barbara

Just take a look to:

or

<bhs> I disagree. 

Regards,

Jordi

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Nov 2018 10:49:26 +0700

On Thu, Nov 8, 2018 at 2:40 AM Gert Doering <[email-masked]> wrote:

> real world networks.

... and always forces all traffic to go through a centralized point,
increasing latency and potentially creating surveillance opportunities.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 10:50:00 +0700

Hi Bob,

No that I know !

But I'm not asking either for a prefix to be persistent if you move to a new house :-)

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Bob Hinden <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 10:43
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Jordi,

    
    Bob

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 8 Nov 2018 04:07:26 +0000

I’m done responding. I’ve made my position clear.
Barbara

https://blog.returnpath.com/gdpr-impact-for-non-eu-companies/<https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.returnpath.com_gdpr-2Dimpact-2Dfor-2Dnon-2Deu-2Dcompanies_&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=iqw7zBrbpMzK1NNIJUhEJp3g0gGJYmBvRGfunmcRQCg&s=nHwEBYHoFwrF9VpAdi861tfOYlcbuvkhy5kSZZlAMTg&e=>

Regards,
Jordi

As an example, here is how one data aggregator/broker describes how useful it is for them when IP addresses don’t change.
https://www.vicimediainc.com/often-ip-addresses-change/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.vicimediainc.com_often-2Dip-2Daddresses-2Dchange_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=iqw7zBrbpMzK1NNIJUhEJp3g0gGJYmBvRGfunmcRQCg&s=UK17rEKaCcnvZPH1MM_94hIDR8X9PIsh9y7Anz1UMu4&e=>

From: JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 07, 2018 9:50 PM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] SLAAC host moving between networks

Hi Barbara,

Regards,
Jordi

In-line with “<bhs>”.
Barbara

Just take a look to:

Regards,
Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.theipv6company.com&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=iqw7zBrbpMzK1NNIJUhEJp3g0gGJYmBvRGfunmcRQCg&s=Ac_5Z3_722-_fXuV-xSs50ntDq-jMdCAQx_QbvvbBnA&e=>
The IPv6 Company

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 11:48:29 +0700

I think this example may be more clarifying.

Laws protect me against people collecting (without my previous and explicit consent), my postal/street address and of course, sending postal mail to me (advertising, etc.). This was already possible before GDPR, but now is clearer and the fines are much higher.

Do we think it will be interesting, instead of having a law like that, to allow people to not have the street name in the street and the street number, etc. ?

Obviously not, as even the people you want to visit you, will not be able to do so.

Bringing privacy to that extreme is making technology complex and disallowing innovation.

Is like forbidding knives because you can kill someone.

What is forbidden is to collect personal data, to use it without consent, to collect postal addresses, to kill someone, but the tools are there for other reasons, and are needed.

We need to consider privacy in protocols, definitively, I'm 100% for privacy, but not at the cost of disallowing simple services. Laws need to take care of people using protocols for privacy violation.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 10:50
Para: Bob Hinden <[email-masked]>, JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Hi Bob,
    
    No that I know !

    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de Bob Hinden <[email-masked]>
    Fecha: jueves, 8 de noviembre de 2018, 10:43
    Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
    CC: "[email-masked]" <[email-masked]>
    Asunto: Re: [v6ops] SLAAC host moving between networks
    
        Jordi,

        
        Bob

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Nov 2018 07:30:56 +0100

> Do we think it will be interesting, instead of having a law like
> that, to allow people to not have the street name in the street
> and the street number, etc. ?
> 

Personally, I prefer stable prefixes, but I don't think it is such a great
idea to hardcode stable prefixes if it is relatively easy to support changing
prefixes.

There can always be an operational need to change a prefix, and yes you 
can first announce the old prefix with a preference of 0, before announcing
to new one, but likely many operators will forget to do that.

It seems to me that it is just a small change in address selection, i.e. when
comparing two prefixes and one is currently announced by a router and the
other isn't, then pick the one that is announced.

---

From: Florian Obser <[email-masked]>
Date: Thu, 8 Nov 2018 07:55:13 +0100

> other isn't, then pick the one that is announced.

It's already in there, it's just optional:

RFC 6724 Section 5:

   Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
   If SA or SA's prefix is assigned by the selected next-hop that will
   be used to send to D and SB or SB's prefix is assigned by a different
   next-hop, then prefer SA.  Similarly, if SB or SB's prefix is
   assigned by the next-hop that will be used to send to D and SA or
   SA's prefix is assigned by a different next-hop, then prefer SB.
      Discussion: An IPv6 implementation is not required to remember
      which next-hops advertised which prefixes.  The conceptual models
      of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
      have no such requirement.  Hence, Rule 5.5 is only applicable to
      implementations that track this information.

Combine this with Neighbor Unreachability Detection (RFC 4861 Section
7.3).

My kernel is not tracking from which nexthop prefixes got advertised,
it doesn't even process RAs.
But I think I'll implement that, too, in addition to RFC 6059.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 08:33:24 +0100

Hi,

> increasing latency and potentially creating surveillance opportunities.

This is purely a matter of local config.  Anything between "just the
tunnel transit (ifconfig) network" to "full default gateway redirection" 
can be done.

You might want to RTFM on "redirect gateway" and "route" options.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Nov 2018 14:36:49 +0700

> tunnel transit (ifconfig) network" to "full default gateway redirection"

s/all traffic/all traffic you want to be mobile/ . If you use a VPN for
mobility, then all traffic has to go through a VPN server.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 08:44:20 +0100

Hi,

> mobility, then all traffic has to go through a VPN server.

Sure, but *that* reply should have gone to Nick's post, not to mine.

Gert Doering
        -- NetMaster

---

From: Lee Howard <[email-masked]>
Date: Thu, 8 Nov 2018 02:44:58 -0500

> It is much better to educate ISP so they understand that with IPv6 there is no need to change prefixes, so they should not do that. They can also offer new services in an easier way if the prefix i…

Sorry. You can't have prefix stability. You have to let network 
operators manage their networks. This isn't an "educate ISPs" issue, and 
it's arrogant of you to suggest that it is.

If we need to reconstitute the 6renum working group to find ways to work 
with changing prefixes, I will support that. It seems to me that there's 
a combination of SDN, Anima, dynamic DNS, and Homenet technologies that 
will make it all work, but maybe there's some set of commonalities or 
defaults that need to exist in unmanaged networks that we need to define.

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 14:53:30 +0700

Note that I'm not advocating for persistent prefixes in different links, I'm guessing that some people has understood that.

What I meant is in the same link, same site, having the same prefix. We described this as "persistent" in RIPE-690.

If you change access technology, ISP, or location or your site, is fine to change the prefix, of course.

There are several options to make that happen, including DHCP option 37, or using an AAA/radius/whatever with the DHCPv6-PD, etc. So not asking something that is impossible or difficult to operate, many ISPs do.

Others just keep doing dynamic because they are used to in IPv4. That's what I mean with educating them. Not all them know that exist option 37, for example.

If we succeed to have a protocol that solves all the issues by means or renumbering, including changing DNS TTLs before the renumber happens, making sure that OS servers got it, etc., making sure operators implement that, etc., I will be happy to support that. But I think the balance among complexity vs gain in privacy vs operation cost vs etc., don't make sense at all.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Lee Howard <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 14:45
Para: <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    
    Lee

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Nov 2018 18:57:14 +1100

> On 8 Nov 2018, at 6:44 pm, Lee Howard <[email-masked]> wrote:
> 
> 
> Sorry. You can't have prefix stability. You have to let network operators manage their networks. This isn't an "educate ISPs" issue, and it's arrogant of you to suggest that it is.

Breaking network connections every day just because you can is not “managing a network”.  Its being actively hostile to your clients.  If a client wants to have different prefixes every day they can trigger that using PD as it currently stands.

> If we need to reconstitute the 6renum working group to find ways to work with changing prefixes, I will support that. It seems to me that there's a combination of SDN, Anima, dynamic DNS, and Homenet technologies that will make it all work, but maybe there's some set of commonalities or defaults that need to exist in unmanaged networks that we need to define.
> 
> Lee
> 
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 09:02:11 +0100

Hi,

> defaults that need to exist in unmanaged networks that we need to define.

I'm in.

I used to rant about ISPs that hand out changing prefixes, but I've
reconsidered - now I'm in the camp "ISPs should rotate prefixes very
frequently" (unless contractually agreeing on a stable prefix).

Why?  Because software needs to learn how to cope with changing prefixes,
and if the "change!" event happens only once a year, software will 
be perpetually broken in that regard.

In most typical home networks, a prefix change is not a real problem
today.  What does a home network user do?

 - request content from the Internet, mostly http/https, with short-
   lived sessions -> no problem (unless someone "smart" decides to code
   client IP address into a session cookie)

 - synchronize stuff with their iDevices -> no problem (using link-local
   and mDNS already today)

 - print -> no problem for some printers, larger problem for others
   (mDNS can be made to work, not all printer vendors get it right)

 - backup their laptop to their TimeMachine enabled storage

 - ...

One of the problems here is that none of the IETF participants are 
proper "home users".  So when people here complain about "but my
SSH sessions will break!" or "how can my SSH session know where the 
home server *is*, today?", you're already in the 0.1% camp.  And you 
know how to run your DNS zone, do dynamic DNS update, and use 
screen/tmux + mosh...

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 15:19:47 +0700

This is a utopia, even much more difficult to the transition from IPv4 to IPv6.

I think it is impossible we convince all the app providers that need to know the prefix/address change (in addition to Oss), to update DNSs before, to keep both addresses in the DNS, to change all the config files so they rely in a single place to look for "prefix" then configure addresses based on that prefix, etc., etc., etc.

Moreover, if I'm downloading/uploading a big file, having a work conference, editing an on-line file, or playing a game, or watching IPTV, or doing a SIP call, it will be broken with every prefix change. Is that acceptable?

Yes, we are those that have "special requirements", but those requirements aren't that much different than those that "regular" users are already have today, just see the previous list.

We have more and more stable access technologies, less network interruptions, and we want to artificially create them?

The operational cost for ISPs is much higher with this artificial prefix change than the cost of learning about option 37 and using it. That's not counting the additional cost for app developers, OS developers, hardware vendors, IETF standardization process, etc.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Gert Doering <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 15:02
Para: Lee Howard <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Hi,

    I'm in.

    

    
    
     - ...

    Gert Doering
            -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2018 15:31:32 +0700

In principle, when you change prefixes, this should occur while there is
still some valid lifetime on the old prefix, so if you are in the middle of
a download, unless the download goes longer than the valid lifetime of the
address, you should be okay.   But if it's a really long download, you need
to be able to restart it.   This is arguably true whether your prefix is
being changed routinely or not.

On Thu, Nov 8, 2018 at 3:20 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> I think it is impossible we convince all the app providers that need to
> know the prefix/address change (in addition to Oss), to update DNSs before,
> to keep both addresses in the DNS, to change all the config files so they
> rely in a single place to look for "prefix" then configure addresses based
> on that prefix, etc., etc., etc.
>
> Moreover, if I'm downloading/uploading a big file, having a work
> conference, editing an on-line file, or playing a game, or watching IPTV,
> or doing a SIP call, it will be broken with every prefix change. Is that
> acceptable?
>
> Yes, we are those that have "special requirements", but those requirements
> aren't that much different than those that "regular" users are already have
> today, just see the previous list.
>
> We have more and more stable access technologies, less network
> interruptions, and we want to artificially create them?
>
> The operational cost for ISPs is much higher with this artificial prefix
> change than the cost of learning about option 37 and using it. That's not
> counting the additional cost for app developers, OS developers, hardware
> vendors, IETF standardization process, etc.
>
> Regards,
> Jordi
>
>
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 15:36:56 +0700

This is assuming that you change the prefix in the right way …, not just dropping them to one customer and assigning to another at the same time, as operators are used to do this in IPv4 … This will also need “properly educate” them.

As said, just in terms of operator cost (also helpdesk), I think this is an operational complexity that has a higher cost than persistent prefix implementation.

Regards,

Jordi

De: Ted Lemon <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 15:32
Para: <[email-masked]>
CC: Gert Doering <[email-masked]>, Time Warner Cable <[email-masked]>, IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

In principle, when you change prefixes, this should occur while there is still some valid lifetime on the old prefix, so if you are in the middle of a download, unless the download goes longer than the valid lifetime of the address, you should be okay.   But if it's a really long download, you need to be able to restart it.   This is arguably true whether your prefix is being changed routinely or not.

On Thu, Nov 8, 2018 at 3:20 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Gert Doering <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 15:02
Para: Lee Howard <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Hi,

    I'm in.

     - ...

    Gert Doering
            -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2018 15:39:00 +0700

Yes.  If the ISP just slams your prefix every 24 hours without any overlap,
you have a problem.   And yes, doing it right isn't trivial.   But I would
argue that it's really a simple matter of programming—if this is a feature
that ISPs care about, the DHCP implementation isn't that hard.

On Thu, Nov 8, 2018 at 3:37 PM JORDI PALET MARTINEZ <
[email-masked]> wrote:

> This is assuming that you change the prefix in the right way …, not just
> dropping them to one customer and assigning to another at the same time, as
> operators are used to do this in IPv4 … This will also need “properly
> educate” them.
>
>
>
> As said, just in terms of operator cost (also helpdesk), I think this is
> an operational complexity that has a higher cost than persistent prefix
> implementation.
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> *De: *Ted Lemon <[email-masked]>
> *Fecha: *jueves, 8 de noviembre de 2018, 15:32
> *Para: *<[email-masked]>
> *CC: *Gert Doering <[email-masked]>, Time Warner Cable <[email-masked]>,
> IPv6 Ops WG <[email-masked]>
> *Asunto: *Re: [v6ops] SLAAC host moving between networks
>
>
>
> [email-masked] <[email-masked]>> wrote:
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 09:39:55 +0100

Hi,

> I think it is impossible we convince all the app providers that need to know the prefix/address change (in addition to Oss), to update DNSs before, to keep both addresses in the DNS, to change all…

Who is talking about DNS?  Who is talking about config files?

*This* is what the app providers need to come to understand - hardcoding
IP addresses in places is just the wrong way to go about it.

Some CPE vendors got this right already for their ACLs, for example - in
the AVM routers, you configure the ACL for the host part.  If the prefix
changes, no need to change the ACL, because the host part is the same
(provided no IID randomization happens, but for ACLs permits you need
stable host parts anyway).  Most others got stuck in last century,
unfortunately.

> Moreover, if I'm downloading/uploading a big file, having a work conference, editing an on-line file, or playing a game, or watching IPTV, or doing a SIP call, it will be broken with every prefix c…

Everything is moving towards short-lived https sessions anyway.  Those
just won't care if the client address changes.

But how long are you telephoning, anyway?  Bring in a new prefix, 
deprecate the old one, but *keep it working* for a few hours before
killing it.  Old phone call will go on until it ends, new phone call
will use the new prefix.

But this is precisely why mind-sets needs to change.  Prefix changes are
inevitable.  Period.  So make them happen *frequent*, like "once a day",
so people can stop hiding in their "THIS WILL NEVER WORK!" corner and
just make it work.

[..]
> We have more and more stable access technologies, less network interruptions, and we want to artificially create them?

The point is: prefix *will change*.    If you put hardcoded IPv6 addresses
everywhere, and things change once a year, you have lots of work to fix
all the places that you forgot about.

If you force a prefix change once per week or once a day, it will be
rough in the beginning but for unmanaged SoHo networks, eventually it
will be just transparent.

Mix in homenet, then you can even have multi-/48 multihoming very nicely
and transparently.

But I'm no longer going to spend time on this - I've made my point, a few
times, and in some 10 years, you'll agree with me.

(Of course, we can just use NAT66, and then you can have all your stable
prefixes forever :-) )

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2018 10:13:39 +0100

Hi Lee,

> If we need to reconstitute the 6renum working group to find ways to work with changing prefixes, I will support that.

Me too.

Cheers,
Sander

---

From: Jen Linkova <[email-masked]>
Date: Thu, 8 Nov 2018 20:36:03 +1100

On Tue, Nov 6, 2018 at 11:22 PM JORDI PALET MARTINEZ
> I just realized that this is the same problem we described in RIPE-690 to recommend persistent prefixes, because when a CPE has a power outage, if the ISP is changing the prefix, hosts may keep the…

I'd say 'similar but not the same. What you are describing is a router
violating CPE Requirement RFC.
Behavior described in this thread is more like a host behavior bug.

> One CPE vendor seems to keep the prefix in flash, so if it gets changed across a reboot or WAN down/up, then can send RA with lifetime 0 to the LANs ...

I'd like to point out that if a router does not deprecate a prefix if
it gets changed after reboot etc, the router clearly violates the
requirement L13 of RFC7084

---

From: [email-masked]
Date: Thu, 08 Nov 2018 10:36:40 +0100 (CET)

> so people can stop hiding in their "THIS WILL NEVER WORK!" corner and

This sounds like an excellent way to create irritated customers.

Steinar Haug, AS2116

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 10:47:00 +0100

Hi,

> This sounds like an excellent way to create irritated customers.

I would wager a guess that 99.9% of customers won't notice a prefix change
*at all* today.

Deutsche Telekom is changing /56 assignments to DSL customers "sometimes"
(the algorithm when it changes is not documented), and nobody seems to care.

OK, "today", most of the poorly written applications just use v4 anyway, 
so if v6 is there or not, or if it is changing has no real significance
on those - but for the long run, if we can make this work properly in a
non-v4 environment, this would be a huge win.

OTOH, I think I will be much better paid to work on people's NAT boxes
for the next 20 years, so I could care less.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 17:02:46 +0700

Hi Jen,

Something you're right ... is not the same. And yes, I just reread RFC7084 and is a violation.

However, unfortunately, only one vendor that I know is following that ...

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 17:56:23 +0700

If you have a DNS server inside that network, needs to know what prefix has been changed, need to coordinate the lifetime with the change, etc.

In addition to residential users, SMEs have this kind of things, and they will not pay for an enterprise internet service because is not needed.

We need to build a protocol so the router or the ISP tell the DNS server all that ...

Most of the IPTV apps that I've seen break even if the interruption is for very short time when changing the address, that means it is needed to play over the TV program using "fast forward". That not nice.

Probably is work that can be done in homenet.

I also agree that will be very nice to have that working, but it is a utopia.

Regards,
Jordi

-----Mensaje original-----
De: Gert Doering <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 15:39
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Gert Doering <[email-masked]>, Lee Howard <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Hi,

    

    

    [..]

    

    
    Gert Doering
            -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 12:06:13 +0100

Hi,

> If you have a DNS server inside that network, needs to know what prefix has been changed, need to coordinate the lifetime with the change, etc.

SoHo networks do not have DNS servers.  They have mDNS.

SME networks are either managed (in which case they would opt for "give
me a static prefix") or unmanaged, in which case the above rule applies.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 18:09:38 +0700

It is not that way in many countries ...

Regards,
Jordi

-----Mensaje original-----
De: Gert Doering <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 18:06
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Gert Doering <[email-masked]>, Lee Howard <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Hi,

    
    
    Gert Doering
            -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Thu, 8 Nov 2018 23:08:57 +1100

Hi Lee,

On Thu., 8 Nov. 2018, 18:45 Lee Howard <[email-masked] wrote:

> Sorry. You can't have prefix stability.

Not sure what you mean by that.

I've had the same stable IPv6 prefix for the past 7 years on my home
broadband connection, as have all residential IPv6 customers of my ISP
since 2010 (and I know that was the design, because I was one of the people
who worked on that IPv6 residential deployment).

You have to let network
> operators manage their networks.

The only issue is route aggregation.

With stable home broadband connections, you're not going to get a lot of
route churn, so your need for aggregation is driven by conserving route
table slots, rather than load caused by route flaps. (BGP assumed ...)

If you do need to aggregate, you can provide prefix stability without
guaranteed static assignment by e.g. defining a geographical area were
stability is provided.

If the customer moves within that area, they keep the same prefix. If the
customer moves out of that area, they get assigned a different stable
prefix.

I think there is a distinction between stable and static. Stable means the
ISP will try to avoid changing it, but don't guarantee they won't need to
at sometime in the future. A static prefix provides the guarantee of
permanent assignment and it is the guarantee the customer pays the premium
for.

This isn't an "educate ISPs" issue, and
> defaults that need to exist in unmanaged networks that we need to define.

If it can be made totally seamless and automatic, the those that want
changing prefixes should have them if possible. It is easier said than
done, which is why privacy experts saying a prefix should be changed every
24 hours suggests to me they may not have much understanding of what that
would entail to make it seamless and automatic.

Most people also have stable IPv4 addresses today, because one of the most
common BRAS implementations that I have experience with caches dynamic
address assignment from a pool and reallocates the same address to the same
authenticated user if they disconnect and then reconnect to the same BRAS.

Most ISPs seem to like a very small number of very large BRASes (unlike me)
at a service aggregation point, so the likelihood of being assigned the
same IPv4 address across disconnect/reconnect goes up.

If they have stable broadband connections, they can have the same IPv4
address for months, depending on their service (link) uptime and their BRAS
uptime.

If there is a privacy problem with stable IPv6 prefixes, there's a very
similar one with the inherently stable IPv4 addresses people have had for
the last 15 or so years since always-on residential broadband became
available. I'm not dismissing the privacy concern, just observing that it
has been an accepted one with IPv4 for quite a long time.

Regards,
Mark

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 13:27:44 +0100

Hi,

> permanent assignment and it is the guarantee the customer pays the premium

Indeed.  And I think "stable" is not something desirable in the long
run, because it leads to hardwiring IPv6 addresses in lots of places 
- and then, if it has to be changed one day (like "the cable plant 
being split into two, new prefix for half the customers") unhappiness 
ensues.

This is why I think that either you want *static*, or should avoid the 
impression of a prefix being "stable", whatever that means.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 8 Nov 2018 12:55:39 +0000

Gert Doering wrote on 08/11/2018 12:27:
> This is why I think that either you want*static*, or should avoid the

this usually works by being "mostly static".   I.e. the provider will 
assign a prefix which will probably remain static over reasonably long 
times, but they don't commit to anything.  The benefit to the user is 
that they don't get the annoyance of having prefixes changes every hour 
or day, and the provider gets the benefit of being to attach the 
customers to prefix pools with loose binding, which allows efficient 
dynamic assignment.

As Steiner hinted, there is no need to actively aggravate users.  If you 
do this, they will vote with the wallet and move to service providers 
which don't actively aggravate them, and end up with the impression that 
the cause of the aggravation is ipv6 rather than the service provider.

Nick

---

From: [email-masked]
Date: Thu, 08 Nov 2018 14:48:22 +0100 (CET)

> that they don't get the annoyance of having prefixes changes every
> hour or day, and the provider gets the benefit of being to attach the

In one sense, I agree with what has been expressed earlier - most
users don't know and don't care. However, a rather vocal minority
explicitly wants stable ("mostly static") IP addresses, which makes
it easier for them to run servers and similar. "Mostly static" is
fine, and they normally don't want to pay extra to have a *real*
static IP.

I have so far not heard from any users explicitly wanting addresses
that change on a regular basis.

Steinar Haug, AS2116

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Nov 2018 14:51:55 +0100

Hi,

> that change on a regular basis.

From how many users have you heard that ask for *any* sort of IPv6
addresses?

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Thu, 08 Nov 2018 15:20:09 +0100 (CET)

> From how many users have you heard that ask for *any* sort of IPv6

Probably too few to make it a statistically valid sample. But these
users certainly exist, and I've heard from at least some of them...

Steinar Haug, AS2116

---

From: Lee Howard <[email-masked]>
Date: Thu, 8 Nov 2018 10:14:44 -0500

On 11/8/18 7:08 AM, Mark Smith wrote:
>
>
> Hi Lee,
>
> On Thu., 8 Nov. 2018, 18:45 Lee Howard <[email-masked] 
> <mailto:[email-masked]> wrote:
>
>
>     > It is much better to educate ISP so they understand that with
>     IPv6 there is no need to change prefixes, so they should not do
>     that. They can also offer new services in an easier way if the
>     prefix is persistent ...
>
Thanks for making some technical points, as someone who worked at an 
ISP. . .
> With stable home broadband connections, you're not going to get a lot 
> of route churn, so your need for aggregation is driven by conserving 
> route table slots, rather than load caused by route flaps. (BGP 
> assumed ...)
>
> If the customer moves within that area, they keep the same prefix. If 
> the customer moves out of that area, they get assigned a different 
> stable prefix.

Not just "the customer moved" but "you moved the customer." Sometimes 
you get more users than one provider edge box can handle, and you have 
to move them to another edge box.

What happens then? The modem interface might blink, but that doesn't 
tell the router that anything happened. So it doesn't request a new 
prefix, and keeps using the one it had before. But the new PE box 
doesn't have a route for it, because there was no DHCPv6 exchange to 
snoop/glean. Even if you (or the customer, hopefully not after a call) 
bounce the home router, the new PE box installs a route, but how does 
the old box know to delete its route?

You said "if you do need to aggregate," but you always do, if you have 
more than a few thousand customers. Nobody wants ten million customer 
prefixes in their network. Really, nobody wants ten thousand prefixes in 
their IGP.

Really, nobody wants to maintain a table of ten million assigned 
prefixes, to be queried with every DHCPv6 request. The initial 
population of that table, and lookups, and moves/add/changes/deletions, 
requires a bit of automation that has no ROI. If I ran an ISP, I would 
not want to spend a lot of time developing features to retain my most 
expensive customers.

>
> I think there is a distinction between stable and static. Stable means 
> the ISP will try to avoid changing it, but don't guarantee they won't 
> need to at sometime in the future. A static prefix provides the 
> guarantee of permanent assignment and it is the guarantee the customer 
> pays the premium for.
>
I've tried to avoid saying "static prefix" because it's easily confused 
with "static route." I've generally said "persistent prefix" to mean 
that doesn't change (your "static"), and only referred to the relative 
stability or persistence of a prefix for one that may change.

> done, which is why privacy experts saying a prefix should be changed 
> every 24 hours suggests to me they may not have much understanding of 
> what that would entail to make it seamless and automatic.
>
> Most people also have stable IPv4 addresses today, because one of the 
> most common BRAS implementations that I have experience with caches 
> dynamic address assignment from a pool and reallocates the same 
> address to the same authenticated user if they disconnect and then 
> reconnect to the same BRAS.
>
> Most ISPs seem to like a very small number of very large BRASes 
> (unlike me) at a service aggregation point, so the likelihood of being 
> assigned the same IPv4 address across disconnect/reconnect goes up.
>
> address for months, depending on their service (link) uptime and their 
> BRAS uptime.
>
> If there is a privacy problem with stable IPv6 prefixes, there's a 
> very similar one with the inherently stable IPv4 addresses people have 
> had for the last 15 or so years since always-on residential broadband 
> became available. I'm not dismissing the privacy concern, just 
> observing that it has been an accepted one with IPv4 for quite a long 
> time.

This is a strong argument. My motivations are not so much to protect 
privacy (I'd like a privacy expert to explain the threat relative to 
other issues, considering how effective fingerprinting and cookies are) 
as the operational issues above.

But I also have an architectural principle that an IP address is a 
network locator and host identifier, just a set of integers, and relying 
on them not changing is ossifying the network.

RFC7010 "IPv6 Site Renumbering Gap Analysis" lists the stuff that needs 
to happen when a prefix changes. In short, it's how to notify everything 
of changes, updating DNS, firewall/ACL/policy stuff, and miscellaneous 
config bits. If DHCPv6 Reconfigure was supported and it was obvious how 
to declare a dDNS server, using wildcards for prefixes in firewalls and 
DHCP servers gets you 90% of the way there.

Lee

---

From: Lee Howard <[email-masked]>
Date: Thu, 8 Nov 2018 10:28:50 -0500

> customers to prefix pools with loose binding, which allows efficient 

I agree that users shouldn't have to do something to their network every 
time their prefix changes.

I think it's more sensible to build a dynamic network than to expect it 
to remain static.

>
> As Steiner hinted, there is no need to actively aggravate users. If 
> you do this, they will vote with the wallet and move to service 
> providers which don't actively aggravate them,

If this is your concern, then I propose we let ISPs and users sort it 
out between themselves.

I am very frustrated with people at the IETF trying to force protocol 
changes into their ISPs. The IETF is not the place to mediate conflicts 
between users and ISPs.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Nov 2018 08:39:22 +1300

> It's already in there, it's just optional:

It's raised to a SHOULD for hosts following RFC 8028.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 9 Nov 2018 13:41:59 +1100

Hi Lee,

On Fri, 9 Nov 2018 at 02:14, Lee Howard <[email-masked]> wrote:
> Thanks for making some technical points, as someone who worked at an ISP. . .
>
>
>
>
> With stable home broadband connections, you're not going to get a lot of route churn, so your need for aggregation is driven by conserving route table slots, rather than load caused by route flaps. (BGP assumed ...)
>
> If you do need to aggregate, you can provide prefix stability without guaranteed static assignment by e.g. defining a geographical area were stability is provided.
>
> If the customer moves within that area, they keep the same prefix. If the customer moves out of that area, they get assigned a different stable prefix.
>
> Not just "the customer moved" but "you moved the customer." Sometimes you get more users than one provider edge box can handle, and you have to move them to another edge box.
>
> What happens then? The modem interface might blink, but that doesn't tell the router that anything happened.

BRASes and CPEs both send keepalives to detect this event if it is
disruptive to packet flow.

> So it doesn't request a new prefix, and keeps using the one it had before. But the new PE box doesn't have a route for it, because there was no DHCPv6 exchange to snoop/glean. Even if you (or the customer, hopefully not after a call) bounce the home router, the new PE box installs a route, but how does the old box know to delete its route?
>

BRAS session keepalives.

Other mechanisms I've seen is DSLAMs that spoof a PPPoE PADT on behalf
of the CPE if the ADSL link went down so that BRAS sessions were
terminated. I remember not liking that because it meant that BRAS
sessions were torn down even though the ADSL link could recover within
our BRAS's and CPE's keepalive periods. That created needless
authentication requests and session database entries.

>
> You said "if you do need to aggregate," but you always do, if you have more than a few thousand customers.

I don't think you do at a threshold of a few thousand customers.

BGP demonstrably scales to at least 700 000 routes for IPv4, so lets
assume 350K for IPv6.

The other main scaling factor is route churn. Per Geoff's research
from 2017 (https://blog.apnic.net/2018/01/10/bgp-in-2017/), the global
Internet is handling close to 2 BGP updates per second (170 000/day).

So I'd estimate a cluster of BRASes servicing 100 000 customers, with
full announcement of all delegated prefixes between the cluster
members, and route aggregation only occurring towards the cluster's
upstream routers should be quite possible.

The population of users serviced by a cluster is the customers' prefix
stability domain. That may be a city, town, region or PoP. If the
customers session disconnect/reconnect lands on the same BRAS cluster
all the time (but not necessarily the same BRAS) - and that is what
you design to happen if it is not already inherent in your broadband
backbone - then their IPv6 PD prefix is stable across sessions.

> Nobody wants ten million customer prefixes in their network.

I don't think I said anybody does. You'll need to aggregate before then.

The fundamental point of the above BRAS cluster model is that the
aggregation boundary doesn't have to be at the boundary of an
individual BRAS device, because we have a routing protocol that can
scale far beyond the capacity of a typical BRAS and well above a few
thousand customers.

With stable broadband connections, the primary aggregation factor is
how many routes you can support and want to have within and outside
the BRAS cluster.

> Really, nobody wants ten thousand prefixes in their IGP.
>

("BGP assumed ...")

I'd be a bit surprised if people are importing 1000s of customer
prefixes into an IGP today at an ISP, and if they are, I'd be advising
them to shift those routes into BGP.

> Really, nobody wants to maintain a table of ten million assigned prefixes, to be queried with every DHCPv6 request. The initial population of that table, and lookups, and moves/add/changes/deletions, requires a bit of automation that has no ROI.

I think it does have an RIO, it will both cut down on helpdesk calls
and also avoids creating or contributing to a negative reliability
perception in your customers' minds.

It can also impact your word of mouth marketing. Some customers will
tolerate a small amount of unreliability below a threshold. If they're
asked their opinion of your service by a friend, neighbour etc., you
want them to say "it's excellent", "I'm very happy", "highly
recommended" etc. rather than "it's not to bad", "occasionally it's
sometimes a bit unreliable". People have a bias that places more
weight on negativity - https://en.wikipedia.org/wiki/Negativity_bias -
so you want to avoid anything that creates a negative experience.

If a customer is reissued with their same prefix across a
disconnect/reconnect, then their application session connections
survive, because it is a period of transient packet loss. That induces
some minor application delays, but then things recover and continue.

If their prefix changes on each disconnect/reconnect, then application
sessions fail, and that can become visible to end-users.

It has been argued that applications should be written to cope with
that event, however that is a I think that is a reasonably high cost
to impose all applications. It may be becoming necessary however it
would be better to minimise its use if possible.

Some applications may not be written to cope with it, and recovery is
much more involved than recovering from packet loss. There's more
chance of a negative end-user experience.

> If I ran an ISP, I would not want to spend a lot of time developing features to retain my most expensive customers.
>
>

I don't think it is the expensive customers who desire the most
reliable service they can have within what they're paying, I think it
is all of your customers. Who purposely buys something that is
noticeably unreliable?

>
> I think there is a distinction between stable and static. Stable means the ISP will try to avoid changing it, but don't guarantee they won't need to at sometime in the future. A static prefix provides the guarantee of permanent assignment and it is the guarantee the customer pays the premium for.
>
> I've tried to avoid saying "static prefix" because it's easily confused with "static route." I've generally said "persistent prefix" to mean that doesn't change (your "static"), and only referred to the relative stability or persistence of a prefix for one that may change.
>

I'm taking a slightly more customer perspective on the term in regards
to the prefix - "static' means never changing while the
customer/provider paid relationship exists, where as "stable" means
under normal and common network circumstances the prefix won't change
(i.e. connection/reconnection at the network point)

For example, my DHCPv6-PD prefix has been stable for 7 years because
I've lived in the same place for 7 years. If I move house, I may or
may not get the same prefix.

> If it can be made totally seamless and automatic, the those that want changing prefixes should have them if possible. It is easier said than done, which is why privacy experts saying a prefix should be changed every 24 hours suggests to me they may not have much understanding of what that would entail to make it seamless and automatic.
>
> Most people also have stable IPv4 addresses today, because one of the most common BRAS implementations that I have experience with caches dynamic address assignment from a pool and reallocates the same address to the same authenticated user if they disconnect and then reconnect to the same BRAS.
>
> Most ISPs seem to like a very small number of very large BRASes (unlike me) at a service aggregation point, so the likelihood of being assigned the same IPv4 address across disconnect/reconnect goes up.
>
> If they have stable broadband connections, they can have the same IPv4 address for months, depending on their service (link) uptime and their BRAS uptime.
>
> If there is a privacy problem with stable IPv6 prefixes, there's a very similar one with the inherently stable IPv4 addresses people have had for the last 15 or so years since always-on residential broadband became available. I'm not dismissing the privacy concern, just observing that it has been an accepted one with IPv4 for quite a long time.
>
> This is a strong argument. My motivations are not so much to protect privacy (I'd like a privacy expert to explain the threat relative to other issues, considering how effective fingerprinting and cookies are) as the operational issues above.
>
> But I also have an architectural principle that an IP address is a network locator and host identifier, just a set of integers, and relying on them not changing is ossifying the network.
>

With the rise of multipath transport layer protocols, I've started to
think that trying to solve the locator identifier problem at the
network layer may have been the incorrect place to try to solve it.

I think they're separating the identifier property from an IP address,
however rather than having a host identifier, they're instead using a
transport layer session identifier. I think that's the communications
identity that matters, not the identity of the host the application is
operating on.

So I think multipath transport layer protocols will help reduce the
impact of renumbering events.

> RFC7010 "IPv6 Site Renumbering Gap Analysis" lists the stuff that needs to happen when a prefix changes. In short, it's how to notify everything of changes, updating DNS, firewall/ACL/policy stuff, and miscellaneous config bits. If DHCPv6 Reconfigure was supported and it was obvious how to declare a dDNS server, using wildcards for prefixes in firewalls and DHCP servers gets you 90% of the way there.
>

I think with the rise of mobile devices, multipath transport protocols
and end-to-end encryption, a lot of the need for a lot of these things
might disappear, because once an IP address is just a locator, and not
an identifier, a lot of the policy stuff that assumes and relies on an
IP address being an identifier won't work e.g. ACLs, DNS etc.

"The Rapid Rise of the Mobile Multihomed Host, and What It Might Mean
to the Network"
https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf

Regards,
Mark.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 09 Nov 2018 10:04:41 +0700

One additional consideration.

Most of the time, "business" customers are in the same BRAS as "residential" customers. Even if they get different SLAs, or whatever.

Business customers may be a "different" concept depending on the size of the customer, that's clear. I'm not talking about "leased" lines.

The point is that those customers get persistent addresses. So technologically/operationally there is no reason for making a difference.

Now, if you tell me that the "real" reason for that is making a marketing distinction, I may (or may not) agree. But this shows that is not "a problem" for operators.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mark Smith <[email-masked]>
Fecha: viernes, 9 de noviembre de 2018, 9:42
Para: Lee Howard <[email-masked]>
CC: v6ops list <[email-masked]>
Asunto: Re: [v6ops] SLAAC host moving between networks

    Hi Lee,

    
    BRAS session keepalives.

    

    

    

    
    
    ("BGP assumed ...")

    

    

    

    

    

    

    Regards,
    Mark.

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Nov 2018 08:47:29 +0100

Hi,

> would be better to minimise its use if possible.

"All applications that are expected to be used in a SoHo environment",
which tends to move towards "https requests, https requests, and bit of
local stuff in the local network".

(All the mobile apps have learned this long ago, because you need to
be able to do it for wifi<->3G/4G roaming.  Why expect less from SoHo
desktop applications?)

Gert Doering
        -- NetMaster

---

From: Richard Patterson <[email-masked]>
Date: Fri, 9 Nov 2018 09:31:02 +0000

> disruptive to packet flow.

When using PPP[oE], sure, but what about IPoE?
A problem we're trying to solve with draft-patterson-intarea-ipoe-health

-Richard

---

From: Mark Smith <[email-masked]>
Date: Sat, 10 Nov 2018 11:20:20 +1100

> When using PPP[oE], sure, but what about IPoE?

So I don't have first hand experience with IPoE, however I have to
assume that since it has been used for HFC networks universally for in
the order of 15+ years, and a broadband ADSL network I know of for the
past 10 or more years, that is fundamentally a solved problem.
Otherwise it would be well known that there are hanging
sessions/RADIUS accounting problems with HFC/IPoE networks, and I
expect it would have fallen out of favour as an access method by now.
There's been plenty of time for that to happen.

The bit of research I've done in the past (about 10 years ago now),
and verified now is that they're using things like ARP ping and ICMP
echo request/response in addition to DHCP to create and maintain
session state.

For example, the copyright date on this presentation is 2007, and that
describes how IPoE new sessions are established and how session
failure is detected via a number of methods (DHCP lease expiry, ARP
ping failure, ICMP ping failure).

http://www.swinog.ch/wp-content/uploads/2018/07/The_Evolution_from_PPPoE_to_IPoE_sessions.pdf

And here is a description of how another vendor is doing it (the same way)

https://www.juniper.net/documentation/en_US/junos/topics/concept/subscriber-management-dhcp-liveness-detection.html

> A problem we're trying to solve with draft-patterson-intarea-ipoe-health

I think the only and a major criticism of the above methods is that
they're using BRAS control plane resources for this liveness testing,
and that can become considerable with 1000s of subscriber sessions on
a BRAS.

Having CPEs use forwarding plane verification i.e. sending traffic
that is looped through the forwarding plane of the BRAS, back to the
CPE, rather than CPEs using keepalives methods that are processed by
the control plane of the BRAS (including PPP LCP Echo Request/Reply in
a PPPoE scenario), would help remove a useful amount of load from BRAS
control planes.

Regards,
Mark.

---

From: Richard Patterson <[email-masked]>
Date: Sat, 10 Nov 2018 13:40:41 +0000

> echo request/response in addition to DHCP to create and maintain

Control plane issues aside, these approaches aren't commonly
implemented by off-the-shelf CPEs.  In the downstream direction,
however, most BNGs do support the use of ARP/ND for CPE liveliness
detection, however without reciprocal checks, it can actually
exacerbate the problem/downtime.

Lower DHCP lease times help, but doesn't scale very well in larger networks.