Subject: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 14:37:54 +0100

Hi v6opsers,

I suppose this RFC has been developped here in v6ops, otherwise please
excuse me.

This RFC is an Independent Stream (not IETF Stream, no Standards Track,
no BCP) RFC7849 "An IPv6 Profile for 3GPP Mobile Devices".

This RFC has a number of problems; they are related to its
recommendation of the INFORMATIONAL 64share RFC7278 at the loss of
DHCPv6-PD.

I propose to make this RFC7278 HISTORICAL, or find some other way to
discard its contents with respect to 64share and DHCPv6 PD (Errata?).

I also propose to inform officially 3GPP that this specific document
should not be taken at face value, but just For Your Information, if you
like it.

Here are the detail comments:

> ===== L_REC#1:  For deployments that require that the same /64 prefix
> be shared,

I think this formulation is a reverse formulation.

Some deployments need more than one /64, and an INFORMATIONAL solution
is to share one /64 among many subnets.  That does not mean the
deployment requires 'sharing' the same /64.  Deployments require
multiple /64s.

This should be either removed or corrected.

(and I understand yes that the word 'share' may have been used by some
as in 'WiFi is a shared link, as opposed to 3GPP being a ptp link', in
which case - yes, some deployments require the use of 'shared
links/WiFi' connected to a cellular link; beware the misinterpretations).

> the cellular device should support [RFC7278] to enable sharing a /64
>  prefix between the LAN and the WAN interfaces.

That is a wrong recommendation.

The right recommendation is the following: the cellular device SHOULD
support DHCPv6-PD.

And the text MUST NOT recommend sharing a /64 prefix.

> The WAN interface is the one towards the Gateway GPRS Support Node
> (GGSN) / Packet Data Network Gateway (PGW).
>
> Prefix Delegation (refer to L_REC#2) is the target solution for

It's not a 'target', it is a 'now'.  It comes before 64share.

> distributing prefixes in the LAN side but, because the device may
> attach to earlier 3GPP release networks, a means to share a /64
> prefix is also recommended [RFC7278].

No!  That recommendation is wrong.  That RFC is INFORMATIONAL and we
should stop recommending it.  I has huge problems, at least with respect
to scalability.

This backwards-compatible requirement does not make much sense here.  We
dont know what is a 'earlier 3GPP release network' with respect to
64share or DHCPv6-PD.  Since 64share puts no requirement on the network,
earlier 3GPP networks are precisely the same as newer 3GPP networks when
it comes to 64share.

> [RFC7278] must be invoked only if Prefix Delegation is not in use.

... _and_ if it works for the network being deployed.  If it does not
work, it MUST NOT be invoked.

> L_REC#2:  The cellular device must support Prefix Delegation
> capabilities [RFC3633] and must support the Prefix Exclude Option for
> DHCPv6-based Prefix Delegation as defined in [RFC6603].

Why is the 'prefix exclude' option a MUST?  I may need to understand
that, by further reading...

I am asking because that puts additional burden on the smartphone
implementer.

I suggest to make 'prefix exclude' an option, not a must.  Do not block
the deployment of DHCPv6-PD because 'prefix exclude' is absent.

> Particularly, it must behave as a Requesting Router.

Yes, and it is a MUST, not a must.

> Cellular networks are more and more perceived as an alternative to
> fixed broadband networks for home IP- based services delivery;

I agree.

> especially with the advent of smartphones and 3GPP data dongles.

_and_ M2M and IoT devices which are not 'dongles' (btw, 'dongles' are
only the USB dongles, there are no other kinds of dongles).

> There is a need for an efficient mechanism to assign larger prefixes
>  (other than /64s) to cellular hosts

I fully agree.

> so that each LAN segment can get its own /64 prefix

_if_ that LAN is an Ethernet, yes it needs a /64.  Often it is the case.

> and multi-link subnet issues to be avoided.

I agree, there is an RFC that must be cited there.

> In case a prefix is delegated to a cellular host using DHCPv6, the
> cellular device will be configured with two prefixes:
>
> (1)  one for the 3GPP link allocated using the Stateless Address
> Autoconfiguration (SLAAC) mechanism and
>
> (2)  another one delegated for LANs acquired during the Prefix
> Delegation operation.

I dont know what you mean by 'configured', but this second prefix may
just be in the rt table of the device (not necessarily on its
interfaces).  I dont understand why you say 'will be configured with two
prefixes'.

How about the default route?

> Note that the 3GPP network architecture requires both the WAN and the
> delegated prefix to be aggregatable so the subscriber can be
> identified using a single prefix.

Yes, it's good to avoid waste.

> Without the Prefix Exclude Option, the delegating router (GGSN/PGW)
> will have to ensure compliance with [RFC3633] (e.g., halving the
> delegated prefix and assigning the WAN prefix out of the first half
> and the prefix to be delegated to the terminal from the second
> half).

So 'prefix exclude' is not mandatory in order to have DHCPv6-PD working?
  Earlier it seemed mandatory.

> Because Prefix Delegation capabilities may not be available in some
> attached networks, L_REC#1 is strongly recommended to accommodate
> early deployments. =====

This is wrong.  We should _never_ recommend somehting we know it does
not scale.  64share does not scale, there is a 'multi-link subnets' RFC
and there is operational experience showing so.

Alex

---

From: Erik Kline <[email-masked]>
Date: Fri, 3 Mar 2017 22:43:56 +0900

> and there is operational experience showing so.

False.

We wrote IPv6 tethering in Android N (MR1), it uses 64share, and it pretty
much works just fine.

It is tricky if you want to further delegate from there, but works A-OK for
its stated intended purpose.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 14:53:57 +0100

Le 03/03/2017 à 14:43, Erik Kline a écrit :
> not scale.  64share does not scale, there is a 'multi-link subnets'
> RFC and there is operational experience showing so.
>
>
> False.
>
> We wrote IPv6 tethering in Android N (MR1), it uses 64share, and it
> pretty much works just fine.

Works fine but does is scale?

> It is tricky if you want to further delegate from there,

That 'tricky' scares me, really.

> but works A-OK for its stated intended purpose.

If its intended purposes are that 'deployments require 64 sharing', as
RFC7849 puts it, please let me say I have strong doubts.

If the intended purpose is "make one or two WiFi hotspots on a
smartphone" - then say so everywhere.  Do not generalise, or falsely
induce people into thinking 64share can be used to anything more than
just that.

Do not put this 64share into 3GPP specs.  Do not put this 64share into 
IETF documents having '3GPP' in their titles.

It's as if I put my preferred 'Hello World' software in 3GPP specs. 
True, it runs on a smartphone, but what more could 3GPP care about it.

3GPP does much more about extendign networks at the edges than just one
or two wifi hotspots on a smartphone.  64share does not scale to that.

But let me ask: what is the intended purpose of 64share from your point
of view?

Alex

---

From: Ca By <[email-masked]>
Date: Fri, 03 Mar 2017 16:09:36 +0000

> Works fine but does is scale?

Yes, millions of users (apple and android) on many networks use what is
described in 64share.  64share describes 100% of the cases where users get
ipv6 addresses via 3gpp phone tether afaik. Spare me the discussion about
how the dongle ....

I am unaware of any network or mainstream smartphone that supports
dhcp-pd.  I am sure you can rig something up, but i am simply referring to
your comment of scale in the real world for todays use cases.

This is ietf, running code matters. Deployments matter even more.

Bike shed colors do not matter, bike shed colors for flying bike to bike
communication is an interesting topic, but I suggest you avoid calling the
current bike shed a failure and keeping its deployment reality a dirty
secret. We tried that with nat44, it did not turn out well.

CB

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 18:10:44 +0100

Le 03/03/2017 à 17:09, Ca By a écrit :
>
> On Fri, Mar 3, 2017 at 5:54 AM Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
>  wrote:
>
>
>
>> Because Prefix Delegation capabilities may not be available in
>> some attached networks, L_REC#1 is strongly recommended to
>> accommodate early deployments. =====
>>
>>
>> This is wrong.  We should _never_ recommend somehting we know it
>> does not scale.  64share does not scale, there is a 'multi-link
>> subnets' RFC and there is operational experience showing so.
>>
>>
>> False.
>>
>> We wrote IPv6 tethering in Android N (MR1), it uses 64share, and
>> it pretty much works just fine.
>
> Yes, millions of users

Well, I did not ask about scaling in terms of how many times can you
copy the same software on how many devices, or how many human users can
buy smartphones from same operator.  I agree 64share (like most other
sw) can scale to millions of devices sold to millions of users as part
of some subscription plans.

I asked about scaling in terms of IP networking.

I dont want _your_ network to grow, I want the end user's network to
grow.  And your network must not prevent the end user's network from
growing.

64share prevents your end users' networks from growing.

So, while millions of users is good, I look more at like billions of
devices connected to these millions of users.

> (apple and android) on many networks use what is described in
> 64share.

It is good that apple and android implement that software.

But that alone does not make it more recommendable than a plethora of
other software, starting from the simplest 'Hello World'.

> 64share describes 100% of the cases where users get ipv6 addresses
> via 3gpp phone tether afaik.

Yes, 64share RFC describes use-cases where it's relevant.

But I guess, as you write below about bicycles, 64share does not
care about, well, bicycles.

And the bicycles are different than smartphones.

As such, I dont understand why pushing 64share into 3GPP, when 3GPP
cares not only about smartphones, but also about IoTs like bicycles.

As such, I dont understand why making 64share into a recommendation to 3GPP.

More refinement should be there.

> Spare me the discussion about how the dongle ....

Well - you dont care about dongles, I do.

I will spare you.

But you will have to change the way you think of your end users.  They
wont spare you about their dongles, M2M devices and other IoTs.

> dhcp-pd.

Dont you think that the question of whether or not DHCP-PD runs ok on
smartphone is irrelevant?  DHCP-PD is open source software, can compile
anywhere.

Assume DHCPv6-PD app runs ok on smartphone.

And that does not make the operator respond and deliver prefixes.  They
dont care about a smartphone running or not the DHCPv6-PD.  They care
about what 3GPP asks.  And 3GPP asks what this RFC says.  And this RFC
says no need of DHCP because do 64share.  That's not normal.

> I am sure you can rig something up, but i am simply referring to your
> comment of scale in the real world for todays use cases.

Ah, let me clarify my comment of scale.

I am concerned with scaling beyond 2 subnets: up to 45 subnets in 15
cars, and 10 subnets in 5 Road-Side Units, in a city center area.  And
that's the lowest number I could go with.

64share cant scale to that.  Do you agree?

This may be 'rigging up' for you, but for me it is more serious.

I agree.

But in this case it seems what you believe your smartphone deployment
should prime over what non-smartphone (e.g. bicycle) deployments need.

> Bike shed colors do not matter, bike shed colors for flying bike to
> bike communication is an interesting topic,

I agree with you that communicating bicycles may sound a far-fetched
scenario to some, but I also agree with hundreds of people working
precisely on the topic of communicating bicycles.  It saves lives.

The fact that you discard that as some 'flying' objects, presumably
assuming they are only on the drawing board, is not very kind.  Please
stop that.

Please do not be ignorant with topics that are important to others.

Moreover, I invite you to come and see the next demo events.

> but I suggest you avoid calling the current bike shed a failure and
> keeping its deployment reality a dirty secret.

I do not understand what you mean, but I want to let you know that I did 
work on connecting a Parking (including bike shed) to the IPv6 Internet.

I dont understand what you mean by 'keeping its deployment reality a 
dirty secret'.  The deployments I work often get publicized in public 
media and events.

> We tried that with nat44, it did not turn out well.

We agree on NAT is evil, but I dont understand: do you threaten with it?
I dont understand that here.

If we discuss threats, here is my reply:

It's now the 64share argument killing DHCP-PD at 3GPP that MAY make me
make a second deployment with NAT66.

Were 64share to be less all-encompassing in its claims, DHCPv6-PD may 
get in a stronger recommendation document to RFC, then to 3GPP and then 
to operators.

Alex

> If its intended purposes are that 'deployments require 64 sharing',
> as RFC7849 puts it, please let me say I have strong doubts.
>
> Do not put this 64share into 3GPP specs.  Do not put this 64share
> into IETF documents having '3GPP' in their titles.
>
> 3GPP does much more about extendign networks at the edges than just
> one or two wifi hotspots on a smartphone.  64share does not scale to
>  that.
>
> But let me ask: what is the intended purpose of 64share from your
> point of view?
>
> Alex
>
> _______________________________________________ v6ops mailing list
> [email-masked] <mailto:[email-masked]>

---

From: Ca By <[email-masked]>
Date: Fri, 03 Mar 2017 17:27:46 +0000

> > But let me ask: what is the intended purpose of 64share from your

Alex -- i suggests you re-read 64share to discover its intended purpose.

For your convenience, i provide this quote from it.

"DHCPv6 is the best way to delegate a prefix to a LAN link. The

   methods described in this document SHOULD only be applied when
   deploying DHCPv6 Prefix Delegation is not achievable in the 3GPP
   network and the UE.

"

So telling anyone about 64share is by association telling them dhcp-pd is
best.

Dhcp-pd will be deployed as soon as the business case justifies it, 64share
is a single LAN stop gap.

 Your issue is simply one of supply and demand. No ietf or 3gpp document is
lacking specification for making dhcp-pd happen.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 18:56:45 +0100

Le 03/03/2017 à 18:27, Ca By a écrit :
[...]

> "DHCPv6 is the best way to delegate a prefix to a LAN link.

I agree.

> The methods described in this document SHOULD only be applied when
> network and the UE."

I disagree with this formulation.  It leaves place for applying it.

The method in this document SHOULD NOT be applied because it is not a
scalable networking technology.

Please stop using it.

> "
>
> So telling anyone about 64share is by association telling them
> dhcp-pd is best.
>
> Dhcp-pd will be deployed as soon as the business case justifies it,

I think you are too much immediate business oriented.  Please have a
longer term look.

If you agreed that 64share is evil, then you may open the ways for even
more traffic into your network.

> 64share is a single LAN stop gap.

I agree.  It is single LAN, but it is not a stop gap.

It is a stop in that it stops creating the demand for scalable
networking technologies.  It stops the edge networks from growing.

> Your issue is simply one of supply and demand.

There is demand.  The supply is lacking.  Moreover, it looks as a
purposeful refusal to make supply, without any technical issue.

Are you interested in getting more traffic through your network?  Or not?

If you are interested in getting more traffic through your network then
give people more addresses - it's as simple as that.

> No ietf or 3gpp document is lacking specification for making dhcp-pd
> happen.

Were the above text corrected as I suggest, I would indeed agree with you.

Alex

>>  [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: Ca By <[email-masked]>
Date: Fri, 03 Mar 2017 18:08:53 +0000

> I disagree with this formulation.  It leaves place for applying it.

Correct , 64share was writen to be deployed.

> scalable networking technology.

I disagree with SHOULD NOT since i am certainly focused on immediate
business / engineering issues.

I do not have any more to offer on this topic.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 19:11:01 +0100

Le 03/03/2017 à 19:08, Ca By a écrit :
>
> On Fri, Mar 3, 2017 at 9:56 AM Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>

That is _too_ immediate business.  Maybe you should look at the longer term.

> I do not have any more to offer on this topic.

That's what I am asking - stop defending this RFC.

Alex

>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Simon Hobson <[email-masked]>
Date: Fri, 3 Mar 2017 19:11:49 +0000

> Are you interested in getting more traffic through your network?  Or not?

Based on past activities, I suspect that for many networks, the answer is "no" ! More specifically, I suspect many would see the inability to expand the client end network as an advantage - giving them an opportunity to charge extra from people who do want that extra functionality.
So as to "demand is there, supply isn't" - that may be as much a business decision (screw the customer) as technical foot dragging.

Or perhaps I'm just too cynical about mobile network operators.

---

From: Erik Kline <[email-masked]>
Date: Sat, 4 Mar 2017 11:11:40 +0900

It is true that it cannot really be used to scale beyond the one hop that's
doing the 64sharing.  Really the use is for when PD is not available (as
Cameron noted).

As the first paragraph of 7278 section 1 says, PD support is only even
theoretically possible in release-10 networks.

I am curious to know how many 3GPP networks (a) are release-10 or above and
(b) support PD.

Cameron: is there such info somewhere?

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 4 Mar 2017 13:56:37 +0900

RFC 7849 is not a product of v6ops. It's an independent submission and has
no standards value. It even says:

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741
<https://tools.ietf.org/html/rfc5741#section-2>.

If you don't like it, take it up with the authors.

If you want the IETF to declare RFC 7278 historic or say that it should not
or must not be used, write a draft and see if you can get consensus on it
in v6ops. Personally I doubt you'll reach consensus, but you're free to
take that path.

On 3 Mar 2017 10:37 pm, "Alexandre Petrescu" <[email-masked]>
wrote:

Hi v6opsers,

I agree.

I fully agree.

Alex

---

From: Ca By <[email-masked]>
Date: Sat, 04 Mar 2017 06:50:28 +0000

On Fri, Mar 3, 2017 at 7:12 PM Erik Kline <[email-masked]> wrote:

> It is true that it cannot really be used to scale beyond the one hop
> that's doing the 64sharing.  Really the use is for when PD is not available
> (as Cameron noted).
>
> I am curious to know how many 3GPP networks (a) are release-10 or above
> and (b) support PD.
>

Any given 3GPP network is not one release or another. Most mobile operators
are effectively systems integrators that stitch together multiple
 technologies.  For example, t-mobile usa is deploying LAA this year.  Does
that make t-mobile a release 12 network?  Not strictly.

> Cameron: is there such info somewhere?

Not that i know of.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 4 Mar 2017 14:01:43 +0100

Le 04/03/2017 à 05:56, Lorenzo Colitti a écrit :
> RFC 7849 is not a product of v6ops.

Seems so... although I remember there was some discussion here about it.

> It's an independent submission and has no standards value. It even
> says:
>
>
>

I agree.  I would like to echo that.

> If you don't like it, take it up with the authors.

There are very many.

Is there one that is the main author?

> If you want the IETF to declare RFC 7278 historic or say that it
> should not or must not be used, write a draft and see if you can get
> consensus on it in v6ops.

There is already such an RFC - it is DHCPv6-PD and other Stds Track RFCs 
that cite it.

I could write another draft in support of DHCPv6-PD, or I could help
someone to.  In the past I already did for some RFCs supporting DHCPv6-PD.

But isn't that enough documents already present?  Arent they enough to 
warrant the invalidation of this particular RFC?

> Personally I doubt you'll reach consensus, but you're free to take
> that path.

Thanks for encouraging me :-)  But seriously I appreciate invitations to 
write drafts.

Alex

>
> On 3 Mar 2017 10:37 pm, "Alexandre Petrescu"
> I suppose this RFC has been developped here in v6ops, otherwise
> please excuse me.
>
> This RFC is an Independent Stream (not IETF Stream, no Standards
> Track, no BCP) RFC7849 "An IPv6 Profile for 3GPP Mobile Devices".
>
>  should not be taken at face value, but just For Your Information,
> if you like it.
>
> Some deployments need more than one /64, and an INFORMATIONAL
> solution is to share one /64 among many subnets.  That does not mean
> the deployment requires 'sharing' the same /64.  Deployments require
>  multiple /64s.
>
> (and I understand yes that the word 'share' may have been used by
> some as in 'WiFi is a shared link, as opposed to 3GPP being a ptp
> link', in which case - yes, some deployments require the use of
> 'shared links/WiFi' connected to a cellular link; beware the
> misinterpretations).
>
>  should stop recommending it.  I has huge problems, at least with
> respect to scalability.
>
> This backwards-compatible requirement does not make much sense here.
> We dont know what is a 'earlier 3GPP release network' with respect to
> 64share or DHCPv6-PD.  Since 64share puts no requirement on the
> network, earlier 3GPP networks are precisely the same as newer 3GPP
> networks when it comes to 64share.
>
> I suggest to make 'prefix exclude' an option, not a must.  Do not
> block the deployment of DHCPv6-PD because 'prefix exclude' is
> absent.
>
> interfaces).  I dont understand why you say 'will be configured with
> two prefixes'.
>
> So 'prefix exclude' is not mandatory in order to have DHCPv6-PD
> working? Earlier it seemed mandatory.
>
> <https://www.ietf.org/mailman/listinfo/v6ops>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 4 Mar 2017 14:07:57 +0100

Cameron,

In adition to this release clarification that I thank for.

I would like to ask: when an operator stitches some protocol to others, 
like LAA, how much dependent is she of, say, a router manufacturer such 
as Ericsson, for example?

Could it be the case that one particular manufacturer avoids 
implementing some protocol because of IPR conditions?

Alex

Le 04/03/2017 à 07:50, Ca By a écrit :
>
> On Fri, Mar 3, 2017 at 7:12 PM Erik Kline <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     that's doing the 64sharing.  Really the use is for when PD is not
>     available (as Cameron noted).
>
>     As the first paragraph of 7278 section 1 says, PD support is only
>     even theoretically possible in release-10 networks.
>
>     I am curious to know how many 3GPP networks (a) are release-10 or
>     above and (b) support PD.
>
>
> Any given 3GPP network is not one release or another. Most mobile
> operators are effectively systems integrators that stitch together
> multiple  technologies.  For example, t-mobile usa is deploying LAA this
> year.  Does that make t-mobile a release 12 network?  Not strictly.
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Sat, 4 Mar 2017 12:12:24 -0800

> On Mar 4, 2017, at 5:01 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

It was introduced in v6ops and discussed. It went through several revisions, including being adopted by the working group and then dropped due to dissent.

  - https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-reqs-rfc3316update
  - https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements
  - https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile

I think the fairest thing to say is that there were three separate consensuses in the discussion: those that supported it (the authors, representing a number of 3GPP networks), those that didn't (a set of people who also worked in 3GPP), and those that wished we would talk about something else. The chairs (Joel and I) eventually suggested to the authors that they publish it in the Independent Stream, which they did.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Mar 2017 15:57:00 +1300

> I think the fairest thing to say is that there were three separate consensuses in the discussion: those that supported it (the authors, representing a number of 3GPP networks), those that didn't (a…

So why are we even discussing a document whose boilerplate says things like

  "The consensus-based IETF description of IPv6 functionality for
   cellular hosts is described in RFC 7066.
   ...
   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   Standard..."

?

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 5 Mar 2017 13:29:38 +0100

Le 04/03/2017 à 21:12, Fred Baker a écrit :
> It was introduced in v6ops and discussed. It went through several
> revisions, including being adopted by the working group and then
> dropped due to dissent.
>
> -
> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-reqs-rfc3316update
>
>
>
-
https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements
> -
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile
>
>
>
I think the fairest thing to say is that there were three separate
> consensuses in the discussion: those that supported it (the authors,
> representing a number of 3GPP networks), those that didn't (a set of
> people who also worked in 3GPP), and those that wished we would talk
> about something else. The chairs (Joel and I) eventually suggested
> to the authors that they publish it in the Independent Stream, which
> they did.

