Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Le 10/04/2019 à 15:44, Pascal Thubert (pthubert) a écrit :
Hello Ole:

Better remove, it is wrong anyway.

Pascal, fe80::/10 is not wrong, because:
- using fe80::/10 on OCB works ok.
- using fe80::/10 on Cisco, linux and openbsd works ok.
- IANA allows fe80::/10 for link-local addresses.

Why do you think fe80::/10 is wrong?

Because it is transitive, the description extends the so-called subnet step by step to a potentially large number of cars such that there is no broadcast domain that covers them all.

Pascal - the extension of OCB subnets happens with IP routing
(forwarding between IP OCB interfaces), not with bridging.  The IP
routing does not forward link-locally scoped IP packets.

There is indeed no single broadcast domain that covers them all. But there is potentially a multicast scope that could cover them all. I never tried it, but I guess it may be necessary.

There is no single broadcast domain for all these numerous cars in a convoy also because each car uses not one OCB interface but three OCB interfaces, each situated in a distinct IP subnet.

If there is no broadcast domain and no multicast emulation like a BSS
does, how can we run ND? Yes, it works with 3 cars in a lab.

If it is ironic...

Between each pair of cars (or triplet of cars some times) there is a distinct IP subnet; that IP subnet links the front bumper of one car to the rear bumper of the other car (or the rear of a car to two fronts of the other two cars, if in triangle formation). These IP subnets support well IPv6 and ND works ok.

It works with 3 cars on track, not just in the garage. They form linear convoy, or triangle formation some times.

The description looks like it is confused with the MANET / 6LoWPAN concept of link, whereby my link joins the collection of nodes that my radio can reach.

No, there is no confusion in writing. There is no confusion in experimenting.

There may be confusion in reading.

We do not use MANET protocols neither 6LoWPAN protocol, nor their concepts of links, nor 802.15.4. They are valuable in other contexts.

Alex


All the best,

Pascal

-----Original Message----- From: Ole Troan <otroan@xxxxxxxxxxxxx> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> Cc: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>; ietf@xxxxxxxx; its@xxxxxxxx; int-dir@xxxxxxxx; draft-ietf-ipwave-ipv6-over- 80211ocb.all@xxxxxxxx; Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> Subject: Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64

You said: if OCB is still 48bit, and if there is bridging OCB-Ethernet, then no
reason to be different than rfc2464.

I said: OCB is still 48bit, but there is no bridging OCB-Ethernet.

The conclusion is: there is reason to be different from RFC 2464.

Why?

Now, you give a different conclusion.

Excuse me, I would like to clarify this please?

Clarify what? That a link-layer that looks an awfully lot like Ethernet should not follow the 64-bit boundary and the definition of the link-local address mapping of rfc2464? Section 4.5.1 is already clear on that.

I think the only thing we are asking you is to change the
following paragraph:

OLD: A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces). This subnet MUST use at least the link-local prefix fe80::/10 and the interfaces MUST be assigned IPv6 addresses of type link-local.

NEW: A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces). A node MUST form a link-local address on this link.

Not quite sure what value that paragraph adds in the first place. You could probable remove it.

Cheers, Ole



Alex

Le 10/04/2019 à 12:28, Ole Troan a écrit :
Alexandre, Right, so it doesn’t sound like you have any reason to be different from
RFC2464.
Just reference or copy that text (section 5, rfc2464). Ole
On 10 Apr 2019, at 11:22, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx> wrote:



Le 10/04/2019 à 11:04, Ole Troan a écrit :
"At least" does not mean "the value should be at least 10" in that
phrase.

Do you think we should say otherwise?

To me there is nothing in the actual text to tell me that "at least" qualifies the "/10". I think you could rephrase as "This subnet's prefix MUST lie within the link-local prefix fe80::/10 ..."

However, see Jinmei's messages about conformance
with RFC 4291.

I think there might be unexpected side effects from using an address like fe80:1::1. What if some code uses matching with fe80::/64 to test if an address
is link-local? I agree that would be faulty code,
but you would be the first to discover it.
Indeed. If you absoultely must cut and paste text from 2464:

YEs, that is how we started. We cut and paste from 2464.

5. Link-Local Addresses The IPv6 link-local address [AARCH] for an Ethernet interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+



|1111111010|         (zeros)       |    Interface Identifier    |

+----------+-----------------------+----------------------------+




I presume there is support for bridging 802.11p and other 802.3 links?

In the IP-OBUs that I know there is IP forwarding between 802.11-OCB
(earlier 802.11p) and 802.3, not bridging.

In some IP-OBU (Internet Protocol On-Board Unit) some non-OCB
interfaces are indeed bridged. E.g. the Ethernet interface is bridged to the WiFi interface; that helps with DHCP, tcpdump and others to see one a single - bridged - interface.

Bridging may be, but it is not a MUST. There is no necessarily any bridging
between the 802.11-OCB interface and other interface, neither bridging between the multiple 802.11-OCB interfaces that might be present in the same computer.

Do you assume bridging of 802.11-OCB interface to Ethernet interface is
always there?

Note: I also heard many comments suggesting that EAL is akin to
'bridging'. I do not know whether you refer to that perspective. If yes, we can discuss it separately.

Alex

[...]

And that the MAC address length of this link type is also 48 bits?

YEs, the length of MAC address on 802.11 mode OCB is
also 48.

If the two assumptions above hold, then I see zero justification for
pushing the 64 bit boundary in this draft.

Let me try  to understand the first assumption.
Ole

_______________________________________________ Int-dir mailing list Int-dir@xxxxxxxx https://www.ietf.org/mailman/listinfo/int-dir

_______________________________________________ Int-dir mailing list Int-dir@xxxxxxxx https://www.ietf.org/mailman/listinfo/int-dir





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux