Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses - other topic of /64

[Alexandre Petrescu <[e-mail]>]

Le 01/03/2021 à 21:08, Brian E Carpenter a écrit :
[...]

> although we do have a need for 3GPP operators to support prefixes 
> shorter than /64, but that's a deployment issue, not a standards 
> issue.

Hi, Brian,

I am very happy to see this problem mentioned here!

I would like to help progress on this deployment issue.

I might tend to agree that the problem of shorter-than-64 at cellular
operator is more a deployment issue, rather than a standards issue.
It's a deployment issue in that it would be sufficient that a 3GPP
operator sets a parameter in the big router facing the smartphone.  That
parameter sets the prefix length to be e.g. /56 and then that's it.
It's like when somebody configures an address on an interface or sets a
routing table entry - a mostly local matter.

However, there might be benefit from looking closer at this deployment
issue.

This deployment issue affects principally the 3GPP organisation.  An
oppinion explains that it might be sufficient to do something at 3GPP
about shorter-than-64 prefixes and subsequently all operators
implementing these 3GPP standards might permit allocation of
shorter-than-64 prefixes to end users.  It sounds natural.

But there are several aspects of the problem that were revealed in the
past about this kind of standards work:

- the positive: there would be a need of an Internet Draft (something
   that one might qualify as standards work at IETF) that 3GPP could
   refer to.  This draft might need to explain the requirement.  Then,
   3GPP could refer to this I-D, and make it a 3GPP requirement on its
   own.  It is probably that 3GPP document that the cellular operators
   might abide to.  And these two documents can easily be qualified as
   'standards work', I suspect.

- the negative: one should worry that in the past the 3GPP has written
   documents in which DHCPv6 Prefix Delegation is required on the UE and
   in the Core.  However, that 3GPP document is not implemented at any
   cellular operator.  As such, this could be considered a sort of
   'mistake', if I can say so.  This should not be repeated, if I can say
   so.

- there is a second negative, this time at IETF.  There is an RFC 7849
   "IPv6 Profile for 3GPP Mobile Devices" which
   clearly sets a requirement that the mobile must support DHCPv6-PD.
   That requirement is completely overlooked - no smartphone supports
   DHCPv6-PD.  Not only it's extremely rare to see a DHCPv6 PD client in
   a smartphone but their modems block DHCPv6 outright.  This again can
   be considered to be a sort of 'mistake' that should be avoided.

   We should not write another RFC or I-D that says something that nobody
   implements.

Alex

> 
> (BIER doesn't strike me as such a use case; an overlay is the
> natural solution and it's roughly what Rick Boivie and others
> proposed in XCAST 20 years ago, as eventually recorded in RFC5058.
> I'm fairly uninformed about ICN but again it seems to me that an
> overlay is the natural solution and blending it into the network
> layer would be spaghetti engineering.)
> 
> It would take but a minute to design a longer-address mechanism for 
> IPv6, although I don't have space to include it in the margin of
> this email**. But it would take many years for it to be widely
> implemented and deployed, during which time the Internet would be
> opaque to such addresses.
> 
>> We've already seen with SRv6 how more flexible use of addresses
>> can help solutions.
> 
> Have we really seen that? How many sites are running production 
> traffic using SRv6? In any case, 128 bits seem to be largely 
> sufficient for SRv6 purposes, since the semantics are local.
> 
> Brian
> 
> ** Basically, use a prefix such as fb00::/8 to indicate an extended 
> address.
> 
> _______________________________________________ Int-area mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/int-area
>