From ljb at merit.edu Mon Sep 11 18:59:50 2006 From: ljb at merit.edu (Larry J. Blunk) Date: Mon, 11 Sep 2006 12:59:50 -0400 Subject: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <7.0.1.0.2.20060823112119.035181e8@ripe.net> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> Message-ID: <45059606.6070100@merit.edu> Henk Uijterwaal wrote: > >> Date: Wed, 23 Aug 2006 11:20:53 +0200 >> To: Mark Prior >> From: Henk Uijterwaal >> Subject: Re: RPSL support for 32 bit ASN >> Cc: rpslnp at ripe.net, asn32 at ripe.net, ggm at apnic.net >> >> At 15:08 18/08/2006, Mark Prior wrote: >> >>> Is it worth doing another update to RPSL to include this >> >> This would certainly help us a lot (we can point to a document when >> we update our tools), so ... >> >> ... I spent a morning writing essentially a 1 page document just to >> update this and submitted it as an individual submission ID, >> draft-uijterwaal-rpsl-4byteas-ext-00.txt. To appear in the ID >> repository soon. >> >> Henk There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach. -Larry Blunk Merit From henk at ripe.net Mon Sep 11 20:32:40 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Mon, 11 Sep 2006 20:32:40 +0200 Subject: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <45059606.6070100@merit.edu> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> <45059606.6070100@merit.edu> Message-ID: <7.0.1.0.2.20060911201410.034831a8@ripe.net> Larry, > There was considerable discussion during the development of the >RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. >The consensus was that this approach should not be taken and that >new attributes should be created wherever an IPv6 address could >appear so as not to break existing tools. >draft-uijterwaal-rpsl-4bytesas-ext-00.txt >appears to have abandoned this approach. That is correct. I looked at the problem and creating new attributes for ASN32 would cause the number of attributes to expand as N^2. In other words, for each kind of attribute, there would be a version for IPv4-ASN16, IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in the future, this will result in 8 versions of essentially the same attribute. This does not look very attractive to me. Also, contrary to IPv4 and IPv6, we are very likely to have a mixed ASN16 and ASN32 world "forever". In fact, the ASN32 standard is specifically designed with this in mind, and the two worlds can live happily together. So, any tool will have to be upgraded sooner or later, the only question is when and how. In both cases (change existing attributes or create new ones), people will have to upgrade when they move into the ASN32 world. The difference is in the code change. In my draft, the tools will have to recognize 2 versions for an AS. Changing attributes means that tools will have to check if the ASN16 or ASN32 version is there, then parse that to get the information. In the end, this doesn't look like a big difference to me. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From katie at ripe.net Tue Sep 12 09:22:54 2006 From: katie at ripe.net (Katie Petrusha) Date: Tue, 12 Sep 2006 09:22:54 +0200 Subject: [asn32] Re: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <7.0.1.0.2.20060911201410.034831a8@ripe.net> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> <45059606.6070100@merit.edu> <7.0.1.0.2.20060911201410.034831a8@ripe.net> Message-ID: <20060912072254.GA18674@ripe.net> Hi Larry, > > There was considerable discussion during the development of the > >RPSLng spec (RFC4012) concerning modifying the syntax for existing > >attributes. > >The consensus was that this approach should not be taken and that > >new attributes should be created wherever an IPv6 address could > >appear so as not to break existing tools. > >draft-uijterwaal-rpsl-4bytesas-ext-00.txt > >appears to have abandoned this approach. > > That is correct. I looked at the problem and creating new attributes for > ASN32 would cause the number of attributes to expand as N^2. In other > words, for each kind of attribute, there would be a version for IPv4-ASN16, > IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in > the future, this will result in 8 versions of essentially the same > attribute. This does not look very attractive to me. I support Henk in this. To strictly follow the RPSL extention guidelines, one has to add 12 new attributes to existing objects and 7 new classes (with total of 30+ new attributes) to accept 32bit ASn. Following RPSL extention guidelines where possible is good, but I think here alternative approach is justified. -- Katie Petrusha RIPE NCC From ljb at merit.edu Wed Sep 13 21:26:26 2006 From: ljb at merit.edu (Larry J. Blunk) Date: Wed, 13 Sep 2006 15:26:26 -0400 Subject: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <7.0.1.0.2.20060911201410.034831a8@ripe.net> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> <45059606.6070100@merit.edu> <7.0.1.0.2.20060911201410.034831a8@ripe.net> Message-ID: <45085B62.5080508@merit.edu> Henk Uijterwaal wrote: > Larry, > >> There was considerable discussion during the development of the >> RPSLng spec (RFC4012) concerning modifying the syntax for existing >> attributes. >> The consensus was that this approach should not be taken and that >> new attributes should be created wherever an IPv6 address could >> appear so as not to break existing tools. >> draft-uijterwaal-rpsl-4bytesas-ext-00.txt >> appears to have abandoned this approach. > > That is correct. I looked at the problem and creating new attributes for > ASN32 would cause the number of attributes to expand as N^2. In other > words, for each kind of attribute, there would be a version for > IPv4-ASN16, > IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in > the future, this will result in 8 versions of essentially the same > attribute. This does not look very attractive to me. > > Also, contrary to IPv4 and IPv6, we are very likely to have a mixed > ASN16 and ASN32 world "forever". In fact, the ASN32 standard is > specifically designed with this in mind, and the two worlds can > live happily together. > > So, any tool will have to be upgraded sooner or later, the only question > is when and how. > > In both cases (change existing attributes or create new ones), people > will > have to upgrade when they move into the ASN32 world. The difference is > in the code change. In my draft, the tools will have to recognize 2 > versions for an AS. Changing attributes means that tools will have to > check if the ASN16 or ASN32 version is there, then parse that to get > the information. In the end, this doesn't look like a big difference > to me. > > The big difference is that existing tools can potentially break if the syntax is changed in existing attributes. I agree that adding new attributes is undesirable, but I see a couple alternatives. The first would be to use straight integer notation for the AS numbers instead of the "." notations. This is actually compatible with the RFC 2622 flex macro for AS numbers (as Mark Prior noted) and would likely be compatible with existing tools. INT [[:digit:]]+ ASNO AS{INT} The presentation and submission layers could optionally support the "." notation. Note that RFC3779 uses a straight integer for 32-bit ASN's (as opposed to the dotted character bitstrings for IPv4 numbers), so this is not unprecedented. The other option would be to update RFC4012 (RPSLngbis?) as it is relatively fresh and the tools to process mp- attributes are few. -Larry From henk at ripe.net Thu Sep 14 10:09:06 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 14 Sep 2006 10:09:06 +0200 Subject: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <45085B62.5080508@merit.edu> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> <45059606.6070100@merit.edu> <7.0.1.0.2.20060911201410.034831a8@ripe.net> <45085B62.5080508@merit.edu> Message-ID: <7.0.1.0.2.20060914091843.0353dcf8@ripe.net> Larry, > The big difference is that existing tools can potentially break if >the syntax is changed in existing attributes. I agree that adding new >attributes is undesirable, but I see a couple alternatives. The first would >be to use straight integer notation for the AS numbers instead of the >"." notations. The IESG has asked for a standard notation for ASN32 when processing draft-ietf-idr-as4bytes. draft-michaelson-4byte-as-representation was written to suggest the "x.y" notation. This draft is likely to be accepted soon. My draft follows this "x.y" notation simply because I don't think that it is a good idea to have 2 different formats for the same thing. At least, it'd drive me nuts if I had to type 1.0 in one place (my router CLI, for example) and 65536 in another (an RPSL tool) when referring to the same thing. > This is actually compatible with the RFC 2622 flex macro >for AS numbers (as Mark Prior noted) and would likely be compatible >with existing tools. An AS has been a 16 bit number forever (in terms of the lifetime of the Internet) and authors have implicitly used that when writing their tools. That means: regular int's (or even short unsigned ints) in the code, checks on input that numbers entered are below 65536 and/or 5 digits, arrays dimensioned to 65536, etc. All this code will have to be checked and updated. I would definitely not feel comfortable using code with numbers outside the range of the original spec. > Note that RFC3779 uses a straight integer for 32-bit >ASN's (as opposed to the dotted character bitstrings for IPv4 numbers), so >this is not unprecedented. I seriously doubt that the authors of RFC3779 had ASN32 in mind when they wrote that RFC. I also think that this is a good example of why things have to be checked; a regular C integer (31 bits plus sign bit) in your code will fail for ASN 32768.0. It should be an unsigned int. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From ljb at merit.edu Thu Sep 14 22:40:48 2006 From: ljb at merit.edu (Larry J. Blunk) Date: Thu, 14 Sep 2006 16:40:48 -0400 Subject: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <7.0.1.0.2.20060914091843.0353dcf8@ripe.net> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> <45059606.6070100@merit.edu> <7.0.1.0.2.20060911201410.034831a8@ripe.net> <45085B62.5080508@merit.edu> <7.0.1.0.2.20060914091843.0353dcf8@ripe.net> Message-ID: <4509BE50.3020701@merit.edu> Henk Uijterwaal wrote: > Larry, > > >> The big difference is that existing tools can potentially break if >> the syntax is changed in existing attributes. I agree that adding >> new >> attributes is undesirable, but I see a couple alternatives. The >> first would >> be to use straight integer notation for the AS numbers instead of the >> "." notations. > > The IESG has asked for a standard notation for ASN32 when processing > draft-ietf-idr-as4bytes. draft-michaelson-4byte-as-representation was > written to suggest the "x.y" notation. This draft is likely to be > accepted soon. > > My draft follows this "x.y" notation simply because I don't think that it > is a good idea to have 2 different formats for the same thing. At least, > it'd drive me nuts if I had to type 1.0 in one place (my router CLI, for > example) and 65536 in another (an RPSL tool) when referring to the same > thing. The tool could convert from "x.y" when processing for submission, so you wouldn't have to deal with 2 different formats. > >> This is actually compatible with the RFC 2622 flex macro >> for AS numbers (as Mark Prior noted) and would likely be compatible >> with existing tools. > > An AS has been a 16 bit number forever (in terms of the lifetime of the > Internet) and authors have implicitly used that when writing their tools. > That means: regular int's (or even short unsigned ints) in the code, > checks on input that numbers entered are below 65536 and/or 5 digits, > arrays dimensioned to 65536, etc. All this code will have to be > checked and updated. I would definitely not feel comfortable using > code with numbers outside the range of the original spec. The original spec doesn't specify a range. Some code will have problems with numbers greater than 16-bit, others won't. Certainly fewer implementations will have issues with 32-bit numbers than "x.y" notation. > > >> Note that RFC3779 uses a straight integer for 32-bit >> ASN's (as opposed to the dotted character bitstrings for IPv4 >> numbers), so >> this is not unprecedented. > > I seriously doubt that the authors of RFC3779 had ASN32 in mind when they > wrote that RFC. I also think that this is a good example of why things > have to be checked; a regular C integer (31 bits plus sign bit) in your > code will fail for ASN 32768.0. It should be an unsigned int. > > Actually, they did have 32 bit AS numbers in mind. That's why they defined the following in the RFC -- Autonomous System number - a 32-bit number that identifies an autonomous system. I'm not sure if this is actually compatible with the ASN.1 INTEGER definition, but they definitely had the foresight to allow for 32-bit AS numbers. From henk at ripe.net Fri Sep 15 08:39:41 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Fri, 15 Sep 2006 08:39:41 +0200 Subject: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <4509BE50.3020701@merit.edu> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> <45059606.6070100@merit.edu> <7.0.1.0.2.20060911201410.034831a8@ripe.net> <45085B62.5080508@merit.edu> <7.0.1.0.2.20060914091843.0353dcf8@ripe.net> <4509BE50.3020701@merit.edu> Message-ID: <7.0.1.0.2.20060915082959.03431538@ripe.net> Larry, > The tool could convert from "x.y" when processing for submission, >so you wouldn't have to deal with 2 different formats. Yes, it could. I'm not sure if it will though. There is a canonical representation for printing these numbers and as a developper I'd use that. If somebody wants another format internally because that is easier, I expect him to do that in his tool. For the same reason, I allow people to enter an IPv4 adress as 193.0.1.49, I don't expect them to do the artimethic to convert it to 3238002993 even if in my code, I use unsigned int's. >>An AS has been a 16 bit number forever (in terms of the lifetime of the >>Internet) and authors have implicitly used that when writing their tools. >>That means: regular int's (or even short unsigned ints) in the code, >>checks on input that numbers entered are below 65536 and/or 5 digits, >>arrays dimensioned to 65536, etc. All this code will have to be >>checked and updated. I would definitely not feel comfortable using >>code with numbers outside the range of the original spec. > > The original spec doesn't specify a range. Some code will have problems >with numbers greater than 16-bit, others won't. Certainly fewer >implementations >will have issues with 32-bit numbers than "x.y" notation. The AS spec does. Then, nothing prevents you to convert "x.y" into an unsigned int in your code and use that internally. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From ljb at merit.edu Fri Sep 15 16:04:05 2006 From: ljb at merit.edu (Larry J. Blunk) Date: Fri, 15 Sep 2006 10:04:05 -0400 Subject: Fwd: Re: RPSL support for 32 bit ASN In-Reply-To: <7.0.1.0.2.20060915082959.03431538@ripe.net> References: <7.0.1.0.2.20060823112119.035181e8@ripe.net> <45059606.6070100@merit.edu> <7.0.1.0.2.20060911201410.034831a8@ripe.net> <45085B62.5080508@merit.edu> <7.0.1.0.2.20060914091843.0353dcf8@ripe.net> <4509BE50.3020701@merit.edu> <7.0.1.0.2.20060915082959.03431538@ripe.net> Message-ID: <450AB2D5.8020300@merit.edu> Henk Uijterwaal wrote: > Larry, > >> The tool could convert from "x.y" when processing for submission, >> so you wouldn't have to deal with 2 different formats. > > Yes, it could. I'm not sure if it will though. There is a canonical > representation for printing these numbers and as a developper I'd > use that. If somebody wants another format internally because that > is easier, I expect him to do that in his tool. > > For the same reason, I allow people to enter an IPv4 adress as > 193.0.1.49, I don't expect them to do the artimethic to convert it > to 3238002993 even if in my code, I use unsigned int's. I guess I wasn't being clear. I was speaking of the input processor for the routing registry itself. For example, the RIPE software will convert inetnum attributes from CIDR prefix format to range format. The point is that a number tools using the registry. Some use the whois interface, while others do bulk downloads of the registry data to process it. While not a huge population of users, I think you may underestimate the number and variety of tools. Further, these tools will not always reference objects registered by the user. There may be object references to external route-set's/as-set's, etc.. Tools that do bulk processing of registry files will scan through all the objects (looking for particular AS numbers in route: objects for example). -Larry > >>> An AS has been a 16 bit number forever (in terms of the lifetime of the >>> Internet) and authors have implicitly used that when writing their >>> tools. >>> That means: regular int's (or even short unsigned ints) in the code, >>> checks on input that numbers entered are below 65536 and/or 5 digits, >>> arrays dimensioned to 65536, etc. All this code will have to be >>> checked and updated. I would definitely not feel comfortable using >>> code with numbers outside the range of the original spec. >> >> The original spec doesn't specify a range. Some code will have >> problems >> with numbers greater than 16-bit, others won't. Certainly fewer >> implementations >> will have issues with 32-bit numbers than "x.y" notation. > > The AS spec does. > > Then, nothing prevents you to convert "x.y" into an unsigned int in > your code and use that internally. > > Henk > >