January 1996 - Test - lists.nanog.org

Re: Static IP addresses for Dial-up
by marthag＠MIT.EDU 30 Jan '96

30 Jan '96

> At 09:36 PM 1/29/96 +1100, Robert Elz wrote: > > > > >That sounds like a perfect place for a dynamic address, however, > >if he had that, it would make life harder for me. With his > >static address I can instal filters to give him more access to > >my system at home (which is basically permanently connected, and > >not a PC) than I allow all the rest of you. (For Tony's > >benefit - no, this is not relying on source address filtering, > >I actually filter the packets that my system sends out, I will > >let it send packets to him that I won't let it send elsewhere, > >which has basically the same effect). > > > > I can certainly understand the need for access control & security, but > with the use of a smart-card one-time password system, this is a moot > point. > > - paul You are ignoring the risks of the session being stolen after the password is given. Outbound filters will help this, strong end-to-end encryption will prevent it. Martha Greenberg marthag(a)mit.edu

1 0

Re: multihoming
by Walter O. Haas 30 Jan '96

30 Jan '96

The view from the trenches out here is, multihoming to different ISPs is a necessity. Our biggest lossage is SprintLink problems, *NOT* power or the local loop. XMission bought a link to MCInet in Denver to back up the SprintLink connection thru Westnet, and as a result XMission has far fewer lossages than the Westnet sites that are SprintLink only. -- Walt (not speaking for XMission, just a customer)

1 0

Re: Policy Statement on Address Space Allocations
by matthew＠scruz.net 30 Jan '96

30 Jan '96

Original message <4D07037D30(a)hq.mainet.com> From: "Vincent J. Bono" <VBONO(a)hq.mai.net> Date: Jan 26, 20:57 Subject: Re: Policy Statement on Address Space Allocations > ... > > How about trying to prevent the static assignment of addresses to > dial-in customers? This chews IP space like there was no tomorrow... > >-- End of excerpt from "Vincent J. Bono" Actually, I suspect that's one of the MOST efficient uses of addresses. We fill a handful of class C equivalents with our static-IP single-address dialup customers, but those are filled to capacity and used daily, whereas most of our small-business customers have an entire class C equivalent each, and only have a dozen hosts, if that, on their LAN so far. I feel much better about using 254/256 addresses serving 254 customers than I do about using 12/256 addresses serving 1 customer. As for the whole routing issue, I'm VERY sad to see so many people in support of address assignment and routing policy that effectively locks out smaller providers. Were we starting today, rather than back in 1993, we'd be stuck with our original provider, or face renumbering if we wanted to switch to a higher-performance provider AND connect to MAE-West, as we've done. If word gets out that going with a small provider == having to renumber your corporate hosts regularly, big providers will have effectively locked small players out of the market... which helps their pocketbooks at the expense of a lot of other people. At this rate we're going to see the policy change to "each RBOC gets a /7 out of the old class A space, and then that's it" -matthew kaufman matthew(a)scruz.net

7 10

Re: Have we started to chop up the B-space into /24's.
by postel＠ISI.EDU 30 Jan '96

30 Jan '96

Hmm: Well since the Net 39 experiment proved that it is ok to chop larger class-full address block into smaller class-less address blocks, why not. --jon. From list-admin(a)merit.edu Tue Jan 30 08:19:07 1996 Date: Tue, 30 Jan 96 16:56:54 MET From: Peter Lothberg <roll(a)stupi.se> To: nanog(a)merit.edu Subject: Have we started to chop up the B-space into /24's. Date: Mon, 29 Jan 1996 17:50:09 +0000 From: William griffin <wgriffin(a)mci.net> To: insc(a)sprintlink.net Cc: trouble(a)mci.net, pp000314(a)interamp.com Subject: route not being advertised We have a customer with the following address: 164.103.3.0/24 and it seems that you are not accepting our advertising of it. Could you please adv. -- The darkness illuminates the light. William Griffin Network Engineer wgriffin(a)mci.net (800)977-4662 % whois 164.103.0.0 Telecommunications Department of Information Systems (NET-IPAPER) International Paper Southwind Computer Center 3232 Players Club Parkway Memphis, TN 38125 Netname: IPAPER Netnumber: 164.103.0.0 Coordinator: Harrison, Donald R. (DRH37) PP000314(a)INTERRAMP.COM (901) 748-5459 (FAX) (901) 748-5401 Record last updated on 08-Feb-93.

1 0

Re: Have we started to chop up the B-space into /24's.
by Paul Ferguson 30 Jan '96

30 Jan '96

At 04:56 PM 1/30/96 MET, Peter Lothberg wrote: > >Date: Mon, 29 Jan 1996 17:50:09 +0000 >From: William griffin <wgriffin(a)mci.net> >To: insc(a)sprintlink.net >Cc: trouble(a)mci.net, pp000314(a)interamp.com >Subject: route not being advertised > >We have a customer with the following address: 164.103.3.0/24 and it seems >that you are not accepting our advertising of it. Could you please adv. > >-- >The darkness illuminates the light. > >William Griffin >Network Engineer >wgriffin(a)mci.net >(800)977-4662 > > Hmm. According to WHOIS, 164.103/16 appears to belong to: % whois 164.103 Telecommunications Department of Information Systems (NET-IPAPER) International Paper Southwind Computer Center 3232 Players Club Parkway Memphis, TN 38125 Netname: IPAPER Netnumber: 164.103.0.0 Coordinator: Harrison, Donald R. (DRH37) PP000314(a)INTERRAMP.COM (901) 748-5459 (FAX) (901) 748-5401 Record last updated on 08-Feb-93. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. - paul

1 0

Re: Static IP addresses for Dial-up
by Paul Ferguson 30 Jan '96

30 Jan '96

At 09:36 PM 1/29/96 +1100, Robert Elz wrote: > >That sounds like a perfect place for a dynamic address, however, >if he had that, it would make life harder for me. With his >static address I can instal filters to give him more access to >my system at home (which is basically permanently connected, and >not a PC) than I allow all the rest of you. (For Tony's >benefit - no, this is not relying on source address filtering, >I actually filter the packets that my system sends out, I will >let it send packets to him that I won't let it send elsewhere, >which has basically the same effect). > I can certainly understand the need for access control & security, but with the use of a smart-card one-time password system, this is a moot point. - paul

4 3

Re: so have nanog and cidrd merged???
by Vince Fuller 30 Jan '96

30 Jan '96

if so, let's shoot one and reduce the mail i get by half. if not, let's pick one and use it for this discussion and reduce the mail i get by half. Amen to that. I just flipped a coin to decide which list to use and it came up tails, for NANOG. Please send all further followups only to NANOG. --Vince

1 0

Re: Static IP addresses for Dial-up
by Paul Ferguson 30 Jan '96

30 Jan '96

[cc: trimmed to nanog] At 07:50 PM 1/30/96 +1100, Robert Elz wrote: > >I also know that there are attacks that can be made without >requiring return packets at all - those I have to deal with >in other ways (smart card password schemes most certainly >aren't it) regardless of what kind of address (statically >assigned, or dynamically assigned) my brother gets. > Yes, I understand completely. Actually, we could go back and forth like this forever, punching holes in secure access control methods. Let's just agree that without strong end-to-end encryption, its all swiss cheese. :-) - paul

2 1

Re: on a lighter note...
by Kent W. England 30 Jan '96

30 Jan '96

At 11:49 AM 1/27/96 -0800, Hans-Werner Braun wrote: >Regarding the NANOG meeting. ... so don't leave home without your PCMCIA card. >Though I will only install the access points if people ask for it. >Y'know, people who don't always want to depend on cables. > >By the way, I would also be interested hearing from people having >experience with other wireless products. > > I find that 10BaseT works pretty well for my portable needs. Can you pre-assign us some IP addresses? --Kent

2 1

Re: Chiappa blows his brains out (was Re: Policy Statement)
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

<There's an interesting point in the middle of this, about how multihoming presents technically rooted problems no matter *how* we do the addressing, even if we solve the conflict he mentions, and that these problems have an impact on what policies it is useful to discuss...> From: "Joel M Snyder, writing fool" <Joel_M_Snyder(a)opus1.com> GIVEN that I have sufficient knowledge about routing as is necessary to fully understand every technical issue involved Sorry, I guess I just assumed the wrong interpretation of what your question was about. (Also, to be honest, if we've got to the point that most everyone understands these issues, I guess it's time for the champagne... :-) GIVEN that I have a rudimentary and imperfect understanding of the political and economic issues regarding IP numbering and the propagation of routes thereunto I'm not sure anyone has a truly "global" view of this, although if one listens on this and other lists hard, one can start to get a view which integrates the large and small ISP's, equipment suppliers, etc, etc... GIVEN that there exists some set of organizations who want to purchase multiple T1s from multiple independent suppliers ... HOW do I resolve the conflict between justifiable corporate service requirements and the expressed statements ... that anyone who does not consume at least a /18 worth of address space is not worthy of being globally routed? To start with, this is another case where setting the size-based filter for routing updates is having deleritous effects. Again, all we're doing is creating a demand for address space, and as long as there is no well-modulated back-pressure on address space (such as charging for it), I'm not sure I see any easy way of dealing with it. Second, whether it's a /18 or a /24 is of no interest to the routing. Let's assuming we can separate the addressing issues out, to focus just on the routing cost, which is going to be the same *regardless* of how you resolve the address space issues. This is important: *** No matter how you do the addresses, you *still* have the problem that if *** a significant percentage of customers want to be multihomed, and we still *** don't have any mechanism or tools for reducing the scopes of those *** advertisements from global (such as I mentioned in my original message on *** this thread), we will find it technically impossible to provide this *** multihoming capability to a large number of users: we will be rerunning the *** very routing table growth (tracking local sites individually) that caused *** us to go to CIDR in the first place. I don't know about you, but I could do without a re-run of that particular learning experience! :-) Ideally, in solving this, I would take a monetary approach, which is to say "what are the true costs of this multihoming, and given that, is it important enough to the client for them to pay for it", but of course we don't have a charging mechanism for routes that would help to answer this, and maybe never will. So, I can't use that copout. Maybe a better question is to ask "what goal are they really after with multi-homing", because if the answer is "reliability", then perhaps they get more bang for their <insert-local-currency> with things like multiple access lines, etc. I am asking, I suspect, not for a technical answer (there being none other than Chiappa's "it's gonna cost"), but the most politically correct answer to give the organization I understand that you have a very "bottom-line" concern, which is "what do we tell the customer", but I hope that this time I have made clear to everyone that there is no solution to the technical question of "can we provide multihoming on a large scale", *at least in the system as it stands today*. (I.e. if this is an important goal we need to get cracking on technical solutions...) Any policy discussion must take place in an environment which is aware of this technical constraint. Thus, your question about the policy conflict you pointed out is interesting and true, but ultimately not a critical one... Noel

1 0