May 1995 - Test - lists.nanog.org

Re: Will there be mbone ?
by Sean Doran 19 May '95

19 May '95

>When can we start having virtual meetings *just* like that? >And avoid travel. I think you want mbone(a)isi.edu and the remconf list. :-) Besides, some of us happen to *like* travelling and meeting face-to-face. Sean.

1 0

Re: Draft internic ip allocation doc
by Geoff Huston 19 May '95

19 May '95

Sean, lets see now ... cut.. paste.. you're only doing this to keep your customers locked in place because you're an evil greedy bastard! ok its out of the way - now can we progress onto what this implies in terms of inter-ISP routing alignments? geoff

1 0

Re: Internic address allocation policy
by Nathan Stratton 19 May '95

19 May '95

On Wed, 3 May 1995, Karl Denninger wrote: > Until then it is none of their damn business, and that is and was my exact > response to the request. Yep Nathan Stratton CEO, NovaNet, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NovaNet, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales(a)novanet.com Arlington, Va. 22201 WWW http://www.novanet.com/ Access: (703) 524-4802 guest ---------------------------------------------------------------------------

1 0

Re: Draft internic ip allocation doc
by bmanning＠ISI.EDU 18 May '95

18 May '95

> > > 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. > > 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? > No, the problem is solved, just not widely deployed. There is no requirement to delegate on octet bounds anymore. -- --bill

3 2

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