- NZNOG - lists.nznog.org

Re: NZGATE addressing within NZ
by craig＠laptop.iprolink.co.nz 11 Oct '98

11 Oct '98

Hi. > Craig, all of the recent (post 1996) RFCs and IETF drafts that I have seen > make it clear that address portability is inconsistent with having a > routable Internet. The regional registries all have policies to > reduce route table fragmentation by migrating organisations to provider > addressing. I'm suggesting we attempt to address historical address portability where it was rightfully assumed and that we do not attempt to force migration. Also clarification of the "ownership" of the NZGATE addresses would seem to be in order as there seems to be some dispute and confusion there. > I think Joe pretty much assumed that ISPs were aware of the potential > problems with portability. If any of the major upstream providers of the > New Zealand providers begin to filter small advertisements (say, smaller > than /20) then a lot of NZ organisations with "portable" addresses > could potentially be cut off from the rest of the world. This is pretty unlikely. It would cut off major and important sections of the Internet, including most root name servers. Sprint unilaterally began filtering longer prefix routes several years ago but not those in ranges in use prior to widespread discussion of provider blocks (i.e. they have never filtered out NZGATE prefixes shorter than or equal to /24). Also, routing table growth has slowed because of the introduction of CIDR, the use of provider based addressing, and (proxy) aggregation. Routing table growth for the past three years (~1.7x) has been much slower than router CPU and memory growth and this trend is likely to continue. With it becoming increasingly easier to handle all routes, such action is now unlikely for technical reasons. The dampening used by some providers does tend to cause /24's to incur longer blocking than a /20 would as a result of flapping. But beyond this it's hard to see any potential problems with the portability of the NZGATE addresses (and many are in blocks larger than a /24 anyway). > You can be sure that many of these small routes are not carried globally > and only have connectivity because the origin of the supernet routes gets > the traffic close enough to a provider that doesn't filter. For NZGATE addresses, i do not believe this is factual. In addition to my general moaning, the draft specifically penalises many older ISPs (by making the addresses of their servers non-portable) does not address multi-homed use, and does not provide exceptions where portability is reasonable. How about policies based more roughly around these ideas: Those who obtained addresses directly from Waikato with the legitimate understanding they were portable should be treated as portable (/23 or shorter automatically qualifies). Addresses obtained from an ISP are not portable and should not be advertised by another ISP (except by agreement). No provider is allowed to advertise supernets that overlap another providers advertisements (except by agreement). -Craig --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

4 7

NZGATE addressing within NZ -Reply
by Donald Neal 08 Oct '98

08 Oct '98

Problems in getting small allocations advertised have been foreseen for years. Are we actually at the stage where we're seeing international carriers refuse to advertise anything, say, below a /18? - Donald Neal --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

NZGATE addressing within NZ
by Joe Abley 07 Oct '98

07 Oct '98

