RE: FW: Question regarding address specs for IPv4-only protocol MIBs

["Barr Hibbs" <rbhibbs@pacbell.net>]

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.
>