November 2004 - 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

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

APNIC New IPv6 address block(s)
by John Tran 30 Nov '04

30 Nov '04

Dear colleagues APNIC received the following IPv6 address blocks from IANA today and will be making allocations from this range in the near future. 2001:8000::/19 2001:A000::/20 This announcement is being made for the information of the Internet community, and so that network configurations such as routing filters may be updated as appropriate. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son ____________________________________________________________________ Resources Services Manager <Son(a)apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk(a)apnic.net Please send Internet Resource Requests to <hostmaster(a)apnic.net> _____________________________________________________________________ -- This is the SANOG (http://www.sanog.org/) mailing list.

1 0

RE: size of the routing table is a big deal, especially in IPv6
by Joe Johnson 29 Nov '04

29 Nov '04

I'm sorry, North Korea is in the UN. My mistake. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Joe Johnson Sent: Monday, November 29, 2004 10:25 PM To: Tony Li; nanog(a)merit.edu Subject: RE: size of the routing table is a big deal, especially in IPv6 <Snip> My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term. Tony </snip> What happens to non-member states? What happens to Taiwan, who has not been a part of the UN for decades? Does the island nation of Togo get a prefix, but not Taiwan. Also, what about North Korea? Only South Korea is a member state in the UN. Next thing you know, they'll be trading prefixes for kick-backs . . .

1 0