Subject: RE: Modefg considered harmful

From: Van Aken Dirk <[email-masked]>
Date: Mon, 3 Feb 2003 09:16:53 +0100

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: vrijdag 31 januari 2003 16:10
To: Van Aken Dirk
Cc: 'Cheryl Madson'; [email-masked]
Subject: RE: Modefg considered harmful

> I cannot answer for the future and extensibility. What I do know is that
> ModeCfg is almost identical to PPP-IPCP (RFC1332, RFC1877) in
functionality:
> it supports a bare minimum on IP parameters.

RFC 1877 has been heavily criticized over the years (see James Carlson's
PPP book), and the island of address state that it created has proven
to be a headache.
I've read this book and I'm confronted with the consequences. On the Wide
Area side of DSL routers we implement PPP over ATM and PPP over Ethernet. On
the LAN (Ethernet side) we use DHCP and we have to come up with complex
constructs to get the PPP negotiated parameters via PPP-DHCP-Proxy
constructs into the PC's on the LAN. It is a perfect example of how to link
two totally different state machines with different feature sets together.

ModeCfg & DHCP is the same story but then the solution is called
ModeCfg-DHCP-Proxy.

 Also, it became apparent that the set of parameters
defined in RFC 1877 was not enough -- and that attempting to duplicate
all the DHCP options was not fruitful. So PPP peers such as Windows 2000
and XP had to add support for DHCP anyway!
BroadBand Remote Access server manufactures don't come up with this kind of
solutions. They continue the path of PPP-IPCP but then with "private"
extensions. As an example, there is a private PPP-IPCP option to negotiate a
subnet. The goal is to have these addresses on the LAN side. So I must
populate a DHCP pool of my local DHCP server with this subnet and serve the
PC on the Ethernet segment from this pool. If the PPP link goes down, then
these addresses are no longer valid etc ...
And last but not least, brand A encodes this PPP-IPCP option in an IP
address/length format and brand B does it via address/mask format. Two times
development and testing from my side ..

Same will happen with ModeCfg ...

Given what we have learned from history, it makes little sense to
continue on with this approach, particularly with IPv6, where there are
a well defined set of address and configuration mechanisms for all types
of interfaces.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Feb 2003 04:06:34 -0800 (PST)

> ModeCfg & DHCP is the same story but then the solution is called

You are right about the implications -- and that the architecture would be
simpler if only one mechanism were used.

> extensions.

Indeed. So we will end up with interoperability headaches, too.

> Two times development and testing from my side ..

Yup. I've been there too :)

> a well defined set of address and configuration mechanisms for all types

I'd agree.