Subject: [Idr] new draft - reservation of two already reserved ASNs

From: Jon Mitchell <[email-masked]>
Date: Mon, 20 May 2013 09:02:13 -0400

IDR -

During the private asn draft process, several times it was recommended
that proper documentation of the EXISTING reservations for 65535 and
4294967295 be done, so have posted a draft to try and rectify that.
Wanted to get some initial feedback on this draft and add any
additional reasoning the group has for these reservations before
asking for WG acceptance.

Thanks,

Jon

A new version of I-D, draft-jhjm-idr-last-as-reservations-00.txt
has been successfully submitted by Jeffrey Haas and posted to the IETF
repository.

Filename:	 draft-jhjm-idr-last-as-reservations
Revision:	 00
Title:		 Last Autonomous System (AS) Reservations
Creation date:	 2013-05-16
Group:		 Individual Submission
Number of pages: 4
URL:
http://www.ietf.org/internet-drafts/draft-jhjm-idr-last-as-reservations-00.txt
Status:
http://datatracker.ietf.org/doc/draft-jhjm-idr-last-as-reservations
Htmlized:
http://tools.ietf.org/html/draft-jhjm-idr-last-as-reservations-00

Abstract:
   This document reserves two Autonomous System numbers (ASNs) at the
   end of the 16 bit and 32 bit ranges, described in this document as
   "Last ASNs" and recommends they not be used by operators.

The IETF Secretariat

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 May 2013 10:32:28 -0400

> asking for WG acceptance.

Also, to seed/head off some of the discussion, the justifications in the
draft are easy to see as thin in some cases.  IMO, we're looking for
something that will look historically reasonable but beyond that IANA would
rather just have something that says "this doc says they're reserved".
Matter of fact, we could simply publish the document and say "they're
reserved" and be done with it.

Historically, 65535 had been problematic for some implementations.  Most of
the reason for this to have been problematic was simply bad code and the
correspondence of the value with UINT16_MAX/-1 signed int16.  One would
hope that all such bugs have been banished from the Internet by now. :-)

The extension of such thin reasoning to UINT32_MAX is less because bugs have
been observed using this value and more from the (these days) typical
process of tending to reserve the top and/or bottom code points as magic
values for "future extensions".  Sometimes such values are never used,
sometimes they are.

It is, of course, the WG's prerogative to pick whatever justification it
would like in such a document.  Let us know what text you'd like. :-)

-- Jeff

---

From: David Farmer <[email-masked]>
Date: Mon, 20 May 2013 14:05:25 -0500

> asking for WG acceptance.

At a minimum, we need to formally document the technical reservation of 
the numerically highest 16 and 32 bit ASNs as this draft does.

However, another approach would be to deal with these two ASNs as a 
protocol issue and require implementations of BGP to NOT originate or 
propagate a route with these two ASNs, similar to draft-ietf-idr-as0, 
section 2 "Behavior".

While I'm not convinced this is absolutely necessary, we should strongly 
consider it.  This has the advantage of clearly making any use of these 
two ASNs an actual protocol error.  As drafted, what implementations 
should do when these two ASNs are seen is ambiguous. I'm afraid some 
implementations will treat it as an error and others will not, minimally 
leading interesting operational situations, and worst case leading to 
outright incompatibilities.

On the other hand, treating it only as an operational issue keeps the 
status quo, and should not require any changes in the BGP protocol. 
But, if not explicitly disallowed, it should be clear that all 
implementations must at least provide an option to allow the use of 
these two ASNs, though.

Does anyone know if any implementations disallow the use of one or both 
of these ASNs currently or maybe planed as part of implementing 
draft-ietf-idr-as0?  Either as the Local ASN, a Neighbor ASN, or within 
the AS_PATH (or AS4_PATH as appropriate)?

Also, someone with a better understanding of RPKI should consider if 
there are RPKI issues that should be discussed for these two ASNs, I 
don't think so, but I'm not an expert on RPKI.

