date:20111205

Frank,

On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
 The last state I'm aware of is that the 240/4 addresses minus one
 were and still are (RFC 5735) reserved for IETF experiments, did I miss
 some newer IETF consensus about this?
...
 http://omniplex.blogspot.com/2008/06/lost-found-268435455-free-ips.html

Does it actually matter?  What RFCs say (or don't say) about 240/4 means 
precisely nothing to the deployed, non-field-upgradable CPE that I understand 
is driving the interest draft-weil.

Regard,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Consensus Call: draft-weil-shared-transition-space-request

2011-12-05 Thread George, Wes

From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cameron 
Byrne

 The ietf did act. It is called ipv6.

[WEG] sarcasm thanks for that wonderfully relevant and technical rebuttal. 
I'm so glad we've stopped debating philosophy and religion in this thread and 
gotten down to solving technical problems. I'll be sure to tell all of my 
customers (and my shareholders, for that matter) that when they call to ask why 
their new internet-enabled TV, Xbox Live/PSN, Skype, etc doesn't work on my 
IETF-approved (IPv6-only) Internet service. /sarcasm

I don't know how much clearer I can make this, so I'll keep repeating it until 
it hopefully sinks in:
Independent of whether we have any left, continued support for IPv4 in the home 
and enterprise is *non-negotiable*, no matter how many people stand atop the 
IETF soapbox and decree that it MUST be otherwise because IPv6 exists. I would 
also like it to be different, but there are a *lot* of stars that have to align 
before it actually is, most of which are not in my control. It's 
extraordinarily unproductive to vilify a group of operators as the singular 
scapegoat for IPv6's failure to generate critical mass when all they're trying 
to do is keep their network running and their customers happy, especially since 
they're simultaneously deploying IPv6, not using CGN to avoid it as folks on 
this list seem so quick to assume. If you have a way to convince my customers 
(or anyone else's) that they don't need IPv4 anymore, be my guest.

Until then, let's stick to solutions to the actual problem, shall we? Saying 
that IPv6 is a solution to an IPv4 CGN implementation problem is like saying 
that a railroad car is a perfectly acceptable alternative to renting a truck to 
move the contents of my house across town without considering whether both my 
source and destination are in reasonable proximity to the railroad tracks. Or 
worse yet, saying that I shouldn't be moving house in the first place because 
trucks are scarce and less efficient than rail cars.


 And, they underscored that point by rejecting various past attempts at 
 expanding private ipv4 space like 240/4.

 [WEG] Every argument I've ever heard regarding 240/4 was related to the 
difficulty of ensuring that it was going to work *everywhere* just like the 
rest of the currently allocated IPv4 space. It's similar to the problems 
associated with going to CIDR, but the installed base is much, much larger. The 
concern was that most, if not all router and host stacks would have to be 
updated to make it work. Even if it was only commenting out a few lines of 
code, that was viewed as a virtual impossibility, making it impractical to 
consider releasing the space for general use. I'm disappointed that the space 
wasn't simply released (even as additional private/experimental space) with the 
caveat that it may not work on old equipment, and then allow the market to 
decide how important it was to fix such equipment, even if just for specific 
use cases rather than globally routable space.
IPv6 figured into the discussion, but only as a follow-on to the above. That 
is, it makes far more sense to expend efforts to ensure good support for IPv6 
if we're proposing modifying the host stacks of lots of devices, as well as the 
idea that by the time we fixed 240/4, IPv6 would be well-deployed, and everyone 
would have their own personal 128 bit unicorn to ride, making this a case of 
too little too late. Depending on how far back in time you rewind, I think at 
least that latter point has been proven wrong repeatedly, and subsequent 
attempts to cut our losses and try to fix a previous poor assumption have been 
unsuccessful.
I think that when people look back on the IPv4 to IPv6 transition, 240/4 will 
be a great example of IETF's hubris and failure to use all of the tools 
available to them in the name of upholding some misguided sense of principles 
(no matter how noble they might be) or forcing people to do it our way because 
there's no way that we could be wrong. I would still support releasing 240/4, 
but I don't think that it's a solution for this problem.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

 From: Chris Donley c.don...@cablelabs.com

 Both draft-bdgks and RFC 6319 describe the problems with 240/4 - too
 many legacy devices won't support it. ... In addition, back-office
 systems would need to be able to use the same 240/4 space for network
 monitoring/maintenance, billing, lawful intercept, etc.

I hear you. However, after thinking about it for a while, I still think we
ought to include a chunk of 240/ space _as well as_ some 'general use' space
(be it a /10 of that, or whatever).

My reasoning for adding a chunk of 240/ is that anytime it is suggested that
we use 240/ for some infrastructure purpose (it's clearly not feasible for
general use - too many legacy hosts), we get the same 'well, most things
won't handle it' response. Well, ya gotta start somewhere! If we never take
the first steps to making it usable, we'll never be able to take the second,
will we? And this seems as good a place as any to start...

Yes, I know, to begin with, it will not be useful. But sooner or later some
vendor will make their boxes deal with it. And when they do, with the crunch
for address space being what it is, some customer will say 'Great! This
solves my horrible problem {X}. I'll buy your stuff.' And then others will
follow.

And then 240/ will be available for _other_ infrastructure applications.
Really, with the severe crunch that's happening, we really need to figure out
how to make it available - and this seems as good a path as any.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Consensus Call: draft-weil-shared-transition-space-request

 From: George, Wes wesley.geo...@twcable.com

 sarcasm thanks for that wonderfully relevant and technical rebuttal. 

Err, Ron asked us to stay off this (non-productive) point:

 From: Ronald Bonica rbon...@juniper.net
 Date: Sat, 3 Dec 2011 17:06:42 -0500

 By contrast, further discussion of the following topics would not help
 the IESG gauge consensus:
 - Does the assignment of the requested /10 enable or hinder the 
deployment of IPv6?
 - Is CGN a viable service model for IPv4?

So far I've been trying to be a good boy, and keep quiet about IPv6, so I
hope everyone else can also comply with his request.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread Cameron Byrne

On Mon, Dec 5, 2011 at 9:46 AM, Frank Ellermann
hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com wrote:
 On 5 December 2011 04:27, Cameron Byrne wrote:

  [they = the IETF]
 they underscored that point by not rejecting various past attempts at
 expanding private ipv4 space like 240/4.

 Sorry. S/not rejecting/rejecting/

 ACK.  The last state I'm aware of is that the 240/4 addresses minus one
 were and still are (RFC 5735) reserved for IETF experiments, did I miss
 some newer IETF consensus about this?

 -Frank

 http://omniplex.blogspot.com/2008/06/lost-found-268435455-free-ips.html

Hi,

The addresses, AFAIK, are still in a no mans land.

I went on a short-lived quest to make these addresses usable in 2008,
because in 2008, they were not usable and i needed addresses.
Meaning, Linux, FreeBSD, Windows would not accept these addresses in
configuration and Juniper and Cisco router would not only not accept
these addresses as part of their configuration, they would not route
the addresses in transit.  Some of this may have changed, but not
enough to make this a clear win.

I was told, by a large vendor of network gear, an IETF direction must
be made to define a purpose for these addresses, like:

http://tools.ietf.org/html/draft-wilson-class-e-02

http://tools.ietf.org/html/draft-fuller-240space-02

Both failed to gain support (i assume), and thus nothing happened.  My
assumption is these drafts were killed as IPv4 life support

RFC 5735 leaves the use of 240/4 undefined ... it could be used for
public, private, multicast, some future use we never thought of,
carrier pigeons ...

Thus, my feeling is that the IETF implicitly said no ipv4 life
support by expanding private addresses, the cost of ipv4 will go
higher and higher, we can all see it like a slow moving train wreck,
make your strategies wisely.  Making this allocation for draft-weil
is changing the rules, slowing the train wreck, going backwards of
previous guidance(IPv6 is the answer to IPv4 exhaust),  while at the
same time increasing the amount of of damage.


cb
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread Marshall Eubanks

On Mon, Dec 5, 2011 at 1:00 PM, David Conrad d...@virtualized.org wrote:
 Frank,

 On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
 The last state I'm aware of is that the 240/4 addresses minus one
 were and still are (RFC 5735) reserved for IETF experiments, did I miss
 some newer IETF consensus about this?
 ...
 http://omniplex.blogspot.com/2008/06/lost-found-268435455-free-ips.html

 Does it actually matter?  What RFCs say (or don't say) about 240/4 means 
 precisely nothing to the deployed, non-field-upgradable CPE that I understand 
 is driving the interest draft-weil.

That IMO is the rock that proposals to use Class E have floundered on.
There is a lot of gear out there that will not be able to
deal with any Class E internetworking protocol, little prospect that
that will be changed any time soon, and a general feeling that it is
unwise to spend limited resources changing this.

Regards
Marshall


Regards
Marshall



 Regard,
 -drc

 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call: draft-weil-shared-transition-space-request

Wes,

On Dec 5, 2011, at 10:02 AM, George, Wes wrote:
 Independent of whether we have any left, continued support for IPv4 in the 
 home and enterprise is *non-negotiable*,

True, however as I understand it, this isn't the issue.  IIUC, the problem 
isn't what happens in the home and enterprise, it is what happens on the WAN 
side of old non-upgradeable CPE when connected via CGNs.  

 Saying that IPv6 is a solution to an IPv4 CGN implementation problem is like 
 saying ...

I'm guessing part of the issue here is folks appear to be talking past each 
other.  It might be helpful to be explicit about what your view of the IPv4 
CGN implementation problem is. For example, IPv6 _could_ be a solution if both 
the CPE and the CGN supports IPv6 and a way to tunnel v4 through v6 (no idea if 
anyone does this).

Regards,
-drc


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread Bob Hinden

Marshall,

On Dec 5, 2011, at 10:21 AM, Marshall Eubanks wrote:

 On Mon, Dec 5, 2011 at 1:00 PM, David Conrad d...@virtualized.org wrote:
 Frank,
 
 On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
 The last state I'm aware of is that the 240/4 addresses minus one
 were and still are (RFC 5735) reserved for IETF experiments, did I miss
 some newer IETF consensus about this?
 ...
 http://omniplex.blogspot.com/2008/06/lost-found-268435455-free-ips.html
 
 Does it actually matter?  What RFCs say (or don't say) about 240/4 means 
 precisely nothing to the deployed, non-field-upgradable CPE that I 
 understand is driving the interest draft-weil.
 
 That IMO is the rock that proposals to use Class E have floundered on.
 There is a lot of gear out there that will not be able to
 deal with any Class E internetworking protocol, little prospect that
 that will be changed any time soon, and a general feeling that it is
 unwise to spend limited resources changing this.
 


While all of that is true to use the Class E space for general purpose usage, 
the current proposal for using it for the CGN is different.  As far as I can 
tell, it would only require the CPE router, CGN's, and routers between the CPE 
and CGN's to support it.  It would not require any support by the customer 
behind the CPE or the rest of the Internet.  That the reason why several people 
have suggested it.

I think it's reasonable for the ISPs who want to deploy this CGN gear to the 
deal with upgrading the CPE routers of their customers.   They get the 
benefit, they should incur the costs.  The proposal to use some of the 
remaining public IPv4 space for this, IMHO has everyone else incur the costs.

Bob


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

2011-12-05 Thread Chris Grundemann

On Sat, Dec 3, 2011 at 15:06, Ronald Bonica rbon...@juniper.net wrote:

 Several topic have become intertwined in the mailing list discussion, making 
 it difficult to gauge community consensus. Further discussion of the 
 following topics would help the IESG to gauge consensus:

 - Is the reserved /10 required for the deployment of CGN?

No, but it is the best option and it's allocation and use will lower
the pain inflicted by CGN on the Internet at large.

 - What is the effect of burning 4 million IPv4 addresses on the exhaustion of 
 IPv4?

The benefit of a shared space far outweighs one months worth of
addresses for one RIR. Plus, it is likely that the availability of a
shared CGN space will slow allocations enough to offset this one month
loss.

 - Can alternative /10s be used?

This has been stated many times already (and is contained in multiple
drafts), so I'll just leave a high-level summary of our other options
as a reminder:
 - RFC 1918 space WILL NOT be used by operators.
 - Globally unique space is a waste and has all the same problems as a
shared /10 with the added problem of lack of standardization.
 - Squat space has all the same issues as a shared CGN space plus the
lack of standardization plus add the complications of squatting.
 - 240 - All the same issues of a shared CGN space but add the
complications from an explicit/intentional lack of vendor support in
many of the devices in question.

 By contrast, further discussion of the following topics would not help the 
 IESG gauge consensus:
snip

Agreed. The bottom line here is that if we remove ourselves from the
religious/political debate and focus on operational realities - the
choice is not a hard one. The allocation of a shared CGN space is the
best thing we can do for the Internet, it's users, it's operators,
it's vendors, and for IPv6 deployment as well (which is actually
redundant).

Cheers,
~Chris


 --
 Ron Bonica
 vcard:       www.bonica.org/ron/ronbonica.vcf


 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

 From: Bob Hinden bob.hin...@gmail.com

 As far as I can tell, it would only require the CPE router, CGN's, and
 routers between the CPE and CGN's to support it. ... I think it's
 reasonable for the ISPs who want to deploy this CGN gear to the deal with
 upgrading the CPE routers of their customers.

The problem is that for a lot of ISPs, the CPE equipment is owned by the
customers, and comes from a zillion different vendors, and upgrading all of
them is just not feasible.

 The proposal to use some of the remaining public IPv4 space for this,
 IMHO has everyone else incur the costs.

Scenario I: The IETF defines a /10 for this use, to be shared by all ISPs.
Scenario II: The IETF refuses to define a /10 for this use, each ISP goes
out and asks for its own.

Scenario II is incurring less cost on 'everyone else'... how?


Which does lead me to something I've been wondering about, though.

Why don't the ISPs get together, outside the IETF (I so wanted to expand on
this thought, but I had better not), and have one of them - one which is in
an area with an RIR with the most available space - go their RIR and ask for
a /10 for their in-house CGN - and then publish the number and say 'hey,
everyone, here's a /10 that anyone can use for their CGN'? And then, _once
it's already allocated_, they could even publish an I-D/non-standard-track
RFC documenting it, and how to use it...

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E

2011-12-05 Thread Frank Ellermann

On 5 December 2011 19:00, David Conrad d...@virtualized.org wrote:

 [IETF and 240/4]
 Does it actually matter?

Dunno, I can't judge it.  But I'd be seriously disappointed if any
hard- or software on my side won't let me participate in any 240/4
experiments, for all possible definitions of experiment.

-Frank (found a plausible expansion of CPE :-)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread Bob Hinden

Noel,

On Dec 5, 2011, at 10:58 AM, Noel Chiappa wrote:

 From: Bob Hinden bob.hin...@gmail.com
 
 As far as I can tell, it would only require the CPE router, CGN's, and
 routers between the CPE and CGN's to support it. ... I think it's
 reasonable for the ISPs who want to deploy this CGN gear to the deal with
 upgrading the CPE routers of their customers.
 
 The problem is that for a lot of ISPs, the CPE equipment is owned by the
 customers, and comes from a zillion different vendors, and upgrading all of
 them is just not feasible.

Sure, for all forms of CPE currently deployed.  I assume that there aren't any 
CPE deployed behind CGN today.  That is, all CPE today work without CGN and any 
sort of special addresses, probably use public IPv4 space on the WAN/ISP side.  
So a CGN deployment is a new deployment and the ISPs choosing to do this could 
make sure that their customers CPE can support class E addresses, upgrade the 
CPE firmware, or send them new CPE.  

Bob


 
 The proposal to use some of the remaining public IPv4 space for this,
 IMHO has everyone else incur the costs.
 
 Scenario I: The IETF defines a /10 for this use, to be shared by all ISPs.
 Scenario II: The IETF refuses to define a /10 for this use, each ISP goes
   out and asks for its own.
 
 Scenario II is incurring less cost on 'everyone else'... how?
 
 
 Which does lead me to something I've been wondering about, though.
 
 Why don't the ISPs get together, outside the IETF (I so wanted to expand on
 this thought, but I had better not), and have one of them - one which is in
 an area with an RIR with the most available space - go their RIR and ask for
 a /10 for their in-house CGN - and then publish the number and say 'hey,
 everyone, here's a /10 that anyone can use for their CGN'? And then, _once
 it's already allocated_, they could even publish an I-D/non-standard-track
 RFC documenting it, and how to use it...
 
   Noel
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread Nick Hilliard

On 05/12/2011 18:58, Noel Chiappa wrote:
 Why don't the ISPs get together, outside the IETF (I so wanted to expand on
 this thought, but I had better not), and have one of them - one which is in
 an area with an RIR with the most available space - go their RIR and ask for
 a /10 for their in-house CGN - and then publish the number and say 'hey,
 everyone, here's a /10 that anyone can use for their CGN'? And then, _once
 it's already allocated_, they could even publish an I-D/non-standard-track
 RFC documenting it, and how to use it...

