Subject: Re: Ietf Digest, Vol 38, Issue 6

From: [email-masked]
Date: Sat, 2 Jul 2011 19:15:55 +0000

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: [email-masked]
Sender: [email-masked]
Date: Sat, 02 Jul 2011 12:00:04 
To: <[email-masked]>
Reply-To: [email-masked]
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
	[email-masked]

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

You can reach the person managing the list at
	[email-masked]

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 <[email-masked]>
To: [email-masked]
Subject: Re: HOMENET working group proposal
Message-ID: <[email-masked]>
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 <[email-masked]>
To: Scott Brim <[email-masked]>
Cc: [email-masked]
Subject: Re: HOMENET working group proposal
Message-ID:
	<[email-masked]>
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 <[email-masked]>
To: "[email-masked]" <[email-masked]>, IETF Discussion <[email-masked]>
Subject: draft-ietf-v6ops-6to4-to-historic
Message-ID:
	<[email-masked]>
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

End of Ietf Digest, Vol 38, Issue 6
***********************************