- Test - lists.nanog.org

Re: Cable Modem [really more about PPPoE]
by Daniel Senie 26 Jun '01

26 Jun '01

At 12:21 PM 6/26/01, Steve Schaefer wrote: >On Tue, 26 Jun 2001, Fletcher E Kittredge wrote: > > > > > On Tue, 26 Jun 2001 10:28:16 -0400 (EDT) Chris White wrote: > > > DHCP alone is not a viable option in this model. How do you get the end > > > user traffic to the ISP and back in a pure IP environment? Policy > routing, > > > GRE, MPLS, force your ISP customer to interconnect at every location, > > > etc.? > > > > Hello Chris; > > > > You provide frustrating few details and a statement "DHCP alone is not > > a viable option in this model." Could you restate more concretely > > what is your design problem which can only be solved by > > ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some > > constraint I don't know about. > >The constraint is that outbound packets need to go to the right ISP. That >is, the packets need to go through the carrier network according to the >business relationship, not according to the destination IP address. This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet sells services to LOTS of ISPs from all of its POPs. The RADIUS authentication has to get to the proper ISP, but the traffic certainly does NOT travel to the ISP's network before going out into the world. Traceroutes from your dialup account will show that the traffic goes directly. UUNet charges the ISP a fee for the use of the dialup, and UUNet provides a relaying of the RADIUS traffic to the right ISP, and provides transport for the end user's packets. The same scenario COULD be used in DSL or cable setups. That's not to say that it will be. >Some method of identifying the ISP associated with each outbound packet is >necessary. Policy routing, tunnels and PVC's are a few methods. VLAN >tagging works, too. Right. Assuming the business model where the ISP actually handles the traffic. ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranth.com

3 2

Re: SBC Contract Post (fwd)
by owen＠dixon.delong.sj.ca.us 26 Jun '01

26 Jun '01

