Re: encoding Subnet ID in link-local addrs (Re: about violation of standards)

[Alexandre Petrescu <[e-mail]>]

Dusan,

Le 29/04/2019 à 16:31, Mudric, Dusan (Dusan) a écrit :
>>>> 
>>>> Le 25/04/2019 à 16:32, Mudric, Dusan (Dusan) a écrit :
>>>>> 
>>>>>> 2 IPv6 link-local addresses are typically self-configured
>>>>>> according to 4 RFCs and relying on the fe80::/10 IANA
>>>>>> allocation, RFC 54 0 bits, and RFC MAC-based 64bit
>>>>>> Interface IDs.  In some cases, it is advantageous to
>>>>>> manually configure link-local addresses.  This is useful
>>>>>> for easy remembering by humans, and for parameter
>>>>>> resilience during network interface replacement.
>>>>>> 
>>>>>> Manual configuration of an LL may use short IID and Subnet
>>>>>> ID The Subnet ID presence in the link-local address is
>>>>>> useful in some wireless settings where the subnet structure
>>>>>> parameters depend on the link locality.  Other settings may
>>>>>> also benefit.
>>>>>> 
>>>>>> When manually setting the link-local address it is
>>>>>> necessary to know the length of the prefix of the subnet on
>>>>>> which this link-local address is present.  This length is
>>>>>> necessary for on-link determination.
>>>>>> 
>>>>> [Dusan] Is the Subnet ID unique per host?
>>>> 
>>>> In  my setting, the Subnet ID in the LL address is unique per
>>>> subnet, not per host.  There is a subnet formed by the front
>>>> bumper interface in the follower car and the rear bumper
>>>> interface of the lead car.
>>>> 
>>>> The Subnet ID in an LL address would be unique per a set of
>>>> hosts in that subnet.
>>>> 
>>>>> Is it possible that all hosts on the link share the same
>>>>> Subnet ID?
>>>> 
>>>> Yes, they should.
>>>> 
>>>>> Can somebody provide more details about the problem and how
>>>>> this solution will solve the problem?
>>>> 
>>>> More details about the problem: RFC4291 54 0 bits would refuse
>>>> to change to accomodate this solution's Subnet ID in an LL
>>>> address; another detail is that one particular OS would not
>>>> allow the manual configuration of an LL address setting some of
>>>> these 54 0 bits.
>>>> 
>>>> Alex
>>>> 
>>>>> 
>>> [Dusan] These are RFC4291 and OS limitations, if you would define
>>> Subnet
>> ID in LL address.
>> 
>> Agreed.
>> 
>>> Based on the comment above, I gather you are talking about
>>> vehicle- to-vehicle (V2V) communication.
>> 
>> YEs.  How IP could be used in V2V communications? one would look at
>> the IPWAVE WG Problem Statement and Use Cases 
>> draft-ietf-ipwave-vehicular-networking-08 section 'V2V' and an
>> Architecture Figure 1 depicting a relevant topology of V2V and
>> V2I.
>> 
>>> Looks like there are several cars talking to each other on the
>>> local link. They form a subnet.
>> 
>> Yes.  In my setting, there can be two or three cars in a subnet.
>> When there are two in a subnet they are either a convoy of two
>> cars, or a convoy of three cars with two subnets:
>> car-subnet1-car-subnet2-car. When there are three cars in a subnet
>> the convoy is not linear, but a triangular formation: the leader
>> has two first followers, and they are more like in a triangle than
>> in a line.
>> 
>>> Somehow, somewhere, there is a master device that knows this is a
>>> subnet.
>> 
>> Yes, that is the Cloud who knows the subnets; it knows the
>> frequencies (channels) on which subnets are; one subnet is in a
>> channel and vice-versa; the cloud also knows, or imposes, who are
>> the participants in each subnet and their relative position in the
>> convoy (Leader, First Follower, Second Follower).
>> 
>>> May be that device's link is on the subnet. ...
>> 
>> YEs.  There is an IP-OBU (Internet Protocol On-Board Unit) on each
>> car; this IP-OBU has several IP-enabled interfaces; the interface
>> of an IP- OBU in one car forms a subnet with the interface of
>> another IP-OBU in another car.
>>> 
>> 
>>> 
>>> - Can you please provide more details about the topology first,
>> 
>> The topology in a linear convoy is like this:
>> 
>> car1                       car2                        car3 
>> ---------                   ---------                  --------- |
>> IP-OBU1 | ---subnet1 ---- | IP-OBU2 | --- subnet2--- | IP-OBU3 | 
>> ---------                   ---------                  --------- 
>> |in-car                     |                          | |subnets:
>> Ethernet, WiFi, CAN, BT, etc
>> 
>> (subnet1 is on 5880 MHz, subnet2 is on 5890 MHz)
>> 
>> (in the triangular convoy the figure is different)
>> 
>>> - then, details about the restrictions with the current LL
>>> definition in that topology,
>> 
>> In the above topology the restrictions with RFC4291 definitions,
>> and the FreeBSD implementations are the following:
>> 
>> - RFC4291 needs 64bit MAC-based IIDs on the LLs on subnet1 and
>> subnet2. The inconvenients of these restrictions are the
>> following: - 64bit IIDs are too long to remember and type; easy to
>> remember addresses are good for network debugging. - MAC-based IIDs
>> may have some privacy risk; attackers on the road may listen to
>> these IIDs (they are sent outside the car) and make associations
>> that may help tracking users, like web cookies do. - RFC 4291 54 0
>> bits make it impossible to assign subnet-specific link-local
>> addresses to subnet1 and subnet2. A RFC4291-compliant link-local
>> address, like fe80::IID/64, assigned to an interface on subnet2,
>> and replying from a ping from subnet1, does not give ensurance that
>> subnets (on 5880 MHz or on 5890 MHz) are set up wrongly.  It may be
>> that the channels are set wrong (subnets are set up wrongly) as
>> much as it may be that that fe80::IID/64 is in the same subnet as
>> the pinger and the channels are right.
>> 
>> On another hand, if the LL addresses were like fe80:1::X on subnet1
>> and fe80:2::Y on subnet 2, then a ping issued from subnet1 to
>> fe80:2::X and replying OK means clearly that the channels are set
>> wrongly.
>> 
>> RFC4291 54 0 bits prevent this use of subnet-specific LL
>> addresses.
>> 
>> - FreeBSD OS: - forbids the manual assignment of LL addresses on
>> interfaces (it is impossible to ifconfig add fe80::2 on an
>> interface). - FreeBSD OS does not implement OCB mode.  OCB mode is
>> an essential kind of link in vehicular communications.
>> 
>>> - then, details about the expected improvements if LL has the
>>> Subnet ID?
>> 
>> The expected improvements are the following:
>> 
>> - human users type short LL addresses, like fe80:1::1 instead of
>> long to type addresses like fe80::IID64bit - use fe80:1::1 and
>> fe80:2::1 in two distinct subnets; if a ping from fe80:1::1 to
>> fe80:1::2 that does not reply means the channels are wrong; 
>> otherwise (with fe80::IID) it is impossible to say whether the
>> channels are wrong or that wrong address was used to ping (all
>> fe80::IID64bit) look the same to a human - they are 'random'). -
>> BSD allowing manual configuration of LL addresses may have other
>> benefits outside the OCB context
>> 
>>> Once we understand these three categories, we will be able to
>>> talk about solutions. May be the solution will be generic enough
>>> to help other mobile hosts too, not just V2V.
>> YEs, easy to remember link-local addresses can be used by sys admin
>> to diagnose links between UE and pGW.  Currently these link-local
>> addresses on the UE and pGW are negotiated at link setup time (LCP
>> protocool). This negotiations comes up with 64bit IIDs.  They get
>> in the routing tables of both.  When human tries to test whether
>> they work human needs to copy paste that long address and ping it;
>> it would have been easier if the negotiation gave shorter IIDs like
>> 1, or 2.
>> 
>> Second, the pGW uses a distinct routing table entry for each UE
>> attached to it.  IT would probably make sense to have the nexthop
>> of that entry of a simple form and that also identifies briefly
>> that entry: a nexthop like fe80:1::2 means that the first '1' is
>> the UE number 1.
>> 
>> YEs, we could talk about solutions that are valid outside V2V and
>> OCB mode.
>> 
>> Alex
> [Dusan] Great topology and problem descriptions. Thanks.
> 
> I have further questions and initial proposals.
> 
> - Why is it important to assign LLs manually?

BEcause we need to prototype fastly the dynamic assignment of channels
to form subnets.  This fast prototype includes the development of
intelligent algorithms in the cloud and the execution of scripts that
are commanded by that the algorithms.  The scripts call 'ifconfig' commands.

The manual assignment of LLs is also needed for other reasons:

- currently the LLs have only long forms (64 bit IIDs) which are
difficult to remember.  We need something easy to type in order to
debug the network.

- the LLs need to have a significance with respect to particular subnet.
  If a ping replies it should mean that one is part of that subnet.


> - Is it more important to assign Subnet IDs or IIDs? Based on the
> examples above, managing Subnet IDs on a local link will allow

Both have same importance.

> -- grouping of devices (cars and devices within cars) within LL
> Subnets, and -- a better control of devices on the LL Subnets.
> 
> - If the control can be done based on Subnet IDs, do these IDs have
> to be short and simple?

YEs.

> 
> - Would so simple LL addresses, like fe80:1::2 in the example, cause
> any security risks?

There is a list of SeND implementations.  I suppose they all work with
fe80:1::2 as much as they work with fe80::64bitIID.  I dont think
fe80:1::2 adds more risk than fe80::64bitIID.  But to be sure, that can
be verified in practice.
> 
> - Would it be more flexible to assign LL Subnet IDs automatically
> (for example using RA)?  The automatic assignment would allow simple
> LL Subnet IDs.

It would.

In that case, my fast prototyping problem comes to the ability to script
the modification of the config file of the RA.  It is not impossible,
because we already script it for other parameters.

> - Would LL Subnets benefit from the knowledge of the global subnets?
> I expect  the cloud that knows about subnets is also assigning the
> subnet prefixes for global addresses in Car1, Car2 and Car3.
> Potentially, the same global prefixes can be reused within LL
> addresses, as Subnet IDs.

Well, at this time the Cloud does not assign global subnets to these
cars.  Maybe it should.  I dont know how.

I think the ULAs inside a car make sense - the cars be pre-hardcoded
with independent unique ULA per car, at manufacture time.

(currently cars are pre-hardcoded with a same 192.168 at manufacture time).

> -  If global or random Subnet IDs are used, and they are long, can
> DNS help to reach subnets (for example resolve Subnet2Host1 name into
> fe80:Subnet2:1, so a user does not need to know  and type the long
> Subnet2Host1 number when pinging fe80:Subnet2:1)?

I think yes, it could.

I am not sure whether you request I modify the draft to reflect these
points?

Alex

> 
>