Le 04/04/2013 22:22, Manfredi, Albert E a écrit :
-----Original Message----- From: Alexandru Petrescu
[mailto:alexandru.petre...@gmail.com]
For one, homenets don't move or at least not as fast as cars. A
homenet may change its attachment every year or so, whereas a car
may change it every 10 minutes or so.
Just as a side FYI, my homenet attachment IP changes every time I
reboot the ADSL modem. So even this would not matter greatly, *if*
the unique ID of a car were a DNS entry, rather than hardcoded in the
IP address in any way.
When a homenet boots up in may need to use a Network Access Identifier
(NAI) or a MAC address maybe to request the same IP address from the
provider.
With vehicles, this would mean to make the VIN (Vehicle Identification
Number) to be that NAI - a conversion from VIN to NAI like
<VIN>@example.com.
Whereas in a homenet it may be appropriate that a DNS Server be present,
it may be less likely that a DNS Server is present in a vehicle. I
haven't seen one, but one may put one DNS Server in a vehicle.
Whereas the friendly applications are sensitive to the advice to _not_
hardcode the IP address of the Server, the preliminary yet futuristic
in-vehicle applications often hardcode the IP address of the Server.
And that for a good reason: it may be that the DNS is not reachable.
When migrating the large number of applications in a vehicle from IPv4
to IPv6 one already faces first very simple problems like what addresses
to put there, or is the IPv6 stack available for that small CPU. The
advice to _always_ use DNS is just an additional requirement on top of
others.
A DNS in a vehicle may also put significant unknowns with respect to the
DNS64 deployed by the cellular operator.
Your point about having multiple IPv6 subnets (prefixes) inside the
car is a good one. But it can be solved like it is for home nets, as
long as we don't run out of the shortened prefixes we're creating.
I agree. Some argument says that there may be little if at all risk of
running out of these shortened prefixes.
But other arguments suggest we'd better lengthen the prefix length
instead of shortening it.
Side note:
Seems to me, with new applications like these IoT concepts (which are
nothing new, but promise way more addressable hosts than we might
have expected in the 1990s when IPv6 was invented), or vehicles, that
allowing for something like 112-bit prefixes would be a good thing.
I think so too. Prefix of length 112bit could be made to to work with
SLAAC and Ethernet.
2^64 hosts on a single IPv6 subnet will probably never be supported by
any single link layer.
Also, the IoT and its keen M2M concepts often consider that they're very
small and less powerful machines in terms of CPU, yet often with more
than one IP interfaces (i.e. they're dumb Routers). These devices need
small software implementations of protocol. Yet for the simplest tasks
- get an IP address, a delegated prefix, a default route - the IPv6
landscape requires such a device to use both ND and DHCP.
This is a disconnect. The results look strange if looked at from IETF
perspective. For example, a small 'mobile IPv6 hotspot' deployed on
cellular does some things which IETF documents dont ack.
I wonder whether homenet people consider that the prefix to be delivered
to a homenet could be longer than /64 (i.e. /65 or /66).
You still get 16-bit IIDs, way more than you are likely to need in a
single in-car subnet, and you can assign the individual car a 96-bit
prefix. Giving each car the possibility of 64K subnets, while
wasting far less address space.
Makes sense to me.
I kringe at wanton waste.
Yes, seems as intentional waste.
Alex
Bert
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
