gmane.ietf.ipv6

Revision of draft-ietf-6man-stable-privacy-addresses

Fernando Gont — 2013-05-19T17:33:27

Folks,

I've posted a rev of the aforementioned document, meant to address the
comments received during IETF LC.

This rev is the result of the IETF LC discussions we had on the 6man wg
list and on the general IETF list, and of off-list discussions with a
number of folks who generously provided input, reviewed proposed
changes, etc.

I'd expect this rev to be "ready to ship" or very close to that. But
please provide your input confirming whether you think that's the case,
or whether there are any remaining issues to be solved.

The rev is available at:
<http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-07>.

A diff from the previous version of the I-D is available at:
<tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-06.txt&url2=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-07.txt>.

Thanks so much!

Best regards,

solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt

Hosnieh Rafiee — 2013-05-14T20:37:22

Hello,

A new version of http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy is
available online. I considered the comments that I received and made the
pertinent changes to this version. I also improved the document to better
address the following issues that I have with RFC 4941.
1- lifetime of the IID  
The fact that the node might not generate a new IID when it receives a new
subnet prefix
Solution: Give the router prefix a higher priority than the IID's max
lifetime
2- Nodes may use an IID that was generated based on a MAC address and use
this in their response
A MAC based IID may still be valid and this RFC does not force the node to
stop using it.
 Solution: The node MUST not generate its IID based on a MAC address when
using this approach. The Privacy Extension RFC does not clearly address
this.
3- A better way to handle trouble shooting and debugging 
4-The need to maintain the status of reserved IIDs and already used IIDs
requiring  a large storage space and the fact that the randomization of IIDs
is limited.
Solution: Using modified CGA algorithm skipping the security steps
5-The cutting of connections when the max lifetime for the IID expires

I would be appreciative if you could find the time to review this draft RFC
and offer constructive comments.

Thanks,
Best,
Hosnieh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[6man] #4: Normative section / Informational section

6man issue tracker — 2013-05-08T20:14:04

#4: Normative section / Informational section

 After reading the document again, the main issue is that the document
 specifies a solution to a problem by detailing a specific implementation,
 but does not explain the design choices behind that solution. As such, we
 end up with an over constrained specification, which at the same time
 fails to explain the problems at hand. The specification aims at providing
 addresses that are "stable and different," so that the same host
 connecting will have different and uncorrelated addresses when connecting
 to different networks, but will keep the same address when connecting
 repeatedly to the same network.

 As Mike St-Johns pointed out, the solution is trivial: create a different
 random number each time the host connect to a new network; make sure that
 the same random number is reused if the host reconnect to the same
 network. The latter property can be achieved either by keeping of log of
 previously visited networks and the corresponding address, or by using a
 "master random number" and combining it with the identification of the
 visited network. In theory, that's about all what the IETF ought to
 specify.

 Instead, the draft goes into great details on how to actually implement
 the random number generator. Apart from not being necessary, some of these
 details are wrong. For example, the suggested algorithm includes an
 "interface index," but different operating systems have different ways of
 enumerating interfaces, and the variations in enumeration could end up
 violating the "stable address" property.

 I would suggest reworking the draft to separate a normative section,
 effectively a variation of the 3 lines paragraph above, and an
 informational section, the current specification of the algorithm as  "an
 example of a way to achieve this result if the operating system meets
 certain condition, like stable interface identifiers."

 I would also explain the inherent issues that have to be solved, e.g.,
 swapping interfaces, or enabling multi-homed hosts. And I would observe
 that the DAD problem cannot be solved ina  reliable way.

[6man] #3: Need for DAD counter

6man issue tracker — 2013-05-08T20:07:44

#3: Need for DAD counter

 Your draft attempts to make the fallback predictable, by incorporating a
 DAD counter in the seeds of your nominal algorithm. But that means
 redefining the solution a only a guarantee that "the visiting host will
 have one of the same 2 or 3 addresses on the visited network." I am not
 sure it is worth the additional complexity, by opposition to just saying,
 "in case of collision, pick a new number."

