Skip to main content

BGP Support for Four-octet AS Number Space
RFC 4893

Revision differences

Document history

Date Rev. By Action
2015-10-14
13 (System) Notify list changed from idr-chairs@ietf.org, gih@apnic.net, narten@us.ibm.com, quaizar.vohra@gmail.com, enkechen@cisco.com to narten@us.ibm.com, gih@apnic.net
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Bill Fenner
2007-05-22
13 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-05-22
13 Amy Vezza [Note]: 'RFC 4893' added by Amy Vezza
2007-05-18
13 (System) RFC published
2007-04-03
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-04-02
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-04-02
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-04-01
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-03-28
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-03-26
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-03-12
13 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-03-12
13 (System) IANA Action state changed to In Progress
2007-03-09
13 Amy Vezza IESG state changed to Approved-announcement sent
2007-03-09
13 Amy Vezza IESG has approved the document
2007-03-09
13 Amy Vezza Closed "Approve" ballot
2007-02-22
13 Bill Fenner State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bill Fenner
2007-02-22
13 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner
2007-02-07
13 (System) New version available: draft-ietf-idr-as4bytes-13.txt
2006-11-30
13 Yoshiko Fong
This is a late IANA Last Call Comment

With the recent approval from the IESG to the IANA to extend
the registry AS numbers per …
This is a late IANA Last Call Comment

With the recent approval from the IESG to the IANA to extend
the registry AS numbers per draft-ietf-idr-as4bytes-04.txt,
the extension has been implemented.

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

The 32 bit AS numbers are in 1.0 - 65535.65535 format.

Do we need to continue with this document? Please let us know.
2006-11-08
13 (System) Request for Early review by SECDIR Completed. Reviewer: Vidya Narayanan.
2006-10-27
13 Bill Fenner State Change Notice email list have been change to idr-chairs@tools.ietf.org, gih@apnic.net, narten@us.ibm.com, quaizar.vohra@gmail.com, enkechen@cisco.com from idr-chairs@tools.ietf.org
2006-10-27
13 Bill Fenner
Reply from Geoff Huston regarding IANA Considerations:

From: Geoff Huston <gih@apnic.net>
Subject: Re: IANA considerations in  draft-ietf-idr-as4bytes-12.txt
Date: Wed, Oct 4 09:20:19
To: …
Reply from Geoff Huston regarding IANA Considerations:

From: Geoff Huston <gih@apnic.net>
Subject: Re: IANA considerations in  draft-ietf-idr-as4bytes-12.txt
Date: Wed, Oct 4 09:20:19
To: Thomas Narten <narten@us.ibm.com>
Cc: Enke Chen <enkechen@cisco.com>, qv@juniper.net, alexeis@us.ibm.com, Susan Hares <skh@nexthop.com>, Yakov Rekhter <yakov@juniper.net>,
    Ross Callon <rcallon@juniper.net>, Bill Fenner <fenner@research.att.com>

In response to your initial thoughts:

1) state clearly what the status quo is, namely RIRs have been doing
    the policy here, and IANA has been subdelegating to them. This
    document recognizes the status quo and believes it is working fine
    and is not making any changes.

I don't believe that this draft needs to define the current AS number
policy, but if a document is to be produced defining current
practice, then it would contain a description of an allocation
process of blocks of 1024 AS numbers, allocated to RIRs sequentially,
and additional block is allocated when the current working RIR free
AS pool is "low" (I don't know offhand if there is a precise
definition of "low" in this context).  I suspect that the parties who
should write such a document are the RIRs and IANA, and I am aware
that in the RIR context this work is underway on formalizing the
current AS number allocation practices into an agreed document
already, and this the proposed content is one that continues current
allocation practices, outside of the transition considerations. I
would suggest that this draft should simply state that "this does not
mandate any change to AS number allocation practices, outside of
considerations relating to a phased introduction of 4 byte AS Numbers"

2) Make clear that there are no technical requirements associated with
    the 4-byte ASNs, in terms of _which_ ones to use in what
    order. They are all equivalent. Right? So we don't really care
    whether IANA allocates to the RIRs in increasing order, decreasing
    order, or completely at random. (or if we do care, provide advice
    to IANA so that it does the Right Thing).

I support "there are no technical requirements associated with 4-byte
ASNs that require or even suggest a change to the current AS number
allocation policy, outside of considerations of phased introduction
of 4-byte AS numbers", but then again this is just a restatement of
the point above!


