shared address space... a reality!
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
On 3/13/12 23:29 , Joel jaeggli wrote:
On 3/13/12 23:22 , Christopher Morrow wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Already updated my martians acl and deployed it internally...
this also means you should probably filter the 6to4 mapped address range from 2002:a40::/48 to 2002:a7f:ffff::/48 since those have no chance of making it home.
On 14 Mar 2012, at 06:31, "Joel jaeggli" <joelja@bogus.com> wrote:
On 3/13/12 23:22 , Christopher Morrow wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Already updated my martians acl and deployed it internally...
There's an app for that! -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
;-) So that is what "very rough consensus" looks like operationally! IESG Note http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09959.html Christian On 15 Mar 2012, at 06:59, Randy Bush wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 Already updated my martians acl and deployed it internally...
and i have configured two home LANs to use it
randy
Christian de Larrinaga wrote:
;-) So that is what "very rough consensus" looks like operationally! IESG Note http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09959.html
Instead, I wonder whether the last phrases of the note, "the IETF remain committed to the deployment of IPv6" is the consensus, however rough, or not. It might be so, if people silently ignoring IPv6 are not counted. Masataka Ohta
What, senior network people testing out new test/transitional space at home before they test it at work is bad? On Thu, Mar 15, 2012 at 6:26 AM, Jérôme Nicolle <jerome@ceriz.fr> wrote:
Le 15/03/12 07:59, Randy Bush a écrit :
and i have configured two home LANs to use it
Sooooo wrong...
-- Jérôme Nicolle
-- -george william herbert george.herbert@gmail.com
More like "wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want". not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours? -r George Herbert <george.herbert@gmail.com> writes:
What, senior network people testing out new test/transitional space at home before they test it at work is bad?
On Thu, Mar 15, 2012 at 6:26 AM, Jérôme Nicolle <jerome@ceriz.fr> wrote:
Le 15/03/12 07:59, Randy Bush a écrit :
and i have configured two home LANs to use it
Sooooo wrong...
-- Jérôme Nicolle
-- -george william herbert george.herbert@gmail.com
I'm sure it happened much sooner than 72 hours post allocation. In fact, there were probably folks already squatting on that space long before any of this. Maybe their life just got a little easier. :) Cheers, -Benson On Mar 15, 2012, at 3:57 PM, Robert E. Seastrom wrote:
More like "wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want".
not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours?
-r
George Herbert <george.herbert@gmail.com> writes:
What, senior network people testing out new test/transitional space at home before they test it at work is bad?
On Thu, Mar 15, 2012 at 6:26 AM, Jérôme Nicolle <jerome@ceriz.fr> wrote:
Le 15/03/12 07:59, Randy Bush a écrit :
and i have configured two home LANs to use it
Sooooo wrong...
-- Jérôme Nicolle
-- -george william herbert george.herbert@gmail.com
On Thu, Mar 15, 2012 at 1:57 PM, Robert E. Seastrom <rs@seastrom.com> wrote:
More like "wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want".
not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours?
-r
I think this is people reading their preconceived notions onto the situation. I understand the policy disagreement about having the space in the first place. That said... Your and Jerome's reactions seem to amount to "Not only should you never have done this, actually testing it in the normal informal operational area once it's here and approved is a further insult." My counterargument is - if you are suggesting people should be less professional about testing out the new space than they are for any other new thing, then you're being political and not operational. Operationally this is exactly the right thing to have Randy do. He certainly didn't need to do this because he's exhausted 1918 space at home (well, I hope not... 8-). -- -george william herbert george.herbert@gmail.com
George Herbert <george.herbert@gmail.com> writes:
On Thu, Mar 15, 2012 at 1:57 PM, Robert E. Seastrom <rs@seastrom.com> wrote:
More like "wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want".
not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours?
-r
I think this is people reading their preconceived notions onto the situation.
I understand the policy disagreement about having the space in the first place. That said...
Your and Jerome's reactions seem to amount to "Not only should you never have done this, actually testing it in the normal informal operational area once it's here and approved is a further insult."
My counterargument is - if you are suggesting people should be less professional about testing out the new space than they are for any other new thing, then you're being political and not operational. Operationally this is exactly the right thing to have Randy do.
He certainly didn't need to do this because he's exhausted 1918 space at home (well, I hope not... 8-).
In the unlikely but not impossible event that Randy is on 1918 space at home and has the external address of his consumer home gateway configured into this space, and thence to a CGN appliance or blade in the Big Router at his perimeter where he gets NATted into a globally unique address (i.e., the meat in a NAT444 sandwich), or something similar, then I certainly stand corrected. I encourage this sort of testing. I'm not reading "my preconceived notions" of anything other than Randy's personality and very vocal assertions of what people would do with this space if it got assigned into my assessment of what's going on here. Inasmuch as I am pretty sure I'm in Randy's .procmailrc, y'all will have to ask him directly; don't expect him to chime in replying to my mail. -r
On Thu, Mar 15, 2012 at 4:57 PM, Robert E. Seastrom <rs@seastrom.com> wrote:
Le 15/03/12 07:59, Randy Bush a écrit :
and i have configured two home LANs to use it
More like "wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want".
not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours?
That's OK. I've configured two home LANs to use 147.28.0.0/16 and I'm not expecting any problems either. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Mar 15, 2012 at 3:57 PM, Robert E. Seastrom <rs@seastrom.com> wrote:
More like "wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want".
The draft indicates you can deploy it anywhere as long as you meet the special requirement: You have a router capable of performing address translation across router interfaces when addresses are identical on two different interfaces. The other option is that you are a service provider If you meet the router capability requirement you don't have to be a SP. -- -JH
On Thu, 15 Mar 2012 13:35:13 PDT, George Herbert said:
What, senior network people testing out new test/transitional space at home before they test it at work is bad?
Either that, or Randy was being snarky about how long the promise to *only* use the address space for numbering CGN interfaces and not as additional RFC1918 space was going to last in reality....
On 15 Mar 2012, at 21:03, Valdis.Kletnieks@vt.edu wrote:
On Thu, 15 Mar 2012 13:35:13 PDT, George Herbert said:
What, senior network people testing out new test/transitional space at home before they test it at work is bad?
Either that, or Randy was being snarky about how long the promise to *only* use the address space for numbering CGN interfaces and not as additional RFC1918 space was going to last in reality....
So where is that new /10 leaking to already? ;). Tim
On Wed, Mar 14, 2012 at 02:22:04AM -0400, Christopher Morrow wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
GOOD. Now I can BOTH keep sticking my head in the sand AND get NEW RFC 1918 space to number my devices! Trailing edge WINS! Congrats, all you people who joined the ietf mailing list to get your VOTE through. You can sign off now and continue non-contributing to the developement of the future. -- /Måns, pissed off.
On 3/14/2012 2:22 AM, Christopher Morrow wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Did IANA have to justify this space to ARIN or was it just given to them no questions asked because a draft RFC specified a need for a /10?
On Wed, Mar 14, 2012 at 7:54 AM, ML <ml@kenweb.org> wrote:
On 3/14/2012 2:22 AM, Christopher Morrow wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Did IANA have to justify this space to ARIN or was it just given to them no questions asked because a draft RFC specified a need for a /10?
see the discussion in PPML/arin-announce... my recollection is something like this happened (paraphrased for the tl/dr crowd): 1) someone wanted more 1918^H^H^Hshared-transition space 2) a policy proposal came to ARIN's PP meeting 3) the policy proposal ran around for a time making friends 4) the proposal passed and the ARIN BoT essentially got a message from IANA/IESG saying: "Hey, before you leap... lookout, perhaps the IETF should weigh in?" 5) an IETF draft was drafted (which later had a baby... so there are 2 versions/parts flying about) 6) the main draft was finalized and sent along to the RFC editor, and made into a BCP <http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09959.html> 7) IANA received this /10 from ARIN -chris
Thanks Chris for the update to the list. One minor clarification for the community with regards to: 4) the proposal passed and the ARIN BoT essentially got a message from IANA/IESG saying: "Hey, before you leap... lookout, perhaps the IETF should weigh in?" After the ARIN Advisory Council forwarded the policy to the ARIN Board of Trustees for consideration, the Trustees directed the President, John Curran, to consult with the IAB and IESG on the potential issues of adopting said draft policy prior to taking any further policy action. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers
On Wed, Mar 14, 2012 at 1:22 PM, Nate Davis <ndavis@arin.net> wrote:
Thanks Chris for the update to the list. One minor clarification for the community with regards to:
4) the proposal passed and the ARIN BoT essentially got a message from IANA/IESG saying: "Hey, before you leap... lookout, perhaps the IETF should weigh in?"
After the ARIN Advisory Council forwarded the policy to the ARIN Board of Trustees for consideration, the Trustees directed the President, John Curran, to consult with the IAB and IESG on the potential issues of adopting said draft policy prior to taking any further policy action.
thanks! history is important here.
On Mar 14, 2012, at 6:54 PM, Christopher Morrow wrote:
thanks! history is important here.
Policy proposals for "specialized technical allocations" are best considered by the IETF. ARIN was aware of the RFC 2860 (the MOU between ICANN and the IAB) which said as much, and once we confirmed this understanding with the IAB, ARIN directed the community to make use of the IETF process to develop an appropriate RFC for an IANA assignment. ARIN was notified by the IANA that the RFC was approved and was asked if we could assign sufficient resources to them for this purpose. The ARIN Board approved assigning back to the IANA a /10 block out of one of the /8's we received from them in 2010. The IANA registry has been now updated accordingly: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml#no... Thanks! (and hope this clarifies things) /John John Curran President and CEO ARIN
On Thu, Mar 15, 2012 at 11:34 AM, John Curran <jcurran@arin.net> wrote:
On Mar 14, 2012, at 6:54 PM, Christopher Morrow wrote:
thanks! history is important here.
reading this this morning, my comment sounds more flippant than I meant. I really did mean that getting the details right was important.
Policy proposals for "specialized technical allocations" are best considered by the IETF. ARIN was aware of the RFC 2860 (the MOU between ICANN and the IAB) which said as much, and once we confirmed this understanding with the IAB, ARIN directed the community to make use of the IETF process to develop an appropriate RFC for an IANA assignment.
ARIN was notified by the IANA that the RFC was approved and was asked if we could assign sufficient resources to them for this purpose. The ARIN Board approved assigning back to the IANA a /10 block out of one of the /8's we received from them in 2010. The IANA registry has been now updated accordingly: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml#no...
Thanks! (and hope this clarifies things)
does, thanks!
John Curran President and CEO ARIN
On Mar 14, 2012, at 7:41 AM, Christopher Morrow wrote:
On Wed, Mar 14, 2012 at 7:54 AM, ML <ml@kenweb.org> wrote:
On 3/14/2012 2:22 AM, Christopher Morrow wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Did IANA have to justify this space to ARIN or was it just given to them no questions asked because a draft RFC specified a need for a /10?
see the discussion in PPML/arin-announce... my recollection is something like this happened (paraphrased for the tl/dr crowd): 1) someone wanted more 1918^H^H^Hshared-transition space 2) a policy proposal came to ARIN's PP meeting 3) the policy proposal ran around for a time making friends 4) the proposal passed and the ARIN BoT essentially got a message from IANA/IESG saying: "Hey, before you leap... lookout, perhaps the IETF should weigh in?"
Well, actually, the ARIN board^H^H^H^H^HCEO went to IESG saying "mother may I" would be a more accurate description of the process.
5) an IETF draft was drafted (which later had a baby... so there are 2 versions/parts flying about)
Actually, draft-weil was floated before the ARIN policy proposal IIRC. The other draft (draft-bdgks) came after, essentially in response to the statement by the ARIN board/CEO that getting the policy implemented would require IESG approval.
6) the main draft was finalized and sent along to the RFC editor, and made into a BCP <http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09959.html> 7) IANA received this /10 from ARIN
Otherwise, yeah, I think that about sums it up. Owen
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow <christopher.morrow@gmail.com> wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? Sure, this lets CGN to be more organized for operators, but those that already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6. -- Octavio.
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow <christopher.morrow@gmail.com> wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live?
ha!
Sure, this lets CGN to be more organized for operators, but those that
ghuston has a great presentation about CGN deployments, and how they essentially become permanent (or could, according to his chickenbone-readings)... It's an interesting thought experiment/discussion, and one I'm curious to see play out.
already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6.
are you really asking: "Why on why did we go through all this hard work for something with basically no easy to quantify return?" hell, this may get more use than SCTP does, and sctp took a LOT longer to do... -chris
From: Octavio Alvarez
Sure, this lets CGN to be more organized for operators, but those that already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6.
-- Octavio.
This is yet one more moving parts in the growing assemblage of moving parts that is required to make v4 work going forward. At some point (soon) we will reach a point of diminishing return and people are simply going to realize that it is easier to deploy v6 native than it is to attempt to keep v4 limping along. A new player is probably going to buy new gear. New gear isn't going to have the problems with v6 that older networks might have who could still be using ancient gear and can't afford to "forklift" their stuff out. A new player entering the market these days looking to use this for a native v4 deployment going forward any significant period of time ... is probably not making the wisest choice. And with every additional moving part there is something else that impacts performance, something else to break, something else to become CPU or memory bound ... performance over v4 will become increasingly poor, increasingly unreliable, and people are just going to realize that any pain of v6 migration is a lot less than keeping the bailing wire, super glue, and rubber bands around v4. This will be true of their own networks and the networks they are communicating with. V4 performance in general from here on out is simply going to go south. Umpteen NATs, routing table bloat as the nets shatter into smaller and smaller blocks, at some point v4 isn't worth it. Maybe we should just propose more and more and more Band-Aids. Many choose not to migrate to v6 out of simple laziness (if it ain't broken, don't fix it). At some point it will take so much more work to keep v4 going that the path of least phone calls in the middle of the night will be IPv6.
In my perception, this is primarily a moving part that will be used by providers deploying IPv6 as a mechanism to compensate for things on the internet their customers want to reach that have not yet deployed IPv6. If deploying IPv6 on your own network qualified as a complete solution to the problem, I suspect we'd actually be much further along in the process. Unfortunately, deploying IPv6 locally does not change the fact that you use the internet to talk to things not under your control and until they deploy IPv6, you cannot depend entirely on IPv6 to do that. I don't think any sane provider will use this as yet another way to avoid deploying IPv4. OTOH, the number of not sane providers is somewhat scary, but, hopefully not of sufficient critical mass as to be meaningful in the long term. Owen
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com]
In my perception, this is primarily a moving part that will be used by providers deploying IPv6 as a mechanism to compensate for things on the internet their customers want to reach that have not yet deployed IPv6.
I think it will be used mostly as the middle 4 in NAT444 and in links between networks where there are RFC1918 network assignment collisions. My gut tells me we will see that net block being used for NAT on a lot of VPNs between RFC1918 networks.
I don't think any sane provider will use this as yet another way to avoid deploying IPv4.
I hope you're right.
OTOH, the number of not sane providers is somewhat scary, but, hopefully not of sufficient critical mass as to be meaningful in the long term.
On Mar 16, 2012, at 3:59 PM, George Bonser wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com]
In my perception, this is primarily a moving part that will be used by providers deploying IPv6 as a mechanism to compensate for things on the internet their customers want to reach that have not yet deployed IPv6.
I think it will be used mostly as the middle 4 in NAT444 and in links between networks where there are RFC1918 network assignment collisions. My gut tells me we will see that net block being used for NAT on a lot of VPNs between RFC1918 networks.
I would agree with both of those statements.
I don't think any sane provider will use this as yet another way to avoid deploying IPv4.
I hope you're right.
Certainly of the providers I have spoken with about the subject, that seems to be the prevailing attitude. So there is some hope. Owen
On Fri, Mar 16, 2012 at 3:47 PM, Owen DeLong <owen@delong.com> wrote:
I don't think any sane provider will use this as yet another way to avoid deploying IPv4.
I'm sure that's correct, but if you fix the typo it may not be. ;-) Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow <christopher.morrow@gmail.com> wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live?
"We" forgot to ask if all the stakeholders wanted it solved. Most self-styled "enterprise" operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite. Christian de Larrinaga On 16 Mar 2012, at 19:35, William Herrin <bill@herrin.us> wrote:
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow <christopher.morrow@gmail.com> wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live?
"We" forgot to ask if all the stakeholders wanted it solved. Most self-styled "enterprise" operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
It may be easy to sell, but it's also fictitious. NAT is antithetical to security, not beneficial to it. Owen On Mar 16, 2012, at 1:21 PM, cdel.firsthand.net wrote:
NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite.
Christian de Larrinaga
On 16 Mar 2012, at 19:35, William Herrin <bill@herrin.us> wrote:
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow <christopher.morrow@gmail.com> wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live?
"We" forgot to ask if all the stakeholders wanted it solved. Most self-styled "enterprise" operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, 16 Mar 2012 14:17:38 PDT, Owen DeLong said:
It may be easy to sell, but it's also fictitious.
NAT is antithetical to security, not beneficial to it.
Anybody want to hazard a guess what % of Vint Cerf's famous 140M compromised boxes were behind a NAT and still got pwned by a drive-by fruiting?
Some major stakeholders are under legal or regulatory obligation to supervise and control. A small number of control points makes this less awful to effect. Dave Edelman On Mar 16, 2012, at 16:21, "cdel.firsthand.net" <cdel@firsthand.net> wrote:
NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite.
Christian de Larrinaga
On 16 Mar 2012, at 19:35, William Herrin <bill@herrin.us> wrote:
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow <christopher.morrow@gmail.com> wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live?
"We" forgot to ask if all the stakeholders wanted it solved. Most self-styled "enterprise" operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Greetings Dave, Having been one of the authors of this, and, at the time, unfortunately looking down the barrel of a CGN deployment (in AU). I can say, at least in our case, it had nothing to do with monitoring or intercept. In fact, CGN actually made that more difficult in some circumstances. And this was a carrier that definitely had that requirement. Chris On 17Mar2012, at 10.33, Dave Edelman wrote:
Some major stakeholders are under legal or regulatory obligation to supervise and control. A small number of control points makes this less awful to effect.
Dave Edelman
On Mar 16, 2012, at 16:21, "cdel.firsthand.net" <cdel@firsthand.net> wrote:
NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite.
Christian de Larrinaga
On 16 Mar 2012, at 19:35, William Herrin <bill@herrin.us> wrote:
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow <christopher.morrow@gmail.com> wrote:
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live?
"We" forgot to ask if all the stakeholders wanted it solved. Most self-styled "enterprise" operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- 李柯睿 Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl
participants (25)
-
Benson Schliesser -
cdel.firsthand.net -
Christian de Larrinaga
-
Christopher LILJENSTOLPE -
Christopher Morrow -
Christopher Morrow -
Dave Edelman -
George Bonser -
George Herbert -
Jimmy Hess -
Joel jaeggli -
John Curran -
Jérôme Nicolle -
Leigh Porter -
Masataka Ohta -
ML -
Måns Nilsson -
Nate Davis -
Octavio Alvarez -
Owen DeLong -
Randy Bush -
Robert E. Seastrom -
Tim Chown -
Valdis.Kletnieks＠vt.edu -
William Herrin