Thanks for kicking off the discussion with the draft.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Jared Mauch <[email-masked]>
Date: Mon, 20 May 2013 15:32:53 -0400

On May 20, 2013, at 3:05 PM, David Farmer <[email-masked]> wrote:

> At a minimum, we need to formally document the technical reservation of the numerically highest 16 and 32 bit ASNs as this draft does.
> 
> However, another approach would be to deal with these two ASNs as a protocol issue and require implementations of BGP to NOT originate or propagate a route with these two ASNs, similar to draft-ietf-idr-as0, section 2 "Behavior".
> 
> While I'm not convinced this is absolutely necessary, we should strongly consider it.  This has the advantage of clearly making any use of these two ASNs an actual protocol error.  As drafted, what implementations should do when these two ASNs are seen is ambiguous. I'm afraid some implementations will treat it as an error and others will not, minimally leading interesting operational situations, and worst case leading to outright incompatibilities.
> 
> On the other hand, treating it only as an operational issue keeps the status quo, and should not require any changes in the BGP protocol. But, if not explicitly disallowed, it should be clear that all implementations must at least provide an option to allow the use of these two ASNs, though.

There is some significant brain damage out there in some BGP implementations.  eg: Cisco reserves the MED of 2^32-1 as INVALID internally and forces anything 2^32-1 to 2^32-2 silently.

There is some hidden knob in some IOS versions that allows it to have 2^32-1 properly and moves that overload elsewhere.

- Jared

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 20 May 2013 16:13:30 -0400

On 20/05/13 14:05 -0500, David Farmer wrote:
> 
> Does anyone know if any implementations disallow the use of one or
> both of these ASNs currently or maybe planed as part of implementing
> draft-ietf-idr-as0?  Either as the Local ASN, a Neighbor ASN, or
> within the AS_PATH (or AS4_PATH as appropriate)?

I don't know of any implementations that don't support these ASN's as
normal ASN's today (assuming they have 4 byte AS Support for the 2nd
one).  I think by any reading of existing standards, having
limitations on these ASN's today would be considered a bug.  I know a
number of networks have used 65535 (it occasionally is leaked as well
by folks who don't properly strip private asns) as if it was a Private
Use ASN and many vendors documentation include it in the Private Use
range regardless of the IANA actual allocation.

I'm open to others thoughts, but forcing a change on existing
implementations (versus just IETF/operator guidance on ASN's usage)
was not my intention. 

Cheers,

Jon

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 22 May 2013 13:28:12 -0400

David,

On Mon, May 20, 2013 at 02:05:25PM -0500, David Farmer wrote:
> protocol issue and require implementations of BGP to NOT originate
> or propagate a route with these two ASNs, similar to
> draft-ietf-idr-as0, section 2 "Behavior".
> 
> While I'm not convinced this is absolutely necessary, we should
> strongly consider it.  This has the advantage of clearly making any
> use of these two ASNs an actual protocol error.  As drafted, what
> implementations should do when these two ASNs are seen is ambiguous.
> I'm afraid some implementations will treat it as an error and others
> will not, minimally leading interesting operational situations, and
> worst case leading to outright incompatibilities.

I believe that with 65535 we're already in this situation to some extent.  I
believe many implementations will treat it as being in the "private" range
and thus subject to "remove-private" and similar knobs.  Similarly, a lot of
people's AS-path filters are likely to include this from common operational
practice.

IMO, permitting this AS to be used as private, despite not being included as
such, is probably okay.  Where things get messy is where pedantic BGP
implementations may choose to not consider it private where others do and
thus we end up with inconsistent behaviors.

AS 2^32-1 doesn't currently have such history and I'm less concerned here.

This perhaps opens the question of whether we should simply give up on
65535, remand it to the private AS range and if that doesn't happen to work
between a given set of providers, consider it an implementation issue?

-- Jeff