Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Stop monitoring project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005802IPv6overGeoNetworkingBase Specpublic02-11-2010 13:4502-11-2010 13:47
ReporterAlexandre Berge 
Assigned ToAlexandre Berge 
PrioritynormalSeveritymajorReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Versionv0.0.7 
Target VersionFixed in VersionNext Release 
Summary0005802: TS102636-6-1 v0.0.7 section 8.2.2: checks should be performed on destination address, not on source address
DescriptionIn section 8.2.2, point 2) b:

“If the IPv6 source address has a scope greater than link-scope and one
or more GVLs exist in the itsGn6aslVLTable whose GVL Area
contains the GeoNetworking source node’s position, the GN6ASL shall,
among those GVLs, select one (if present) that is associated to a virtual
interface for which that prefix is considered to be on-link. If such a
GVL does not exist in the itsGn6aslVLTable, the packet shall be silently
discarded.”

It means that an ITS station will drop all IPv6 packets for which the IPv6 source address does not match a prefix associated to a GVL ?
It seems then impossible for an ITS station to communicate with distant IPv6 hosts (it would be impossible for instance to connect to www.etsi.org from an ITS station)


In my opinion, this check should be performed on the IPv6 _destination_ address:

“If the IPv6 destination address has a scope greater than link-scope and one
or more GVLs exist in the itsGn6aslVLTable whose GVL Area
contains the GeoNetworking destination node’s position, the GN6ASL shall,
among those GVLs, select one (if present) that is associated to a virtual
interface for which that prefix is considered to be on-link. If such a
GVL does not exist in the itsGn6aslVLTable, the packet shall be silently
discarded.”
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0009794)
Alexandre Berge (administrator)
02-11-2010 13:47

 [Roberto Baldessari]

Yes, the IPv6 destination address should be checked and not the IPv6 source address. But the GeoNetworking source address should be checked too, in order to distinguish the link.

"b. If the GeoNetworking header is of type GEOUNICAST, the GN6ASL shall check the IPv6 destination address scope of the IPv6 header transported by the GEOUNICAST. If the IPv6 destination address is the link-local unicast address FE80::<IID>/10, the GN6ASL shall select the TVL as inbound virtual link. If the IPv6 destination address has a scope greater than link-scope and no GVL exists in the itsGn6aslVLTable whose GVL Area contains the GeoNetworking source node’s position, the GN6ASL shall silently discard the packet. If the IPv6 destination address has a scope greater than link-scope and one or more GVLs exist in the itsGn6aslVLTable whose GVL Area contains the GeoNetworking source node’s position, the GN6ASL shall, among those GVLs, select one (if present) that is associated to a virtual interface for which the IPv6 destination address prefix is considered to be on-link. If the IPv6 destination address prefix is considered to be on-link for more than one GVL, the GVL associated to the prefix with the highest invalidation timer value in the Prefix List [14] shall be selected as inbound GVL. If no GVL exists in the itsGn6aslVLTable that matches the above criteria, the packet shall be silently discarded."

- Issue History
Date Modified Username Field Change
02-11-2010 13:45 Alexandre Berge New Issue
02-11-2010 13:46 Alexandre Berge Summary TS102636-6-1 v0.0.7 section 8.2.2: => TS102636-6-1 v0.0.7 section 8.2.2: checks should be performed on destination address, not on source address
02-11-2010 13:47 Alexandre Berge Status new => resolved
02-11-2010 13:47 Alexandre Berge Fixed in Version => Next Release
02-11-2010 13:47 Alexandre Berge Resolution open => fixed
02-11-2010 13:47 Alexandre Berge Assigned To => Alexandre Berge
02-11-2010 13:47 Alexandre Berge Note Added: 0009794

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker