>>>>> On Thu, 17 Aug 2006 12:50:51 -0400,
>>>>> "John Spence" <[EMAIL PROTECTED]> said:
> I would like the capability to have an interface construct a link-local
> address via some mechanism (EUI-64 from MAC, as an example) as normal,
> then configure a privacy address, all without autoconfiguring a
> global-scope address from the RA being sent on the subnet (there would
> be no valid or preferred global-scope addresses containing the MAC).
> This interface would be harder to scan for from off-link, since the only
> valid global-scope address would be a privacy address - no
> autoconfigured address embedding FFFE or a small set of OUIs (there are
> probably only a few hundred OUIs really in wide deployment) would be
> configured on the interface.
> This could be accomplished, I think, by allowing the node to passively
> listen to RAs, to learn the valid /64 prefixes assigned to the link, and
> then global-scope privacy addresses could be configured. Perhaps the
> node could allow a configuration option like "USE_PRIVACY_ONLY=yes".
> Other interfaces on other nodes on the subnet could use
> autoconfiguration, either with or without privacy addresses, as desired.
Regarding the protocol specification
(draft-ietf-ipv6-privacy-addrs-v2-04), my read is that this behavior
is beyond the description of the spec if not disallowed.
Specifically, it states at bullet 3 of Section 3.3:
3. When a new public address is created as described in [ADDRCONF],
the node SHOULD also create a new temporary address.
I don't think this can be interpreted as allowing the creation of
a temporary address only. Also, if we allowed that, the following
bullet could not be implemented at least in its literal sense:
4. When creating a temporary address, the lifetime values MUST be
derived from the corresponding prefix as follows:
* Its Valid Lifetime is the lower of the Valid Lifetime of the
public address or TEMP_VALID_LIFETIME
because "the Valid Lifetime of the public address" is meaningless
unless the public address doesn't exist.
It would not be so hard to modify the spec so that we can allow the
"private-only" configuration, but I'm not convinced the possible
benefit is worth the effect (on the document and on the existing
implementations).
Regarding the implementation, BSD/KAME implements the specification in
a straightforward way, and so it doesn't allow a temporary address to be
configured without the corresponding public address. Again, it would
not be so hard to modify the implementation to allow that, but I don't
think the possible benefit is worth the additional code.
By the way, if your goal is to minimize the chance of revealing an
existent address by scanning (and if you're not satisfied with the
effective scan range of IEEE based interface IDs), I think you can
simply specify a non-EUI-64 public IFID by playing a dice (and setting
the universal/local bit to 0). Even though this might look against
the description about generating "standard" IFIDs shown in RFCs (e.g.,
RFC2464), I believe this is generally interpreted as part of
operational choices. In fact, I know some operators configure
well-known service addresses with "readable" IFIDs such as 2001:db8::1
even when the prefix part is automatically configured via RA. You
should be able to do the same thing with a "more-unreadable" IFID.
For KAME/BSD, you can do that by configuring the link-local address
with the non-EUI-64 IFID at the system boot time. Then non-link-local
addresses configured via RA will also have the same IFID, which I
believe meet your requirement (for that matter, whether you also
configure a temporary address or not is irrelevant to this discussion).
I don't know whether other implementations support the same feature,
though.
Another operational approach would be to block incoming packets to the
public address by a local firewall as you indicated in a separate
message. If you also configure a system-wide switch (when available)
so that temporary addresses will be preferred as the source address of
outgoing packets, you'll be fine without much trouble (except the ones
due to shorter lifetimes of the temporary addresses).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
