- Test - lists.nanog.org

elimination of AS690 transit routing
by Steve Heimlich 18 May '95

18 May '95

Folks, With tomorrow morning's configuration run, AS690 will announce only ANS routes (those of ANS customers) to peer providers at interchange points. This will complete the work we started last Friday, when we eliminated third party route reflection at these interchange points. Those providers who are also ANS customers will not be affected. As an example, ANS will no longer announce provider X routes which we hear from the PAC Bell NAP to other providers Y and Z at other interchange points. Those providers who do not peer with either the Routing Arbiter Route Server or directly with provider X may not have connectivity to the provider X set of routes. Steve

1 0

Re: Internic address allocation policy
by Stan Barber 18 May '95

18 May '95

>>> Stan Barber <sob(a)academ.com> 03/23/95 11:46am >>> ORIGINAL DISTRIBUTION: RoseCanyon.RoseCanyon SMTP("digex(a)ss2.digex.net", "gcook(a)tigger.jvnc.net"), RoseCanyon.RoseCanyon SMTP("sob(a)academ.com") //////////// Which NIC are you talking about? The InterNIC has three different faces. One is run by ATT, one by General Atomics and one by Network Solutions. Are you abusing the use of NIC to mean the registration function by Network Solutions? Don't forget the RIPE NCC and APNIC are also NICs that have the authority to issue addresses as well. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Draft internic ip allocation doc
by Daniel Karrenberg 18 May '95

18 May '95

> Juha Heinanen <Juha.Heinanen(a)funet.fi> writes: > > this is a very bad thing, since it forces an ip NETWORK provider also > to deal with the DNS of its customers, not just to assign a pointer to > their DNS. > > when is this problem solved? with ipv6? A draft is due out soon.

1 0

PI vs PA Address Space
by Daniel Karrenberg 18 May '95

18 May '95

> bmanning(a)ISI.EDU writes: > ... > So there is the suggestion that policies be created/enforced to > accomodate problem routing technology? Is this really what we > want to do? That is exactly what my contribution is arguing *against*. It is OK for service providers to not offer certain services, i.e. Internet service for customers using PI space, or charge more for them. It is not OK to enforce stringent policies through address space registration. Daniel

1 0

None
by Jeffrey J. Libman 18 May '95

18 May '95

unsubscribe end |\ +-------------------+ Jeffrey J. Libman | \ | Wantabe, Inc. | Wantabe, Inc. |__\ +-------------------+ jeffrl(a)wantabe.com <-----|------> | www ftp news mail | (713) 493-0718 __,.-=\'`^`'~=-../__,.-= +-------------------+

1 0

Re: Draft internic ip allocation doc
by Vadim Antonov 17 May '95

17 May '95

There is an easy solution -- do not allocate less than /16s. This would relieve InterNIC from caring about IN-ADDRs (and will do good things for routing, too). --vadim All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC. I think you mean shorter, as in: The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes SHORTER than /16 issued directly from the InterNIC. No, I think he means longer. IN-ADDR.ARPA can only be delegated on octet boundaries, so IN-ADDR for /16 and shorter prefixes will be delegated in /16 chunks. IN-ADDR for prefixes longer than /16 must still be maintained by the root, since they cannot be delegated. For example, assume an ISP has been allocated the prefix 204.160/14. Along with this, the InterNIC will delegate the corresponding IN-ADDR domains: 160.204.IN-ADDR.ARPA 161.204.IN-ADDR.ARPA 162.204.IN-ADDR.ARPA 163.204.IN-ADDR.ARPA If the ISP were instead only assigned 204.160.0/17, the associated IN-ADDR range would be: 0.160.204.IN-ADDR.ARPA ... 127.160.204.IN-ADDR.ARPA which is not octet-aligned and therefore cannot be delegated. --Vince

5 4

Re: Draft internic ip allocation doc
by Vadim Antonov 17 May '95

17 May '95

> There is an easy solution -- do not allocate less than /16s. > This would relieve InterNIC from caring about IN-ADDRs > (and will do good things for routing, too). > >Of course that violates the NIC charter as being the NIC of first and last >resort. >--bill Which do we care more -- preserving status quo or keeping the Internet above the water? Sounds like the IPv6 anthem: Oh, yeah, we gonna fix things Without changing anything... --vadim

1 0

Re: Draft internic ip allocation doc
by Vince Fuller 17 May '95

17 May '95

All- Can we move this discussion to either "CIDR" or "NANOG" but not both? Also, I'd appreciate it if my explicit address were removed from the "CC" list - I'm currently getting three copies of each message on this topic, each arriving at wildly different times... --Vince

1 0

Re: Draft internic ip allocation doc
by chris＠connect.com.au 17 May '95

17 May '95

>... > >Well, you can delegate these as 128 individual zones. With a little >bit of automation to help, it may approach practical. You can >delegate a single domain name in the limiting case. But this doesn't really save anything in terms of the amount of work that has to be done by the NICs and probably increases it, as when the ISP's clients want to be primary for their IN-ADDR.ARPA domains, the delegation records will have to be updated to list extra servers. -- Chris Chaundy (Network Manager) connect.com.au pty ltd, P.O. Box 2202, Caulfield, Victoria 3161, Australia Internet: chris(a)connect.com.au Phone: +61 3 9528-2239 Fax: +61 3 9528-5887

3 2

Re: Draft internic ip allocation doc
by randy＠psg.com 17 May '95

17 May '95

> This sounds pretty onerous. If you insist on requirements such as this, > you should be much clearer on what you require, and what form you require > it in. Check out RIPE-124.

2 1