Subject: 64share v2

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 00:10:10 -0800

Folks,

In an effort to progress the conversation, i created a simple and rough
pre-00 i-d (as ietf is not accepting submissions now) for your review and
comment

https://pastebin.com/duyYRkzG

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Nov 2020 18:44:17 +0900

This looks pretty similar to the PIO-X bit which +Erik Kline <[email-masked]>
 and +Mikael Abrahamsson <[email-masked]> wrote up in 2017:

https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit

I can't remember what happened to that. IIRC one of the primary
difficulties was that the scheme needs a strong guarantee from the link
layer that the RA is received by only one host. The minutes from IETF 98
<https://datatracker.ietf.org/doc/minutes-98-6man/00/> suggest that
there was also a concern that it duplicates existing functionality in
DHCPv6 PD. Also there was a question about the router being able to
authenticate the client.

Maybe time to revive this?

On Tue, Nov 10, 2020 at 5:10 PM Ca By <[email-masked]> wrote:

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Nov 2020 10:56:20 +0100 (CET)

> Maybe time to revive this?

Yes, something like that was what I thought of. Just send a /56 PIO-X RA 
down the GTP bearer, it'll just have a single recipient since it's a point 
to point tunnel.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: [email-masked]
Date: Tue, 10 Nov 2020 11:13:30 +0100

> This looks pretty similar to the PIO-X bit which +Erik Kline and +Mikael Abrahamsson wrote up in 2017:
> 
> I can't remember what happened to that. IIRC one of the primary difficulties was that the scheme needs a strong guarantee from the link layer that the RA is received by only one host. The minutes from IETF 98 suggest that there was also a concern that it duplicates existing functionality in DHCPv6 PD. Also there was a question about the router being able to authenticate the client.
> 

RA in general is a one to many protocol. Providing configuration information tothe attached link.
Which is not the intended case here.

I suppose you could restrict this option to point to point link or unicast RA only.
And make a new option. You will end up re-inventing PD though.

The biggest concern is that delegated prefix is expected to have a lifetime equivalent to the L2 link state.
We don't know how to build networks with those properties...

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Nov 2020 21:15:20 +1100

On Tue, 10 Nov 2020, 20:45 Lorenzo Colitti, <lorenzo=
[email-masked]> wrote:

> layer that the RA is received by only one host.
>

A true point-to-point link layer makes that guarantee.

RAs could be exclusively unicast on a multi-access link (i.e. no multicast
RAs ever), which also provides that sort of guarantee.

A router would have to learn of a host's Link-Local address to send the
unicast RAs to. That would come from RS source address, MLD source address
for solicited node group joins for addresses, and in the future, GRAND NAs,
which all will occur soon after a host's interface comes up on the link.

The minutes from IETF 98

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Nov 2020 19:15:54 +0900

> And make a new option. You will end up re-inventing PD though.

Right, the draft says that this must only be used on P2P links.

The biggest concern is that delegated prefix is expected to have a lifetime
> equivalent to the L2 link state.

3GPP networks do have this property. The PIO lifetime in the RA is set to
infinite and the actual lifetime is the link lifetime. By and large that
seems to work in practice :-)

---

From: [email-masked]
Date: Tue, 10 Nov 2020 11:32:29 +0100

Lorenzo,

> 3GPP networks do have this property. The PIO lifetime in the RA is set to infinite and the actual lifetime is the link lifetime. By and large that seems to work in practice :-) 

It works fine for the directly connected node. 
Now please put a large network behind this link and tell me how that goes...

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Nov 2020 19:58:39 +0900

On Tue, 10 Nov 2020, 19:32 , <[email-masked]> wrote:

> > 3GPP networks do have this property. The PIO lifetime in the RA is set
> to infinite and the actual lifetime is the link lifetime. By and large that

What problems do you see with this that aren't already addressed by
existing RFC7278 implementations?

---

From: [email-masked]
Date: Tue, 10 Nov 2020 12:15:12 +0100

> What problems do you see with this that aren't already addressed by existing RFC7278 implementations?

RFC7278 says:
"The LAN link RA configuration must be tightly
    coupled with the 3GPP link state.  If the 3GPP link goes down or
    changes the IPv6 prefix, that state should be reflected in the LAN
    link IPv6 configuration. "

In an arbitrary topology, i.e. with multiple routers and hosts.
Why do you do think this will work?

If the the RFC7278++ deploymenent model is one of ephemeral addressing, is the expectation that any time the cellular link flaps, the user should do the equivalent of a logical power reset of all devices? That would of course also assume those prefixes were not hard-coded in configuration files, DNS etc.

It is of course possible to provide long-lived prefixes also with this hack^H^H^H^Hmechanism. But that didn't seem like what Cameron was proposing.

Cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Nov 2020 12:36:02 +0100 (CET)

> Why do you do think this will work?

This problem exists regardless of how the prefix is delegated or how big 
it is. There is always the requirement to send zero preferred times down 
the topology and also to support flash renumbering.

---

From: [email-masked]
Date: Tue, 10 Nov 2020 12:38:52 +0100

> This problem exists regardless of how the prefix is delegated or how big it is. There is always the requirement to send zero preferred times down the topology and also to support flash renumbering.

But you see the difference right?
RA configuration tied to link state. PD assignment not.

Obviously both can be misconfigured. But as I think we have experienced. Getting the defaults correct, both in standards, implementations and understanding is important.

Cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Nov 2020 13:29:17 +0100 (CET)

> Obviously both can be misconfigured. But as I think we have experienced. Getting the defaults correct, both in standards, implementations and understanding is important.

I've experienced internet connections where the PPPoE session was 
forcefully bounced by ISP once per 24 hours and you received a new DHCP 
based address when it came up again. True for both IPv4 and IPv6.

So it makes no difference to me. In real world, neither RA or DHCP based 
methods keep their promise (valid/lifetimes) and they can both be forced 
to be tied to a link state.

It's all up to what the receiver is configured to do about this 
information, and we're already trying to figure out how RA/DHCP should be 
tied together. If someone says "ships in the dark" again I don't know what 
to say, operationally they shouldn't be.

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 07:15:48 -0800

> https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit

Interesting.

Do you think we can achieve the goal without changing RA / adding a bit ?

> DHCPv6 PD.

I believe constraining this to 3gpp makes this achievable, as the link does
not even run DAD. Duplicating PD functionality is a feature, not a bug.  As
Joel pointed out, the ietf has already agreed to have 2 approaches for
assign addresses. Adding DNS to RA has been a good thing.

Also there was a question about the router being able to authenticate the
> client.

In 3gpp, this is assured by low layer technologies

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Nov 2020 10:20:53 -0500

