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

[James Carlson <[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:
>   1. Client with RFC5072 only + Server with RFC5072 and RA/DHCPv6 -->
> current documented behavior
>   2. Client w/ RFC5072 & proposed extension + Server with RFC5072 and
> RA/DHCPv6 --> falls back to (1)
>   3. Client with RFC5072 only + Server with RFC5072 & proposed extension
> and RA/DHCPv6 --> falls back to (1)
>   4. Client w/ RFC5072 & proposed extension + Server with RFC5072 &
> proposed extension and RA/DHCPv6 --> new behavior
> 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?

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.

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