Given that we just saw a /16 sold for $12/ip, what makes you think that any
carrier would open up a /10 allocated to them for the good of humanity, at
a potential future asset loss of $50m?

This is why this sort of address space needs to be allocated by policy, not
by bequest.

Nick
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

Bob,

On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
 So a CGN deployment is a new deployment and the ISPs choosing to do this 
 could make sure that their customers CPE can support class E addresses, 
 upgrade the CPE firmware,

I think the ISPs are saying that there is a non-trivial base of deployed 
non-upgradable CPE out there now.

 or send them new CPE.  

This assumes either (a) the ISP is responsible for the CPE and/or (b) the ISP 
is willing to pay for this.  I'm guessing these assumptions aren't valid.  

Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

 From: Nick Hilliard n...@inex.ie

 Given that we just saw a /16 sold for $12/ip, what makes you think that
 any carrier would open up a /10 allocated to them for the good of
 humanity, at a potential future asset loss of $50m?

I hear you, but... if these things are worth so much, why are the RIR's just
giving them away? (Rhetorical question: I know the answer.)

I mean, it really drives me a bit batty that, under current rules, ISP's
I1...In can all go to their RIRs, and each be given a block of space for
free, to support future customers, and under those current rules, the RIRs
pretty much _have_ to give them the space, but... we have a hard time giving
those same ISPs _one_ block instead, to share.

