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

[Alexandre Petrescu <[e-mail]>]

Le 06/05/2019 à 17:36, Mudric, Dusan (Dusan) a écrit :
> Hi Alex,
> 
> I kept the whole content so we can have a nice description of the problem and various arguments together. Please find the comment at the bottom.
> 
> Thanks,
> Dusan.
> 
>> -----Original Message-----
>> From: Alexandre Petrescu <[e-mail]>
>> Sent: Monday, May 6, 2019 9:47 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)
>>
>> 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?
> [Dusan] I have not been following the correspondence since the beginning. Sorry. Can you send the link to the draft please?

Yes, it is:

https://tools.ietf.org/html/draft-petrescu-6man-ll-prefix-len-17

> Without seeing the draft, I think you it would be nice to update it. The main idea is to be able to configure Subnet ID for multiple hosts via RA, rather than doing it for each host manually. Since global IIDs are already managed to provide subnetting, we should check if they can be reused for LLs. DNS can be extended to resolve SubnetID_HostID into LL, to further simplify the subnet management. If DNS resolver is used, a short Subnet ID might not be needed.
> 
> I am hoping a more generic approach will benefit other IoT devices on local links.

I added some text along the lines of DNS.  There was some text already 
about the fe80 prefix in RA.

If further improvement is needed to address your comment I will do.

Alex

> 
>>
>> Alex
>>
>>>
>>>