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

From: Dino Farinacci <[email-masked]>
Date: Tue, 19 Feb 2013 09:12:11 -0800

Sorry I am late on this thread. I just joined the list and read the discussion on this draft. Here are my comments from a LISP perspective. I am cross posting to the LISP WG mailing list.

Your draft text comes first indented and my comments follow.

> Network Working Group                                            M. Levy
> Internet-Draft                                        Hurricane Electric
> Intended status: Informational                               M. Pounsett
> Expires: July 28, 2013                                           Afilias
>                                                         January 24, 2013
> 
> 
>    A mechanism to allocate IPv6 blocks for BGP networks based on the
>                            networks AS Number
>           draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt

We have been discussing in the LISP WG the allocation of a coarse IPv6 prefix for the use of Provider Independent EID prefixes.

> Abstract
> 
>    This document provides a methodology for automatically allocating
>    IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] and
>    are either single-homed or multi-homed [BARBER2011].  The automatic
>    allocation is taken from a specific /16 block assigned by IANA for
>    this purpose.
> 
>    Networks that require more than this single /48 can still request
>    additional allocations via the existing RIR process.  Networks are
>    not forced to use this allocation and can ignore this completely.
>    Availability of the /48 assignment via this mechanism does not change
>    existing mechanisms for obtaining IPv6 assignments through the
>    existing RIR (Regional Internet Registry) or LIR (Local Internet
>    Registry) mechanisms.

This is a good idea PROVIDED these prefixes are not injected into the core routing system.

> 1.  Introduction
> 
>    IPv6's massive address space provides a wonderful opportunity to
>    radically change the process of IP address allocation.  Presently
>    IPv6 allocation is the same process as used by the IPv4 world.  The
>    RIRs allocate IPv6 address blocks based on member requests and their
>    space requirements.  A minimum allocation of a /48 is believed to be
>    sufficient to start any enterprise in the world of IPv6.

Or a small set of devices that plan to be mobile. Where they do not want to reallocate addresses when they move.

> 2.  Defining the /48 address
> 
>    The /48 address is allocated using a fixed pattern.
> 
> 
>    ASN-based address assignment
>    +----------+--------------------+-----------------/ /------------+
>    | IANA /16 |     32 bit ASN     |   80 bits for IPv6 /48 space   |
>    +----------+--------------------+-----------------/ /------------+

This is similar in concept to the GLOP space we allocated for IPv4 multicast addresses. What we said is that anyone could join a group with a ASN-based address. That is, they did not have to own it.

Can the authors tell me if someone who owns such a prefix, will they be allowed to use and reallocate for any general purpose to other entities/organizations?

>    The sum of the bits in the IANA allocated /16 prefix plus the 32 bits
>    of the ASN plus the /48 of user defined usage adds up to 128 bits.
> 
>                       +------+----------------------+
>                       | Bits |                Usage |
>                       +------+----------------------+
>                       |   16 | IANA provided prefix |
>                       |   32 |                  ASN |
>                       |   80 |         User defined |
>                       |  128 |                TOTAL |
>                       +------+----------------------+
> 
>                         Table 1: Address space math