I-D Action: draft-ietf-6man-resilient-rs-01.txt

2013-05-06T22:51:04

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

Title           : Packet loss resiliency for Router Solicitations
Author(s)       : Suresh Krishnan
                          Dmitry Anipko
                          Dave Thaler
Filename        : draft-ietf-6man-resilient-rs-01.txt
Pages           : 7
Date            : 2013-05-06

Abstract:
   When an interface on a host is initialized, the host transmits Router
   Solicitations in order to minimize the amount of time it needs to
   wait until the next unsolicited multicast Router Advertisement is
   received.  In certain scenarios, these router solicitations
   transmitted by the host might be lost.  This document specifies a
   mechanism for hosts to cope with the loss of the initial Router
   Solicitations.  Furthermore, on some links, unsolicited multicast
   Router Advertisements are never sent and the mechanism in this
   document is intended to work even in such scenarios.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-resilient-rs-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt -

Hosnieh Rafiee — 2013-05-04T19:17:37

Has anybody had a chance to look at this draft
(http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy )? Any comments?
The aim of this draft is to adapt the current RFC to the latest European law
http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en and to
accommodate the needs of customers with relation to the new law for a long
term period. The purpose is to allow users to choose their means to the
privacy and anonymity within a network as well as across networks. 

There is still an option of merging this draft with other drafts, that
address the issue of allowing users to set the lifetime of the IP address
during the installation or an option to set it by the users, if people on
the mailing list thinks it would be useful. 
Share your technical ideas.

Thanks,
Best,
Hosnieh



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

I-D: action - draft-rafiee-6man-ra-privacy-00.txt

Hosnieh Rafiee — 2013-05-02T19:54:20

Dear all,

