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 |