Le 17/04/2019 à 23:55, Brian E Carpenter a écrit :
Hi Alexandre, On 17-Apr-19 21:41, Alexandre Petrescu wrote:
Brian,
Le 16/04/2019 à 04:18, Brian E Carpenter a écrit : [...]
I think I will drop this discussion until ipwave gets its two
main drafts properly synchronized.
I would like to ask you whether you disagree that we move the
appendix titled "ND issues in wireless links" away from the
IP-over-OCB draft into the IPWAVE Problem Statement draft?
My understanding now is that the IP-over-OCB draft is scoped only for
single-link subnets (i.e. does not even try to cover the case of
hidden nodes). I think that needs to be stated very clearly,
I propose this text in the Subnet Structure section of IP-over-OCB draft:
NEW:
The subnet structure on which the Neighbor Discovery protocol (ND)
on OCB works ok is a single-link subnet; the status of ND operation
on a subnet that covers multiple OCB links that repeat the signal at
PHY layer, or the messages at MAC layer, is unknown.
[...]
and I don't quite understand whether there is a non-link-local prefix
at all.
In my network of 3 cars no, there is no non-LL prefix at all between cars.
In my deployment of 2 cars and an IP-RSU IPv6 4G NAT66 NEMOv6 there was
a ULA prefix between the RSU and the car, on OCB. In year 2015.
In a very fluid network situation, it isn't at all obvious that a
useful non-link-local prefix can be established.
I agree.
The problem is probably less in the fluidity, than in determining authority.
When there is an RSU one may associate authority to RSU that got it from
Cellular Operator who got it from the Default FRee Zone; but absent RSU
who should be trusted as authority?
It is the same problem when we try to make security between several cars
in a convoy. We try to use quickly the OpenVPN software to achieve
security, but who's the client who's the server? Cars are created
equal. They are equally safe, even though some are more expensive than
others. We may end up with two openvpn tunnels between two cars, when
one is normally sufficient.
The draft seems a bit ambiguous on that point, so perhaps that can
also be clarified.
YEs, could be, in the Problem Statement draft.
Given those changes, I agree that moving the appendix as you suggest
would be reasonable.
By the way, where you use the word "global" to describe IPv6
addresses or prefixes, I suggest using either "Globally Reachable"
(as defined in RFC8190) or "global unicast" as defined in RFC8200.
ULA != globally reachable. ULA == global unicast
Noted.
Alex
Regards Brian
