Subject: Is there any provision in privacy addressing, autoconfiguration, or ND specifications to have privacy address and *not have* autoconfigured addresses?

From: "John Spence" <[email-masked]>
Date: Thu, 17 Aug 2006 08:52:55 -0400

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

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

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"?

John Spence, Command Information (HQ: Herndon VA)

[email-masked] <mailto:[email-masked]> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 17 Aug 2006 10:19:55 -0400

Hi John,
   Please find comments inline

Cheers
Suresh

John Spence wrote:
> greater than link-local).  Is there any provision for having **only** 
> [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 

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 
> no static and no autoconfigured”?

Yes.

> 
>  
> 
> **John Spence****, **Command Information (HQ: Herndon VA)
> 
> ------------------------------------------------------------------------
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Aug 2006 08:48:34 -0700

Hi Suresh, 

> all the properties of a stateless autoconf address.

Privacy addresses can also be configured using DHCP, right?

Fred
[email-masked]

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Aug 2006 09:45:20 -0700

RFC 3041 specifies privacy for autoconfiguration only. If DHCP is in use, 
the node can simply request multiple addresses from DHCP, and to the extent 
that the DHCP server allows a node to have more than one address, different 
addresses can be used for different transactions.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Suresh Krishnan" <[email-masked]>; "John Spence" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 17, 2006 8:48 AM
Subject: RE: Is there any provision in privacy addressing, 
autoconfiguration,or ND specifications to have privacy address and *nothave* 
autoconfiguredaddresses?

Hi Suresh,

Fred

---

From: "John Spence" <[email-masked]>
Date: Thu, 17 Aug 2006 12:50:51 -0400

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-masked]] 
Sent: Thursday, August 17, 2006 7:20 AM
To: John Spence
Cc: [email-masked]
Subject: Re: Is there any provision in privacy addressing,
autoconfiguration, or ND specifications to have privacy address and *not
have* autoconfigured addresses?

Hi John,

Cheers
Suresh

.txt], 
> section 3, bullet 2 begins "Create additional addresses ...".  Perhaps

Yes.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Aug 2006 09:50:25 -0700

James,

I'm looking at (RFC3315, Section 22.5), and it seems that there
is an "Identity Association for Temporary Addresses" (IA_TA)
using RFC3041.

I assume this will implicitly also support RFC3041(bis)?

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 9:45 AM
To: Templin, Fred L; Suresh Krishnan; John Spence
Cc: [email-masked]
Subject: Re: Is there any provision in privacy addressing,
autoconfiguration,or ND specifications to have privacy address and
*nothave* autoconfiguredaddresses?

RFC 3041 specifies privacy for autoconfiguration only. If DHCP is in
use, 
the node can simply request multiple addresses from DHCP, and to the
extent 
that the DHCP server allows a node to have more than one address,
different 
addresses can be used for different transactions.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Suresh Krishnan" <[email-masked]>; "John Spence" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 17, 2006 8:48 AM
Subject: RE: Is there any provision in privacy addressing, 
autoconfiguration,or ND specifications to have privacy address and
*nothave* 
autoconfiguredaddresses?

Hi Suresh,

Fred

---

From: "Eric Klein" <[email-masked]>
Date: Thu, 17 Aug 2006 21:02:04 +0300

Comment at the end.

> valuable tool for administrators to have.  What is your opinion?

This sounds remarkably like you are trying to recreate RFC1918 addresses to 
me or to mimic NAT. Both of which are (currently) being kept out of IPv6. 
please see draft: IPv6 Network Architecture Protection 
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-03.txt for an 
explination as to why these are not encouraged in IPv6.

Eric

---

From: "John Spence" <[email-masked]>
Date: Thu, 17 Aug 2006 15:36:40 -0400

I am not trying to anything like NAT.  My question does not involve
translation at all.

I am interested in improving the hiding capability of "client" nodes on
any network by not autoconfiguring a global-scope address that
incorporates any portion of any unique identifier (like a MAC address)
on my interface.  My privacy-only addressing scheme would give me a
globally-routable address.  I would be forgoing peer-to-peer capability,
but no more so than a host that used only stateless autoconfiguration.