I explained the purpose of this draft in my last message to the list ( You can find it here http://www.ietf.org/mail-archive/web/ipv6/current/msg17718.html ). I upload this draft which addresses the problems in rfc 4941. I would appreciate your comments. 
Share your ideas as to whether or not you find it useful.

Thanks,
Best,
Hosnieh


Filename: draft-rafiee-6man-ra-privacy
Revision: 00
Title: Router Advertisement based privacy extension in IPv6 autoconfiguration
Creation date: 2013-05-02
Group: Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-rafiee-6man-ra-privacy-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-6man-ra-privacy
Htmlized:        http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-00


Abstract:
   Privacy is an important issue for many governments and users where
   its importance becomes more evident every day. Nodes might change
   their IP addresses frequently in order to avoid being tracked by
   attackers and which also results in the prevention of information
   being leaked from their nodes. In IPv6 networks there is currently
   one solution for maintaining privacy for nodes when IPv6 StateLess
   Address AutoConfiguration (SLAAC) (RFC-4662) is used. Unfortunately
   this solution, i.e., Privacy Extension (RFC-4941), has some problems,
   such as not generating a new Interface ID (IID) after changing the
   router prefix. The RFC also gives no explanation as to how to use CGA
   in its randomizing solution. The purpose of this document is to
   address these issues and to update the current RFC.



                                                                                  


The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Solutions to the problem with RFC 4941

Hosnieh Rafiee — 2013-05-02T19:35:06

Dear All,

 

Since Fernando's proposal is not going to solve the current problem with RFC
4941, I have suggested to him, on several occasions, that he resolve this
problem so that the node's privacy will be better protected but he ignored
this suggestion and claiming that his purpose is different. This is the main
reason that today I wrote an RFC draft which I will submit  to the IETF
repository. This draft does not overlap Fernando's proposal  it is related
to the problems with this RFC (RFC 4941) which he doesn't feel the need to
address. The problems that I address here concern the fact that the node
should also change its IID when it receives different router prefixes.

 

In the experimental results, Windows machine that implemented privacy
extension RFC, generates different IIDs by rebooting .But when it receives a
different prefix without a reboot, then, on the first two occasions that the
new  prefixes received, the node was generated a new IID, but not for other
new prefix generations. Also, as you can see, the temporary addresses have
the same IID. This means that there is a need to change section 8 of this
RFC

   6.  The node is now allowed to generate different interface

      identifiers for different prefixes, if it so desires.

 

Where a different IID should be generated when a different prefix is
received.  I called it "RA-based privacy extension for SLAAC".

   Physical Address. . . . . . . . . : 00-0C-29-FA-38-32

 

   IPv6 Address. . . . . . . . . . . :
2000:abc:ab:0:3003:bfe7:125a:5c0(Preferre

d)

   IPv6 Address. . . . . . . . . . . :
2000:abc:bad:bad:3003:bfe7:125a:5c0(Prefe

rred)

   Temporary IPv6 Address. . . . . . :
2000:abc:ab:0:5d60:2136:554:188b(Preferre

d)

   Temporary IPv6 Address. . . . . . :
2000:abc:bad:bad:5d60:2136:554:188b(Prefe

rred)

   Temporary IPv6 Address. . . . . . :
2000:bad:bad:bad:5d60:2136:554:188b(Prefe

rred)

 

Lifetime of the addresses as long as the computer is on

Addr Type  DAD State   Valid Life Pref. Life Address

---------  ----------- ---------- ---------- ------------------------

Public     Preferred   3314d21m1s 779d18h22m24s
2000:abc:ab:0:3003:bfe7:125a:5c0

Temporary  Preferred   6d23h51m4s 6d23h51m4s
2000:abc:ab:0:5d60:2136:554:188b

Public     Preferred  3314d16m15s 779d18h17m38s
2000:abc:bad:bad:3003:bfe7:125a:

5c0

Temporary  Preferred  6d23h50m22s  23h50m22s
2000:abc:bad:bad:5d60:2136:554:188b

Public     Preferred  3314d21m13s 779d18h22m36s
2000:aed:ab:0:3003:bfe7:125a:5c0

Temporary  Preferred  6d23h55m20s  23h55m20s
2000:aed:ab:0:5d60:2136:554:188b

Public     Preferred  3314d15m26s 779d18h16m49s
2000:bad:bad:bad:3003:bfe7:125a:

5c0

Temporary  Preferred  6d23h49m13s 6d23h49m13s
2000:bad:bad:bad:5d60:2136:554:188

b

 

A second problem that I found with that RFC is the second approach used to
generate the IID. In section 3.2.2 it describes a more randomized  IID
generation approach by using  CGA, but it does not explain how to use this
algorithm when security is not a consideration. In my extension, I also
explain how to use that algorithm if we do not wish to consider security as
a part of CGA. Of course, I derived that section from my last draft , SSAS,
and will remove that section from SSAS. I would prefer that the SSAS
algorithm  focus more on security and then focus on privacy.

 

Best,

Hosnieh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[6man] #2: Description of issues with traditional SLAAC addresses(embedding IEEE identifiers)

6man issue tracker — 2013-04-30T07:51:04

#2: Description of issues with traditional SLAAC addresses (embedding IEEE
identifiers)

 Some folks have noted that this I-D should clarify what are the issues
 with traditional SLAAC addresses (addresses that embed link-layer
 addresses). This is deemed as key to clarify which of them are
 solved/mitigated by the method discussed in this document.

[6man] #1: Proper source for an "Interface Identifier"

6man issue tracker — 2013-04-30T06:22:16

#1: Proper source for an "Interface Identifier"

 Version -06 of the document includes the "interface index" in the
 expression "F()" that generate the stable privacy IIDs. It has been noted
 that interface indexes might not be stable, and that, in any case,
 mandating a specific source for tan "interface identifier" would be over-
 specifying the algorithm

Biggest Fake Conference in Computer Science

