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

[Lorenzo Colitti <[e-mail]>]

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" <[e-mail]>
wrote:

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

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