So, nothing to do with NAT.

John Spence, Director, IPv6 Technical Operations
Command Information (HQ: Herndon VA)
2001 6th Avenue, Suite 3210, Seattle, Washington 98121
w: 206.448.5553 m: 425.260.0112
[email-masked]

-----Original Message-----
From: Eric Klein [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 11:02 AM
To: [email-masked]
Subject: Re: Is there any provision in privacy addressing,
autoconfiguration,or ND specifications to have privacy address
and*nothave* autoconfigured addresses?

Comment at the end.

> valuable tool for administrators to have.  What is your opinion?

This sounds remarkably like you are trying to recreate RFC1918 addresses
to 
me or to mimic NAT. Both of which are (currently) being kept out of
IPv6. 
please see draft: IPv6 Network Architecture Protection 
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-03.txt for an 
explination as to why these are not encouraged in IPv6.

Eric

---

From: Bob Hinden <[email-masked]>
Date: Thu, 17 Aug 2006 13:26:38 -0700

John,

> configured on the interface.

First of all, even with the auto-configured addresses, it still very  
hard to do any kind of scanning.  The IEEE mac based interface IDs  
are very sparse.

I don't think anything new is required to do what you want.  A node  
can create auto-configured address and privacy addresses.  Which  
addresses it uses for what purposes is completely under it's  
control.  It doesn't have to use the auto-configured address for  
communication if it doesn't want to.  It could only use the privacy  
based address if it choose to.

> valuable tool for administrators to have.  What is your opinion?

I personally don't think this is very useful, but it is allowed under  
the current specifications.  Implementors and/or vendor could easily  
build in this type of address usage policy if they saw a need or  
customer requirement.

Bob

---

From: "John Spence" <[email-masked]>
Date: Thu, 17 Aug 2006 16:39:09 -0400

Hi Bob - thanks for the quick reply.  Three things:

1) If I have autoconfiguration enabled, and I autoconfigure a
global-scope address from an RA where the valid lifetime is greater than
zero (the usual case certainly), I would normally respond to connections
from other nodes at that address.  I guess I could use a platform
firewall to suppress that.  I guess I'd like a switch that says "do not
consider autoconfigured addresses valid even if they have a positive
valid lifetime", but I think that would put me at odds with the ND
specifications.  Maybe the platform firewall is a solution.

2) As for the value, I like it when implementers have choices.  I hear
people talk about the difficulty of scanning a 128-bit addressing space,
but it is not hard, if autoconfiguration is in use and the attacker
knows a little about an organization, to get that down to more like a 10
OUIs x 2^24 problem.  You are right - still significant - but not
insurmountable.

3) I got on off-list suggestion that maybe CGA is a potential solution
for this, which is a good thought too.

John Spence

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 1:27 PM
To: John Spence
Cc: [email-masked]
Subject: Re: Is there any provision in privacy addressing,

John,

Bob

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 18 Aug 2006 14:17:09 +0900

>>>>> On Thu, 17 Aug 2006 12:50:51 -0400, 
>>>>> "John Spence" <[email-masked]> said:

> 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-masked]

---

From: "Eric Klein" <[email-masked]>
Date: Fri, 18 Aug 2006 10:02:27 +0300

John

> I am not trying to anything like NAT.  My question does not involve
I understand that NAT is not what you want.

> but no more so than a host that used only stateless autoconfiguration.

This is what we wanted to show to the v6 Ops group.

You should read the NAP (Network Address Protection) document as it talks 
about this topic. Originally we were trying to show that address protection 
is important and translation is not a good idea as it breaks things up.

please see draft: IPv6 Network Architecture Protection
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-03.txt

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 18 Aug 2006 09:45:51 +0200

John Spence wrote:
> firewall to suppress that.

Depending on your trust in the network you either firewall on the 
borders (easiest) or you deploy some per-host firewall that can be 
reconfigured from a central point (eg Active Directory style or custom 
scripted)

> OUIs x 2^24 problem.  You are right - still significant - but not

