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
[email protected] https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