Hi all, I have prepared a VERY DRAFT paper in an attempt to clarify the situation regarding IP addresses delegated historically by NZGATE, and to describe one possible approach for bringing the current situation into line with current policies of provider-based addressing. This is only one possible solution. This document is DRAFT. This document does not attempt to define policy; it is merely intended to provoke some useful discussion. >From some informal conversations on the subject it would seem that there is a widespread interest in eliminating the ambiguity that has existed on this topic, and in agreeing a strategy to allow a transition to provider- based addressing to proceed as rapidly as is practical. Please distribute this document as widely as you care to. Comments, criticism, flames and threats back to the list please, so everybody can enjoy them :) Thanks to Andy Linton and John Houlker for useful feedback and comments on earlier, even more primitive drafts. Note that any factual errors or ommisions on this history of the NZ internet are mine. The spelling mistakes are all Andy's fault, however :) Copies are available at http://www.patho.gen.nz/~jabley/nznumber.txt Joe -- Joe Abley <jabley(a)clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ -------------------------------------------------------------------------- IP Addresses delegated from "NZGATE" in use within New Zealand 1. The problem 1.1. Overview RFC2050 documents the best current practice for address delegation for the global Internet. It imposes a framework of restrictions driven by a growing scarcity of globally-unique IP addresses and a need to summarise or aggregate routing advertisements globally to keep the Internet running reliably. The history of the Internet in New Zealand includes, at an early stage, a single domestic provider known as "NZGATE". This provider was facilitated by the University of Waikato, with international connectivity to NASA. Initially, NZGATE provided the sum total of international Internet connectivity for New Zealand. The regional authority for IP address allocation, APNIC, delegated a number of address ranges to NZGATE [3.1]. Early entrants to the Internet community in New Zealand, obtaining transit through NZGATE, were delegated address space out of these blocks according to the guidelines set down by APNIC and, indirectly, IANA. NZGATE faded out of existance in 1996 [3.2]. Since that time additional providers have added global internet transit using dedicated international circuits to their portfolio of products, including (in no particular order) Netway, IBM, CLEAR, IHUG, Telstra NZ and Voyager. Most of these participants have obtained address delegations directly from an appropriate regional registry, as they are diversely connected and don't favour a single provider for "default routing". Newly-connected customers of these transit providers (be they end users or resellers, i.e. ISPs) have been delegated address space by their providers, from the blocks delegated to those providers from APNIC, according to RFC2050. If these customers change providers, they are obliged to return the address delegations to their old provider, and obtain corresponding new ranges from their new provider. 1.2. Issues 1.2.1. Stability and RFC2050 It is extremely important from a technical standpoint that provider-based aggregation and delegation is adhered to for all customers who do not meet the criteria for operating under addresses delegated directly from APNIC. 1.2.2. Impact on end-users Renumbering can be an expensive exercise for some end users, especially those whose networks have evolved for some years. In the early days of the Internet in New Zealand, provider-based addressing was not part of the network design. Provider-based addressing first came under discussion as a solution to problems of scale, and only gradually moved from being a radical departure from good practice to an accepted reality. The evolutionary nature of this change was good in the sense that the impact could be somewhat tuned to the timeline of the allocations and expectations, but was bad in the sense that the moving situation added to the complexity and uncertainty. Many established end-user networks were built without the expectation that the IP addresses delegated to them were tied to a particular provider. Now that provider-based addressing is widely recognised as best current practice and is required by the regional registries, the requirement to renumber upon changing provider is still widely misunderstood. It is worth noting that there was no way that NZGATE (or any other ISP at the time) could solve all the issues of address portability raised by the addressing policy changes sweeping across the internet. Many NZGATE-numbered end-users may already have changed providers without renumbering, reinforcing the unfortunate myth that the NZGATE addresses they are using are still inherently portable, and "owned" by them. Although some providers now include clauses in their customer contracts underlining the point that addresses delegated as part of service delivery must be returned at the end of the contract, this is by no means universal, and the myth of "customer-owned IP addresses" lives on. It is imperative going forward that the concept of provider-based addressing and the non-portability of most network numbers is widely publicised amongst end-users. 1.2.3. Impact on national providers For ISPs that obtain global transit through other providers, and who have not arranged address delegations directly from APNIC, renumbering may be just as onerous as for end-users. Additionally national providers may supply end-users for whom renumbering is expensive, and the associated inconvenience mentioned in [1.2.2] is cumulative. 1.2.4. Competitive advantage There has been a misconception within the NZ Internet community that Netway communications (and, latterly, NetGate/Telecom NZ) assumed the NZGATE role by providing connectivity to the Waikato network in early 1996, and by virtue of this fact the addresses delegated by APNIC to NZGATE are now, by proxy, effectively delegated to Telecom NZ. This does not appear to be a view held by others involved in the "transition" [3.2]. More accurately, for a time Netway was the sole provider to NZGATE, and hence also to all downstream networks of NZGATE. This situation soon changed, with other providers bringing international transit to NZGATE subscribers, and NZGATE slowly faded out of existance leaving end-user networks direct customers of the new international providers. It is not at all obvious that any single provider can lay legitimate claim to operational responsibility of the NZGATE blocks. The effective use of these addresses as "portable" between providers over the past few years is not compatible with a delegation model whereby it is acceptable for NetGate customer networks to use them, but not acceptable for a customer of another provider. In effect, an expectation has been raised by Telecom NZ that customers who have been happily numbered under NZGATE addresses (and have used a variety of ISPs for some time) are now faced with a choice of (a) renumber, or (b) change providers to NetGate/Xtra. Due to the operational cost of renumbering, this gives Telecom NZ competitive advantages over other ISPs based on the contentious belief that Telecom has assumed operational responsibility for the NZGATE address blocks. Many address ranges delegated from the NZGATE blocks, although well documented at the time, have since been unofficially "transferred" to other operators, or are not currently in use. Hence documentation of the current state of NZGATE delegations is out-of-date. The operational responsibility for the NZGATE address blocks, when coupled with a lack of documentation for past delegations is, in fact, a hindrance to Telecom NZ, as it makes strict compliance with APNIC policy for the delegation of additional address blocks far more difficult. 1.3. Unified approach It is in the interests of all providers within NZ that a solution to the problems outlined in this document be found. It is also important that no single provider is seen to be responsible for what may be seen by end-users as restrictions, or inconvenient changes of policy. By taking a unified approach to the problem with a policy document agreed by the majority of New Zealand providers, the risk of confusion is minimised and the chances of productive user education are increased. It is proposed that the unified policy be agreed as an operational exercise within the provider community, by the usual open discussion within the NZNOG forum. 2. One possible solution 2.1. Overview The proposed solution attempts to minimise the risks discussed in [1.2], whilst providing a clear migration path towards full provider-based addressing within New Zealand. 2.2. Rationalisation of historical NZGATE delegations A list should be generated (and published) documenting subnets of the NZGATE blocks [3.1] which are in use at some agreed time. All blocks being so-used should be documented. If the sections of the NZGATE blocks in use by Telecom/NetGate/Xtra infrastructure (and not by end-users of Telecom/NetGate/Xtra) are conveniently contiguous, it will make sense to re-designate those blocks as delegated to Telecom rather than "NZGATE". On the other hand, if it transpires that the NZGATE blocks are overly fragmented to make this impractical, Telecom should approach APNIC for a further, distinct address delegation. 2.3. Administrative control of NZGATE blocks returned to APNIC All NZGATE-derived subnets not in use at the agreed time should be returned to APNIC for administration. No further delegations from the NZGATE blocks should be permitted by any NZ provider. To enforce this, providers in NZ may apply route filters to prevent the use of non-approved NZGATE address ranges. 2.4. Forced renumbering No end-user network using NZGATE subnets should be obliged to renumber as part of the normal course of their operation (but see [2.5] and [2.6]). 2.5. Process for extending address space delegations Any end-user network which needs additional addresses due to growth should be obliged to renumber with provider-based addressing in order to obtain their larger address range. The released NZGATE addresses will be returned to APNIC by the ISP. 2.6. Process for managing ISP-hopping by end-user networks Any end-user network that uses NZGATE numbers and decides to change ISPs must renumber using provider-based addressing provided by the new ISP. The released NZGATE addresses will be returned to APNIC by the former ISP. 2.7. Process for managing ISP-hopping by national providers Any national provider that uses NZGATE numbers and decides to change global transit providers must renumber its own infrastructure using provider-based addressing provided by the new global transit provider. Customers of the national provider who use NZGATE numbers will not be required to renumber (but see [2.5], [2.6]). 3. References 3.1. Netblocks delegated historically to NZGATE-NZ The addresses concerned have all been delegated from within the NZGATE-NZ networks as recorded at APNIC, which are described as: netname: NZGATE-NZ descr: NZ Gate National Service Provider descr: Component of University Of Waikato descr: New Zeland The netblocks currently assigned to NZGATE-NZ are: inetnum: 202.27.0.0 - 202.27.255.255 inetnum: 202.49.0.0 - 202.49.255.255 inetnum: 202.50.0.0 - 202.50.255.255 inetnum: 202.36.0.0 - 202.37.255.255 inetnum: 203.96.0.0 - 203.97.255.255 The netblock 203.96.0.0 - 203.97.255.255 is perhaps erroneously attributed to NZGATE-NZ here - in fact, this block was delegated to an APNIC confederate member, NZNIC, operated by the University of Waikato. NZNIC no longer operates [3.2]. 3.2. Transition of NZGATE services to other providers The following message outlines the events surrounding the transition of international internet transit from NZGATE to other providers in early 1996, as recalled by John Houlker of Waikato University (quoted with permission). From: John Houlker <john(a)waikato.ac.nz> To: ccc_rex(a)waikato.ac.nz, "'Joe Abley'" <jabley(a)clear.co.nz> Cc: asjl(a)netlink.co.nz, Jamie Clark <jclark(a)clear.co.nz>, Roger Hicks <rhicks(a)clear.co.nz> Subject: RE: [jabley(a)clear.co.nz: NZGATE-NZ] Date: Tue, 22 Sep 1998 16:38:45 +1200 X-Mailer: Internet Mail Service (5.5.2232.9) Joe > I would be very interested to hear your views on my original e-mail, which > is attached; in particular relating to Brett Telfer's comment, quoted in > the Herald: > > "Netgate service specialist Brett Telfer says most of the Waikato > University provided IP addresses passed to the Telecom subsidiary when > it took over the running of NZ Gate in late 1995." > > It was my understanding that NZ Gate had ceased to exist in its former > role, rather than being subsumed into Telecom? Telecom (i.e., Netway) did not "take over" NZGate, but nor did NZGate instantly "cease to exist" (such a step was simply not possible). Netway did become NZGate's supplier for a significant period while NZGate gradually reduced out of existence (I believe this started in January 1996). At the time NZGate shut down its international links this was phased with the introduction of commercial providers offering international capacity at the NZIX, but it was a complex transition with Telecom and Clear only slowly coming to grips with international IP services, and NZGate clients only slowly working out what they should do. The NZGate international circuit contracts came up to expiry in January 1996 (and we were in no position to renew for a further 12 months) and the NASA "PACCOM" access was supposed to cease in February 1996 (in the event it didn't, but we could not count on further access to the NASA FIX-WEST gateway beyond that date). We were not in a position, however, to disperse all the NZGate customers to direct supply from the newly establishing commercial suppliers (Clear made a late start with limited bandwidth, pricing was still under negotiation, all this was proving harder for the new entrants than they expected). Indeed we were asked to keep NZGate going to give our clients more time to sort out alternatives. As a result NZGate continued as a reseller, i.e., an intermediate IP provider, and we bought our international supply from Netway (our only option at the time). The University network "Kawaihiko" ceased being a customer of "NZGate" and moved to buy directly (also from Netway). As you know, somewhat later Kawaihiko took the considerably more complicated step of "multi-homing", buying from Netway and Clear in parallel (and later again, also from Telstra). In this way Netway "inherited" the NZGate address blocks as they were at that time - since they became suppliers to the remains of NZGate, and Kawaihiko (and they later picked up the then "CRINET" and AgNet as well). I would be interested in your comments, I haven't seen the Herald article, but it does sound like there are sites that don't yet know the implications of moving provider. In terms of the old blocks of former NZGate addresses it could indeed be most useful to get special treatment from the APNIC to allow greater flexibility in on-going devolution of the original NZGate group. As things stand Telecom have no option but to comply with APNIC requirements on efficient use of address space (this does not apply to the "NZNIC confederation" space that Waikato allocated to ISPs - in an attempt to assist portability - i.e., 203.96.0.0/15, which is entirely independent. Whether or not the APNIC would agree to a special approach here, it seems there may be existing customers of Telecom (or of ISPs using Telecom) who aren't yet aware of the portability issues. If not, perhaps some publicity drive out of Telecom and/or perhaps NZNOG contacts could spread the word. I asked Jim Higgens if ISOCNZ has good contacts to spread information to ISPs but I gather that (especially given the demise of ISPANZ) NZNOG may be the best shot. John 4. Contributors Joe Abley, CLEAR Communications Ltd <jabley(a)clear.co.nz> John Houlker, Waikato University <j.houlker(a)waikato.ac.nz> Andy Linton, NetLink Communications Ltd <asjl(a)netlink.co.nz> 5. Document History $Log: nznumber.txt,v $ Revision 1.4 1998/10/08 09:23:46 jabley Some further clarification Revision 1.3 1998/10/08 09:01:42 jabley Modifications following comments from jhoulker Revision 1.2 1998/10/08 00:22:36 jabley minor typo corrected as pointed out by wellingtonian pedant Revision 1.1 1998/10/07 13:01:32 jabley Initial revision --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Route servers on Citylink (WIX)
by Simon Blake 07 Oct '98

07 Oct '98

Hi Folks For the last couple of months I've had a linux box running the MRT route daemon as an experimental BGP route server, with links between a few organisations on Citylink who were happy to participate in a trial. The main aim of the experiment was to consider ways that Citylink connected organisations with BGP capable routers but without AS numbers might exchange routing data, so that they can send data directly between each other, without having to go through one (or several) ISP routers. As a rudimentary route server, MRT seems to work really well (it lacks some of the RIPE tools of the Merit RA, but on the other hand, it compiles under Linux :-). We ended up setting up MRT to peer with the organisations who had AS numbers, and then setup all the other routers in AS number 65502 (chosen at random) as static routes within MRT, and redistributed them into BGP. Turn off synchronisation on the routers in AS65502, and everything seemed to work as advertised (this is speaking from memory, I haven't looked at it for about 6 weeks). Citylink is now at the stage where we've got customers pestering us to incorporate them into the system, and a management itchy keen to take some money off of these people. So I guess what I'm after from the list is some opinions on whether this is a good idea, and I'm on the right track. Obviously, for this to be more than a toy I need the ISP's on Citylink to participate in such an exchange, so recommendations on making it easier for them to be involved are welcome. Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