Hi Fred,

I think that course of action looks reasonable.  I think often RFCs get
this path of independent stream.

However, I would like to raise a strong doubt about making RFC at IETF
when IETF does not want it to be an RFC.

I think it is a waste of time from both IETF process participants, and
also from operators redirecting me to that RFC while also telling me it
has little value other than simply having "IETF" and "3GPP" in its front
page.

If it is an individual ambition from authors and Sponsor, then it could
stay at Internet Draft level - experience shows now Internet Drafts live
long time even though they are 'expired'.  Or it could be published as
other means.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 5 Mar 2017 13:30:48 +0100

>    published for informational purposes.

As such, it should not have an RFC number.

There are many I-Ds out there without RFC numbers - they are also for 
informational purposes.

>    the RFC Editor are not a candidate for any level of Internet

As such, it should not have an RFC number.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Mar 2017 08:07:57 +1300

> As such, it should not have an RFC number.

The IETF does not own the RFC series. See https://www.rfc-editor.org/about/independent/
and RFCs 5741, 5742, 6548.

  Brian (member of the ISEB, https://www.rfc-editor.org/about/ISEB/ )

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 5 Mar 2017 20:28:34 +0100

Le 05/03/2017 à 20:07, Brian E Carpenter a écrit :
[...]
>>> cellular hosts is described in RFC 7066. ... This document is
>>> not an Internet Standards Track specification; it is published
>>> for informational purposes.
>>
> The IETF does not own the RFC series. See
> https://www.rfc-editor.org/about/independent/ and RFCs 5741, 5742,
> 6548.

I will look at that.

Until then:

The RFC-Editor MUST NOT publish documents which are _against_
technically valid oppinion of professionals of the technology,
represented in the WG.

When the RFC-Editor carefully Edits text written by the technically
inclined, the technically inclined does not dare to correct them back,
right?  In return, the RFC-Editor should not publish technical oppinion
which is against technical oppinion of a particular WG.  They dont have
the appropriate skillset to qualify that.

I could agree they could publish something that is neutral, like an
April Fool's RFC.  But it is obvious this document is far from neutral:
it even lists requirements(!)

How could someone publish something that says "deployments require X"
when people doing these deployments say "deployments require Y"?

Also, I wonder whether Authors of the document are conscious that that
document has no value whatsoever?  If it were so, the document would not
even be invoked, in any discussion... so why publishing it at all?  But
I think the Authors believe this RFC has some value, they are using it
somehow, otherwise they would not agree publishing it.

Who can gain from this?  How is the document used?  Does the RFC-Editor
have some explanation about that?

(and no, I will not write a document about what may appear a destructing
activity; I prefer continue working in a constructive way towards
deployment of DHCPv6-PD in 3GPP networks - the "target";
I just hope the RFC Editor does not make that harder :-)

Alex

>> There are many I-Ds out there without RFC numbers - they are also
>> for informational purposes.
>>
>>> This is a contribution to the RFC Series, independently of any
>>> other RFC stream.  The RFC Editor has chosen to publish this
>>> document at its discretion and makes no statement about its
>>> value for implementation or deployment.  Documents approved for
>>> publication by the RFC Editor are not a candidate for any level
>>> of Internet Standard..."
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Mar 2017 08:44:35 +1300

> technically valid oppinion of professionals of the technology,

Well, actually, that is exactly what the Independent series of RFCs
*can* do. This is not the list for that discussion, however. 

    Brian

---

From: <[email-masked]>
Date: Mon, 6 Mar 2017 07:02:21 +0000

Alex, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Alexandre
> Petrescu
> Envoyé : samedi 4 mars 2017 14:02
> À : Lorenzo Colitti
> Cc : [email-masked] WG
> Objet : Re: [v6ops] RFC7849 must not recommend 64share, and must not be
> recommended itself to 3GPP
> 
> 
> 

[Med] For the matters discussed in RFC7849, the only available RFC with an IETF consensus is: RFC7066. This RFC reflects the current 3GPP documents: 

   Starting from Release-10, DHCPv6 Prefix Delegation was added as an
   optional feature to the 3GPP system architecture [RFC3633].  The
   Prefix Delegation model defined for Release-10 requires that the /64
   IPv6 prefix assigned to the cellular host on the 3GPP link must
   aggregate with the shorter delegated IPv6 prefix.  The cellular host
   should implement the Prefix Exclude Option for DHCPv6 Prefix
   Delegation [RFC6603] (see [RFC6459], Section 5.3 for further
   discussion).

I'm quite sure that language is not what you are looking for. If so, you can add RFC7066 to your list of RFCs to be updated. I will be supportive.

FWIW, you can grab some motivation text from RFC7849, that says explicitly the following: 

   This profile uses a stronger language for the support of Prefix
   Delegation compared to [RFC7066].  The main motivation is that
   cellular networks are more and more perceived as an alternative to
   fixed networks for home IP-based services delivery; especially with
   the advent of smartphones and 3GPP data dongles.  There is a need for
   an efficient mechanism to assign larger prefixes to cellular hosts so
   that each LAN segment can get its own /64 prefix and multi-link
   subnet issues to be avoided.  The support of this functionality in
   both cellular and fixed networks is key for fixed-mobile convergence.

Unless you have a better solution to share a single /64 prefix over a cellular network when PD is not supported (device, network, or both), the recommendation in RFC784 is the way the proceed (of course, from the standpoint of the authors of that RFC). 

Cheers,
Med

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Mar 2017 16:19:41 +0100

Le 06/03/2017 à 08:02, [email-masked] a écrit :
> Alex,
>
> Please see inline.
>
> Cheers, Med
>
>> -----Message d'origine----- De : v6ops
>> [mailto:[email-masked]] De la part de Alexandre Petrescu
>> Envoyé : samedi 4 mars 2017 14:02 À : Lorenzo Colitti Cc :
>> [email-masked] WG Objet : Re: [v6ops] RFC7849 must not recommend
>> 64share, and must not be recommended itself to 3GPP
>>
>>
>>
>>> It's an independent submission and has no standards value. It
>>> even says:
>>>
>>>
>>>
>>> This document is not an Internet Standards Track specification;
>>> it is published for informational purposes.
>>
>>> of Internet Standard; see Section 2 of RFC 5741
>>>  should not or must not be used, write a draft and see if you
>>> can get consensus on it in v6ops.
>>
>> There is already such an RFC - it is DHCPv6-PD and other Stds
>> Track RFCs that cite it.
>
> [Med] For the matters discussed in RFC7849, the only available RFC
> with an IETF consensus is: RFC7066.

Med, as I said, DHCPv6-PD is a Standards Track document and is agreed
and implemented and consensual.  Why does not RFC7849 require it?  Why
does RFC7849 require something else?

> This RFC[7066] reflects the current 3GPP documents:
>

I agree with RFC7066.

So why does not RFC7849 require DHCPv6-PD too?

Why does RFC7849 require something else than DHCPv6-PD?

> I'm quite sure that language is not what you are looking for.

I agree.

> If so, you can add RFC7066 to your list of RFCs to be updated. I
> will be supportive.

RFC7066 is fine with respect to DHCPv6-PD: it seems to require it.  As
such I agree with it.

(it has some other issues in detail, but I agree with RFC7066 and its
stance it takes with respect to DHCPv6-PD)

> Delegation compared to [RFC7066].

Excuse me, Med, but this RFC7849 says:
> L_REC#1:  For deployments that require that the same /64 prefix be
> shared, the cellular device should support [RFC7278] to enable
> sharing a /64 prefix between the LAN and the WAN interfaces.  The WAN
> interface is the one towards the Gateway GPRS Support Node (GGSN) /
> Packet Data Network Gateway (PGW).
>

This text is not an invitation to use DHCPv6-PD.  It is an invitation to
use 64share.

I fully disagree with this text.

BEcause of that, I disagree with you saying that DHCPv6-PD uses an even
stronger language to support DHCPv6-PD, than RFC7066.

RFC7066 does not even mention 64share, whereas RFC7849 requires it.

If its "L_REC#2" requiring  DHCPv6-PD came _before_ "L_REC#1" then I'd 
agree with you.

But as of now the reverse is true: RFC7849 requires _first_ 64share and 
only second DHCPv6-PD.  As such it delays arrival of DHCPv6-PD.

> The main motivation is that cellular networks are more and more
> perceived as an alternative to fixed networks for home IP-based
> services delivery; especially with the advent of smartphones and 3GPP
> data dongles.  There is a need for an efficient mechanism to assign
> larger prefixes to cellular hosts so that each LAN segment can get
> its own /64 prefix and multi-link subnet issues to be avoided.  The
> support of this functionality in both cellular and fixed networks is
> key for fixed-mobile convergence.

I agree.  But not with 64share.

> Unless you have a better solution to share a single /64 prefix over
> a cellular network when PD is not supported (device, network, or
> both), the recommendation in RFC784 is the way the proceed (of
> course, from the standpoint of the authors of that RFC).

Med - with all due respect that I have to your oppinion, and about the
IPv6 connections about which I am very happy.

Here is my answer: /64share is a non-scalable technology that hurts more
than it helps.

There are many other protocols that could be used.  Each of these has 
been standardised and has consensus at IETF.  The most prominent of 
these protocols, that most consider most viable is this: DHCPv6-PD.

And that is a protocol that a 3GPP network may have something to say 
about, whereas a 3GPP network should never impose a User Equipment to 
share some prefix.

IP addresses are unique and distinct, they are not to be shared.

Alex

> Cheers, Med

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Mar 2017 11:48:17 -0800

You may be correct. My understanding of the author's intention/usage is that, like anyone that purchases equipment and software, they include in their RFP/RFQ references that they want a vendor to say they support. They can use this in that context. The IETF is not recommending it, but a purchasing agent might require it for products used in their network.

There is an issue with posting as an internet draft and leaving it hanging in space. We claim that they disappear, and we actually kinda-sorta make it look that way. We also state, in the I-D boilerplate, that folks shouldn't reference it. It becomes referencable when it gets an RFC number. Now, there's what we say and what we do, I understand, but we do try to pretend that they are the same thing.

The Independent Stream, whether or not it has been called that (it was once called "I sent something to Jon"), has been with use since the RFC series came into existence. It publishes April Fool's RFCs, poetry (RFC 968), white papers, and a variety of other things. And yes, companies have published what are otherwise proprietary protocols or descriptions of proprietary technology. We didn't call it the "Independent Stream" in 1994, we simply called it "publishing as INFORMATIONAL" or "...EXPERIMENTAL", but RFC 1701/2 (GRE) was pretty much that; we knew how to send IP/IP and a few other things, but we needed a way to send AppleTalk/IP, SNA/IP, and etc. The authors designed and published a way to do it, which allowed other companies to also use it at their discretion. Six years later, it was updated and published as a Proposed Standard, and there has been further work. Think of RFC 1701/2 as a pair of "Internet Drafts", if you will, that had a longer lifetime. When we had experience with it, we collectively decided we wanted an actual consensus document. And the rest is history.

My point being that using the Independent Stream for this kind of thing isn't exactly new. It's not something I would recommend to anyone, but it is a tool that is available.
 
> On Mar 5, 2017, at 4:29 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>