Michael Dillon said on 5/17/98 6:13 AM
On Sat, 16 May 1998, Karl Denninger wrote:
agency). Renumbering THEM would be a job out of the depths of Hades itself; even broaching the subject would likely cost us the account.
I see. So if you tell the customer that they need to renumber, then they tell you to stuff it and switch to a new provider who... tells them that they must renumber out of your soon-to-be-reassigned address space.
I just don't see this as a realistic example of a situation in which a renumbering ISP is at a severe business disadvantage. In fact I can't remember ever seeing any such realistic example nor do I ever remember hearing of a case in which an ISP lost a significant amount of business because of renumbering.
We have renumbered out of two /20's and 2 /19's and, although we haven't lost any dedicated customers, our time investment in the process has been unreal. In several instances we had to go onsite and do the renumbering for them. Of course, the first time you go onsite, the tech guy isn't there, so that's half a day for two people lost. Then, the next time you go, he doesn't have the passwords to the server, so you have to come back again... And, because this is something we are requiring them to do, we can't charge them for it. Let's not forget to mention the 10,000 dialup customers who have to change their DNS numbers. We have sent snail-mail and e-mail over and over again, yet only about 1/3 of that 10k have actually made the change away from the old numbers. How many of those customers do you think we'll lose when we officially turn off the old ip's? Mike Michael K. Smith Senior Network Administrator - Northwest Link http://www.nwlink.com mksmith@nwlink.com 1-800-390-1270 Extension 103
On Sun, 17 May 1998, Michael K. Smith wrote:
Let's not forget to mention the 10,000 dialup customers who have to change their DNS numbers. We have sent snail-mail and e-mail over and over again, yet only about 1/3 of that 10k have actually made the change away from the old numbers. How many of those customers do you think we'll lose when we officially turn off the old ip's?
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
IMHO every dialup customer, the vast majority of which use Windows 95, should have their machines set up to get the DNS servers, routing info, etc. from the terminal server they dial in to. Change the DNS servers in the PRI box and you're done. Nobody notices except people with Un*x boxes or Trumpet Winsock. I'm not sure if Mac boxes can do this, but Mac users represent about 5% of our dialup base, so it's not a terribly huge problem. Seems a little less disaster prone than every provider on the net having a nameserver on the same IP in 1918 space, especially those that don't realize that you're not supposed to announce it and those that don't filter it... -Blake --------------------------------------------------------------------------- Blake Willis 703-448-4470x483 Network Engineer, New Customers blakew@cais.net CAIS Internet, a CGX Communications Company --------------------------------------------------------------------------- On Sun, 17 May 1998, Michael Dillon wrote:
On Sun, 17 May 1998, Michael K. Smith wrote:
Let's not forget to mention the 10,000 dialup customers who have to change their DNS numbers. We have sent snail-mail and e-mail over and over again, yet only about 1/3 of that 10k have actually made the change away from the old numbers. How many of those customers do you think we'll lose when we officially turn off the old ip's?
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away.
On Sun, 17 May 1998, Michael Dillon turned on his computer and typed:
On Sun, 17 May 1998, Michael K. Smith:
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away.
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 - two mail relays, e.g. 192.168.254.5 and 192.168.253.5 - two news servers, e.g. ---254.9 and 253.9 - two ntp time servers - etc etc [the addresses chosen for /30 netmasks, I think that in my Monday morning brain-state I got it right?] And so on for "standard" services, then we could achieve global roaming SO easily. The number of times we've had customers roam elsewhere and then try and use our mail relays when for spam reasons relaying is denied... Paul ---- P Mansfield, Senior SysAdmin PSINet *** If a grand piano had a rubout key, I'd be a concert pianist by now! ***
On Mon, May 18, 1998 at 10:59:16AM +0100, Paul Mansfield wrote:
On Sun, 17 May 1998, Michael Dillon turned on his computer and typed:
On Sun, 17 May 1998, Michael K. Smith:
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away.
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 - two mail relays, e.g. 192.168.254.5 and 192.168.253.5 - two news servers, e.g. ---254.9 and 253.9 - two ntp time servers - etc etc
Of course, if a customer has a LAN out the back of the same machine they're connecting from, and it's using these addresses (which they are entitled to use), then it'll cause immense headaches.. -- Ben Buxton___bb@zip.com.au_____ o _ _--_|\ ZIP Internet P/L Zip's Network Dude /____|___|_)________/______\______________________ Carbon: 9270-4777 | . \_.--._* Virtually Silicon: 9273-7111, 9247-7288 Paper: 92475276 v the best :)
On Mon, 18 May 1998, Ben Buxton rose up and penned these lines to NANOG:
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 !snip!
Of course, if a customer has a LAN out the back of the same machine they're connecting from, and it's using these addresses (which they are entitled to use), then it'll cause immense headaches..
The actual addresses wouldn't matter (I'm sure IANA could release a couple of unused class Cs for example) as long as all ISPs ensure that they used the same ones for "local" services. As you say, 192.168.*.* would probably be unsuitable as a lot of people use these already. One really nifty side effect could be to make it harder to spam through other ISP's relays if the relays which had to be relatively open for customers weren't visible on the 'net at large. Paul ---- P Mansfield, Senior SysAdmin PSINet, +44-1223-577577x2611/577611 fax:577600 *** If a grand piano had a rubout key, I'd be a concert pianist by now! ***
One really nifty side effect could be to make it harder to spam through other ISP's relays if the relays which had to be relatively open for customers weren't visible on the 'net at large.
Your customer relays never have to be visible to the net at large. Remember, sendmail is a "mail router" --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Mon, 18 May 1998, Dean Anderson wrote:
One really nifty side effect could be to make it harder to spam through other ISP's relays if the relays which had to be relatively open for customers weren't visible on the 'net at large.
Your customer relays never have to be visible to the net at large. Remember, sendmail is a "mail router"
yes, but our relays also act as backup MX... its a long story, sigh. luckily Exim (http://www.exim.org) can be configured to do both relay and MXing controllably... and the documentation is plenty good enough to make it easy!
--Dean
Paul ---- P Mansfield, Senior SysAdmin PSINet, +44-1223-577577x2611/577611 fax:577600 *** If a grand piano had a rubout key, I'd be a concert pianist by now! ***
Then we have a special /24 or so that is in another RFC that is "service provider independent service addresses". Allocate it out of the swamp (192.x.x.x for those too young) and treat it just like private address space, but the convention is that no one uses it for "corporate" addressing. Peter
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Ben Buxton Sent: Monday, May 18, 1998 1:23 PM To: Paul Mansfield; Michael Dillon Cc: nanog@merit.edu Subject: Re: renumbering and roaming
On Mon, May 18, 1998 at 10:59:16AM +0100, Paul Mansfield wrote:
On Sun, 17 May 1998, Michael Dillon turned on his computer and typed:
On Sun, 17 May 1998, Michael K. Smith:
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be
hard coded
as the default in all client software. Then this problem would go away.
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 - two mail relays, e.g. 192.168.254.5 and 192.168.253.5 - two news servers, e.g. ---254.9 and 253.9 - two ntp time servers - etc etc
Of course, if a customer has a LAN out the back of the same machine they're connecting from, and it's using these addresses (which they are entitled to use), then it'll cause immense headaches..
-- Ben Buxton___bb@zip.com.au_____ o _ _--_|\ ZIP Internet P/L Zip's Network Dude /____|___|_)________/______\______________________ Carbon: 9270-4777 | . \_.--._* Virtually Silicon: 9273-7111, 9247-7288 Paper: 92475276 v the best :)
Would it be terribly unreasonable to suggest assigning a reserved /24 explicitly for internal ISP services such as those listed below, and write up some sort of rfc for the whole ordeal, so that there are no conflicts with 1918 space? -Blake --------------------------------------------------------------------------- Blake Willis 703-448-4470x483 Network Engineer, New Customers blakew@cais.net CAIS Internet, a CGX Communications Company --------------------------------------------------------------------------- On Mon, 18 May 1998, Ben Buxton wrote:
On Mon, May 18, 1998 at 10:59:16AM +0100, Paul Mansfield wrote:
On Sun, 17 May 1998, Michael Dillon turned on his computer and typed:
On Sun, 17 May 1998, Michael K. Smith:
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away.
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 - two mail relays, e.g. 192.168.254.5 and 192.168.253.5 - two news servers, e.g. ---254.9 and 253.9 - two ntp time servers - etc etc
Of course, if a customer has a LAN out the back of the same machine they're connecting from, and it's using these addresses (which they are entitled to use), then it'll cause immense headaches..
-- Ben Buxton___bb@zip.com.au_____ o _ _--_|\ ZIP Internet P/L Zip's Network Dude /____|___|_)________/______\______________________ Carbon: 9270-4777 | . \_.--._* Virtually Silicon: 9273-7111, 9247-7288 Paper: 92475276 v the best :)
On Mon, 18 May 1998, Blake Willis wrote:
Would it be terribly unreasonable to suggest assigning a reserved /24 explicitly for internal ISP services such as those listed below, and write up some sort of rfc for the whole ordeal, so that there are no conflicts with 1918 space?
-Blake
Anyone care to co-author an RFC suggesting a sensible global standard for "local" mail relays, time servers, resolvers etc so that dial-in people can roam without getting filtered, blocked etc? Paul ---- P Mansfield, Senior SysAdmin PSINet, +44-1223-577577x2611/577611 fax:577600 *** If a grand piano had a rubout key, I'd be a concert pianist by now! ***
On Mon, 18 May 1998, Blake Willis wrote:
Would it be terribly unreasonable to suggest assigning a reserved /24 explicitly for internal ISP services such as those listed below, and write up some sort of rfc for the whole ordeal, so that there are no conflicts with 1918 space?
-Blake
Anyone care to co-author an RFC suggesting a sensible global standard for "local" mail relays, time servers, resolvers etc so that dial-in people can roam without getting filtered, blocked etc?
How about defining 192.x.y.port-number, where port-number is the port number of the service. 192.x.y.53 is the DNS server, etc.. Nah, good idea, but too many useful services with port numbers > 255, so it doesn't work too well. -Phil
On Mon, 18 May 1998, Phillip Vandry wrote: ) > Anyone care to co-author an RFC suggesting a sensible global standard for ) > "local" mail relays, time servers, resolvers etc so that dial-in people can ) > roam without getting filtered, blocked etc? ) How about defining 192.x.y.port-number, where port-number is the port ) number of the service. 192.x.y.53 is the DNS server, etc.. ) ) Nah, good idea, but too many useful services with port numbers > 255, so ) it doesn't work too well. 192.69.0.25:25 -> SMTP 192.69.0.53:53 -> DNS 192.69.0.80:80 -> HTTP 192.69.66.67:6667 -> IRC etc. Why not just 192.x.*.* and have the first two numbers in the port be represented in the second to last quad, and the last two numbers in the last quad? Or, maybe more practically (to take care of those pesky 5 digit ports that someone might use for some reason), you could just use the actual numeric representation, ie: 25 -> 0x0019 -> 192.69.0.25 (0x00 is 0, 0x19 is 25) 80 -> 0x0050 -> 192.69.0.80 (0x00 is 0, 0x50 is 80) 6667 -> 0x1A0B -> 192.69.26.11 (0x1A is 26, 0x0B is 11) 54321 -> 0xD431 -> 192.69.212.49 (0xD4 is 212, 0x31 is 49) etc. To reconstruct the original port from the host, just take the second to last quad, multiple it by 256 (aka left bitshift it 8 places), and add the last quad. 0*256 + 25 = 25; 0*256 + 80 = 80; 26*256 + 11 = 6667; 212*256 + 49 = 54321 -- Daniel Reed <n@ml.org> (ask me for my PGP key) Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. -- Winston Churchill
At 8:22 AM -0400 5/18/98, Ben Buxton wrote:
On Mon, May 18, 1998 at 10:59:16AM +0100, Paul Mansfield wrote:
On Sun, 17 May 1998, Michael Dillon turned on his computer and typed:
On Sun, 17 May 1998, Michael K. Smith:
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away.
If terminal server providers would support DHCP, this might be a non-issue. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Mon, 18 May 1998, Paul Mansfield wrote:
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 - two mail relays, e.g. 192.168.254.5 and 192.168.253.5 - two news servers, e.g. ---254.9 and 253.9 - two ntp time servers - etc etc [the addresses chosen for /30 netmasks, I think that in my Monday morning brain-state I got it right?]
Actually, you can get away with only using a /32. With host routes and tagging the address as a secondary on a loopback, you don't need more than a single address. However, I agree that we need to have a standard address set. It would make everyone's life so much easier. I would recommend getting a single /24 allocated (probably from the swamp) and reserved for this use, instead of utilizing existing PA space, as there may be some situations where you walk on top of an already allocated PA space, and by having something not listed in the PA RFC you end up getting away from clueless people who utilize PA space. So this last paragraph is understood and I don't get flames because of a misunderstanding, here's a better statement of what I'd like to see done: 1) Have a RFC written which contains the following: a) A list of initial services which are covered under this b) The IP addresses of the initial services, from the new /24 c) A pointer to IANA where an up to date list of allocations from the /24 can be found. d) Maybe some recommendations for some handling of certain univiersal services - such as web proxy - when there is no service available. (Ping the address and if no response, assume that that service is not provided and go at the web directly) 2) Based on 1c above, have the IANA maintain a list of standard IP addresses. Now, I realize that we just stepped out of the lines of nanog. Is there an appropriate IETF forum to discuss this in? BTW, I would be interested in co-authoring this RFC. - Forrest W. Christian (forrestc@imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
On Mon, 18 May 1998, Forrest W. Christian wrote:
I would recommend getting a single /24 allocated (probably from the swamp) and reserved for this use, instead of utilizing existing PA space, as there may be some situations where you walk on top of an already allocated PA space, and by having something not listed in the PA RFC you end up getting away from clueless people who utilize PA space.
Yeah. Then 192.0.35/24 would be a good choice. It's in an IANA reserved block that already has subnets allocated for special purposes such as 192.0.2/24 for use in textbook examples. I picked 35 at random except for making sure that there are no digits in common with 192.0 because that makes it easier for people to type in correctly, etc.
1) Have a RFC written which contains the following:
Sounds like you already have a good start on the document. Write it up according to these guidlines ftp://ftp.ietf.org/ietf/1id-guidelines.txt and http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2223.txt and then send it to rfc-editor@isi.edu when you are done.
Now, I realize that we just stepped out of the lines of nanog. Is there an appropriate IETF forum to discuss this in?
Basically the only generic place for this sort of stuff is the ietf mailing list http://www.ietf.org/maillist.html but you don't need to do that to get things started. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
In message <Pine.GSO.3.93.980518105250.8122N-100000@staff.uk.psi.com>, Paul Man sfield writes:
On Sun, 17 May 1998, Michael Dillon turned on his computer and typed:
On Sun, 17 May 1998, Michael K. Smith:
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away.
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 - two mail relays, e.g. 192.168.254.5 and 192.168.253.5 - two news servers, e.g. ---254.9 and 253.9 - two ntp time servers - etc etc
[the addresses chosen for /30 netmasks, I think that in my Monday morning brain-state I got it right?]
And so on for "standard" services, then we could achieve global roaming SO easily.
The number of times we've had customers roam elsewhere and then try and use ou r mail relays when for spam reasons relaying is denied...
After several discussions, we came up with this solution that we think works well to support standard services for roaming users: Support a .local. root domain in your DNS servers. Examples of DNS hostnames would be mail.local., ntp.local., news.local., etc. When a roamer dials up he generally uses the DNS servers assigned by the NAS; these addresses would be authoritative on a provider-by-provider basis. If all networks supported this schema all users could simply have these addresses coded into their client software and would connect to the proper machines as they differ on various networks. iPass is currently building an Internet-Draft specifying the details of this approach. What do you think? --Michael Michael S. Fischer <otterley@iPass.COM> |\ Sr. Systems/Network Administrator, iPass Inc. _O_ | require Std::Disclaimer; | () Voice: +1 650 944 0333 FAX: +1 650 237 7321 | "There's a thin line between love and a crime and collaboration"
On Mon, May 18, 1998 at 11:38:04AM -0700, Michael S. Fischer wrote:
In message <Pine.GSO.3.93.980518105250.8122N-100000@staff.uk.psi.com>, Paul Man sfield writes:
On Sun, 17 May 1998, Michael Dillon turned on his computer and typed:
On Sun, 17 May 1998, Michael K. Smith:
IMHO every dialup customer from every ISP in the world should use 192.168.254.1 for their DNS address and this number should be hard coded as the default in all client software. Then this problem would go away.
if all ISPs agreed to use these addresses... say - TWO resolvers, e.g. 192.168.254,1 and 192.168.253.1 - two mail relays, e.g. 192.168.254.5 and 192.168.253.5 - two news servers, e.g. ---254.9 and 253.9 - two ntp time servers - etc etc
[the addresses chosen for /30 netmasks, I think that in my Monday morning brain-state I got it right?]
And so on for "standard" services, then we could achieve global roaming SO easily.
The number of times we've had customers roam elsewhere and then try and use ou r mail relays when for spam reasons relaying is denied...
After several discussions, we came up with this solution that we think works well to support standard services for roaming users:
Support a .local. root domain in your DNS servers. Examples of DNS hostnames would be mail.local., ntp.local., news.local., etc. When a roamer dials up he generally uses the DNS servers assigned by the NAS; these addresses would be authoritative on a provider-by-provider basis. If all networks supported this schema all users could simply have these addresses coded into their client software and would connect to the proper machines as they differ on various networks.
iPass is currently building an Internet-Draft specifying the details of this approach. What do you think?
--Michael
That doesn't work; too many of those things must be hard-coded numbers (specifically, the DNS servers). .LOCAL along with defined addresses, declared as "non-routable" (ie: local only) *DOES* do the trick. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
In message <19980518135928.37530@mcs.net>, Karl Denninger writes:
After several discussions, we came up with this solution that we think works well to support standard services for roaming users:
Support a .local. root domain in your DNS servers. Examples of DNS hostnames would be mail.local., ntp.local., news.local., etc. When a roamer dials up he generally uses the DNS servers assigned by the NAS; these addresses would be authoritative on a provider-by-provider basis. If all networks supported this schema all users could simply have these addresses coded into their client software and would connect to the proper machines as they differ on various networks.
iPass is currently building an Internet-Draft specifying the details of this approach. What do you think?
That doesn't work; too many of those things must be hard-coded numbers (specifically, the DNS servers).
What has to be hard-coded besides the DNS servers? Once you have a DNS server assigned (which is typically done by the NAS anyway) the rest is simple. In our experience, well over 90% of roaming users (which excludes UNIX and Mac users) use dynamically-assigned DNS servers. Clearly this approach won't work for those clients that don't support the LCP extensions, but we consider this "Best Current Practice." Those clients that can't use dynamic DNS server assignment will have to use the home ISP's services. We consider it important to make sure as many NASes and PPP clients as possible support dynamic DNS. About the only major obstacle to that is OT/PPP (MacOS) and, to a lesser degree, UNIX.
.LOCAL along with defined addresses, declared as "non-routable" (ie: local only) *DOES* do the trick.
Routability and IP address definitions are secondary to the problem we're discussing here--the ability for roamers to use local services provided by the POP provider. Let DNS do the work for you. I don't see the need to force IP assignments on the Internet community. --Michael Michael S. Fischer <otterley@iPass.COM> |\ Sr. Systems/Network Administrator, iPass Inc. _O_ | require Std::Disclaimer; | () Voice: +1 650 944 0333 FAX: +1 650 237 7321 | "There's a thin line between love and a crime and collaboration"
On Mon, 18 May 1998, Michael S. Fischer wrote:
Support a .local. root domain in your DNS servers. Examples of DNS hostnames would be mail.local., ntp.local., news.local., etc. When a roamer dials up he generally uses the DNS servers assigned by the NAS;
I did think of this a while ago, and nearly proposed it on NANOG, because at first it seems stunningly simple and trivial, but then... a) if you have separate resolvers to nameservers (former being just caches with no primary/secondary domains hosted, thus avoiding downtime during reloading), you don't want to pollute your resolvers b) the client needs to have a starting point for his/her resolvers, i.e. an IP address, which you want on YOUR network not their home ISPs, and if they carry their resolver configuration over... So, although I think it's not a bad idea, there are significant snags, but a lot can be done with this. If the IP addresses were fixed, or at least for a pair of resolvers, perhaps each ISP should have appropriate reverse DNS set up, e.g. relay1.mail.uk.psinet.LOCAL, so that internal traffic and email headers made sense, otherwise it'd make spammers life a lot easier.
these addresses would be authoritative on a provider-by-provider basis. If all networks supported this schema all users could simply have these addresses coded into their client software and would connect to the proper machines as they differ on various networks.
Yes, each ISP would hack their systems to have their own "root" nameserver for .local, and be authoritative for the forward and reverse.
iPass is currently building an Internet-Draft specifying the details of this approach. What do you think?
I'll confess to not being a big fan of the way iPass works... good idea, but the implementation is not as sophisticated as I'd like (we are a partner and use an adapted anti-spam toolkit etc for our mail relays). Paul ---- P Mansfield, Senior SysAdmin PSINet, +44-1223-577577x2611/577611 fax:577600 *** If a grand piano had a rubout key, I'd be a concert pianist by now! ***
On Sun, 17 May 1998, Michael K. Smith wrote:
Let's not forget to mention the 10,000 dialup customers who have to change their DNS numbers. We have sent snail-mail and e-mail over and over again, yet only about 1/3 of that 10k have actually made the change away from the old numbers. How many of those customers do you think we'll lose when we officially turn off the old ip's?
We have the same problem on a smaller scale. What I chose to do at least as a short term solution is keep using a few IPs. i.e. the IP's we gave out as DNS servers are now virtual interfaces on one of our systems...so people within our network (mostly dialups) can still use the old DNS server IPs. This will cause some "connectivity problems" when UUNet recycles our old addresses...but hopefully this is just a short term solution for a temporary problem. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | http://noagent.com/?jl1 for cheap Network Administrator | life insurance over the net. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Sun, May 17, 1998 at 10:27:00AM -0000, Michael K. Smith wrote:
Michael Dillon said on 5/17/98 6:13 AM
On Sat, 16 May 1998, Karl Denninger wrote:
agency). Renumbering THEM would be a job out of the depths of Hades itself; even broaching the subject would likely cost us the account.
I see. So if you tell the customer that they need to renumber, then they tell you to stuff it and switch to a new provider who... tells them that they must renumber out of your soon-to-be-reassigned address space.
I just don't see this as a realistic example of a situation in which a renumbering ISP is at a severe business disadvantage. In fact I can't remember ever seeing any such realistic example nor do I ever remember hearing of a case in which an ISP lost a significant amount of business because of renumbering.
We have renumbered out of two /20's and 2 /19's and, although we haven't lost any dedicated customers, our time investment in the process has been unreal. In several instances we had to go onsite and do the renumbering for them. Of course, the first time you go onsite, the tech guy isn't there, so that's half a day for two people lost. Then, the next time you go, he doesn't have the passwords to the server, so you have to come back again... And, because this is something we are requiring them to do, we can't charge them for it.
Let's not forget to mention the 10,000 dialup customers who have to change their DNS numbers. We have sent snail-mail and e-mail over and over again, yet only about 1/3 of that 10k have actually made the change away from the old numbers. How many of those customers do you think we'll lose when we officially turn off the old ip's?
At least 1/4 to 1/3rd of them. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
Let's not forget to mention the 10,000 dialup customers who have to change their DNS numbers. We have sent snail-mail and e-mail over and over again, yet only about 1/3 of that 10k have actually made the change away from the old numbers. How many of those customers do you think we'll lose when we officially turn off the old ip's?
Keep a /32 route internally for your old DNS server numbers for a couple of years. Your customers will still see it, though noone else will. Of course your entire customer base will possibly lose connectivity to (1/2^32) of the internet - but they'd probably prefer that to losing their nameservers. If you want to be really cunning set the nameservers on the old box to resolve www.yournetworkname.net at a different server, which has a big notice to change their nameservers, plus a downloadable executable to go and do it for them on most operating systems. Presumably you are handing out dynamic DNS by radius in any case, which overrides the built in settings which copes with 95% of users. -- Alex Bligh GX Networks (formerly Xara Networks)
On Mon, May 18, 1998 at 12:36:26AM +0100, Alex Bligh wrote:
Let's not forget to mention the 10,000 dialup customers who have to change their DNS numbers. We have sent snail-mail and e-mail over and over again, yet only about 1/3 of that 10k have actually made the change away from the old numbers. How many of those customers do you think we'll lose when we officially turn off the old ip's?
Keep a /32 route internally for your old DNS server numbers for a couple of years. Your customers will still see it, though noone else will. Of course your entire customer base will possibly lose connectivity to (1/2^32) of the internet - but they'd probably prefer that to losing their nameservers. If you want to be really cunning set the nameservers on the old box to resolve www.yournetworkname.net at a different server, which has a big notice to change their nameservers, plus a downloadable executable to go and do it for them on most operating systems. Presumably you are handing out dynamic DNS by radius in any case, which overrides the built in settings which copes with 95% of users.
-- Alex Bligh GX Networks (formerly Xara Networks)
You may be handing that out NOW (we are). You weren't doing it two or three years ago. We have a significant number of customers from *1993*. There was no such thing as dynamic auto-configuration of DNS at that point in time. If you change those nameservers, you're going to have trouble. Guaranteed. I'll bet that not 10% of the customers with them hard-coded (of which there will be MANY) will make the change *UNTIL* you shut off the old addresses - at which point your NOC will find out what it is like to have a "bad hair" day. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
participants (14)
-
Alex Bligh -
Ben Buxton -
Blake Willis -
Daniel Reed -
Dean Anderson -
Forrest W. Christian -
Jon Lewis -
Karl Denninger -
Michael Dillon -
Michael K. Smith -
Michael S. Fischer -
Paul Mansfield -
Peter Galbavy -
Phillip Vandry