- Test - lists.nanog.org

RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
by Chris Burton 30 Nov '04

30 Nov '04

I was just throwing in the example of the private AS numbers to try and preempt anyone who might try to use that example if any on how transiting to 32-bit AS numbers would somehow cause a collapse of the world as we know it (It was not the best example). Let me qualify my statement; personally I don't think the policies in place should be anymore strict then they already are or changed in any fashion for the given circumstances (If the given circumstances change, well then I reserve the right to change my mind on the issue as do the governing bodies, and anyone else who wishes to change their mind); that being said I also do not believe the policies should be relaxed in any fashion (why add trouble if you do not have to). The current ASN policies are pretty cut and dry as to who can receive a non-private ASN and who cannot. I think overall you and I agree on this. Chris -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, November 30, 2004 12:49 PM To: Chris Burton; Pekka Savola Cc: Jeroen Massar; Cliff Albert; nanog(a)merit.edu Subject: RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI] Actually, no need for trouble with the existing private ASNs. Afterall, RFC 1918 is not exactly taken from any particular end of the IPv4 space. The same situation can exist with private ASNs... They simply become a hole in the list. I don't think we need stricter ASN policies. I think the current policies are quite adequate. If you think that the current policies are not sufficiently strict, I'd be interested in knowing in what way you think they are insufficient. In any case, there isn't a land-rush for ASNs under current policy as far as I can tell, and, I don't think increasing the available bits will change that. Owen --On Tuesday, November 30, 2004 11:38 -0800 Chris Burton <ChrisB(a)VMC.com> wrote: > The idea behind possibly making the policy stricter would be to > keep all of those "I want one too" people from getting an ASN number who > do not have a clear need and therefore conserve resources. Only because > you have the ability to give out ASNs does not me you should. Human > nature dictates for most people that if it is available they want one > also regardless of if the need exists. > > I have no problems with the phased move to 32-bit ASNs; it is a > logical step towards the future. I don't see what the big deal is; > although I do not write the code for the network equipment it seems that > the transition should be fairly transparent since the first 65536 ASN > numbers fit snuggly into the a 32-bit schema (there may be issues with > the private ASNs, but those also should fairly easy to transition) so > there shouldn't be much of a problem for existing users and none for new > users with the proper code/equipment. Future transitions to a 64-bit or > 128-bit ASN if the need should arise, again I do not see a major issue; > but this is just my opinion, YMMV. > > Chris > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, November 29, 2004 9:44 PM > To: Chris Burton > Cc: Owen DeLong; Jeroen Massar; Cliff Albert; nanog(a)merit.edu > Subject: RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large > multi-site enterprises and PI] > > On Mon, 29 Nov 2004, Chris Burton wrote: >> It is highly doubtful that the policies in place will become >> more relaxed with the introduction of 32-bit ASNs, the more likely >> scenario is that they will stay the same or get far stricter as with >> assignments of IPv4 or IPv6 addresses. > > I find this hard to believe. When there is 64K times as much the > resource, there is no way the policies would get stricter, because it > can easily and logically be argued that they don't need to be > stricter. > >> As you had mentioned though, in the near term this definitely would >> not be scalable, but who knows what is going to happen 10, 15, or >> more years from now. > > So, let's delay the move until we know how to make it more scalable. > >> I think your numbers may be a little off 2^32 = 4,294,967,296; >> current world population give or take a few million is hovering around >> 6,300,000,000 according to the US Gov. If everyone and the mother > would >> like an ASN (Which is highly unlikely) you would need just a few more > to >> make that work. > > Yeah, I know the calculations :). Everyone can already get an IPv4 > address too, right? All we need is an AS number NAT.. oops, it's there > already. > > Face it, with 32 bit ASNs, pretty much anyone could have an ASN if > they wanted to unless the policies were very strict, and it would be > very difficult to justify why it would have to be strict because there > is so vast resource to be used.

1 0

ping SBC abuse/security/noc
by Christopher McCrory 30 Nov '04

30 Nov '04

Hello... Can someone from SBC contact me off list. (or help out with contact info for $RealPerson). For the past six months one of SBC's users has been constantly hammering my web servers. Apparently with SBC DSL you can cycle your network interface every five minutes and get another IP address. This makes blocking malcontents an exercise in futility. I have emailed abuse@ and security@ for the last four months with no response other than the automagic "we received your email bla bla bla" (hopefully) Thanks -- Christopher McCrory "The guy that keeps the servers running" chrismcc(a)pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works.

1 0

RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
by Chris Burton 30 Nov '04

30 Nov '04

