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

["Mudric, Dusan (Dusan)" <[e-mail]>]

> >>
> >> 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?

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

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

- Would it be more flexible to assign LL Subnet IDs automatically (for example using RA)?  The automatic assignment would allow simple LL Subnet IDs.

- 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.

-  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)?