2013-04-27T16:48:05

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

AD Evaluation: draft-ietf-6man-addr-select-opt

Brian Haberman — 2013-04-26T15:34:47

Hi all,
      I have performed my usual AD review of 
draft-ietf-6man-addr-select-opt prior to it moving towards IETF Last 
Call.  The document is well-written and I only have a few comments. 
Once we have resolved these, we can move the document along in the 
publication process...

1. Section 2

* The beginning of this section indicates that the Address Selection 
option contains zero or more policy table options.  It would be good to 
clarify that sending an Address Selection option with zero policy table 
options allows the operator to convey the values of the A & P flags.

* The descriptions of "precedence" and "label" should probably indicate 
their direct relationship to the policy table structure in RFC 6724.

2. In section 3, I was expecting better detail in *how* the information 
in the DHCP options is handled.  I am not aware of any other 
DHCP-provided information that is conditional based on the user's whim. 
  This seems like it could lead to hard to diagnose brokenness.

3. In section 6, I think it is better to point to the actual IANA 
registry where the options will be documented, rather than the RFC that 
created the registry.

Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Last Call: (NeighborUnreachability Detection is too impatient) to Proposed Standard

The IESG — 2013-04-25T15:04:52

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Neighbor Unreachability Detection is too impatient'
  <draft-ietf-6man-impatient-nud-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf< at >ietf.org mailing lists by 2013-05-09. Exceptionally, comments may be
sent to iesg< at >ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.
   That function is very useful when a host has an alternative neighbor,
   for instance when there are multiple default routers, since it allows
   the host to switch to the alternative neighbor in short time.  This
   time is 3 seconds after the node starts probing by default.  However,
   if there are no alternative neighbors, this is far too impatient.
   This document specifies relaxed rules for Neighbor Discovery
   retransmissions that allow an implementation to choose different
   timeout behavior based on whether or not there are alternative
   neighbors.  This document updates RFC 4861.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/ballot/


No IPR declarations have been submitted directly on this I-D.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

LC comments on stable-privacy-addresses: Interface Index vs. name

Fernando Gont — 2013-04-25T14:01:16

Folks,

During IETF LC, a couple of folks noted that Interface Indexes might not
be stable.

I added some text on the subject to my working copy (mostly based on the
discussion with Brian Haberman and Mark Smith), but the issue came up
again (Tom Petch commented on the subject).

Since the raison d'etre for including the Interface Index in F() is to
differentiate between multiple interfaces connecting to the same
network, either the Interface Index or the Interface Name could be used.
So far, these are the pros/cons of each:

* Interface Index: Including this one would be ideal, since it's simply
a small number that identifies the interface, and does not really depend
on the NIC vendor, etc. However, as noted above, in some implementations
it might be unstable (i.e., vary when the system is bootstrapped).

* Interface name: This one has the pro that is stable, even on systems
in which the Interface Index is not. However, on some systems (e.g.
BSDs) the Interface name depends on the NIC vendor, which means that if
a NIC is replaced with another from a different vendor, the Interface
name is likely to change, and therefore the resulting address will change.


My take would be to replace "Interface Index" in the expression with an
abstract "Interface_ID", and then explain that "Interfae_ID" can be
either the Interface Index or the Interface name, and include some of
the text above (explaining why an implementation might want to include
one or the other -- i.e., if your Interface Indexes are stable, use
them. Else use the Interface name).

Thoughts?

Thanks!

I-D Action: draft-ietf-6man-addr-select-opt-09.txt

2013-04-25T08:32:31

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

Title           : Distributing Address Selection Policy using DHCPv6
Author(s)       : Arifumi Matsumoto
                          Tomohiro Fujisaki
                          Tim Chown
Filename        : draft-ietf-6man-addr-select-opt-09.txt
Pages           : 10
Date            : 2013-04-25

