Subject: How do you solve 3GPP issue if neither operator nor handset supports PD?

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 02:43:54 -0500

How do we propose to solve this problem if operators don’t support PD even
though the  3GPP standard has supported PD for over 10 years.

Another twist to this puzzle is Android has 90% of the mobile handset
marketplace worldwide and adamantly states they will NOT support DHCPv6 or
PD.

I researched Apple which has 10% of the market and they also do not support
PD.

Whats the solution now?
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Nov 2020 13:24:43 +0100 (CET)

> I researched Apple which has 10% of the market and they also do not support

The obvious use-case for PD is the "LTE router" fixed-wireless use-case. 
There the problem of getting a DHCPv6-PD client into the UE isn't the same 
as on handsets. A lot of those platforms already support DHCPv6-PD for 
their wired versions (some have both LTE and wired WAN).

So this brings us back to the mobile core. Why doesn't this today, 8 years 
after DHCPv6-PD was introduced in 3GPP standards, still not support PD?

I don't know but I know staff at operators who claim to have tried (more 
than 5 years ago). I do not know why their efforts failed. Perhaps the 
mobile core vendors successfully managed to divide the customer base so 
there was no critical mass. I can only speculate. I just find it weird 
that there are now demands to change *everything* downstream from the 3GPP 
bearer to handle smaller subnets instead of enabling PD in mobile core.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 12:05:39 -0500

> their wired versions (some have both LTE and wired WAN).

    Gyan>Agreed the obvious PD use case is for wired LTE but this
particular use case brought up in slaac problem statement draft is for
handsets.

> bearer to handle smaller subnets instead of enabling PD in mobile core.

    Gyan> I have to research technical reasons why

-- 

*Gyan Mishra*

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 23 Nov 2020 19:12:31 +0100

Le 23/11/2020 à 13:24, Mikael Abrahamsson a écrit :
>> How do we propose to solve this problem if operators don’t support 
>> PD even though the  3GPP standard has supported PD for over 10 
>> years.
>> 
>> Another twist to this puzzle is Android has 90% of the mobile 
>> handset marketplace worldwide and adamantly states they will NOT 
>> support DHCPv6 or PD.
>> 
>> I researched Apple which has 10% of the market and they also do
>> not support PD.
>> 
>> Whats the solution now?
> 
> The obvious use-case for PD is the "LTE router" fixed-wireless 
> use-case. There the problem of getting a DHCPv6-PD client into the
> UE isn't the same as on handsets. A lot of those platforms already 
> support DHCPv6-PD for their wired versions (some have both LTE and 
> wired WAN).
> 
> So this brings us back to the mobile core. Why doesn't this today, 8 
> years after DHCPv6-PD was introduced in 3GPP standards, still not 
> support PD?
> 
> I don't know but I know staff at operators who claim to have tried 
> (more than 5 years ago). I do not know why their efforts failed. 
> Perhaps the mobile core vendors successfully managed to divide the 
> customer base so there was no critical mass. I can only speculate.

> I just find it weird that there are now demands to change 
> *everything* downstream from the 3GPP bearer to handle smaller 
> subnets instead of enabling PD in mobile core.

It is an interesting note.  Put that way indeed it looks weird.

Indeed a variable length plen in SLAAC with a non 64bit IID would be
changes downstream rather than upstream.  I can say however that such a
change could also accommodate the upstream; if the RA from PGW ('P'
Gateway in 3GPP network) contained a /56, and if we didnt want to create
a new option in RA, then it would be necessary to use an IID of length
72.  At which point operators might complain about a 'race to the up' if
I can say so.

It might be that after many efforts, discussion, software written,
trials, some people tend to conclude that changes in the 3GPP iface to
mobile are hardly feasible with respect to that /64.  Weird it is, I agree.

Alex

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 23 Nov 2020 22:18:20 +0000

From: ipv6 <[email-masked]> On Behalf Of Gyan Mishra

> How do we propose to solve this problem if operators don’t support PD even though the  3GPP standard has supported PD for over 10 years.

Maybe I've missed this detail in the thread. Are you saying that Android would be happy to tether downstream devices will a longer prefix, and support SLAAC with different length IIDs, but not happy to accept shorter prefixes from upstream? Or is this your suggestion, which assumes that Android will forever oppose receiving anything other than /64s?

Seems to me that accepting /56 or /48s should be an easier upgrade, and create a lot less commotion in the IETF, at this time.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Nov 2020 10:26:02 +0900

I don't think anyone ever said Android will not support DHCPv6 PD. That
said, implementing DHCPv6 PD on cellular is difficult for technical
reasons, including:

   - There is no DHCPv6 PD implementation in Android, so one would need to
   be written.
   - The natural place for such an implementation is in the IpClient code,
   which does not (yet?) run on cellular networks.

Something like the new RA option proposed in the 64share v2 thread (+Cameron
Byrne <[email-masked]>) - assuming it gains consensus - would be much
easier to implement.

As an alternative: it's possible to extend the Android telephony HAL to
allow the baseband to return a delegated prefix as well as the
directly-connected route. That way, if a modem vendor (e.g., Qualcomm,
Mediatek, ...) implements DHCPv6 PD in baseband-dependent code (which is
not part of the Android OS), it can simply pass up the prefix through the
HAL and the OS can use it.

As we know, DHCPv6 PD has been mentioned in 3GPP standards for several
releases. Are there any 3GPP specs on how prefix delegation should be used?
Are there any requirements that might simplify the implementation? For
example, a requirement that the delegated prefix may not change for the
lifetime of the session, and that its lifetime is infinite, would be
consistent with the 3GPP requirements around RAs, and would substantially
simplify implementation.

On Mon, Nov 23, 2020 at 4:44 PM Gyan Mishra <[email-masked]> wrote:

> I researched Apple which has 10% of the market and they also do not
> support PD.
>
> Whats the solution now?
> --
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 23 Nov 2020 22:32:32 -0800

<no hats>

There have been, I think, 2-4 (more?) ND-based PD or PD-like
proposals.  The main argument against ND-PD, as I recall from PIO-X
days, has been "we have DHCPv6 PD, ND PD will have to replicate most
of the same semantics, why do we need two ways to do this?"

If, on the other hand, we are to understand that 3GPP operators are
just not deploying DHCPv6 PD (for whatever reason), then I think a
reasonable argument can be made that "we wouldn't have two, because we
currently have zero."

If the above is true, I, for one, would be interested to evaluate a
simple, clean draft that did things like:

    [1] define a PDIO, and its use in RAs and RSes (for requesting a
prefix length or refreshing/requesting a previously delegated prefix),

    [2] define the scope of applicability (i.e. in contexts where it
can be guaranteed that only one client will receive the RA),

    [3] did not make unnecessary reference to link technologies,
mobility architectures, or the like (just define the generic
deployment requirements, however they may be met),

    [4] did not try to make other unrelated changes (like redoing the
/64 SLAAC boundary; residential PD has been working fine for a while)
and

    [5] define the relationship to any PIOs present (i.e. a PDIO that
covers or equals a PIO with L=0 can inform the client that it's in an
RFC 8273-style environment whereas L=1 indicates an RFC 6603
situation).

I think it's possible to over-complicate the work, but if the
deployment requirements are well-scoped I think it could be fairly
clean and simple.