Ole, I do not understand what you are asking.
network A is allocating to rotuer B over a point-to-point link a prefix. 
  (The router might be a 3GPP UE.  It might be a fixed wireless RG. 
Doesn't matter.)
If there is a network behind B, the B can use that prefix for that 
network.  Obviously, if it is multi-hop network and we want to get 
multiple levels of allocation, then other tools are needed.  That was 
the homenet problem.
This approach does not claim to solve the whole homenet problem.  It 
solves a simple and common problem.

Yours,
Joel

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 07:28:13 -0800

On Tue, Nov 10, 2020 at 4:29 AM Mikael Abrahamsson <swmike=
[email-masked]> wrote:

> > Obviously both can be misconfigured. But as I think we have experienced.
> Getting the defaults correct, both in standards, implementations and
> understanding is important.
>

+1, this is my own home GPON LAN with 6RD. Link bounces cause ipv6 to fail
because addresses are ephemeral in nearly every home broadband network i
have seen.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 16:33:42 +0100

It's a brief read, I read it.

It makes sense forward.

In 64share-v2, I would like to ask if a smartphone receives an RA with a 
plen 56 how will it configure an IPv6 address?

Alex

Le 10/11/2020 à 09:10, Ca By a écrit :
> pre-00 i-d (as ietf is not accepting submissions now) for your review 
> and comment
> 
> https://pastebin.com/duyYRkzG <https://pastebin.com/duyYRkzG>
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Tue, 10 Nov 2020 16:38:49 +0100

Joel,

> network A is allocating to rotuer B over a point-to-point link a prefix.  (The router might be a 3GPP UE.  It might be a fixed wireless RG. Doesn't matter.)
> If there is a network behind B, the B can use that prefix for that network.  Obviously, if it is multi-hop network and we want to get multiple levels of allocation, then other tools are needed.  That was the homenet problem.
> This approach does not claim to solve the whole homenet problem.  It solves a simple and common problem.

In the 64share solution the prefix is assigned to the _link_ between then PE and the CE.
The CE steals that prefix and assigns it to downstream interfaces.

In PD the prefix is delegated (as in the authority of the prefix changes) to the CE.

Do you understand the difference? And the implications of that difference?

I.e. that prefix lifetime is limited to the lifetime of the connection.
Again, we do not know how to operate networks with rapidly changing addresses.

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Nov 2020 10:46:24 -0500

So we add a bit (as the earlier proposal did) to make clear that the 
intent in this case is to make the prefix available to the recipient. 
Over this pt-to-pt link.

Yours,
Joel

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 07:46:33 -0800

> plen 56 how will it configure an IPv6 address?

Hi Alex,

Thanks for reading and the question.

I believe it is ok to leave it undefined, with the scenario in section 3
providing a high level example.

If a /56 is assigned, the ue may assign and delegate addresses per it’s own
only policy.

For example, if the UE only has one active GUA capable interface, then it
will consume one of the /64 for a radio link.

It may split the /56 into 2x /57, where the first /57 is reserved and
assigned to local interfaces and the 2nd 57 is allocated for dhcpv6 PD
delegation to downstream systems.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 16:47:16 +0100

Le 10/11/2020 à 11:58, Lorenzo Colitti a écrit :
> On Tue, 10 Nov 2020, 19:32 , <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > 3GPP networks do have this property. The PIO lifetime in the RA
>     is set to infinite and the actual lifetime is the link lifetime. By
>     and large that seems to work in practice :-)
> 

Well, I think the 64share-v2, as currently formulated, does allude to 
new needed mechanisms when it says:
   "/56 is received from the 3GPP network, it will assign a /64 to the
    wireless LAN interface, another /64 is to be used for a CLAT [RFC
    6877], and the remainder of addresses will create a pool of prefixes
    that are assigned to downstream DHCPv6 PD clients."
These things are not done in current 64share implementations.  There are 
no DHCPv6-PD servers in the smartphones, and there is no standard way to 
form /64s automatically out of a /56.  There are many non-interoperable 
implementations to realize that derivation.

Additionally, a smartphone receiving an RA with a /64, as in current 
64share deployments, will correctly configure an address, but it would 
illegitimately do so if it received a /56 as per 64share-v2, because the 
IID len is 64 currently.

It might be that it might be easier to have a SLAAC with an IID len 72
to match the plen /56 of 64share-v2, rather than a prefix exclude option
in a SLAAC-DHCP combination.

Alex

---

From: [email-masked]
Date: Tue, 10 Nov 2020 17:06:37 +0100

> So we add a bit (as the earlier proposal did) to make clear that the intent in this case is to make the prefix available to the recipient. Over this pt-to-pt link.

Yes, or rather a new option. And text about the lifetime of the delegated prefix being decoupled of the link state.

Here is the required CDDL for the universal configuration option.

delegated-prefix = {
    prefix : tstr
    lifetime : uint
}                                 

And when I get really good at CDDL I can add prefix length range restriction to [0-64].

Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Nov 2020 11:12:53 -0500

I don't care whether we use a flag or use the new universal-config 
option (assuming the WG advances the option.)  The exact mechanism is 
much less important to me than the point of enabling RA to do this job.

Yours,
Joel

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 17:15:52 +0100

> And when I get really good at CDDL I can add prefix length range restriction to [0-64].

If I knew CDDL I would propose a relationship between parameters that 
enforces that the prefix length plus IID length to make for 128.

RA might put a prefix of length 56 in there but the underlying 
link-layer protocol negotiates the IID.  That is currently a 64bit IID. 
  The sum does not make for 128.

Or maybe we dont want SLAAC to be the one who forms an address on the 
3GPP interface of a mobile device?

Alex

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Nov 2020 08:20:36 -0800

Joel, Ole,

> On Nov 10, 2020, at 8:12 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> I don't care whether we use a flag or use the new universal-config option (assuming the WG advances the option.)  The exact mechanism is much less important to me than the point of enabling RA to do this job.

After reading the thread,

Seems like it should be called “prefix delegation” instead of “share”.    That is, as I understand it, the purpose of the proposal.

I would prefer it to be a standard as the intent is to use it with 3GPP style networks.

I like using RA for this as it appears to be a better fit for 3GPP style networks than DHCPv6 PD.

Bob

---

From: [email-masked]
Date: Tue, 10 Nov 2020 17:30:39 +0100

> I don't care whether we use a flag or use the new universal-config option (assuming the WG advances the option.)  The exact mechanism is much less important to me than the point of enabling RA to d…

Why do you care about this being in the RA?
Does the packet wrapping really matter?

Best regards,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Nov 2020 11:39:48 -0500

From what the operators have said, using the existing infrastructure 
for RA/SLAAC is important.  They have not needed DHCPv6.  So they want 
to be able to offer this using the tools they have deployed.  That seems 
reasonable to me.  Creating a new protocol for this would seem even worse.

Yours,
Joel

---

From: [email-masked]
Date: Tue, 10 Nov 2020 17:53:15 +0100

> From what the operators have said, using the existing infrastructure for RA/SLAAC is important.  They have not needed DHCPv6.  So they want to be able to offer this using the tools they have deployed.  That seems reasonable to me.  Creating a new protocol for this would seem even worse.

Then you must have missed the point I made earlier.

What operators find attractive about the RA hack is a deployment model where the user's delegated prefix is taken out of a dynamic pool local to the box.
That deployment model results in ephemeral addresses. Which might work in an environment with tethering today (a client-only stub network, where user is expected to press refresh often). But it is not obvious how scaling that hack to multiple links/routers is possible. Without a massive cost to the rest of the ecosystem.

We already have a protocol so no need for a new one.

Cheers,
Ole

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 09:10:23 -0800

On Tue, Nov 10, 2020 at 8:53 AM <[email-masked]> wrote:

> > From what the operators have said, using the existing infrastructure for
> RA/SLAAC is important.  They have not needed DHCPv6.  So they want to be
> able to offer this using the tools they have deployed.  That seems
> What operators find attractive about the RA hack is a deployment model
> where the user's delegated prefix is taken out of a dynamic pool local to
> the box.
> That deployment model results in ephemeral addresses. Which might work in
> an environment with tethering today (a client-only stub network, where user
> is expected to press refresh often). But it is not obvious how scaling that
> hack to multiple links/routers is possible. Without a massive cost to the
> rest of the ecosystem.
>
>
Ole,

Your understanding is correct.

I believe this thread saw several reports that prefixes in the home are
commonly ephemeral, sometimes on purpose, so this is not new .  It is also
consistent to my user experience with multiple large USA broadband
providers.  Reports from around the world confirm similar, see
draft-ietf-v6ops-slaac-renum-05.
Do you believe there is a new risk here that is not yet commonly seen ?

If you would like to provide some brief cautionary text for the I-D, I
would be happy to include it, so that implementers are not under any false
impressions.  Perhaps reference to draft-ietf-v6ops-slaac-renum-05   would
be sufficient.  That said, like many I-Ds, this one has trade-offs.

> We already have a protocol so no need for a new one.
Your opinion has been noted.

CB

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Nov 2020 12:41:25 -0500

Ole, that problem statement is not how I understand Cameron's 
description to this list.
Yours,
Joel

---

From: Joel Halpern <[email-masked]>
Date: Tue, 10 Nov 2020 12:47:56 -0500

I see that Cameron agreed with your statement, but not your conclusion. 
  I will try to figure out what I am misunderstanding.

Yours,
Joel

On 11/10/2020 12:41 PM, Joel M. Halpern wrote:
>>> for RA/SLAAC is important.  They have not needed DHCPv6.  So they 
>>> want to be able to offer this using the tools they have deployed.  
>>> That seems reasonable to me.  Creating a new protocol for this would 
>>> seem even worse.
>>
>> where the user's delegated prefix is taken out of a dynamic pool local 
>> to the box.
>> That deployment model results in ephemeral addresses. Which might work 
>> in an environment with tethering today (a client-only stub network, 
>> where user is expected to press refresh often). But it is not obvious 
>> how scaling that hack to multiple links/routers is possible. Without a 
>> massive cost to the rest of the ecosystem.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 18:53:17 +0100

Me I can only hope that the operator giving a /56 to a smartphone is 
present where I need access.

Alex

Le 10/11/2020 à 18:47, Joel Halpern a écrit :
>>>>  From what the operators have said, using the existing 
>>>> infrastructure for RA/SLAAC is important.  They have not needed 
>>>> DHCPv6.  So they want to be able to offer this using the tools they 
>>>> have deployed. That seems reasonable to me.  Creating a new protocol 
>>>> for this would seem even worse.
>>>
>>> What operators find attractive about the RA hack is a deployment 
>>> model where the user's delegated prefix is taken out of a dynamic 
>>> pool local to the box.
>>> That deployment model results in ephemeral addresses. Which might 
>>> work in an environment with tethering today (a client-only stub 
>>> network, where user is expected to press refresh often). But it is 
>>> not obvious how scaling that hack to multiple links/routers is 
>>> possible. Without a massive cost to the rest of the ecosystem.
>>>

---

From: [email-masked]
Date: Tue, 10 Nov 2020 19:04:53 +0100

Cameron,

> Your understanding is correct.

Excellent!

> I believe this thread saw several reports that prefixes in the home are commonly ephemeral, sometimes on purpose, so this is not new .  It is also consistent to my user experience with multiple large USA broadband providers.  Reports from around the world confirm similar, see draft-ietf-v6ops-slaac-renum-05.  Do you believe there is a new risk here that is not yet commonly seen ?

The slaac-renum documents describe only a small subset of the problems that ephemeral addressing causes.

> If you would like to provide some brief cautionary text for the I-D, I would be happy to include it, so that implementers are not under any false impressions.  Perhaps reference to draft-ietf-v6ops-slaac-renum-05   would be sufficient.  That said, like many I-Ds, this one has trade-offs.  

It isn't as much an implementation problem (implementation of this is easy) it's the operational problems caused by this (operations in the end-user networks).

Is it not irresponsible to specify a mechanism that we know will cause massive pain for host stacks, applications etc, if we were to properly fix the problem properly, or a miserably functioning network for the end-users if we didn't.

Feel free to tell me I'm wrong, and how networks are supposed to work with ephemeral addressing.

Best regards,
Ole

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 10:12:21 -0800

On Tue, Nov 10, 2020 at 10:04 AM <[email-masked]> wrote:

> for RA/SLAAC is important.  They have not needed DHCPv6.  So they want to
> be able to offer this using the tools they have deployed.  That seems
> in an environment with tethering today (a client-only stub network, where
> user is expected to press refresh often). But it is not obvious how scaling
> that hack to multiple links/routers is possible. Without a massive cost to
> the rest of the ecosystem.
> >
> >
> > Ole,
> >
> draft-ietf-v6ops-slaac-renum-05.  Do you believe there is a new risk here
> that is not yet commonly seen ?
>
> It isn't as much an implementation problem (implementation of this is
> easy) it's the operational problems caused by this (operations in the
> end-user networks).
>