4 5

Re: Route servers on Citylink (WIX)
by craig＠laptop.iprolink.co.nz 07 Oct '98

07 Oct '98

Hi. > The main aim of the experiment was to consider ways that Citylink > connected organisations with BGP capable routers but without AS numbers > might exchange routing data, so that they can send data directly between > each other, without having to go through one (or several) ISP routers. Don't ICMP redirects handle this just fine? There are legitimate security reasons for disabling these, but has anyone actually disabled them, or asked clients to disable them? I've never really had the feeling that anyone was very concerned about security on Citylink (i could be wrong) anyway. If we have ICMP redirects do we actually need BGP between anyone except ISPs and other multiply connected organisations? Can't we use layer 3 ethernet switches (and possibly monitoring) to greatly improve security in general, lessen the risks with responding to ICMP redirects, and thus address this issue much more easily? -Craig --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

4q98 in-addr.audit notice #2
by bmanning＠ISI.EDU 01 Oct '98

01 Oct '98

Hello, This is the second notice for this audit run. I am sorry for duplicates that you may receive. This is to let you know that I will be starting the next quarter sweep of the in-addr.arpa tree on 03 oct 1998 UTC. Thats about 8 hours from now. I'd appreciate it if you would review http://www.isi.edu/div7/people/bmanning.home/in-addr-audit.html for details. Specifically, I'd appreciate your adding the two referenced probes to your xfernets directives so that a valid audit may proceed. The run may take as long as 600 wall-clock hours. The results will be posted to the web page. If there are any questions, please feel free to contact me. If there are others that you feel should be aware, forward the information on to them and/or me. Thank you for your consideration. --bill (call before you dig) manning --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