On Mon, Nov 23, 2020 at 5:27 PM Lorenzo Colitti
<lorenzo=[email-masked]> wrote:
>
> I don't think anyone ever said Android will not support DHCPv6 PD. That said, implementing DHCPv6 PD on cellular is difficult for technical reasons, including:
>
> There is no DHCPv6 PD implementation in Android, so one would need to be written.
> The natural place for such an implementation is in the IpClient code, which does not (yet?) run on cellular networks.
>
> Something like the new RA option proposed in the 64share v2 thread (+Cameron Byrne) - assuming it gains consensus - would be much easier to implement.
>
> As an alternative: it's possible to extend the Android telephony HAL to allow the baseband to return a delegated prefix as well as the directly-connected route. That way, if a modem vendor (e.g., Qualcomm, Mediatek, ...) implements DHCPv6 PD in baseband-dependent code (which is not part of the Android OS), it can simply pass up the prefix through the HAL and the OS can use it.
>
> As we know, DHCPv6 PD has been mentioned in 3GPP standards for several releases. Are there any 3GPP specs on how prefix delegation should be used? Are there any requirements that might simplify the implementation? For example, a requirement that the delegated prefix may not change for the lifetime of the session, and that its lifetime is infinite, would be consistent with the 3GPP requirements around RAs, and would substantially simplify implementation.
>
>> Another twist to this puzzle is Android has 90% of the mobile handset marketplace worldwide and adamantly states they will NOT support DHCPv6 or PD.
>>
>> I researched Apple which has 10% of the market and they also do not support PD.
>>
>> Whats the solution now?
>> --
>>
>>
>> Gyan Mishra
>>
>> Network Solutions Architect
>>
>> M 301 502-1347
>> 13101 Columbia Pike
>> Silver Spring, MD
>>
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 12:56:25 +0100

> days, has been "we have DHCPv6 PD, ND PD will have to replicate
> most of the same semantics, why do we need two ways to do this?"
> 
> If, on the other hand, we are to understand that 3GPP operators
> are just not deploying DHCPv6 PD (for whatever reason), then I
> think a reasonable argument can be made that "we wouldn't have two,
> because we currently have zero."

We are creating 2 mechanisms, the fact that the mobile world doesn't use
it doesn't remove DHCP PD from the 3GPP standards.

Is there any guarantee that the mobile world will implement this new option
or will we be back here in a couple of years with the same discussion? I.e.,
if we do a new option when will it be part of 3GPP specs, when will routers
support it, when will telco's update routers and roll out this feature. When
will handset support it, etc.

That said, it seems to me that by and large DHCPv6 PD is the wrong model for
many of our current use cases. So if we can come up with something better,
then it is reasonable to have a newer mechanism that is better.

> If the above is true, I, for one, would be interested to evaluate
> a simple, clean draft that did things like:
> 
>     [1] define a PDIO, and its use in RAs and RSes (for requesting
>     a prefix length or refreshing/requesting a previously delegated
> prefix),

Yes

>     [2] define the scope of applicability (i.e. in contexts where
>     it can be guaranteed that only one client will receive the RA),

We may need to do the work in two steps. One is something that works only
links that are hardwired point-to-point such as ppp.

A second step would be to include point-to-point ethernet links.

> deployment requirements, however they may be met),

Indeed.

>     [4] did not try to make other unrelated changes (like redoing
>     the /64 SLAAC boundary; residential PD has been working fine
> for a while) and

Yes.

>     [5] define the relationship to any PIOs present (i.e. a PDIO
>     that covers or equals a PIO with L=0 can inform the client that
> it's in an RFC 8273-style environment whereas L=1 indicates an RFC
> 6603 situation).

I think we should be explicit. If part of the prefix is not avaiable then
there should be a field in the PDIO that says so. 

> deployment requirements are well-scoped I think it could be fairly

The hard part is coming up with a model such that we don't have to write
a series of drafts on how to deal with operational issues (such as
renumbering) as few years later.

I.e., the DHCPv6 PD model doesn't work for many cases, what model do we
agree on that does work.

---

From: [email-masked]
Date: Tue, 24 Nov 2020 13:17:24 +0100

Hi Erik, et al,

> deployment requirements are well-scoped I think it could be fairly

I come to realise something and I want to hear if others agree.

The 3GPP model is in may ways very similar to the model I described in P2P Ethernet.
It's not traditional address assignment happening on that link. The upstream router does not have a connected route and glean adjacency (address resolution required) towards the host.

When a RA with a /64 PIO is sent and the mobile terminal does tethering, it's much more like prefix delegation of that /64.

In a traditional RA+PIO with L=1, the router states:
 This prefix is directly connected between us and requires address resolution.
 If A=1 && plen == 64 you can generate an address from this prefix.

