[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: Question regarding address specs for IPv4-only protocolM IBs



Juergen,

I am confused by your email. DHCPv4 servers don't hand out IPv4 "link-local"
addresses. In fact, the zeroconf group is trying to prohibit such behavior
explicitly. The following text is from section 1.4 of
<http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-07.t
xt>: "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
manually or by a DHCP server. Manual or DHCP configuration may cause a host
to use an address in the 169.254/16 prefix without following the special
rules regarding duplicate detection and automatic configuration that pertain
to addresses in this prefix."

It might make sense for DHCPv4 servers to offer "private" IPv4 addresses to
clients, e.g. address space as defined in RFC 1918 (e.g. net 10). That's
where the concept of VPNs for DHCPv4 comes in. Different VPNs may use
overlapping RFC 1918 address space.

I am not sure that the DHC WG is ready to standardize a MIB for such a
"VPN-capable" DHCPv4 server, because that requires fundamental changes to a
standard DHCPv4 server. A "normal" DHCPv4 server only offers a lease for
10.1.1.1 to one client. A "VPN-capable" DHCPv4 server offers a lease for
10.1.1.1 to one client per VPN.

I also don't think we know how to index the MIB tables (e.g. for DHCPv4
leases) for the VPN functionality. Should we use as index an "InetAddress"
object (incorporating VPNs somehow, in a manner not yet defined or accepted
by any WG), or an "InetAddressIPv4" object plus some VPN-identifier-object
-- perhaps requiring a separate VPN table to prevent excessively long OIDs?

It would be hard to answer this question without knowing how the DHC WG is
going to define "VPN labels". The current DHC drafts indicate using an NVT
ASCII string and/or RFC 2685 VPN identifiers. But I don't know when there
would be consensus on these two identifiers, or on any additional
identifiers.

DHCPv4 has been around a long time, but VPN-capable DHCPv4 servers are a
relatively recent concept. I don't think the IETF is ready to standardize
VPN support for DHCPv4. So I think it is reasonable to accept the DHCPv4
Server MIB as is, since it solves real operations problems today.

-- Rich

-----Original Message-----
From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
Sent: Tuesday, March 25, 2003 6:42 PM
To: rbhibbs@pacbell.net
Cc: Woundy, Richard; gww@nortelnetworks.com; mreview@ops.ietf.org
Subject: Re: FW: Question regarding address specs for IPv4-only protocol
MIBs



>>>>> Barr Hibbs writes:

Barr> If a network administrator interconnects two subnetworks, each
Barr> presumably served IPv4 addresses from the same address range
Barr> (for example, 192.168.244.x) the administrator must take some
Barr> additional precautions to prevent conflicts between the two
Barr> servers.  This problem occurred before VPN technology existed
Barr> and was not made better or worse by the introduction of VPNs.

The issue I think shows only up if it is possible that there can be
implementations where you have DHCP servers for links with
"link-local" addresses where there is only a single DHCP MIB
instantiation. Or two independent DHCP subagents exporting information
through a common master agent.

Barr> Introducing a zone index per RFC 3291 would require a
Barr> fundamental change in the message and option formats of DHCPv4,
Barr> and possibly require a change in the protocol message exchange
Barr> as well, forcing a major revision of DHCPv4, something that I'm
Barr> certain the DHC Working Group would not wish to undertake at
Barr> this point.

I do not think there is an issue with the DHCP protocol per se.

The DHCP server hands out the link local IPv4 address for each link as
usual. The "clash" happens when the DHCP server serves multiple links
and the IPv4 addresses on the various links clash. Or in other words,
the clash happens internal in the DHCP and the MIB instrumentation.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>