RFC3041 and also read the NAP draft for a lot of other solutions to 
these silly questions.

> for this, which is a good thought too.

Which is a patent bait waiting to happen according to many discussions.

RFC3041 is all you need and is already implemented. You might want to 
add the per-host firewall if you really require that though.

Greets,
  Jeroen

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Aug 2006 09:45:25 -0700

Suresh,

.txt]

This draft seems to link itself unnecessarily with Stateless
Address Autoconfiguration, since it seems that the same
mechanisms work under DHCPv6 - see: (RFC3315, Section 22.5).
Unless I am missing something, the only difference I see is
that the entity that generates the temporary addresses is
the DHCP server instead of the client.

In particular, the text of Section 2.4, paragraph 1 beginning:
"But DHCPv6 will solve the privacy issue" is new since RFC3041
and seems to make questionable statements about the use of DHCP
for generating temporary addresses, since 1) the server can be
configured to hand out temporary addresses with short preferred/
valid lifetimes, and 2) the client can go back to the server to
get new temporary addresses whenever it wants to regardless of
preferred/valid lifetimes.

Again, unless I am missing something, suggestions are to
1) remove this new text from Section 2.4, and 2) relax any
text (including the document title) that links the generation
of privacy addresses with Stateless Address Autoconfiguration.

Fred

---

From: Ralph Droms <[email-masked]>
Date: Sat, 19 Aug 2006 08:43:24 -0400

Fred correctly points out that this text from draft-ietf-ipv6-privacy- 
addrs-v2-0.txt is inaccurate:

2.4  Possible Approaches

    One way to avoid having a static non-changing address is to use
    DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could be
    configured to hand out addresses that change over time.  But DHCPv6
    will solve the privacy issue only if it frequently handed out
    constantly changing addresses to the nodes or if the DHCPv6 client
    moves from links to links frequently, being allocated independent
    addresses from different DHCPv6 servers.  However, the former does
    not happen automatically, and is difficult to configure manually;  
the
    latter cannot be assumed for static (not frequently moving) hosts.
    Thus, DHCPv6 is not a self contained alternative for solving the
    privacy issues addressed by this document.  However, in the absence
    of stateless address autoconfiguration, DHCPv6 can be used for
    distributing temporary addresses to clients.

DHCPv6 explicitly includes the IA_TA (IA for temporary addresses)  
construct which provides for RFC 3041 addressing; see section 12 of  
RFC 3315:

12. Management of Temporary Addresses

    A client may request the assignment of temporary addresses (see RFC
    3041 [12] for the definition of temporary addresses).  DHCPv6
    handling of address assignment is no different for temporary
    addresses.  DHCPv6 says nothing about details of temporary addresses
    like lifetimes, how clients use temporary addresses, rules for
    generating successive temporary addresses, etc.

    Clients ask for temporary addresses and servers assign them.
    Temporary addresses are carried in the Identity Association for
    Temporary Addresses (IA_TA) option (see section 22.5).  Each IA_TA
    option contains at most one temporary address for each of the
    prefixes on the link to which the client is attached.

    The IAID number space for the IA_TA option IAID number space is
    separate from the IA_NA option IAID number space.

    The server MAY update the DNS for a temporary address, as described
    in section 4 of RFC 3041.

Fred, thanks for your careful read and analysis of RFC 3315.

- Ralph

---

From: Bob Hinden <[email-masked]>
Date: Mon, 21 Aug 2006 14:45:55 -0700

Fred,

> of privacy addresses with Stateless Address Autoconfiguration.

I agree that the text in Section 2.4 that is incorrect should be  
fixed or removed.

This document is in the IESG for Draft standard, so I think it is out  
of scope to make broader changes like changing the document title, etc.

Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 21 Aug 2006 18:43:22 -0400

Hi Fred,
   This text was added as a compromise between dhcp folks and non dhcp 
folks. I added this text in October 2004 and I sent out the following 
mail to the list. Since I heard no objections, I assumed that the text 
was acceptable

http://www1.ietf.org/mail-archive/web/ipv6/current/msg03770.html

If the text is no longer acceptable I am open to redoing the text

Thanks
Suresh

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 24 Aug 2006 20:48:19 +0900

>>>>> On Mon, 21 Aug 2006 14:45:55 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> of scope to make broader changes like changing the document title, etc.

I agree with you on both the points.  I think we can simply update the
first paragraph of Section 2.4 to something like this:

   One way to avoid having a static non-changing address is to use
   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server can be
   configured to hand out "temporary addresses", which are never
   renewed and provide the same property of temporary addresses
   described in this document with regards to the privacy concern.

					JINMEI, Tatuya

p.s., I also think RFC3315 could have been more specific about how to
update the temporary addresses rather than stating "DHCPv6 says
nothing about details" (Section 12 of RFC3315).  We should eventually
do that in some place, but (IMO) it's definitely not in
privacy-addrs-v2.  Perhaps we can do it in rfc3315bis in the future...

---

From: Ralph Droms <[email-masked]>
Date: Thu, 24 Aug 2006 17:08:55 -0400

Jinmei-san - in a private conversation, I made the following
recommendations:

After re-reading draft-ietf-ipv6-privacy-addrs-v2-04.txt, I
think the Abstract is now fine.  I would recommend changing the first
sentence of the Introduction to:

    Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
    node generates addresses using information about available prefixes
    obtained through Router Advertisement messages.

I recommend removing section 2.2 (as I did in the earlier post cited
by Suresh), as experience with IPv4 addressing has little bearing on
IPv6.  This observation is bolstered by the text in section 2.3
describing the problem addressed by privacy addresses.  For example,
a device gets an entirely new IPv4 address when it moves to a new
connection point, so tracking that device as it moves between connection
points is harder than in IPv6.  And, I think there is a fundamental problem
that most IPv4 stacks and applications are built on the assumption of a
single address per interface, so privacy addresses would be hard to use in
any event.  If section 2.2 is retained, some of the details should be
corrected; e.g., "Over the last few years, sites have begun moving
away from static allocation to dynamic allocation via DHCP [DHCP]."
sounds dated.

I recommend the same text as I recommended before for section 2.4:

     One way to avoid some of the problems discussed above is to use
     DHCPv6 [DHCPV6] for obtaining addresses.  Section 12 of RFC 3315
     discusses the use of DHCPv6 for the assignment and management of
     "temporary addresses" (privacy addresses).  Temporary addresses are
     managed separately from non-temporary addresses, so a host can
     differentiate between the two types of addresses.  The lifetimes of
     temporary addresses are independent of the lifetimes of any other
     addresses, so the frequency of replacement for temporary addresses
     can be adjusted as required.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 25 Aug 2006 15:49:51 +0900

>>>>> On Thu, 24 Aug 2006 17:08:55 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> Jinmei-san - in a private conversation, I made the following

(snip)

>      can be adjusted as required.

If I understand the context correctly, this is the only recommendation
regarding this thread, right?  So I'm responding to this part first:

I don't have an objection to your recommended text.  I personally
think this is too much for this document and prefer mine, but it's
probably a matter of taste.

I'm not sure if we want to discuss the other recommendations right now

>     obtained through Router Advertisement messages.

I'm fine with removing the reference to DHCPv6, but then I'd like to
change "how an IPv6 node generates addresses" to "how an IPv6 node
autonomously generates addresses" so that the important characteristic
of stateless address autoconfiguration is clear.

> away from static allocation to dynamic allocation via DHCP [DHCP]."

I don't have a strong opinion on this, but I personally think the
current text is okay as general background information, and it doesn't
sound odd to me.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Aug 2006 06:13:17 -0400

I'm sorry for introducing other recommendations into your thread.  I
forwarded comments from a private exchange about the draft.  I'll separate
the other recommendations out into a different thread.

I don't have a strong opinion about your text, either and perhaps brevity is
a virtue.  How about:

   One way to avoid having a static non-changing address is to use
   DHCPv6 [DHCPV6] for obtaining addresses.   Section 12 of RFC 3315
   discusses the use of DHCPv6 for the assignment and management
   of "temporary addresses", which are never renewed and provide the same
   property of temporary addresses described in this document with regards
   to the privacy concern.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Aug 2006 06:18:06 -0400

On 8/25/06 2:49 AM, "JINMEI Tatuya / 神明達哉"
<[email-masked]> wrote:

> [...]

OK:

    Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
    node autonomously generates addresses using information about available
    prefixes obtained through Router Advertisement messages.

> current text is okay as general background information, and it doesn't

If the text is retained, it needs to be updated and corrected.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 Aug 2006 15:21:28 +0900

>>>>> On Fri, 25 Aug 2006 06:13:17 -0400, 

>    property of temporary addresses described in this document with regards

I'm fine with this text.  We might want to replace "RFC 3315" with
[DHCPV6] for consistency though.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 Aug 2006 15:28:16 +0900

>>>>> On Fri, 25 Aug 2006 06:18:06 -0400, 

> If the text is retained, it needs to be updated and corrected.

Perhaps, but in any event I don't insist on a particular way, whether
to remove or keep this subsection (and with or without modification).
I'd basically leave the decision to the editor.  Of course, I'm
willing to review the revised text if it's updated and a review is
required.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Thu, 31 Aug 2006 08:35:36 -0400

Suresh - I think Jinmei-san and I have come to agreement on replacement text
in section 2.4 (see below).

- Ralph

> [DHCPV6] for consistency though.

I agree with replacing RFC 3315 with [DHCPV6].

---

From: Pekka Savola <[email-masked]>
Date: Thu, 31 Aug 2006 16:18:08 +0300 (EEST)

> in section 2.4 (see below).

As a WG participant, if we want to go ahead with the change, I'd 
expect WG chairs to issue a last call of some sort for the changes 
(giving a good motivation for the change), given that the document has 
already left the WG quite a while ago.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ralph Droms <[email-masked]>
Date: Thu, 31 Aug 2006 09:24:52 -0400

Pekka - I would agree if the text in question were a key component of the
protocol specification.  But, because this text is background material and
the discussion has been conducted on the WG mailing list, I don't think a
last call is warranted for this text.

Of course, there may be other changes to the doc that would more strongly
suggest a WG last call...

- Ralph

On 8/31/06 9:18 AM, "Pekka Savola" <[email-masked]> wrote:

> autolearn=ham version=3.1.4
> X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 31 Aug 2006 19:34:05 +0300 (EEST)

> last call is warranted for this text.

If the text has little relevance, then I don't see why it needs to 
change.  AFAIR, it was significantly debated, and reopening that 
discussion might not be the best use of our time and energy.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2006 09:41:48 -0700

> If the text has little relevance, then I don't see why it needs to change.

The current text in (RFC3041(bis), Section 2.4, paragraph 1) is inaccurate as
discussed earlier in this thread.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2006 09:46:18 -0700

I agree with this resolution.

Fred

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Thursday, August 31, 2006 5:36 AM
To: Suresh Krishnan
Cc: [email-masked]; Templin, Fred L; [email-masked]; JINMEI Tatuya / 神明達哉 
Subject: Re: DHCP for privacy addresses (was: RE: Is there any provisionin privacy addressing ...)

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 31 Aug 2006 12:39:06 -0400

Pekka - the discussion has already occurred on the ipv6 WG mailing list and
we have consensus on replacement text.  I don't see a need to further waste
the WG's time with additional discussion in a WG last call now that the
interested parties have already come to consensus.

I didn't say the text is irrelevant, I said it was background material.
More precisely, the text does not affect the protocol being standardized.
However, the text is, in fact, wrong, and should be corrected.

- Ralph

---

From: Bob Hinden <[email-masked]>
Date: Thu, 31 Aug 2006 17:48:48 -0700

Pekka,

On Aug 31, 2006, at 6:18 AM, Pekka Savola wrote:

> (giving a good motivation for the change), given that the document  
> has already left the WG quite a while ago.
>

The chairs believe these changes are editorial in nature and don't  
require another working group last call.

That said, if anyone has any objections to the proposed changes  
please speak up.

Bob Hinden / Brian Haberman