In the P2P Ethernet/3GPP case it says:
 This prefix is not used on the link between us.
 The prefix is dedicated to you, and I promise to install a route like:
  ipv6 route <prefix> p2p-interface | interface, NH pointing at you.
 You can if you like configure an address on the interface on the upstream link,
 as the router will forward traffic to anything in that prefix blindly.
 (you aren't strictly doing SLAAC at that point though.)

In the latter case the prefix-length can be <1-128>.

Now, if someone else could more succinctly express that difference...

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 13:34:41 +0100

> (you aren't strictly doing SLAAC at that point though.)

In my experience, many true point-to-point links (such as ppp, but also
tunnels) are like this.

The reason is that in theory you should do neighbor discovery even if a link
has no L2 addresses. I found that many implementations just don't react
to an NS or send any themselves.

So all traffic is just sent to the other side of the link. I.e., the route
could actually point to the link, but you can't really tell the difference.

In theory you could try to see if the router has an address on the link, but
I never tried that experiment.

---

From: [email-masked]
Date: Tue, 24 Nov 2020 13:40:21 +0100

Philip,

> to an NS or send any themselves.

That is correct for any implementation I have written.

> I never tried that experiment.

And my point was that this is the desired behaviour in this case.
At least we should explore the consequences of not treating the nodes on each end as having a directly connected shared subnet (apart from fe80::/10) and what that does for address assignment/pd.

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 13:53:10 +0100

> > I found that many implementations just don't react

It seems to me that this is broken. Nowhere in RFC 4861 does it say that if
you are on a point-to-point link you are free to drop an incoming NS.

> At least we should explore the consequences of not treating the
> nodes on each end as having a directly connected shared subnet
> (apart from fe80::/10) and what that does for address assignment/pd.

ND is currently link agnostic. Having a different meaning for the L and A 
bits depending on the link type strikes me as a bad idea.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Nov 2020 22:01:16 +0900

> will handset support it, etc.

As for handset support: as I said, at least on Android such an option would
be easier to implement than DHCPv6 PD.

I don't know how easy it would be to get it into 3GPP implementations. +Cameron
Byrne <[email-masked]> +Gyan Mishra <[email-masked]>, do you
know? Is such a new RA option something that could happen via a feature
request to 3GPP equipment vendors, or would it require a year-long process
of revving the 3GPP specs and waiting for vendors to pick up the new 3GPP
release?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 24 Nov 2020 14:18:13 +0100 (CET)

> The 3GPP model is in may ways very similar to the model I described in P2P Ethernet.

The 3GPP model is almost identical to PPP, HDLC, ATM, IPIP or whatever 
that doesn't have an ethernet header and isn't a broadcast medium.

> Now, if someone else could more succinctly express that difference...

I don't think it should be inferred by the link type, I think similar to 
PIO-X it should be explicit. For broadcast media we put in some 
constraints, but there it gets more complicated. If we could start 
defining the "hey, I routed the entire PIO to you" somehow for P2P then we 
could continue with that for broadcast medium in a follow-up RFC.

For reference:

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

---

From: [email-masked]
Date: Tue, 24 Nov 2020 14:37:16 +0100

Philip,

> you are on a point-to-point link you are free to drop an incoming NS.

Neither do any implementation I'm aware do that.
To be clear. If a link-type has no L2 address / is point to point, then no implementation I've touched does ND address resolution.
It would be happy to respond to a NUD message.

> bits depending on the link type strikes me as a bad idea.

And I'm not proposing that.

The current behaviour of 64share does that (and gets the hack label for that reason).
What I'm saying is that 64share (and what I propose in p2p ethernet) is a lot closer to PD than it is to address assignment.
As soon as you stop thinking that a p2p link has a shared subnet, that's where you end up.

Best regards,
Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 24 Nov 2020 13:59:26 +0000

Hi Ole, Hi Philip,
In general, defining something special for P2P topology (or P2MP) is not a bad architecture decision. Why not?
P2P has really big difference from Multi-Access for address resolution point of view.
Eduard
> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 24 ноября 2020 г. 16:37
> To: Philip Homburg <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor
> handset supports PD?
> 
> Philip,
> 
> >>> I found that many implementations just don't react to an NS or send
> >>> any themselves.
> >>
> > It seems to me that this is broken. Nowhere in RFC 4861 does it say
> > that if you are on a point-to-point link you are free to drop an incoming NS.
> 
> To be clear. If a link-type has no L2 address / is point to point, then no
> implementation I've touched does ND address resolution.
> >> At least we should explore the consequences of not treating the nodes
> >> on each end as having a directly connected shared subnet (apart from
> >> fe80::/10) and what that does for address assignment/pd.
> >
> > ND is currently link agnostic. Having a different meaning for the L
> > and A bits depending on the link type strikes me as a bad idea.
> 
> What I'm saying is that 64share (and what I propose in p2p ethernet) is a lot
> closer to PD than it is to address assignment.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 24 Nov 2020 13:59:45 +0000

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, 24 November 2020 at 14:39

>    To be clear. If a link-type has no L2 address / is point to point, then no implementation I've touched does ND address resolution.

Indeed, what would be the purpose of NA if there is no L2 address to advertise ?

-éric

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Nov 2020 14:05:26 +0000

Hello Ole, 

I'm a bit dumbfounded that there would be an expectation that there is a GUA/ULA  prefix on each and every link. 

Routers do their onlink exchanges such as IGP games using link locals. Even the access router talks to the onlink nodes (e.g., sends RA) using its link local.

We can assign global addresses to the routers in loopbacks if we care, but where does that idea of assigning a /64 on a link between routers come from?

I've not seen such a thing; it seems to me like an IPv4 expectation, not IPv6. 

Keep safe;

Pascal

> From: ipv6 <[email-masked]> On Behalf Of [email-masked]
> Sent: mardi 24 novembre 2020 13:40
> >> You can if you like configure an address on the interface on the
> >> upstream lin k, as the router will forward traffic to anything in
> >> that prefix blindly.
> > The reason is that in theory you should do neighbor discovery even if
> > a link has no L2 addresses. I found that many implementations just
> > don't react to an NS or send any themselves.
> 
> > So all traffic is just sent to the other side of the link. I.e., the
> > route could actually point to the link, but you can't really tell the difference.
> >
> > In theory you could try to see if the router has an address on the
> > link, but I never tried that experiment.
> >
> 
> At least we should explore the consequences of not treating the nodes on each
> end as having a directly connected shared subnet (apart from fe80::/10) and
> what that does for address assignment/pd.
> 
> Best regards,
> Ole

---

From: Jared Mauch <[email-masked]>
Date: Tue, 24 Nov 2020 09:13:20 -0500

> Indeed, what would be the purpose of NA if there is no L2 address to advertise ?

	(not 3GPP/share related but: )

	with ND/NA on p2p ethernet it can be quite hard with some vendors
to clear DAD when an operator or customer configures the wrong IPv6 on
a p2p ethernet interface.  It can require bouncing the entier interface as
vendors haven't always had a way to clear DAD without bouncing the interface.

	If a link is point-to-point are there operations that should be
turned off, and should we define that list?  (perhaps DAD is one of them)

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 24 Nov 2020 15:19:26 +0100 (CET)

> turned off, and should we define that list?  (perhaps DAD is one of them)

I've seen DAD failures disabling interface on IOS XR when POS link was 
looped...

:P

---

From: Jared Mauch <[email-masked]>
Date: Tue, 24 Nov 2020 09:21:20 -0500

> I've seen DAD failures disabling interface on IOS XR when POS link was

	Yes, this is why i'm wondering if an interface is explicitly set
to be point-to-point, should we write up the guidance of what should can
or should be disabled?

	- Jared

---

From: [email-masked]
Date: Tue, 24 Nov 2020 15:23:28 +0100

Jared,

> turned off, and should we define that list?  (perhaps DAD is one of them)

If you have no shared subnet (as in draft-troan-6man-p2p-ethernet-00) and as done on the 3GPP case, there really isn't anything to DAD for.
Of course if as in the 3GPP case (and in p2p ethernet draft) the existing RA/PIO is used, there is no way to signal that fact to the other end. ;-)

Best regards,
Ole

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 24 Nov 2020 14:24:28 +0000

The looped interface issue was one of the use case for rfc7527 (using the SeND nonce option to detect whether the source of NS is myself)

-éric

-----Original Message-----
From: Mikael Abrahamsson <swmike=[email-masked]>
Organization: People's Front Against WWW
Date: Tuesday, 24 November 2020 at 15:19
To: Jared Mauch <[email-masked]>
Cc: Eric Vyncke <[email-masked]>, 6man WG <[email-masked]>
Subject: Re: p2p interfaces (Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?)

    :P

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Nov 2020 14:24:36 +0000

Hello Eric:

Maybe as a keep alive; RFFC 6550 expects that there's such a thing and suggests to use ND. The peers use NS/NA exchange their Link Local addresses and no or empty SLLAO. 
Then they use the link locals to do their protocol exchange, e.g., IGP.

https://tools.ietf.org/html/rfc8505#section-5.6 formalizes the use of link local addresses with a scope of uniqueness which is the pair of nodes, regardless of whether the radio reaches some other nodes at this particular moment. I've seen people oppose RFC 8505 with P2P designs and that's not an indication that they read the spec.

Because the scope of the 2 Link local addresses is the pair of nodes, DAD is instantaneous for link locals, and link local operations can start immediately.

Also note that the classical NS/NA, just like the classical ARP, are not ideally suited. The desire being to form P2P L3 links and find out who's on the other side (which addresses). You'd like to ask a question like what's your LLA, what's your complete set of addresses on this link, an IPv6 adaptation of inverse ARP. This is what we tried to do with https://tools.ietf.org/html/draft-thubert-3122bis, from which RFC 8505 takes its most ancient roots. 

Keep safe;

Pascal

> From: ipv6 <[email-masked]> On Behalf Of Eric Vyncke (evyncke)
> Sent: mardi 24 novembre 2020 15:00
> To: [email-masked]; Philip Homburg <pch-ipv6-ietf-6@u-
> 1.phicoh.com>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 15:31:26 +0100

>To be clear. If a link-type has no L2 address / is point to point, then 
>no implementation I've touched does ND address resolution.

ND answers two questions, what is the L2 address of an address and is the
remote node alive.

So from my point of view it is obvious to just send an NS, mark the neighbor
cache as incomplete until you get an NA back. Then you know that neighbor
is alive.

Now, I wouldn't mind if other implementations would not send the NS and
just assume that their neighbors are alive.

However I found that most sutff just doesn't reply with an NA at all.

> The current behaviour of 64share does that (and gets the hack label
> for that reason).  What I'm saying is that 64share (and what I
> propose in p2p ethernet) is a lot closer to PD than it is to address
> assignment.  As soon as you stop thinking that a p2p link has a
> shared subnet, that's where you end up.

>From a 'bits on the wire' point of view, there is nothing magic to PD.
It is just a message that says: here is prefix, you can do with it as you
see fit.

The devil is in the details. What if the down stream router then hands out
the prefix using DHCPv6 PD. Do we need to do anything special for homenet?
(I guess doing PD using RA would actually be the 3rd version of PD, because 
homenet also does prefix delegation).

If we want this to work on ethernet, we may have to say something specific,
like 'a route will be installed that points to the (link local) source
address of the RS'. Which I guess implies that an RA with a PDIO can only
be sent in response to an RS (on ethernet). Then, what do we do on p2p links.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 15:37:13 +0100

> In
> general, defining something special for P2P topology (or P2MP) is
> not a bad architecture decision. Why not? P2P has really big
> difference from Multi-Access for address resolution point of view.

So we get something like
- If the downstream network does homenet, delegate prefixes using homenet.
- If the downstream network is p2p (for example a VPN client), do RA or DHCP PD
- If the downstream network is configured as p2p ethernet then do RA or
  DHCP PD
- If the downstream network is other ethernet do DHCP PD.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 15:42:26 +0100

> Indeed, what would be the purpose of NA if there is no L2 address

Verifying reachability. From the introduction 'Finally, nodes use the
protocol to actively keep track of which neighbors are reachable and
which are not'. I.e., a router can return a destination unreachable if the
remote router doesn't respond. There is no reason to assume that link state
is reliable or quick.

---

From: [email-masked]
Date: Tue, 24 Nov 2020 15:50:14 +0100

Philip,

> ND answers two questions, what is the L2 address of an address and is the

ND has many functions.
One is address resolution and another is NUD (neighbor unreachability detection).
They use the same messages but have distinct functions.

> cache as incomplete until you get an NA back. Then you know that neighbor

If you have a neighbor cache for neighbors for p2p links.

> However I found that most sutff just doesn't reply with an NA at all.

Right. While NUD isn't a particularly effective keepalive/link state detection mechanism I would expect it to be supported.

> homenet also does prefix delegation).

no, I can't see that the protocol external to the homenet matters.
homenet does not do prefix delegation. homenet does prefix assignment.

> be sent in response to an RS (on ethernet). Then, what do we do on p2p links.

p2p links are simple. my proposal is also to treat Ethernet as a P2P link.
But otherwise, yes, you would have to install the route with the LL as NH.

The biggest difference I see between DHCP PD and something we might do in RA is the coupling between interface state and prefix.
DHCPv6 PD is essentially a fax-replacement. A delegation is independent of the upstream link-state, and in theory also which interface the delegation was received on. Although the realities of routing quickly sets in. If in RA the delegation's lifetime is restricted by the link-state/lifetime of RA, then that will have significant issues for downstream hosts/applications.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 Nov 2020 16:57:39 +0100

Le 24/11/2020 à 07:32, Erik Kline a écrit :
> reasonable argument can be made that "we wouldn't have two, because
> we currently have zero."
> 
> [2] define the scope of applicability (i.e. in contexts where it can
> be guaranteed that only one client will receive the RA),

[2.1] - the option should be implemented on as many as possible
platforms, before proceeding.  Android is a perfect candidate, but there
are more platforms different than Android that use same networks as
Android does - e.g. 'IoT routers' - who also need such option.

> [3] did not make unnecessary reference to link technologies, mobility
> architectures, or the like (just define the generic deployment
> requirements, however they may be met),
> 
> [4] did not try to make other unrelated changes (like redoing the /64
> SLAAC boundary; residential PD has been working fine for a while) 
> and
> 
> covers or equals a PIO with L=0 can inform the client that it's in
> an RFC 8273-style environment whereas L=1 indicates an RFC 6603 
> situation).

[5.1] - define whether or not this option is used to form an address on
the receiving interface.  Define whether or not this option must
be accompanied by a regular PIO.  Consider the consideration of the
reduction of numbers of bytes on wireless links.  Consider whether or 
not the use of this option implies that more other messages must be sent 
on the link.

[5.2] - define the additional security implications of using the new option.

> deployment requirements are well-scoped I think it could be fairly 

It is a good goal.

Alex

.
>> I don't think anyone ever said Android will not support DHCPv6 PD.
>> That said, implementing DHCPv6 PD on cellular is difficult for
>> technical reasons, including:
>> 
>> There is no DHCPv6 PD implementation in Android, so one would need
>> to be written. The natural place for such an implementation is in
>> the IpClient code, which does not (yet?) run on cellular networks.
>> 
>> Something like the new RA option proposed in the 64share v2 thread
>> (+Cameron Byrne) - assuming it gains consensus - would be much
>> easier to implement.
>> 
>> As an alternative: it's possible to extend the Android telephony
>> HAL to allow the baseband to return a delegated prefix as well as
>> the directly-connected route. That way, if a modem vendor (e.g.,
>> Qualcomm, Mediatek, ...) implements DHCPv6 PD in baseband-dependent
>> code (which is not part of the Android OS), it can simply pass up
>> the prefix through the HAL and the OS can use it.
>> 
>> As we know, DHCPv6 PD has been mentioned in 3GPP standards for
>> several releases. Are there any 3GPP specs on how prefix delegation
>> should be used? Are there any requirements that might simplify the
>> implementation? For example, a requirement that the delegated
>> prefix may not change for the lifetime of the session, and that its
>> lifetime is infinite, would be consistent with the 3GPP
>> requirements around RAs, and would substantially simplify
>> implementation.
>> 
>>> How do we propose to solve this problem if operators don’t
>>> support PD even though the  3GPP standard has supported PD for
>>> over 10 years.
>>> 
>>> Whats the solution now? --
>>> 
>>> 
>>> Gyan Mishra
>>> 
>>> M 301 502-1347 13101 Columbia Pike Silver Spring, MD
>>> 
>>> 
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 24 Nov 2020 16:27:38 +0000

There is one principal question about "what additional functionality should be put inside RA to replace DHCP-PD":
How many hops this information should propagate? Or to be more precise: 1 or many?

Because currently, only the need for tethering is in discussion (1 hop).
What if would be the need to delegate prefix one hop more (to home router that could delegate next)?

DHCP-PD did not have such a challenge, because it could be recursively extended to next-next hop. If somebody not satisfied with tree topology - it is not the problem of DHCP-PD.
RA PIO would have additional challenge, because it would be connected to link status.
What if link down on 1st hop?
What if link down on 2nd hop? Who would inform whom? How?

If prefix is requested by one "second hop router", then it is not available for other. Equal split of any mathematical formula would not play well. Some request/response is needed (depends on toplogy).

Sorry to bring HomeNet again. But if something is in development - it is better to satisfy a little bigger "use case".
Of course, it is possible to fix on "tethering only" (1 hop) and do not complicate things too much.

Ed/
> Sent: 24 ноября 2020 г. 17:50
> >> To be clear. If a link-type has no L2 address / is point to point,
> >> then no implementation I've touched does ND address resolution.
> > ND answers two questions, what is the L2 address of an address and is
> > the remote node alive.
> 
> ND has many functions.
> > So from my point of view it is obvious to just send an NS, mark the
> > neighbor cache as incomplete until you get an NA back. Then you know
> > that neighbor is alive.
> 
> > Now, I wouldn't mind if other implementations would not send the NS
> > and just assume that their neighbors are alive.
> >
> Right. While NUD isn't a particularly effective keepalive/link state detection
> mechanism I would expect it to be supported.
> 
> > It is just a message that says: here is prefix, you can do with it as
> > you see fit.
> >
> > The devil is in the details. What if the down stream router then hands
> > out the prefix using DHCPv6 PD. Do we need to do anything special for
> homenet?
> > (I guess doing PD using RA would actually be the 3rd version of PD,
> > because homenet also does prefix delegation).
> 
> > If we want this to work on ethernet, we may have to say something
> > specific, like 'a route will be installed that points to the (link
> > local) source address of the RS'. Which I guess implies that an RA
> > with a PDIO can only be sent in response to an RS (on ethernet). Then, what do
> we do on p2p links.
> 
> The biggest difference I see between DHCP PD and something we might do in RA
> is the coupling between interface state and prefix.
> DHCPv6 PD is essentially a fax-replacement. A delegation is independent of the
> upstream link-state, and in theory also which interface the delegation was
> received on. Although the realities of routing quickly sets in. If in RA the
> delegation's lifetime is restricted by the link-state/lifetime of RA, then that will
> have significant issues for downstream hosts/applications.
> 
> Cheers,
> Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 24 Nov 2020 16:44:11 +0000

Getting what I said earlier onto this thread, I think we should be discussing the
LLA-based PD scheme specified in:

https://datatracker.ietf.org/doc/draft-templin-6man-lla-type/

What is unique and compelling about this scheme is that it brings down two birds with
one stone; in a single RS/RA exchange, the mobile node receives both 1) an IPv6 PD,
and 2) an LLA that is guaranteed to be unique on the link without having to apply DAD.

The idea for this LLA-based PD scheme is as follows:

1) The requesting router creates a temporary LLA using RFC4941(bis) and sets a prefix length
indication inside the LLA itself. The RR then uses the LLA as the IPv6 source address of an RS
message to send to the delegating router.

2) When the delegating router receives the RS, it sees that the IPv6 source is an RFC4941(bis)
address with a non-zero prefix length indication. The DR then coordinates with the DHCPv6
server to request a PD of the length indicated by the RR.

3) When the DR receives the PD from the DHCPv6 server, it creates an OMNI LLA by
embedding the delegated prefix in the IID of fe80::/64, e.g., as fe80::2001:db8:1:2.
The DR then sets a prefix length indication in the OMNI LLA, and sets the LLA as the
destination address of an RA message to send back to the RR.

4) When the RR receives the RA message, it sees that the destination is an OMNI LLA
with a non-zero prefix length. The RR then uses the embedded prefix within the OMNI
LLA as its delegated prefix, and regards the Router Lifetime as the time at which the
delegated prefix needs to be renewed.

Questions?

Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 Nov 2020 18:00:38 +0100

Le 24/11/2020 à 13:17, [email-masked] a écrit :
[...]
> I come to realise something and I want to hear if others agree.

Since publication I wondered whether P2P Ethernet is an L2TP 'in 
disguise'?  I mean, If I understand correctly, L2TP is used in 
residential networks much how the P2P Ethernet seems to be assumed to 
work on a cellular link: a ptp link whose interfaces are highly like 
Ethernet.

> It's not traditional address assignment happening on that link. The upstream router does not have a connected route
> and glean adjacency (address resolution required) towards the host.
> 

I cant express it more succinctly.

The difference between 'assigning a prefix to a link' and 'allocating a
prefix to a Host' depends on the nexthop presence and the kind of iface
in the routing table entry.

In the simplest linuces, three alternate forms of entries in the routing
table are possible:

(1) nexthop '*'        | kind of iface 'Ethernet'
(2) nexthop '*'        | kind of iface 'ptp'
(3) nexthop IP-of-Host | kind of iface 'Ethernet' or 'ptp'
(assume a prefix/plen in each entry)

In the first form, a Gateway 'assigns' that prefix on that link.  The
Host can form an address within that prefix, but packets whose dst is
some address within that prefix might not reach that Host, because other
Host might have it, and because ND would kick in and resolve to that
other Host's IP address; ND is used because there is no nexthop.  This
is the typical Ethernet.  This is called 'connected' route, I think, on
Cisco.

In the second form, a Gateway 'assigns' the prefix to that link, and
also 'delegates' the prefix to the Host.  Packets whose dst is any
address prefixed by that prefix will be transmitted to that Host,
because ND is not used on ptp links, because even if there is no
nexthop, the 'ptp' is exceptional; 'ptp' means no ND because there are
always two neighbors that know each other very well.

In the third form, a Gateway 'delegates' the prefix to the Host but does
not 'assign' it on the link.  The Host cant form an address out of that
prefix on the receiving interface.  That prefix is not assigned to that
link.  But packets addressed to any address prefixed by that prefix are
indeed forwarded to the Host, because ND is not used here because there
is a next-hop.

In summary:
       Assign to link     Delegate to Host
(1)         x
(2)         x                   x
(3)                             x

Alex

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 18:12:15 +0100

In your letter dated Tue, 24 Nov 2020 16:44:11 +0000 you wrote:
>Getting what I said earlier onto this thread, I think we should be discussi=
>ng the

In my opinion it is a quite broken design to put protocol bits in IPv6
addresses when ND already has an option syntax for these types of extensions.

In addtion, there is realistically no risk of collision in link local address
when the IID is either EUI-64 or pseudo random. EUI-64 should not be used in
new links type so there cannot be a risk of collision between EUI and OMNI.
There is no risk of collision of pseudo random and OMNI. 

Of course, there is the case that a pseudo random number generator could
be broken. But that is smething that should be solved by improving the
implementation, not by putting extra bits in addresses

What we see here is how how creative use of bits starts failing. We had
opague IIDs. Nobody really cares if an IID is EUI-64 or pseudo random.
Those IIDs co-exists well.

Then OMNI comes along and puts protocol bits in link-local addresses. Next step
now we need flags in link-local addresses.

So the obvious thing to do is to kill OMNI. Do not put special bits in IIDs,
and put everything you want to encode in extension headers and payloads.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 24 Nov 2020 17:33:25 +0000

Philip, obviously I do not agree to your position and ask that you have a further
consideration of the "LLA Type" draft. IPv6 interfaces may assign multiple IPv6
addresses, and even multiple IPv6 link-local address which may be created by
multiple means (e.g., RFC4941(bis), RFC7217, RFC3972, admin config, OMNI etc.).
By placing a "Type" code in bits 56-63 of the LLA the different types can be
differentiated without there being a chance for mutual interference or collisions
that might require DAD. Then, by also including a Prefix Length value in bits
48-55 of the LLA we can have a PD exchange without having to include any
form of PIO* in the RS/RA message, which saves some bits over low-end links.
Finally, when the mobile node gets its prefix delegation its LLA encodes the
prefix so that PD and IPv6 ND are inherently linked instead of having to map
the PD to some other form of LLA through a lookup table.

Please have a run through the draft(s); I think you will begin to see the value.

Fred

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Tuesday, November 24, 2020 9:12 AM
> To: [email-masked]
> Cc: Templin (US), Fred L <[email-masked]>
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 Nov 2020 21:00:43 +0100

Le 24/11/2020 à 13:34, Philip Homburg a écrit :
[...]
> to an NS or send any themselves.

Indeed NS/NA are also sent on some ptp links.  They are there just to 
respect standard, in some cases.

The use of ND is relevant on ptp links, however.

The distinction is in what is that ND used for.  Is NS/NA used to 
resolve an address that is a nexthop in the rt table, or is it used to 
resolve an address that is just in the dst of the packet.

If the Gateway sends an NS for an address that is in the nexthop field 
in an entry in its rt table, then we are in presence of delegation.

If the Gateway sends an NS for an address that is in the dst field of a 
packet that it needs to forward, then we are in presence of assignment. 
  In this case, the NS/NA is not of any use, because the NA is not used.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 Nov 2020 22:32:33 +0100

> and 2) an LLA that is guaranteed to be unique on the link without having to apply DAD.

YEs for 1), but for 2) one would also consider the IPv6CP part of ppp 
and the PDP protocols.  These two protocols are also involved in the 
negotiation of an IID, LLA or even a GUA some times, on that link.

Delegating a prefix is typically associated by an operation of insertion 
of an entry in a routing table.  That entry should have a next hop 
address.  That address could be an LL address or a GUA.  These are 
negotiated by these IPv6CP or PDP protocols.

If it is too complicated to make IPv6-PD option to use the addresses 
created by IPv6CP or by PDP as nexthop, then one could delegate a prefix 
without pointing to a nexthop, but using that old p2p trick.

Also, the suggestion of this draft of using another LL address comes 
down to associating several LL addresses to an interface; because the LL 
address made by PDP or IPv6CP is always there.  If such a 2nd LL address 
is associated to an interface, but is not used in the Gateway as a 
nexthop field, then one wonders why bothering forming it at all.  An 
interface must always have one LL address, and that is given by IPv6CP 
or PDP, I think.

I am not saying it is not a good idea, though.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Wed, 25 Nov 2020 13:07:54 +0100

> Philip, obviously I do
> not agree to your position and ask that you have a further
> consideration of the "LLA Type" draft. IPv6 interfaces may assign
> multiple IPv6 addresses, and even multiple IPv6 link-local address
> which may be created by multiple means (e.g., RFC4941(bis), RFC7217,
> RFC3972, admin config, OMNI etc.).  By placing a "Type" code in
> bits 56-63 of the LLA the different types can be differentiated
> without there being a chance for mutual interference or collisions
> that might require DAD. 

That doesn't make any sense to me. Outside OMNI, this type of interference
just doesn't exist.

If it does, then please give numbers. How often does adding the flag prevent
interference or collisions outside OMNI? Did anyone ever spotted interference
between different types of addresses on ethernet?

I can see how it is an issue for OMNI, but that just means that OMNI is
broken. 

> Then, by also including a Prefix Length
> value in bits 48-55 of the LLA we can have a PD exchange without
> having to include any form of PIO* in the RS/RA message, which
> saves some bits over low-end links.  

Compression for low-bandwidth links should be done in IPv6-over-foo documents,
not as general changes to the architecture.

In particular, we are discussing prefix delegation in mobile networks,
which as not low-end by any sensible definition of low-end.

> Finally, when the mobile node
> gets its prefix delegation its LLA encodes the prefix so that PD
> and IPv6 ND are inherently linked instead of having to map the PD
> to some other form of LLA through a lookup table.

This seems to be a bogus argument to me. The router needs to map the GUA
prefix to an outgoing interface, so you get the link-local next hop for free.

A transmission function on a point-to-point interface doesn't a next hop
unless you run NUD on the link, which as far as I know, mobile doesn't.

---

From: Ole Troan <[email-masked]>
Date: Wed, 25 Nov 2020 13:12:03 +0100

> On 25 Nov 2020, at 13:08, Philip Homburg <[email-masked]> wrote:
> 
>> Philip, obviously I do

Indeed. And just do like ipv6cp and negotiate the iid at l2 if that’s needed. 

Cheers 
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Nov 2020 01:06:21 +0900

> addresses when ND already has an option syntax for these types of

+1, this does seem pretty hacky.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 25 Nov 2020 16:33:58 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Wednesday, November 25, 2020 8:06 AM
To: Philip Homburg <[email-masked]>
Cc: IETF IPv6 Mailing List <[email-masked]>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

[>]

It is not hacky if it becomes part of the addressing architecture. And, it has
full backwards compatibility in the case that the bits 48-63 are simply 0.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Nov 2020 12:25:47 -0500

> - If the downstream network is other ethernet do DHCP PD.

A point of draft-richardson-6man-cpe-provisioning-00 (expired, rather immature),
was to allow the downstream device to declare what they were, and how they
wanted to get addresses.   I was imagining an IP6CP option that would simply
advise what the downstream is, and what the upstream could support.
This avoids assigning a /64 (and running RA) to the link if it makes no sense.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 Nov 2020 06:23:36 +1100

Hi Michael,

> This avoids assigning a /64 (and running RA) to the link if it makes no

This would have been making a specific layer 2 involved in layer 3,
coupling layer 3 advancement to that layer 2.

IPv6 has moved away from layer 2 extensions or protocols to operate or
configure layer 3, and the advantage is that options can be added to a
protocol that operates at the IPv6 layer, and it automatically works over
all current and future link layers.

A good example. With IPv4 over PPP, there are very limited things to that
can be configured remotely via IPCP in a residential environment e.g. SIP
servers can't. With IPv6 over PPP, and DHCPv6 being used, SIP and all of
the other DHCPv6 options, current and new, automatically works over PPP.

All IPv6 requires from a link layer is unicast and multicast capability,
and a payload type value or a way to implicitly represent that the IPv6 is
being carried (e.g. MPLS label - although see RFC8469 for why implicit
isn't a great). Everything else in IPv6 should happen at the IPv6 layer
independent of the link layer.

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Nov 2020 17:27:19 -0500

> coupling layer 3 advancement to that layer 2.

So why does it matter at all?
The point is to make things work better for the set of layer-2 that use PPP.
That set is rather large.

    > all current and future link layers.

That's an interesting statement, which I don't think is at all relevent.
On what authority to make this statement?

The document explains that this is about announcing capabilities so that the
Layer-3 configuration mechanism can be tuned better.

We could do this in layer-3, but we usually need to decide, (in a BMS),
BEFORE starting the RA daemon, if we should be allocating a /64 to the link or not.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 26 Nov 2020 14:36:20 +1100

> The looped interface issue was one of the use case for rfc7527 (using the SeND nonce option to detect whether the source of NS is myself)

+1. Actually I think Enhanced DAD shall be enabled by default (I was
surprised to see that it's not so widely supported as it should be).
Another nasty scenario is 'a short-lived loop in the switching
infrastructure disabling IPv6 on the router interface' (did I mention
that some routers are happily sending VRRP packets from an address
which is marked as 'duplicated'? ;-\

-- 
SY, Jen Linkova aka Furry

---

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

>A point of draft-richardson-6man-cpe-provisioning-00 (expired, rather immat=
>ure),
>This avoids assigning a /64 (and running RA) to the link if it makes no sen=
>se.

A bit in RS could say 'no need to number the uplink if a prefix is delegated'
and a bit in the RA could say 'here is a prefix, but don't use the first /64'

That should be enough for most practical purposes. An IP6CP has the advantage
that the information is at the router before the first RA is sent. Putting
the information in the RS has the advantage that information does not have to
cross different layers and is avaiable on all link types.

Of course, the /64 of the upstream could be taken form a completely different
prefix. This would waste a /64 per link, but we have enough of those.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Nov 2020 12:14:34 -0500

> and a bit in the RA could say 'here is a prefix, but don't use the first /64'

yes, we could signal things that way, but:
  1) can the CPE set this if a prefix won't be delegated?
  2) what method will be used to get the prefix?
     And, can use a /64 from within the /56,/48(whatever) that will be delegated?

I agree that it can be solved, but it feels really awkward.

    > cross different layers and is avaiable on all link types.

We really don't want it available on all link types, we want it available on
PPP links.
This kind of modal RS as you describe would be a departure from current RS/RA.
An RS can currently be satisfied by a multicast RA, and an RS can be
suppressed by seeing a multicast RA.

Doing this kind of unicast request/response is PRECISELY what DHCPv6 was
created for.

    > prefix. This would waste a /64 per link, but we have enough of those.

Yes, we have lots of /64, but ISPs tend to prefer to not waste more FIB
entries than they need to.  Getting the /64 from within a bigger block that
will be routed to the customer is a win.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 26 Nov 2020 19:10:52 +0100

>   1) can the CPE set this if a prefix won't be delegated? 

I assume an RS option that requests a prefix. If the upstream router doesn't
understand the option or does not want to delegate a prefix, then the
upstream router just assigns a /64 to the link.

>   method will be used to get the prefix?

I assume that the prefix will be delegated using a RA.

>      And, can use a /64 from within the /56,/48(whatever) that will

I assume the prefix delegation option in the RA will have a bit that
tells the downstream router whether the entire prefix is delegated or that
the first /64 used for other purposes.

> We really don't want it available on all link types, we want it
> available on PPP links.  This kind of modal RS as you describe
> would be a departure from current RS/RA.  An RS can currently be
> satisfied by a multicast RA, and an RS can be suppressed by seeing
> a multicast RA.

Indeed. However, using every /64 out of /48 seems to me like an optimization.

A router can just go ahead and send an RS with a prefix and the bit that
reserves the first /64.

What is best depends on operational reality. If some handset get confused
by a prefix option then it is better to wait for the handset to send an RS.

> Doing this kind of unicast request/response is PRECISELY what DHCPv6
> was created for.

I agree. The question is whether it actually good at this.

DHCPv6 has a very complex model. There can be multiple relays and multiple
DHCP servers. So a downstream router first has to collect offers and then
select one.

DHCP is separate from RA. So coordination is required between DHCP and RA
if we want to delegate the entire prefix.

Worse, we have trouble tying a DHCP PD to link state. 

So there is an opportunity to come up with a better way of doing prefix
delegation.

RA has the advantage that all information can be in a single RA, ensuring
consistency. We can also add mechanisms that the downstream node quickly
and reliably notices flash renumbering independent of link state.

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Nov 2020 19:32:04 +0100

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

It’s hard to see what you could remove. A RA solution would likely have to be implemented with some sort of database backend like RADIUS. That something isn’t specified, doesn’t make it simple. 

> Worse, we have trouble tying a DHCP PD to link state. 

The goal of PD is _not_ to tie it to link state. I would expect that goal to be general regardless of wire-representation. 

> and reliably notices flash renumbering independent of link state.

It might be worth noting that  RAs do not guarantee all information in a single RA. It can be split across multiple messages or come from different sources. 

Let’s ask the question differently. Would RS/RA be a good protocol for address assignment?

Cheers 
Ole

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 Nov 2020 06:54:06 +1100

> On what authority to make this statement?

Christian Huitema's IPv6 book. You can also see that theme in the ND RFC:

"Placing address resolution at the ICMP layer makes the protocol
      more media-independent than ARP and makes it possible to use
      generic IP-layer authentication and security mechanisms as
      appropriate."

The NBMA RFC (RFC2491) also is generalising multicast emulation over
NBMA networks so that standard IPv6 unicast and multicast protocols
like ND can be used over NBMA.

> BEFORE starting the RA daemon, if we should be allocating a /64 to the link or not.

That sounds to me like that could be solved with PPP's existing PAP or
CHAP authentication mechanisms to identify the device, to then decide
things like whether a /64 should be allocated.

If you don't want or need to actually authenticate the device via a
shared secret password, you just blindly accept whatever the supplied
password is. You'd be using the PPP authentication protocol really as
just a device identification protocol, and then use RADIUS to supply
whatever attributes to the BMS you want for that identified device.

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Nov 2020 19:16:00 -0500

> DHCP servers. So a downstream router first has to collect offers and then

None of that matters over PPP.
It's a trivial request/response protocol in that case.
No relays required if all the data comes from radius data as is often the
case for BMS (DSL, PPPoE).

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Nov 2020 10:58:13 +0100

> Its hard to see what you could remove. A RA solution would likely
> have to be implemented with some sort of database backend like
> RADIUS. That something isnt specified, doesnt make it simple.

Radius is an optional feature. Yes, you can use it if for example you have
static prefixes, but you can just as well have a pool of prefixes on the
router.

For SLAAC, a router also needs to know what prefix to use. You could use radius
for that, but I assume that local configuration is more likely.

> The goal of PD is _not_ to tie it to link state. I would expect
> that goal to be general regardless of wire-representation.

I think this is the key change we should make is to avoid renumbering problems.
The downstream router has to actively verify that the prefix is still valid.

> It might be worth noting that  RAs do not guarantee all information
> in a single RA. It can be split across multiple messages or come
> from different sources.

So that is something we should work out. I.e., specify that related information
has to go in a single message. Maybe a bit that says this a point-to-point
link. Maybe a counter to allow the host to verify that all parts have been
received.

> Lets ask the question differently. Would RS/RA be a good protocol
> for address assignment?

RA is widely used for SLAAC. Though SLAAC has a few renumbering issues.

On the other hand, in the mode DHCPv6 PD is commonly used, it is a bad protocol.

---

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

> The downstream router has to actively verify that the prefix is still valid.

The exact opposite you mean. It will create renumbering problems.
You seem to propose pushing all the cost of ephemeral addressing to the end-users.
I doubt that the problem is solvable in the sense of finding a way it can be deployed.
Look forward to a draft.

> link. Maybe a counter to allow the host to verify that all parts have been

Now you are designing a new configuration protocol...

Ole

---

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

>case for BMS (DSL, PPPoE).

DHCP is far from trivial. There are all kinds of issues. Having to repopulate
FIB entries in a magic ways after a reboot of a router because the
downstream router believes it still has a valid lease.

Alternativly, we can leave it to the client to deal with that. Requiring the
client to have a reliable link state detector. Which can fail because people
relay packets in weird ways.

Another example is when user swaps CPEs and the new CPE doesn't get a lease
because the lease is still assigned to the old CPE.

Client side, there is a lot of protocol that is specified that is hardly used.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 27 Nov 2020 10:16:40 +0000

> On the other hand, in the mode DHCPv6 PD is commonly used, it is a bad protocol.

You can't run a flexible address assignment protocol without a 
provisioning database. ND is typically implemented in o/s kernels, so 
interfacing this with user-mode radius is architecturally troublesome.

As a separate issue, adding this level of complexity also goes against 
many of the design principals that ND was intended to fulfil.  It could 
be argued that these principals are already being infringed on, but a PD 
extension would take this several steps further.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 Nov 2020 19:19:42 +0900

> extension would take this several steps further.

I don't think that's the case. I'm sure there are residential broadband
deployments that use Framed-Ipv6-Prefix radius attribute to assign the
directly-connected IPv6 prefix to the customer. I once designed a network
like that many years ago, and the BNGs at that time already supported it.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 27 Nov 2020 11:24:47 +0000

Lorenzo Colitti wrote on 27/11/2020 10:19:
> directly-connected IPv6 prefix to the customer. I once designed a 
> network like that many years ago, and the BNGs at that time already 
> supported it.

No doubt this functionality exists somewhere - with sufficient thrust, 
pigs fly just fine.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Nov 2020 13:58:01 +0100

> You seem to propose pushing all the cost of ephemeral addressing
> to the end-users.  I doubt that the problem is solvable in the
> sense of finding a way it can be deployed.  Look forward to a draft.

Ephemeral addressing is a fact of life. Yes we can pretend that the whole 
world can use static addresses, but that is just living in a fantasy world.

Ephemeral addressing is currently deployed. For common cases software has
checks that something has changed and reacts. Of course, this fails for 
uncommon cases.

> Now you are designing a new configuration protocol...

I'm improving an existing configuration protocol. From day one RAs provide
configuration information related to a link. What we find is that in a
world where devices move around, RAs needs to provide some extra information
to allow a device to figure out whether it's link has still the same config
or that something has changed.

---

From: [email-masked]
Date: Fri, 27 Nov 2020 14:14:01 +0100

> checks that something has changed and reacts. Of course, this fails for 

You keep saying that.

Can you please write a draft explaining how it is supposed to work?
And if it is true as you say that it is currently implemented and deployed, what implementations support that, how do the topologies look like etc?
I work for a reasonably large vendor I can guarantee you that we have not implemented support for ephemeral addressing. ;-)

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Nov 2020 14:10:48 +0100

>interfacing this with user-mode radius is architecturally troublesome.

It is my experience that RAs are sent by a user space daemon. Maybe
I'm wrong. Which kernels send RAs directly from the kernel. How does the 
RDNSS option get passed to the kernel?

>extension would take this several steps further.

Can you explain? RA provides hosts with a prefix to configure addresses from.
How is providing a device with a bigger prefix that can be be used to number
downstream networks are significant departure?

Beyond that we have a flash renumbering problem. In my opinion we should 
try to fix that in ND instead of letting hosts guess whether something has
changed or not.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Nov 2020 17:43:45 +0100

> And if it is true as you say that it is currently implemented and
> deployed, what implementations support that, how do the topologies
> look like etc? I work for a reasonably large vendor I can guarantee
> you that we have not implemented support for ephemeral addressing.
> ;-)

Maybe we are talking about different things.

What I'm talking about if that applications on phones keep working even if
the phone witch between mobile and wifi connections or moves from one
wifi to the next.

Similarly laptops can move from one wifi to the next. VM running on a laptop
can be taken from one wifi to the next and keep working, etc.

Nobody expects to reboot a phone or laptop just because you connect to another
wifi. In the case of the VMs running on my laptop, they are bridged, so they
pick up new addresses even though there connections stay up.

Now the question is we can also make this work for prefixes. Can I give
my VMs a separate prefix and expect that to be updated as I move around.

If vendors of network equipment don't care about this, then there is always
IPv4 and NAT. Or maybe IPv6 and NAT.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 27 Nov 2020 18:27:33 +0100

Le 27/11/2020 à 17:43, Philip Homburg a écrit :
>> Can you please write a draft explaining how it is supposed to
>> work? And if it is true as you say that it is currently implemented
>> and deployed, what implementations support that, how do the
>> topologies look like etc? I work for a reasonably large vendor I
>> can guarantee you that we have not implemented support for
>> ephemeral addressing. ;-)
> 
> What I'm talking about if that applications on phones keep working 
> even if the phone witch between mobile and wifi connections or moves
>  from one wifi to the next.

In IPv4 _most_ applications on smartphone do work ok after handover.
Other particular apps, eg Skype ongoing calls, break after handover.

The same behaviour is with IPv6.

If one wants an universal solution to deal with that mobility
universally at network layer, such that all apps - even the ones that
are not improved to deal with address changes - will continue working
after addresses change then that solution is the protocol Mobile IP
(there is Mobile IPv4 and Mobile IPv6).  But people dont need that.
Most apps that need to resist handovers do have some sort of handover
management built in; other apps never need to be handed over either (eg
always use the 4G everywhere).

In the case of cars, such a universal mobility protocol Mobile IP has
been extended with NEMO extensions (network mobility).  But it has some
drawbacks stemming from the mandatory use of tunnels and from the
security risks of its route optimization.

Without Mobile IP, it would be already an exceptional achievement if
cars got a shorter than /64 prefix from the cellular network, or if it
used /65 RAs SLAAC in the onboard network.  That would already have a
high impact.

> Similarly laptops can move from one wifi to the next. VM running on a
> laptop can be taken from one wifi to the next and keep working, etc.
> 
> Nobody expects to reboot a phone or laptop just because you connect 
> to another wifi. In the case of the VMs running on my laptop, they 
> are bridged, so they pick up new addresses even though there 
> connections stay up.
> 
> Now the question is we can also make this work for prefixes. Can I 
> give my VMs a separate prefix and expect that to be updated as I move
> around.

Mobile IP with NEMO extensions does mobility for prefixes, but it is
hard; it even use DHCPv6-PD to dynamically get a prefix - through the
tunnel - from home.  Yet it has too much encapsulation and a difficult
triangular routing involved.

In small networks (eg VMs moving between Xeon blades in datacenters) it
is possible to use something else than Mobile IP.  Maybe DHCPv6-PD with
CONFIRM messages coupled to a route update mechanism.

But in distant and non-cooperating networks (eg wifi hotspot and
cellular networks separated by firewalls) it's impossible to hand-over
even an address, because the route update involved will provoke 'route
churn'.  Imagine then handing over an entire prefix (not an address) and
the route updates that go with it.  One exception to this is the
Boeing/BGP/NASA experiments which update the routes to a plane ok.  But
despite the geographically large areas, they are still small networks -
the number of hops is small, the number of routers is small.

In these cases, one (myself included), would be very happy if one could
rely on the layer-2 handover mechanisms of the cellular networks which
guarantee the allocated address (and potentially a prefix) stays the
same within an area of certain size as long as the phone keeps heartbeating.

But we dont have even that: we cant connect a car to a cellular network
without involving multiple SIM cards, or additional Gateways (Home
Agents, VPN ageways, etc), additional tunnels, triangular routing, etc.

> If vendors of network equipment don't care about this, then there is
>  always IPv4 and NAT. Or maybe IPv6 and NAT.

I doubt the necessity of threatening, even if in this case the
threatening might indeed reflect a legitimate irritation.

In IPv4 the question is not well posed.  The fortunate fact that some
apps do resist handovers wifi-cellular is not thanks to NAT-IPv4.  It is
thanks to app-specific software dealing with such events, or due to the
web browsing nature which is bursts of req-response messages during
which address changes get unnoticed often; their speed is the speed at
which human users 'tap' or 'click'.  Also the nature of audio stream
listening where re-transmits and buffer accommodate temporary losses of
connectivity until next address is allocated.

It is not IPv4 NAT that helps apps continue after handovers.

As such, it will not be IPv6 NAT either that will help apps to continue
after handovers.

But, conceptually, IPv4 NAT and IPv6 NAT certainly do help to extend the
networks, to go beyond that bottom.

It is IPv4 NAT that makes today to extend networks beyond a smartphone.
  That is the legitimate irritation, because the immediate availablity of
IPv6 NAT software coupled with the lack of other-than-64 prefixes in
cellular networks and coupled to the 64-only SLAAC, it leads to this
potential fear that IPv6 NAT will also extend the networks.  I share
that potential fear.

Alex

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 27 Nov 2020 12:35:49 -0500

> like that many years ago, and the BNGs at that time already supported it.

Exactly.  It's just stupid to do it any other way.

Even if you really want dynamically assigned prefixes from a pool (with
forced nightly renumbering even), it's still smarter to do that in the radius
server rather than in the DHCPv6-PD server.   That's because you need the
audit logs, and you want the minute to minute persistant across power cycles of stuff.

If we could do *all* IPv6 assignment via PD (whether DHCPv6-PD, or some new
way), and never number the PPP link there are many gains to be had.

---

From: [email-masked]
Date: Fri, 27 Nov 2020 18:51:30 +0100

Philip,

> IPv4 and NAT. Or maybe IPv6 and NAT.

For the case you cite IPv4 NAT would work equally well.

This started with a discussion how to support multiple links (i.e. more than a single /64).
We are the IETF and have a responsibility to solve the general problem.
A site with an arbitrary topology. Can you now please describe your solution?

Best regards,
Ole

---

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

>For the case you cite IPv4 NAT would work equally well.

You keep bringing that up. IPv4 NAT doesn't work very well if you can't get
IPv4 addresses for your servers.

In addition, NAT CGN boxes are more expensive than IPv6 routing.

> This started with a discussion how to support multiple links (i.e.
> more than a single /64).  We are the IETF and have a responsibility
> to solve the general problem.  A site with an arbitrary topology.
> Can you now please describe your solution?

For site with arbitrary topology, the solution is simple:
- for inter-site prefix delegation use DHCPv6 PD, or (if we get agreement on it)
  PD using RA.
- intra-site use homenet.

Personally, I'd like to see a good solution for an intra-site tree topology
where parties don't trust each other.

But homenet seems to have sacraficed practical security to support arbitrary
topologies. And that seems to be your focus as well.

---

From: [email-masked]
Date: Mon, 30 Nov 2020 15:37:29 +0100

> topologies. And that seems to be your focus as well.

Right, so can you know describe how the network, hosts and applications are supposed to deal with flash renumbering?
Including servers in that network.

Specification, implementation and deployment status?

I'm drilling down on this to see if we can get a common understanding of what the IETF gaps are, and what the implementation and deployment gaps are.
(Not making any assumption that the IETF would ever recommend an ephemeral addressing model of course.)

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 Nov 2020 16:54:16 +0100

> Right, so can you know describe how the network, hosts and applications
> are supposed to deal with flash renumbering? Including servers in
> that network.
> 
> I'm drilling down on this to see if we can get a common understanding
> of what the IETF gaps are, and what the implementation and deployment
> gaps are.  (Not making any assumption that the IETF would ever
> recommend an ephemeral addressing model of course.)

Network: 
- DHCPv6 PD: there is a little bit, I think DOCSIS requires the CPE to poll
  the upstream router
- I still plan to read the HNCP spec one day, but I assume it has support for
  with drawing prefixes and annoucing new ones. 
- We can assume that routers get the new prefix from HNCP and use RA to
  renumber hosts.

Host:
- hosts get a new SLAAC prefix using RA, the old SLAAC prefix will be marked
  deprecated
- DHCPv6 has a way to inform hosts, but it doesn't seem widely implemented.

Applications:
- applications have to use short flows and detect broken connections. Many
  applications can do that, but certainly not all
- for applications that use TCP and want to keep the connection, we could use
  MPTCP. 
- QUIC will be seen as a path forward 

Servers:
- by and large servers don't have to anything special. Servers just receive
  requests, it doesn't matter to the server what address is used to reach the
  server.
- For a service, we probably need to update directory information:
  - DNS has an update mechanism. A daemon on the host could detect address
    changes and update. There doesn't seem to be a standard notification
    mechanism at the operating system level. 
  - Torrents use DHTs. This would require OS specific code to detect the 
    change and then the torrent process can update the DHT.