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

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 25 Apr 2019 14:32:10 +0000

> 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? Is it possible that all hosts on the link share the same Subnet ID? Can somebody provide more details about the problem and how this solution will solve the problem?

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Apr 2019 11:01:30 +0200

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

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 26 Apr 2019 17:56:28 +0000

> -----Original Message-----
> From: Alexandre Petrescu <[email-masked]>
> Sent: Friday, April 26, 2019 5:02 AM
> To: Mudric, Dusan (Dusan) <[email-masked]>; [email-masked]; Ole Troan
> <[email-masked]>; , <[email-masked]>
> Cc: Pascal Thubert (pthubert <[email-masked]>
> Subject: Re: encoding Subnet ID in link-local addrs (Re: about violation of
> standards)
> 
> 
> 
> 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.
> 
> 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. Based on the comment above, I gather you are talking about vehicle-
   to-vehicle (V2V) communication. Looks like there are several cars talking to each other on the local link. They form a subnet. Somehow, somewhere, there is a master device that knows this is a subnet. May be that device's link is on the subnet. ...

- Can you please provide more details about the topology first,
- then, details about the restrictions with the current LL definition in that topology,
- then, details about the expected improvements if LL has the Subnet ID?

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.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 26 Apr 2019 18:48:08 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Alexandre Petrescu

that subnet.

Instead of messing with LL standards, why not use ULAs? For example, the front car determines the 54 random bits in the ULA prefix. Same logic as you are using now, without requiring any DNS, and without violating anything.

I would always look for an equally simple solution that doesn’t need to violate standards. It is the path of least resistance.

Alternatively, you can do what MANET does, which is essentially to use IP addresses as flat address space.

Bert

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 17:18:36 +0200

Le 26/04/2019 à 20:48, Manfredi (US), Albert E a écrit :
> -----Original Message----- From: ipv6 <[email-masked]> On
> Behalf Of Alexandre Petrescu
> 
> 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.
>> 
> Instead of messing with LL standards, why not use ULAs? For example,
> the front car determines the 54 random bits in the ULA prefix. Same
> logic as you are using now, without requiring any DNS, and without
> violating anything.

I need the cars to send RAs to each other.  I think RAs have src a LL 
address.  Hence the need to use LLs.

Second, a ping to LL responding ok means the channels (frequency, GHz) 
are set correctly.  A ping to LL not responding means the channels are 
not set correctly.  Were that LL a GUA/ULA the conclusion is not the 
same, because IP routing.

HEre are the details:

Outside a car there are multiple subnets.  Each subnet is on a different 
5.9GHz channel.  The only addresses sure to be present are the LL addresses.

If I ping a paarticular address (fe80:1::1) and it responds it means 
that the channel is set correctly.    If it does not respond, it means 
the channel is set incorrectly.

If on the other hand I used GUAs or ULAs instead of LLs, the fact that a 
ping responds may mean the router between the subnets forwards, even 
though the channels might be set incorrectly.

Thus, when I ping fe80:1::1 and it responds I am sure I am in that 
fe80:1::/32 subnet and the channels are set correctly.  A negative 
answer means the channels are set incorrectly.

I hope I explained clearly enough, otherwise I can explain further.

> 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.
> 
> I would always look for an equally simple solution that doesn’t need
> to violate standards. It is the path of least resistance.

I agree with you to look for simplest solution not violating standards.

In addition, I would also look for what immediately available 
implementation can do.

I the deployments where I work, people are much harsher about technology 
than here.

Note that the ULA recommendation I received at IETF I did take and 
deploy in some cars - but inside the cars, not outside.

> use IP addresses as flat address space.

YEs.  Many people suggest that.

Flat addressing space on OCB may work but has some indeterminism.  There 
is no bridging in OCB, there is much dynamicity, etc.  SOme things 
happen and you dont know why.  I am afraid a convoy of more than 
800meter long will not scale (workr eliably) if MANET IP flat address 
space is used.

But only trying it in practice can prove me right or wrong.  And trying 
it in practice I cant do in the immediate months. (a convoy of more than 
800m).

On another hand, claiming that a flat IP space on OCB on a convoy of 
more than 800m long works ok should also be backed by some experimental 
evidence.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 27 Apr 2019 20:19:34 +0200

Le 26/04/2019 à 19:56, Mudric, Dusan (Dusan) a écrit :
> [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

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 29 Apr 2019 14:31:49 +0000

> >> 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
> section 'V2V' and an Architecture Figure 1 depicting a relevant topology of
> V2V and V2I.
> 
> 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.
> triangular formation: the leader has two first followers, and they are more
> like in a triangle than in a line.
> 
> (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).
> 
> 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.
> >
> 
> >
> - human users type short LL addresses, like fe80:1::1 instead of long to type
> addresses like fe80::IID64bit
> 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
> 
> 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.
> 
[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)?