Abstract:
   RFC 6724 defines default address selection mechanisms for IPv6 that
   allow nodes to select an appropriate address when faced with multiple
   source and/or destination addresses to choose between.  The RFC 6724
   allowed for the future definition of methods to administratively
   configure the address selection policy information.  This document
   defines a new DHCPv6 option for such configuration, allowing a site
   administrator to distribute address selection policy overriding the
   default address selection parameters and policy table, and thus
   control the address selection behavior of nodes in their site.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

IPv4 mapped IPv6 addresses

S Moonesamy — 2013-04-23T21:59:58

Hello,

Section 5 of draft-ietf-spfbis-4408bis-14 has the following text:

   'When any mechanism fetches host addresses to compare with <ip>, when
    <ip> is an IPv4, "A" records are fetched; when <ip> is an IPv6
    address, "AAAA" records are fetched.  SPF implementations on IPv6
    servers need to handle both "AAAA" and "A" secords, for clients on
    IPv4 mapped IPv6 addresses [RFC4291].  IPv4 <ip> addresses are only
    listed in an SPF record using the "ip4" mechanism.'

Is the text about "IPv4 mapped IPv6 addresses" correct?

Regards,
S. Moonesamy (as document shepherd)

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

last call comments for draft-ietf-6man-stable-privacy-addresses-06

Eliot Lear — 2013-04-22T06:20:15

In the process of doing the apps area review, I came across some points
that were not related to applications.  The basis for these comments is
precisely the sentiment that Russ Housley expressed, which is that the
specification is done when there is no more to remove.  With this
document, I wonder if quite a bit could be removed.

Specifically, a great deal of discussion goes into the PRF involving DAD
counters, etc, when all that is needed is a suitable PRF.  The draft in
fact says this in Section 3 after an explanation of the inputs.  Any PRF
that follows the guidelines of RFC 4086 should do fine and not cause
interoperability OR security problems.  Put simply, you are
over-specifying the RID and derive no benefit from doing so.

Also, the following text in section 3 Page 7 is contorted:

      This means that this document does not formally obsolete or
      deprecate any of the existing algorithms to generate Interface IDs
      (e.g. such as that specified in [RFC2464]).  However, those IPv6
      implementations that employ this specification must generate all
      of their "stable" addresses as specified in this document.

My suggestion is to simplify remove it as it is self-evident.

Finally, this algorithm requires that the resultant host portion be 64
bits.  Is that necessary?

Eliot

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Protocol Action: 'Duplicate Address Detection Proxy' to ProposedStandard (draft-ietf-6man-dad-proxy-07.txt)

The IESG — 2013-04-12T16:13:24

The IESG has approved the following document:
- 'Duplicate Address Detection Proxy'
(draft-ietf-6man-dad-proxy-07.txt) as Proposed Standard

This document is the product of the IPv6 Maintenance Working Group.

The IESG contact persons are Brian Haberman and Ted Lemon.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/

Technical Summary

The document describes a proxy based mechanism allowing the use of
Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-
multipoint architecture with "split-horizon" forwarding scheme,
primarily deployed for Digital Subscriber Line (DSL) and Fiber access
architectures. Based on the DAD signalling, the first hop router
stores in a Binding Table all known IPv6 addresses used on a point-
to-multipoint domain (e.g. VLAN). When a node performs DAD for an
address already used by another node, the first hop router replies
instead of this last one.

Working Group Summary

The working group has reviewed and discussed this draft, feel it solves a relevant problem,
and supports it becoming a standard.

Document Quality

This document has been reviewed by many people and the chairs believe there is
agreement in the w.g. to move it forward.

Personnel

Bob Hinden is the Document Shepherd.
Brian Haberman is the Responsible Area Director.

RFC Editor Note

OLD:
When a node performs DAD for an address already used by another node, the first hop
router replies instead of this last one.

NEW:
When a node performs DAD for an address already used by another node, the first hop
router defends the address rather than the device using the address.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------