Too bad the RIRs can't say 'OK we changed our policy, no more address blocks
for free - but if you ask for one for a _shared_ purpose, that we can do'.


 From: Bob Hinden bob.hin...@gmail.com

 I assume that there aren't any CPE deployed behind CGN today.

Well, I actually suspect there are - but other strategies are being used to
provide the address space for those CGNs (per-ISP 'public' space; 1918-space;
squatted space; etc, etc).

 a CGN deployment is a new deployment and the ISPs choosing to do this
 could make sure that their customers CPE can support class E addresses

I suspect that CGNs are not, by and large, targetted to entirely new
customers: if they were, it might work to say 'equipment you buy to connect
must meet standards A, B and C'. Rather, I suspect that as customer bases
grow, some ISPs don't have enough 'public' space to give one to each customer
any more, so they want to deploy CGN - and they need address space for the
chunk of fabric between the CGNs and the CPEs. In other words, its mostly
_existing_ customers who are about to be CGN'd.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-12-05 Thread Michael Richardson


 Pete == Pete Resnick presn...@qualcomm.com writes:
 For RFC 1918 space, the problem with picking it isn't so much
 that the ISP can't pick one that consumer NATs don't use - it's
 that they can't pick one that no Enterprise on a*different* ISP
 uses.  For example, assume my employer used 10.64.0.0/10 (they
 probably do somewhere), and connected to ISP-A.  I connect to
 ISP-B using a 3GPP laptop-card, and get the same 10.64.0.0/10
 address space.  I now cannot use a VPN to my employer, because of
 the resulting conflict in the routing table in my laptop.  But
 there's nothing I nor my*ISP-B* can do about this, because my
 employer has been using that address for a long time
 (legitimately) and is connected to*ISP-A*.

Pete Doesn't this same problem exist if I'm currently attached to a
Pete CPE NAT that provides me with a 10.64.0.0/10 address and my
Pete VPN uses the same space? Are you saying that VPN software does
Pete not already deal with this?

It's not an easily solved problem, particularly if the VPN software is
not provided by the creator of the TCP/IP stack.  Even when it is
solved, it's still a horrible hack.

Most NAT boxes are routers that twiddle addresses.  They are not double
stack application gateways.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-12-05 Thread Andrew Sullivan

On Mon, Dec 05, 2011 at 04:02:07PM -0500, Michael Richardson wrote:

 Even when it is solved, it's still a horrible hack.

At last!  The slogan for this discussion!

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC

2011-12-05 Thread Murray S. Kucherawy

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John 
 Levine
 Sent: Sunday, December 04, 2011 1:28 PM
 To: ietf@ietf.org
 Cc: dcroc...@bbiw.net
 Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized 
 Third-Party Signers) to Experimental RFC

 ADSP already dictates use of the From: domain.  ATPS is a modification
 to ADSP.  It doesn't change anything that DKIM reports, only the rule
 for deciding whether ADSP finds an Author Domain Signature.

ATPS can be applied without ADSP by a Verifier that cares about author domain 
signatures in its own way, so it's not a direct modification to ADSP.  But 
there is a section that discusses how they work in tandem.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread John C Klensin



--On Monday, December 05, 2011 11:54 -0800 David Conrad
d...@virtualized.org wrote:

 Bob,
 
 On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
 So a CGN deployment is a new deployment and the ISPs choosing
 to do this could make sure that their customers CPE can
 support class E addresses, upgrade the CPE firmware,
 
 I think the ISPs are saying that there is a non-trivial base
 of deployed non-upgradable CPE out there now.
 
 or send them new CPE.  
 
 This assumes either (a) the ISP is responsible for the CPE
 and/or (b) the ISP is willing to pay for this.  I'm guessing
 these assumptions aren't valid.  

Right.  But, unless there is CPE gear out there that is so
locked into a particular 1918 (or other) address range that it
can't use anything else internally (I haven't heard of such
equipment, but maybe it is out there), this is a much stronger
argument for a dear customer, either renumber or upgrade your
hardware position than for an allocation that will force that
renumber or upgrade position as soon as, e.g., ISPs merge or
discover a need for an extra layer or CGN.

   john





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

2011-12-05 Thread Roger Jørgensen

On Dec 5, 2011 7:48 PM, Chris Grundemann cgrundem...@gmail.com wrote:

 On Sat, Dec 3, 2011 at 15:06, Ronald Bonica rbon...@juniper.net wrote:
  By contrast, further discussion of the following topics would not help
the IESG gauge consensus:
 snip

 Agreed. The bottom line here is that if we remove ourselves from the
 religious/political debate and focus on operational realities - the
 choice is not a hard one. The allocation of a shared CGN space is the
 best thing we can do for the Internet, it's users, it's operators,
 it's vendors, and for IPv6 deployment as well (which is actually
 redundant).

No it might not be a hard choice, but that dont make it a good solution,
just a choice of the lesser evil.

Btw: If this allocation are made from any of the free available pools, not
rfc1918 or 240/4, then lets us also give out a /8 from somewhere in 240/4
and lets see if it really is so d*mn hard to use this space. That might add
some value for the future

--- Roger J ---
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread Chris Donley


On 12/5/11 2:13 PM, John C Klensin john-i...@jck.com wrote:



--On Monday, December 05, 2011 11:54 -0800 David Conrad
d...@virtualized.org wrote:

 Bob,
 
 On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
 So a CGN deployment is a new deployment and the ISPs choosing
 to do this could make sure that their customers CPE can
 support class E addresses, upgrade the CPE firmware,
 
 I think the ISPs are saying that there is a non-trivial base
 of deployed non-upgradable CPE out there now.
 
 or send them new CPE.
 
 This assumes either (a) the ISP is responsible for the CPE
 and/or (b) the ISP is willing to pay for this.  I'm guessing
 these assumptions aren't valid.

Right.  But, unless there is CPE gear out there that is so
locked into a particular 1918 (or other) address range that it
can't use anything else internally (I haven't heard of such
equipment, but maybe it is out there), this is a much stronger
argument for a dear customer, either renumber or upgrade your
hardware position than for an allocation that will force that
renumber or upgrade position as soon as, e.g., ISPs merge or
discover a need for an extra layer or CGN.

   john

On DOCSIS networks, there are typically two deployment scenarios:
A) subscriber plugs PC directly into the CM
B) subscriber provides a router, which connects to the CM

In both cases, the subscriber is responsible for the equipment.  Many
subscribers don't know what an IP address is, and don't care.  I'm trying
to imagine my parents receiving such a letter renumber your IP address
and/or buy a new PC or router.  Such a letter would probably cause anger
and confusion and an increased readiness to switch to the ISP across town
that's using squat space and doesn't require customers to call Geek Squad
or buy something else.

Chris




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)


In message 0780b9d75d1ce23f15b5a...@pst.jck.com, John C Klensin writes:
 --On Monday, December 05, 2011 11:54 -0800 David Conrad
 d...@virtualized.org wrote:
 
  Bob,
  
  On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
  So a CGN deployment is a new deployment and the ISPs choosing
  to do this could make sure that their customers CPE can
  support class E addresses, upgrade the CPE firmware,
  
  I think the ISPs are saying that there is a non-trivial base
  of deployed non-upgradable CPE out there now.
  
  or send them new CPE.  
  
  This assumes either (a) the ISP is responsible for the CPE
  and/or (b) the ISP is willing to pay for this.  I'm guessing
  these assumptions aren't valid.  
 
 Right.  But, unless there is CPE gear out there that is so
 locked into a particular 1918 (or other) address range that it
 can't use anything else internally (I haven't heard of such
 equipment, but maybe it is out there), this is a much stronger
 argument for a dear customer, either renumber or upgrade your
 hardware position than for an allocation that will force that
 renumber or upgrade position as soon as, e.g., ISPs merge or
 discover a need for an extra layer or CGN.
 
john

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 choosen for this
purpose.  Customers that are using RFC 1918 addresses, in good
faith, are being force to renumber because the IETF is changing the
rules retrospectively.  Using a RFC 1918 block for this purpose
will also force companies to stop using this block internally as
it will break routing over VPNs to addresses in this block.

Ask everyone everywhere that is using this block, in good faith,
for some purpose other than supporting addresses behind a CGN to
renumber out of this block of RFC 1918 addresss which is now being
re-purposed 16 years after it was allocated.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)


In message cb028331.30361%c.don...@cablelabs.com, Chris Donley writes:
 
 On 12/5/11 2:13 PM, John C Klensin john-i...@jck.com wrote:
 
 
 
 --On Monday, December 05, 2011 11:54 -0800 David Conrad
 d...@virtualized.org wrote:
 
  Bob,
  
  On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
  So a CGN deployment is a new deployment and the ISPs choosing
  to do this could make sure that their customers CPE can
  support class E addresses, upgrade the CPE firmware,
  
  I think the ISPs are saying that there is a non-trivial base
  of deployed non-upgradable CPE out there now.
  
  or send them new CPE.
  
  This assumes either (a) the ISP is responsible for the CPE
  and/or (b) the ISP is willing to pay for this.  I'm guessing
  these assumptions aren't valid.
 
 Right.  But, unless there is CPE gear out there that is so
 locked into a particular 1918 (or other) address range that it
 can't use anything else internally (I haven't heard of such
 equipment, but maybe it is out there), this is a much stronger
 argument for a dear customer, either renumber or upgrade your
 hardware position than for an allocation that will force that
 renumber or upgrade position as soon as, e.g., ISPs merge or
 discover a need for an extra layer or CGN.
 
john
 
 On DOCSIS networks, there are typically two deployment scenarios:
 A) subscriber plugs PC directly into the CM
 B) subscriber provides a router, which connects to the CM
 
 In both cases, the subscriber is responsible for the equipment.  Many
 subscribers don't know what an IP address is, and don't care.  I'm trying
 to imagine my parents receiving such a letter renumber your IP address
 and/or buy a new PC or router.  Such a letter would probably cause anger
 and confusion and an increased readiness to switch to the ISP across town
 that's using squat space and doesn't require customers to call Geek Squad
 or buy something else.
 
 Chris

It's really only those that have a router connected that need to
check.  The ordinary PC that is not being used as a router is not a
issue with RFC 1918 addresses.

If you have a router connected to the cable modem or are using a
PC in Internet Connection Sharing (ICS) mode please reconfigure it to not
use the address range  for the home network.  Most routers and
PC in ICS mode already do not use this address range.

That said a lot of customers won't know how to check and/or change
the address range.

Additionally this also affects everybody that is currently using
this block of RFC 1918 address as the IETF is taking it away from
them.  Not just the customers behind CGNs.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)


In message 
CAJNg7V+wxN_hsqGA_hQOr0Yc3Xyf1dqJQmaCDjzRu-zGCf_-=w...@mail.gmail.com
, Marshall Eubanks writes:
 On Mon, Dec 5, 2011 at 1:00 PM, David Conrad d...@virtualized.org wrote:
  Frank,
 
  On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
  The last state I'm aware of is that the 240/4 addresses minus one
  were and still are (RFC 5735) reserved for IETF experiments, did I miss
  some newer IETF consensus about this?
  ...
  http://omniplex.blogspot.com/2008/06/lost-found-268435455-free-ips.html
 
  Does it actually matter? =A0What RFCs say (or don't say) about 240/4 mean=
 s precisely nothing to the deployed, non-field-upgradable CPE that I unders=
 tand is driving the interest draft-weil.
 
 That IMO is the rock that proposals to use Class E have floundered on.
 There is a lot of gear out there that will not be able to
 deal with any Class E internetworking protocol, little prospect that
 that will be changed any time soon, and a general feeling that it is
 unwise to spend limited resources changing this.
 
 Regards
 Marshall

The annoying thing here is that the IETF has already spent more
time arguing over whether to do this that it would have taken to
do it.

Add some signaling to PPP/DHCP that you are happy to receive a Class
E address and it could have been done incrementally.  ISP would
have turned it on when there equipment supported it.  The latest
Windows and MacOS builds would have supported it.  Similarly the
laters Linus and *BSD builds would have supported it (some already
do, sans signalling).  CPE vendors would have turned it on.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call: draft-weil-shared-transition-space-request


In message 3e7ae2ad-18e0-4ea0-bf76-704cd49ec...@virtualized.org, David Conrad
 writes:
 Wes,
 
 On Dec 5, 2011, at 10:02 AM, George, Wes wrote:
  Independent of whether we have any left, continued support for IPv4 in the 
 home and enterprise is *non-negotiable*,
 
 True, however as I understand it, this isn't the issue.  IIUC, the problem is
 n't what happens in the home and enterprise, it is what happens on the WAN si
 de of old non-upgradeable CPE when connected via CGNs.  
 
  Saying that IPv6 is a solution to an IPv4 CGN implementation problem is lik
 e saying ...
 
 I'm guessing part of the issue here is folks appear to be talking past each o
 ther.  It might be helpful to be explicit about what your view of the IPv4 C
 GN implementation problem is. For example, IPv6 _could_ be a solution if bot
 h the CPE and the CGN supports IPv6 and a way to tunnel v4 through v6 (no ide
 a if anyone does this).
 
 Regards,
 -drc

It's called DS-Lite and the IETF is working towards getting it added
to the IPv6 CPE Router profile.   Unfortunately it requires a CPE
that supports IPv6 or is upgradable to support IPv6 and most existing
CPE routers don't fall into either of those categories.

This is primarly about getting existing equipment to work well with
CGNs without breaking everything else and address conservation.

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.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

John,

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 would react either with anger or non-comprehension if presented with such 
a position. If you were running such a network, would you risk it?

 than for an allocation that will force that
 renumber or upgrade position as soon as, e.g., ISPs merge or
 discover a need for an extra layer or CGN.

I'm confused: why would an ISP merge/extra layer of CGN for the ISP to relay 
that position to their customers? My impression is that we're talking about 
ISP-side (only) . I'd think this would be handled by the ISP changing the IP 
address on the WAN side of the CPE via normal provisioning systems if/whern 
collisions occur with the merged/layered network.

Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-12-05 Thread Doug Barton

On 12/05/2011 10:02, George, Wes wrote:
 I don't know how much clearer I can make this, so I'll keep repeating it 
 until it hopefully sinks in:
 Independent of whether we have any left, continued support for IPv4 in the 
 home and enterprise is *non-negotiable*

In case it isn't clear, and in spite of my snarky comments, I'm not
suggesting that IPv4 shouldn't be supported. I'm not even saying that
CGN shouldn't be done. What we're discussing is *how* it should be done,
and whether or not a new allocation is necessary to do it.


Doug

-- 

[^L]

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC

2011-12-05 Thread Dave CROCKER



On 12/4/2011 1:27 PM, John Levine wrote:

ADSP already dictates use of the From: domain.


The the nature ADSP's use of the From: domain is fundamentally different from 
ATPS' use.


Broadly, we can distinguish:

   Name extraction:determining what name is being claimed

   Name verification:  determining that the use of the name is authorized

   Name assessment:determining whether the name is associated with good
   or bad actor.

ADSP adds a constraint on name verification; it mandates that at least one DKIM 
d= name match the domain in the From: field.


ATPS essentially modifies name extraction, by making it a two-step process. The 
first step is the usual one, with d=, for use with validation, but the second 
one takes the domain in the From: field and makes it the output string to the 
assessment process.



 ATPS is a modification

to ADSP.  It doesn't change anything that DKIM reports, only the rule
for deciding whether ADSP finds an Author Domain Signature.


While yes it has text pertaining to ADSP, I will claim that with ADSP, too, the 
modification is in name extraction rather than validation or assessment.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC

2011-12-05 Thread Dave CROCKER




On 11/30/2011 1:03 PM, Barry Leiba wrote:

In plain English, this reads as an update of ADSP but this draft does not
  update RFC 5617.

It does not.  There's no reason that anyone implementing ADSP need pay
attention to this.*IF*  you implement this, it might change your
behaviour with respect to ADSP, but information about that is
contained here.  There's no reason for this to update 5617 in the
IETF sense.



I think Barry's characterization is correct.  The word update can have some 
different uses in this realm.


In IETF RFC formal lingo, I believe update means that the new spec is 
modifying the core document.  It really is, therefore, to be taken as part of 
that core document's text.


In a very different sense, some specification provide optional value-add to a 
core spec.  Using that enhancement is optional; so it's no part of the core. 
However, if one chooses to use the enhancement, then yes the enhancements 
updates some aspect of the core.


I believe that ATPS is the latter form of update to DKIM and ADSP.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-storm-rddp-registries-00.txt (IANA Registries for the RDDP (Remote Direct Data Placement) Protocols) to Proposed Standard

2011-12-05 Thread SM


At 14:41 05-12-2011, The IESG wrote:

The IESG has received a request from the STORage Maintenance WG (storm)
to consider the following document:
- 'IANA Registries for the RDDP (Remote Direct Data Placement) Protocols'
  draft-ietf-storm-rddp-registries-00.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-19. Exceptionally, comments may be


The intended status is odd if the following requirement has to be tested:

  IANA MUST NOT add an entry to this registry with an Error Code
   for the same Error Type

From the PROTO write-up:

  The IANA Considerations section exists and states that no
   IANA actions

And from Section 3 of the draft:

  This memo creates the following RDDP registries for IANA to manage:

 o RDMAP Errors (Section 3.1)
 o DDP Errors (Section 3.2)
 o MPA Errors (Section 3.3)
 o RDMAP Message Operation Codes (Section 3.4)
 o SCTP Function Codes for DDP Stream Session Control (Section 3.5)

From Section 3.1:

  An IESG-approved standards-track specification

Are there standard-track specifications which do not require IESG approval?

Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC

2011-12-05 Thread John R. Levine

ATPS essentially modifies name extraction, by making it a two-step process. 
The first step is the usual one, with d=, for use with validation, but the 
second one takes the domain in the From: field and makes it the output string 
to the assessment process.


If you're referring to the second paragraph in section 5, I agree that the 
second sentence should go, or at least be rewritten to clarify that the 
client is supposed to pretend that the message passed ADSP.  If it's 
anything else in atps-11, you'll have to help me out with references to 
specific language.


R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC

2011-12-05 Thread Murray S. Kucherawy

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John 
 R. Levine
 Sent: Monday, December 05, 2011 5:25 PM
 To: Dave Crocker
 Cc: ietf@ietf.org
 Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized 
 Third-Party Signers) to Experimental RFC

 If you're referring to the second paragraph in section 5, I agree that
 the second sentence should go, or at least be rewritten to clarify that
 the client is supposed to pretend that the message passed ADSP.  If
 it's anything else in atps-11, you'll have to help me out with
 references to specific language.

But that's what Section 6 says.

Section 5 is for those people that do DKIM without ADSP but care about giving 
author domain signatures preferential treatment.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-05 Thread Martin Rex

Sabahattin Gucukoglu wrote:
 
 In case you didn't see this:
 http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html
 
 It's a complete IPv6 NAT implementation with the functionality of
 the IPv4 one in the same stack.  ALGs.  Port translation.  Connection
 tracking.  You don't need me to tell you why I don't like this.


I fail to understand the issue that you have with this.

Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
outbound connections by default (i.e. *NO* static network prefix that
can be linked to a single ISP customer) would be extremely irresponsible
with respect to data privacy protection.

Without that, I consider IPv6 a complete no-go.

And many DSL routers are based on Linux, so having an implementation
of such a NAT is a prerequisite before IPv6 can be reasonably offered
to home customers in Europe.

I'm perfectly OK with folks getting static IPv6 network prefixes for
specific applications that desperately need it.  But the default
definitely ought to be temporary dynamic IPv6 addresses, especially
for outbound connections.


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-05 Thread Brian E Carpenter

On 2011-12-06 15:00, Martin Rex wrote:
 Sabahattin Gucukoglu wrote:
 In case you didn't see this:
 http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html

 It's a complete IPv6 NAT implementation with the functionality of
 the IPv4 one in the same stack.  ALGs.  Port translation.  Connection
 tracking.  You don't need me to tell you why I don't like this.
 
 
 I fail to understand the issue that you have with this.
 
 Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
 outbound connections by default (i.e. *NO* static network prefix that
 can be linked to a single ISP customer) 


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.

If you want to protect the privacy of individuals within the home (etc.)
behind the CPE, you can use IPv6 privacy addresses. But the traffic will
still be traceable back to the CPE, of course.

I hope you aren't under the illusion that NAT44 in CPE provides any
privacy.

  Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-05 Thread Martin Rex

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.

Your reasoning is obviously flawed.

Having a temporary dynamic IP address assigned will not prevent any
negligent or privacy-ignorant protocols and apps higher up the stack
to reveal identifying information about you.

But _without_ a temporary dynamic IP address, each and every of your
network communcation will be 100% identifyable as you for everybody that
can oberserve you IP datagrams floating by, even when you're using IPSEC.


 
 We have local source address selection mechanisms in recent Windows
 versions that use randomized IIDs on outbound connections today.
 This doesn't prevent exposure of the information regarding the
 internal network structure, but nor do firewalls at publically
 addressed IPv4 institutions today.

I fail to understand what you mean by randomized IIDs.
What you need is a temporary network address randomized by you ISP
so that your address blends within the entire customer base
of that ISP.


 
 Putting NATs on the path just causes the device inside the network
 to be unaware of its presented addresses, which means that it will
 impede peer-to-peer communications, as it cannot even describe its
 available services without external information services.

Asking your border router for the temporary external IP-Address is
trivial compared to performing a secure DNS lookup.


 
 This is the awful situation in IPv4 today:  Address scarcity
 is not the problem, addressability is the problem.

It is a problem for which solutions exists or can be built with
moderate effort.  Privacy is a much more serious problem today,
and without temporary dynamic addresses assigned by the ISP
privacy can no longer exist.


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-05 Thread Martin Rex

Brian E Carpenter wrote:

Martin Rex wrote:
Sabahattin Gucukoglu wrote:
In case you didn't see this:
http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html

It's a complete IPv6 NAT implementation with the functionality of
the IPv4 one in the same stack. ALGs. Port translation. Connection
tracking. You don't need me to tell you why I don't like this.

I fail to understand the issue that you have with this.

Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
outbound connections by default (i.e. *NO* static network prefix that
can be linked to a single ISP customer)

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 subscriber, any only
the ISP knows to which of his customers he is routing the datagrams
during any specific point in time. The DHCP lease should be 24h at most
and the ISP is bound by data protection laws to not make the mapping
publicly accessible except under very specific legal exceptions.

If you want to protect the privacy of individuals within the home (etc.)
behind the CPE, you can use IPv6 privacy addresses. But the traffic will
still be traceable back to the CPE, of course.

The so-called IPv6 privacy addresses are terminology fud.

I hope you aren't under the illusion that NAT44 in CPE provides any
privacy.

For my ISP (and it seems to be the norm for german home customers),
that is not an illusion, but rather a feature.

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-12-05 Thread Doug Barton

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 those
 interested in deploying CGN would like to avoid in order to protect
 their margins. I'm not sympathetic.
 
 [CD] Really?  10% of customers having problems is a viable model?

I should have inserted the word technically in there to make my
meaning more clear. Sorry about the confusion.

 Let's do the math here.  Consider a 10M subscriber ISP. Your breakage
 model (10%)

Please note, that's a total WAG. My gut is that the actual amount of
breakage will be substantially less, especially for an ISP that deals
primarily with the SOHO market.

 would generate at least 1 M support calls (some people
 may call more than once).  Let's say a support call costs $50 (I
 don't know the exact cost, but I think this is close), so the cost of
 supporting a 10% failure case will be close to the $50M you keep
 quoting (multiply this by the number of affected ISPs).  What do you
 think an ISP will do if faced with this option and no Shared CGN
 Space? Select an IETF-specified RFC1918 block of addresses and deal
 with $50M of support costs plus 1M upset subscribers?  Acquire
 addresses from the RIR (or from an address broker)?  Or squat on
 someone else's space?

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 helped create.

 And if that doesn't fully answer your Which part don't you agree
 with? question, I doubt that even a significant portion of ISPs are
 going to use routable addresses internally for CGN as the value of
 those addresses for their intended purpose is only going to increase,
 and they will still need to be able to number publicly facing things
 after the RIRs have exhausted their supply.
 
 [CD] So you're really arguing for squat space?

Certainly not. I think I've made my position on the right way to
handle this issue perfectly clear.

 I have a real problem
 with that.  I know people are already doing it, but I think it sets a
 bad precedent and increases risk of interoperability problems across
 the Internet. I believe the IETF has a vested interest in
 discouraging address squatting, and should act accordingly.

If it's already being done then we've got running code, right? :)

More seriously, it sounds to me like the most persuasive argument in
favor of doing the new allocation boils down to simple extortion. Give
us a $50,000,000 'gift' or we'll do bad things to the intahrnetz.


Doug

-- 

[^L]

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-05 Thread Brian E Carpenter

On 2011-12-06 15:40, Martin Rex wrote:
Brian E Carpenter wrote:
Martin Rex wrote:
Sabahattin Gucukoglu wrote:
In case you didn't see this:
http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html

It's a complete IPv6 NAT implementation with the functionality of
the IPv4 one in the same stack. ALGs. Port translation. Connection
tracking. You don't need me to tell you why I don't like this.

I fail to understand the issue that you have with this.

Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
outbound connections by default (i.e. *NO* static network prefix that
can be linked to a single ISP customer)

If you are paranoid about your IP address, that's fine. Personally, I prefer
a stable address. If your IPv6 prefix changes every day, your home network
will get renumbered every day. What does this have to do with NAT?

If you want to protect the privacy of individuals within the home (etc.)
behind the CPE, you can use IPv6 privacy addresses. But the traffic will
still be traceable back to the CPE, of course.

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 downloading music.

I hope you aren't under the illusion that NAT44 in CPE provides any
privacy.

For my ISP (and it seems to be the norm for german home customers),
that is not an illusion, but rather a feature.

You mean there is a privacy benefit in translating some address such
as 10.1.1.2 into a routeable IPv4 address that can, as you say, be traced
back to you even if it changes every day?

You'll have to explain that.

Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC

2011-12-05 Thread John Levine

Section 5 is for those people that do DKIM without ADSP but care about
giving author domain signatures preferential treatment.

Since there's nothing in the DKIM spec that suggests that's a correct
way to use DKIM, I'd be fairly unhappy about any language that
purports to legitimize it.

Here in standards-land, if you think that author domain signatures
matter, you're supposed to use ADSP.

R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Netfilter (Linux) Does IPv6 NAT


In message 4edd894e.6030...@gmail.com, Brian E Carpenter writes:
 On 2011-12-06 15:40, Martin Rex wrote:
  Brian E Carpenter wrote:
  Martin Rex wrote:
  Sabahattin Gucukoglu wrote:
  In case you didn't see this:
  http://www.h-online.com/open/news/item/Netfilter-developers-working-on-N
 AT-for-ip6tables-1385877.html
 
  It's a complete IPv6 NAT implementation with the functionality of
  the IPv4 one in the same stack.  ALGs.  Port translation.  Connection
  tracking.  You don't need me to tell you why I don't like this.
 
  I fail to understand the issue that you have with this.
 
  Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
  outbound connections by default (i.e. *NO* static network prefix that
  can be linked to a single ISP customer) 
 
  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 subscriber, any only
  the ISP knows to which of his customers he is routing the datagrams
  during any specific point in time.  The DHCP lease should be 24h at most
  and the ISP is bound by data protection laws to not make the mapping
  publicly accessible except under very specific legal exceptions.
 
 If you are paranoid about your IP address, that's fine. Personally, I prefer
 a stable address. If your IPv6 prefix changes every day, your home network
 will get renumbered every day. What does this have to do with NAT?
 
  If you want to protect the privacy of individuals within the home (etc.)
  behind the CPE, you can use IPv6 privacy addresses. But the traffic will
  still be traceable back to the CPE, of course.
  
  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 downloading music.

If parents want to know which child is doing what they can do that
even with privacy addresses.  Privacy addresses don't change the
mac, that just don't encode the mac in the IPv6 address.  If the
kids start playing mac games use 802.1x.

  I hope you aren't under the illusion that NAT44 in CPE provides any
  privacy.
  
  For my ISP (and it seems to be the norm for german home customers),
  that is not an illusion, but rather a feature.
 
 You mean there is a privacy benefit in translating some address such
 as 10.1.1.2 into a routeable IPv4 address that can, as you say, be traced
 back to you even if it changes every day?
 
 You'll have to explain that.
 
 Brian
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)