The idea behind possibly making the policy stricter would be to keep all of those "I want one too" people from getting an ASN number who do not have a clear need and therefore conserve resources. Only because you have the ability to give out ASNs does not me you should. Human nature dictates for most people that if it is available they want one also regardless of if the need exists. I have no problems with the phased move to 32-bit ASNs; it is a logical step towards the future. I don't see what the big deal is; although I do not write the code for the network equipment it seems that the transition should be fairly transparent since the first 65536 ASN numbers fit snuggly into the a 32-bit schema (there may be issues with the private ASNs, but those also should fairly easy to transition) so there shouldn't be much of a problem for existing users and none for new users with the proper code/equipment. Future transitions to a 64-bit or 128-bit ASN if the need should arise, again I do not see a major issue; but this is just my opinion, YMMV. Chris -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Monday, November 29, 2004 9:44 PM To: Chris Burton Cc: Owen DeLong; Jeroen Massar; Cliff Albert; nanog(a)merit.edu Subject: RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI] On Mon, 29 Nov 2004, Chris Burton wrote: > It is highly doubtful that the policies in place will become > more relaxed with the introduction of 32-bit ASNs, the more likely > scenario is that they will stay the same or get far stricter as with > assignments of IPv4 or IPv6 addresses. I find this hard to believe. When there is 64K times as much the resource, there is no way the policies would get stricter, because it can easily and logically be argued that they don't need to be stricter. > As you had mentioned though, in the near term this definitely would > not be scalable, but who knows what is going to happen 10, 15, or > more years from now. So, let's delay the move until we know how to make it more scalable. > I think your numbers may be a little off 2^32 = 4,294,967,296; > current world population give or take a few million is hovering around > 6,300,000,000 according to the US Gov. If everyone and the mother would > like an ASN (Which is highly unlikely) you would need just a few more to > make that work. Yeah, I know the calculations :). Everyone can already get an IPv4 address too, right? All we need is an AS number NAT.. oops, it's there already. Face it, with 32 bit ASNs, pretty much anyone could have an ASN if they wanted to unless the policies were very strict, and it would be very difficult to justify why it would have to be strict because there is so vast resource to be used. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

2 1

RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
by Chris Burton 30 Nov '04

30 Nov '04

These are the same arguments that are presented each time something new comes along to replace something old. When IPv4 first came along nobody thought all of the 4 billion plus address could ever be used; but we were wrong. 16-bit ASNs have served their place and will continue to serve for the time being. Those who fail to plan, plan to fail. It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses. As you had mentioned though, in the near term this definitely would not be scalable, but who knows what is going to happen 10, 15, or more years from now. I think your numbers may be a little off 2^32 = 4,294,967,296; current world population give or take a few million is hovering around 6,300,000,000 according to the US Gov. If everyone and the mother would like an ASN (Which is highly unlikely) you would need just a few more to make that work. Chris -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Pekka Savola Sent: Monday, November 29, 2004 11:41 AM To: Owen DeLong Cc: Jeroen Massar; Cliff Albert; nanog(a)merit.edu Subject: Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI] On Mon, 29 Nov 2004, Owen DeLong wrote: >> Also, with 32bit ASN's, also expect upto 2^32 routes in your routing >> table when each and every ASN would at least send 1 route and of course >> there will be ASN's sending multiple routes. > > Only if EVERY ASN were allocated and active. You and I both know this > doesn't begin to approach reality. Slightly more than half of current > ASNs are actually in the routing table. The ASN issuance rate is not likely > to go up simply because we go to 32 bit ASNs. Probably we are really talking > about a need for 20 bit ASNs or so, generally, but, 32 bits is a much more > convenient boundary for lots of code implementations and lots of hardware, > so, 32 bits is the chosen number for the sake of simplicity. Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be "no need" (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table. Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god. It's better to try to stick to 16 bit ASNs for now, and make stricter policies and reclaim the space if needed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

3 4

Re: size of the routing table is a big deal, especially in IPv6
by Joe Loiacono 30 Nov '04

30 Nov '04

Please see an earlier write-up below. Will we run into IPv6 routing table problems without more formalized aggregation guidelines? "The general guiding principal for the allocation of IPv6 address space is as follows: " /48 in the general case, except for very large subscribers " /64 when it is known that one and only one subnet is needed by design " /128 when it is absolutely known that one and only one device is connecting The second-half of the IPv6 address (the last 64 bits) are generally reserved for the devices end-system identifier. Typically this is a Network Service Access Point (NSAP) identifier, or derived from the device's 48-bit IEEE 802 address padded up to 64 bits. A /64 network address then can hold 64 bits worth of devices. It is useful to look at /64s as if they were IPv4 Class C addresses, which are typically used for a single LAN or broadcast domain. A /48 has 16 bits worth (65,536) of Class C's then, which, if we continue the comparison, makes it the equivalent of an IPv4 Class A address. A /48 is generally considered the smallest routable prefix. A typical IPv6 address allocation (e.g., 200A:06D1::/32) holds 16 bits worth (65,535) of these /48 Class A's. The overall Aggregatable Global Unicast range (001::/3) holds 45 bits worth of routable networks. This clearly exceeds any router's capacity to accommodate a routing table of strictly /48s." Joe Loiacono

