headers
Ralph Droms (rdroms | 25 May 2013 15:59
Picon
Favicon

Fwd: New Version Notification for draft-droms-6man-multicast-scopes-00.txt

This draft proposes to redefine IPv6 multicast scope 0x03 from "reserved" to "Network-Specific scope,
greater than Link-Local scope, defined automatically from the network topology".  The expectation is
that mesh trickle multicast, as defined in draft-ietf-roll-trickle-mcast, will define multicast
scope 0x03 as "all interfaces attached to links in the mesh", for use in multicast delivery.

I've requested a slot on the 6man agenda in Berlin to discuss the draft.

- Ralph

Begin forwarded message:

> From: <internet-drafts <at> ietf.org>
> Subject: New Version Notification for draft-droms-6man-multicast-scopes-00.txt
> Date: May 22, 2013 3:15:22 PM EDT
> To: Ralph Droms <rdroms <at> cisco.com>
> 
> 
> A new version of I-D, draft-droms-6man-multicast-scopes-00.txt
> has been successfully submitted by Ralph Droms and posted to the
> IETF repository.
> 
> Filename:	 draft-droms-6man-multicast-scopes
> Revision:	 00
> Title:		 IPv6 Multicast Address Scopes
> Creation date:	 2013-05-22
> Group:		 Individual Submission
> Number of pages: 3
> URL:             http://www.ietf.org/internet-drafts/draft-droms-6man-multicast-scopes-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-droms-6man-multicast-scopes
> Htmlized:        http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-00
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 25 May 2013 06:30
Picon

[Fwd: I-D Action: draft-ietf-6man-ug-01.txt]

Hi,

This version is intended to respond to WG comments. In particular:

- the title, Abstract and text have been modified to clarify
  the nature of the entire IID, not just the U/G bits;

- there is additional text about DAD failures;

- expanded IANA considerations.

Please read and comment.

   Brian + Sheng

-------- Original Message --------
Subject: I-D Action: draft-ietf-6man-ug-01.txt
Date: Fri, 24 May 2013 21:23:55 -0700
From: internet-drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org
CC: ipv6 <at> ietf.org

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           : Significance of IPv6 Interface Identifiers
	Author(s)       : Brian Carpenter
                          Sheng Jiang
	Filename        : draft-ietf-6man-ug-01.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Chown | 24 May 2013 18:07
Picon
Favicon

Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy

Comments in-line...

On 24 May 2013, at 16:17, Hosnieh Rafiee <ietf <at> rozanak.com> wrote:
> 
> I just wonder why, when you can use a monitoring system to log all your
> events (MAC + IP) when you are inside a corporate network, you see this as a
> big issue. You can also rotate your logs so that a large amount of storage
> is not necessary. Why would you sacrifice your user's privacy over a
> logging issue? If you really have no concern about  user privacy,  then that
> become another decision and you can use public IP addresses, that are not
> generated based on MAC addresses, and use them for an unlimited time which
> is explained in the draft. You can use either this draft or any other
> approach.

At our site we do just this; an SNMP-based tool harvests IP/MAC/port data from the switches,routers etc.  I
agree that it works very well.

That said, I expect quite a few (enterprise) sites will try to disable 4941. Or if they use ULAs as well, to
disable for ULAs for internal traffic. That's their choice. 

The question is just what additional privacy you're delivering. In principle, 4941 addresses could be put
in the DNS, or could be passed to peers to use for communications. Conceptually, it may be simpler to have
just two classes of address; stable privacy addresses (as per Fernando's text) and "temporary" privacy
addresses which change over time (RFC 4941), whether the addresses are used to initiate or receive connections.

My current feeling is that we have Fernando's stable privacy draft that's getting quite close to being done
(I hope :) and we of course have 4941.  I would personally prefer to see Fernando's text published, and then -
if you feel it necessary - you could issue a proposal for any additional functionality you believe is
needed beyond that, or for perceived fixes to 4941. You may have valid points to make, e.g. regarding
requirements on dynamic DNS when using that, but it would be easier to assess them after the publication of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Chown | 24 May 2013 16:43
Picon
Favicon

Re: [Fwd: I-D Action: draft-ietf-6man-ext-transmit-00.txt]

On 24 May 2013, at 13:40, John Leslie <john <at> jlc.net> wrote:

> Ray Hunter <v6ops <at> globis.net> wrote:
>> 
>> I would also like to see some text on whether it is possible/desirable
>> for a middleware box to strip unknown headers, or even some known
>> headers, rather than making a binary decision to drop or transmit the
>> entire packet. If (new) headers are truly optional or experimental, the
>> residual stripped packet may still have value e.g. stripping hop by hop
>> extension headers on entry to/ egress from a corporate network or
>> transit AS. That way the (new) extension headers could be usefully
>> deployed in an AS that supports them, but the end to end traffic would
>> not be blocked further along the path by firewalls in an AS that does not.
> 
>   I had a similar thought -- even going so far as to posit a way to
> notate that a header had been stripped...

For that you need a new header... ;)

>   I think the answer is we don't want to do that in this document;
> nonetheless some folks are likely to try it. I think a mention of the
> issue, and a reference to RFC(s) stating the current rules, would help.
> 
>   (The prime purpose of this document is creating an IANA registry;
> that purpose should not be clouded by discussion of what firewalls
> "should" do.)

Yes, the doc should focus on its primary reason for existence. 

A couple of additional comments.
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 24 May 2013 16:04
Picon
Favicon

I-D Action: draft-ietf-6man-enhanced-dad-03.txt


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           : Enhanced Duplicate Address Detection
	Author(s)       : Rajiv Asati
                          Hemant Singh
                          Wes Beebee
                          Eli Dart
                          Wes George
                          Carlos Pignataro
	Filename        : draft-ietf-6man-enhanced-dad-03.txt
	Pages           : 12
	Date            : 2013-05-24

Abstract:
   Appendix A of the IPv6 Duplicate Address Detection (DAD) document in
   RFC 4862 discusses Loopback Suppression and DAD.  However, RFC 4862
   does not settle on one specific automated means to detect loopback of
   Neighbor Discovery (ND of RFC 4861) messages used by DAD.  Several
   service provider communities have expressed a need for automated
   detection of looped backed ND messages used by DAD.  This document
   includes mitigation techniques and then outlines the Enhanced DAD
   algorithm to automate detection of looped back IPv6 ND messages used
   by DAD.  For network loopback tests, the Enhanced DAD algorithm
   allows IPv6 to self-heal after a loopback is placed and removed.
   Further, for certain access networks the document automates resolving
   a specific duplicate address conflict.

The IETF datatracker status page for this draft is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Chown | 24 May 2013 15:22
Picon
Favicon

Re: Comments on draft-ietf-6man-stable-privacy-addresses-07

Hi,

In-line...

On 24 May 2013, at 02:00, Fernando Gont <fgont <at> si6networks.com> wrote:

> Hi, Tim,
> 
> Thanks so much for your feedback! -- Please find my comments in-line...
> 
> On 05/22/2013 10:19 AM, Tim Chown wrote:
>> 
>> Overall, I think this is good work and should be progressed.
> 
> Thanks!
> 
>> First, some general comments:
>> 
>> You may wish to be clearer earlier in the document (abstract and/or
>> introduction) that your method applies to all prefixes a host may
>> have, including link-local, ULA, and global(s).  As it stands, you
>> only, for example, mention link-locals first in Section 3.
> 
> Good point. I've tweaked the abstract, and have also clarified this
> point in Section 3.
> 
>> The implication of the above is that a multihomed host will have
>> different IIDs per ISP it receives a prefix from. This may have
>> privacy advantages in a static device scenario (this is implied, but
>> never stated anywhere that I can see).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Chown | 24 May 2013 13:45
Picon
Favicon

Re: Comments on draft-ietf-6man-stable-privacy-addresses-07

On 24 May 2013, at 10:31, Fernando Gont <fgont <at> si6networks.com> wrote:

> On 05/22/2013 03:34 AM, Dave Thaler wrote:
>>> I attend an IETF meeting, and learn the IID of your laptop. Then I can actively
>>> probe your node regarding "Is David at the office?" "Is David at home?",
>>> etc.... simply because your IID is known and constant.
>> 
>> Since you're making this personal... please explain how you can probe whether 
>> I'm at the office or at home, both of which are behind firewalls (so won't respond
>> to arbitrary probes) and have address prefixes you don't know to begin with.
> 
> As noted, this wasn't meant to be personal -- it was just meant to be an
> example.
> 
> Now, given the example under discussion:
> 
> I could learn your IID when we both attend the IETF meeting. And I could
> learn your prefixes when you post to mailing-lists from such places.
> Then I could use Prefix|IID to track you.

Or you can sometimes get the user's IID in their home network via email headers, e.g.

Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::22]) by
gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OBbV6x027652 (version=TLSv1/SSLv3 ...

Well, that's not a great example, but that information is available to anyone on a mail list you post to,
though not usually in web archives of the same list.

> The fact that you use a firewall is mostly irrelevant. I'd bet your
> firewall still reponds to some packets (e.g., packets with unsupported
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Chown | 24 May 2013 13:36
Picon
Favicon

Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy


On 23 May 2013, at 18:36, Ray Hunter <v6ops <at> globis.net> wrote:
> 
> In corporate environments it is very important that cross-correlation of
> log events can occur to support various operational processes (also over
> longer periods of time and for examining historical records). IPv4 did
> not randomly rotate end node identifiers in an uncorrelated manner, and
> the consequences of this new behaviour could be far reaching.

Well, I think the jury is out on use of 4941 in enterprise environments. There are advantages and
disadvantages. Accountability is still manageable.

But in general I agree with Ray's points.

Tim

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Tim Chown | 24 May 2013 13:33
Picon
Favicon

Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy

Hi,

Can you clarify, succinctly, what your proposal adds that you cannot achieve by a combination of http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ and RFC4941?

It seems a key point is that 4941 "only" says SHOULD for the IID regeneration when the prefix changes.  Yet afaics all implementations do this?

Tim

On 23 May 2013, at 16:04, "Hosnieh Rafiee" <ietf <at> rozanak.com> wrote:

Follow up,

 
I forgot to post the link to the draft :-)

 
Thanks,

Best,

Hosnieh

 
 

 

I first want to thank Dave who took the time to read and comment on my draft and to discuss the problems associated with it. Based on some offline discussions with Dave, I have changed this document to better address the current issues with RFC 4941 which are actually related to differences in interpretation of the wording used in the that document. In many cases the wording used gives implementations the choice of how best to accomplish the goal which can lead to bad choices being made which negates the purpose of the document. This draft is thus an update to the Privacy Extension document and also, because it does not allow a node to generate and use an IID based on a MAC address, an update to one section of RFC 4862 which pertains to this.

 

In this document an approach is recommend that doesn't make use MAC addresses in the generation of public addresses. It does, in fact, endorse the use other approaches that aren't based on the use of MAC addresses in the generation of public addresses. Public addresses can be valid forever but it is recommended that, for privacy purposes, a node not make use of public addresses.

The definition of public addresses here is the same as what Dave explained in his last responses to the people on this list, i.e., the addresses that need to have DNS records. In my opinion, these addresses are more useful for servers than other nodes.

 

I appreciate your support and any and all comments that you might proffer.

 

Thank you,

Best,

Hosnieh

 

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
internet-drafts | 24 May 2013 03:01
Picon
Favicon

I-D Action: draft-ietf-6man-stable-privacy-addresses-08.txt


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           : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address
Autoconfiguration (SLAAC)
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-6man-stable-privacy-addresses-08.txt
	Pages           : 26
	Date            : 2013-05-23

Abstract:
   This document specifies a method for generating IPv6 Interface
   Identifiers to be used with IPv6 Stateless Address Autoconfiguration
   (SLAAC), such that addresses configured using this method are stable
   within each subnet, but the Interface Identifier changes when hosts
   move from one network to another.  This method is meant to be an
   alternative to generating Interface Identifiers based on hardware
   address (e.g., using IEEE identifiers), such that the benefits of
   stable addresses can be achieved without sacrificing the privacy of
   users.  The method specified in this document applies to all prefixes
   a host may be employing, including link-local, global, and unique-
   local addresses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-08

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
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Hosnieh Rafiee | 23 May 2013 16:53

Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy

I first want to thank Dave who took the time to read and comment on my draft and to discuss the problems associated with it. Based on some offline discussions with Dave, I have changed this document to better address the current issues with RFC 4941 which are actually related to differences in interpretation of the wording used in the that document. In many cases the wording used gives implementations the choice of how best to accomplish the goal which can lead to bad choices being made which negates the purpose of the document. This draft is thus an update to the Privacy Extension document and also, because it does not allow a node to generate and use an IID based on a MAC address, an update to one section of RFC 4862 which pertains to this.

 

In this document an approach is recommend that doesn't make use MAC addresses in the generation of public addresses. It does, in fact, endorse the use other approaches that aren't based on the use of MAC addresses in the generation of public addresses. Public addresses can be valid forever but it is recommended that, for privacy purposes, a node not make use of public addresses.

The definition of public addresses here is the same as what Dave explained in his last responses to the people on this list, i.e., the addresses that need to have DNS records. In my opinion, these addresses are more useful for servers than other nodes.

 

I appreciate your support and any and all comments that you might proffer.

 

Thank you,

Best,

Hosnieh

 

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

Gmane