Considering the no. Of users at every second it will not be possible to achieve direct privacy addressing system, for me IETF shld design a system which will enhance DMZ network connection detection and monitoring system. Amenawon Osa Peter Sent from my BlackBerry wireless device from SapenaNET -----Original Message----- From: ietf-request@xxxxxxxx Sender: ietf-bounces@xxxxxxxx Date: Sat, 02 Jul 2011 12:00:04 To: <ietf@xxxxxxxx> Reply-To: ietf@xxxxxxxx Subject: Ietf Digest, Vol 38, Issue 6 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ietf Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Ietf mailing list submissions to ietf@xxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ietf or, via email, send a message with subject or body 'help' to ietf-request@xxxxxxxx You can reach the person managing the list at ietf-owner@xxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of Ietf digest..." Today's Topics: 1. Re: HOMENET working group proposal (Masataka Ohta) 2. Re: HOMENET working group proposal (Keith Moore) 3. draft-ietf-v6ops-6to4-to-historic (Ronald Bonica) ---------------------------------------------------------------------- Message: 1 Date: Sat, 02 Jul 2011 16:20:33 +0900 From: Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> To: ietf@xxxxxxxx Subject: Re: HOMENET working group proposal Message-ID: <4E0EC6C1.2000304@xxxxxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=ISO-2022-JP Martin Rex wrote: > This means you want to make IPv6 addresses > and all communications with that address direct personally > identifiable information, something for which a "must informed > beforehand", let alone an "opt opt" is technically impossible? If what you want is "opt out" from static IP addresses, use proxies at an application layer or IP over IP at the network layer. Masataka Ohta ------------------------------ Message: 2 Date: Sat, 2 Jul 2011 10:52:08 -0400 From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> To: Scott Brim <scott.brim@xxxxxxxxx> Cc: ietf@xxxxxxxx Subject: Re: HOMENET working group proposal Message-ID: <1B0E6A5D-0BF1-400B-A063-D59D8ED2C766@xxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=us-ascii On Jul 1, 2011, at 2:55 PM, Scott Brim wrote: >> >> The IETF has several times veered away from the deep water where internet standards cross paths with regulatory requirements. >> >> http://tools.ietf.org/html/rfc2804 >> >> We are not legal experts we are not qualified to interpret the statutory requirements of various nation states, our own or others. We need to be clear on what is in vs out of scope for IETF work. Focus on what would be percieved to be in the best interests the users and the network. Nation states will do whatever they do and sovereign by definition can impose whatever mandate they find necessary on their network operations and citizens. > > Joel, the issue is very clear: what the IETF does must not make > privacy and confidentiality impossible. It's not just some arbitrary > regulation from a committee, there are whole cultures who take this > very seriously. You cite the wiretapping decision -- note we didn't > make wiretapping impossible, we just didn't support it. In this case > it is very easy to make privacy (the right to control personal > information) and confidentiality (the right to know that private > information you share with one party will be kept within that scope) > impossible -- that's a position you may not take as someone making the > Internet work, since the ultimate stakeholders are those humans out at > the edges. See also "Changes to Internet Architecture Can Collide > With Privacy" <http://www.ietf.org/proceedings/79/slides/intarea-3.pdf> > for a discussion of mobility. > > When you think "oh right, I have to come up with a security > considerations section", include privacy and confidentiality > implications in your checklist of things to think about. Very much agree. I strongly disagree with the statement that every home network should have only ephemeral external addresses and that it should NAT to stable internal addresses. I also strongly disagree with the assertion that EU law requires IETF to make it so. But the underlying concerns are quite valid and important. I don't want to cripple all home networks and applications by imposing ephemeral addresses and/or NATs on them. But having a stable address prefix associated with every device in one's home network that communicates with the public Internet can indeed threaten the user's privacy. (Note that privacy addresses don't really solve the problem as they still all have the same prefix.) Some applications and hosts require stable addresses; others do not. So it might be that a home network needs to be able to support two prefixes - a stable one that can be used by those applications that need it, and an ephemeral one that can be used by everything else. That's not difficult to do by itself, but my next question is how to arrange these things such that ordinary consumers can understand such details and manage them? Anyway, to me it seems reasonable for the HOMENET group to consider privacy issues associated with address assignment. > As to the technical issues here, higher layers don't need to use IP > addresses as identifiers, they have their own. The only layer that > needs to care about IP addresses is the IP layer itself. This has been demonstrated many times to be false. Keith ------------------------------ Message: 3 Date: Sat, 2 Jul 2011 12:36:05 -0400 From: Ronald Bonica <rbonica@xxxxxxxxxxx> To: "v6ops@xxxxxxxx" <v6ops@xxxxxxxx>, IETF Discussion <ietf@xxxxxxxx> Subject: draft-ietf-v6ops-6to4-to-historic Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@xxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron <Speaking as OPS Area AD> ------------------------------ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf End of Ietf Digest, Vol 38, Issue 6 *********************************** _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf