Subject: Fwd: New Version Notification for draft-petrescu-6man-ll-32-ietf-iana-request-00.txt

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:42:04 +0200

Hi participants to 6MAN WG,

I submitted a new Internet Draft that requests IETF / IANA to assign the 
fe80:1::/32 prefix.

I want it for me, but I dont mind sharing it with others.

Alex

-------- Message transféré --------
Sujet : 	New Version Notification for 
draft-petrescu-6man-ll-32-ietf-iana-request-00.txt
Date : 	Fri, 19 Apr 2019 07:40:33 -0700
De : 	[email-masked]
Pour : 	Alexandre Petrescu <[email-masked]>, Alexandre 
Petrescu <[email-masked]>

A new version of I-D, draft-petrescu-6man-ll-32-ietf-iana-request-00.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name: draft-petrescu-6man-ll-32-ietf-iana-request
Revision: 00
Title: A request to IETF / IANA to Allocate a 32bit Link-Local Prefix
Document date: 2019-04-19
Group: Individual Submission
Pages: 3
URL: 
https://www.ietf.org/internet-drafts/draft-petrescu-6man-ll-32-ietf-iana-request-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-petrescu-6man-ll-32-ietf-iana-request/
Htmlized: 
https://tools.ietf.org/html/draft-petrescu-6man-ll-32-ietf-iana-request-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-petrescu-6man-ll-32-ietf-iana-request

Abstract:
This draft requests IETF / IANA to assign the link local prefix
fe80:1::/32.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:43:27 +0200

I request support for this Internet Draft that requests IANA the 
assignment of the fe80:1::/32.

Please reply to this email for support.

Alex

-------- Message transféré --------
Sujet : 	Fwd: New Version Notification for 
draft-petrescu-6man-ll-32-ietf-iana-request-00.txt
Date : 	Fri, 19 Apr 2019 16:42:04 +0200
De : 	Alexandre Petrescu <[email-masked]>
Pour : 	IPv6 <[email-masked]>

Alex

-------- Message transféré --------

Abstract:

The IETF Secretariat

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 15:45:26 +0100

> I want it for me, but I dont mind sharing it with others.

If you want it for yourself, then you need to state this in the draft. 
If you intent to share it with other people, then you should state that too.

Otherwise, the draft does not describe who the prefix should be assigned 
to, or why it should be assigned.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:58:19 +0200

Le 19/04/2019 à 16:45, Nick Hilliard a écrit :
>> I submitted a new Internet Draft that requests IETF / IANA to assign 
>> the fe80:1::/32 prefix.
>>

Does your comment mean support?

If it means support, please post it in the thread where I ask support.

I am asking you do that because the AD is under the impression there is 
no support for this.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 16:17:31 +0100

> Does your comment mean support?

It means that you haven't stated who the prefix should be assigned to, 
or why it should be assigned.  Until you do this, no-one is even going 
to consider your proposal.

> I am asking you do that because the AD is under the impression there is 

Indeed, it doesn't look like the working group is being overwhelmed by 
support.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:24:00 +0200

> to consider your proposal.

Ok, I added 'assigned for vehicular networks' in -01.

Do you consider the proposal?

>> I am asking you do that because the AD is under the impression there 
>> is no support for this.
> 
If that is ironical, I am sorry.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 16:31:35 +0100

> Do you consider the proposal?

I've read it but don't support it because it lacks any justification.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:43:10 +0200

> I've read it but don't support it because it lacks any justification.

I propose this justification.

Do you support it?

If yes, then I insert it in the draft.

 > In one such vehicular network there are 3 cars in a convoy.  Each car
 > has several computers and routers.  Each car has an IPv6 OCB (OCB -
 > Outside the Context of a BSSID, an 802.11 mode at 5.9GHz, specific
 > for vehicles) interface on front bumper and another interface on the
 > rear bumper.  There is a distinct IPv6 subnet between a pair of cars
 > (at a distinct 5.9GHz channel), and several IPv6 subnets in each car,
 > with hubs, etc.
 >
 > When setting this up automatically, and troubleshooting IPv6 routing, 
 > I need:
 > - simple way to ping.  It must be simple, because in-car programmer
 >   position is uncomfortable (not like at a desk); copy paste is
 >   difficult of long IPv6 addresses.  Shorter commands to type are
 >   easier.
 > - no globally routable prefixes on interfaces between cars, because
 >   it's hard to determine which car should allocate a prefix to which
 >   other car.
 > - distinct link-local addresses for all between-cars interfaces,
 >   because when ping replies I need to understand quickly from which
 >   car it comes.
 > - a same Interface ID on all front bumpers (e.g. '1') and same
 >   Interface ID on all rear bumpers (e.g. '2'); so that it easy to
 >   remember and picture in mind.
 >
 > That leads me to manually assign (script) fe80:1::1/32 and
 > fe80:1::2/32 on the subnet between first and second cars,
 > fe80:2::1/32 and fe80:2::2/32 between 2nd and 3rd car, and why not
 > more cars later.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Fri, 19 Apr 2019 18:49:16 +0200

>  That leads me to manually assign (script) fe80:1::1/32 and >
>  fe80:1::2/32 on the subnet between first and second cars, >
>  fe80:2::1/32 and fe80:2::2/32 between 2nd and 3rd car, and why
>  not > more cars later.

Please explain why you can't do the same thing within the existing 
fe80::/64 prefix, i.e. assign fe80::1:1/64 and fe80::1:2/64 to one subnet,
and fe80::2:1/64 and fe80::2:2/64 to another.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 19 Apr 2019 16:52:58 +0000

Alex,

I think the main issue here is, why can you NOT use a flat address space, for this vehicle system? Why do you think you need separate prefixes?

Bert

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Philip Homburg
Sent: Friday, April 19, 2019 12:49
To: [email-masked]
Cc: Alexandre Petrescu <[email-masked]>
Subject: Re: support for draft-petrescu-6man-ll-32-ietf-iana-request-01.txt 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Apr 2019 19:05:40 +0100

> I propose this justification.

No - you've made no claims which would justify the reassignment of a 
large chunk of fe80::/10.  There's lots of other address space out there 
which might make a better choice because it wouldn't be encumbered by 
reassignment behaviour problems.

I doubt that the IETF would stand in the way of the car industry asking 
for chunks of address space for its own purposes, btw.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Apr 2019 00:06:44 +0200

Bert,

Le 19/04/2019 à 18:52, Manfredi (US), Albert E a écrit :
> Alex,
> 
> I think the main issue here is, why can you NOT use a flat address
> space, for this vehicle system? Why do you think you need separate
> prefixes?

Thank you for asking.

Note that I no longer request support.  The WG IPWAVE declared consensus 
on 64bit, so I retire from that draft.

With respect to your question:

I do not understand what do you mean by flat address space.

There are at least two distinct IPv6 prefixes in each car: one for 
Ethernet one for its wifi hotspot.

Then there are the interfaces to the outside of the car.  I dont really 
know what prefix to put there.  Whatever prefix I put on an egress 
interface of a car it means that other car should use it to form an 
address in it; but why not the other way around; so you end up with two 
prefixes on a link between two cars.  So I thought I'd put a generic 
link-local prefix FE80::/64 and a particular fe80:1::/32 for debugging. 
  IT works.  But I no longer push it here.

I do not know what do you mean by flat; it's as if I said that there is 
soething there hierarchical, or unflat.  I did not say that.

Maybe you mean I should have used a multi-link subnet, and a single huge 
/64 on all these links between several cars outgress and ingress interfaces.

Well, for multi-link subnets to work one needs bridging to work. 
Bridging works fine between Ethernet and WiFi.  But bridging OCB to 
Ethernet does not work.

I really dont know what do you mean by flat address space.

Alex
> 
> Bert
> 
> -----Original Message----- From: ipv6 <[email-masked]> On
> Behalf Of Philip Homburg Sent: Friday, April 19, 2019 12:49 To:
> [email-masked] Cc: Alexandre Petrescu <[email-masked]> 
> Subject: Re: support for
> draft-petrescu-6man-ll-32-ietf-iana-request-01.txt
> 
> fe80::/64 prefix, i.e. assign fe80::1:1/64 and fe80::1:2/64 to one
> subnet, and fe80::2:1/64 and fe80::2:2/64 to another.
> 
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Apr 2019 00:13:07 +0200

> reassignment behaviour problems.

Note: I no longer request it.  The IPWAVE WG has declared consensus on 
the 64.  I retire from that draft.

> for chunks of address space for its own purposes, btw.

Does one know someone from the car industry requesting link-local addresses?

Alex

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 19 Apr 2019 23:01:06 +0000

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 

> I do not understand what do you mean by flat address space.

Flat address space means non-hierarchical, like MAC addresses.

> Then there are the interfaces to the outside of the car.  I dont really 
know what prefix to put there.

Actually, the truth is, you have just explained one reason why I think that IIDs less than 64 bits should be considered. It seems like it should be quite easy for car makers to request one /64 prefix per car. But to remain with today's ideas about SLAAC, each manufacturer can request a /56 or /48. That's one possibility. Those insisting that /48s are possible to give out freely should have no problem with such a scheme. (Me, I cringe at the egregious waste, as people invent more and more uses for IP connectivity. We also used to think that 1 MB of RAM was plentiful!)

Another possibility, somewhat less simple, is to use only ULAs inside cars. Then translate to something with a /64 prefix assigned to that car, only for all external comms. Using a prefix NAT type of device. Examples of external comms should be fewer than internal.

Yes, that is what I had in mind, although there are ways to make all inside comms hierarchical too.

Bert

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Apr 2019 01:44:47 +0200

BErt,
Thank you for the message.

I would like the AD to read these messages.

Le 20/04/2019 à 01:01, Manfredi (US), Albert E a écrit :
> -----Original Message----- From: Alexandre Petrescu
> <[email-masked]>
> 
> Actually, the truth is, you have just explained one reason why I
> think that IIDs less than 64 bits should be considered. It seems like
> it should be quite easy for car makers to request one /64 prefix per
> car. But to remain with today's ideas about SLAAC, each manufacturer
> can request a /56 or /48. That's one possibility. Those insisting
> that /48s are possible to give out freely should have no problem with
> such a scheme. (Me, I cringe at the egregious waste, as people invent
> more and more uses for IP connectivity. We also used to think that 1
> MB of RAM was plentiful!)
> 
> Another possibility, somewhat less simple, is to use only ULAs inside
> cars. Then translate to something with a /64 prefix assigned to that
> car, only for all external comms. Using a prefix NAT type of device.
> Examples of external comms should be fewer than internal.

We do use ULA space inside the vehicles.

We do not use NAT translation from inside to outside of vehicle, because 
NAT translation is additional software to configure, check presence, 
make sure it works on embedded, etc.  Instead, we use IP routing.

That said, it is highly likely in the near future to use NAT66 for 
connecting the car's LTE connection.  Some LTE operator did provide 
prefix delegation but Qualcomm blocks it; Qualcomm claims, as the WG 
seems to claim too, that 64 is the Internet design (64) and hence block 
DHCP port 547 because 64 and SLAAC are the Internet design; other chip 
manufacturers block multicast, because IPv4 does not rely on 
multicast[*].  In the future closer to now, the RSU connected to 
Internet will also do NAT66 because of the same reason.
[*]: these are these manufacturers oppinions, not mine.

That 64 is something that the AD and the IPWAVE WG and many other people 
agree is the thing to do.  I do not.

> inside comms hierarchical too.

YEs.  But there is no way to bridge the out-of-the car to the inside of 
the car.  Neither bridging LTE to Ethernet, nor bridging OCB (a kind of 
WiFi) to Ethernet can work. (brctl command issues errors on these, even 
though it works for WiFi-Ethernet).

Absent that bridging it's hard to make a flat address space, because 
there must be routing.  Routing in a flat address space (route between 
two prefixes of equal len and equal value) does not work: one does not 
know where to put a packet.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Sat, 20 Apr 2019 12:48:43 +0200

>But to remain with today'
>s ideas about SLAAC, each manufacturer can request a /56 or /48. That's one po
>ssibility. Those insisting that /48s are possible to give out freely should ha
>ve no problem with such a scheme. (Me, I cringe at the egregious waste, as peo
>ple invent more and more uses for IP connectivity. We also used to think that 
>1 MB of RAM was plentiful!)

In these discussions, I always strikes me as weird that very cheap wifi
devices comes with its own unique 48-bit MAC, but somehow as an internet
community we can't assign a /48 to a car.

Of course this a RIR policy. If the RIRs are fine, then it is not something
for the IETF to worry about. If the RIR show projections that 2000::/3 is
running out faster then expected and they can't do anything because of the 
64-bit boundary, then it clearly becomes an IETF issue. I can see if I can
ask for 2000::/3 run out projections. 

There is another angle, does the car manufacturer give each car a unique 
/48 which the car will then continuously broadcast? That may have some
privacy implications. Most likely a car gets a /48 from the 3GPP SIM that
will be installed somewhere in the car. And car-to-car communication will
use pseudo-random identifiers to avoid tracking.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 20 Apr 2019 22:50:07 +0200

In your letter dated Sat, 20 Apr 2019 13:38:24 -0700 you wrote:
>At 03:48 AM 20-04-2019, Philip Homburg wrote:
>There are five RIRs.  Are you referring to a policy which is common 
>to all regions?

The five RIRs have their own policies. However those policies are not
wildly different. For example, I'm not aware of a policy that would force an
ISP to provide a customer with just one /64. So in general we can assume
that RIR policies allow customers to receive as many /64s as they need.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 23 Apr 2019 23:46:14 -0400

I think from an IETF perspective with the IANA RIR's and the 2000::/3
running out of addresses  which I had not heard or though that would happen
during my lifetime --  I wonder if its even possible entertain that we
change the 64 bit station id field for future generations of IPv6 devices
so they are not bound by the EUI64 64 bit field so we can give back more
bits to the network prefix.

The 64 bit station-id came out decades ago 1998 and alot has changed and I
IoT is booming and just  about everything imaginable will have an IPv6
address space but even then I think the 64 bit boundary is a bit much.

Alexandre

Do we have any plans to possibly change the IPv6 addressing 64 bit boundary
created for EUI64 station-id device requirements?

Gyan

-- 
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Apr 2019 15:22:12 +1000

On Wed., 24 Apr. 2019, 13:46 Gyan Mishra, <[email-masked]> wrote:

> running out of addresses

Citation?

  which I had not heard or though that would happen during my lifetime --
> I wonder if its even possible entertain that we change the 64 bit station
> id field for future generations of IPv6 devices so they are not bound by
> the EUI64 64 bit field so we can give back more bits to the network prefix.
>
> Do we have any plans to possibly change the IPv6 addressing 64 bit
> boundary created for EUI64 station-id device requirements?
>
> Gyan
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 24 Apr 2019 11:29:18 +0200

>bits to the network prefix.

To start with EUI-64, that has been replaced with pseudo-random IIDs already.
See RFC-7217, RFC-8064.

So it would be possible to specify other IID lengths. Though obviously that
would leave nodes that only do EUI-64 behind.

I think there are two ways to look at 2000::/3. One is that there is plenty
of space. We don't have to worry about cars, IoT, etc. In that situation we
should keep the 64-bit boundary, keep recommending /48, etc. 

On the other hand, if we do expect to run out of 2000::/3 in a couple of
decades, then it may be worth changing some parameters. We could for
example have an allocation policy for 4000::/3 where customers get a /64
and number subnets with /80. 

What would be bad in my opinion, is to introduce all kinds of complexity
to conserve address space when we have plenty.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 16:27:44 +0200

Le 20/04/2019 à 12:48, Philip Homburg a écrit :
>> But to remain with today' s ideas about SLAAC, each manufacturer
>> can request a /56 or /48. That's one po ssibility. Those insisting
>> that /48s are possible to give out freely should ha ve no problem
>> with such a scheme. (Me, I cringe at the egregious waste, as peo 
>> ple invent more and more uses for IP connectivity. We also used to
>> think that 1 MB of RAM was plentiful!)
> 
> In these discussions, I always strikes me as weird that very cheap
> wifi devices comes with its own unique 48-bit MAC, but somehow as an
> internet community we can't assign a /48 to a car.

YEs I agree.  IT strikes me too.

> Of course this a RIR policy. If the RIRs are fine, then it is not
> something for the IETF to worry about. If the RIR show projections
> that 2000::/3 is running out faster then expected and they can't do
> anything because of the 64-bit boundary, then it clearly becomes an
> IETF issue. I can see if I can ask for 2000::/3 run out projections.
> 
> There is another angle, does the car manufacturer give each car a
> unique /48 which the car will then continuously broadcast?

There are two things here.

In IPv4, the car manufacturers I was exposed to like to put the same
192.168 in each car and behind a NAT.  (note that 'car manufacturers'
are actually using expertise from elsewhere).  It's not like 192.168.1
in car1, 192.168.2 in car2 and so on.  No, they all have same addresses.

In IPv6 there are tendencies.  Because of the IPv4 background, one
tendency is to do the same in IPv6.  That leads to ULA - same ULA in
each car of a manufacturer.  There is also tendency of distinct ULA per
car, but it is newer and hard to accept.

> That may have some privacy implications.

There already huge privacy risks with connected cars, except that few
people doing these connected cars are aware.

For example, all cars continously broadcast messages.  These messages
are almost always in clear.  The MAC addresses are there visible.

> Most likely a car gets a /48 from the 3GPP SIM that will be installed
> somewhere in the car.

Sigh - if only it were that it would be so great.

The SIMs installed in cars rarely get IPv6.  The ones that do, get a
/64, not a /48.

That is a huge problem: the 'car manufacturers', using expertise from
the communications-inclined, get only one /64 that is hard to use in a
car with multiple subnets.

The concept is this: the car is like a smartphone, so the car does what
the smartphone does.  The smartphone does IPv4 tethering, so why not the
car does also IPv6 tethering.

> And car-to-car communication will use pseudo-random identifiers to
> avoid tracking.

To check.

But the V2V with IPv6 that I know of does not use the prefix obtained
from cellular.

Alex