Re: in-addr for v6

Robert Elz <kre@munnari.oz.au> Sat, 12 November 1994 00:56 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08994; 11 Nov 94 19:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08988; 11 Nov 94 19:55 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16263; 11 Nov 94 19:55 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08979; 11 Nov 94 19:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08952; 11 Nov 94 19:54 EST
Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa16230; 11 Nov 94 19:54 EST
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18363; Sat, 12 Nov 1994 10:14:20 +1100 (from kre@munnari.OZ.AU)
To: "Michael A. Patton, special reply address" <MAP=Reply@bbn.com>
Cc: ietf@CNRI.Reston.VA.US
Subject: Re: in-addr for v6
In-Reply-To: Your message of "Fri, 11 Nov 1994 16:08:36 EST." <map=1994Nov11160836@gaak.bbn.com>
Date: Sat, 12 Nov 1994 10:14:16 +1100
Message-Id: <13233.784595656@munnari.OZ.AU>
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert Elz <kre@munnari.oz.au>

    Date:        Fri, 11 Nov 1994 16:08:36 EST
    From:        "Michael A. Patton" <MAP@BBN.COM>
    Message-ID:  <map=1994Nov11160836@gaak.bbn.com>

    For a technique like I described above, the zone
    administrator (a human, presumably at least marginally intelligent)
    needs to know (and tell the program).

This is exactly the problem - the system you describe will
probably work well enough now that it could be very useful.
With IPv6, addresses are supposed to be able to dynamically
change - if that is how it turns out, we can't really be relying
on humans updating files all over the place, both because the
volume of work will be too great, and because some will get
forgotten, leading to an almighty mess.

If this is to work at all, it has to be totally automated,
and not rely on humans, however intelligent we can assume they
are.

There have been (in other messages) a couple of references to
rfc1706 on this topic.  The techniques in rfc1706 are just fine
(rfc1706 relates to nsap reverse mapping), and something like
that can doubless solve the technical issues of how to
represent the address for lookups, and the formats of RR's,
etc.  We could discuss the details, but not here, but there's
no question that the DNS techniques are a tractable problem, and
not even a difficult one.

Its the dynamics that make this hard, not the bit twiddling.

kre