Re: [ipwave] IETF-115 IPMON BoF Side Meeting

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Jari,
Thanks for your very constructive and insight-giving comments and questions.
I put my opinions inline below with the prefix [PAUL].

On Thu, Nov 10, 2022 at 10:17 AM Jari Arkko <[e-mail]> wrote:

> I wanted to send some notes from my perspective. To be clear, I’m sending
> this as a personal opinion as a generalist who has very little knowledge
> about V2X, ITS, etc. but who has some knowledge of the IPv6 mechanisms for
> traditional cellular network connections. Feel free to treat these comments
> the way you see fit, including ignoring them as appropriate :-)
>
> This was a constructive meeting where I at least learned some new things
> and new questions. Thanks all!
>
> The meeting covered the 5G V2X case, neighbor discovery, mobility, there
> was a talk about an interesting hackathon project, and so on. I got
> interested on this topic due to the recent BOF proposal that mentioned work
> was needed to 'specify the mechanisms for transmission of IPv6 datagrams
> over either 3GPP 5G V2X or IEEE 802.11bd V2X’. I was curious as to what
> extent this had already been defined, and also, there was lack of detail of
> what actually needed to be done.
>
> In the meeting I think I understood some of the thinking from the point of
> view of the 5G case; there’s a desire to figure out how to use DAD, how to
> assign addresses, and how to use mobility to support long-standing
> sessions. Did I get this right? In any case, these are fine things to wish
> to do, but I still have some questions :-) Two types of questions,
> actually, both technical and those related to who should specify what.
>
> So the technical questions that came to my mind are:
>
> 1/ The case for using DAD seems to depend on what kind of model one wants
> to have, and it wasn’t clear to me which model is actually desired, or
> perhaps more to the point, why. If you use the infrastructure uplink model,
> there there are no collisions and DAD is not needed. If you want
> device-to-device connections then you may have to do something, but that
> something could be (a) infrastructure still giving you unique IIDs (b) you
> run a DAD process and keep re-checking as participants on the link change
> or (c) have some node assign you an address.
>
 => [PAUL] What do you mean by 'infrastructure uplink model'?
      As long as I understand, this model seems like an infrastructure node
(e.g., UPF) allocates a unique IPv6 prefix to a vehicle as a UE.
      In this case, you are right that there is no need of DAD for the
vehicle's IPv6 address based on the allocated prefix because the uniqueness
      of the IPv6 address is guaranteed.
      According to TS 23.287, one of two UEs should act as an IPv6 default
router, and advertise its prefix to the other UE. The first UE should get a
      prefix from the infrastructure node (e.g., UPF) somehow (by IPv6
Prefix Delegation in RFC3633). This prefix delegation should be specified by
      3GPP. Which UE will as an IPv6 default router in a high-speed and
highly-dynamic-topology VANET should be also specified by 3GPP.

>
> 2/ For mobility, there are similar questions. There’s mobility already
> today at several layers, provided by the cellular infrastructure, and
> built-in to various applications and transports that have capability to
> continue even when addresses change. Do we want (a) to use the
> infrastructure uplink and its mobility support for enabling long-lasting
> sessions while the devices move? Or (b) introduce an additional layer on
> top of that, for situations where you change networks? Or (c) build some
> kind of external-world ad hoc connectivity from the device-to-device
> connections, along with some support for mobility?
>
  => [PAUL]Though your definition of infrastructure uplink is not clear to
me, mentioned in 1/ above, we want to support for enabling long-lasting
sessions
       while the UEs move along their trajectory by pre-assigning the
relevant UPFs and gNodeBs with their trajectory information.
       Maybe we consider an additional layer for this continuent session
management along with AMF. UEs need to maintain the connectivity to an RAN
       through multihop VANET to an UPF that has a door to the Internet.

>
> 3/ 3GPP allows both link local and SLAAC-based assignment of addresses
> within advertised prefixes. For running address assignment, SLAAC with
> prefix seems to require one of the nodes willing to do this to act as
> routers and assign addresses. This would seem to require a configured
> prefix, where does that come from? (Does 3GPP specify this?)  But are we
> doing SLAAC with prefixes, or are we doing only link-local addresses? Why
> or why not?
>
  => [PAUL] I discussed this prefix assignment issue that seems not
specified by 3GPP. In order that a UE can reach a server in the Internet,
it may need
       forwarding service from relaying UEs in the multihop VANET toward a
gNodeB.

>
> With regards to who should specify what — 3GPP has defined the IPv6 usage
> for their system. If that needs to change, then it would probably be 3GPP
> that should do that. You could make a proposal for that to the 3GPP. On the
> other hand, if you are specifying something on top the 3GPP system (e.g.,
> communicate with a server that performs some functions), then that could be
> a general thing specified in the IETF. It is not entirely clear what
> category the different things we talk about are. What is your opinion?
>
 => [PAUL] In the case of multihop VANET connected to the 3GPP RAN, since
the second approach requires multihop DAD for IPv6 address
      configuration and multihop routing to the RAN in 5G system, it seems
like the IETF is a right place to handle the issues that you mentioned
above.
      However, the proponents of IPMON will investigate those issues
carefully and prepare for a non-WG forming BoF in IETF 116 in Yokohama.

      Thanks.

      Best Regards,
      Paul

>
> Anyway, I don’t pretend that I have answers to any of the above questions,
> but I think it would be worthwhile you have them before the BOF in
> Yokohama. For instance, if option X gives you grief and you want to improve
> the technology to make it easier, let's make sure we understand why we are
> doing X and not Y to begin with. Obviously there can be many reasons why
> one would need to pick a specific direction. This can be clear in your
> heads right now :-) But it would be useful if those reasons and decisions
> were spelled out for the rest of us as well :-)
>
> Hope this helps,
>
> Jari
>
> P.S. Part of the meeting went also into a discussion about cellular vs.
> wireless lan technologies. I think there will be two competing models,
> maybe more interesting to figure out what we do on these platforms instead.
>
>