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
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.
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.
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...
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...
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..
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.
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.
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?
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?
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"
>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!
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.
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:
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 IETF | IETF mailing lists but you don't need to do
that to get things started.