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

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



I totally agree with Barr and Glenn that the DHCPv4 Server MIB will be
distinct from any future DHCPv6 Server MIB, and there is little value in
trying to use a combined MIB for both server entities.

It *is* possible for a DHCPv4 server to use "non-globally scoped addresses".
At least two commercially-available DHCPv4 servers support the allocation of
IP addresses on a per-VPN basis. For example, a single DHCPv4 server might
offer 10.1.1.1 as an IPv4 address lease to multiple clients, as long as each
of those clients belong to a distinct VPN.

Here are two recent internet-drafts on using VPN identifiers for DHCPv4
server operation:
<http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-02.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-02.txt>

But to make things more complicated, I'm not sure that the RFC 3291 concept
of "zones" is going to work here. RFC 3291 uses a four byte "zone index" for
IPv4 and IPv6 addresses. The DHCP VPN drafts either use a "NVT ASCII VPN
Identifier" or a "RFC 2685 VPN ID". RFC 2685 defines a seven byte VPN
identifier, consisting of a three byte OUI and a four byte VPN identifier
unique within the context of the OUI.

I'm not sure of the urgency of MIB support for DHCPv4 servers that support
multiple VPNs...

-- Rich

-----Original Message-----
From: Barr Hibbs [mailto:rbhibbs@pacbell.net]
Sent: Monday, March 24, 2003 9:14 PM
To: Juergen Schoenwaelder
Cc: Woundy, Richard; Glenn Waters; mreview@ops.ietf.org
Subject: RE: FW: Question regarding address specs for IPv4-only protocol
MIBs



I'm not sure I understand your point:  I don't at all understand the terms
"non-globally scoped address" and "zone identifier" in the IPv4 context.

A DHCPv4 server DOES NOT listen for requests on the well-known port for
DHCPv6, will NEVER offer IPv6 addresses to its clients (all of which MUST be
IPv4), will NEVER support IPv6 addresses in its options, NOR will it EVER
support DHCPv6 protocol messages.

A DHCPv6 server is NOT an extension or upgrade path from DHCPv4:  the
protocols use different message formats, different port numbers, and a
different protocol exchange.  We do not believe that they can coexist on the
same host.

--Barr Hibbs



> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> Sent: Monday, March 24, 2003 15:02
>
> Barr> As the protocol messages, method of address allocation, and
> Barr> methods of identifying clients and leases are completely
> Barr> different between DHCPv4 and DHCPv6, we believe that this
> Barr> subtree could only be used for a DHCPv4 server.
>
> Barr> Alternative One: specify the addresses using the InetAddressIPv4
> Barr> convention -- this is, perhaps, the simplest approach.
>
> Barr> Alternative Two: specify the addresses using the pair
> Barr> InetAddressType and InetAddress, including the enumeration
> Barr> clause "{ ipv4(1) }" for InetAddressType and the size clause
> Barr> "(SIZE(4))" for InetAddress, along with the text "An
> Barr> implementation is only required to support IPv4 addresses" in
> Barr> each object description -- this is slightly misleading because
> Barr> the subtree is not intended to ever be used for IPv6.
>
> Barr> Alternative Three: specify the addresses as in Two, but without
> Barr> the restricting enumeration and size clauses, adding explanatory
> Barr> text to the conformance section -- this unfortunately causes the
> Barr> OID subidentifier strings used in the index of four tables to
> Barr> exceed the maximum size (by as much as 382.)
>
> Alternative One only works if you will never ever have to support non
> globally scoped addresses which potentially require a zone identifier
> values to be distinguishable. If you can't be totally sure, using
> alternative Three is the safer bet.
>