While implementing draft-ietf-ipngwg-addrconf-privacy-01.txt, some issues
have come up that I'd like to discuss.
The good news is that with the changes I propose below, it does work great.
First some review... RFC 2462 section 5.5.3 discusses processing of a Prefix
Information option for address auto-configuration. The basic idea is
- If the interface has any auto-configured addresses that match the prefix,
then their Valid & Preferred lifetimes are reset to the prefix lifetimes in
the RA. (There's a complication about not decreasing the Valid Lifetime
below two hours.)
- If the interface has no addresses that match the prefix (auto-configured
or not), and the Valid Lifetime in the RA is non-zero, then you configure a
new address (prefix + interface-id) with lifetimes taken from the RA.
So in normal operation, the first RA that you get will create an address,
the address lifetimes will decay until the next RA arrives, and then the
address lifetimes will be reset.
The basic mechanism in the privacy draft is to create two addresses instead
of one in response to a prefix information option. Addresses with an
IEEE-derived interface identifier are called public addresses, addresses
with a randomly chosen interface identifer are called anonymous addresses.
If you get a DAD collision on an anonymous address, then you try again with
another randomly chosen interface identifier. Anonymous addresses are
intended to be fairly ephemeral - the draft recommends by default that they
have a preferred lifetime of one day and a valid lifetime of two weeks. When
choosing a source address, you prefer anonymous addresses to public
addresses - the draft achieves this by saying public addresses are created
with a zero preferred lifetime so they are deprecated.
So in normal operation, the first RA that you get will create a public
address and an anonymous address. The anonymous address will be deprecated
after a day and a new anonymous address will be created. Eventually in
steady state you'll have fourteen anonymous addresses (all but one
deprecated) for each public address. The draft allows implementations to
remove deprecated anonymous addresses that are known to be not in use by any
application, but this is not always feasible.
Some issues that came up during implementation:
Issue 1. You don't want to increase the lifetimes of existing anonymous
addresses when you are processing a prefix information option. You want them
to age away. I think it is appropriate to lower anonymous lifetimes, in case
an admin decides to start removing a prefix by lowering lifetimes in the
RAs.
Issue 2. If a prefix information option has a zero preferred lifetime, then
you should create a public address but not an anonymous address. Creating a
new anonymous address with a zero preferred lifetime is at best pointless.
Issue 3. When an anonymous address becomes deprecated, should you always
create a new anonymous address? What lifetimes do you use for the new
anonymous address? For example, suppose an admin changes the advertisement
of a prefix to have zero preferred lifetime. This causes existing public &
anonymous addresses that match the prefix to become deprecated. When the
existing preferred anonymous address becomes deprecated, this should not
cause the creation of a new anonymous address.
Issue 4. When an anonymous address is deprecated and a new anonymous address
is created, there's a small window in which a new connection doesn't have a
good source address choice. This is because the old anonymous address is
deprecated and the new anonymous address is still tentative. (I saw this
happen in testing.)
Issue 5. The end result is a LOT of unicast addresses assigned to an
interface. Fourteen anonymous addresses for each public address, and there
might easily be multiple public addresses. The bad thing about this is that
the anonymous addresses all have different low bits, so they result in
different solicited-node multicast addresses, which in turn produce
different ethernet multicast groups. So you likely end up putting your
ethernet card in promiscuous mode because it can't handle so many groups.
Issue 6. In some environments, network administrators will want to disable
the privacy. For example, I was thinking of using a flag bit in the prefix
information option to control whether an anonymous address is created for
the prefix. But this has to be balanced with the users privacy - you don't
want a home user to not get privacy because their ISP is lazy and disables
it.
>From an implementation view, there's the question of what kind of
relationship needs to be maintained between public addresses & anonymous
addresses. Do operations on the anonymous address need to refer to the
corresponding public address, or vice-versa?
Here is a proposal:
1. Public addresses are NOT created with a zero Preferred lifetime. Instead
they have normal preferred & valid lifetimes. Source address selection has a
new rule, separate from the deprecated/preferred rules, to prefer anonymous
addresses over public addresses.
2. When updating the lifetimes of existing auto-configured addresses in
response to a received Prefix Information option, you never raise the
lifetimes of anonymous addresses. You do lower their lifetimes if the
received RA has smaller lifetimes.
3. You never create an anonymous address with a zero preferred lifetime.
4. When an anonymous address becomes deprecated (because it's preferred
lifetime expires normally), you create a new anonymous address only if the
corresponding public address has a non-zero preferred lifetime. If an
anonymous address becomes deprecated because it's preferred lifetime is set
to zero while processing an RA, then you do NOT create a new anonymous
address - note that the corresponding public address will also have its
preferred lifetime set to zero by this RA.
5. When you create an anonymous address (either this is the first time you
are creating an anonymous address corresponding to a public address, or
because of DAD failing for an anonymous address, or because an old anonymous
address is being deprecated), you use the following lifetimes:
valid lifetime = MIN(corresponding public's valid lifetime, two weeks)
preferred lifetime = MIN(corresponding public's preferred lifetime, one day)
(Because the corresponding public's preferred lifetime <= its valid
lifetime, these formulas will always produce an anonymous preferred lifetime
<= valid lifetime.)
6. Actually, you create a new anonymous address a few seconds before an
existing anonymous address becomes deprecated, instead of waiting until it's
actually deprecated. This gives DAD some time to work. I think five seconds
for this regenerate interval is about right.
7. So I said above it was wrong to create a new anonymous address with a
preferred lifetime of zero. Actually, I think you should never create a new
anonymous address with a preferred lifetime smaller than the regenerate
interval - if the formula in proposal 5 produces a preferred lifetime that
is smaller than five seconds, just don't create the anonymous address.
8. You don't create a new random interface-identifier each time you generate
an anonymous address. Instead you keep a current random interface-identifier
associated with an interface, and use it when generating an anonymous
address. Whenever the random interface-identifier is more than a day old
(default value: the max preferred lifetime for anonymous addresses minus the
regenerate interval, so one day less five seconds), you generate a new
random interface identifier. This means that if you have anonymous addresss
with multiple prefixes, then they will share their interface identifers.
Also I suggest lowering the default max valid lifetime from two weeks to one
week. In combination, this means that you will have seven different random
interface-ids in use simultaneously, no matter how many prefixes you are
using.
An implementation consequence of all this is that you do need to find the
corresponding public addresses from an anonymous address. But the reverse
direction is not mandated.
Comments?
Thanks,
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