3) Perhaps make clear that the "private use" range was explicitly not
    expanded, with the rational being that getting  globally unique
    values was the preferred technical approach.

This is currently an implication as distinct from overt text. Making
this implication explicit has some sense. i.e. "There is no expansion
of the private-use and reserved AS number sets outside of AS23456"

4) run the text by IANA and some of the RIR  folk to be sure everyone
    agrees it solves the problem satisfactorily.

yep!

For your information:

1 - the RIRs have adopted a common policy related to opening up 2
allocation windows for the period 2007 - 2010, to allow those who
want 32 bit numbers now (as from 1 Jan 2007) to have them, but
otherwise they would allocate a 16 bit number, and then two years
later (1 Jan 2009) when we should be down to a relatively small pool
of unallocated 16 bit ASNs remaining to flip the default, and only
allocate 16 bits numbers upon explicit request. As of 1 Jan 2010 the
distinction between the two number sets would be dropped and the RIRs
would drop back to the current AS number policy (single active
allocation number block).

2 - We have adequate numbers in the ASN space so that there appears
to be no pragmatic need to open up a further private use AS number
pool. This  does rely on the RIRs having the policy framework for AS
number allocation criteria that is not explicitly limited to a public
network context (i.e. the policy is equally applicable to private
network contexts). I _believe_ that this is the case, but the check
should be made from a due diligence sense.

3 - the RIRs are working on the IANA - RIR allocation policy document
now. They are not proposing any changes to the blocks of 1024 numbers
allocated sequentially. They are proposing to define the low
watermark for subsequent allocations. they are proposing the interim
arrangements to support the phased introduction policy described above.

As I type this I could not help but smile at some words in RFC 1930 (1996):

9. AS Space exhaustion

    The AS number space is a finite amount of address space. It is
    currently defined as a 16 bit integer and hence limited to 65535
    unique AS numbers. At the time of writing some 5,100 ASes have been
    allocated and a little under 600 ASes are actively routed in the
    global Internet. It is clear that this growth needs to be continually
    monitored. However, if the criteria applied above are adhered to,
    then there is no immediate danger of AS space exhaustion. It is
    expected that IDRP will be deployed before this becomes an issue.
    IDRP does not have a fixed limit on the size of an RDI.




:-)

  Geoff
2006-10-27
13 Bill Fenner
Email from Thomas Narten regarding IANA Considerations:

From: Thomas Narten <narten@us.ibm.com>
Subject: IANA considerations in  draft-ietf-idr-as4bytes-12.txt
Date: Wed, Oct 4 07:55:25
To: Geoff …
Email from Thomas Narten regarding IANA Considerations:

From: Thomas Narten <narten@us.ibm.com>
Subject: IANA considerations in  draft-ietf-idr-as4bytes-12.txt
Date: Wed, Oct 4 07:55:25
To: Geoff Huston <gih@apnic.net>
Cc: Enke Chen <enkechen@cisco.com>, qv@juniper.net, alexeis@us.ibm.com, Susan Hares <skh@nexthop.com>, Yakov Rekhter <yakov@juniper.net>,
    Ross Callon <rcallon@juniper.net>, Bill Fenner <fenner@research.att.com>

Expanding the cc's on this old thread, and bringing in a new
question... (and for those scared by the lengthy quotes, the punch
line at the end is the need for some additional text in the IANA
considerations section.)