Can you be specific with regards to text in the i-d draft ?

> Is it not irresponsible to specify a mechanism that we know will cause
> massive pain for host stacks, applications etc, if we were to properly fix
> the problem properly, or a miserably functioning network for the end-users
> if we didn't.
>

---

From: [email-masked]
Date: Tue, 10 Nov 2020 19:26:38 +0100

Cameron,

> Can you be specific with regards to text in the i-d draft ? 

Can't you rather describe how it is supposed to work?
I'm not the one suggesting ephemeral addressing of networks...

Cheers,
Ole

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 10:29:11 -0800

> I'm not the one suggesting ephemeral addressing of networks...

The i-d does not mention ephemeral addressing.

To focus progress, let’s focus on the text of the i-d.

Perhaps you would like the i-d to say the RA allocation should not be
ephemeral ?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2020 10:49:01 +1300

On 10-Nov-20 21:10, Ca By wrote:
> Folks,
> 
> In an effort to progress the conversation, i created a simple and rough pre-00 i-d (as ietf is not accepting submissions now) for your review and comment
> 

I'm having difficulty reconciling that with what I read at:
https://mailarchive.ietf.org/arch/msg/v6ops/0d7lSiP_78td3vWBlMnVvmp7UAo/

If that email is correct, the 3GPP model is tightly bound to
the /64 boundary and to the notion of giving a single address
and predefined Interface ID to the UE. Also, since /64
is still fixed by the addressing architecture, and RA PIOs
are constrained by that architecture, I don't understand how
a UE can be "given a prefix such as a /56 using RA".

Perhaps someone familiar with 3GPP internals, e.g. the authors
of RFC6459, can comment?

Regards
    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Nov 2020 16:58:12 -0500

I can't promise what 3GPP will do.  (Heck,< i can't even speak for what 
my employer wants from this.)

But I think it is useful to have the conversation with them.  I have 
talked to some folks involved, and believe that if we come to agreement 
that the change is useful, we could have a good discussion as to whether 
they agree.

Yours,
Joel

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 14:03:27 -0800

> and predefined Interface ID to the UE.

This is not a correct summary. I believe rfc6459 describes it clearly. The
ue receives an off-link  /64, the iid is simply a hint and typically not
used. This is why rfc7278 works.

Also, since /64
> a UE can be "given a prefix such as a /56 using RA".

The i-d is to requests the 3gpp to make a change to allow < 64 via RA

---

From: Philip Homburg <[email-masked]>
Date: Tue, 10 Nov 2020 23:23:22 +0100

>how networks are supposed to work with ephemeral addressing.

This is a good question, but it seems to be one that we need to solve.

If I start with your proposal to only have point-to-point ethernet links,
then I still want devices that behave like the current ethernet switches
we have everywhere.

So, I need to be able to connect such a device anywhere in the network and it
should work. The device should automatically find out which are upstream
and downstream links, obtain a /64 for each downstream link.

When another switch shows up on a downstream link it should be able to provide
the downstream switch with enough /64s.

I should be able to disconnect cables and reconnect them else where in the 
network.

I.e. it is nice to have static prefixes and long lease times. However the
reality is that links come and go. 

DHCPv4 created the model that you get a lease and nothing will change until
the lease expires. DHCPv6 introduced ways to inform clients of changes, but
I don't think it has seen much use. RAs constantly update hosts, but as we
have seen in the renum drafts we need to explictly invalidate old stuff. 

So we need to figure out how to invalidate stuff, in particular, if a link goes
down, how to invalidate what we learned from that link.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2020 12:06:39 +1300

On 11-Nov-20 11:03, Ca By wrote:
> 
> 
> On Tue, Nov 10, 2020 at 1:49 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> This is not a correct summary. I believe rfc6459 describes it clearly. The ue receives an off-link  /64, the iid is simply a hint and typically not used. This is why rfc7278 works. 

Thanks for the clarification.

> The i-d is to requests the 3gpp to make a change to allow < 64 via RA

RFC 6459 says "The 3GPP network allocates each default bearer a
unique /64 prefix" but doesn't seem to explain how that prefix is
conveyed to the UE. It does say that the suggested IID is conveyed
by "layer-2 signaling". If the allocated prefix is only conveyed
by an RA/PIO there is something unconventional going on, i.e. the
UE is allowed to deduce *from the RA* that it owns the entire /64,
which is not all what applies on a conventional LAN. (Yes, I do see
how that enables RFC 7278, but this unconventional semantic is
not all obvious from RFC 6459.)

So if that's right, I think we do have a problem. If we (=IETF+3GPP)
decide to allow <64 prefixes in RA/PIO during the establishment of
a PDP context, that seems to be not only an unconventional use
of RA but also one that directly contravenes the /64 rule in the
addressing architecture.

I'm not against either of those things, but I think some very
explicit wording is needed to explain what's going on and how it
is different from a conventional LAN.

   Brian

---

From: Ca By <[email-masked]>
Date: Tue, 10 Nov 2020 15:37:18 -0800

On Tue, Nov 10, 2020 at 3:06 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     > In an effort to progress the conversation, i created a simple and
> rough pre-00 i-d (as ietf is not accepting submissions now) for your review
> and comment
> >     >
> > This is not a correct summary. I believe rfc6459 describes it clearly.
> The ue receives an off-link  /64, the iid is simply a hint and typically
> not used. This is why rfc7278 works.
>

Yes, it is conveyed only using RA

On the wire(less), it looks like this (image of pcap)

https://imgur.com/a/p6dBy3d

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2020 13:00:49 +1300

Thanks for the capture. So, a friendly amendment to your draft:

OLD:
   As described in [RFC 6459], the 3GPP network may only assign a single
   off-link /64 per bearer attachment.  This assignment is passed from
   the gateway to the UE using a router advertisement (RA)[RFC 4861].
   This memo requests the 3GPP to change this requirement to allow any
   prefix size less than or equal to 64 be advertised by the 3GPP
   gateway RA.

NEW:
   As described in [RFC 6459], the 3GPP network may only assign a single
   off-link /64 per bearer attachment.  This assignment is passed from
   the gateway to the UE using a router advertisement (RA)[RFC 4861].
   This usage of RA to effectively signal prefix delegation is
   applicable in the 3GPP context but not on traditional LANs.

   This memo requests the 3GPP to change this requirement to allow any
   prefix size less than or equal to 64 be advertised by the 3GPP
   gateway RA. It also, for this purpose only, overrides the implication
   of [RFC 4291] and [RFC 4861] that subnet prefixes in RAs are
   always /64.

Regards
   Brian

On 11-Nov-20 12:37, Ca By wrote:
> 
> 
> On Tue, Nov 10, 2020 at 3:06 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Tue, Nov 10, 2020 at 1:49 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     > Folks,
>     >     >
>     >     > In an effort to progress the conversation, i created a simple and rough pre-00 i-d (as ietf is not accepting submissions now) for your review and comment
>     >     >
>     >     > https://pastebin.com/duyYRkzG
>     >

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Nov 2020 16:38:12 -0800

The conclusion I personally came to after the PIO-X stuff was that I was
just trying to do it at the wrong layer.

I think the right way to do it is to have some information from the link
layer (or sub-IP layer) that tells the client that the RA is exclusive to
it.

In 3GPP, the architecture itself *is* that bit of information.  For wifi in
a /64 per host model (RFC 8273, which motivated the PIO-X work), it would
probably have to be some IEEE 802.11 bit somewhere.

On Tue, Nov 10, 2020 at 7:15 AM Ca By <[email-masked]> wrote:

>> This looks pretty similar to the PIO-X bit which +Erik Kline
>> <[email-masked]> and +Mikael Abrahamsson <[email-masked]> wrote up in
>> 2017:
>>
> I believe constraining this to 3gpp makes this achievable, as the link
> does not even run DAD. Duplicating PD functionality is a feature, not a
> bug.  As Joel pointed out, the ietf has already agreed to have 2 approaches
> for assign addresses. Adding DNS to RA has been a good thing.
>

