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.
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
Sh
On 05/24/2013 08:17 AM, Hosnieh Rafiee 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.
I work primarily with customers who implement networks inside their own
borders. Ray is
It also now occurs to me that since RFC 3972 has IPR disclosures from both
Microsoft and Ericsson, those disclosures may or may not apply to
draft-ietf-6man-stable-privacy-addresses as well.
Per the Note Well, I'm at least sending this email, but will check with
Microsoft folks to see whether an
[...]
> 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 options?).
[..]
No, the Windows firewall doesn't allow any ICMP responses to unsolicited
traffic,
they're all dropped. This is what is sometimes
On 25/05/2013 10:04, Dave Thaler wrote:
> Thanks Alissa for the nice table, this is very helpful.
Agreed. Two points though:
1. It seems to me that location tracking to the level of the 64-bit
prefix is *always* possible, which may well identify a specific
customer and/or physical location, but n
I'd also like to see CGAs (3972) added to this analysis. It seems to me they're
the existing standards-track "random-per-network" addresses. So all of the
"random-per-network" statements would seem apply equally to the existing RFC.
This draft references that RFC but does not contain any discuss
> correlation but their admins won't let them use temporary addresses,
> then random-per-network (row 3) provides some benefits over random (row 2).
So is the goal of the draft to give a new way for network administrators to
decrease privacy of users? If yes, then if this goal was removed, would
Thanks Alissa for the nice table, this is very helpful.
> -Original Message-
> From: Alissa Cooper [mailto:acoo...@cdt.org]
> Sent: Friday, May 24, 2013 2:34 PM
> To: Fernando Gont
> Cc: Dave Thaler; 6...@ietf.org; 6man-cha...@tools.ietf.org; Brian
> Haberman; Ray Hunter; tom.petch; Christ
On 25/05/2013 00:40, John Leslie wrote:
> Ray Hunter 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 (
Michael,
>> Can we move from the process discussion to the technical discussion?
>>
>> Michael raised an interesting issue, and we have to analyze it. The
>> consensus of the working group so far is that interface identifiers are
>> private to the host, that any leakage outside the host should
Kerry,
On 2013-05-24, at 3:44 PM, Kerry Lynn wrote:
> ...
> scheme://[v1.fe80:::...:+zoneid]:port/path
>
> So it appears the current 'host' production used by print drivers is not
> currently specified
> by any RFC; why not just continue to use the same format irrespective of RFC
>
On Fri, May 24, 2013 at 3:27 PM, Michael Sweet wrote:
> Kerry,
>
> On 2013-05-24, at 2:51 PM, Kerry Lynn wrote:
>
> ...
>
> Just so we're clear, I assume this does NOT work today with link-local
> IPv6 addresses (because no print client yet
> constructs a Host URI with link-local address and zon
Kerry,
On 2013-05-24, at 2:51 PM, Kerry Lynn wrote:
> ...
> Just so we're clear, I assume this does NOT work today with link-local IPv6
> addresses (because no print client yet
> constructs a Host URI with link-local address and zoneID according to RFC
> 6874)? And you're saying that RFC 6874
Christian,
On 2013-05-24, at 2:41 PM, Christian Huitema wrote:
> ...
>> All of this falls apart with link-local addresses and RFC 6874. Because the
>> client is required to remove the zoneid from the outgoing request, the URIs
>> it gets back from the server are no longer "reachable".
>
> Do
On Fri, May 24, 2013 at 2:27 PM, Michael Sweet wrote:
> Christian,
>
> On 2013-05-24, at 1:45 PM, Christian Huitema
> wrote:
> > Can we move from the process discussion to the technical discussion?
> >
> > Michael raised an interesting issue, and we have to analyze it. The
> consensus of the wor
> Some background: HTTP and IPP services in printers include absolute URIs in
> the content they return. For IPP this can be http/https URLs to the printer's
> web page, ICC profiles, and other resources, along with the ipp/ipps URIs
> that the printer supports. For HTTP the most common are http
Christian,
On 2013-05-24, at 1:45 PM, Christian Huitema wrote:
> Can we move from the process discussion to the technical discussion?
>
> Michael raised an interesting issue, and we have to analyze it. The consensus
> of the working group so far is that interface identifiers are private to the
Michael,
Can I echo what Tom and Christian have said - that you join the 6man working
group and start by clearly and concisely stating the problem that this RFC
poses
for your application and how you suggest we fix it?
When you speak of "hundreds of millions of printers..." it gives the
impressio
Can we move from the process discussion to the technical discussion?
Michael raised an interesting issue, and we have to analyze it. The consensus
of the working group so far is that interface identifiers are private to the
host, that any leakage outside the host should be prevented, and that a
Hosnieh Rafiee 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 i
Comments in-line...
On 24 May 2013, at 16:17, Hosnieh Rafiee 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 stor
Original Message -
From: "Michael Sweet"
To: "t.petch"
Cc: "Christian Huitema" ;
Sent: Friday, May 24, 2013 1:10 PM
> Tom,
>
> On 2013-05-24, at 4:00 AM, t.petch wrote:
> > Michael
> >
> > I would have been happy to see your erratum rejected in 24 minutes,
> > because it is an abuse of
> >
> I have read this draft and I don't particularly like it for several
operational
> reasons.
>
> 1) Use of purely random unpredictable IIDs appears to impose an ISP model
of
> working where there is no trust relationship between the end node and the
> network infrastructure.
>
> In corporate
Fernando
Looks good.
One more technical point, in a raft of lesser ones.
s1
/network, an infer which addresses/network, and infer which addresses/
/(since the follow different patterns from that of traditional SLAAC
addresses),/
(since they follow different patterns from those of traditional S
On 24 May 2013, at 13:40, John Leslie wrote:
> Ray Hunter 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 p
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
Hi Tim,
>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?
I do not want to open up the old discussion here again. If you use RFC 4941
or in other word you enable
Hi,
In-line...
On 24 May 2013, at 02:00, Fernando Gont 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
Ray Hunter 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 experime
> > 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
> > ma
Tom,
On 2013-05-24, at 4:00 AM, t.petch wrote:
> Michael
>
> I would have been happy to see your erratum rejected in 24 minutes,
> because it is an abuse of process. It's a bit like submitting an I-D in
> Swahili, nothing wrong with Swahili but quite wrong for the context.
>
> Erratum are for
On 24 May 2013, at 10:31, Fernando Gont 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
On 23 May 2013, at 18:36, Ray Hunter 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 n
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 perso
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. Y
Michael
I would have been happy to see your erratum rejected in 24 minutes,
because it is an abuse of process. It's a bit like submitting an I-D in
Swahili, nothing wrong with Swahili but quite wrong for the context.
Erratum are for errors, where the text did not mean what the WG had
agreed on,
37 matches
Mail list logo
