Subject: [its] P1609.3 Networking Services and IPv6 Address Auto-Configuration

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Jun 2013 11:21:17 +0200

ITSsers,

Following the mentioning of IEEE P1609.3 'Networking Services'.  It is
good that we have a contact with IEEE about P1609 and I look
forward for closer collaboration.

To that end, let me mention technical aspects of IPv6 Address
Auto-Configuration.

The document IEEE P1609.3/D5.0 Draft Standard for Wireless Access in
Vehicular 3 Environments (WAVE) - Networking Services, March 2010,
describes among other things aspects related to IPv6 address
auto-configuration.

> For WAVE devices supporting dynamic IP addressing, the WME shall
> calculate the global IPv6 address 18 via a stateless configuration
> procedure. This is the procedure described in RFC 3513,

For more precision, instead of the Proposed Standard RFC3513 "IPv6
Addressing Architecture" one would rather mention the Draft Standard
RFC4291 of same title.  At IETF a Draft Standard status witnesses wider
adoption than Proposed Standard status.

Moreover, if the intent of the text is to refer to the procedure of
stateless address autoconfiguration then the more precise reference
would rather be RFC4862 "Stateless Address Autoconfiguration".

In addition, there is another tool for dynamic IP addressing: DHCPv6 in
RFC3315.

> except the WAVE device uses its MAC address in conjunction with the
> IpPrefix received in the WaveRoutingAdvertisement of a WAVE Service
> Advertisement, rather than that received in an RFC 4861 Router
> Advertisement message.

This may be an unncessarily new way to do same functionality.  The use
of RA is widely implemented and it should be preferred over the use of
link-layer specific mechanisms to realize address autoconfiguration.

In the past we have seen in the cellular space a similar mechanism to
configure IPv6 addresses with RANAP protocol.  At IEEE also we seem to
be seing the same thing in 802.11ai for Fast Initial Link Setup.  These
alternative ways to configure IP addresses are obviously incompatible
and may need to converge.

> WAVE provides this IP configuration information in the WAVE Service
> Advertisement to minimize the need for neighbor and router discovery
> with their associated overhead and latency.

The ND and router discovery may function quite fast.

> Note that IP transmissions are prohibited on the control channel.

It may be that IP transmissions are not prohibited on the control
channel.  Some of the 'road safety' and 'traffic efficiency
applications' of ETSI ITS may not be prohibited from using IP, hence
transmitted on the control channel.

Alex

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 19 Jun 2013 10:48:13 +0000

Hi, 

For the information of the participants in this work. The IETF has a formal liaison channel with the IEEE Standards Association. I am the Liaison Manager of the IETF to the IEEE-SA. I see that several participants already provided answers and information that seems reliable. If there is a need for more information, contacts, formal communication - please let me know I will try to help. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Wednesday, June 19, 2013 12:21 PM
> To: [email-masked]
> Subject: [its] P1609.3 Networking Services and IPv6 Address Auto-
> Configuration
> 
> ITSsers,
> 
> good that we have a contact with IEEE about P1609 and I look forward for
> closer collaboration.
> 
> To that end, let me mention technical aspects of IPv6 Address Auto-
> Configuration.
> 
> describes among other things aspects related to IPv6 address auto-
> configuration.
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: "John Moring" <[email-masked]>
Date: Fri, 21 Jun 2013 11:18:44 -0700

Greetings, I am editor of IEEE 1609.3 (and some of the other 1609
standards); I've recently started watching this forum. 

I appreciate the feedback on IPv6 references, and we'll try to tighten that
specification up on our next pass. 

Allow me to explain the rationale for the WAVE Routing Advertisement (WRA),
which is optionally sent as part of the WAVE Service Advertisement (WSA).
One usage scenario is a vehicle driving past a roadside unit (RSU) and
wishing reach an IP-based server through that RSU while within radio range.
The RSU broadcasts the WSA with WRA, perhaps every few 10s of milliseconds.
Upon receipt of the WSA, the vehicle has everything it needs (service info,
router info, perhaps addressing) to access the server, allowing it to use
the rest of its limited connectivity opportunity for application info
exchange. Using the standard discovery mechanism (which is allowed) would
reduce the time available for application transfer in this scenario. We have
not performed an analysis to estimate the time savings.

IP traffic is prohibited on the IEEE 1609 control channel (CCH) for legacy
reasons. When the requirement was written, we expected the CCH to carry a
heavy load of safety traffic as well as control info such as the WSA. Now,
the bulk of safety traffic is expected to use a different channel, and we
will revisit the prohibition of IP on the CCH.

We are currently collecting input for both corrections and improvements to
1609.3-2010 and 1609.4-2010. Any suggestions are welcome.

Regards,
John Moring

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Wednesday, June 19, 2013 2:21 AM
To: [email-masked]
Subject: [its] P1609.3 Networking Services and IPv6
AddressAuto-Configuration

ITSsers,

Following the mentioning of IEEE P1609.3 'Networking Services'.  It is good
that we have a contact with IEEE about P1609 and I look forward for closer
collaboration.

The document IEEE P1609.3/D5.0 Draft Standard for Wireless Access in
Vehicular 3 Environments (WAVE) - Networking Services, March 2010, describes
among other things aspects related to IPv6 address auto-configuration.

Moreover, if the intent of the text is to refer to the procedure of
stateless address autoconfiguration then the more precise reference would
rather be RFC4862 "Stateless Address Autoconfiguration".

> Advertisement, rather than that received in an RFC 4861 Router 

This may be an unncessarily new way to do same functionality.  The use of RA
is widely implemented and it should be preferred over the use of link-layer
specific mechanisms to realize address autoconfiguration.

In the past we have seen in the cellular space a similar mechanism to
configure IPv6 addresses with RANAP protocol.  At IEEE also we seem to be
seing the same thing in 802.11ai for Fast Initial Link Setup.  These
alternative ways to configure IP addresses are obviously incompatible and
may need to converge.

> Note that IP transmissions are prohibited on the control channel.

It may be that IP transmissions are not prohibited on the control channel.
Some of the 'road safety' and 'traffic efficiency applications' of ETSI ITS
may not be prohibited from using IP, hence transmitted on the control
channel.

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 21 Jun 2013 15:02:28 -0700

> Any suggestions are welcome.
> 
You _had_ to ask.

John,  I've spent the past decade observing the internet-ready standards
work for extending the internet to mobile platforms (e.g. IEEE 802.16)
and the past three years or so specifically looking at emergency
services -- fire, ambulance, police -- and their communications needs.  

But none of the NPSTC (National Public Safety Telecom Council) sources
(to pick just one example) seem to have any reference to IEEE 1609.
NPSTC, for reasons they probably can't explain, have latched onto LTE as
the layer 1/2 protocol.  Emergency services has a segregated 800MHz band
of spectrum available.  (This is US-specific).  Given the overlap in
needs and infrastructures, this is odd.

It appears that extending the internet to mobile platforms is a
thought-piece that has lots of independent players in their own silos.
The general recommendation is that these ought to be 'liaised' together
better (at all?) to forestall a lot of circular motion.