Re: Last Call: <draft-ietf-ipwave-vehicular-networking-20.txt> (IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases) to Informational RFC

Brian E Carpenter <> Tue, 15 June 2021 03:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 118713A1C60; Mon, 14 Jun 2021 20:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zCw9zrBTvH_5; Mon, 14 Jun 2021 20:25:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A463B3A1C5D; Mon, 14 Jun 2021 20:25:16 -0700 (PDT)
Received: by with SMTP id c12so12201642pfl.3; Mon, 14 Jun 2021 20:25:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v/GNOPQI98A/hw7ZMLrpFbf9v5gvlrcall7Mml/WC6I=; b=klvQHFYgj6gWgJBw4wiMSBzWsWSnxXuDrLu9cmUwXQWOi6Pua1wjs2PPLOtn7yHxzp O90Qkqljqll5J5GwgO+GiuggIA8YDmiUJIrT1lTLeLJ5dvQZkAiRUq2IoD7g5Rdm4TbU tesFyZKufxEjnPoRbDy1tT1VdweVCAk6Semry1WDCPlXeV1MMpMwICyHlWTDC8B+jixY NtFqgMNa/PcuEbSoYFISzSmZU7gJrdXSZiqcDKTqH62+YpE9KBIUxYYwXshBhAPS1HcJ hUNQDfi89jx0tAVQHsvxE5b0/A2dG2ANcejHbe3QkSgvMgcC3+W2aYpor+3aWgPonQju r6bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v/GNOPQI98A/hw7ZMLrpFbf9v5gvlrcall7Mml/WC6I=; b=IpheNPH0us79/JCyNEMN/8eQtOSUSmk99WRTExbWoXPbFfyyDQ7O6a3KJx/L9s9MWv wiOJb4evsfKCVUMSZ0rOhBH4e023iHo+b3Hg3puKAuS8cjQo06/Krfyb8pTRLPmXXkYw 0rJ1SQ825a3FZPx+vGXh2spz2q4v6dUV/Gl/vt02ti9yWhlsVRDhD3X7Zk2X8Fyqjwo8 0+XqPgZQZ/sRECfTefJYhmeztbEzF5iqT3gzP1YE9iWKiLAgrJmmX2dFdgc5clAwZexa n7SlpwaP6ch8xZJX+zYI9TxCSlnnmQ2OIqtkPhxywwWkXn/3/M4oyHL7GQqbn/z5WiPg XELQ==
X-Gm-Message-State: AOAM5335iRlN64yC4kEmcGc3trT7MFnffn0IIED9lHiyyga5HDAsQKr7 kxkFSrnNEpmDF/KPMpOkV0K35SzKENvKMg==
X-Google-Smtp-Source: ABdhPJwaJq8zHyJAraaFpGHjnTVOonr/iSKZ7sPSG1GO73f7IDo+enFITYUVxoMy2FstZ6OtuG0gOA==
X-Received: by 2002:aa7:998f:0:b029:2ec:9844:a549 with SMTP id k15-20020aa7998f0000b02902ec9844a549mr2192233pfh.65.1623727514220; Mon, 14 Jun 2021 20:25:14 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by with ESMTPSA id w59sm13627305pjj.13.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jun 2021 20:25:13 -0700 (PDT)
Subject: Re: Last Call: <draft-ietf-ipwave-vehicular-networking-20.txt> (IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases) to Informational RFC
To: Erik Kline <>,
Cc: 6MAN <>,,, Carlos Bernardos <>, IETF-Announce <>,
References: <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 15 Jun 2021 15:25:07 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Jun 2021 03:25:22 -0000

Thanks for the heads-up, Erik.

This text at

>    Therefore, the existing IPv6 protocol can be
>    augmented through the addition of an Overlay Multilink Network (OMNI)
>    Interface [OMNI] and/or protocol changes in order to support both
>    wireless single-hop/multihop V2V communications and multiple radio
>    technologies in vehicular networks.

is of concern regardless of the mention of OMNI. Does it mean "can be" or "needs to be"? This paragraph seems like a very short summary of a big problem area. At the end of page 13 there is some related discussion, which mentions RPL as part of the solution (good choice, IMHO) but again seems to depend on OMNI. I don't think the fix of simply removing references to OMNI works, because it would leave a gap. In an informational document, that is not a formal problem but as far as this draft describes architecture, I don't think that big a gap is reasonable. "OMNI" is mentioned more than 20 times in the document. There are also several references to AERO, which is strongly associated with OMNI.

At this point I became confused about the purpose of the document. The Abstract says

>    This document discusses the problem statement and use cases of
>    IPv6-based vehicular networking

In fact, most of section 4 seems to be a draft architecture of a solution.

> 5.  Problem Statement
>    In order to specify protocols using the architecture mentioned in
>    Section 4.1, IPv6 core protocols have to be adapted to overcome
>    certain challenging aspects of vehicular networking.

That's a big leap. But the rest of section 5 seems to get back to solution design.

So I am left puzzled about what would happen next if this draft becomes an RFC. Do the authors expect 6man to work on the issues they've raised? I'm not sure they match 6man's limited charter ("not chartered to develop major changes or additions
to the IPv6 specifications").

   Brian Carpenter

On 15-Jun-21 13:07, Erik Kline wrote:
> +6man, since there are many statements about IPv6 work in this document.
> One thing of note: in the time after this document was WGLC'd, 6man
> held an adoption call on OMNI that did not result in adoption [OMNI].
> There are at two places where this text appears:
>    "The existing IPv6 protocol must be augmented through the addition of
>    an OMNI interface..."
> These statements should probably be revised (or removed).
> -Erik
> [OMNI]
> On Mon, Jun 14, 2021 at 7:02 AM The IESG <> wrote:
>> 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'
>>   <draft-ietf-ipwave-vehicular-networking-20.txt> 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
>> mailing lists by 2021-06-28. Exceptionally, comments may
>> be sent to 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
>> No IPR declarations have been submitted directly on this I-D.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------