WIX interface - full- or half-duplex?
by Joe Abley 27 Sep '98

27 Sep '98

Should we be running our WIX-facing interfaces half- or full-duplex? We are using 10baseT from the CNHL-supplied media converter... Joe -- Joe Abley <jabley(a)clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

4q98 in-addr.audit notice
by bmanning＠ISI.EDU 24 Sep '98

24 Sep '98

Hello, I am sorry for duplicates that you may receive. This is to let you know that I will be starting the next quarter sweep of the in-addr.arpa tree on 03 oct 1998. I'd appreciate it if you would review http://www.isi.edu/div7/people/bmanning.home/in-addr-audit.html for details. Specifically, I'd appreciate your adding the two referenced probes to your xfernets directives so that a valid audit may proceed. The run may take as long as 600 wall-clock hours. The results will be posted to the web page. A target for this audit run is to attempt to identify DNS version distribution. If there are any questions, please feel free to contact me. If there are others that you feel should be aware, forward the information on to them and/or me. Thank you for your consideration. --bill --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

MX'ing to 127.0.0.1
by Simon Blake 24 Sep '98

24 Sep '98

Hi Folks Over the weekend some fairly disreputable types in the US sent a whole pile of spam out with fake From: lines which resolved to a server I administer in Wellington. Since the hostname in question (city.wellington.net.nz) has no users and doesn't actually receive any legit email, my first response was to MX it to a spare IP# on our network so that I didn't have to deal with the many (~100K) bounce messages. Upon further reflection, in occured to me that an even better technique for avoiding traffic bills would be to MX city.wellington.net.nz to 127.0.0.1, which I did, and all my spam problems have gone away :-). My question - is this a dodgy thing to do, have I missed some critical reason why I shouldn't do this? Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

5 15

Re: MX'ing to 127.0.0.1
by Michael Newbery 21 Sep '98

21 Sep '98

On Tue, Sep 22, 1998 at 02:11:09PM +1000, Dean Pemberton wrote: > > On Tue, Sep 22, 1998 at 03:56:42PM +1200, Chris Wedgwood wrote: > > > On Tue, Sep 22, 1998 at 03:38:16PM +1200, Joe Abley wrote: > > > > > > > Unless the remote site happens to have a machine on their internal > > > > network, reachable by their mail relay, numbered 10.99.98.97 :) > > > > > > 0 chance of having that. (Statistically speaking, allowing for > > > rounding errors). > > > > Guess we're right off the end of the bell curve then :) How about... > > > > 127.0.0.2? > > 'fraid not - there are devices that use 127.0.0.2 as a valid address. To paraphrase the Hitchiker's Guide: "this is some new meaning of the term 'valid' with which I was hitherto unacquainted" I guess what you REALLY want to do is locate the address used by the spammers and MX that. ;-) --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1