Can there be some ASN values assigned to signify "no one owns the /48"? So we can have even more independent assignments. For the purposes of LISP, we don't care if these address don't perfect aggregate because these addresses will go into the LISP mapping database system which may not need to aggregate since the RLOCs associated with the prefixes will be different anyways (and therefore can't aggregate or compress).

>    The end network can allocate out of the assigned /48 as needed.  It
>    is assumed that the end network will use this allocation for global
>    routing; however the network may choose to not announce this
>    allocation.

Okay, so lets use an example to see how this can be used. Let's say a /80 comes out of Verizon's space:

(1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and Ford so they can use Vehicle ID Numbers for the rest of the allocation for their automobile EID assignments?

(2) Or do the RIRs believe they need to assign a /48 with distinct ASNs to each of BMW, Mercedes and Ford so they have more bits to embed VIN numbers?

(3) What if these auto manufactures don't want to allocate ASN numbers because they will never have any intent to run BGP either in the cars, POPs, data centers?

>    If any route is announced from this allocation, any prefixes more
>    specific than the allocated /48 must not be propagated in to the
>    global IPv6 routing table.  This is to prevent the IPv6 routing table

This is fine authors, but if you are multi-home, it will require each system at the site to possess multiple addresses one from each attached ASN if they do not have their own prefix but get it out of their provider.

If you say that this prefix will never be associated with a provider's attachment point, then I'm okay with that and agree.

>    from becoming too large.  Therefore, a site which uses this
>    allocation MUST NOT advertise a more specific than the allocated /48
>    routing prefix.  All native IPv6 network operators MUST filter out
> 
> 
> 
> Levy & Pounsett           Expires July 28, 2013                 [Page 3]
> Internet-Draft  Auto allocation mechanism for IPv6 blocks   January 2013
> 
> 
>    and discard any routing prefix advertisements longer than /48 from
>    within this /16 allocation.

Can you explicitly state then that this prefix for use as a PROVIDER INDEPENDENT prefix. Thanks.

> 3.  IANA allocated /16
> 
>    IANA is to allocate a /16 in a similar manner to the 2002::/16
>    allocation for 6to4 [RFC3068] which is used by the 6to4
>    protocol[RFC3056]..  No IPv4 allocation by IANA is required.

But in this case there is no implicit assumption about mapping to anything else with a bit-by-bit algorithm but rather an advertisement or another network-based mapping data structure. Correct?

>    ASNs are normally expressed as human-readable decimal numbers; yet
>    for this allocation the number should be converted into a hexadecimal
>    notation.  All IPv6 addresses are written in hexadecimal.  (NNNN
>    represents the /16 allocation by IANA)
> 
>        +----------------+--------------------+---------------------+
>        | ASN in decemal | ASN in hexadecimal |     Sample IP block |
>        +----------------+--------------------+---------------------+
>        |            AS1 |                  1 | NNNN:0000:0001::/48 |
>        |         AS6939 |               1B1B | NNNN:0000:1B1B::/48 |
>        |        AS29001 |               7149 | NNNN:0000:0001::/48 |
>        |       AS393220 |              60004 | NNNN:0006:0004::/48 |
>        +----------------+--------------------+---------------------+

What we had found in the old days of NSAP deployment (OSI) that encoding IPv4 addresses in BCD format in a hexadecimal longer address was extremely useful for management. And as we have seen for IPv6, even embedding IPv4 dotted decimal format was extremely useful.

Rather than having to build tools and make vendors do UI work, can we have some form of BCD format for AS number. I know this will be difficult for a 32-bit number but we could make it work for the ASNs that are <= 65535. Just a thought. But even 10 million ASNS would only take up to 8 nibbles. And since we won't and can't aggregate ASNs there is no point in making the encoding a power-of-2 value.

> 5.  ASN allocation
> 
>    ASNs are allocated by RIRs and this RFC does not handle that arena.
> 
>    ASNs defined as private ASNs MUST NOT use this scheme.  The special
>    16-bit ASN 23456 MUST NOT use this scheme.

I would let users do this with private ASes if they want to. Set a local/global bit in your encoding so they can use it. If you don't they will steal ASN numbers which they should not do but will.

> 6.  BGP Filtering and Validation
> 
>    Filtering would be a simple case of mapping the final ASN in a path
>    to the prefix in an exact bit-order match.
> 
>    For example; the prefix NNNN:0000:1B1B::/48 should only be seen as
>    announced from AS6939 (6939 equals 0x1B1B in hex).  Networks would
>    have their upstream transit providers add this /48 prefix to their
>    existing inbound BGP route filters.

IMO, these addresses should stay out of underlying routing. If you want to build a mobile Internet for IPv6, these sort of addresses are identity addresses and not topological.

Let's not perpetuate the non-sense of the past.

> 10.  Routing Table Impact
> 
>    This mechanism is not expected to have any impact to the global
>    Internet routing table since existing policies in the RIR system
>    already readily provide for the allocation of provider-independent
>    IPv6 prefixes.  Additionally, AS number holders are likely to be
>    multihomed entities which were going to be independently routed in
>    any case.  Service Providers are, as always, not obligated to route
>    these IPv6 assignments and/or may establish conditions of service
>    which offset any additional routing cost.

I would say it would have the same impact as PI prefixes do today.

> 14.2.  Informative References

You may, not sure, but may want to add these as possible informative references:

draft-ietf-lisp-eid-block
draft-iannone-lisp-eid-block-mgmnt

>    Martin J. Levy
>    Matthew Pounsett

Thanks for coming out with this,
Dino

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 Feb 2013 18:07:00 +0000

> This is a good idea PROVIDED these prefixes are not injected into the

I don't think that this is a realistic expectation.  If people get blocks
of this form, they will turn up in the dfz for sure.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Tue, 19 Feb 2013 12:34:58 -0800

> This is a good idea PROVIDED these prefixes are not injected into the core routing system.

The prefixes should not be automatically injected, but I think prohibiting such
injection would decrease the utility of this addressing and that there is no good
reason to have such a prohibition.

> Can there be some ASN values assigned to signify "no one owns the /48"? So we can have even more independent assignments. For the purposes of LISP, we don't care if these address don't perfect aggr…

Wouldn't the private ASN range already effectively do this?

> (1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and Ford so they can use Vehicle ID Numbers for the rest of the allocation for their automobile EID assignments?

First of all, you can't pull a /64 out of a /80 so I think you mean a /48 assigned to $PROVIDER.

In that case, I see no reason $AUTO_MAKER1, $AUTO_MAKER2, etc. could not receive /64s from $PROVIDER for that purpose, but, I would propose that such use is not a very good idea from the auto maker's perspective. Once you embed one of these addresses into an automobile and sell it, you are locked into a contract with Verizon until you can readdress all such cars.

> (2) Or do the RIRs believe they need to assign a /48 with distinct ASNs to each of BMW, Mercedes and Ford so they have more bits to embed VIN numbers?

I don't believe that the RIRs are involved in the addresses contemplated under this draft.

I think permanently assigned addresses related to VINS are, in general, a bad idea. I don't see any advantage to tying the semantics of the two systems to each other. If anything, the development of LISP is the result of failing to separate the semantics of end-point addressing from the semantics of topological location. Combining the semantics of end-point addressing and VINs seems even more far-fetched to me.

> (3) What if these auto manufactures don't want to allocate ASN numbers because they will never have any intent to run BGP either in the cars, POPs, data centers?

I don't see anything in this draft that would preclude them from using a different source of addressing.

I confess, to some extent, I wonder if this is a solution in search of a problem.

> If you say that this prefix will never be associated with a provider's attachment point, then I'm okay with that and agree.

Either I misunderstand what you are saying, or, you have erred. I'm not sure which.

If a site uses a /64 from within this /48 to attach to each upstream, the more specific does not need to propagate beyond the immediate upstream router, so it still wouldn't be announced into the global routing table.

> Can you explicitly state then that this prefix for use as a PROVIDER INDEPENDENT prefix. Thanks.

I think that is inherent in the definition of the prefix. Can you clarify why you think this
statement is necessary?

> Rather than having to build tools and make vendors do UI work, can we have some form of BCD format for AS number. I know this will be difficult for a 32-bit number but we could make it work for the…

I would oppose doing this. If we are going to do this (and I'm not entirely convinced that we should, but also not opposed), we should support the full ASN space and doing so as a bit field is fine. I don't think any UI work is required. Tools to convert 32-bit numbers from decimal to hex are already widely available and the process is well understood. It's not like anyone will have to do this conversion on a daily basis.

perl -e 'printf "%08x\n", <as_number_in_decimal>' will solve the problem, for example.

> I would let users do this with private ASes if they want to. Set a local/global bit in your encoding so they can use it. If you don't they will steal ASN numbers which they should not do but will.

What local/global bit?

Institution of a local/global bit would require a /15 instead of a /16. I'm not convinced that this is worthy of 1/65536 of the IPv6 address space, let alone 1/32768.

> Let's not perpetuate the non-sense of the past.

I don't see any reason to limit these addresses to that single use case.

For example, assume an SMB organization that just wants to use these addresses for general multi homed connectivity. In this case, they would only need to obtain an ASN. They would not need to apply for a prefix, they could simply advertise this one.

> I would say it would have the same impact as PI prefixes do today.

Which means that this has no impact because it doesn't change the impact vs. the current PI impact.

Owen

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 19 Feb 2013 15:02:34 -0800

> Wouldn't the private ASN range already effectively do this?

I'm asking the intent of the authors.

> First of all, you can't pull a /64 out of a /80 so I think you mean a /48 assigned to $PROVIDER.

Yes, I mistyped.

> I think permanently assigned addresses related to VINS are, in general, a bad idea. I don't see any advantage to tying the semantics of the two systems to each other. If anything, the development o…

An EID is opaque and not used by the protocol stack just by humans if they choose to look at them. 

> I confess, to some extent, I wonder if this is a solution in search of a problem.

I know there are customers that want to reduce the number of total databases they have to manage at all layers of the stack.

> If a site uses a /64 from within this /48 to attach to each upstream, the more specific does not need to propagate beyond the immediate upstream router, so it still wouldn't be announced into the g…

There is still PI flat routing on the scale of number of sites that use this prefix. That is the point, there is no attempt to improve the route table scaling problem. I'm not saying this draft should, just speaking generally.

> I think that is inherent in the definition of the prefix. Can you clarify why you think this

I want it explicit so there is no layers of ownership of the prefix.

> perl -e 'printf "%08x\n", <as_number_in_decimal>' will solve the problem, for example.

Multiply by 1000 products coming out over different delivery times. Don't underestimate the slowness of vendors.

>> I would let users do this with private ASes if they want to. Set a local/global bit in your encoding so they can use it. If you don't they will steal ASN numbers which they should not do but will.

Add one is the suggestion.

> Which means that this has no impact because it doesn't change the impact vs. the current PI impact.

You miss the point. The problem needs to be solved. Saying this draft doesn't worsen it is not panacea.

Dino

---

From: Owen DeLong <[email-masked]>
Date: Tue, 19 Feb 2013 17:09:52 -0800

> An EID is opaque and not used by the protocol stack just by humans if they choose to look at them. 

One of us is misunderstanding the other. My point is that using IPv6 address space to number things that are not IPv6 hosts is, IMHO, a bad idea.

> I know there are customers that want to reduce the number of total databases they have to manage at all layers of the stack.

All well and good, but I do not support turning IPv6 addresses into the primary key for everything in world anyone wants to identify in any namespace. If that's not what your sentence above means, then I'm afraid I misunderstand your meaning.

Again, I do not support the idea of using IPv6 numbers as a mechanism for identifying anything that isn't an IPv6 host and I do not support tying semantics other than the host end-system identifier for packet delivery to IPv6 addresses. I think that past experience has demonstrated that both of these practices create more problems than they solve.

> There is still PI flat routing on the scale of number of sites that use this prefix. That is the point, there is no attempt to improve the route table scaling problem. I'm not saying this draft sho…

I think that concern is entirely orthogonal to this draft. My point is that for every PI
prefix that gets advertised from this space, it should represent a PI prefix from RIR
space that does not get advertised, so it is a net equivalence in terms of the
routing table. Thus, I would anticipate that this draft has no impact on the routing
table.

OTOH, the whole way we do IDR is broken and we should have fixed it as part
of the IPv6 development process. Unfortunately, we (IETF) chose to punt on that and
go down all kinds of other less important roads. However, this issue is really
not part of the discussion of this draft.

> I want it explicit so there is no layers of ownership of the prefix.

I'm not sure how stating that this prefix is PROVIDER INDEPENDENT conveys any ownership or lack thereof.

> Multiply by 1000 products coming out over different delivery times. Don't underestimate the slowness of vendors.

I'm not sure what you mean by this. Why would products coming out receive AS Numbers? I think you are pursuing a use case that is not intended under my interpretation of this draft and taking it to extremes that are beyond my comprehension.

> Add one is the suggestion.

I expected that's where you were going. I think 16 bits is already a rather short prefix for this use case. I don't believe that there is a sufficient use case for a local/global bit. If you do, you need to make a better case for it than the above.

I would propose modifying section 5 of the draft to state, instead of "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any prefixes within the prefix allocated for this purpose must be considered "LOCAL addresses and given similar semantics to RFC-1918".

I would not give the the semantics of ULA because of the likelihood of overlap.

> You miss the point. The problem needs to be solved. Saying this draft doesn't worsen it is not panacea.

You miss the point. This draft is not intending to solve that problem and makes no claim in that respect.

I agree the problem needs to be solved. However, Solving the problem isn't even within the purview of the v6ops working group. Raising it as an issue in the discussion of this draft is only relevant to the extent that this draft makes the problem worse or prevents any proposed solution to the problem from being effective. Since neither of those applies, there are no routing table considerations applicable to this draft IMHO.

Owen

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 19 Feb 2013 18:16:41 -0800

> One of us is misunderstanding the other. My point is that using IPv6 address space to number things that are not IPv6 hosts is, IMHO, a bad idea.

The automobiles are IPv6 hosts. 

> All well and good, but I do not support turning IPv6 addresses into the primary key for everything in world anyone wants to identify in any namespace. If that's not what your sentence above means,…

It is none of your business how sites use their addresses. That is the whole point of ID/Locator separation. 

The EID is opaque to the network but may have meaning to the sites who communicate with each other within that EID-prefix. 

> Again, I do not support the idea of using IPv6 numbers as a mechanism for identifying anything that isn't an IPv6 host and I do not support tying semantics other than the host end-system identifier…

See above. Tell me if you still disagree and if so we will have to disagree. This is where IPv6 could be useful. What does IPv6 have that IPv4 doesn't? Really only longer addresses. 

> routing table. Thus, I would anticipate that this draft has no impact on the routing

Okay fine. 

> not part of the discussion of this draft.

If locator/ID separation is used then this is helped and you make multi-homing  easier at the same time as making address management in every host. 

Look how complicated the home networking proposals are?

> I'm not sure how stating that this prefix is PROVIDER INDEPENDENT conveys any ownership or lack thereof.

Never mind - bit worth arguing the point. 

> I'm not sure what you mean by this. Why would products coming out receive AS Numbers? I think you are pursuing a use case that is not intended under my interpretation of this draft and taking it to…

I mean each product would have to build a hex to decimal conversion capability in their UI. 

> I expected that's where you were going. I think 16 bits is already a rather short prefix for this use case. I don't believe that there is a sufficient use case for a local/global bit. If you do, yo…

Well explicitly encoding that the intent of the address is local is a good thing IMO. 

> I would propose modifying section 5 of the draft to state, instead of "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any prefixes within the prefix allocated for this purpose mus…

Sounds good. 

> You miss the point. This draft is not intending to solve that problem and makes no claim in that respect.

I understand that and I'm not saying the spec should fix it. I was replying to your comment only. 

> 
> I agree the problem needs to be solved. However, Solving the problem isn't even within the purview of the v6ops working group. Raising it as an

I realize that.  But not let's process get in the way of having an open dialogue. 

> issue in the discussion of this draft is only relevant to the extent that this draft makes the problem worse or prevents any proposed solution to the problem from being effective. Since neither of those applies, there are no routing table considerations applicable to this draft IMHO.
> 
> Owen

Fine. Thanks for listening. 

Dino

---

From: Owen DeLong <[email-masked]>
Date: Tue, 19 Feb 2013 18:50:02 -0800

> The automobiles are IPv6 hosts. 

It is unlikely that any network will ever be {all vehicles with VIN is a member of [RANGE]} other than possibly a brief factory test.

Thus, I do not believe it is appropriate to permanently associate a prefix with a collection of vehicles based on their VIN.

> The EID is opaque to the network but may have meaning to the sites who communicate with each other within that EID-prefix. 

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.

> See above. Tell me if you still disagree and if so we will have to disagree. This is where IPv6 could be useful. What does IPv6 have that IPv4 doesn't? Really only longer addresses. 

I disagree, but at least I now fully understand what you're trying to inflict on the world.

As to the answer to your other question:

SLAAC
6-lowpan
Improved header structure
Extension headers
Cleaner IPSEC implementation

I'm sure there's more, but I don't want to get too far down yet another orthogonal discussion.

> If locator/ID separation is used then this is helped and you make multi-homing  easier at the same time as making address management in every host. 

At the price of converting every connection into a tunnel with associated MTU penalties.

A better solution (IMHO) would be to have a 32 bit field added to the protocol to contain the destination ASN embedded in the packet header. Unfortunately, this is a major change to every system and would basically be the next protocol version (though at least IPv6 and IPv{N} would be interchangeably compatible with each other except for the MTU issues).

> Look how complicated the home networking proposals are?

Agreed, it's ridiculous. We should, instead, recognize that we dropped the ball in IPv6 design and do something slightly different before the routing table explodes. We have several years beyond IPv6 deployment to address that issue, IMHO. For now, I'd rather focus on actual operational issues related to IPv6 deployment and revisit solving the routing table problem later.

> I mean each product would have to build a hex to decimal conversion capability in their UI. 

1.	Libraries already contain these and nobody is hand-coding systems in assembly language any more.
2.	This is seriously not difficult and most products duplicate enough UI components from other products
	that it would rapidly become a boilerplate component in the developer tool kit at each organization if
	it hasn't already.

> Well explicitly encoding that the intent of the address is local is a good thing IMO. 

Which I believe my suggestion below would cover...

>> I would propose modifying section 5 of the draft to state, instead of "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any prefixes within the prefix allocated for this purpose mu…

Zero bit cost here. 

Owen

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 19 Feb 2013 19:20:37 -0800

> A better solution (IMHO) would be to have a 32 bit field added to the protocol to contain the destination ASN embedded in the packet header. Unfortunately, this is a major change to every system an…

Right - a non-starter. 

LISP is certainly not a non-starter. More specifically, it is a incremental-starter. 

If you want to find out, get on the LISP pilot network. See www.lisp4.net, err I mean www.lisp6.net for you. :-)

Dino

---

From: Bill Jouris <[email-masked]>
Date: Wed, 20 Feb 2013 14:20:46 -0800 (PST)

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
831-659-8360
925-855-9512 (direct)

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Feb 2013 17:45:10 -0800

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 <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 21 Feb 2013 04:44:31 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Owen DeLong
Sent: Wednesday, February 20, 2013 8:45 PM
To: Bill Jouris
Cc: [email-masked]
Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn

Bill

Owen

On Feb 20, 2013, at 14:20 , Bill Jouris <[email-masked]<mailto:[email-masked]>> wrote:

Owen,

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 <[email-masked]<x-msg://10939/mc/compose?to=[email-masked]>> wrote:

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 20 Feb 2013 23:22:12 -0800

On 2/20/13 2:20 PM, Bill Jouris 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.
>
The assignment of global unicast v6 addresses to Registries, LIRs, 
service providers and direct assignments is done elsewhere.

We have examples of aircraft and other large structures such as 
airports/tunnels and buildings receiving prefixes from their 
manufacturers which had originally been obtained from RIRs.
> 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
> 831-659-8360
> 925-855-9512 (direct)
>
>
>     > On Feb 19, 2013, at 5:09 PM, Owen DeLong <[email-masked]
>     </mc/compose?to=[email-masked]>> wrote:
>
>
>     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.
>
>
>
>

---

From: Ray Hunter <[email-masked]>
Date: Thu, 21 Feb 2013 09:37:18 +0100

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:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Owen DeLong
> *Sent:* Wednesday, February 20, 2013 8:45 PM
> *To:* Bill Jouris
> *Cc:* [email-masked]
> *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.
>
>  
>
> On Feb 20, 2013, at 14:20 , Bill Jouris
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
> Owen,
>
> www.insidethestack.com <http://www.insidethestack.com>
> 831-659-8360
> 925-855-9512 (direct)
>
>
> <x-msg://10939/mc/compose?to=[email-masked]>> wrote:
>
>
> claiming ASNs to support this? Yeah, we could probably burn 4 billion
> ASNs that way without too much trouble.
>
> [email-masked] <mailto:[email-masked]>
> 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.
>

---

From: Bill Jouris <[email-masked]>
Date: Thu, 21 Feb 2013 06:25:24 -0800 (PST)

That being the case, wouldn't we be stepping away from the whole idea of having IPv6 addresses related to VIN numbers?  Leave it to the auto industry to figure out how they want to deal with the subject?

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Wed, 2/20/13, joel jaeggli <[email-masked]> wrote:

From: joel jaeggli <[email-masked]>
Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn
To: "Bill Jouris" <[email-masked]>, [email-masked]
Date: Wednesday, February 20, 2013, 11:22 PM

> 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…
The assignment of global unicast v6 addresses to Registries, LIRs, service providers and direct assignments is done elsewhere.

We have examples of aircraft and other large structures such as airports/tunnels and buildings receiving prefixes from their manufacturers which had originally been obtained from RIRs.
>     > On Feb 19, 2013, at 5:09 PM, Owen DeLong <[email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Feb 2013 16:22:36 +0000

On 21/02/2013 14:25, Bill Jouris wrote:
> That being the case, wouldn't we be stepping away from the whole idea of
> having IPv6 addresses related to VIN numbers?  Leave it to the auto
> industry to figure out how they want to deal with the subject?

I don't think the IETF has any competence to deal with VINs, has it?  If
the car-makers want to register an ipv6 prefix for whatever reason from
their RIR and have a 1:1 mapping between VINs and ipv6 addresses, then that
is entirely their concern but I don't see why the IETF should take any part
in this.

Nick

> 
> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com
> 831-659-8360
> 925-855-9512 (direct)
> 
> 
> --- On *Wed, 2/20/13, joel jaeggli /<[email-masked]>/* wrote:
> 
> 
>     Subject: Re: [v6ops] Comments to
>     </mc/compose?to=[email-masked]>
>     >     </mc/compose?to=[email-masked]
>     </mc/compose?to=[email-masked]>>> wrote:
>     >
>     >
>     > [email-masked] </mc/compose?to=[email-masked]>

-- 
Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698
3 Westland Square    | INEX - Internet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland    | Exchange Association    | Email: [email-masked]

---

From: Bill Jouris <[email-masked]>
Date: Thu, 21 Feb 2013 08:45:43 -0800 (PST)

Fair enough.  But in that case, the whole draft would seem to be outside our competence.  

All I'm saying is that, if the IETF is going to say anything about relating IPv6 addresses to VIN numbers, the SAE folks ought to be involved as well.

Bill 

--- On Thu, 2/21/13, Nick Hilliard <[email-masked]> wrote:

From: Nick Hilliard <[email-masked]>
Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn
To: "Bill Jouris" <[email-masked]>
Cc: [email-masked], "joel jaeggli" <[email-masked]>
Date: Thursday, February 21, 2013, 8:22 AM

Nick

>     > Owen,
>     >
>     > So what you seem to be saying is: If manufacturers want to use a
>     >
>     > If so, perhaps we should at least suggest to the SAE (Society of
>     >
>     > Bill Jouris
>     > Inside Products, Inc.
>     > www.insidethestack.com
>     > 831-659-8360
>     > 925-855-9512 (direct)
>     >
>     >
>     >     > On Feb 19, 2013, at 5:09 PM, Owen DeLong <[email-masked]
>     >     </mc/compose?to=[email-masked]
>     >
>     >
>     >     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
>     > [email-masked] </mc/compose?to=[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Feb 2013 08:52:40 -0800

The draft doesn't say anything about VIN numbers.

The draft provides a /48 for every ASN automatically by allocating a  /16 prefix to\
which the 32 bit ASN is appended.

VINs entered the discussion when someone presented an example of how this
address space might be (mis?)used.

Owen

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Feb 2013 16:59:46 +0000

On 21/02/2013 16:45, Bill Jouris wrote:
> All I'm saying is that, if the IETF is going to say anything about
> relating IPv6 addresses to VIN numbers, the SAE folks ought to be
> involved as well.

Uh, I think Dino mentioned VINs as an example plucked out of thin air for
demonstrating potential end-user applications (i.e. nothing to do with the
ietf).

Nick

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Feb 2013 09:08:20 -0800

> demonstrating potential end-user applications (i.e. nothing to do with the

It is a real user/customer requirement. IETF should not tell users how to assign their addresses. Just allow part of the address space available so they can do what they want.

I would go one step further, that providers of a service should not users how to assign their addresses. That is the whole point the user community is begging for EIDs.

Dino

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Feb 2013 17:33:11 +0000

On 21/02/2013 17:08, Dino Farinacci wrote:
> It is a real user/customer requirement. IETF should not tell users how
> to assign their addresses. Just allow part of the address space
> available so they can do what they want.

if the car makers want a new VIN bin, then they can have it.  The only
requirement for creating a new bin is a common agreement between them that
their chosen range of integers or symbols means something to them.  Whether
or not this range is a subset of an ietf-assigned ipv6 subnet is completely
irrelevant.

>From the IETF's point of view, if the car makers come to them and ask them
for a range of numbers for car VINs, my reaction would be "wut?"

Nick

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Feb 2013 09:59:25 -0800

So let's get back on track:

(1) I brought up VIN numbers because people are requesting for rather opaque addresses.
(2) I said that LISP EIDs are typically used as opaque addresses.
(3) I said the draft-mlevy-v6ops-auto-v6-allocation-per-asn is a decent encoding format for EIDs.

Nothing more was said, implied, or suggested.

Dino

---

From: Bill Jouris <[email-masked]>
Date: Thu, 21 Feb 2013 10:52:34 -0800 (PST)

Just an FYI, 6man has got not one but TWO drafts on VINs and IPv6 addresses:

1) Vehicle Identification Number-Based IPv6 Interface Identifier
(VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
Addresses (VULA), at:
http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00

It must be something in the air, that is putting the same area in everyone's heads....

Bill 

--- On Thu, 2/21/13, Dino Farinacci <[email-masked]> wrote:

From: Dino Farinacci <[email-masked]>
Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn
To: "Nick Hilliard" <[email-masked]>
Cc: [email-masked]
Date: Thursday, February 21, 2013, 9:59 AM

Dino

---

From: Randy Bush <[email-masked]>
Date: Fri, 22 Feb 2013 06:11:32 +0900

> relating IPv6 addresses to VIN numbers

this case should not arise.  this exercise indicates serious confusion
on the part of someone.

randy

---

From: SM <[email-masked]>
Date: Sat, 23 Feb 2013 22:31:40 -0800

At 17:09 19-02-2013, Owen DeLong wrote:
>One of us is misunderstanding the other. My point is that using IPv6 
>address space to number things that are not IPv6 hosts is, IMHO, a bad idea.

It's not the first time that the idea came up.  It's not because 
there is a seemingly infinite source of integers that they should be 
assigned to any thing.

Regards,
-sm