---

From: [email-masked]
Date: Wed, 11 Nov 2020 08:27:45 +0100

Cameron,

> To focus progress, let’s focus on the text of the i-d. 

This discussion is a sub-thread of Gyan's more generic thread.

> Perhaps you would like the i-d to say the RA allocation should not be ephemeral ?

Yes, please.

I think the draft needs to include:

 - the delegated prefix lifetime must be long lived and independent of the CE-PE link state
   it should also say something about the consequences of renumbering and how that's handled
 - the PIO is used for prefix discovery on the directly connected link, a different option
   "delegated prefix option" should be created. A principle of good protocol design is to be explicit
 - ND has been designed to be datalink type agnostic. This mechanism should not assume a 3GPP link.
   Needs text to state that this new option requires per client messaging or an underlaying p2p link.
 - Unsure if you need some way for the client to refresh or request a delegation.
 - You need to clarify host/router behaviour in that you now make the RS/RA behaviour between routers.
 - You should require a mechanism for the CE to verify forwarding state in the PE. We missed that in 3315.

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Nov 2020 17:48:34 +0900

> protocol design is to be explicit

+1. We can't just change the length of the PIO from 64 to 60, since this is
really not the same as a PIO. A PIO specifies "the prefixes that are
on-link and/or are used for stateless address autoconfiguration". Here, the
prefixes are not on-link, and any non-/64 PIO can't be used for autoconf
anyway, because for global addresses, IIDs are 64 bits long. If we just
change the PIO from /64 to /60, IPv6 on existing mobile devices will just
stop working. Also, the A and L bits in the PIO are meaningless. If the
network is delegating a /60 prefix to a mobile device, it makes no sense to
say "you can have this entire /60 but nothing in it can use autoconf", or
even "you can have this /60 and autoconf is available on it".

> or an underlaying p2p link.

+1

>  - Unsure if you need some way for the client to refresh or request a

Personally I don't think we need a way to do this. For the problem at hand,
the semantics of RAs are fine, it's the semantics of the PIO that don't
meet the needs.

> RS/RA behaviour between routers.

Not sure that necessarily needs to be added here. After all, we
published RFC 7278 without it, and the problem is basically the same. And
RFC 6204/7084 (IPv6 CE routers) already expects such routers to listen to
RAs.

> the PE. We missed that in 3315.

I don't think this is a problem in mobile networks. Certainly, I don't
think we currently have anything along these lines for IPv4 addresses or
IPv6 /64s.

Instead, I think we should say that the prefix MUST be a superset of a
prefix that already has a PIO with A=1. That would make failure modes very
clear.

---

From: [email-masked]
Date: Wed, 11 Nov 2020 09:53:11 +0100

Hi Lorenzo,

> +1. We can't just change the length of the PIO from 64 to 60, since this is really not the same as a PIO. A PIO specifies "the prefixes that are on-link and/or are used for stateless address autoconfiguration". Here, the prefixes are not on-link, and any non-/64 PIO can't be used for autoconf anyway, because for global addresses, IIDs are 64 bits long. If we just change the PIO from /64 to /60, IPv6 on existing mobile devices will just stop working. Also, the A and L bits in the PIO are meaningless. If the network is delegating a /60 prefix to a mobile device, it makes no sense to say "you can have this entire /60 but nothing in it can use autoconf", or even "you can have this /60 and autoconf is available on it".
>  
> Personally I don't think we need a way to do this. For the problem at hand, the semantics of RAs are fine, it's the semantics of the PIO that don't meet the needs.
>  
> Not sure that necessarily needs to be added here. After all, we published RFC 7278 without it, and the problem is basically the same. And RFC 6204/7084 (IPv6 CE routers) already expects such routers to listen to RAs.
>  
> I don't think this is a problem in mobile networks. Certainly, I don't think we currently have anything along these lines for IPv4 addresses or IPv6 /64s.

Right, you do get a very clear L2 event on mobile networks.
If we want to make this general it might be needed in other networks.
I thought it might be something to consider, given how many problems we've seen in broadband deployments, where the PE does DHCPv6 PD snooping as a relay, and seems to forget state. And unless the CE actively probes there's no way to recover.

> Instead, I think we should say that the prefix MUST be a superset of a prefix that already has a PIO with A=1. That would make failure modes very clear.

Implied exclude option. Yeah.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Nov 2020 10:03:38 +0100

Brian,
I mainly agree with the potential direction, but still.

>     of [RFC 4291] and [RFC 4861] that subnet prefixes in RAs are

And, should the UE negotiate an IID of length different than 64?  The UE 
negotiation of an IID happens below IP, it happens between UE and GGSN, 
and is specified by 3GPP.  Sometimes IPv6CP of PPP protocol can also 
negotiate an IID.

Should that IID be of which length?

Or should the UE extract a /64 out of that /56, create an RA, send it to 
itself, to form an address for itself?

Or should the UE use the received prefix and pad with 0s between /56 and 
/64 to form an IID and then an address?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Nov 2020 10:06:54 +0100

> of RA but also one that directly contravenes the /64 rule in the

I agree.

> is different from a conventional LAN.

I agree.

But it comes down again to the problem of length of an 'IID'.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Nov 2020 18:31:06 +0900

>    of [RFC 4291] and [RFC 4861] that subnet prefixes in RAs are

I think that if we want to gain consensus on this document, we should avoid
overriding/updating/touching RFC 4291.

Fortunately I don't think we need to. We can simply do as Ole suggested and
have the RA contain both the /64 PIO and a new option conveying the
delegated prefix. We need to continue to maintain the /64 PIO anyway. If we
don't, otherwise existing devices won't get IPv6 connectivity, since they
know that a PIO with a /60 isn't valid for autoconf (even if A=1), because
for global space, IIDs are always 64 bits long.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 12:43:43 +0100

> Right, you do get a very clear L2 event on mobile networks.  If we
> want to make this general it might be needed in other networks.
> I thought it might be something to consider, given how many problems
> we've seen in broadband deployments, where the PE does DHCPv6 PD
> snooping as a relay, and seems to forget state. And unless the CE
> actively probes there's no way to recover.

It seems to me that we need to rethink how we distribute prefixes and other
address information. At the moment the primary mechanism to control the
lifetime of a prefix or an address is a timer. But we know that doesn't
really work.

If my laptop connects to a wifi, gets a SLAAC prefix and configures an
address and then later connects to a different wifi, then the valid time
of the SLAAC prefix is irrelevant, the laptop needs to stop using the
prefix. At the same time the router can invalidate the prefix at any moment.

So the lifetime is nice for garbage collection, but doesn't have much real
world value.

In many DHCPv6 PD installations we have the issue that the lifetime of the
prefix is completely detached from the forwarding state.

If we define a new option to do prefix delegation using RA, then maybe we
can try to get rid of lifetimes are the primary mechnism and switch to 
something more explicit.

For example, a downstream device receives a prefix using RA. At some point
the downstream device either sees an RA from a new router or see an RA from
the same router without the prefix. That should trigger a link attachment
procedure where the downstream device verifies that it still connected to
the same link and that the upstream router still offers the same prefix.

If verification fails then the device removes derived prefixes from any
downstream interfaces and tries to inform downstream devices.

Ideally we can set all prefix lifetimes to infinity and they will still
get cleaned up in time through other mechanisms.

I'm not in favor of duplicating DHCP features in RA. However, in the case
of prefix delegating, we may be able to fix the semantic gap between what
DHCP PD offers and what we really need.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Nov 2020 12:50:30 +0100 (CET)

> can try to get rid of lifetimes are the primary mechnism and switch to

https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05

This actually tries to figure out if an address/prefix works, and if 
not, act.

---

From: [email-masked]
Date: Wed, 11 Nov 2020 13:03:16 +0100

Philip,

Let me rename this thread as this opens a much larger issue.
While being able to rapidly reconfigure an end-user network using the layer3 primitives in 6man, I don't think it's worth solving unless also the upper layer problems are solved.
- How do TCP connections survive a renumbering event?
- How do applications get notified to reconnect?
- Do all applications have to change as a result? Or use a different transport layer?
- What happens with DNS configuration? Are you assuming everyone has DNS-SD deployed and working?
- What about other configuration? Static addresses for example?

Good luck I say...
Until then I suggest that we continue (to pretend) that addresses must be long-lived.

Cheers,
Ole

> On 11 Nov 2020, at 12:43, Philip Homburg <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Wed, 11 Nov 2020 13:06:33 +0100

> https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05

Yes I was thinking Cam's draft could suggest something like section 3.4.

> This actually tries to figure out if an address/prefix works, and if not, act.

It's unclear what the act would imply here though.
Resending RS?

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 13:19:27 +0100

>This actually tries to figure out if an address/prefix works, and if 

I appreciate what the draft is trying to do but I don't like the mechanisms.
BFD seems to be a complex protocol. Maybe it possible to strip it down
to a BFD-lite that just does a simple echo.

