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

[Alexandre Petrescu <[e-mail]>]

Le 06/03/2017 à 08:02, [e-mail] a écrit :
> Alex,
>
> Please see inline.
>
> Cheers, Med
>
>> -----Message d'origine----- De : v6ops
>> [mailto:[e-mail]] De la part de Alexandre Petrescu
>> Envoyé : samedi 4 mars 2017 14:02 À : Lorenzo Colitti Cc :
>> [e-mail] WG Objet : Re: [v6ops] RFC7849 must not recommend
>> 64share, and must not be recommended itself to 3GPP
>>
>>
>>
>> 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:
>>>
>>>
>>>
>>> This document is not an Internet Standards Track specification;
>>> it is published for informational purposes.
>>
>> I agree.  I would like to echo that.
>>
>>> 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.
>>
>> 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.
>
> [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:
>
> 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 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)

> 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].

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).
>
> Prefix Delegation (refer to L_REC#2) is the target solution for
> 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].
>
> [RFC7278] must be invoked only if Prefix Delegation is not in use.

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
>
>