1 0

Cisco ATM to ethernet VLAN local switching
by Robert Larsen 30 Nov '04

30 Nov '04

Hi, I'm trying to get the ATM to ethernet VLAN local switching working properly. What I'm trying to achieve is to connect a Cisco 828 over an SDSL line using a VP/VC that terminates on a Cisco 7200. This VC is then connected at layer 2 on the 7200 to a VLAN, which eventually terminates on a Cisco2621. Physical view: 828 ____SDSL ____ ATM ____ 7200 ____VLAN____ 2621 router DSLAM cloud router router I can get the 828 to talk to the 7200 at layer 3 no problem, but what I'm trying to do is get the 828 to see the 2621 as being directly connected at layer 3 (i.e. the 7200 is transparent). Here is the logical (layer 3) view: 828 ____ 2621 router router The config I'm trying to use is the following under the fastethernet sub-interface: connect connection-name interface pvc interface interworking interworking-type This is described in more detail here: http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guid e09186a00801ea88d.html#wp1110021 I'm not having any joy getting this working, so I was wondering whether any of you have had any experience with this and can help me out? The 7200 is a 7206VXR running IOS 12.2(25)S1. Thanks in advance, Rob.

1 0

RE: Sensible geographical addressing [Was: 16 vs 32 bit ASNs yadd a, yadda]
by Hannigan, Martin 30 Nov '04

30 Nov '04

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] > Sent: Tuesday, November 30, 2004 9:28 AM > To: nanog(a)merit.edu > Subject: Sensible geographical addressing [Was: 16 vs 32 bit > ASNs yadda, > yadda] > > > > > This is broken by design. What would have happend if this > > had be done before the fiber glut in the late 90's? As far > > as I am aware a couple of new fiber routes have been build > > and a few more cities have become nodes. > > I am not suggesting time machines. I am proposing that > this be done now, after the fiber glut has largely been > built out and when we are in a much better position to > understand how the global network will evolve. That's > why I suggest that the planning for the aggregation > hierarchy should be done in the regions. They know > more about the topology of their region and the > pressures (economic, political, social) that will > drive the evolution of the network in their region. Fiber routes have very little to do with evolution of the Internet. Capacity is key, and underlying markets drive where the glass is. Internet service is bottom up. [ snip ] > Technically speaking, I don't care about where people go or > where containers go. It's the fiber routes that I care about > and these usually lead to interconnect points or exchanges > in the major cities. I worked for GTS at the time they All fiber must meet somewhere. It's the nature of the beast. Fiber is not dependant upon exchanges or meet me rooms, the meet-me's and exchanges are dependant upon it. -M< > were building Flag Atlantic. Even though we knew that the > cables landed at Crab Meadow and Long Beach, we still > referred to that end as the New York end because we > were only planning to connect customers to the link > in the city of New York. On a trans-oceanic hop it > doesn't make a lot of difference if the traffic lands > in a Sprint Pop and then has to go crosstown to > MCI's PoP before being routed to its destination in > Rochester. Why do the Europeans need to see the > topology of New York State in order to efficiently > route traffic? So people don't build PVC's from NYC to LAX and call it one hop? -M<

1 0

Re: who gets a /32 [Re: IPV6 renumbering painless?]
by Paul Vixie 30 Nov '04

30 Nov '04

> And please don't add any more layering violations. It makes implementors > life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events.

8 12

Re: who gets a /32 [Re: IPV6 renumbering painless?]
by Iljitsch van Beijnum 30 Nov '04

30 Nov '04

On 22-nov-04, at 17:53, Mohacsi Janos wrote: >> And don't forget that you still have to change your phone number when >> you move a great enough distance. In IP we somehow feel it's >> important that there are no geographical constraint on address use at >> all. That's a shame, because even if we aggregate by contintent that >> would save up to four times in the number of entries in the routing >> table of any router. > Then why geographic based aggregated IPv6 addresses disposed? > Geographic based addresses can solve the agregation quite nicely. The general objection (apart from incorrect assumptions based on old incomplete work) is that network topology and geography don't correlate. My counter-objection is that the correlation doesn't have to be 1 to be able to take advantage of it when it's present. > Unfortunately the uniqueness can be problematic.... How do you mean?

3 4

Re: who gets a /32 [Re: IPV6 renumbering painless?]
by Owen DeLong 30 Nov '04

30 Nov '04

> Instead of hacking the nice and working TCP we have now you should > move on to greener grass and use SCTP instead. It does what you > want, at least in the specification. I don't know how many implementors > have managed to code it properly. > Please point me to where I can get a version of SSH that uses SCTP instead of TCP and talks to the existing SSHD services using TCP with flow survivability. If the TCP library changes underneath SSH and provides this capability, it will get deployed. If we need to completely rewrite all the applications to support TCP and SCTP in some sort of split-brained idea of how the world should work, then, adoption is less likely. Personally, I agree that TCP is the wrong place to solve this. I think instead of moving up the stack we need to move down the stack and solve this entirely at layer 3 by recognizing that IP addresses as currently implemented (both in v4 and v6) are better as endpoint identifiers and as such should be migrated to layer 4 with layer three being built on a new series of addresses that are topologically derived and do not need to remain consistent during a session for the session to continue. The further this thread goes, the more I am convinced that the telcos have the key. There are actually two phone numbers associated with each end of any given call. One is the endpoint identifier (Dialed Number/Billing Number), the other is the routing identifier (I don't know the SS7 term for this). In most cases, it turns out that these are the same, but, that is purely a matter of architectural convenience resulting mostly from the prevalence of incumbent local carriers and geographic hierarchy. There is no real need for any correlation between the two addressing schemes even though they use the same address format and limitations. > Yea, but what is a surviving TCP good if you put your laptop to sleep > and wake it up somewhere else? It can't pre-announce the next IP address > it will use. Instead at the new location it will have to convince somehow > the remote host that he is he indeed. No way without cryptography. IPSEC > will break too. > There are lots of ways to solve this. Simple X.509 certificate based authentication over a separate stateless service among them. However, if we separate the routing identifier entirely from the endpoint identifier, then, this question is moot except for the generic case of endpoint authentication which we either don't bother with today (mostly) or, which we can use the existing solutions for. > Oops, the remote end switched IP addresses too and you are lost. > Not if we separate endpoint identifier from routing identifier. In that case, we just need to learn the new mapping between the same endpoint identifier and it's new routing identity. > The question is whether renumbering while moving active TCP sessions to > the new IP address is a problem at all other than a nice-to-have dream > of 'propellerhead' Paul? ;) > Well... If you want to get entirely away from PI space in v6 and preserve hierarchical addressing as the primary goal (as stated by the IETF, ICANN, and RIR policies), then, it is an absolute requirement. If you are willing to concede that given the existing implementations, this goal shouldn't be the primary goal any more and there are tradeoffs to be made to meet real world requirements, then, this can become less important. > And the other, more serious, question is whether IP addresses are > something > that you only use temporarily or permanently? > Depends. Endpoint Identifiers need to be something you can use permanently in enough situations that as long as IP addresses are endpoint identifiers I would say permanently (or at least nearly permanently). If we can use something else as endpoint identifiers and use IP addresses strictly as routing identifiers, then, IP addresses can be temporary, and, it is the other endpoint identifiers that must be permanent. > Nonetheless having a simple and easily implementable spec is key to > success and compatibility. I know you can write, hmm, interesting > and complex code... > Have you read the SCTP spec? It is not especially simple, and, I would argue, not particularly easy to implement. How many known interoperable implementations of SCTP exist today? How many can be put in place as a DSO replacement for the existing TCP DSOs? How much recoding is necessary at the application level to get a daemon to listen for both SCTP and TCP connections? How much recoding is necessary at the application level to get a client to attempt and SCTP and TCP connection and use the best one that answers? How much delay is introduced when connecting to an SCTP unaware site that doesn't send back ICMP unreachables for SCTP? >>> KISS KISS KISS KISS !!! >>> Yep... There loses SCTP. > No, they don't mind just using the computer because you set up the > internet > connection. Have them call your favorite ADSL provider and order an ADSL > line and then have them set up some DSLWLAN thingie plus a printer > connected > via ethernet. And using the Apple offerings is cheating, take the average > cheap windooze stuff. > Actually, I have never written an IP stack, but, I've set up lots of internet connections. In most cases, there is no requirement to know how the routing table works to get connected to the internet. Try again. Even if you inflict the pain of doing this in a Whine-D0ze environment (you're right, even FreeBSD is easier these days), using a ZyXel toaster, the web interface to get it all running just isn't that hard. Oh, and, BTW, once you put a complete setup together, the Apple stuff turns out not to be any more expensive than the "cheap" whine-doze stuff. > Because all this worked so well they want to run their own webserver on > their computer and others from the internet should be able to connect... > > You see? Paul may, but, I don't see the relevance of the above statement. If they can get reasonable DNS, this shouldn't be an issue as long as their provider will provide an address that doesn't change rapidly or often. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.

3 3