Section 3.4. is a layering violation so that may make it tricky to implement
it. But worse, it requires router to reflex packets back to the same link
they came from. This usually a recipe for routing loops.

Just thinking out loud, if I want to verify that my local address works,
why not send an ICMP ECHO request to the router?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Nov 2020 13:41:21 +0100 (CET)

> It's unclear what the act would imply here though.

That's one thing one can do. Basically if the old world view seems to not 
be correct anymore, re-discover. So if you before discovered the world 
with RS+DHCPv6+DHCP, retry them all. Worst thing that can happen is that 
you end up with same world view again. Best thing that can happen is that 
you discover that your old world view no longer is correct and you 
discover a new one.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Nov 2020 13:44:12 +0100 (CET)

> to a BFD-lite that just does a simple echo.

BFD is probably a no-go, yes. We've kind of moved away from that.

> they came from. This usually a recipe for routing loops.

Why is 3.4 a layering violation?

> why not send an ICMP ECHO request to the router?

You mean use DHCPv6-PD derived GUA address and ping the LLA address of the 
upstream router?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Nov 2020 21:52:36 +0900

> you discover that your old world view no longer is correct and you

Do we really need to solve this problem in order to solve the problem of
how to distribute the information? Or rather - do we need to solve the
problems together, in the same draft?

---

From: [email-masked]
Date: Wed, 11 Nov 2020 13:58:35 +0100

> Do we really need to solve this problem in order to solve the problem of how to distribute the information? Or rather - do we need to solve the problems together, in the same draft?

I thought the answer to that was no when writing RFC3315. In hindsight leaving those musky corner cases out was a mistake.
If there is a chance that state will be lost in the PE, we should specify a way for the CE to detect it. Otherwise you'd live the site blackholed.

Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 11 Nov 2020 13:00:51 +0000

Hi all,
In year 1998 I did translate (NAT) our office (about 100 hosts) dynamically into 2 different carriers.
With ping check that primary link is alive.
Users have low chances to see switchover.
I mean: may be it is use case for NAT? "Stable connectivity for the case of ephemeral addresses".
Ed/
> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 11 ноября 2020 г. 15:03
> To: Philip Homburg <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Ephemeral addressing [was Re: 64share v2]
> 
> Philip,
> 
> While being able to rapidly reconfigure an end-user network using the layer3
> primitives in 6man, I don't think it's worth solving unless also the upper layer
> problems are solved.
> > It seems to me that we need to rethink how we distribute prefixes and
> > other address information. At the moment the primary mechanism to
> > control the lifetime of a prefix or an address is a timer. But we know
> > that doesn't really work.
> >
> > address and then later connects to a different wifi, then the valid
> > time of the SLAAC prefix is irrelevant, the laptop needs to stop using
> > the prefix. At the same time the router can invalidate the prefix at any
> moment.
> >
> > So the lifetime is nice for garbage collection, but doesn't have much
> > real world value.
> >
> > In many DHCPv6 PD installations we have the issue that the lifetime of
> > the prefix is completely detached from the forwarding state.
> >
> > If we define a new option to do prefix delegation using RA, then maybe
> > we can try to get rid of lifetimes are the primary mechnism and switch
> > to something more explicit.
> >
> > For example, a downstream device receives a prefix using RA. At some
> > point the downstream device either sees an RA from a new router or see
> > an RA from the same router without the prefix. That should trigger a
> > link attachment procedure where the downstream device verifies that it
> > still connected to the same link and that the upstream router still offers the
> same prefix.
> >
> > If verification fails then the device removes derived prefixes from
> > any downstream interfaces and tries to inform downstream devices.
> >
> > Ideally we can set all prefix lifetimes to infinity and they will
> > still get cleaned up in time through other mechanisms.
> >
> > I'm not in favor of duplicating DHCP features in RA. However, in the
> > case of prefix delegating, we may be able to fix the semantic gap
> > between what DHCP PD offers and what we really need.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Nov 2020 14:07:33 +0100 (CET)

> problems together, in the same draft?

No, these are separate problems.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 14:08:58 +0100

> Let me rename this thread as this opens a much larger issue.  While
> being able to rapidly reconfigure an end-user network using the
> layer3 primitives in 6man, I don't think it's worth solving unless
> also the upper layer problems are solved.  
> - How do TCP connections
> - What happens with DNS configuration?
> Are you assuming everyone has DNS-SD deployed and working?
> - What
> about other configuration? Static addresses for example?
> 
> Good luck I say...  Until then I suggest that we continue (to
> pretend) that addresses must be long-lived.

My reality is that many addresses are short lived. Not because addresses
on a single link change often, but because mobile devices regularly connect
to new links.

Static addresses are similar to old unix systems where you have recompile
the kernel and reboot for each new piece of hardware that gets added to a
system. Modern systems were forced to evolve because users expect to 
plug in USB devices, connect bluetooth devices, etc.

Does the world wait until the IETF solves renumbering? No. Just like the
world switched to NAT long before the IETF recognized there was such a
thing, most modern application deployments are essentially an overlay
network.

Applications use https to connect to the cloud, session identifiers are 
stored in cookies. Short sessions and short timeouts make renumber event
transparent to the application.

Can TCP survive a renumber event? Yes, MPTCP should be able to that.

How do applications get notified. The IETF and the Open Group failed to 
create APIs for that. So every OS creates its own ad-hoc mechanisms.

DNS support dynamic updates.

But what we do at the transport layer may not be relevant. So we can focus
on making the network layer work. 

Or just stick to static prefixes.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 14:15:27 +0100

>Why is 3.4 a layering violation?

"Check probe
"is a simple UDP/IP packet with a destination IP address from the
"lease being checked, and a destination MAC address of the upstream
"router.

I.e., the packet needs to be sent to a MAC address that is not associated
with the destination address. So to send the packet, the process doing the
health check probe needs to be able the retreive the MAC address of the
upstream router and send a packet directly over the L2 interface bypassing
the IPv6 stack.

>You mean use DHCPv6-PD derived GUA address and ping the LLA address of the 

Indeed.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 14:19:33 +0100

>problems together, in the same draft?

We have a problem with DHCPv6 PD relays and soft state getting
lost. We have quite a few drafts related to RAs and renumbering.

Maybe we should first figure out how it should work, before we specify
bits on the wire.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Nov 2020 14:19:49 +0100 (CET)

> upstream router and send a packet directly over the L2 interface bypassing

I don't see how this is a layering violation. Yes, it's a bit fugly but I 
don't see why it violates layers.

>> You mean use DHCPv6-PD derived GUA address and ping the LLA address of the

I can see equal failure modes here where the upstream router is configured 
to not respond to such packets.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 14:33:44 +0100

>don't see why it violates layers.

It's a layering violation if you handcraft an IPv6 packet and directly
send it over L2.

The IPv6 protocol is quite specific on how destination caches, neighbor
caches, and neighbor discovery works.

This bypasses all of that and assumes the MAC address of the router is
avaiable outside the neighbor cache.

>to not respond to such packets.

One option is that we make this mandatory for a new RA option. Another
approach would be to have a flag to specifies if this feature is available.

In any case, I think it important to have a specification on how clients
can detect renumbering events and recover.

---

From: [email-masked]
Date: Wed, 11 Nov 2020 14:35:39 +0100

Philip,

> Or just stick to static prefixes.

Seems to me the world waited. At least the one I'm leaving in did. :-)
None of the systems I use handle renumbering. Barring a single application (mosh).
Most of the building blocks are there, but in 20 years of waiting few if any have put them together.
I doubt this is deployable in time to avoid users being forced to NAT on the edge, to protect themselves from instability in global addressing.

Are we going to restrict all future IPv6 end-user networks that are forced to depend on PA addressing to be client only?

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Nov 2020 22:37:25 +0900

> lost. We have quite a few drafts related to RAs and renumbering.

I don't think that can really happen here because the option we're defining
is explicitly for a point-to-point link. It's very unlikely that
point-to-point links won't have some sort of liveness detection already.
You know if your point-to-point link is up, right?

> Maybe we should first figure out how it should work, before we specify

If you're talking about what should happen *downstream* of the device that
receives the option ("recipient"), then it seems to me that that problem is
almost completely independent of how the recipient gets the prefix, and is
basically entirely between the recipient and its downstream devices. I mean
- sure, we can decide that the option should or should not contain a timer,
and per the above, I think we can assume that there is a link-layer signal
that the recipient can use to determine that the option is no longer valid.
But... once we've done that, I think the recipient has all the information
we can possibly convey to it. The recipient will definitely know if its
prefix is no longer valid if the link goes down.

Obviously, we still have the problem that downstream devices don't know
what happened. But I don't see how we can fix that as part of defining the
option. The only things we can do when defining the option are a) add more
information to the option (but I don't see what we could add to make this
better), or b) to say that the devices implementing the option should
behave in some way. I don't think it's reasonable to mandate that behaviour
on the sender of the option, because the recipient already has all the
information it needs. So yes, in theory we could say that the recipient of
the option must have some way to notify its downstream devices when the
option is no longer valid. But I don't think that mechanism should be
specified in this draft.

---

