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

["HUANG, JERRY (ATTLABS)" <[e-mail]>]

> -----Original Message-----
> From: James Carlson [mailto:[e-mail]]
> 
> HUANG, JERRY (ATTLABS) wrote:
> > Reasonable question. But the intent was to operate one way or the
other
> > in any single operational instance. Vendors will have to implement
> > IPv6CP already along with RA/DHCPv6 options. Is the addition of
these
> > few options overly burdensome to existing IPv6CP code? I suppose
working
> > code will help. The scenarios might be:

[Scenario outlines deleted.]

> > Servers not having RA/DHCPv6 support seem unlikely given the
standards
> > track status of 5072 and 5571.
> >
> > Hmmm. While this draft may seem to simplify the end point
configuration
> > by doing it within the IPv6CP flow, in practice, does it really
simplify
> > things for implementers? Or solve a new problem?
> 
> I believe it creates new problems.
> 
> As we've seen with RFC 1877 deployment, there are vendors and
> administrators out there who will offer information only by way of
that
> PPP mechanism, and not by way of the standards-track mechanisms.  And
> there are users who have little choice but to comply.  The result is
> that it forces other clients to implement both mechanisms, and that
> causes the data-integration problem I mentioned.  It's not always
clear
> when you should use one or the other.
> 
> The scheme you're suggesting is one where successful negotiation of
the
> new IPV6CP options trumps all other sources of information, and the
> existing standards-based ones are used only if the new feature is
> unavailable on one or both ends.  But is that necessarily right?  What
> if the server only offers these new options as a "convenience" to
> less-capable clients, and actually offers better service (and more
> information) via the standards-track mechanisms?
> 
> 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.

> These are problems already solved in DHCP, but not solved here.
> 
> >> Even if you do, what's your plan for supporting non-PPP media?
> >
> > I think I see your point. If I am going to support non-PPP media on
the
> > same service box, would I not need to support RA/DHCPv6 or just
DHCPv6
> > on it already, thus negating the need to extend IPv6CP? As the
> 
> Yes.
> 
> > motivation for the draft arises from RFC 5571 within the Softwire
Hub
> > and Spoke's Softwire Concentrator and Initiator concept, the PPP
> > sessions ride in L2TP over IPv4 or IPv6. The need to support non-PPP
> > media directly is not apparent on the Concentrator at first blush.
> 
> Implementations and requirements change, but specifications are
forever.
> 
> What if a future deployment of "Hub and Spoke" uses Ethernet or some
> other link layer tunneled over L2TP?
> 
> I *think* what you're describing is what's sometimes called a "walled
> garden:" a specific deployment (or set of deployments) with particular
> and consistent needs that are a either a subset of or distinct from
the
> 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. 

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

Thanks for the discussion,
--
Jerry Huang, AT&T Labs, [phone] [Not speaking for my employer in
any way, shape or form.]