In message 20111206055756.gd20...@besserwisser.org, =?utf-8?B?TcOlbnM=?= Nils
son writes:
Subject: Re: class E (was: Consensus Call: draft-weil-shared-transition-s=
pace-request) Date: Tue, Dec 06, 2011 at 08:38:56AM +1100 Quoting Mark Andr=
ews (ma...@isc.org):
=20
Ask everyone everywhere
Greg Daley wrote:
I do not know if this is a current environment, or what you would like to see
(A reference would be good).
That is the current environment for home DSL subscribers (IPv4) in Germany.
One would use DHCPv6-PD to request the lease for a period,
Router Advertise it
Hi Mark,
Adding a address range as non-public to existing equipment is a lot
easier than adding IPv6 so that you can use DS-Lite. Much CPE
equipment doesn't have the flash capacity to do the later. The former
is trival provide the company that supplied the fireware is still in
business.
Hi Martin,
The assumption that information is present only within the IP address is
erroneous.
This has been studied for mobile IPv6 users as well, and there is information
leakage up and down the stack.
We have local source address selection mechanisms in recent Windows versions
that use
Hi Martin,
-Original Message-
From: Martin Rex [mailto:m...@sap.com]
Sent: Tuesday, 6 December 2011 1:30 PM
To: Greg Daley
Cc: m...@sap.com; mail-dated-1325290081.a3a4e0@sabahattin-
gucukoglu.com; ietf@ietf.org
Subject: Re: Netfilter (Linux) Does IPv6 NAT
Greg Daley wrote:
Dear Martin,
I think you're confused. Whatever IPv6 source address is in the
outgoing packet from the CPE is bound 1:1 to the subscriber. You
can't
conceal the address of the subscriber, if you ever want to get any
packets back.
The outgoing packet is bound 1:1 to the ISP of the
Mark,
On 12/5/11 10:38 PM, Mark Andrews wrote:
It's not that the CPE's can't renumber. The ISP are already using RFC
1918, in good faith, internally to talk to the management interfaces
of modems so using RFC 1918 is forcing the ISP's to renumber out of
whichever RFC 1918 block that is
On 12/05/2011 18:11, Greg Daley wrote:
The assumption that information is present only within the IP address is
erroneous.
This has been studied for mobile IPv6 users as well, and there is information
leakage up and down the stack.
We have local source address selection mechanisms in
On 2011-12-06 18:14, Mark Andrews wrote:
...
The so-called IPv6 privacy addresses are terminology fud.
No, there is no fear, uncertainty or doubt involved. If you don't want
to be traceable by your MAC address, use privacy addresses. That will
even conceal from parents which child is
Martin,
Renumbering the internal network would be completely silly.
You certainly do not want any interruptions of the local network traffic
just because you frequently change the address on the external interface for
privacy reasons.
This is why ULAs are useful. People just need to get used
Brian, I'd like to join this from another angle.
What exactly does changing your v4 address get you in terms of privacy?
It's my understanding that protocols including TCP, HTTP, TLS, and very
much the web platform are fairly easily linked.
That is, it's relatively easy to determine with
Brian E Carpenter wrote:
Renumbering the internal network would be completely silly.
You certainly do not want any interruptions of the local network traffic
just because you frequently change the address on the external interface for
privacy reasons.
This is why ULAs are useful.
In message 4ede4884.1030...@cisco.com, Eliot Lear writes:
Mark,
On 12/5/11 10:38 PM, Mark Andrews wrote:
It's not that the CPE's can't renumber. The ISP are already using RFC
1918, in good faith, internally to talk to the management interfaces
of modems so using RFC 1918 is forcing the
On 12/5/11 7:47 PM, Doug Barton do...@dougbarton.us wrote:
On 12/04/2011 19:10, Chris Donley wrote:
More seriously, the impression I've gathered from various discussions
is that the 90/10 model is viable, but it's not the first choice
because the 10 part involves customer service work that
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Doug Barton
Thank you for confirming publicly that the issue here is not a
technical
one, but rather that the ISPs would prefer not to bear the costs of
dealing with the problem that they
The IESG has received a second willing nominee for the IAOC position. Tobias
Gondrom would like to serve the community as an IAOC member. Please send
comments on Tobias to i...@ietf.org.
Additional nominations are welcome until 7 December 2011.
On behalf of the IESG,
Russ Housley
IESG
On Dec 5, 2011, at 4:58 PM, David Conrad wrote:
On Dec 5, 2011, at 1:13 PM, John C Klensin wrote:
this is a much stronger argument for a dear customer, either renumber or
upgrade your
hardware position
I'd imagine the vast majority of the customers of ISPs who are facing this
issue
On 03/12/2011, at 10:41 PM, t.petch wrote:
Rather, I would insert
'reserved and unreserved are formally defined in section 1.5 using the same
definitions as appear in [RFC3986]'
after the first paragraph of 1.2.
In SVN.
Cheers,
--
Mark Nottingham http://www.mnot.net/
Hi, Ron.
On Dec 3, 2011, at 4:06 PM, Ronald Bonica wrote:
On Thursday, December 1, the IESG deferred its decision regarding
draft-weil-shared-transition-space-request to the December 15 telechat.
I support the assignment of an IPv4 /10 for shared CGN space. Most of my
thoughts on this topic
On Tue, Dec 06, 2011 at 06:52:41AM -0800, the IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP Resource
Records'
draft-os-ietf-sshfp-ecdsa-sha2-04.txt as a Proposed
Subject: Re: class E (was: Consensus Call:
draft-weil-shared-transition-space-request) Date: Wed, Dec 07, 2011 at
12:19:49AM +1100 Quoting Mark Andrews (ma...@isc.org):
In message 20111206055756.gd20...@besserwisser.org, =?utf-8?B?TcOlbnM=?=
Nils
son writes:
Subject: Re: class E (was:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP Resource
Records'
draft-os-ietf-sshfp-ecdsa-sha2-04.txt as a Proposed Standard
The IESG plans to make a decision in the next few
The IESG has approved the following document:
- 'Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension'
(draft-ietf-tls-dtls-heartbeat-04.txt) as a Proposed Standard
This document is the product of the Transport Layer Security Working
Group.
The
The IESG has received a request from the SIP Common Log Format WG
(sipclf) to consider the following document:
- 'The Common Log Format (CLF) for the Session Initiation Protocol (SIP):
Framework and Data Model'
draft-ietf-sipclf-problem-statement-09.txt as an Informational RFC
The IESG
The IESG has received a second willing nominee for the IAOC position. Tobias
Gondrom would like to serve the community as an IAOC member. Please send
comments on Tobias to i...@ietf.org.
Additional nominations are welcome until 7 December 2011.
On behalf of the IESG,
Russ Housley
IESG
25 matches
Mail list logo
