Subject: EXPERIMENTAL Variable SLAAC draft-mishra-6man-variable-slaac

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Dec 2020 07:47:58 +0100

Hi, 6MANers,

I would like to ask what do you think if we intended the status of the
Variable SLAAC draft-mishra-6man-variable-slaac as EXPERIMENTAL, rather
than the current Standards Track?

Alex

---

From: Philip Homburg <[email-masked]>
Date: Thu, 17 Dec 2020 12:10:32 +0100

>than the current Standards Track?

What is the experiment?

Are mobile telco's going to implement this only to drop it later when we
do something different?

Are handset manufactures going to implement it?

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Dec 2020 14:33:38 +0100

Le 17/12/2020 à 12:10, Philip Homburg a écrit :
>> I would like to ask what do you think if we intended the status of
>> the Variable SLAAC draft-mishra-6man-variable-slaac as
>> EXPERIMENTAL, rather than the current Standards Track?
> 
> What is the experiment?

It is an experiment of using a /64 from the mobile operator down into
/65 SLAAC into car subnetworks.

It is a sysctl that is off by default.

> Are mobile telco's going to implement this only to drop it later when
> we do something different?

I doubt mobile telco's are going to implement it on the radio link
between base station or GGSN and the terminal's modem.

But a mobile operator might implement it on the wired or wifi link of a
mobile hotspot portable device.

> Are handset manufactures going to implement it?

I doubt Android or iPhone might implement this.

But other devices such as a Sierra Wireless IoT router, and an
industrial PC platform might implement it.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Thu, 17 Dec 2020 14:54:10 +0100

>/65 SLAAC into car subnetworks.

Sorry, I confused the drafts.

In my opinion this draft should not be published. We don't need to 
experiment with with protocols that violate the IPv6 addressing architecture.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 17 Dec 2020 09:16:29 -0500

> experiment with with protocols that violate the IPv6 addressing

   The experimental is to test this 3GPP  use case to change  the IPv6
architecture RFC 4291 to eliminate 64 bit boundary.  As the removal
solution is the experimental using the sysctl to for slaac to allow
variable length prefixes to perform a study of impact to endpoints using
sysctl for v2v only thus would not impact other devices.  This would be a
controlled method of testing variable slaac.

This sysctl (by default at 'off', but optionally set to on by an admin)
might help in the auto industry.  The car manufacturer delegates to
externals the design but ultimately controls all PCs in the car.  The
manufacturer might implement in the onboard gateway (IP-OBU) a derivation
of a few /65s out of the obtained /64 from the cellular link.  Then it
might turn that sysctl to on on the PCs that are built into the car.  That
could make it work, independently of what the cellular operator does,
independently of the availability of CLAT, etc.

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 17 Dec 2020 16:01:34 +0100

>controlled method of testing variable slaac.

Changing RFC 4191 has been debated for a long time, and there doesn't seem
to be any consensus that changing the 64-bit boundary is something that
should be done.

It could be that an experiment provides input in a discussion, but in this
case there seems to be no link between the discussion and the experiment.

So the only outcome of the experiment could be that a change that violates
one of the core standards of IPv6 would technically work. However that doesn't
seem to be in dispute.

Obviously anybody can just experiment without an RFC or endorsement from the
IETF.

---

From: Markku Savela <[email-masked]>
Date: Thu, 17 Dec 2020 17:07:10 +0200

Conserning the draft, why reserve a RA flag bit? Wouldn't the intent for 
"variable length SLAAC" be already obvious from "Prefix length" field of 
the RA Prefix information?

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Dec 2020 17:03:08 +0100

> the RA Prefix information?

Indeed the flag bit in an RA might be redundant, because the intent for 
variable length SLAAC is already obvious from the plen field of the RA 
prefix information option.

The latest implementation gets rid of that new RA bit.

We have to update the Internet Draft to reflect that change.

Alex, with input from co-author

---

From: David Farmer <[email-masked]>
Date: Thu, 17 Dec 2020 10:28:33 -0600

+1, more inline.

> Obviously anybody can just experiment without an RFC or endorsement from

Does anyone really doubt that the 64-bit boundary could be changed if there
was a consensus to do so? I don't think so. The argument has always been it
shouldn't be changed, not that it can't be changed, if we wish to do so. I
don't believe there is anything a formal experiment can tell us we don't
already know. This is merely an attempt to get the camel's nose into the
tent. NO, an experiment isn't necessary!

Thanks
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Dec 2020 17:30:03 +0100

Le 17/12/2020 à 16:01, Philip Homburg a écrit :
>> The experimental is to test this 3GPP  use case to change  the
>> IPv6 architecture RFC 4291 to eliminate 64 bit boundary.  As the
>> removal solution is the experimental using the sysctl to for slaac
>> to allow variable length prefixes to perform a study of impact to
>> endpoints using sysctl for v2v only thus would not impact other
>> devices. This would be a controlled method of testing variable
>> slaac.
> 
> Changing RFC 4191 has been debated for a long time,

RFC 4191 "Archi" must reflect most cases, that is why it takes long time.

> and there doesn't seem to be any consensus that changing the 64-bit 
> boundary is something that should be done.

There are a few additional paths that could be explored.

I would invite, if someone wants to, to be tempted to persuade the
mobile ISPs to deliver shorter-than-64 prefixes (e.g. a /56) to
smartphones, to formulate such a requirement in a more official manner.
  It should be something more efficient than a simple email.  It could be
a form of inception of a liaison statement to relevant regulatory bodies
or registries.  For my part, I can work on that with the tempted persons.

I also invite, if someone wants to, from regulatory bodies, to express
what they see in reality, which is the fact that mobile ISPs only
deliver /64s to terminals.  I am going to work in that direction too.

> It could be that an experiment provides input in a discussion, but in
> this case there seems to be no link between the discussion and the
> experiment.

I dont understand?  There is clearly a link between the discussion and
the experiment.

What in particular do you think is unlinked?

> So the only outcome of the experiment could be that a change that 
> violates one of the core standards of IPv6 would technically work. 
> However that doesn't seem to be in dispute.

I am not looking at anything that contradicts standards.  Standards are
valuable.

> Obviously anybody can just experiment without an RFC or endorsement 
> from the IETF.

That is fair as well.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Dec 2020 17:34:37 +0100

Le 17/12/2020 à 17:28, David Farmer a écrit :
> +1, more inline.
> 
> On Thu, Dec 17, 2020 at 9:01 AM Philip Homburg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Changing RFC 4191 has been debated for a long time, and there
> doesn't seem to be any consensus that changing the 64-bit boundary
> is something that should be done.
> 
> It could be that an experiment provides input in a discussion, but
> in this case there seems to be no link between the discussion and the
>  experiment.
> 
> Does anyone really doubt that the 64-bit boundary could be changed
> if there was a consensus to do so?

I am not asking to change the 64bit boundary.

If one is really convinced by the necessity of the 64bit boundary then I
would like to invite to promote to the mobile operators the delivery of
/56 to the end user.

Are you convinced by the necessity of the 64bit boundary?

Alex

  I don't think so. The argument has
> always been it shouldn't be changed, not that it can't be changed,
> if we wish to do so. I don't believe there is anything a formal 
> experiment can tell us we don't already know. This is merely an 
> attempt to get the camel's nose into the tent. NO, an experiment 
> isn't necessary!
> 
> Thanks -- =============================================== David 
> Farmer Email:[email-masked] <mailto:[email-masked]> 
> Networking & Telecommunication Services Office of Information 
> Technology University of Minnesota 2218 University Ave SE Phone:
> 612-626-0815 Minneapolis, MN 55414-3029   Cell: 612-812-9952

---

From: Philip Homburg <[email-masked]>
Date: Thu, 17 Dec 2020 19:08:43 +0100

> I dont understand?  There is clearly a link between the discussion
> and the experiment.

Currently RFC 4191 supports only 64-bit IIDs (with a specific exception).

The main worry of people against changing RFC 4191 is that where ISPs now
have to provide customers with a /64 (or shorter) some ISPs would in the
future provide way longer prefixes, bringing us back to square one.

> I am not looking at anything that contradicts standards.  Standards
> are valuable.

Given that there is no consensus to change RFC 4191 the obvious approach
is to avoid situations where you only have one /64.