Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt

[James Carlson <[e-mail]>]

On 02/10/10 02:02, HUANG, JERRY (ATTLABS) wrote:
>> From: James Carlson [mailto:[e-mail]]
>> Perhaps more importantly, the PPP-based mechanism described is a bit
>> less capable than the other mechanisms.  It's generally done once at
>> connection establishment time and provides little in the way of
>> customization mechanisms.  What happens if the parameters change while
>> the connection is running?  What if particular classes of clients need
>> different answers?  What if particular vendors or users need local
>> extensions to carry configuration information that's useful to them?
>> What if two DNS server addresses aren't right, but three are?
> 
> Given the scenario is PPP in L2TP, changes in parameters can be
> accommodated via L2TP control messages (CDN, etc) and allow the PPP
> session to be renegotiated, right?  Classes of users are accommodated
> via AAA (RADIUS) so different configuration parameters can be returned.
> Vendor-Specific-Attributes can probably handle local extensions.

RADIUS doesn't have client classes the way DHCP does, but that's perhaps
a minor point.

A larger point is that the scheme you're describing is actually a bit
worse.  There's no defined way for RADIUS to tell the client that
parameters need to be negotiated.  You'd have to invent some way of
telling PPP to restart from scratch -- because RADIUS depends on an
authentication session -- any time a parameter changed on the RADIUS
server.  Or you'd have to configure the PPP clients to do a restart
periodically just to check whether there are changes.

In contrast, DHCP obliges the clients to refresh their parameters
periodically, and (with v6) even includes an optional server-to-client
refresh mechanism.  In addition to that, DHCP doesn't require a new
round of authentication, nor does it involve tearing down the IP link
just to change a DNS server address.  The checks are "hitless."

Without RADIUS in the picture, and with the needed parameters somehow
present on the PPP "server," you'd still need to have IPCP restart,
which (for most implementations) would still cause an unnecessary link
bounce.  In some peers, though, layer restart is known to trigger bugs
that will cause link failure.  (Obviously not a specification issue, as
the spec is clear on what should happen, but a deployment issue none the
less.)

On top of that, DHCP is dirt cheap.  If all you need are configuration
parameters, then you just need DHCPv6 Information.  It's a UDP
request/response, without much in the way of overhead.

The "simplicity" argument in favor of new PPP options unfortunately also
runs into the usual counter-argument: computer capacity limitations
(even for the tiniest of embedded systems) are fleeting things in
comparison to the longevity of protocols.  We're still using the same
basic TCP/IP that was originally deployed in 1982.  Imagine if the
computer system limitations back then were encoded into the base protocols.

Again, the archive should be consulted here.  We've discussed at length
the problems in this concept when it's deployed outside of a walled
garden.  For essentially the same reason that it makes no sense to have
an Ethernet NIC caring about DNS addresses, it also makes no sense to
have PPP handling them.

>> more diverse Internet.  There's nothing particularly wrong with walled
>> gardens, but there's also little reason to standardize what they do,
> at
>> least within the IETF.  The protocols used there can be ad-hoc (or set
>> by some other standards group) without compromising the Internet
> itself.
> 
> I was thinking more in terms of dial network and (potential) RFC 5571
> implementation scenarios and attempted to extend the IPCP model for IPv4
> straight-forwardly to IPv6. IMHO, in those cases, IP address assignment
> by the NAS/LNS model could still make sense without invoking RA and/or
> DHCPv6 mechanisms. But I concede that in reality the proposal probably
> doesn't provide the benefits I was hoping to get, mainly because it adds
> to implementation requirements, instead of reducing them. 

Exactly.  For a robust and interoperable implementation, you'd actually
have to include both mechanisms.  It's only inside of the previously
mentioned walled gardens (where interoperability is tightly constrained)
that this can be safely ignored.  That makes it more complex.

Or as a wise IETF-er once said, a specification isn't complete when
there's nothing left to add, but rather not until there's nothing left
to remove.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>