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

[Owen DeLong <[e-mail]>]

>> 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.
> 

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.

>>   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).

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

>>   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?
> 

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 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.
> 

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.

>>   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.
> 

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


>>   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.

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.

> 
>> 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.

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.

>> 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.
> 

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.

>> 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.
> 

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

Owen