And, of course, we all know how well BOCs (Bell Operating Companies) and other incumbent LECs (Local Exchange Carriers) follow such rules. The problem is that most of these safeguards are not really enforceable, and the telecom providers violate them at will. Heck, look at how easily Pac Bell was able to drive MCI out of the local telco business in California by dragging their feet on service/install requests, making repeated mistakes in the process, etc. (Yes, Pac Bell makes mistakes with their own customers as well, but these were mistakes that looked suspicious, even compared to Pac Bell's usual level of incompetence). SBC is one of the scariest, slimiest, sleaziest organiziations I've ever run up against. They truly fit the definition of Telco someone posted a while back (A law firm with a side business in telecommunications). They have certainly violated most, if not all, of the safeguards mentioned below, and their new contract certainly violates the spirit, if not the letter, of said same safeguards. Owen > Robert Cannon of cybertelecom.org asked I submit > this re: the SBC Contract thread.... > > ---------------- > > In proceedings going back to 1966 known as the Computer Inquiries, > the FCC established a series of safeguard rules that create ISP > rights to telecommunications. The Computer Inquiries first divided > the world into Enhanced Service Providers (aka computer networks, > ISPs, information service providers) and basic telecom. Enhanced > service providers are unregulated by the FCC. But acknowledging > the dependency of ESPs on the underlying telecom monopoly (remember > this is 1970s and 1980s), the FCC created a series of safeguards. > > The safeguards require all facilities based telecom carriers who > offer ISPs services to unbundle the services and offer them to > independent ISPs on the same terms and conditions. BOCs have added > requirements; they can elect to have an ISP through a separate > subsidiary (Computer II) or they can have an integrated ISP if they > file a comparably efficient interconnection plan (Computer III). > BOCs, regardless of whether they have an ISP, were also required > to create Open Network Architecture plans, breaking their networks > down to basic building blocks for the benefit of ISPs. > > Additional safeguards that generally fall on all carriers include > prohibitions against discrimination, requirements that line > provisioning be completed in the same time frame, cost accounting > rules, prohibitions against cross subsidization, requirements > for network information disclosure, and restrictions on the use > of customer information. > > I have created a white paper entitled "Where ISPs and Telephone > Companies Compete: A Guide to the Computer Inquiries, Enhanced > Service Providers and Information Service Providers." It is > available at http://www.cybertelecom.org/ci/ciii.htm#guide It > explains these rules as they exist today. > > -B > __________________________________________________ > > > -- > A host is a host from coast to coast.................wb8foz(a)nrk.com > & no one will talk to a host that's close........[v].(301) 56-LINUX > Unless the host (that isn't close).........................pob 1433 > is busy, hung or dead....................................20915-1433 >

2 1

SBC Contract Post (fwd)
by David Lesher 26 Jun '01

26 Jun '01

Robert Cannon of cybertelecom.org asked I submit this re: the SBC Contract thread.... ---------------- In proceedings going back to 1966 known as the Computer Inquiries, the FCC established a series of safeguard rules that create ISP rights to telecommunications. The Computer Inquiries first divided the world into Enhanced Service Providers (aka computer networks, ISPs, information service providers) and basic telecom. Enhanced service providers are unregulated by the FCC. But acknowledging the dependency of ESPs on the underlying telecom monopoly (remember this is 1970s and 1980s), the FCC created a series of safeguards. The safeguards require all facilities based telecom carriers who offer ISPs services to unbundle the services and offer them to independent ISPs on the same terms and conditions. BOCs have added requirements; they can elect to have an ISP through a separate subsidiary (Computer II) or they can have an integrated ISP if they file a comparably efficient interconnection plan (Computer III). BOCs, regardless of whether they have an ISP, were also required to create Open Network Architecture plans, breaking their networks down to basic building blocks for the benefit of ISPs. Additional safeguards that generally fall on all carriers include prohibitions against discrimination, requirements that line provisioning be completed in the same time frame, cost accounting rules, prohibitions against cross subsidization, requirements for network information disclosure, and restrictions on the use of customer information. I have created a white paper entitled "Where ISPs and Telephone Companies Compete: A Guide to the Computer Inquiries, Enhanced Service Providers and Information Service Providers." It is available at http://www.cybertelecom.org/ci/ciii.htm#guide It explains these rules as they exist today. -B __________________________________________________ -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

straw poll for multi-homed operators
by Joe Abley 26 Jun '01

26 Jun '01

[number 5 in a series of unscientific surveys] If you currently multi-home between two or more providers using IPv4: + why do you do it? What are the high-level goals you are hoping to achieve? Are you finding that you are achieving them? + how often does your traffic shift between transit providers due to a failure of some kind triggering a re-homing? + how often do you manually shift traffic, and why? Just inbound traffic? Or outbound too? + what impact does a manual or automatic shift in traffic between providers have to your users? Do their TCP sessions break? Or do you think they normally stay alive, maybe after a delay? What makes you think this? + what is *bad* about the way that multi-homing works in IPv4? + what is good about it? Context is an attempt to nail down some requirements for a multi-homing architecture in IPv6 (one that doesn't incorporate exciting up-and-to-the- right state explosion in the DFZ). I can summarise private replies if there is interest. http://www.ietf.org/html.charters/multi6-charter.html http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements… http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt Joe

1 0

History of 24/8 (was RE: for folks tracking DDOS sources or reading the GRC attack log)
by David R. Conrad 26 Jun '01

26 Jun '01

[Long, boring, and not much operational content. You are warned] A bit of biased history: Long ago, in an Internet very different than today's, Jon Postel was convinced by people with more than a little knowledge about such things that this "IP over Cable TV infrastructure" idea might actually take off. In fact, he was convinced that it was going to work so well that all the Cable TV providers all over the world were going to besiege the IANA like a biblical swarm of locusts and Jon would spend all his time fending off requests for huge blocks of addresses. My understanding of why things went to the IANA was that @Home was rejected for a large block of address space and they appealed to the IANA (as was the policy in those days). After much discussion, multiple requests for more information, proof, first-borns, etc., Jon agreed that the IP over CATV infrastructure model of operation was sufficiently different that it justified special treatment (the argument being, to my understanding, that IP over CATV provided something new at the time: always on end user service). The convincer (I'm told) suggested that the Cable TV industry was going to form a trade association that would handle industry coordination requirements like, oh say, allocation of IP addresses. Jon decided to allocate 24/8 to this (at that time not-yet-existant organization) with the understanding that all IP over CATV infrastructure address requirements were to be managed by this new trade association once it was formed. Until it was formed, the IANA would authorize ARIN (InterNIC at the time, I believe) to allocate address space out of the 24/8 block. Of course, history has shown that no such organization was formed (if you assume AT&T is not that organization). Anyhow, when APNIC, InterNIC, and RIPE-NCC found out about all this, we all expressed significant unhappiness as we didn't think there was any significant difference between a IP over CATV provider and any other ISP. However, what was done was done and it would've been a bit difficult to get @Home to return the block since they'd already allocated a bunch of customers to it. APNIC gave IP over CATV ISPs the option of allocating out of normal APNIC space or forwarding their request to the IANA. I think one request was forwarded to the IANA for an IP over CATV provider (but my memory is hazy). Not sure if RIPE-NCC forwarded any requests. After a while, I saw 24/8 as just another InterNIC/ARIN block, albeit one with a weird genealogy. At the time, 24/8 was pretty controversial. Many of the loons whinged and moaned about the unfairness of it all, making all sorts of bogus claims like @Home got the entirety of 24/8, that Jon was biased about the allocation since he worked with many of the @Home principals, etc. But then again, the loons whinge and moan about pretty much anything. Controversy flared up over this more recently when ICANN used 24/8 as an example of RIR-independent address space that would justify ICANN doing allocations of address space themselves. Suffice it to say that this was a poor example. Now, isn't that more than you ever wanted to know? Rgds, -drc (who played a small role at APNIC in a previous life) At 02:24 PM 6/26/2001 +1000, Bruce Campbell wrote: >On Mon, 25 Jun 2001, Richard A. Steenbergen wrote: > > > On Mon, Jun 25, 2001 at 04:54:12PM -0700, Mike Batchelor wrote: > > > > > > > 24.0/8 is the "cable block". > > > > > > No it's not. Check out 24.132/14 for instance. > >and 24.192/14 > > > IANA and ARIN seem to think it is... Check out: > > http://www.iana.org/assignments/network-24 > >24/8 has been used by all 3 RIRs to make assignments to cable modems in >times past. > >Recent events have lead to the non-ARIN parts of 24/8 being taken up by >ARIN, in addition to the non-allocated-to-a-RIR parts of 24/8. Updates to >various databases will simply take a bit of time, thats all. > >--==-- >Bruce.

1 0

RE: for folks tracking DDOS sources or reading the GRC attack log
by Richard A. Steenbergen 26 Jun '01

26 Jun '01

On Mon, Jun 25, 2001 at 04:54:12PM -0700, Mike Batchelor wrote: > > > 24.0/8 is the "cable block". > > No it's not. Check out 24.132/14 for instance. IANA and ARIN seem to think it is... Check out: http://www.iana.org/assignments/network-24 The "Network 24 - Cable Block" will link to the following text: Internet Assigned Numbers Authority (IANA) Date: May 11, 2001 The IANA has completed the administrative transfer of responsibility for 24.0.0.0 - 24.255.255.255 (Cable Block) to the American Regional Internet Registry (ARIN). Questions or Whois information for this 24/8 block should be directed to ARIN <www.arin.net>. I'm sure a few legacy allocations in 24/8 space will happen to slip through... > > Nearly all the cable operators > > have one slice or another from this block. > > Perhaps this is true in the US. > > > Nearly all North American > > cable modems users have address space in this block. > > No they don't. Well since I don't think you can argue Canadian cable modems follow different patterns, you seem to have contradicted yourself... > > Ran > > rja(a)inet.org > > Didja ever have a bad hair day, when you just felt like being contrary > for the hell of it? You think thats funny, until Extreme switchs starts shipping with your IP null routed by default... :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 2

Cisco Routers
by Moe Allen 26 Jun '01

26 Jun '01

Does anyone have any information concerning IP address blocking, as it relates to Cisco routers. I need to start blocking some of this Forged Spam E-mail. It would be nice if this list is current? thanks Morris Allen VidcomNet, Inc.

2 1

Re: Cable Modem [really PPPoE is inferior]
by Fletcher E Kittredge 26 Jun '01

26 Jun '01

On Fri, 22 Jun 2001 11:35:25 -0400 "Drash, Jim [EESUS]" wrote: >At 11:19 AM 6/25/2001 -0400, Fletcher E Kittredge wrote: >>I think we are in violent agreement. I don't like the >>IP->MAC->Customer mapping, it is forgeable, but it is the only one I >>know we have available. I agree with you that it is not the only >>possible mapping. If you can point me to a better existing mechanism, >>I would be grateful. > Since DHCP maps a MAC to and IP address but not to a user, maybe there is a > technology that would provide this missing piece. Low and behold, there is > one: PPP and more specifically PPPoE (Over Ethernet) provides just the > functionality that some people are looking for. A number of broadband > providers are using PPPoE to fill the need of not only assigning an ip > address to a connection but associating that connection with a user. Note the key phrase "better mechanism" in my statement. Many people consider PPPoE an inferior technology. It reduces reliability and usability of the product while raising the cost by increasing complexity and placing unacceptable restrictions on the customer. PPPoE adds an unnecessary layer on the network stack. Thus it consumes extra resources and gives one more component to fail and debug. PPPoE used as an authentication mechanism negates the "aways on" advantage of IPoE networks. I don't like it when vendor engineers impose restrictions on customers to satisfy the engineers design problems. Good engineers design systems that make the network simple, easy to use, secure, cheap and end-to-end. They don't come up with ways to deliberately degrade the value of the network. Personally, I think PPPoE belongs in the "bad idea box" along with IPoATM and MPLS. > I would propose that if DHCP (or any other technology) does not do what you > want, see if there is another that will. If there is not build your own and > don't whine about it. Since the ISC DHCPD is open source, you can change it > as you see fit. If you change it, you should contribute back. However, do > not assume that Ted or anyone else will do this for you or support it if you > contribute back. Hum, you must be thinking of someone else. Properly designed systems based on DHCP do exactly what I want. My complaint is with people who don't design networks properly. Economic, Fast, Secure, Reliable and easy-to-use: If you can't design a network system that is has all five qualities, best copy the system of someone who can. Copying other's work until you reach master level is a good thing. I do so appreciate your suggestions about how open software projects work. Lots of people think that because I have been doing this for so long, I don't need these little reminders. But was one gets older, the details slip out of your mind, like sea water running through the fingers of your cupped hands. Time for a walk on the beach. regards, fletcher -- Fletcher Kittredge Great Works Internet 8 Pomerleau St. Biddeford, Maine

4 4

for folks tracking DDOS sources or reading the GRC attack log
by RJ Atkinson 25 Jun '01

25 Jun '01

24.0/8 is the "cable block". ARIN normally allocates residential cable modem subnets out of this space. Nearly all the cable operators have one slice or another from this block. Nearly all North American cable modems users have address space in this block. Cable modems themselves are nearly always numbered in 10.0/8. For those who have read the GRC web site, note that 216.216.8.x appears not to be a cable modem slice in any event. ARIN reports that this slice has been allocated to @Work, which is the commercial IP lease-line business unit within Excite@Home. Presence of a *.home.net DNS entry does not mean the system is on any cable modem network. There are no 24.0/8 addresses listed in the log at http://grc.com/dos/attacklog.htm so it isn't clear to me that any cable modems were used in that particular attack. Ran rja(a)inet.org

5 6

RE: Exodus Down
by Richard A. Steenbergen 25 Jun '01

25 Jun '01

On Mon, Jun 25, 2001 at 03:18:30PM -0700, Bill Woodcock wrote: > > > maybe there should be a nanog range day :) > > Mmmm... well, there's certainly a history of pre-NANOG field trips, > and the next NANOG is in Oakland... Not to say that Oakland is a > free-fire zone or anything, but it would certainly be easy enough to > arrange for the use of a range the Sunday before the next meeting. > :-) It isn't? For the t-shirt, I was thinking it could show some people wearing nanog badges getting mugged on the street corner while the routers from the beer 'n gear are being wheeled out the back of the hotel... Just a thought. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0