> > > >I've been talking to some folk who are starting to run up against the
> > > >limit of private ASNs. That is, the following range is reserved for
> > > >private use:
> > > >
> > > >>64512 - 65534 Designated for private use (Allocated to the IANA)
> > > >
> > > >That is, a total of 1022. But for some enterprise deployments (i.e.,
> > > >those with more than 1K individual sites, that number is too small.
> > > >
> > > >In going to 4-byte ASNs, would it make sense to expand the size of the
> > > >reserved block as well? E.g., reserving a full 16bits worth of space?
> > > >
> > > >Do you see any issues or concerns with doing this? Should I bring it
> > > >up in the IDR WG (or somewhere else?)

> >Enke Chen <enkechen@cisco.com> writes:
> >
> > > Hi, Thomas:
> >
> > > It makes sense to enlarge the pool for private ASs.  It could be either
> > > from the 2-byte AS pool, or 4-byte AS pool.  IDR and/or GROW would be
> > > the right WG for discussing your proposal.
> >
> > > -- Enke

> At 07:11 AM 13/07/2006, Thomas Narten wrote:
> >I just had a hallway conversation with Geoff Huston, and he suggested
> >that expanding the size of the private AS pool was unnecessary.
> >
> >Getting assignments out of the global space is trivial, and with the
> >expanded range, there are plenty of numbers to assign. Thus as far as
> >he knows, if somebody were to request some large number of ASNs (e.g.,
> >in the hundreds), there would be nothing stopping that from happening.
> >
> >So perhaps there is no problem here at all?
> >
> >Thomas

Geoff Huston <gih@apnic.net> writes:

> In developing the 4-Byte AS number allocations policies for ARIN, APNIC,
> RIPE, LACNIC and AFRINIC I can report that there was no visible support for
> expanding the private use AS number space, and it is certainly the case
> that RIR AS number allocation policies are, on the whole, ones that make AS
> numbers for a diversity of use, including contexts that encompass more
> scenarios than the public Internet.

Then, in a followup:

Alexei Sadovnikov <alexeis@us.ibm.com> writes:

> Geoff,

> Let me expand a bit on the reason for the request.  I will keep it brief
> but would gladly provide more information later if you wish.

> Many large enterprises are in process of move from private networks to
> MPLS services.  Predominant PE-CE protocol I observe remains to be BGP.
> Larger enterprises often have number of offices in excess of available
> private ASN space.  Specifically IBM internal network and a financial
> client in England are 2 recent examples (~5000 and about ~2000 BGP AS
> respectfully).

> Service Providers are implementing AS overwrite feature to go around a
> limitation of private AS number space.  This however does create numerous
> issues including but not limited to:
> - difficulties in use of more then one MPLS service provider
> - difficulties in arranging off MPLS backup links
> - difficulties in splitting a site to multiple routing domains

> I could have went on about limitations of AS overwrite feature for a long
> time, but it is outside the scope of this email.  I hope you get a flavor
> of it though.

> Although I agree that ASn are relatively easy to get, I disagree that ARIN
> is prepared to hand them out by thousands.

> Fee for an ASn number is another issue.  Although one-time $500 is short
> money for ASn, there is not a volume discount, and a bill for over a
> million dollars is very hard to stomach for just a number allocation.  I
> see the fact that volume pricing is not present as one more demonstration
> that ARIN is not ready to deal with large volume requests.

> In comparison the IP space comes in x-small at $1,250/year and goes up to
> x-large at $18,000/year.  If ASn pricing for 1000 ASn was in the same
> order of magnitude it would have been much easier to swallow.

> I also like to point out that original private ASn allocation was done in
> the days when IP networks were lot smaller and MPLS did not come to
> existence yet.  Development in networking area since have put lot larger
> demand on private ASn space while there is no viable expansion.

> I realize that the above discussion is enterprise centric and ISP/WSPs do
> not fill the pain.

> Your help on the matter would be greatly appreciated.

> Having said all that I whole hardly agree that registered ASn space is
> much more preferable to expansion of un-registered space.  For example if
> IBM network could have been assigned a block of 4 byte ASn of 65536 ( i.e.
> assign first 2 byte number and any value in the last 2 bytes) it would
> have solved our ASn issue for good.  I have not heard about a discussion
> on such large-range assignments.


> Best Regards,
> Alexei Sadovnikov

> IBM Certified IT Specialist
> IBM Global Services - Network Services
> (781) 715 1267

OK, Sorry for all the quoting, but I think its useful to review the
entire thread/context.

I'm not at all personally familiar with the RIR policies surrounding
"volume discounts", but presumably if they don't have an acceptable
policy, one could be introduced. I'd suggest we have some homework to
do here to figure out what (if anything) is needed to be done within
the RIR community.

Separately, I've heard from IANA that they are in the process of
figuring out how to deal with the the RIR policy concerning 4-byte ASN
numbers. E.g., see http://www.arin.net/policy/proposals/2005_9.html,
which is well on its way to being adopted by all the RIRs. Although it
may sound odd, IANA needs some "advice" on how to hand out 4-byte ASN
numbers to the RIRs, so that the RIRs can then hand ASNs out to end
users.

This is a unusual registry for IANA, because unlike most IETF-created
registries, IANA delegates assignment responsibility to the RIRs. And
the RIRs have developed policy around this. This is largely
undocumented on the IETF side (I believe.)

So, draft-ietf-idr-as4bytes-12.txt needs to clarify the situation and
provide sufficient guidance to IANA so that everyone is happy and we
don't have to (for example) require that the RIRs adopt a global
policy (a very heavy-weight thing!) just to allow IANA to provide it
with blocks of ASN numbers.

My initial thoughts:

1) state clearly what the status quo is, namely RIRs have been doing
  the policy here, and IANA has been subdelegating to them. This
  document recognizes the status quo and believes it is working fine
  and is not making any changes.