From: [email-masked]
Date: Wed, 11 Nov 2020 14:43:27 +0100

> I don't think that can really happen here because the option we're defining is explicitly for a point-to-point link. It's very unlikely that point-to-point links won't have some sort of liveness detection already. You know if your point-to-point link is up, right?

On the PE you need a route in the FIB for the user's prefix pointing at the interface towards the user.
The prefix has to be configured on the PE as part of provisioning that user. Will there not be any deployment of this option where configuring the interface is separate from delegating the prefix?

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Nov 2020 22:55:48 +0900

QUIC supports connection migration. See for example this draft:

https://tools.ietf.org/html/draft-tan-quic-connection-migration-00

In hindsight, the real reason mobility is hard is that TCP does not provide
its own session identifier and instead relies on the lower-level
identifiers (i.e., IP addresses) to identify its connections. So I think
part of the answer is that QUIC will solve this problem.

The other part of the answer, I think, is that it isn't actually a big
problem. I think we should remember that flash renumbering - as long as
it's clearly communicated to the application - isn't actually a difficult
problem for many of today's apps, at least on mobile. Modern mobile apps
primarily use HTTP, with either idempotent GETs or using POST with replay
protection tokens. Once you have that, why bother with IP or TCP session
continuity? For streaming use cases you can just use chunked requests at
the application layer, or, at worst, range requests at the HTTP layer. Good
networking libraries can, I think, be told which requests are idempotent so
they can seamlessly retry them. Real-time apps like video conferencing use
things like webrtc which can already deal with multiple concurrent IP
addresses (and thus mobility) via STUN.

So actually, the main problem with mobility is not dealing with the change
- that's easy - but noticing the change. This is why Android added a
feature to the Linux kernel where userspace can force given sockets to
return errors to the apps that opened them. The OS does this when a network
goes down, so the app can immediately retry on whatever other network is
available, ideally without ever showing the user an error. The default
Linux behaviour was that read() or write() on that socket would block
"forever" (i.e., at least for minutes). That was solved a decade ago.

The remaining hard problem is what do you do when wifi is still connected
but is not actually getting any packets through right now. For that you do
need an actual L5 protocol that can do multipath or at least connection
migration. One of the first apps to do this was Siri, using MPTCP. But
other apps are starting to use QUIC connection migration for that, since
it's a lot easier to build and deploy than MPTCP.

On Wed, Nov 11, 2020 at 10:36 PM <[email-masked]> wrote:

> I doubt this is deployable in time to avoid users being forced to NAT on
> the edge, to protect themselves from instability in global addressing.
>
> Are we going to restrict all future IPv6 end-user networks that are forced
> to depend on PA addressing to be client only?
>
> Cheers,
> Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 11 Nov 2020 14:04:24 +0000

Under some rate of address changes
The post would fail to deliver the majority of messages.
Independent from how fast somebody would change plates on streets and buildings.
Physical location should have stable ID.
All changes are better to move into Overlay.

Is it possible for everything in the world to have Unique ID that would be used for Underlay? No UID – no communication.
The real learning would happen in opposite direction: client would tell what is his UID.
UID movement inside one carrier (or the set of properly interconnected carriers) would not disrupt connectivity.
Underlay should be limited by size (carriers could choose the limit), because it would be difficult to aggregate UID.
The real internet would happen in Overlay. Here logical address could be assigned in normal direction: from carrier.
Ed/
From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 11 ноября 2020 г. 16:37
To: Philip Homburg <[email-masked]>
Cc: IETF IPv6 Mailing List <[email-masked]>
Subject: Re: 64share v2

If you're talking about what should happen *downstream* of the device that receives the option ("recipient"), then it seems to me that that problem is almost completely independent of how the recipient gets the prefix, and is basically entirely between the recipient and its downstream devices. I mean - sure, we can decide that the option should or should not contain a timer, and per the above, I think we can assume that there is a link-layer signal that the recipient can use to determine that the option is no longer valid. But... once we've done that, I think the recipient has all the information we can possibly convey to it. The recipient will definitely know if its prefix is no longer valid if the link goes down.

Obviously, we still have the problem that downstream devices don't know what happened. But I don't see how we can fix that as part of defining the option. The only things we can do when defining the option are a) add more information to the option (but I don't see what we could add to make this better), or b) to say that the devices implementing the option should behave in some way. I don't think it's reasonable to mandate that behaviour on the sender of the option, because the recipient already has all the information it needs. So yes, in theory we could say that the recipient of the option must have some way to notify its downstream devices when the option is no longer valid. But I don't think that mechanism should be specified in this draft.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 15:31:01 +0100

> Seems to me the world waited. At least the one I'm leaving in did.
> :-) None of the systems I use handle renumbering. Barring a single
> application (mosh).  Most of the building blocks are there, but in
> 20 years of waiting few if any have put them together.  I doubt
> this is deployable in time to avoid users being forced to NAT on
> Are we going to restrict all future IPv6 end-user networks that
> are forced to depend on PA addressing to be client only?

Anything web handles renumbering.

With a bit of scripting you can have a persistent ssh session: restart a new
ssh when the old one fail. Run 'tmux att' on the server side.

Anything running phones handles renumbering, phones constantly switch between
mobile and wifi. 

There are probably a lot more applications that are meant to run on laptops
that can automatically switch to new addresses.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 11 Nov 2020 15:45:42 +0100

>You know if your point-to-point link is up, right?

In theory yes. In practice, people come up with ways of relaying
point-to-point protocols and the link state gets lost.

We can define an option that only works in the narrow context of 3GPP and a 
couple of years later we find that the option is reused in a context where
there is no reliable link state information.

So we should learn from past mistakes and explicitly verify that there
is IPv6 connectivity. Even something as simple as sending an RS if it sees
an RA without the option.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Nov 2020 16:07:08 +0100

Le 11/11/2020 à 13:52, Lorenzo Colitti a écrit :
> On Wed, Nov 11, 2020 at 9:41 PM Mikael Abrahamsson 
> <swmike=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 

I thought in this 64share-v2 thread that we assume that one can modify a 
parameter in the config file at GGSN and thus send a /63 to end user.

That would not modify source code in the GGSN, even though there might 
be a need of new code in the user equipment to deal with that /63.

It means there would be no new protocol.

Whether 64share-v2 answers or not the issues in the Problem Statement 
described in the Variable SLAAC - is an open question.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Nov 2020 16:16:00 +0100

Le 11/11/2020 à 10:31, Lorenzo Colitti a écrit :
> On Wed, Nov 11, 2020 at 9:01 AM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> gateway RA. It also, for this purpose only, overrides the 
> implication of [RFC 4291] and [RFC 4861] that subnet prefixes in RAs
> are always /64.
> 
> 
> I think that if we want to gain consensus on this document, we should
>  avoid overriding/updating/touching RFC 4291.
> 
> Fortunately I don't think we need to. We can simply do as Ole
> suggested and have the RA contain both the /64 PIO and a new option
> conveying the delegated prefix. We need to continue to maintain the
> /64 PIO anyway.

I can say that I like such a proposal because it involves a prefix
delegation concept in RA, an RA-PD, and I co-authored a draft about it
and there might be an implementation hidden somewhere in some archives.

I must say I am happy to hear that.

At the same time, I think GGSN would not implement RA-PD.  The proposal
64share-v2 seems by just modifying the existing /64 parameter in the RA.
  To remind, it was said "a tweak of the 3gpp spec to allow RA < 64 and a
UE mechanism to break that prefix into many 64s".

It says a tweak in spec and an UE mechanism.

It does not say a GGSN mechanism.

So, while we can indeed discuss many possible ways out, I would
re-verify what we want to do.

> If we don't, otherwise existing devices won't get IPv6 connectivity,
> since they know that a PIO with a /60 isn't valid for autoconf (even
> if A=1), because for global space, IIDs are always 64 bits long.

I partially disagree.

Alex

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

---

From: [email-masked]
Date: Wed, 11 Nov 2020 19:38:02 +0100

> that can automatically switch to new addresses.

If you all you have are clients then the IPv4 Internet we have today works perfectly fine.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2020 09:21:27 +1300

On 11-Nov-20 22:31, Lorenzo Colitti wrote:
> On Wed, Nov 11, 2020 at 9:01 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I think that if we want to gain consensus on this document, we should avoid overriding/updating/touching RFC 4291.

I disagree. The reality is that 3GPP has already overridden the intention
of RFC4861 by misusing an RA/PIO as a prefix delegation mechanism. That's
a clever trick, but it is a trick, and Cameron's proposal simply extends
that trick a bit.

> Fortunately I don't think we need to. We can simply do as Ole suggested and have the RA contain both the /64 PIO and a new option conveying the delegated prefix. 

You said a bad word: "new option". We should avoid that if possible.

> We need to continue to maintain the /64 PIO anyway. If we don't, otherwise existing devices won't get IPv6 connectivity, since they know that a PIO with a /60 isn't valid for autoconf (even if A=1), because for global space, IIDs are always 64 bits long.

Hmm. I'd like to know whether that's an experimental or theoretical observation.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2020 10:18:16 +1300

> Let me rename this thread as this opens a much larger issue.

Not exactly a new issue. (Veteran of 6renum here.)

> - How do TCP connections survive a renumbering event?

Why we did SHIM6. The arguments haven't changed.

> - How do applications get notified to reconnect?

Not needed in the SHIM6 model, but in the real world, a TCP disconnect or a missing UDP response is what they get. And then they need to repeat whatever discovery or rendez-vous mechanism they use, e.g. DNS lookup.

> - Do all applications have to change as a result? Or use a different transport layer?

No. There's nothing new here. Well written apps have always done this. Badly written apps just fail. (I have no idea whether QUIC will change this. SCTP hasn't really made it into the mainstream.)

> - What happens with DNS configuration? Are you assuming everyone has DNS-SD deployed and working?

You can't safely assume that. But see above: "whatever discovery or rendez-vous mechanism they use".

> - What about other configuration? Static addresses for example?

Yeah, well, anything that uses static config has been broken for 25 years.

> Good luck I say...

Yes. There's nothing new about ephemeral addresses.

> Until then I suggest that we continue (to pretend) that addresses must be long-lived.

Which is why ULAs should be used whenever possible. Like RFC1918 addresses, they have a better chance of being long-lived.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Wed, 11 Nov 2020 13:33:26 -0800

At Thu, 12 Nov 2020 09:21:27 +1300,
Brian E Carpenter <[email-masked]> wrote:

> > I think that if we want to gain consensus on this document, we
> > should avoid overriding/updating/touching RFC 4291.
>

I tend to agree that "64share" abuses RA/PIO as a prefix delegation
mechanism (although I'd say it rather overrides the intention of
RFC4862 than 4861).  But I'm not sure what you mean by "the
implication of [RFC4291]".  If it refers to this part of the RFC,

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long

then I don't think "64share v2" (https://pastebin.com/duyYRkzG) has to
say it overrides RFC4291.  "v2" is still a prefix delegation
mechanism, so I don't (necessarily) see overriding the implication of
RFC4291 just like RFC3633 (or RFC8415) doesn't override it simply
because it can delegate non /64 prefixes starting with bits 000.  If,
for example, 64share v2 stated the host should auto-configure an
address from (e.g.)  2001:db8:1::/48 by appending a 80-bit identifier,
then, yes, it would override the intent of RFC4291.  But from my quick
read of the draft of draft, it doesn't say anything like that.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2020 13:23:32 +1300

On 12-Nov-20 10:33, 神明達哉 wrote:
> say it overrides RFC4291.

You are correct. It's more what in English we call a "sidestep".

   Brian

> "v2" is still a prefix delegation

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Nov 2020 10:33:29 +0900

> a clever trick, but it is a trick, and Cameron's proposal simply extends

That's incorrect. 3GPP used RFC4861 as the IETF asked it to use it - to
assign a /64 to the phone because a single /128 was not enough. The phone
is free to use as many interface IDs within that /64 as it wants.

If you're referring to RFC 7278 (which is an IETF document, not a 3GPP
one), then I don't see how that conflicts with the intention of RFC 4861.
All interface IDs are still 64 bits. It's conceptually the same as saying
that the /64 is actually on the phone's downlink interface, and the phone's
uplink interface is unnumbered.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2020 15:36:08 +1300

On 12-Nov-20 14:33, Lorenzo Colitti wrote:
> On Thu, Nov 12, 2020 at 5:21 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> That's incorrect. 3GPP used RFC4861 as the IETF asked it to use it - to assign a /64 to the phone because a single /128 was not enough. The phone is free to use as many interface IDs within that /64 as it wants.

I can't find any words in RFC 4861 that describe an RA/PIO as assigning or delegating a prefix. A PIO announces that a prefix is in use on the link, as far as I understand it, and that is very different from assigning or delegating it.

Note, I'm not saying that this usage is harmful within a PDP context, but it is definitely not described by RFC 4861. It is described by RFC6459, but that's Informational.
 
> If you're referring to RFC 7278 (which is an IETF document, not a 3GPP one), then I don't see how that conflicts with the intention of RFC 4861. All interface IDs are still 64 bits. It's conceptually the same as saying that the /64 is actually on the phone's downlink interface, and the phone's uplink interface is unnumbered.

Sure, the sidestep occurs in Cameron's draft that extends the usage to prefixes shorter than /64. Again, I'm not saying that's harmful. But let's not pretend that it's normal usage of RFC 4861 that would work on an Ethernet.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Nov 2020 22:00:59 -0500

On Wed, Nov 11, 2020 at 9:36 PM Brian E Carpenter <
[email-masked]> wrote:

> I can't find any words in RFC 4861 that describe an RA/PIO as assigning or
> delegating a prefix. A PIO announces that a prefix is in use on the link,
> as far as I understand it, and that is very different from assigning or
> delegating it.
>
> Note, I'm not saying that this usage is harmful within a PDP context, but
> it is definitely not described by RFC 4861. It is described by RFC6459, but
> that's Informational.
>
> Sure, the sidestep occurs in Cameron's draft that extends the usage to
> prefixes shorter than /64. Again, I'm not saying that's harmful. But let's
> not pretend that it's normal usage of RFC 4861 that would work on an
> Ethernet.

    Are you saying that with 64share v2 any prefix length could be sent via
slaac RA.  The A flag would is set for slaac so that side step won’t work
as far as I can tell without updating RFC 4861.  Current 64share 7278 with
64 bit prefix but anything shorter would not work without updating the IETF
standards.

The side step occurring in 7278 is a RA delegation of the radio /64 prefix.

Am I missing something?

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Nov 2020 09:48:25 +0100

> a clever trick, but it is a trick, and Cameron's proposal simply extends

It is a trick indeed, but I think it happened unintentionally.  They 
exploited the fortunate consequences, which is fine.  They realized that 
assigning and delegating a prefix to a point-to-point link is 
conflating, independently of their wishes.  Were that an Ethernet-like 
shared link then assigning and delegating prefixes would be distinct.

And I agree that 64share-v2 proposal extends the trick a bit, which is fine.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Nov 2020 10:09:27 +0100

Le 12/11/2020 à 03:36, Brian E Carpenter a écrit :
>> On Thu, Nov 12, 2020 at 5:21 AM Brian E Carpenter 
>> I disagree. The reality is that 3GPP has already overridden the 
>> intention of RFC4861 by misusing an RA/PIO as a prefix delegation 
>> mechanism. That's a clever trick, but it is a trick, and Cameron's 
>> proposal simply extends that trick a bit.
>> 
>> 
>> That's incorrect. 3GPP used RFC4861 as the IETF asked it to use it 
>> - to assign a /64 to the phone because a single /128 was not 
>> enough. The phone is free to use as many interface IDs within that 
>> /64 as it wants.
> 
> I can't find any words in RFC 4861 that describe an RA/PIO as 
> assigning or delegating a prefix. A PIO announces that a prefix is
> in use on the link, as far as I understand it, and that is very 
> different from assigning or delegating it.

The difference between assigning and delegating a prefix could be
described separately.  It involves using a few distinctors such as :
kind of route for that prefix (connected vs direct, or '*' or vs
next-hop), kind of link (point-to-point or shared), kind of protocol 
(SLAAC vs DHCPv6-PD).

[...]

Alex

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 11:32:22 +0100

> today works perfectly fine.

That's not correct for quite a few reasons:
- RIR are by and large out of IPv4 addresses. It is hard to connect a client
  to an IPv4 internet when you have no addresses.
- If an ISP has some IPv4 addresses then bandwidth on a CGN box is more
  expensive than an IPv6 router
- Servers need addresses, so we now require parties to buy second hand
  addresses on the open market. 
- It is perfectly possible to offer service on changing addresses. There is
  this thing called DNS that can be used to assign a stable name to changing
  addresses.

In any case, good support for ephemeral address doesn't hurt operators who
deply static addresses. My servers at home get static addresses from
DHCPv4. Phones, etc. get dynamic addresses. 

Your own proposal of turning L2 bridges into L3 routers creates a lot more 
ephemeral addresses. Currently, relative large subnets have a single /64,
so each device that connects there will have a stable SLAAC address.

When each link has its own /64 then on wifi each time a device connects it
will get a different address (unless 802.1X is used with radius to assign a
static prefix to an account).

So it not clear to me why you are complaining about shortlived addresses.

---

From: [email-masked]
Date: Thu, 12 Nov 2020 11:47:19 +0100

Philip,

> On 12 Nov 2020, at 11:32, Philip Homburg <[email-masked]> wrote:
> 

You seem to be making an argument for why everyone else should deploy IPv6.
Which isn't my point. My point was that IPv6 with ephemeral addressing gives equal or less benefit to the end-user than existing IPv4.
And no, there is little indication that we cannot make the IPv4 Internet work forever. If we must.

> static prefix to an account).

Then you didn't understand that proposal.

> So it not clear to me why you are complaining about shortlived addresses.

I'm all in favour of making renumbering work. Even to the extent of ephemeral addressing.
But glossing over the problem and pretending that it is a solved problem, is quite unfair.
Have a look at the existing work on this. E.g. RFC7010.

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 12:55:14 +0100

