Autonomous System (AS) Reservation for Private Use
draft-ietf-idr-as-private-reservation-05

[Ballot comment]
Converting to a comment, Stuart will address.


While I recognize the 4 byte asn is some 4 billion ASNs the notion that the reservation should be 94 million ASNs seems a bit excessive. I also realize that has been discussed in some detail in the process of getting to this point.

----------------------

The operational considerations section does not discuss the interaction between 4 byte private ASNs and 2 bytes speakers that only see AS_TRANS. While 4 byte capable participants/networks will readily be able to distinguish private ASNs via simple policy filters. Two byte bgp speakers are blind to them If I recall. The could result in either unintentional or deliberate mischef.

I do not believe that the must  in the first sentence can be enforeced by a two byte speaker.

  If Private Use ASNs are used and prefixes are originated from these
  ASNs, which are destined to the Internet, Private Use ASNs MUST be
  removed from the AS_PATH before being advertised to the global
  Internet.

[Ballot comment]
It would be nice if the operational considerations gave stronger advice about the use of AS_PATH filtering to mitigate the leakage of these private use ASNs onto the internet. I suppose people reading the document probably already know what to do, though, so I'm not insisting on this change--I'd just like to point out that the advice is perhaps more gentle than is warranted.

[Ballot comment]
Private use IPv4 addresses resulted in the AS112 project (RFC 6304).  Is something similar needed for private AS #s that are leaked to the internet?

On Adrian's point, I went and looked in RFC 1930 and it doesn't really say what bad things can happen.  The contents of that security consideration section are as follows:

  There are few security concerns regarding the selection of ASes.

  AS number to owner mappings are public knowledge (in WHOIS), and
  attempting to change that would serve only to confuse those people
  attempting to route IP traffic on the Internet.

Whatever bad thing can happen is mitigated by the MUST NOT be advertised, but maybe some words about what bad things can happen if they are leaked would be warranted - especially now that you're reserving so many more #s.

[Ballot discuss]
The operational considerations section does not discuss the interaction between 4 byte private ASNs and 2 bytes speakers that only see AS_TRANS. While 4 byte capable participants/networks will readily be able to distinguish private ASNs via simple policy filters. Two byte bgp speakers are blind to them If I recall. The could result in either unintentional or deliberate mischef.

I do not believe that the must  in the first sentence can be enforeced by a two byte speaker.

  If Private Use ASNs are used and prefixes are originated from these
  ASNs, which are destined to the Internet, Private Use ASNs MUST be
  removed from the AS_PATH before being advertised to the global
  Internet.

[Ballot comment]
While I recognize the 4 byte asn is some 4 billion ASNs the notion that the reservation should be 94 million ASNs seems a bit excessive. I also realize that has been discussed in some detail in the process of getting to this point.

[Ballot discuss]
The operational considerations section does not discuss the interaction between 4 byte private ASNs and 2 bytes speakers that only see AS_TRANS. While 4 byte capable participants/networks will readily be able to distinguish private ASNs via simple policy filters. Two byte bgp speakers are blind to them If I recall. The could result in either unintentional or deliberate mischef

[Ballot comment]
Good work, thanks.

Would be nice if section 7 supplemented what it says with a pointer to where the security considerations for private use AS numbers are to be found.

[Ballot comment]
The value 94,967,295 appears odd to me, I expected a
power of 2, but maybe that's just my binary-bias and I'm
not decimal-diverse enough;-)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-as-private-reservation-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have a comment about the Note to IANA for this document.

We understand that, upon approval of this document, there are two actions which we must complete.

First, in the 16-bit Autonomous System Number registry located at:

http://www.iana.org/assignments/as-numbers

the range 64512 - 65534 inclusive has been designated for private use. The reference for this registration will be updated to [ RFC-to-be ].

Second, in the 32-bit Autonomous System Number registry located at:

http://www.iana.org/assignments/as-numbers

a new range of contiguous AS numbers will be designated for Private Use with the reference set to [ RFC-to-be ]. IANA notes that the authors have suggested the range should be of size 94,967,295 and that the range should be from 4200000000 to 4294967294.

Comment: the following is being marked as a "Note" in the IANA
Considerations section:

[Note to IANA, NOT for publication: The IANA should update the "16-
bit Autonomous System Numbers" registry to reference this RFC (when
published) for the existing Private Use reservation. Further, to
maintain consistency from an operator standpoint, it is suggested
that the end of the "32-bit Autonomous System Numbers" range be
reserved for Private Use, and a size of 94,967,295 (value to replace
TBD1 below) is suggested corresponding to the range of 4200000000
(value to replace TBD2 below) to 4294967294 (value to replace TBD3
below).]

Since this document should be included in the registry for both
sub-registries, "16-bit Autonomous System Numbers" and "32-bit
Autonomous System Numbers", the above text can be included in
the IANA Considerations section for clarity, rather than marking
the "actions: as "Note to IANA".  Specifically,  a contiguous block
of AS numbers and the Private Use range (4200000000 to 4294967294)
should be specified in the following text in section 6:

/snip/
IANA has also reserved, for Private Use, a contiguous block of TBD1
  Autonomous System numbers from the "32-bit Autonomous System Numbers"
  registry, namely TBD2 - TBD3 inclusive.

/snip/

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Autonomous System (AS) Reservation for Private Use) to Best Current Practice


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Autonomous System (AS) Reservation for Private Use'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the reservation of Autonomous System numbers
  (ASNs) that are for Private Use only and MUST NOT be advertised to
  the Internet, known as Private Use ASNs.  This document enlarges the
  total space available for Private Use ASNs by documenting the
  reservation of a second, larger range and updates RFC 1930 by
  replacing Section 10.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/ballot/


No IPR declarations have been submitted directly on this I-D.