2) Make clear that there are no technical requirements associated with
  the 4-byte ASNs, in terms of _which_ ones to use in what
  order. They are all equivalent. Right? So we don't really care
  whether IANA allocates to the RIRs in increasing order, decreasing
  order, or completely at random. (or if we do care, provide advice
  to IANA so that it does the Right Thing).

3) Perhaps make clear that the "private use" range was explicitely not
  expanded, with the rational being that getting  globally unique
  values was the preferred technical approach.

4) run the text by IANA and some of the RIR  folk to be sure everyone
  agrees it solves the problem satisfactorily.

Thoughts? I'd be happy to try and craft some text if this seems like
it is on the right track. (Geoff?)

Thomas
2006-10-27
13 (System) Removed from agenda for telechat - 2006-10-26
2006-10-26
13 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-10-26
13 Bill Fenner
[Ballot discuss]
I want to discuss some of the IESG evaluation with the authors/WG - particularly, IANA Considerations (especially putting the value of AS_TRANS in …
[Ballot discuss]
I want to discuss some of the IESG evaluation with the authors/WG - particularly, IANA Considerations (especially putting the value of AS_TRANS in the document), the use  of "OLD" and "NEW", and SHOULD NOT vs MUST NOT on the use of AS_TRANS.
2006-10-26
13 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to Discuss from Yes by Bill Fenner
2006-10-26
13 Bill Fenner
[Ballot discuss]
I want to discuss some of the IESG evaluation with the authors/WG - particularly, IANA Considerations (especially putting the value of AS_TRANS in …
[Ballot discuss]
I want to discuss some of the IESG evaluation with the authors/WG - particularly, IANA Considerations (especially putting the value of AS_TRANS in the document), the use  of "OLD" and "NEW", and SHOULD NOT vs MUST NOT on the use of AS_TRANS.
2006-10-26
13 (System) [Ballot Position Update] Position for Bill Fenner has been changed to Yes from Discuss by IESG Secretary
2006-10-26
13 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to Discuss from Yes by Bill Fenner
2006-10-26
13 (System) [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by IESG Secretary
2006-10-26
13 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2006-10-25
13 David Kessens
[Ballot comment]
Although this draft has been a long time in the making and has had a large
number of revisions, I am a bit …
[Ballot comment]
Although this draft has been a long time in the making and has had a large
number of revisions, I am a bit disappointed by its overall quality. The
text is not particularly crisp and uses the words SHOULD (NOT) in way
too many places where there really is little reason not to use a
MUST/SHALL or MUST/SHALL NOT.

For example, in section '6. Transition':

'An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System
number.'

I am not convinced that a 'SHOULD NOT' is at all appropriate here.
AS_TRANS has been allocated by IANA for a particular use as defined
in this draft and there is no reason that I can see that there
'may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful' (as 'SHOULD NOT' is
defined in rfc 2119)

Operational problems are touched on but there is very little that helps the reader to understand what will happen when the possible failure
scenarios do happen. The document signals:

'Under certain conditions it may not be possible to reconstruct the
  entire AS path information from the AS_PATH and the NEW_AS_PATH
  attributes of a route.'

While it is explained how this could potentially happen, there is precious
little guidance on what an implementor should do when it is detected that
inconsistent information is received.

The IANA section is similarly difficult: why does it not simply mention
which values were assigned by IANA (together with a reference) instead of
forcing the reader to look them up in the referenced rfcs/IANA registry.

I am also somewhat annoyed that the draft does not contain a simple one line paragraph that describes the textual convention on how one should
represent the 4 byte ASes in CLIs etc. It seems rather ridiculous that
we will have to publish a second document just for this purpose and it
is strange that there is no informative reference to this draft. In fact,
if one is real suspicious, one may think that the actual values
are not mentioned in the IANA considerations to avoid this topic
altogether instead of just dealing with it as it has to be dealt with at
some point anyways.

To summarize, I don't think there is anything in the above that is
blocking. On the other hand, this document could have have been
much more clear and crisp.

I also received the following review from the Ops Directorate by Pekka Savola:

In general I'm not sure if the solution which reinterprets and
redefines (conditionally) the existing attributes is a good idea
rather than just using new attributes and rewriting those, but it
seems that the current decision was made so long ago this is already a
moot point.

RFC3392 has replaced RFC2842 (DS vs PS) but replacing this is just an
editorial update.  [BGP] reference should also be updated to RFC4271.

This document should probably have "Updates RFC4271" in the header,
abstract and introduction, as the size of the AS_PATH and AGGREGATOR
attributes changes depending on the capability

"An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous
System number."  ==> why a SHOULD NOT?  Isn't this a MUST NOT issue?

"  This document makes the four-octet, unsigned integers larger than
  65535 available for allocation as AS numbers. These AS numbers need
  to be managed by the IANA "Autonomous System Numbers" registry."

==> does te new management have new IANA considerations?  For example,
should new private/reserved AS number spaces be taken out of the end
(or some other part) of the 4byte AS ranges as well?  D

==> Further, does IANA require guidance on how (e.g. how large blocks
-- remember the sad story with IPv6 prefix allocation size to RIRs..)
or when to start assigning from it?  Specifically, should IANA keep
"Reserved by the IANA" (48128 - 64511) to itself or redistribute those
to RIRs as well?  Should 4byte AS number allocations start at 2^16 or
from some other number?
2006-10-25
13 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-10-25
13 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2006-10-25
13 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2006-10-25
13 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded by Mark Townsley
2006-10-25
13 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2006-10-24
13 Russ Housley
[Ballot comment]
To make it easier to update these attributes in the future, if needed.
  I suggest the use of a different prefix:
  …
[Ballot comment]
To make it easier to update these attributes in the future, if needed.
  I suggest the use of a different prefix:
    NEW_AS_PATH --> AS4_AS_PATH
    NEW_AGGREGATOR --> AS4_AGGREGATOR

  From the SecDir Review by Vidya Narayanan:

  The security considerations section says:
  >
  > This extension to BGP does not change the underlying security
  > issues inherent in the existing BGP.
  >
  While this seems to be largely true, reading section 4.2, it appears
  that some incomplete AS path information or routing loops may occur
  as a result of interaction between old and new BGP speakers. It seems
  plausible that a rogue node could use this to its advantage to create
  such incomplete AS paths or routing loops.  This is not a major
  concern, but may be worth mentioning in a sentence or two in the
  security considerations section.
2006-10-24
13 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-10-24
13 Sam Hartman
[Ballot comment]
I don't think this document is clear enough that I would have a
reasonbly good probability of successfully taking a BGP
implementation, the …
[Ballot comment]
I don't think this document is clear enough that I would have a
reasonbly good probability of successfully taking a BGP
implementation, the BGP specs and this document and getting something
interoperable out the other end.  In particular, I think examples
would significantly improve this document.

If this were a less important document I would block it on the clarity
issue.  However I realize that this is something we need to get out
soon and so I'm not going to block.  I would object to advancing the
current text to draft standard.
2006-10-24
13 Sam Hartman [Ballot Position Update] New position, Abstain, has been recorded by Sam Hartman
2006-10-24
13 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-10-23
13 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2006-10-23
13 Lars Eggert
[Ballot comment]
Section 1., paragraph 2:
>    Two new
>    attributes, NEW_AS_PATH and NEW_AGGREGATOR, are introduced that can
>    be used to …
[Ballot comment]
Section 1., paragraph 2:
>    Two new
>    attributes, NEW_AS_PATH and NEW_AGGREGATOR, are introduced that can
>    be used to propagate four-octet based AS path information across BGP
>    speakers that do not support the four-octet AS numbers.

  I'd suggest to use a prefix other than "NEW_", which is both very
  unspecific and can't be extended in the future ("NEW_NEW_?") Maybe
  "AS4_" or something.


Section 3., paragraph 1:
>    For the purpose of this document we define a BGP speaker which does
>    not support the new 4-octet AS number extensions as an OLD BGP
>    speaker, and a BGP speaker which supports the new 4-octet AS number
>    extensions as a NEW BGP speaker.

  Similar to above, I'd suggest something more descriptive than "NEW"
  and "OLD" here.


Section 11., paragraph 1:
>    [AS-EXT-COM] Rekhter, Y.,  Ramachandra, S., and Tappan, D.  "Four-
>    octet AS Specific BGP Extended Community", draft-rekhter-as4octet-
>    ext-community-00.txt, October 2005.

  Nit: Cited as [AS-EXT-COMM]
2006-10-23
13 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2006-10-23
13 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-10-18
13 Bill Fenner State Changes to IESG Evaluation from Waiting for Writeup by Bill Fenner
2006-10-18
13 Bill Fenner
Secdir review from Vidya Narayanan:

From: "Narayanan, Vidya" <vidyan@qualcomm.com>
Subject: Secdir review of draft-ietf-idr-as4bytes-12
Date: Mon, Sep 11 23:37:00
To: <iesg@ietf.org>, …
Secdir review from Vidya Narayanan:

From: "Narayanan, Vidya" <vidyan@qualcomm.com>
Subject: Secdir review of draft-ietf-idr-as4bytes-12
Date: Mon, Sep 11 23:37:00
To: <iesg@ietf.org>, <secdir@mit.edu>
Cc: skh@nexthop.com, qv@juniper.net, enkechen@cisco.com, yakov@juniper.net


All,
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the security area directors,
but are copied to the document's editors and the WG chairs for their
information and to allow them to address any issues raised.

The document proposes a 4-octet AS number extension for BGP to address
the exhaustion of the existing 2-octet AS number space. The document
currently states the following in the security considerations section -
"This extension to BGP does not change the underlying security issues
inherent in the existing BGP". While this seems to be largely true,
reading section 4.2, it appears that some incomplete AS path information
or routing loops may occur as a result of interaction between old and
new BGP speakers. It seems plausible that a rogue node could use this to
its advantage to create such incomplete AS paths or routing loops -
however, if the new extension is, say, protected using whatever
mechanism the BGP signaling may be protected with, there would then be
equivalence in the two cases.

This is not a major concern, but may be worth mentioning in a sentence
or two in the security considerations section.

Hope that helps.

Regards,
Vidya
2006-10-18
13 Bill Fenner
IETF Last Call comment from John Leslie:

From: John Leslie <john@jlc.net>
Subject: Re: Last Call: 'BGP Support for Four-octet AS Number Space' to …
IETF Last Call comment from John Leslie:

From: John Leslie <john@jlc.net>
Subject: Re: Last Call: 'BGP Support for Four-octet AS Number Space' to Proposed Standard (draft-ietf-idr-as4bytes)
Date: Mon, Sep 11 17:20:04
To: iesg@ietf.org

The IESG <iesg-secretary@ietf.org> wrote:
>
> The IESG has received a request from the Inter-Domain Routing WG to
> consider the following document:
>
> - 'BGP Support for Four-octet AS Number Space '
>    <draft-ietf-idr-as4bytes-12.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-12.

  (I promised Bill Fenner I'd write up something. It proved more of a
task than I realized, since the subject matter is so esoteric. As this
has prorgessed, the emphasis has changed a lot! Please be patient with
what may seem at first blush to be my rambling.)

  This I-D is a perfect poster child for what was wrong with RFC1264
(Internet Routing Protocol Standardization Criteria) -- and why you
should agree with Bill that RFC1264 is obsolete.

  draft-ietf-idr-as4bytes has been lying around for years without a
Last-Call _because_ it couldn't go to Proposed Standard without
implementations. Thus, rather than be given serious scrutiny, it has
languished awaiting folks who can be inveigled into implementing it.

  Having finally achieved that, it went to WGLC with the document
editor announcing quite plainly that it was four years too late to
consider serious changes. With the WGCs seeming to agree, we tried
to avoid looking at fundamental issues. :^( :^( :^(

  (BTW, I strongly support draft-fenner-obsolete-1264: any routing
protocol _needs_ the scrutiny of Last-Call _before_ we try to implement
it!)

  Hopefully this digression explains why I have taken this long to
consider the very fundamental problems with draft-ietf-idr-as4bytes; and
why I now consider it far more problemmatic than my WG-list posting
following the announcement of draft-ietf-idr-as4bytes-12 seems to
indicate.

  Fundamentally, draft-ietf-idr-as4bytes is bad because:

1 - it does too much violence to RFC 3392 Capability Advertisment
2 - it uses too much bandwidth in routing updates
3 - it too often fails to match actual 4byte ASNs to placeholders

1. RFC 3392 Capability Advertisement

  It turns out that this extension to BGP is poorly understood, even
within the IDR WG. RFC 3392 calls for advertising the ability to read
something that was not part of the original BGP4 spec. This ability is
(currently) noted when issuing the initial OPEN which starts a BGP
session. If the other side of that session (called the "peer") also
supports that "capability", it can then send messages using it.

  draft-ietf-idr-as4bytes-12 doesn't follow this model. Instead it treats
the exchange of capability advertisements as a two-way handshake to change
the meaning of most components of every UPDATE message. This will seriously
complicate the task of dynamic capability adjustment -- work that IDR is
already trying to start. :^(

2. Bandwidth of Updates

  The 4-byte-ASN issue arose because it has turned out that 60,000
different "Autonomous Systems" exchanging routes may not be enough. Geoff
Huston's estimates are the most respected, and they show exhaustion of the
2-byte AS numbers in late 2010. There is universal agreement we should do
something before then, even though there are reasons to doubt we'll actually
exhaust the 2-byte AS numbers by then.

  That given, however, it does not follow that the majority of AS paths
advertised would require 4 bytes to encode each entry. Indeed I know of
no one who believes we'll ever need the fourth byte at all, and it's clear
that an efficient coding wouldn't average significantly (if at all!) over
2 bytes.

  If all routing paths were stable, this would be an minor issue. Alas,
they're not. If all routers exchanged routing information over gigabyte
ethernet, the network transit time would be insignificant. Alas, they
don't. There's a significant subset which exchange over T-1 (1.5 Mbps)
links. If routing information never had to contend for bandwidth on that
T-1 link, we could exchange full routes at four bytes per AS number in
perhaps one minute. Alas, there are competing bandwidth demands. But one
minute is rather too long already; and the number of routes to exchange
continues to grow. :^(

  The point is, engineering for a compact encoding is justified: the burden
of proof should be to show that compact encoding is hard, not to show that
another minute would cause the death of the Internet.

  I don't mean to argue any particular more-compact coding here, though
several come to mind...

3. Matching Placeholders

  To add to the confusion about this issue, it is necessary to detect
loops even when routing information travels through routers which don't
support 4-byte AS numbers. This Internet Draft contains a clever mechanism
to "tunnel" 4-byte AS numbers through such systems. This is based on the
base BGP spec requiring that attributes "unknown" to a particular
implementation can be marked to indicate they must be passed through
unmodified (despite not being understood) if that route is passed on to a
peer.

  Thus, when speaking to a router which doesn't support 4-byte AS numbers,
a router which does understand them can encode actual 4-byte values into an
attribute which will be passed through without being understood. This is a
bit tricky, of course, because by the time this route reaches another router
which understands 4-byte AS numbers, many things could have changed.

  draft-ietf-idr-as4bytes started out (several years ago) with a simple
"tunneling" method, involving writing the entire path, in 4-byte form, in
an "optional transitive" attribute (which must be passed through unmodified
if not understood). Recently, we have noted a few cases where this can't
work, and the draft has been amended to forbid those cases. (It's not clear
what effect these restrictions may have over the long haul.)

  But we have by no means explored all the possible cases, and I'm quite
confident we could come up with a more robust scheme for tunneling 4-byte
AS numbers through BGP speakers which don't understand them. Beyond any
doubt, we could come up with a more compact coding than copying the entire
path -- which could tax the memory of some routers along the way.

  It is likely that no matter how carefully we consider possible cases,
there will be cases where a placeholder AS number is not resolved. This
should be mentioned, and advice given on how to ensure that loop detection
works in such cases.

Recommendation

  I recommend that this draft be sent back to the WG with directions to
address as many of these issues as you deem appropriate, and that there
be a clear statement that a revised 4-byte-ASN proposal will _not_ need
to show implementations before being Last-Called.

--
John Leslie <john@jlc.net>
2006-10-18
13 Bill Fenner Placed on agenda for telechat - 2006-10-26 by Bill Fenner
2006-10-18
13 Bill Fenner [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner
2006-10-18
13 Bill Fenner Ballot has been issued by Bill Fenner
2006-10-18
13 Bill Fenner Created "Approve" ballot
2006-09-15
13 Yoshiko Fong
IANA Last Call Comments:


First Action:

Upon approval of this document, the IANA will change the rules for
assignments in the "AUTONOMOUS SYSTEM NUMBERS" registry …
IANA Last Call Comments:


First Action:

Upon approval of this document, the IANA will change the rules for
assignments in the "AUTONOMOUS SYSTEM NUMBERS" registry located at
http://www.iana.org/assignments/as-numbers

New line in the registry will be:

65535 - 4294967295 Reserved by the IANA


Second Action:
Upon approval of this document, the IANA will make the following assignments in the "AUTONOMOUS SYSTEM NUMBERS" registry located at
http://www.iana.org/assignments/as-numbers

23456 AS_TRAN [RFC-idr-as4bytes]

Third action:
Upon approval of this document, the IANA will make the following assignments in the "Border Gateway Protocol (BGP) Parameters"
registry located at

http://www.iana.org/assignments/bgp-parameters
Table: "BGP Path Attributes - per [RFC4271]"

17 NEW_AS_PATH [RFC-idr-as4bytes]
18 NEW_AGGREGATOR [RFC-idr-as4bytes]

We understand the above to the only IANA Actions for this document.
2006-09-12
13 (System) State has been changed to Waiting for Writeup from In Last Call by system
2006-08-28
13 Amy Vezza Last call sent
2006-08-28
13 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-08-28
13 Bill Fenner State Changes to Last Call Requested from AD Evaluation by Bill Fenner
2006-08-28
13 Bill Fenner Last Call was requested by Bill Fenner
2006-08-28
13 (System) Ballot writeup text was added
2006-08-28
13 (System) Last call text was added
2006-08-28
13 (System) Ballot approval text was added
2006-06-12
13 Bill Fenner
[AS-EXT-COMM] should be draft-rekhter-as4octet-ext-community .  IMO, this could be an informative reference, since it's just advice, not normative behavior.

I think the IANA considerations (and …
[AS-EXT-COMM] should be draft-rekhter-as4octet-ext-community .  IMO, this could be an informative reference, since it's just advice, not normative behavior.

I think the IANA considerations (and perhaps the first reference to each value in the text) should list the values assigned

Draft IANA Note:
Please update the reference in capability-codes for capability 65 to this document.
Please update the reference in bgp-parameters for attributes 17 and 18 to this document.
Please update the reference in as-numbers for AS number 23456 to this document, and correct the name to AS_TRANS.
2006-06-12
13 Bill Fenner State Changes to AD Evaluation from Publication Requested by Bill Fenner
2006-06-12
13 Bill Fenner State Change Notice email list have been change to idr-chairs@tools.ietf.org from skh@nexthop.com, yakov@juniper.net
2005-12-16
13 Bill Fenner
From: Yakov Rekhter <yakov@juniper.net>
Subject: 4 bytes AS to PS
Date: Sat, Nov 12 20:24:11
To: "Bill Fenner" <fenner@research.att.com>, zinin@psg.com
Cc: …
From: Yakov Rekhter <yakov@juniper.net>
Subject: 4 bytes AS to PS
Date: Sat, Nov 12 20:24:11
To: "Bill Fenner" <fenner@research.att.com>, zinin@psg.com
Cc: idr@ietf.org, skh@nexthop.com

Bill and Alex,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-as4bytes-12.txt to a Proposed Standard.
The implementation report is draft-huston-idr-as4bytes-survey-00.txt

Sue & Yakov.
2005-12-16
13 Bill Fenner Draft Added by Bill Fenner in state Publication Requested
2005-11-11
12 (System) New version available: draft-ietf-idr-as4bytes-12.txt
2005-09-28
11 (System) New version available: draft-ietf-idr-as4bytes-11.txt
2005-07-14
10 (System) New version available: draft-ietf-idr-as4bytes-10.txt
2004-12-21
09 (System) New version available: draft-ietf-idr-as4bytes-09.txt
2004-03-16
08 (System) New version available: draft-ietf-idr-as4bytes-08.txt
2003-08-25
07 (System) New version available: draft-ietf-idr-as4bytes-07.txt
2002-12-16
06 (System) New version available: draft-ietf-idr-as4bytes-06.txt
2002-05-02
05 (System) New version available: draft-ietf-idr-as4bytes-05.txt
2001-09-05
04 (System) New version available: draft-ietf-idr-as4bytes-04.txt
2001-05-09
03 (System) New version available: draft-ietf-idr-as4bytes-03.txt
2001-04-26
02 (System) New version available: draft-ietf-idr-as4bytes-02.txt
2001-02-13
01 (System) New version available: draft-ietf-idr-as4bytes-01.txt
2001-01-30
00 (System) New version available: draft-ietf-idr-as4bytes-00.txt