> You seem to be making an argument for why everyone else should
> deploy IPv6.  Which isn't my point. My point was that IPv6 with
> ephemeral addressing gives equal or less benefit to the end-user
> than existing IPv4.  And no, there is little indication that we
> cannot make the IPv4 Internet work forever. If we must.

It seems to be that the industry thought that they could make IPv4 work
forever. But in reality there was no plan. Life behind a CGN is very limiting.

At the same time, our attempts to provide stable addresses have failed. Mobile
IP never got tracktion. The same applies to LISP. There is SHIM6. Now
we have OMNI.

Yes, if you really want statics addresses, you get a PA, find an ISP who is
willing to announce your prefix and done.

For everybody else, prefixes change.

> Then you didn't understand that proposal.

I think I do. Your proposal talks about wireless
"Is a wireless network a hub and spoke network?" but in reality
it considers only a static wired ethernet.

In my experience, computers that are permantly attached to a wired ethernet are
servers. Servers tend to get static addresses. I'm not aware of serious
issues of assigning address to servers, or routing traffic to them.
In multi-tenant sitations, vlans are used to separate traffic.

Where we do have issues is with ND multicast on wireless, which could be
solved by treating the wireless as a series of point-to-point links. 
However, there is no such thing as a stable 'Virtual-P2PEthernet0' in wireless
unless explicitly created using 802.1X.

> I'm all in favour of making renumbering work. Even to the extent
> of ephemeral addressing.  But glossing over the problem and pretending
> that it is a solved problem, is quite unfair.  Have a look at the
> existing work on this. E.g. RFC7010.

6man works at the network layer. So we should take a look at the network
layer problems described in RFC 7010 Section 5. Other groups can work
on transport or applications.

---

From: [email-masked]
Date: Thu, 12 Nov 2020 13:25:53 +0100

Philip,

> forever. But in reality there was no plan. Life behind a CGN is very limiting.

Not too dissimilar to IPv6 with ephemeral addressing (today).
Ref 7010 gaps.

> willing to announce your prefix and done.

PI. But anyway.
We must ensure IPv6 work better than IPv4.
There is something to be said for IPv4's use of private addresses. Unfortunately. We can't make the IPv6 user experience worse.

> unless explicitly created using 802.1X.

There's nothing stopping the address assignment mechanism in p2p ethernet to give the same address back to the same user. So p2p ethernet even with "dynamic" interfaces can provide stable addressing.

> on transport or applications.

Sure. And as I said we should work on this, in collaboration with the other IETF areas.
My point was with regards to Cameron's proposal that we cannot deploy a PD mechanism today, that inhernetly does ephemeral addressing. There just are too many issues with that, and will lead to a bad user experience.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2020 14:33:14 +0100

> Not too dissimilar to IPv6 with ephemeral addressing (today).  Ref
> 7010 gaps.

There is no way a consumer could get port 443 on an address assigned to a CGN.

In contrast, a consumer with IPv6 has as many 443 ports as desired. We have
DNS protocol support for updates.

So this a completely different world.

> PI. But anyway.  We must ensure IPv6 work better than IPv4.  There
> is something to be said for IPv4's use of private addresses.
> Unfortunately. We can't make the IPv6 user experience worse.

Reality is that our attempts to have stable identifers have failed. What
have is topology dependent locators. Yes, any party that can inject
prefixes in BGP is topology independent. But many consumer devices
constantly connect to different ISPs.

A big issue is that by and large devices detect that they are in a different 
environment by watching link state.

With NAT, devices behind the NAT keep the same address even if the upstream
changes. This is a clear gap that we need to address. 

> There's nothing stopping the address assignment mechanism in p2p
> ethernet to give the same address back to the same user. So p2p
> ethernet even with "dynamic" interfaces can provide stable addressing.

The current trent is that devices randomize all identifers. Or the other
way around, any stable identifier can be used for tracking the device.

How you provide stable prefixes to such devices?

> My point was with regards to Cameron's
> proposal that we cannot deploy a PD mechanism today, that inhernetly
> does ephemeral addressing. There just are too many issues with
> that, and will lead to a bad user experience.

Today, any mobile device already has ephemeral addresses and deals with it.

At the same time (in the context of mobile), nothing stops a mobile provider
from assigning static prefixes to customers (other than the cost of a 
more complex (routing) system).

I.e., a mechanism that provides ephemeral addressing can also be used to 
provide static addressing if stable client identifiers are available.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Nov 2020 12:22:03 -0300

Hi, Ole,

> While being able to rapidly reconfigure an end-user network using the layer3 primitives in 6man, I don't think it's worth solving unless also the upper layer problems are solved.

Well, that's exactly why we have layers: to be able to slice the 
different problems, and keep them tractable, among other things.

I guess that if all areas involved would argue "we won't do it until X 
addresses Y", we'd end up with circular dependencies -- and we don't 
need to (and shouldn't).

> - How do TCP connections survive a renumbering event?

They don't, unless MPTCP.

> - How do applications get notified to reconnect?

An API is needed for that. However, in the case where you connect to a 
different network and addresses from the previous network are 
removed/cleaned up, the addresses would be removed, and you'd get an 
error on the corresponding sockets. Many implementations do this, IIRC.

> - Do all applications have to change as a result? Or use a different transport layer?

With the behavior described in the previous bullet, they need not. If 
you want to have something more elaborate, they might -- with possible 
changes ranging from setting/employing a new socket options, to using a 
brand new API.

> - What happens with DNS configuration? Are you assuming everyone has DNS-SD deployed and working?

That's a different issue. What we have for that is dynamic DNS.

> - What about other configuration? Static addresses for example?

If you mean "manually-configured addresses", that's out of scope: by 
definition, those are hard-coded.

> Until then I suggest that we continue (to pretend) that addresses must be long-lived.

While he haven't been trying to tackle the broader issue of what you 
call "ephemeral addressing" (*), I believe both v6ops and even this 
groups itself (6man) have already deviated from that (e.g., 
draft-ietf-v6ops-slaac-renum).

(*) There's not such a thing as permanent address, unless you can 
somehow guarantee that
  1) the node does not/will not move
  2) the node will not add/remove network interfaces (which leads to #1 )
  3) the network topology will not change (when that happens for the 
leaf network, the prefix -- and hence the address -- will change

I don't think #1-#3 could ever be guaranteed. But I'd say that in the 
modern world, you can't guarantee any of them.

       Alice: - "How long is forever?"
       White Rabbit: - "Sometimes, just one second"

           - - Lewis Carrol, "Alice in Wonderland"

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Nov 2020 12:56:55 -0300

On 11/11/20 10:08, Philip Homburg wrote:
[...]
> Or just stick to static prefixes.

Static prefixes are not enforceable.

(As you correctly note, a mobile device that switches among wifi <-> 4G 
is just one example).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Nov 2020 13:03:08 -0300

> Philip,
[....]
> Seems to me the world waited. At least the one I'm leaving in did. :-)

Most leaf IP networks are not exposed to renumbering since they use 
private address space.

That's different for IPv6. My home network gets regularly renumbered, 
and I experience draft-ietf-v6ops-slaac-renum.

> Most of the building blocks are there, but in 20 years of waiting few if any have put them together.

The current mechanisms rely on state in all intervening network devices, 
and the signaling mechanism is unreliable. That makes the network fragile.

> I doubt this is deployable in time to avoid users being forced to NAT on the edge, to protect themselves from instability in global addressing.

If we get to, at the very lest, do more timely garbage collection as in 
draft-ietf-6man-slaac-renum, that would already be a big improvement.

> Are we going to restrict all future IPv6 end-user networks that are forced to depend on PA addressing to be client only?

Many end-user IPv6 networks are restricted to client-only. Because the 
CE Router implements a firewall, and there's no UPnP IPv6 support (or 
similar) that allows nodes to punch holes in the firewall.

Ironically, in such scenarios IPv4 ends up having better 
e2e-connectivity properties than IPv6.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Nov 2020 13:06:37 -0300

On 11/11/20 10:55, Lorenzo Colitti wrote:
> In hindsight, the real reason mobility is hard is that TCP does not 
> provide its own session identifier and instead relies on the lower-level 
> identifiers (i.e., IP addresses) to identify its connections. 

Indeed, TCP checksuming the network attachment point (IP address) rules 
out mobility.

THe approach (mobile IP) of trying to make addresses (a 
location-dependent identifier) mobile (hence "location-independent") 
doesn't seem to be the best one.

And yes, given what we have, it would seem dealing with it at transport 
is what's feasible and deployable.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2020 09:54:41 +1300

On 12-Nov-20 16:00, Gyan Mishra wrote:
> 
> 
> On Wed, Nov 11, 2020 at 9:36 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Thu, Nov 12, 2020 at 5:21 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     Are you saying that with 64share v2 any prefix length could be sent via slaac RA.

That's what Cameron's draft says, yes.

   Brian

>  The A flag would is set for slaac so that side step won’t work as far as I can tell without updating RFC 4861.  Current 64share 7278 with 64 bit prefix but anything shorter would not work without updating the IETF standards.
> 
>     [email-masked] <mailto:[email-masked]>
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike 
> /Silver Spring, MD
> 
>