Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

[Alexandre Petrescu <[e-mail]>]

Pascal,

I do not understand some parts:
> For a link local address, the scope is the link, whereas for a
> global address the scope is the subnet from which the global address
> is derived.

For link local address the scope is the link - true.

For global address the scope is global (not a particular subnet nor a
prefix).

> The underlying assumption for DAD to operate correctly is that the 
> node that owns an IPv6 address can reach any other node within the 
> scope at the time it claims its address, which is done by sending a 
> DAD multicast message, and can hear any future claim for theat 
> address by another party within the scope for the duration of the 
> address ownership.

Yes.  The scope that you refer to is the link-local scope.  One uses DAD
to verify uniqueness of an IP address (link-local address, or
globally-scoped address, or ULA) on that link.  DAD cant be used to
verify uniqueness of an address beyond that link.

The uniqueness of a GUA or of a ULA beyond a link is ensured by other
means than DAD.  That is administrative means with some help from some
other tools.

Address ownership is not verified by DAD but by other things, including 
pings.

> In the case of OCB, there is a need to define a scope that is 
> compatible with DAD,

Well it sounds logic in a sense, but are you sure?  Is that need coming
from practice or from logic?  This is very important.  Without a
practical need it is not worth going to the trouble of adding new text.

Also, the only scope that is compatible with DAD is the link scope.

> and that [needed scope for DAD] cannot be the set of nodes that a 
> transmitter can reach at a particular time, because that set varies 
> all the time and does not meet the DAD requirements for a link local 
> address that could possibly be used anytime, anywhere.

This phrase is too long.

As I read it, it seems to have misunderstandings.

You say 'DAD reqs for a link local address that could possibly used
anytime anywhere' - what does it mean?  Some part of DAD (the initial
NAs) use the unspecified address (::) and dst a group.  None is an ll
address.

Or maybe you need a scope of a multicast group?

Again, the need of scope should come from practice to be worth considering.

> The generic expectation of a reliable multicast is not ensured, and 
> the operation of DAD and AR as specificed by RFC 4861 cannot be 
> guaranteed.

Please explain why DAD and address resolution cant be guaranteed.  In
practice.

I never seen DAD reporting problems of duplicates on OCB, or some
unreachability.

I did see DAD reporting problems in some other contexts, and I know what
these problems look like.

> Early experiences indicate that it should be possible to exchange 
> IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR.

YEs.  We did it even today.

> In the absence of a correct DAD operation, a node that relies only on
> IPv6 ND for AR and DAD over OCB MUST ensure that the addresses that
> it uses are unique by means others than DAD.

Means other than DAD, or DAD with a new scope as proposed earlier?

> It must be noted that deriving an IPv6 address from a globally
> unique MAC address has this property but yields privacy issues.

YEs, I agree, and we already recommend other more recent RFCs about the
forming of an Interface ID.

> RFC 8505 provides a more recent approach to IPv6 ND and in
> particular DAD.

RFC8505 "Registration Extensions for IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN) Neighbor Discovery"

OCB is not 6LoWPAN because cars have not LoW power, but relatively
higher.  Also, OCB is not PAN but more like LAN.

When OCB is used in a V2V manner it is very hard to say who should
register its address to whom.  It's different than
Sensor-to-BackboneRouter.  It is more like Peer-to-Peer.

> the [RFC8505] scope of uniqueness for a link local address is
> restricted to a pair of nodes that use it to communicate, and
> provides a method to assert the uniqueness and resolve the link-Layer
> address using a unicast exchange.

But look, in some of the V2V trials we did there was one leader and two 
followers, each immediately following the leader (not a chain, but more 
like a triangle formation).  In that there are three nodes needing DAD, 
not two.

Why should we discard the existing DAD that works and replace it with 
RFC8505 that only works for two nodes?

> RFC 8505 also enables a router (acting as a 6LR) to own a prefix and
> act as a registrar (acting as a 6LBR) for addresses within the
> associated subnet. A peer host (acting as a 6LN) registers an address
> derived from that prefix and can use it for the lifetime of the
> registration. The prefix is advertised as not onlink, which means that
> the 6LN uses the 6LR to relay its packets within the subnet, and
> participation to the subnet is constrained to the time of reachability
> to the 6LR. Note that RSU that provides internet connectivity MAY

It's an IP-RSU, not an RSU.

> announce a default router preference [RFC 4191], whereas a car that
> does not provide that connectivity MUST NOT do so. This operation
> presents similarities with that of an access point, but at
> Layer-3. This is why RFC 8505 well-suited for wireless in general.

Well, I think you make many logical extensions.

I think claiming RFC8505 to be well-suited for wireless in general is a 
very ambitious statement.

> Support of RFC 8505 is RECOMMENDED on OCB.

I disqgree.

> OCB nodes that support RFC
> 8505 

I am not sure there is any OCB node that supports RFC 8505.
Maybe you can point to one, or maybe how to make one?

> MUST support the 6LN operation in order to act as a host, and may
> support the 6LR and 6LBR operations in order to act as a router and in
> particular own a prefix that can be used by RFC 8505-complient hosts
> for address autoconfiguration and registration.

I think you have a particular view of what is an address architecture in 
the car networks, when you say 'own a prefix', or when you say Host and 
Router.

I will not oppose if you proposed an addressing architecture for 
vehicular networks, in a different draft.  I will comment to it and 
provide our view of addressing architecture for vehicular networks.

Alex

Le 05/04/2019 à 19:53, Alexandre Petrescu a écrit :
> PAscal, Thank you for the text.  We discussed about submitting text 
> and text is what is needed.
> 
> The beginning sounds good.
> 
> But then it is very long.
> 
> We have to discuss further RFC 8505 before inclusion of that 
> RECOMMENDED.
> 
> Alex
> 
> Le 05/04/2019 à 17:09, Pascal Thubert (pthubert) a écrit :
>> Dear all;
>> 
>> As promised I put together some words on using IPv6 ND and then
>> RFC 8505 for OCB. Please find attached early text. This could
>> become a section 4.7.
>> 
>> Note that RFC 8505 enables a DAD operation for both link local and 
>> global addresses, the associated global prefix being owned by 
>> either a car or a RSU. RSUs connected to the internet can
>> advertise a default router preference to indicate they are willing
>> to relay packets for global addresses.
>> 
>> The attached text impacts other sections in particular the 
>> discussion on global addresses which is somehow avoided in the 
>> current draft and could be reintroduced.
>> 
>> Comments welcome : )
>> 
>> Pascal
>> 
>> *From:* Pascal Thubert (pthubert) *Sent:* jeudi 28 mars 2019 11:29
>>  *To:* Alexandre Petrescu <[e-mail]> *Cc:* 
>> [e-mail] *Subject:* Re: Intdir early review of 
>> draft-ietf-ipwave-ipv6-over-80211ocb-34
>> 
>> Yes Alex. Also as an offer to help...
>> 
>> Regards,
>> 
>> Pascal
>> 
>> 
>> Le 28 mars 2019 à 11:08, Alexandre Petrescu 
>> <[e-mail] 
>> <mailto:[e-mail]>> a écrit :
>> 
>> Pascal,
>> 
>> Should we treat these two reviews (iotdir and intdir reviews) as 
>> just one?
>> 
>> The contents appear to me to be the same.
>> 
>> Alex
>> 
>> Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
>> 
>> Reviewer: Pascal Thubert
>> 
>> Review result: Not Ready
>> 
>> Reviewer: Pascal Thubert
>> 
>> Review result: Not ready. Need to clarify IEEE relationship, IOW 
>> which SDO
>> 
>> defines the use of L2 fields, what this spec enforces vs. 
>> recognizes as being
>> 
>> used that way based on IEEE work. The use of IPv6 ND requires a
>> lot more
>> 
>> thoughts, recommendation to use 6LoWPAN ND. The definition of a 
>> subnet is
>> 
>> unclear. It seems that RSUs would have prefixes but that is not 
>> discussed.
>> 
>> I am an assigned INT and IOT directorates reviewer for <
>> 
>> draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were 
>> written
>> 
>> primarily for the benefit of the Internet Area Directors. Document 
>> editors and
>> 
>> shepherd(s) should treat these comments just like they would treat 
>> comments
>> 
>> from any other IETF contributors and resolve them along with any 
>> other Last
>> 
>> Call comments that have been received. For more details on the INT 
>> Directorate,
>> 
>> seehttps://datatracker.ietf.org/group/intdir/about/
>> 
>> Majors issues
>> 
>> -----------------
>> 
>> “
>> 
>> o  Exceptions due to different operation of IPv6 network layer on
>> 
>> 802.11 than on Ethernet.
>> 
>> “
>> 
>> Is this doc scoped to OCB or 802.11 in general? Is there an 
>> expectation that an
>> 
>> implementer of IPv6 over Wi-Fi refers to this doc? Spelled as 
>> above, it seems
>> 
>> that you are defining the LLC. Figure 1 shows the proposed 
>> adaptation layer as
>> 
>> IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? 
>> Who defines
>> 
>> their use? If this spec defines a new LLC header (vs. how to use
>> an IEEE field)
>> 
>> then it should be very clear, and the newly defined fields should 
>> be isolated
>> 
>> from IEEE fields.
>> 
>> "
>> 
>> The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>> 
>> preceded by a Logical Link Control (LLC) header and an 802.11 
>> header.
>> 
>> "
>> 
>> Is there anything new or specific to OCB vs. classical 802.11 
>> operations?
>> 
>> If/when this is echoing the IEEE specs then this text should not 
>> use uppercase
>> 
>> but say something like: 'Per IEEE Std 802.11, the IPv6 packet 
>> transmitted on
>> 
>> 802.11-OCB is immediately  preceded by a Logical Link Control
>> (LLC) header and
>> 
>> an 802.11 header ...'
>> 
>> different things? Why define both?
>> 
>> "   An 'adaptation' layer is inserted between a MAC layer and the
>> 
>> Networking layer.  This is used to transform some parameters 
>> between
>> 
>> their form expected by the IP stack and the form provided by the 
>> MAC
>> 
>> layer.
>> 
>> "
>> 
>> Is this different from what an AP does when it bridges Wi-Fi to 
>> Ethernet? Is
>> 
>> this IETF business?
>> 
>> "
>> 
>> The Receiver and Transmitter Address fields in the 802.11 header 
>> MUST
>> 
>> contain the same values as the Destination and the Source Address
>> 
>> fields in the Ethernet II Header, respectively.
>> 
>> "
>> 
>> Same,  this is IEEE game isn't it?
>> 
>> "
>> 
>> Solutions for these problems SHOULD
>> 
>> consider the OCB mode of operation.
>> 
>> "
>> 
>> This is not specific enough to be actionable. I suggest to remove 
>> this sentence.
>> 
>> It would be of interest for the people defining those solutions to 
>> understand
>> 
>> the specific needs of OCB vs. Wi Fi, but I do not see text about 
>> that.
>> 
>> "
>> 
>> The method of forming IIDs
>> 
>> described in section 4 of [RFC2464] MAY be used during transition
>> 
>> time.
>> 
>> "
>> 
>> Contradicts section 4.3 that says
>> 
>> "
>> 
>> Among these types of
>> 
>> addresses only the IPv6 link-local addresses MAY be formed using 
>> an
>> 
>> EUI-64 identifier.
>> 
>> "
>> 
>> "
>> 
>> This
>> 
>> subnet MUST use at least the link-local prefix fe80::/10 and the
>> 
>> interfaces MUST be assigned IPv6 addresses of type link-local.
>> 
>> "
>> 
>> If this is conforming IPv6 then the MUST is not needed.
>> 
>> "
>> 
>> A subnet is formed by the external 802.11-OCB interfaces of 
>> vehicles
>> 
>> that are in close range (not by their in-vehicle interfaces).
>> 
>> "
>> 
>> Is the definition transitive? Do we really get a subnet?
>> 
>> A is close to  B who is close to C .... to Z, makes Paris one 
>> subnet! Are you
>> 
>> talking about a link, rather?
>> 
>> "
>> 
>> The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over
>> 
>> 802.11-OCB links.
>> 
>> "
>> 
>> IPv6 ND is not suited for a non-broadcast network. How does DAD 
>> work?
>> 
>> Maybe you could consider RFC 6775 / RFC 8505 instead.
>> 
>> "
>> 
>> In the moment the MAC address is changed
>> 
>> on an 802.11-OCB interface all the Interface Identifiers of IPv6
>> 
>> addresses assigned to that interface MUST change.
>> 
>> "
>> 
>> Why is that? This is unexpected, and hopefully wrong.
>> 
>> Minor issues
>> 
>> ---------------
>> 
>> "   OCB (outside the context of a basic service set - BSS): A mode 
>> of
>> 
>> operation in which a STA is not a member of a BSS and does not
>> 
>> utilize IEEE Std 802.11 authentication, association, or data
>> 
>> confidentiality.
>> 
>> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
>> 
>> attribute dot11OCBActivited is true.  Note: compliance with 
>> standards
>> 
>> and regulations set in different countries when using the 5.9GHz
>> 
>> frequency band is required.
>> 
>> "
>> 
>> Are these 2 different things?
>> 
>> "
>> 
>> Among these types of
>> 
>> addresses only the IPv6 link-local addresses MAY be formed using 
>> an
>> 
>> EUI-64 identifier.
>> 
>> "
>> 
>> This text should not be in a LL specific section since it deals 
>> with the other
>> 
>> addresses. Maybe rename the section to "addressing" or something?
>> 
>> "
>> 
>> For privacy, the link-local address MAY be formed according to the
>> 
>> mechanisms described in Section 5.2.
>> 
>> "
>> 
>> The MAY is not helpful. I suggest to remove the sentence that does 
>> not bring
>> 
>> value vs. 5.2
>> 
>> Could you make sections 4.3 and 4.5 contiguous?
>> 
>> "
>> 
>> If semantically
>> 
>> opaque Interface Identifiers are needed, a potential method for
>> 
>> generating semantically opaque Interface Identifiers with IPv6
>> 
>> Stateless Address Autoconfiguration is given in [RFC7217].
>> 
>> Semantically opaque Interface Identifiers, instead of meaningful
>> 
>> Interface Identifiers derived from a valid and meaningful MAC 
>> address
>> 
>> ([RFC2464], section 4), MAY be needed in order to avoid certain
>> 
>> privacy risks.
>> 
>> ...
>> 
>> In order to avoid these risks, opaque Interface Identifiers MAY be
>> 
>> formed according to rules described in [RFC7217].  These opaque
>> 
>> Interface Identifiers are formed starting from identifiers 
>> different
>> 
>> than the MAC addresses, and from cryptographically strong 
>> material.
>> 
>> Thus, privacy sensitive information is absent from Interface IDs, 
>> and
>> 
>> it is impossible to calculate the initial value from which the
>> 
>> Interface ID was calculated.
>> 
>> "
>> 
>> Duplicate and mis ordered text, isn't it?
>> 
>> " For this reason, an attacker may realize many
>> 
>> attacks on privacy.
>> 
>> "
>> 
>> Do we attack privacy? Maybe say that privacy is a real concern,
>> and maybe move
>> 
>> that text to security section?
>> 
>> "
>> 
>> The way Interface Identifiers are used MAY involve risks to 
>> privacy,
>> 
>> as described in Section 5.1.
>> 
>> "
>> 
>> Also duplicate
>> 
>> Nits
>> 
>> ------
>> 
>> "
>> 
>> IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>> 
>> frames whose format is specified in IEEE Std 802.11.
>> 
>> "
>> 
>> Please add link to the reference
>> 
>> " the 802.11 hidden node"
>> 
>> Do not use 802.11 standalone (multiple occurrences).
>> 
>> => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden 
>> terminal".
>> 
>> BCP 14 text:
>> 
>> Suggest to use this text:
>> 
>> “
>> 
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
>> NOT",
>> 
>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 
>> and
>> 
>> "OPTIONAL" in this document are to be interpreted as described in
>> 
>> https://tools.ietf.org/html/bcp14 
>> https://tools.ietf.org/html/bcp14
>> 
>> [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only
>> when, they
>> 
>> appear in all capitals, as shown here.
>> 
>> “
>> 
>> All the best
>> 
>> Pascal
>> 
> 
> _______________________________________________ its mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/its