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

[Alexandre Petrescu <[e-mail]>]

Le 26/04/2019 à 19:56, Mudric, Dusan (Dusan) a écrit :
> 
> 
>> -----Original Message-----
>> From: Alexandre Petrescu <[e-mail]>
>> Sent: Friday, April 26, 2019 5:02 AM
>> To: Mudric, Dusan (Dusan) <[e-mail]>; [e-mail]; Ole Troan
>> <[e-mail]>; , <[e-mail]>
>> Cc: Pascal Thubert (pthubert <[e-mail]>
>> Subject: Re: encoding Subnet ID in link-local addrs (Re: about violation of
>> standards)
>>
>>
>>
>> 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