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(_at_)ietf(_dot_)org
Sender: ietf-bounces(_at_)ietf(_dot_)org
Date: Sat, 02 Jul 2011 12:00:04
To: <ietf(_at_)ietf(_dot_)org>
Reply-To: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
You can reach the person managing the list at
ietf-owner(_at_)ietf(_dot_)org
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(_at_)necom830(_dot_)hpcl(_dot_)titech(_dot_)ac(_dot_)jp>
To: ietf(_at_)ietf(_dot_)org
Subject: Re: HOMENET working group proposal
Message-ID:
<4E0EC6C1(_dot_)2000304(_at_)necom830(_dot_)hpcl(_dot_)titech(_dot_)ac(_dot_)jp>
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(_at_)network-heretics(_dot_)com>
To: Scott Brim <scott(_dot_)brim(_at_)gmail(_dot_)com>
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: HOMENET working group proposal
Message-ID:
<1B0E6A5D-0BF1-400B-A063-D59D8ED2C766(_at_)network-heretics(_dot_)com>
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(_at_)juniper(_dot_)net>
To: "v6ops(_at_)ietf(_dot_)org" <v6ops(_at_)ietf(_dot_)org>, IETF Discussion
<ietf(_at_)ietf(_dot_)org>
Subject: draft-ietf-v6ops-6to4-to-historic
Message-ID:
<13205C286662DE4387D9AF3AC30EF456D3F3507EDA(_at_)EMBX01-WF(_dot_)jnpr(_dot_)net>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
End of Ietf Digest, Vol 38, Issue 6
***********************************
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf