Thanks so much for your prompt and thoughtful reply. I do not quite understand yet, though, so let me seek clarification.
I understand that privacy addresses are not for the link-local prefix, but for address scopes greater than link-local. I would like to be able to have an interface construct it's link-local address using the EUI-64 method, but then configure a privacy address for the prefix assigned to the link. I would like this to work even if I do not configure a greater-than-local-scope autoconfigured address that would accept inbound connections. I see now, writing this, that without an RA, hosts with interfaces on the link would not know the /64-bit prefix to use when constructing the global-scope (for example - could of course be a ULA prefix too) privacy address. So, let me revise my comment, focusing on requirements. 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. The result would be a privacy address that not only protected my privacy for outbound sessions, but improved my stealthly-ness from off-link attackers as well. This is not supported today, I do not believe, but I think it would be a valuable tool for administrators to have. What is your opinion? John Spence, Command Information (HQ: Herndon VA) -----Original Message----- From: Suresh Krishnan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 7:20 AM To: John Spence Cc: ipv6@ietf.org Subject: Re: Is there any provision in privacy addressing, autoconfiguration, or ND specifications to have privacy address and *not have* autoconfigured addresses? Hi John, Please find comments inline Cheers Suresh John Spence wrote: > My reading of the current and proposed specs are that privacy addresses > may be generated in addition to autoconfigured addresses (of scope > greater than link-local). Is there any provision for having **only** > privacy addresses, and no autoconfigured addresses? This would make it > more difficult (in a good way) to find interfaces using inbound > connections, such as scanning. In my reading of > [http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-04 .txt], > section 3, bullet 2 begins "Create additional addresses ...". Perhaps > there is another reference, but that implies that privacy addresses can > only complement public autoconfigured addresses, not take the place of them. The term additional is used to refer to addresses which are not link-local. This term is introduced n the second paragraph of section 1, where we see the following text. "All nodes combine interface identifiers (whether derived from an IEEE identifier or generated through some other technique) with the reserved link-local prefix to generate link-local addresses for their attached interfaces. Additional addresses can then be created by combining prefixes advertised in Router Advertisements via Neighbor Discovery [DISCOVERY] with the interface identifier." If you feel further clarification is required, please let me know. I am in the middle of doing a new revision. > > > > I'm sure there would be side-effects (like how could an administrator > invalidate a privacy address early by removing or changing the prefix > being sent by the router if autoconfiguration is not in use). Autoconfiguration IS still IN USE even with privacy addresses. The prefix can be invalidated just as well with privacy addresses as with non-privacy addresses. I do not see any issues in this regard. In short privacy addresses just extend stateless autoconf, and hence will retain all the properties of a stateless autoconf address. > > > > So, my question then is "Do the current or proposed specs allow me to > have an interface with a link-local address and a privacy address only, > no static and no autoconfigured"? Yes. > > > > **John Spence****, **Command Information (HQ: Herndon VA) > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
