Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn

[Ray Hunter <[e-mail]>]

I have been trying hard to understand this thread and I have to admit
that the background motivation still remains opaque to me.

If I understand correctly, a car already has an L8 ID: the VIN.

Why is there any good architectural reason to tie the VIN or any other
L8 identifier to any L2 LAN hardware or L3 addressing at all?
And especially via a static mapping?

I can think of many counter-reasons. It's forbidden in Europe to use any
government assigned L8 ID associated with an individual (e.g. medical
insurance number) for any purpose other than that for which it was
specifically intended: Article 24 WBP. Vice versa is also true: you have
to keep the personal data private, so leaking personal data into L2/L3
is also a no-go. Medical ID's are especially sensitive, and fall under
the rules for processing "special personal data".

IMHO We should almost certainly explicitly tell these "multiple
industries" NOT to assume ANY link between L2/L3 and L8, or make any
assumptions about the structure of the IPv6 addressing space beyond that
documented in RFCs. If they want to have some industry-specific L8
idents for use in an application or DB, they should arrange these
themselves via an appropriate industry-specific group. If they want to
communicate industry-specific L8 ID's over a network, they should encode
these within the application-layer protocol, not in the transport layer.

regards,
RayH

Ackermann, Michael wrote:
>
> This is very similar to something we were exploring in the
> Medical/Insurance realms.   That is using IPV6 addresses for
>  entities/artifacts such as Claim or Subscriber numbers.    ARIN did
> not like that as rationale for additional or larger address space as
> alluded by Owen below.      But similar approaches are  being
> considered in multiple industries.  
>
>  
>
> Why would that be preferred over MAC & SLAAC?    Not sure at this
> point as this is still being explored.  but possibly being more
> predictable, controlled and self documenting?     
>
>  
>
> *From:*[e-mail] [mailto:[e-mail]] *On
> Behalf Of *Owen DeLong
> *Sent:* Wednesday, February 20, 2013 8:45 PM
> *To:* Bill Jouris
> *Cc:* [e-mail]
> *Subject:* Re: [v6ops] Comments to
> draft-mlevy-v6ops-auto-v6-allocation-per-asn
>
>  
>
> Bill
>
>  
>
> I think that sums it up reasonably well. However, if they come back to
> the RIR for more space and try to use having put a bunch of numbers on
> VINs/Cars addressed by VIN that are not actually networked to the
> company using a network that topologically matches the numbering
>
> scheme, then, the RIR should rightly count those addresses as not
> utilized in determining eligibility for additional space.
>
>  
>
> If you feel that some sort of recommendation to SAE is worth while, go
> for it. Personally, I don't understand the need for a car to have a
> permanently assigned prefix rather than just a MAC address and then
> get its prefix through SLAAC or get its addressing via DHCP.
>
>  
>
> If someone can explain this, I am open to being better convinced.
>
>  
>
> Owen
>
>  
>
> On Feb 20, 2013, at 14:20 , Bill Jouris
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
> Owen,
>
> So what you seem to be saying is: If manufacturers want to use a
> specific part of their company allocation of addresses to give
> addresses to the cars that they make based on VIN numbers, that is up
> to them.  But IETF should not mandate allocating part of the overall
> spectrum of addresses to them.
>
> If so, perhaps we should at least suggest to the SAE (Society of
> Automotive Engineers), which makes standards for that industry, that
> they look at whether it makes sense for all of the companies to take a
> uniform approach to how they do that.
>
> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com <http://www.insidethestack.com>
> 831-659-8360
> 925-855-9512 (direct)
>
>
> > On Feb 19, 2013, at 5:09 PM, Owen DeLong <[e-mail]
> <x-msg://10939/mc/compose?to=[e-mail]>> wrote:
>
>
> I do not support allocating globally unique prefixes for things that
> are not networks.
>
> Perhaps that will better explain my position.
>
> I think that overloading the IPv6 prefix space with semantics for
> arbitrary collections of things is a really bad idea that has
> tremendous potential to consume vast amounts of addresses while
> yielding no network benefit in return.
>
> Will it exhaust the IPv6 space immediately, probably not. Could we
> easily exhaust the ASN space if we start promoting the idea of
> claiming ASNs to support this? Yeah, we could probably burn 4 billion
> ASNs that way without too much trouble.
>
> _______________________________________________
> v6ops mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
>
>  
>
>
> The information contained in this communication is highly confidential
> and is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you
> are hereby notified that any viewing, copying, disclosure or
> distribution of this information is prohibited. Please notify the
> sender, by electronic mail or telephone, of any unintended receipt and
> delete the original message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue Cross
> and Blue Shield Association.
>