2011-12-05 Thread Måns Nilsson

Subject: Re: class E (was: Consensus Call: 
draft-weil-shared-transition-space-request) Date: Tue, Dec 06, 2011 at 
08:38:56AM +1100 Quoting Mark Andrews (ma...@isc.org):
 
 Ask everyone everywhere that is using this block, in good faith,
 for some purpose other than supporting addresses behind a CGN to
 renumber out of this block of RFC 1918 addresss which is now being
 re-purposed 16 years after it was allocated.

I do not understand why it is so hard to come to terms with the fact
that IF you have -- in whatever faith -- chosen to use non-unique address
space, you have been taking your chanches that sometime, in the future,
you WILL have to renumber to keep the illusion of quasi-uniqueness. This
goes for everybody. Customer, operator, middlebox or CPE vendor,
and my mother. This is inherent in all non-unique space. A new shared
allocation from the RIR pools or Class E will not change this fundamental
characteristic.  Therefore, 1918 space, being the prime example of
non-uniqueness, should be quite suited to populate the inside of a CGN.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Am I SHOPLIFTING?


signature.asc
Description: Digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Protocol Action: 'Sieve Extension for Converting Messages Before Delivery' to Proposed Standard (draft-ietf-sieve-convert-06.txt)

The IESG has approved the following document:
- 'Sieve Extension for Converting Messages Before Delivery'
  (draft-ietf-sieve-convert-06.txt) as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working
Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-sieve-convert/




Technical Summary

   This document describes how IMAP CONVERT can be used within Sieve to
   transform messages before final delivery.

Working Group Summary

This extension started as an individual submission in 2008 and was
adopted as a WG document in 2010. The basic premise has remained the
same throughout all revisions of the document.

This extension adds a new combined action and test to SIEVE to allow
message parts to be converted to other types during delivery. One new
behavior here is that this extension creates a new combined test and
action. This is something new for SIEVE (though allowed by the base
spec), and implementors were explicitly asked to comment on whether this
approach was viable - with a positive response. The document has not
received any reviews from non-WG members. However, many of the existing
WG members had participated in the Lemonade WG IMAP CONVERT work, on
which the SIEVE convert extension is heavily based, so from that
standpoint we do have review from existing IMAP implementors.

Document Quality

There are no known implementations of this extension at present. Various
vendors have expressed interest in implementing this extension, however
it is not currently a top priority for any of them.

Personnel

Document Shepherd: Cyrus Daboo mailto:cy...@daboo.name
AD: Pete Resnick mailto:presn...@qualcomm.com
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Document Action: 'Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail' to Informational RFC (draft-melnikov-mmhs-header-fields-08.txt)

The IESG has approved the following document:
- 'Registration of Military Message Handling System (MMHS) header fields
   for use in Internet Mail'
  (draft-melnikov-mmhs-header-fields-08.txt) as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-melnikov-mmhs-header-fields/




Technical Summary

A Miltary Message Handling System (MMHS) processes formal messages
ensuring release, distribution, security, and timely delivery across
national and international strategic and tactical networks. The MMHS
Elements of Service are defined as a set of extensions to the ITU-T
X.400 (1992) international standards and are specified in STANAG 4406
Edition 2. This document describes a method for enabling those MMHS
Elements of Service that are defined as Heading Extension to be encoded
as RFC 5322 (Internet Email) message header fields. These header field
definitions support the provision of a STANAG 4406 MMHS over Internet
Email, and also provides for a STANAG 4406 / Internet Email Gateway
supporting message conversion compliant to this specification.

Working Group Summary

The substance of the definitions in this draft is derived from the
military messaging heading elements defined in STANAG 4406. The comments
to date have consisted of corrections and minor amendments only.

The decision was made by the authors to exclude support for the
distribution extensions form of the Distribution-Codes heading
extension. This is noted in sections 3.3 and 6. However, this MMHS
feature is sparsely implemented and is not known to be in use within any
major military organization.

The decision was taken after the -01 draft to split the
MMHS-Other-Recipients-Indicator header into two separate headers
containing primary (to:) and copy (cc:) other recipients. This approach
varies from the approach in STANAG 4406, but is more consistent with the
RFC 822 style of address headers, and should be simpler for
implementations to process. It is not expected to create a significant
problem for gateway implementations.

Document Quality

At least three client implementations of this specification and one
server implementation exist. One client implementation is the open
source Thunderbird plugin. Another implementation is an Outlook plug-in
that was prepared by one of the authors.

Reviewers of the document are cited in Appendix A.

Personnel

Chris Bonatti bonat...@ieca.com is the Document Shepherd.
Pete Resnick presn...@qualcomm.com is the AD.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' to Full Standard (draft-ietf-appsawg-rfc3462bis-04.txt)

The IESG has approved the following document:
- 'The Multipart/Report Media Type for the Reporting of Mail System
   Administrative Messages'
  (draft-ietf-appsawg-rfc3462bis-04.txt) as a Full Standard

This document is the product of the Applications Area Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3462bis/




Technical Summary 

The multipart/report media type is a general family or container type 
for electronic mail reports of any kind. Although this memo defines only 
the use of the multipart/report media type with respect to delivery status 
reports, mail processing programs will benefit if a single media type is 
used for all kinds of reports. 

Practical experience has shown that the general requirement of having 
that media type constrained to be used only as the outermost MIME 
type of a message, while well-intentioned, has provided little operational 
benefit and actually limits such things as the transmission of multiple 
administrative reports within a single overall message container. In 
particular, it prevents one from forwarding a report as part of another 
multipart MIME message. 

This update removes that constraint. No other changes apart from 
some editorial ones are made. 

Working Group Summary 

There was initially concern that the original requirement that multipart/report 
be a top-level-only media type was done for a good reason, and that the 
requirement should not be removed entirely. After some discussion, it seemed 
that the right approach was to retain the requirement in the context of newly 
generated DSNs, but to lift it in the more general case. This version of the 
document does just that, by reference to the original DSN specifications, and 
that formulation has broad consensus. 

Document Quality 

Multipart/report is very widely implemented and deployed, and, in fact, it has 
been used in the form described herein, with the top-level constraint ignored, 
for years. Ned Freed, who is the expert reviewer for media types, has reviewed 
this update and is happy with it. The interoperability report that was used to
take 3462 to Draft was:
http://www.ietf.org/iesg/implementation/report-rfc1891-1894.txt

Personnel

Barry Leiba barryle...@computer.org is the Document Shepherd.
Pete Resnick presn...@qualcomm.com is the AD.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Document Action: 'BCP 47 Extension T - Transformed Content' to Informational RFC (draft-davis-t-langtag-ext-07.txt)