IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
draft-ietf-ipwave-vehicular-networking-30

[Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

Thank you for making edits in response to my DISCUSS positions.  Despite these changes, it is my assessment that the security and privacy properties are not sufficiently described given the wide array of enabling technologies cited (e.g., credit-based authorization models, blockchain based authentication and logging, in vehicle credit card transactions).  Furthermore, the document references architectural elements such as “legal vehicles” and “legal … smartphones”; and threats such as “privacy breakage” without sufficient explanation.

For the reasons above and a few noted by Rob Wilton in his ballot, I am abstaining on this document.  The IESG DISCUSS criteria (https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc) is not applicable to my above concerns since no protocol is being described and the guidance presented here is not intended to be implemented without significant further design and specification.

[Ballot discuss]
Thanks for all of the changes in -29 to address the DISCUSS points noted for -28.  To help us talk these through the remaining issues, I have updated my ballot to remove issues that have already been resolved.  I have also provided feedback on the new text in -29 intended to resolve the original DISCUSS points.

(1) The Privacy Considerations are under-specified:

(1.a) [per -28] Section 6.3 suggests the needs for logging, “To deal with this kind of security issue, for monitoring suspicious behaviors, vehicles' communication activities can be recorded in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) along with other vehicles or infrastructure.  To solve the issue ultimately, we need a solution where, without    privacy breakage, …”.  Some discussion on the “privacy breakage” is needed.  What exactly would be the trade offs between a centralized vs. distributed log?  Who would get to see this information?  What is sensitive about this information?

From -29:
  Alternatively, for
  completely secure vehicular networks, we shall embrace the concept of
  "zero-trust" for vehicles in which no vehicle is trustable and
  verifying every message (such as IPv6 control messages including ND,
  DAD, NUD, and application layer messages) is necessary.  In this way,
  a failure to prevent a cyberattack shall never happen on a vehicular
  network.  Thus, we need to have an efficient zero-trust framework or
  mechanism for vehicular networks.

I’m speculating that the second from last sentence, “[i]n this way, a failure to prevent a cyberattack shall never happen on a vehicular network” was added to partially respond to the above feedback.  Saying that an attack will “never” success due to a zero-trust framework is not plausible.  Could this please rephrased.

(1.b) [per -28] Section 3.3 notes a V2P use case where the pedestrian’s smart-phone is sharing unspecified information.  Does that include location
information?  Who gets it?  What kind of identifiers are shared?

Thanks for adding the following text -29:

  The location information of a VRU from a smart device is multicasted
  only to the nearby vehicles.  The true identifiers of a VRU's
  smartphone shall be protected, and only the type of the VRU, such as
  pedestrian, cyclist, and scooter, is disclosed to the nearby
  vehicles.

To clarify, this “multicasted” in the IPv6 sense?  The VRU’s smartphone is using some kind of “fake identifier” (source address?) to announce its presence so as not to reveal its “true identifier”?  Is there a security consideration (attack) that these “fake identifiers” multicasting to nearby vehicles could convince that vehicle that they are surrounded by pedestrians (e.g., roughly https://www.abc.net.au/news/2020-02-04/man-creates-fake-traffic-jam-on-google-maps-by-carting-99-phones/11929136)? 

Can we state the security properties or provide a reference to handle this issue.  I see the following text later in the section:

  To support applications of these V2X use cases, the required
  functions of IPv6 include IPv6-based packet exchange, transport-layer
  session continuity, and secure, safe communication between a vehicle
  and a pedestrian either directly or indirectly via an IP-RSU.

I don’t recognize the desired properties of protecting identifiers as being congruent with the above text.

(2) Section 4.2

  Note that it is dangerous if the
  internal network of a vehicle is controlled by a malicious party.  To
  minimize this kind of risk, an reinforced identification and
  verification protocol shall be implemented.

-- [per -28] Who are the parties in this verification protocol?  What security properties is this verification providing?

[new per -29] Thanks for adding this new text in -29 in response:

  To minimize this kind of risk,
  an augmented identification and verification protocol with extra
  means shall be implemented.  These extra means can be certificate-
  based, biometric, credit-based, and one-time passcode (OTP)
  approaches in addition to a used approach [RFC8002].  The
  verification shall provide security properties such as
  confidentiality, integrity, authentication, authorization, and
  accounting [RFC7427].

I’m having trouble understanding this guidance.  The architecture is suggesting “augmented identification and verification with extra means.”  I don’t follow what “augmented means” or “extra” -- augmented or extra from what baseline?  The security properties this provides is “confidentiality, integrity, authentication, authorization and accounting” don’t seem to match authentication and identity topics. 

To the specific examples, how does “credit-based” provide the stated security properties?  I have the same question for the others.

** [per -28 and same for -29] The need for safety properties (very helpful) is asserted multiple times but not further discussed in the Security Considerations:

-- Section 3: 
      In addition, IPv6
      security needs to be extended to support those V2V use cases in a
      safe, secure, privacy-preserving way.

-- Section 3.1:
      To support applications of these V2V use cases, the required
    functions of IPv6 include IPv6-based packet exchange and secure,   
    safe communication between two vehicles. 

-- Section 3.3:
  To support applications of these V2X use cases, the required
  functions of IPv6 include IPv6-based packet exchange, transport-layer
  session continuity, and secure, safe communication between a vehicle
  and a pedestrian either directly or indirectly via an IP-RSU.

The explanation from the authors noted that the following text was added to Section 4.2 -29:

“A malicious party can be a group of hackers, a criminal group, and a competitor for industrial espionage or sabotage.”

“The verification shall provide security properties such as confidentiality, integrity, authentication, authorization, and accounting [RFC7427].”

I’m having trouble understanding how this text addresses the safety properties.

[Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

Thanks for addressing the other COMMENTs in -29.

** Section 6.3.  Per the proposed use of blockchain for "IPv6 transaction", thanks for making a few edits per the more granular feedback on -28.  I leave it to the WG, but I think this guidance seems speculative, under-specified, and one of only a number of candidate architectures.  It seems misplaced to be calling it out here.

[Ballot comment]
Thank you for the work put into this document. I found the use cases part of section 3.1 very interesting to read even if some of them seem very far fetched ;-)

I have now cleared my previous blocking DISCUSS points as you have addressed them as well as all but one of my previous non-blocking COMMENTs. Thanks for your reaction.

I have kept below the DISCUSS & COMMENT points just for archiving, please ignore them.

Special thanks to

- Carlos Bernardos for the shepherd's write-up even if a justification for the informational status would have been welcome but the WG consensus description is appreciated.

- Pascal Thubert for his IETF last call INT directorate review at: https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-20-intdir-lc-thubert-2021-06-18/ and for his IESG telechat INT directorate review https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28/ Pascal's Last Call & telechat reviews were (at least partially) acted upon by Paul ;-)

I hope that this helps to improve the document,

Regards,

-éric

# DISCUSS (just for archiving)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Abstract & Section 1

"then enumerates requirements for the extensions of those IPv6 protocols" does not match any IPWAVE WG work item, i.e., it is outside the scope of the charter of IPWAVE WG. As the document does not explicitly specify requirements, I strongly suggest to use the word "gaps" rather than "requirements" in the abstract and section 1.

## Section 4.1

Using an IPv6 address out of a ULA prefix still requires DAD. So the text below should be updated to be corrected:
  "their own IPv6 Unique Local Addresses
  (ULAs) [RFC4193] over the wireless network, which does not require
  the messaging (e.g., Duplicate Address Detection (DAD)) of IPv6
  Stateless Address Autoconfiguration (SLAAC) [RFC4862]."

## Section 4.2

Very similar comment as above (i.e., DAD & MLD must be done for all IPv6 addresses of an interface and not only for the global one):
  "... When global IPv6
  addresses are used, wireless interface configuration and control
  overhead for DAD"

## Section 5.2
  "... If DHCPv6 is used to assign
  a unique IPv6 address to each vehicle in this shared link, DAD is not
  required. "
This is incorrect and must be changed (see section 18.2.10.1. of RFC 8415)

# COMMENTS (just for archiving)

"100km/h as the speed limit in highway" will make many European drivers smile as it is really slow...

## Section 1

"Most countries and regions in the world have adopted the same frequency allocation for vehicular networks." but there are TWO frequency allocations described just before, so, which one has been adopted ?

## Section 2

"GPS" is just the USA commercial example of the more generic "global navigation satellite system" (GNSS), GNSS should be used in this document.

As IP-RSU have at least 2 interfaces, should "Also, it may have *the* third IP-enabled wireless interface" be replaced by "Also, it may have *a* third IP-enabled wireless interface" ?

LiDAR ... "by measuring the reflected pulsed light" but on which kind of metrics ?

## Section 3.1

Should the 1st and 5th bullets be grouped together ?

Please describe "UAM" (e.g., in the terminology section) as it is unclear to the reader whether it is a crewed / uncrewed aircraft.

If both road and air vehicles are use case, what about river / sea ships or trains ?

Does the paragraph about "reward system" belong to the use case ? It rather sounds like a business requirement. Suggest to remove this part.

Like written by Pascal Thubert in his telechat review, the last paragraph "IPv6-based packet exchange and secure" should be clear that this is not only about data plane traffic but also control plane L2/L3 ones. Please also use the Oxford comma, i.e., add a "," after "exchange".

## Section 3.2

Suggest to also mention "5G" after "IP-RSU or 4G-LTE networks"

How is the UAM use case different from a driverless terrestrial EV ? Suggest to merge those use cases.

## Section 4.1

As noted by other ADs, "Existing network architectures," the list should not include OMNI yet as it is not deployed and would probably not be described as an architecture.

"the wireless media interfaces are autoconfigured with a global IPv6 prefix", is it the same shared prefix or multiple prefixes ?

Is "RSU" the same concept as "IP-RSU" ?

The last paragraph is about TCP session continuity, but does not explain why multi-path TCP or QUIC session resumption cannot be used.

## Section 4.2

The computation about "dwell time" is interesting even if it is computed in the best case. But, I really wonder whether using IPv6 and routing are applicable to the use case as opposed to more layer-2 + tunnel solutions (like 3GPP) with such short time for hand-over. I am a strong supporter of layer-3 (IPv6 and routing), but I cannot refrain from thinking that IPv6 is the wrong technical solution for those use cases... Was this discussed in the WG ?

## Section 5.1

What is "legacy DAD" ?

  "...the NA interval needs to be
  dynamically adjusted according to a vehicle's speed so that the
  vehicle can maintain its neighboring vehicles in a stable way"
With the issues linked to multicast over wireless, are the authors and the WG sure that increasing the amount of multicast will not aggravate the problem ? See RFC 9119 (cited as a normative down reference)

## Section 5.1.2

Please add some references to the MADINAS WG current work items. The authors may also consider adding this use case to the MADINAS use case.

"The pseudonym of a MAC address affects an IPv6 address based on the MAC address", nearly no implementations use EUI-64 anymore so this part should probably be removed from the document. But, the change of MAC address probably has other impact on the IP stack, e.g., the neighbour cache.

## Section 5.1.3

AFAIK, RPL relies on messages to discover the topology and I am afraid that in such a moving / dynamic environment, there will be too many of RPL messages. Will RPL scale in this ever changing network ? Please note that I am not a RPL expert.

## Section 6.1

Some explanations on how SEND protects against DAD flooding would be welcome.

Is "classical IPv6 ND" the same as the previously used "legacy ND" ?

Wondering why "Vehicle Identification Number (VIN)" is suggested to be used as SubjectAltName in a certificate rather than a car manufacturer cert ?

## Section 6.3

The part about bitcoin and blockchain errs probably too far away from the IETF remit.

## Appendix B

I fail to understand how RPL and OMNI can be compared as they are vastly different technologies (routing vs. tunneling).

"In OMNI protocol, each wireless media interface is configured with an IPv6 Unique Local Address (ULA)" but from my last read of OMNI drafts (1+ year ago), the OMNI virtual interface can have a ULA indeed but the wireless physical ones are using any prefix.

## Appendix D

What will be the impact of high packet loss rate (that I am expecting on such networks) on IP parcels ?

# NITS 

Please check that all IPv6 addresses are in lowercase (e.g., in section 4.1).

[Ballot comment]
First off, this is really interesting stuff.  Thanks for putting it together, and I'm looking forward to reading more.

I support Roman's and Eric's DISCUSS positions.  I also concur with Alvaro's comments about references.

The shepherd writeup doesn't say why "Informational" is the right type of RFC here.  (It becomes obvious quickly, but please still answer the question.  We often go to the writeup first.)

Section 2 defines "Class-Based Safety Plan", "V2I2D", "VMM", "VND", and "VSP", but then those terms don't appear anywhere in the document.  (I did find "class-based automatic safety action plan" later.)  It also defines "OCB" and "VIP", but then only really uses them as part of reference anchors.  On the flipside, I would love to see a definition (or reference) for "UAM".

[Ballot comment]
I'm not an expect on these areas of technology, but I find parts of this document to be quite uncompelling.  However, it is an informational document, where considerable latitude is allowed.

Although I'm happy for the authors to correct my misunderstandings below, if they wish, I'm doubtful that such a discussion will really be helpful, hence my abstain ballot.

Some of my concerns when reviewing this document:

(1) It feels like quite a lot of these problems are (or could be) solved today using the existing wireless networks and GPS already included in cars.  E.g., presumably they are already making use of IP over 4G-LTE without needing these proposed protocol changes?  I.e., how many of the problems described here can really be most efficiently solved by having a local dynamic network?

(2) Having some sort of bitcoin/blockchain based micropayment scheme for sharing sensor data between vehicles feels highly implausible to me, given that the world hasn't seemed to manage a micropayment scheme for websites which seems like an easier problem to solve.

(3) Would vehicles even be able to safely trust sensor data coming from other vehicles?  E.g., hacked vehicles that randomly occasionally inject false sensor readings.  Who would have legal liability if your vehicle takes some action based on unreliable 3rd party sensor data?  I appreciate that it outside this type of technical document, but I think that it limits the likely hood of solving this in an ad hoc network.

(4) I struggle to understand how the V2X use cases really work.  In a street (at least in the UK) there would often be people in very close proximity to a vehicle (e.g., walking on the pavement [sidewalk] next to a vehicle, and presumably it is only people in front of the vehicle that are potential collision problems, and for these cases, are radar/lidar/cameras/sensors not a more robust choice (and are already deployed today, and seemingly improving every year).  I would think that the only way that this could work with a smartphone is if it sharing very precise (0.1 m) location data all the time to everything around it, which would probably degrade the battery and would also seem to have some serious privacy considerations.

(5) In Appendix D, I don't understand how the AERO/OMNI service solves the MTU problem.  It seems to be just introducing another layer to solve exactly the problem that are already solved by existing transport layer protocols.  If there is some data illustrating how TCP over OAL (with IP parcels) is more efficient that straight TCP over IP then that would be worth sharing.

Regards,
Rob

[Ballot comment]
First off, this is really interesting stuff.  Thanks for putting it together, and I'm looking forward to reading more.

I support Roman's and Eric's DISCUSS positions.  I also concur with Alvaro's comments about references.

The shepherd writeup doesn't say why "Informational" is the right type of RFC here.  (It becomes obvious quickly, but please still answer the question.  We often go to the writeup first.)

Section 2 defines "Class-Based Safety Plan", "V2I2D", "VMM", "VND", and "VSP", but then those terms don't appear anywhere in the document.  (I did find "class-based automatic safety action plan" later.)  It also defines "OCB" and "VIP', but then only really uses them as part of reference anchors.  On the flipside, I would love to see a definition (or reference) for "UAM".

[Ballot comment]
I concur with Ronan's DISCUSS concerns.

In addition, I have a few comments:

        To encourage more vehicles to participate in this cooperative
        environmental sensing, a reward system will be needed.

The reward system could be "you are allowed to sell your car and drive it here".
In other words, how things are encouraged seems very open, and not really limited
to a reward system. I'd strongly recommend removing blockchain/bitcoin references
as these are too speculative - if anything these reward systems seem to be headed
towards getting banned or restricted by governments.

I'm very nervous about adding pedestrians to vehicle networks. It will
be a big privacy concern, especially if these networks are commercially
run by for-profit companies as these days companies are very eager to
monetize their data. Furthermore, pedestrian gadgets (phones, tablets)
usually can only connect to one wifi network, so sacrificing this to V2X
might not be what they want when sitting near an intersection at the coffee
shop.

also think Bring-Your-Own- Prefix (BYOP)") does not avoid doing DAD, especially
if there might be malicious parties around.

  Note that it is dangerous if the
  internal network of a vehicle is controlled by a malicious party.  To
  minimize this kind of risk, an reinforced identification and
  verification protocol shall be implemented.

I don't see easy solutions here. No one wants to give control of their vehicle network
to another entity - even if identification/verification is "reinforced".

  For doing so, we shall have an
  efficient zero-trust framework or mechanism for vehicular networks.

There is a lot of heavy lifting done by this one sentence. Especially when it is
also being combined with blockchain/bitcoin solutions. All of these mechanisms
seem many orders of magnitude slower than for an attaker to pretend to be a new
and different vehicle.

[Ballot comment]
Thank you for the work on this document

Many thanks to Jim Fenton for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/8JP36SKQXl7jNXXdWEbcXng5bD0/, and to
the authors for addressing it.

Francesca

[Ballot comment]
Thanks for working on this informational document.

I found this document a good read from the vehicular connectivity and networking point of view, however, there are some cases where the descriptions are not clear to convey the message and required ask.  Specially in section 4 and section 6. I think Roman already have covered most of those. Hence supporting his discuss points regarding  those sections.

I also have following observation/comments which I believe if addressed will improve the document-

* Abstract: I actually didn't find enumerated requirements form the problem statements that obviously. Hence, I would suggest to remove this part ("then enumerates requirements for the extensions of those IPv6 protocols for IPv6-based vehicular networking") from the abstract. Lets stick to what the title says.  Otherwise, I would expect a numbered list of requirements that the wg would like to refer to and fulfill in future works.

* Please add V2P (and X2P) definitions like others in the terminology section.

* Section 3.1: it says -

    "To encourage more vehicles to participate in this cooperative environmental sensing, a reward system will be needed. Sensing activities of each vehicle need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) through other vehicles or infrastructure. In the case of a blockchain, each sensing message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin][Vehicular-BlockChain]."

  This seems like a misfit to the use case section and felt more like belongs to some sort of requirement for a reward system. I would suggest to just remove this paragraph.

* Section 5: it says -

    "Since the vehicles are likely to be moving at great speed, protocol exchanges need to be completed in a relatively short time compared to the lifetime of a link between a vehicle and an IP-RSU, or between two vehicles"

  While it is true that vehicles can move with "great speed", it is also true that the relative speeds between vehicles might not be that "great", e.g. platooning case. And when vehicles passes each other or a IP-RSU really fast there might not be enough time to setup the link layer connection and V2I communication becomes more important. I found the quoted section of problem statement to be ignorant of these facts and missing the potential relation among V2V, V2I and V2X connectivity and communication.

*  I would note that, fro, the use case and problem statement, tranport-layer session mobility and usage of available bandwidth mentioned in the document. However, those are not discussed with details but I understand would play vital role to support the discussed application use cases and architecture. I assume this might be due to  the scope of the document but this document should say something about those aspect, at least mention as potential future work that need to fulfill the envisioned use cases.

[Ballot comment]
Thanks for working on this informational document.

I found this document a good read from the vehicular connectivity and networking point of view, however, there are some case it was not clear in the message and required ask.  Specially in section 4 and section 6. I think Roman already have covered most of those. Hence supporting his discuss points regarding  those sections.

I also have following observation/comments which I believe if address will improve the document-

* Abstract: I actually didn't find enumerated requirements form the problem statements that obviously. Hence, I would suggest to remove this part ("then enumerates requirements for the extensions of those IPv6 protocols for IPv6-based vehicular networking") from the abstract. Lets stick to what the title says.  Otherwise, I would expect a numbered list of requirements that the wg would like to refer to and fulfill in future works.

* Please add V2P (and X2P) definitions like others in the terminology section.

* Section 3.1: it says -

    "To encourage more vehicles to participate in this cooperative environmental sensing, a reward system will be needed. Sensing activities of each vehicle need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) through other vehicles or infrastructure. In the case of a blockchain, each sensing message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin][Vehicular-BlockChain]."

  This seems like a misfit to the use case section and felt more like belongs to some sort of requirement for a reward system. I would suggest to just remove this paragraph.

* Section 5: it says -

    "Since the vehicles are likely to be moving at great speed, protocol exchanges need to be completed in a relatively short time compared to the lifetime of a link between a vehicle and an IP-RSU, or between two vehicles"

  While it is true that vehicles can move with "great speed", it is also true that the relative speeds between vehicles might not that "great". And when vehicles passes each other or a IP-RSU really fast there might not be enough time to setup the link layer connection and V2I communication becomes more important. I found the quoted section of problem statement to be ignorant of this fact and over missing the potential relation among V2V, V2I and V2X connectivity and communication.

*  I would note that from, the use case and problem statement, tranport-layer session mobility is mentioned, also  usage of available bandwidth mentioned in the document. However, those are not discussed with details but I understand would play vital role to support the discussed application use cases and architecture. I assume this might be because of the scope of the document but this document should say something about those aspect, at least mention as potential future work,.

[Ballot comment]

I support Roman's and Eric's DISCUSS positions.  I, too, found the line between examples and gaps/requirements to be blurry, at best.


This document lists more than 40 Normative references!  Most (all?) of them point at examples of potential technology or are there as background.  For example, the first few point at MLD/MLDv2, OLSR, NEMO, and a couple of documents about terminology and documentation -- all clearly informative.

This is how the IESG Statement on Normative and Informative References [1] characterizes them:

  Within an RFC, references to other documents fall into two general
  categories: "normative" and "informative". Normative references specify
  documents that must be read to understand or implement the technology
  in the new RFC, or whose technology must be present for the technology
  in the new RFC to work. An informative reference is not normative;
  rather, it only provides additional information. For example, an
  informative reference might provide background or historical information.
  Informative references are not required to implement the technology in
  the RFC.

Please examine the references and classify them accordingly.



[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

[Ballot discuss]
Thank you for the work put into this document. I found the use cases part of section 3.1 very interesting to read even if some of them seem very far fetched ;-)

Please find below some blocking DISCUSS points (easy to address though), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to

- Carlos Bernardos for the shepherd's write-up even if a justification for the informational status would have been welcome but the WG consensus description is appreciated.

- Pascal Thubert for his IETF last call INT directorate review at: https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-20-intdir-lc-thubert-2021-06-18/ and for his IESG telechat INT directorate review https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28/ Pascal's Last Call & telechat reviews were (at least partially) acted upon by Paul ;-)

I hope that this helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Abstract & Section 1

"then enumerates requirements for the extensions of those IPv6 protocols" does not match any IPWAVE WG work item, i.e., it is outside the scope of the charter of IPWAVE WG. As the document does not explicitly specify requirements, I strongly suggest to use the word "gaps" rather than "requirements" in the abstract and section 1.

## Section 4.1

Using an IPv6 address out of a ULA prefix still requires DAD. So the text below should be updated to be corrected:
  "their own IPv6 Unique Local Addresses
  (ULAs) [RFC4193] over the wireless network, which does not require
  the messaging (e.g., Duplicate Address Detection (DAD)) of IPv6
  Stateless Address Autoconfiguration (SLAAC) [RFC4862]."

## Section 4.2

Very similar comment as above (i.e., DAD & MLD must be done for all IPv6 addresses of an interface and not only for the global one):
  "... When global IPv6
  addresses are used, wireless interface configuration and control
  overhead for DAD"

## Section 5.2
  "... If DHCPv6 is used to assign
  a unique IPv6 address to each vehicle in this shared link, DAD is not
  required. "
This is incorrect and must be changed (see section 18.2.10.1. of RFC 8415)

[Ballot comment]

# COMMENTS

"100km/h as the speed limit in highway" will make many European drivers smile as it is really slow...

## Section 1

"Most countries and regions in the world have adopted the same frequency allocation for vehicular networks." but there are TWO frequency allocations described just before, so, which one has been adopted ?

## Section 2

"GPS" is just the USA commercial example of the more generic "global navigation satellite system" (GNSS), GNSS should be used in this document.

As IP-RSU have at least 2 interfaces, should "Also, it may have *the* third IP-enabled wireless interface" be replaced by "Also, it may have *a* third IP-enabled wireless interface" ?

LiDAR ... "by measuring the reflected pulsed light" but on which kind of metrics ?

## Section 3.1

Should the 1st and 5th bullets be grouped together ?

Please describe "UAM" (e.g., in the terminology section) as it is unclear to the reader whether it is a crewed / uncrewed aircraft.

If both road and air vehicles are use case, what about river / sea ships or trains ?

Does the paragraph about "reward system" belong to the use case ? It rather sounds like a business requirement. Suggest to remove this part.

Like written by Pascal Thubert in his telechat review, the last paragraph "IPv6-based packet exchange and secure" should be clear that this is not only about data plane traffic but also control plane L2/L3 ones. Please also use the Oxford comma, i.e., add a "," after "exchange".

## Section 3.2

Suggest to also mention "5G" after "IP-RSU or 4G-LTE networks"

How is the UAM use case different from a driverless terrestrial EV ? Suggest to merge those use cases.

## Section 4.1

As noted by other ADs, "Existing network architectures," the list should not include OMNI yet as it is not deployed and would probably not be described as an architecture.

"the wireless media interfaces are autoconfigured with a global IPv6 prefix", is it the same shared prefix or multiple prefixes ?

Is "RSU" the same concept as "IP-RSU" ?

The last paragraph is about TCP session continuity, but does not explain why multi-path TCP or QUIC session resumption cannot be used.

## Section 4.2

The computation about "dwell time" is interesting even if it is computed in the best case. But, I really wonder whether using IPv6 and routing are applicable to the use case as opposed to more layer-2 + tunnel solutions (like 3GPP) with such short time for hand-over. I am a strong supporter of layer-3 (IPv6 and routing), but I cannot refrain from thinking that IPv6 is the wrong technical solution for those use cases... Was this discussed in the WG ?

## Section 5.1

What is "legacy DAD" ?

  "...the NA interval needs to be
  dynamically adjusted according to a vehicle's speed so that the
  vehicle can maintain its neighboring vehicles in a stable way"
With the issues linked to multicast over wireless, are the authors and the WG sure that increasing the amount of multicast will not aggravate the problem ? See RFC 9119 (cited as a normative down reference)

## Section 5.1.2

Please add some references to the MADINAS WG current work items. The authors may also consider adding this use case to the MADINAS use case.

"The pseudonym of a MAC address affects an IPv6 address based on the MAC address", nearly no implementations use EUI-64 anymore so this part should probably be removed from the document. But, the change of MAC address probably has other impact on the IP stack, e.g., the neighbour cache.

## Section 5.1.3

AFAIK, RPL relies on messages to discover the topology and I am afraid that in such a moving / dynamic environment, there will be too many of RPL messages. Will RPL scale in this ever changing network ? Please note that I am not a RPL expert.

## Section 6.1

Some explanations on how SEND protects against DAD flooding would be welcome.

Is "classical IPv6 ND" the same as the previously used "legacy ND" ?

Wondering why "Vehicle Identification Number (VIN)" is suggested to be used as SubjectAltName in a certificate rather than a car manufacturer cert ?

## Section 6.3

The part about bitcoin and blockchain errs probably too far away from the IETF remit.

## Appendix B

I fail to understand how RPL and OMNI can be compared as they are vastly different technologies (routing vs. tunneling).

"In OMNI protocol, each wireless media interface is configured with an IPv6 Unique Local Address (ULA)" but from my last read of OMNI drafts (1+ year ago), the OMNI virtual interface can have a ULA indeed but the wireless physical ones are using any prefix.

## Appendix D

What will be the impact of high packet loss rate (that I am expecting on such networks) on IP parcels ?

# NITS 

Please check that all IPv6 addresses are in lowercase (e.g., in section 4.1).

[Ballot discuss]
I had difficulty in understanding the bounds for the scope of the use cases and proposed architecture.  At times I had trouble understanding what was an example of related work, and what was narrative formally describing the gaps in IPv6 for vehicular networking.  In that spirit:

** The Privacy Considerations are under-specified:

-- Section 6.3 suggests the needs for logging, “To deal with this kind of security issue, for monitoring suspicious behaviors, vehicles' communication activities can be recorded in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) along with other vehicles or infrastructure.  To solve the issue ultimately, we need a solution where, without    privacy breakage, …”.  Some discussion on the “privacy breakage” is needed.  What exactly would be the trade offs between a centralized vs. distributed log?  Who would get to see this information?  What is sensitive about this information?

-- Section 5.1.2 and 6.3 highlights the use of MAC address pseudonyms.  This is helpful.  More discussion is needed about the associate privacy threat being mitigated.  Section 6.3 mentions an “adversary from tracking a vehicle” which I think means a passive observer of the path.  However, there are other entities in which ecosystem – what is the privacy exposure to the TCC, V2I, etc?  The opening in Section 6 notes that “vehicles and infrastructure must be authenticated” and those credentials (perhaps bound to even MAC pseudonyms) would also facilitate tracking even given MAC pseudonyms.  Section 6.1 explicit comments on using VINs in certificates.  Who are the assumed trusted actors?

-- Section 3.3 notes a V2P use case where the pedestrian’s smart-phone is sharing unspecified information.  Does that include location information?  Who gets it?  What kind of identifiers are shared?

** Section 4.2

  Note that it is dangerous if the
  internal network of a vehicle is controlled by a malicious party.  To
  minimize this kind of risk, an reinforced identification and
  verification protocol shall be implemented.

-- What are these dangers?

-- What is a ‘reinforced identification’?

-- Who are the parties in this verification protocol?  What security properties is this verification providing?

** Section 6.
  Vehicles and infrastructure must be authenticated in order to
  participate in vehicular networking. 

Authenticated with respect to whom? Vehicles to infrastructure and vice-versa?  Or to someone else?

** Section 6 makes references to “secure communication” – what is the expected key management approach and is that in scope?

** The need for safety properties (very helpful) is asserted multiple times but not further discussed in the Security Considerations:

-- Section 3: 
      In addition, IPv6
      security needs to be extended to support those V2V use cases in a
      safe, secure, privacy-preserving way.

-- Section 3.1:
      To support applications of these V2V use cases, the required
    functions of IPv6 include IPv6-based packet exchange and secure,   
    safe communication between two vehicles. 

-- Section 3.3:
  To support applications of these V2X use cases, the required
  functions of IPv6 include IPv6-based packet exchange, transport-layer
  session continuity, and secure, safe communication between a vehicle
  and a pedestrian either directly or indirectly via an IP-RSU.

[Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

** Section 1.  Editorial
  Vehicular networking studies have mainly focused on improving safety
  and efficiency, and also enabling entertainment in vehicular
  networks. 

This first sentence is unrelated to the reset of the paragraph which is focused on spectrum allocation.

** Section 1.

  Most countries and regions in
  the world have adopted the same frequency allocation for vehicular
  networks.

This statement seems incongruent with the previous two sentences which describe how the US and EU have allocated very similar but not “same” spectrum (5.850 – 5.925 vs. 5.875 vs. 5.905).

** Section 2.  Edge Computing is defined but doesn’t seem to be used in the rest of the document beyond in ECD.  Is it needed?

** Section 2.

IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a
      computer situated in a vehicle

Is this “computer” the same as an ECD defined earlier in the section?

** Section 3.1.  Editorial.

  These five techniques will be important elements for autonomous
  vehicles, which may be either terrestrial vehicles or UAM end
  systems.

This sentence seems to suggest that all give techniques are relevant to both terrestrial and UAMs.  As far as I can tell, the first three (1 – 3) are terrestrial related, the fourth is relevant to both terrestrial and UAM, and the fifth is UAM only.

** Section 3.1

  To encourage more vehicles to participate in this cooperative
  environmental sensing, a reward system will be needed.  Sensing
  activities of each vehicle need to be logged in either a central way
  through a logging server (e.g., TCC) in the vehicular cloud or a
  distributed way (e.g., blockchain [Bitcoin]) through other vehicles
  or infrastructure.  In the case of a blockchain, each sensing message
  from a vehicle can be treated as a transaction and the neighboring
  vehicles can play the role of peers in a consensus method of a
  blockchain [Bitcoin][Vehicular-BlockChain].

I’m struggling to link this proposed solution to stated uses case or gap-analysis for IPv6.  Can the IPv6 enablers be described.

** Section 3.2.  Typo?  s/air firmware/over-the-air firmware/.  If not a typo, what is an “air firmware/software update”?

** Section 3.2. Editorial?
  For this battery charging schedule, a UAM
  end system can communicate with an infrastructure node (e.g., IP-RSU)
  toward a cloud server via V2I communications.

Is there is a missing word here.  What does it mean to “... communicate with an infrastructure node … toward a cloud server”

** Section 4.2

  It is reasonable to consider the
  interaction between the internal network and an external network
  within another vehicle or an EN. 

Can the intent of this be clarified?  Isn’t something on the internal vehicle network talking to another vehicle the definition of V2V per Section 3.1?

** Section 4.2.  Is there any expectation of any perimeter-based policy enforcement between this internal network and the edge network (e.g., firewall?).

** Section 4.3.  Is there implicit trust between the platooning vehicles?  Security impact if one becomes untrusted?

** Section 5.
  For safe driving, vehicles need to exchange application messages
  every 0.5 second [NHTSA-ACAS-Report] to let drivers take an action to
  avoid a dangerous situation (e.g., vehicle collision), so IPv6
  protocol exchanges  need to support this order of magnitude for
  application message exchanges. 

This is a helpful performance envelope.  Can this be more tightly linked to IPv6?  It seems like this kind of performance is related to the capabilities of the link layer to move the IPv6 packets fast enough.

** Section 5.1.1
  For instance, some IPv6 protocols assume symmetry in the connectivity
  among neighboring interfaces [RFC6250]. 

RFC6250 (Section 3.1.1) seems to be saying the opposite of this sentence which is that symmetry can’t be assumed.  What protocols are making this assumption?

** Section 5.1.2

  However, the pseudonym handling is not
  implemented and tested yet for applications on IP-based vehicular
  networking.

No issues.  However, isn’t this true for all of the VIP and VND work (as in, it needs more testing)?

** Section 6.

  For the authentication in
  vehicular networks, vehicular cloud needs to support a kind of Public
  Key Infrastructure (PKI) in an efficient way.

What does the qualifier of “a kind of” PKI mean?

** Section 6

  Also, in-vehicle devices (e.g.,
  ECU) and a driver/passenger's mobile devices (e.g., smartphone and
  tablet PC) in a vehicle need to communicate with other in-vehicle
  devices and another driver/passenger's mobile devices in another
  vehicle, or other servers behind an IP-RSU in a secure way.

Is securing arbitrary communication between a smartphone-A in vehicle-1 and smartphone-B in vehicle-2 in scope?

** Section 6.
  Even
  though a vehicle is perfectly authenticated and legitimate,

What does it mean for a vehicle to be legitimate?  Authenticated to whom?

** Section 6
  Note that when driver/passenger's mobile devices are
  connected to a vehicle's internal network, the vehicle may be more
  vulnerable to possible attacks from external networks.

This doesn’t seem framed right.  Why is it _more vulnerable_?  More relative to what?  I think the central idea is that like any network (e.g., public library, IETF conference network), the end-node assumes risk of its packets transiting a network it doesn’t control, and exposes itself to “local network/segment” attacks of any peer nodes on the network.

** Section 6.3
  Alternatively, for
  completely secure vehicular networks, we shall embrace the concept of
  "zero-trust" for vehicles in which no vehicle is trustable and
  verifying every message is necessary.  For doing so, we shall have an
  efficient zero-trust framework or mechanism for vehicular networks.

-- What is a “completely secure vehicular network”?

-- There seems to be an architecture mismatch in this aspirational zero trust architecture.  How does the premise of “verifying every message” align with focus of this document being IPv6 protocol mechanisms.  What is an “IPv6 message”?  Is that a packet?  It would seem to me that these messages would be application layer matters.

** Section 6.3

Each message from a
  vehicle can be treated as a transaction and the neighboring vehicles
  can play the role of peers in a consensus method of a blockchain
  [Bitcoin] [Vehicular-BlockChain].

Same comment as for ZT -- what is an “IPv6 message” that could be put on a blockchain?

** Section 6.3

  For the non-repudiation of the harmful activities of malicious nodes,
  a blockchain technology can be used [Bitcoin].  Each message from a
  vehicle can be treated as a transaction and the neighboring vehicles
  can play the role of peers in a consensus method of a blockchain
  [Bitcoin] [Vehicular-BlockChain].  For a blockchain's efficient
  consensus in vehicular networks having fast moving vehicles, a new
  consensus algorithm needs to be developed or an existing consensus
  algorithm needs to be enhanced.

Given the architecture layout in Figures 1 – 5?  Where does this block live?  Who checks it?  Under what circumstances?  It isn’t clear how this architectural construct is linked a gap analysis of IPv6 for vehicular networking.

[Ballot comment]
Section 1. , paragraph 5, comment:
>    Along with these WAVE standards and C-V2X standards, regardless of a
>    wireless access technology under the IP stack of a vehicle, vehicular
>    networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6
>    protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6)
>    [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network
>    Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP)
>    [I-D.ietf-lisp-rfc6830bis], and Automatic Extended Route Optimization
>    based on the Overlay Multilink Network Interface (AERO/OMNI)
>    [I-D.templin-6man-aero] [I-D.templin-6man-omni]).  In addition, ISO
>    has approved a standard specifying the IPv6 network protocols and
>    services to be used for Communications Access for Land Mobiles (CALM)
>    [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1].

Isn't it a bit premature to list AERO and OMNI alongside a number of published
standards from the IETF and other organizations? As far as I know they are
individual documents that have not been adopted? (Here and elsewhere in the
document.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "invalid"; alternatives might be "not valid", "unenforceable", "not
  binding", "inoperative", "illegitimate", "incorrect", "improper",
  "unacceptable", "inapplicable", "revoked", "rescinded".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5.2. , paragraph 7, nit:
-    home.  There is nonnegligible control overhead to set up and maintain
+    home.  There is non-negligible control overhead to set up and maintain
+                      +

Section 1. , paragraph 3, nit:
> 9.4 [WAVE-1609.4] specifies the multi-channel operation. IEEE 802.11p was fi
>                                ^^^^^^^^^^^^^
This word is normally spelled as one.

Section 4.1. , paragraph 7, nit:
> arty. To minimize this kind of risk, an reinforced identification and verific
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 4.3. , paragraph 17, nit:
> livered to relevant vehicles in an efficient way (e.g., multicasting). With
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 4.3. , paragraph 17, nit:
> layers (e.g., IPv6, TCP, and UDP). Hence the bandwidth selection according t
>                                    ^^^^^
A comma may be missing after the conjunctive/linking adverb "Hence".

Section 5.1.1. , paragraph 4, nit:
> y with standard IPv6 links in an efficient fashion to support IPv6 DAD, MLD a
>                            ^^^^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.1.2. , paragraph 2, nit:
> ergy constraints, RPL does not suggest to use a proactive mechanism (e.g., k
>                                ^^^^^^^^^^^^^^
The verb "suggest" is used with the gerund form.

Section 5.2. , paragraph 4, nit:
> lic Key Infrastructure (PKI) in an efficient way. To provide safe interactio
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.2. , paragraph 5, nit:
> other servers behind an IP-RSU in a secure way. Even though a vehicle is per
>                                ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.2. , paragraph 8, nit:
> eceived ND message, which requires to use the CGA ND option in the ND protoc
>                                    ^^^^^^
Did you mean "using"? Or maybe you should add a pronoun? In active voice,
"require" + "to" takes an object, usually a pronoun.

Section 6. , paragraph 3, nit:
>  taking a safe maneuver. Since cyber security issues in vehicular networks ma
>                                ^^^^^^^^^^^^^^
The word "cybersecurity" is spelled as one.

Section 6.1. , paragraph 4, nit:
> ensus algorithm needs to be developed or an existing consensus algorithm need
>                                      ^^^
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

Section 8.2. , paragraph 7, nit:
>  Device-free human counting through WiFi fine-grained subcarrier information
>                                    ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 8.2. , paragraph 23, nit:
> unction (called OF), which allows to adapt the activity of the routing proto
>                                  ^^^^^^^^
Did you mean "adapting"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

"Appendix B. ", paragraph 5, nit:
> ST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France, Phone: +33169089
>                                ^^^^^^^^^^^^^
"Ile-de-France" is an imported foreign expression, which originally has a
diacritic. Consider using "Île-de-France".

Uncited references: [RFC3849].

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ipwave-vehicular-networking-20, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-28):

From: The IESG
To: IETF-Announce
CC: Carlos Bernardos , cjbc@it.uc3m.es, draft-ietf-ipwave-vehicular-networking@ietf.org, ek.ietf@gmail.com, ipwave-chairs@ietf.org, its@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases) to Informational RFC


The IESG has received a request from the IP Wireless Access in Vehicular
Environments WG (ipwave) to consider the following document: - 'IPv6 Wireless
Access in Vehicular Environments (IPWAVE): Problem
  Statement and Use Cases'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document discusses the problem statement and use cases of
  IPv6-based vehicular networking for Intelligent Transportation
  Systems (ITS).  The main scenarios of vehicular communications are
  vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
  vehicle-to-everything (V2X) communications.  First, this document
  explains use cases using V2V, V2I, and V2X networking.  Next, for
  IPv6-based vehicular networks, it makes a gap analysis of current
  IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
  and Security & Privacy), and then enumerates requirements for the
  extensions of those IPv6 protocols for IPv6-based vehicular
  networking.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/



No IPR declarations have been submitted directly on this I-D.

[ abstract, section 1 ]

* "lists up" -> "enumerates|sets forth|details|...", might be a better
  word/verb phrase


[ section 2 ]

* "table PC"? Perhaps "tablet PC", like in section 6.

[ section 3 ]

* There are two sentences in the final paragraph which both direct the reader
  to section 5 for vehicular IPv6 problem statement and requirements.
  Probably only one of those sentences is really required.

[ section 3.2 ]

* "can facilitates" -> "can facilitate"

* "can make the battery charging schedule" is technically correct, but the
  multiple possible interpretations of "make" in this context tripped me up
  looking for some final (indirect) object or something.

  Suggest something like "can plan the battery charging schedule", perhaps?

* "The existing IPv6 protocol must be augmented ..."

  Should there be some explanation about why this needs to be done at the IPv6
  layer and, more explicitly, why a Layer 2 solution is not an option that
  can also be considered?  I can understand that L2 options are out of scope
  for the IETF to work on, but are they also out of scope overall?  I could
  believe that the reason is RFC 4903 -style issues, but I figured I'd ask.

[ section 4.1 ]

* "...vehicles under the coverage of an RSU share a prefix such
  that mobile nodes share a prefix..."

  Perhaps s/such that/(just as)|(in the same way that)/?

[ section 4.2/5(.0) ]

* The final paragraph of 4.2 hints at this, but I found myself wanting to read
  about the expected "dwell times" for a vehicle connected to an IP-RSU.
  For how long is a vehicle expected to be connected to any given access node?
  I think the maximum is probably uninteresting (the vehicle could be parked,
  for example), but what is the useful minimum time?

  (I see that section 5.1.2 goes include a helpful timescale reference.)

[ section 5.1.1/5.2 ]

* During handover, can a vehicle be connected to multiple IP-RSUs on the
  logical interface?  If so, does this mean they need to use RFC 8028 -style
  address and next hop selection?

[ section 6 ]

* How can a vehicle authenticate other vehicles (and their ND information)
  and the RAs coming from IP-RSUs?

  Ah, I guess this is what the final two paragraphs are saying, actually, that
  there needs to be such a mechanism.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.  Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  It is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

    The document introduces different use cases of interest for
    IPv6-based vehicular networking for Intelligent Transportation
    Systems (ITS).  Then, it describes an example vehicular network
    architecture supporting V2V, V2I, and V2X communications as a
    baseline for further discussion about current IPv6 protocols with
    respect to IPv6 neighbor discovery, mobility management, security,
    and privacy.  Finally, some requirements for future work are offered.

  Working Group Summary:

    Initially, the IPWAVE WG was chartered to work on documents:
    one informational document explaining the state of the art in the
    field and describe the use cases for IPv6, and another
    informational document describing the problem statement, including
    associated security and privacy considerations.  The charter
    indicated that the working group would decide at a future point
    whether these informational documents needed to be published
    separately as RFCs or if they could be combined.  It was decided at
    the beginning of the process to combine them, without any
    controversy.

    The document has required a lot of time to progress, due to the low
    energy level of the IPWAVE WG.

  Document Quality:

    The document is informational, and therefore does not include any
    protocol specification, so no implementations exist.  The document
    went through many iterations, as it originally had an academic
    flavor, and did not properly serve its purpose of identifying key
    gaps that require protocol development.  This has been improved in
    the last revisions.  Overall, the document has a good quality.

    The document has been reviewed in several occasions (more than 10) by
    several IPWAVE WG participants and external reviewers recruited by
    the WG chairs and the document editor.  None of the reviewers has
    expressed concerns with latest version of the Internet-Draft.

Personnel:

    Carlos J. Bernardos is the Document Shepherd.
    Erik Kline is the responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The Document Shepherd has reviewed this document in multiple occasions,
  even before it was adopted by the IPWAVE WG.  During the process,
  different recommendations were provided, especially aimed at making the
  document more concise and less "academic".  After this long process,
  the document is now ready to be forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No, not really.  As part of the publication process, I understand that
  a SecDir review will take place, which might be further improve the
  security-related content of the document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No critical concerns.  I feel that with more energy at the IPWAVE WG,
  we could have come up with a baseline document to take on further work.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  Yes.

(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR has been filed.

(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  Strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  idnits reflects just one comment, regarding an unexpected draft version,
  which is actually correct in the document.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A.

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  The document has no normative references.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  N/A.

(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

  The document does not require any IANA action, and this is reflected
  in the IANA considerations section.

(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  N/A.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation?  If there are any resulting errors or warnings,
what is the justification for not fixing them at this time?  Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

  N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.  Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  It is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

    The document introduces different use cases of interest for
    IPv6-based vehicular networking for Intelligent Transportation
    Systems (ITS).  Then, it describes an example vehicular network
    architecture supporting V2V, V2I, and V2X communications as a
    baseline for further discussion about current IPv6 protocols with
    respect to IPv6 neighbor discovery, mobility management, security,
    and privacy.  Finally, some requirements for future work are offered.

  Working Group Summary:

    Initially, the IPWAVE WG was chartered to work on documents:
    one informational document explaining the state of the art in the
    field and describe the use cases for IPv6, and another
    informational document describing the problem statement, including
    associated security and privacy considerations.  The charter
    indicated that the working group would decide at a future point
    whether these informational documents needed to be published
    separately as RFCs or if they could be combined.  It was decided at
    the beginning of the process to combine them, without any
    controversy.

    The document has required a lot of time to progress, due to the low
    energy level of the IPWAVE WG.

  Document Quality:

    The document is informational, and therefore does not include any
    protocol specification, so no implementations exist.  The document
    went through many iterations, as it originally had an academic
    flavor, and did not properly serve its purpose of identifying key
    gaps that require protocol development.  This has been improved in
    the last revisions.  Overall, the document has a good quality.

    The document has been reviewed in several occasions (more than 10) by
    several IPWAVE WG participants and external reviewers recruited by
    the WG chairs and the document editor.  None of the reviewers has
    expressed concerns with latest version of the Internet-Draft.

Personnel:

    Carlos J. Bernardos is the Document Shepherd.
    Erik Kline is the responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The Document Shepherd has reviewed this document in multiple occasions,
  even before it was adopted by the IPWAVE WG.  During the process,
  different recommendations were provided, especially aimed at making the
  document more concise and less "academic".  After this long process,
  the document is now ready to be forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No, not really.  As part of the publication process, I understand that
  a SecDir review will take place, which might be further improve the
  security-related content of the document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No critical concerns.  I feel that with more energy at the IPWAVE WG,
  we could have come up with a baseline document to take on further work.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  Yes.

(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR has been filed.

(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  Strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  idnits reflects just one comment, regarding an unexpected draft version,
  which is actually correct in the document.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A.

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  The document has no normative references.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  N/A.

(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

  The document does not require any IANA action, and this is reflected
  in the IANA considerations section.

(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  N/A.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation?  If there are any resulting errors or warnings,
what is the justification for not fixing them at this time?  Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

  N/A.