renumbering and roaming

Mailman List Mirror (Read Only)
1

From: "Michael S. Fischer" <otterley@iPass.COM>
>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.

Ideal World:
    Nothing should be hard coded. Every NAS should support DHCP and
    DHCP INFORM. Each roaming user simply sends a DHCP multicast /
    broadcast packet, which is intercepted and forwarded by the NAS
    (serial link) or the local router (LAN), and recieves a list of
    services, including DNS.

    This is the direction that many of us in the IETF have been
    advocating for about 11 years....

Real World:
    Although all the early (circa '89-92) NAS's supported BOOTP/DHCP
    relaying, more recent shoe-string NAS vendors are missing it, and
    clients have not universally implemented DHCP. We have to tell our
    customers the list of local DNS (and other) servers for them to type
    into their configuration (or we use a standard install CD).

    For this latter scenario, a few default universal hardcoded numbers
    would be a great idea! It would help with legacy clients, it would
    help roaming, and would not hurt as DHCP gets installed base.

    I look forward to reading the internet-draft. It should require no
    changes to client or server software.

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.

Speaking as the author of "LCP Extensions", there is no such LCP
extension as "dynamically-assigned DNS servers".

There is a bogus, NDA'd, Mircosoft-only, NetBEUI extension to PPP IPCP,
using numbers stolen from the high end of the option space without
registering with IANA, which is marginally applicable to DNS.

This approach has been officially rejected by the IETF. It is not a
"best current practice". It only works with NT servers, which no sane
and stable ISP would use.

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.

AFIAK, Dynamic DNS is _only_ supported by Unix, but I have high hopes to
see it on MacOS, now that Vinnie is back at Apple. I have no idea why
it would be supported by a NAS or PPP client. I think you have your
terminology wrong....

WSimpson@UMich.edu
    Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2

FWIW, almost all of the NAS's in production today support Microsoft's PPP
extensions for dynamically assigned DNS servers. Like it or not, it's
something that we have to live w/today.

3

Really? I can't seem to find it in the USR manuals.

    --Dean

4

>FWIW, almost all of the NAS's in production today support Microsoft's PPP
>extensions for dynamically assigned DNS servers. Like it or not, it's
>something that we have to live w/today.

Really? I can't seem to find it in the USR manuals.

Yep:

NetServer 5> help set nasdns_info
Usage: set nasdns_info on|off

Charles

5

>FWIW, almost all of the NAS's in production today support Microsoft's PPP
>extensions for dynamically assigned DNS servers. Like it or not, it's
>something that we have to live w/today.

Really? I can't seem to find it in the USR manuals.

    --Dean

AFAIK from our testing it is there... if people are really interested I can
find out more from a colleague.

Peter

6

Speaking as the author of "LCP Extensions", there is no such LCP
extension as "dynamically-assigned DNS servers".

There is a bogus, NDA'd, Mircosoft-only, NetBEUI extension to PPP IPCP,
using numbers stolen from the high end of the option space without
registering with IANA, which is marginally applicable to DNS.

This approach has been officially rejected by the IETF. It is not a
"best current practice". It only works with NT servers, which no sane
and stable ISP would use.

The sad fact is that this what what most people use. It may as well be a
standard, since it works. I hate M$ as much as the next clueful person, but
you need to know your enemy before making statements like this. The
assignments of DNS during PPP IPCP is not restricted to NT, but works on the
other M$ OSes and also a large number of non WinCE PDAs too.

No matter how technically inelegant, the solution is one that works, uses
minimum overhead and can be driven from that simple configuration engine,
"RADIUS". You may also now argue that RADIUS is an user authentication
database, but it is being used, again, in the real world, as a configuration
database, and users just happen to be one of those items being configured.

Peter

7

That figures and is not surprising at all.

Lucent/Livingston and ASCEND both do support it.

Of course, between the two of them they're easily a majority of the market.