Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Joel Jaeggli]

On Jul 10, 2011, at 11:57 PM, William Herrin wrote:

> On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong  wrote:
>> On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
>>> Consider, for example, RFC 3484. That's the one that determines how an
>>> IPv6 capable host selects which of a group of candidate IPv4 and IPv6
>>> addresses for a particular host name gets priority. How is a server's
>>> address priority NOT an issue that should be managed at an operations
>>> level by individual server administrators? Yet the working group which
>>> produced it came up with a static prioritization that is the root
>>> cause of a significant portion of the IPv6 deployment headaches we
>>> face.
>>> 
>> 3484 specifies a static default. By definition, defaults in absence of
>> operator configuration kind of have to be static. Having a reasonable
>> and expected set of defaults documented in an RFC provides a known
>> quantity for what operators can/should expect from hosts they have
>> not configured. I see nothing wrong with RFC 3484 other than I would
>> agree that the choices made were suboptimal. Mostly that was based
>> on optimism and a lack of experience available at the time of writing.
> 
> Hi Owen,
> 
> A more optimal answer would have been to make  records more like
> MX or SRV records -- with explicit priorities the clients are
> encouraged to follow. I wasn't there but I'd be willing to bet there
> was a lonely voice in the room saying, hey, this should be controlled
> by the sysadmin. A lonely voice that got shouted down.

Give me a break... multiple implementations have chosen to tweak the algorithm 
independently and at various times.

It's just an rfc, not the gospel according to richard draves.

"
   Acknowledgments

   The author would like to acknowledge the contributions of the IPng
   Working Group, particularly Marc Blanchet, Brian Carpenter, Matt
   Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun
   Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik
   Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman,
   Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas.  In
   addition, the anonymous IESG reviewers had many great comments and
   suggestions for clarification.
" 

> 
>>> Today's RFC candidates are required to call out IANA considerations
>>> and security considerations in special sections. They do so because
>>> each of these areas has landmines that the majority of working groups
>>> are ill equipped to consider on their own.
>>> 
>>> There should be an operations callout as well -- a section where
>>> proposed operations defaults (as well as statics for which a solid
>>> case can be made for an operations tunable) are extracted from the
>>> thick of it and offered for operator scrutiny prior to publication of
>>> the RFC.
>> 
>> I think this would be a good idea, actually. It would probably be more
>> effective to propose it to IETF than to NANOG, however.
> 
> If the complaint is that the IETF doesn't adequately listen to the
> operations folk, then I think it makes sense to consult the operations
> folks early and often on potential fixes. If folks here think it would
> help, -that- is when I'll it to the IETF.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
> 
> 

Re: Why is IPv6 broken?

[Tom Hill]

On Sun, 2011-07-10 at 10:14 -0400, Jeff Wheeler wrote:
> Cogent's policy of requiring a new contract, and from what I am still
> being told by some European customers, new money, from customers in
> exchange for provisioning IPv6 on existing circuits, means a simple
> technical project gets caught up in the complexities of budgeting and
> contract execution.

"Can we have IPv6 transit?"
"Yes, please turn up a session to.."

That was asking Cogent for IPv6 dual-stack on our existing IPv4
transit. 

I'm not saying it's any good, but it certainly didn't cost extra.

Tom

Re: Why is IPv6 broken?

[Nick Hilliard]

On 11/07/2011 08:25, Tom Hill wrote:
> I'm not saying it's any good, but it certainly didn't cost extra.

Several people mentioned this to Jeff on IRC a short time ago, so it's not
clear why he chose to suggest that ipv6 users in Europe were being fleeced
by Cogent for a set-up fee.  Perhaps it has happened, but it appears not to
be their policy.

Of course, if you actually want a full ipv6 table, you will need to go
elsewhere.

Nick

Re: Why is IPv6 broken?

[Jeff Wheeler]

On Mon, Jul 11, 2011 at 3:25 AM, Tom Hill  wrote:
> On Sun, 2011-07-10 at 10:14 -0400, Jeff Wheeler wrote:
>> Cogent's policy of requiring a new contract, and from what I am still
>> being told by some European customers, new money, from customers in
>> exchange for provisioning IPv6 on existing circuits, means a simple
>> technical project gets caught up in the complexities of budgeting and
>> contract execution.
>
> "Can we have IPv6 transit?"
> "Yes, please turn up a session to.."
>
> That was asking Cogent for IPv6 dual-stack on our existing IPv4
> transit.

I continue to hear different.  In my first-hand experience just about
three weeks ago, I was told by Cogent that I need to execute a new
contract to get IPv6 added to an existing IPv4 circuit (U.S.
customer.)  This turned a simple pilot project with only a few I.T.
folks involved into, well, I'm still waiting on this new contract to
be executed.  I'm not surprised.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Mikael Abrahamsson]

On Mon, 11 Jul 2011, William Herrin wrote:

If the complaint is that the IETF doesn't adequately listen to the 
operations folk, then I think it makes sense to consult the operations 
folks early and often on potential fixes. If folks here think it would 
help, -that- is when I'll it to the IETF.


I started participating in the IETF 1-2 years ago. Coming from Fidonet 
background, the threshold of entry felt very low, as long as you make any 
kind of sense, people will discuss with you there and it doesn't matter 
who you are. You don't even have to go to the meetings (I've only been to 
a single one).


I encourage everybody to participate, at least to subscribe to the WG 
mailing lists and keep a look out for the draft announcements and give 
feedback to those.


If we in the ISP business don't do this, the show will be run by the 
vendors and academics (as is the case right now). They're saying "come to 
us", you're saying "come to us", and as long as both do this the rate of 
communication is going to be limited. What is needed is more people with 
operational backgrounds. For instance, I pitched the idea that ended up as 
a draft, dunno what will come of it:




This has purely operational background and the puritans didn't like it 
(they didn't even understand why one would want to do it like that), but 
after a while I feel I received some traction and it might actually end up 
as a protocol enhancement that will help some ISPs in their daily work. 
Even something like your IGP isn't "done", and can be enhanced even if it 
takes time.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Why is IPv6 broken?

[Tom Hill]

On Mon, 2011-07-11 at 04:50 -0400, Jeff Wheeler wrote:
> > "Can we have IPv6 transit?"
> > "Yes, please turn up a session to.."
> >
> > That was asking Cogent for IPv6 dual-stack on our existing IPv4
> > transit.
> 
> I continue to hear different.  In my first-hand experience just about
> three weeks ago, I was told by Cogent that I need to execute a new
> contract to get IPv6 added to an existing IPv4 circuit (U.S.
> customer.)  This turned a simple pilot project with only a few I.T.
> folks involved into, well, I'm still waiting on this new contract to
> be executed.  I'm not surprised.

In fairness, we have a small commit. 

If you're talking multi-gigabit+, then perhaps they could be a little
more concerned about the amount of IPv6 traffic that you might start
pushing, leading to delay tactics and/or a required contract change to
protect themselves.

(Not that it's likely much to be concerned about. But then, I don't know
who your customer is. ;))

Or the more likely reality that one hand doesn't talk to the other and
everyone's getting varying answers/actions from Cogent, depending on
whom they speak with.

Tom

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Owen DeLong]

Sent from my iPad

On Jul 11, 2011, at 2:57, William Herrin  wrote:

> On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong  wrote:
>> On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
>>> Consider, for example, RFC 3484. That's the one that determines how an
>>> IPv6 capable host selects which of a group of candidate IPv4 and IPv6
>>> addresses for a particular host name gets priority. How is a server's
>>> address priority NOT an issue that should be managed at an operations
>>> level by individual server administrators? Yet the working group which
>>> produced it came up with a static prioritization that is the root
>>> cause of a significant portion of the IPv6 deployment headaches we
>>> face.
>>> 
>> 3484 specifies a static default. By definition, defaults in absence of
>> operator configuration kind of have to be static. Having a reasonable
>> and expected set of defaults documented in an RFC provides a known
>> quantity for what operators can/should expect from hosts they have
>> not configured. I see nothing wrong with RFC 3484 other than I would
>> agree that the choices made were suboptimal. Mostly that was based
>> on optimism and a lack of experience available at the time of writing.
> 
> Hi Owen,
> 
> A more optimal answer would have been to make  records more like
> MX or SRV records -- with explicit priorities the clients are
> encouraged to follow. I wasn't there but I'd be willing to bet there
> was a lonely voice in the room saying, hey, this should be controlled
> by the sysadmin. A lonely voice that got shouted down.
> 

Uh, right, because the average system administrator wants the remote host
telling his systems which address to prefer? Besides, that would have been
DESTINATION address selection, not source address selection which isn't
what we're talking about.

I wasn't there either, but, it _IS_ controlled by the sysadmin. There are 
defaults
in case the sysadmin is asleep at the switch (RFC 3484) and there are handles
and knobs for the sysadmin to tune if he wants (the other RFC that I referred 
you
to).

> 
>>> Today's RFC candidates are required to call out IANA considerations
>>> and security considerations in special sections. They do so because
>>> each of these areas has landmines that the majority of working groups
>>> are ill equipped to consider on their own.
>>> 
>>> There should be an operations callout as well -- a section where
>>> proposed operations defaults (as well as statics for which a solid
>>> case can be made for an operations tunable) are extracted from the
>>> thick of it and offered for operator scrutiny prior to publication of
>>> the RFC.
>> 
>> I think this would be a good idea, actually. It would probably be more
>> effective to propose it to IETF than to NANOG, however.
> 
> If the complaint is that the IETF doesn't adequately listen to the
> operations folk, then I think it makes sense to consult the operations
> folks early and often on potential fixes. If folks here think it would
> help, -that- is when I'll it to the IETF.
> 

I think it would help. Hopefully others will express similar sentiment.

Owen

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Mon, Jul 11, 2011 at 3:08 AM, Joel Jaeggli  wrote:
> On Jul 10, 2011, at 11:57 PM, William Herrin wrote:
>> A more optimal answer would have been to make  records more like
>> MX or SRV records -- with explicit priorities the clients are
>> encouraged to follow. I wasn't there but I'd be willing to bet there
>> was a lonely voice in the room saying, hey, this should be controlled
>> by the sysadmin. A lonely voice that got shouted down.
>
> Give me a break... multiple implementations have chosen to tweak the 
> algorithm independently and at various times.
>
> It's just an rfc, not the gospel according to richard draves.
>
> "
>   Acknowledgments
>
>   The author would like to acknowledge the contributions of the IPng
>   Working Group, particularly Marc Blanchet, Brian Carpenter, Matt
>   Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun
>   Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik
>   Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman,
>   Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas.  In
>   addition, the anonymous IESG reviewers had many great comments and
>   suggestions for clarification.
> "

Joel,

I am giving you a break. Instead of calling this list of folks to the
carpet over a failure of imagination that by the time we've
ubiquitously deployed IPv6 will have been the root cause of billions
if not tens of billions of dollars in needless industry expense, I'm
trying to move the discussion past the errors and focus on ways to
help the next team of smart, selfless and dedicated individuals avoid
sullying their results with a similar mistake.

Denial keeps the discussion focused on the errors. You don't want that
and neither do I.


 Today's RFC candidates are required to call out IANA considerations
 and security considerations in special sections. They do so because
 each of these areas has landmines that the majority of working groups
 are ill equipped to consider on their own.

 There should be an operations callout as well -- a section where
 proposed operations defaults (as well as statics for which a solid
 case can be made for an operations tunable) are extracted from the
 thick of it and offered for operator scrutiny prior to publication of
 the RFC.

Do you find this adjustment objectionable? Do you have other fresh
ideas to float? Something better than the tired refrain about
operators not showing up?

'Cause I have to tell you: Several years ago I picked a working group
and I showed up. And I faced and lost the argument against the
persistent certainty on the workability of ridiculous deployment
scenarios by folks who never managed any system larger than a software
development lab. And I stopped participating in the group about a year
ago as the core of participants who hadn't given up wandered off into
la la land.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Joel Jaeggli]

On Jul 11, 2011, at 8:13 AM, William Herrin wrote:

> 
> 
> Today's RFC candidates are required to call out IANA considerations
> and security considerations in special sections. They do so because
> each of these areas has landmines that the majority of working groups
> are ill equipped to consider on their own.
> 
> There should be an operations callout as well -- a section where
> proposed operations defaults (as well as statics for which a solid
> case can be made for an operations tunable) are extracted from the
> thick of it and offered for operator scrutiny prior to publication of
> the RFC.
> 
> Do you find this adjustment objectionable? Do you have other fresh
> ideas to float? Something better than the tired refrain about
> operators not showing up?

The operations area has a directorate. It reviews basically every draft in 
front of the IESG.

I'm on it.

Am I not an operator?

Do I think that adding yet another required section to an internet draft is 
going to increase it's quality? 

No I do not.

> 'Cause I have to tell you: Several years ago I picked a working group
> and I showed up. And I faced and lost the argument against the
> persistent certainty on the workability of ridiculous deployment
> scenarios by folks who never managed any system larger than a software
> development lab. And I stopped participating in the group about a year
> ago as the core of participants who hadn't given up wandered off into
> la la land.



> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
> 

AOL security contact?

[Chris]

Anyone have an AOL security contact because like I posted yesterday,
CNN was hit through a redirect vulnerability in their ad system and
now AOL is suffering the same thing by having some scammer serving up
"Casey Anthony leaked lawyer video" crap as Facebook spam where
unsuspecting lusers are clicking like wild on it

-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton

Re: AOL security contact?

[Jay Ashworth]

- Original Message -
> From: "Chris" 

> Anyone have an AOL security contact because like I posted yesterday,
> CNN was hit through a redirect vulnerability in their ad system and
> now AOL is suffering the same thing by having some scammer serving up
> "Casey Anthony leaked lawyer video" crap as Facebook spam where
> unsuspecting lusers are clicking like wild on it

My recommendation to anyone from Facebook who's listening here:

Block the whole damn domain.  That will get them to contact you.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: AOL security contact?

[Chris]

I tried doma...@aol.net, which I got when I did a whois on the IP of
the affected domain, then hit noc@ and ab...@aol.com

I fired off an email to iWeb, who is hosting the scam site and is
notorious for lack of response, and GoDaddy.

My recommendation to anyone: start blocking .info like how Google delisted co.cc

On Mon, Jul 11, 2011 at 12:13 PM, Jay Ashworth  wrote:
> - Original Message -
>> From: "Chris" 
>
>> Anyone have an AOL security contact because like I posted yesterday,
>> CNN was hit through a redirect vulnerability in their ad system and
>> now AOL is suffering the same thing by having some scammer serving up
>> "Casey Anthony leaked lawyer video" crap as Facebook spam where
>> unsuspecting lusers are clicking like wild on it
>
> My recommendation to anyone from Facebook who's listening here:
>
> Block the whole damn domain.  That will get them to contact you.  :-)
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink                       
> j...@baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>
>



-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton

Re: AOL security contact?

[Jay Moran]

Chris,

Did you not get my direct email to you? I included the email address there,
here it is again for yourself and others who need to report a security
vulnerability with an AOL property.

secvuln
at
aol
dot
net

Jay
--
Jay Moran
http://tp.org/jay


On Mon, Jul 11, 2011 at 12:42 PM, Chris  wrote:

> I tried doma...@aol.net, which I got when I did a whois on the IP of
> the affected domain, then hit noc@ and ab...@aol.com
>
> I fired off an email to iWeb, who is hosting the scam site and is
> notorious for lack of response, and GoDaddy.
>
> My recommendation to anyone: start blocking .info like how Google delisted
> co.cc
>
> On Mon, Jul 11, 2011 at 12:13 PM, Jay Ashworth  wrote:
> > - Original Message -
> >> From: "Chris" 
> >
> >> Anyone have an AOL security contact because like I posted yesterday,
> >> CNN was hit through a redirect vulnerability in their ad system and
> >> now AOL is suffering the same thing by having some scammer serving up
> >> "Casey Anthony leaked lawyer video" crap as Facebook spam where
> >> unsuspecting lusers are clicking like wild on it
> >
> > My recommendation to anyone from Facebook who's listening here:
> >
> > Block the whole damn domain.  That will get them to contact you.  :-)
> >
> > Cheers,
> > -- jra
> > --
> > Jay R. Ashworth  Baylink
> j...@baylink.com
> > Designer The Things I Think   RFC
> 2100
> > Ashworth & Associates http://baylink.pitas.com 2000 Land
> Rover DII
> > St Petersburg FL USA  http://photo.imageinc.us +1 727
> 647 1274
> >
> >
>
>
>
> --
> --C
>
> "The dumber people think you are, the more surprised they're going to
> be when you kill them." - Sir William Clayton
>
>

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli  wrote:
> On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
>> Today's RFC candidates are required to call out IANA considerations
>> and security considerations in special sections. They do so because
>> each of these areas has landmines that the majority of working groups
>> are ill equipped to consider on their own.
>>
>> There should be an operations callout as well -- a section where
>> proposed operations defaults (as well as statics for which a solid
>> case can be made for an operations tunable) are extracted from the
>> thick of it and offered for operator scrutiny prior to publication of
>> the RFC.
>>
>> Do you find this adjustment objectionable? Do you have other fresh
>> ideas to float? Something better than the tired refrain about
>> operators not showing up?
>
> The operations area has a directorate. It reviews basically every draft in 
> front of the IESG.
> I'm on it.
> Am I not an operator?

Well, you work at Zynga, a company which makes facebook games. Before
that you worked at Nokia, company which makes phones but doesn't run
phone networks. Before that it was Check Point Software, a company
which makes firewalls but doesn't run networks. And before that it was
the University of Oregon.

Do you believe any of those roles offered you the perspective you'd
gain working for an ISP, telco or MSO?

Are you not an operator? Sure, why not. It's a big tent. Are you well
qualified to represent operator interests before the IETF? You really
haven't been speaking to the issues I had to deal with when I led an
ISP and you've expressed little respect for the validity of issues I
face now. But you do show up.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Darrel Lewis]

> \
> I have found my input on the LISP list completely ignored because, as
> you suggest, my concerns are real-world and don't have any impact on
> someone's pet project.  LISP as it stands today can never work on the
> Internet, and regardless of the fine reputations of the people at
> Cisco and other organizations who are working on it, they are either
> furthering it only because they would rather work on a pet project
> than something useful to customers, or because they truly cannot
> understand its deep, insurmountable design flaws at Internet-scale.
> You would generally hope that someone saying, "LISP can't work at
> Internet-scale because anyone will be able to trivially DoS any LISP
> ITR ('router' for simplicity), but here is a way you can improve it,"
> well, that remark, input, and person should be taken quite seriously,
> their input examined, and other assumptions about the way LISP is
> supposed to work ought to be questioned.  None of this has happened.


Jeff I've spend many hours working through the issues you brought up (indeed 
cache management, population, and security are three of my focus areas in LISP, 
and something we considered when we started this), have been socializing them 
with the LISP team, and can personally say that I take your comments very 
seriously.  Or testing group in house as well as on the LISP beta network have 
been working through these issues.  Also, we've had an email thread going on 
about this for, by my count, 3-4 replies back and forth.

While I appreciate your opinions above, I have to say that I disagree with 
them, and also with the conclusions you draw.

-Darrel

P.S. oh and Randy Bush is pretty damn smart. :-)

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Allen Simpson]

On 7/10/11 6:29 PM, Randy Bush wrote:

The IETF is run by volunteers. They volunteer because they find
designing protocols to be fun. For the most part, operators are not
entertained by designing network protocols. So, for the most part they
don't partiticpate.


Randy Bush, "Editorial zone: Into the Future with the Internet Vendor
Task Force: a very curmudgeonly view, or testing spaghetti," ACM SIGCOMM
Computer Communication Review Volume 35 Issue 5, October 2005.
http://archive.psg.com/051000.ccr-ivtf.html


I agree with Randy.  Well, that's no surprise, I usually agree with
Randy.  But I didn't know/remember that he'd managed to get his rant
published!  Good work

But the problem has been pretty apparent since circa 1991.  I remember
calls for an Internet Operator's Task Force (IOTF) to parallel IETF
sometime in '92 or '93.

Folks have asked me from time to time why I stopped participating in the
IETF a decade or so ago.  My usual tongue-in-cheek reply is, "it's more
important to use the protocols we already have before we build more."
(CF. nukes.)

IPv6 was certainly a part of it (as was security).  As I remind folks
from time to time, I'm the guy that originally registered v6 with IANA.
But PIPE->SIP->SIPP was a much simpler, shorter, cleaner extension using
64-bit addresses.  My proposal used the upper 32-bits extending the then
16-bit BGP ASN, making addresses match topology, shrinking the routing
tables

Although I *do* find designing protocols to be fun, these days I only
post Experimental drafts.  There are committees (dysfunctional "working
groups") where the chair cannot get his own drafts through the process
in under 4 years.  It took about 7 years to publish the group
negotiation extension to SSH, many years after it was shipping.

It's no wonder that operators don't want to participate.

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli  wrote:
> On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
>> Today's RFC candidates are required to call out IANA considerations
>> and security considerations in special sections. They do so because
>> each of these areas has landmines that the majority of working groups
>> are ill equipped to consider on their own.
>>
>> There should be an operations callout as well -- a section where
>> proposed operations defaults (as well as statics for which a solid
>> case can be made for an operations tunable) are extracted from the
>> thick of it and offered for operator scrutiny prior to publication of
>> the RFC.
>>
>> Do you find this adjustment objectionable?
>
> Do I think that adding yet another required section to an
> internet draft is going to increase it's quality?
> No I do not.

Joel,

You may be right. Calling out IANA considerations doesn't seem to have
made the IETF any smarter on the shared ISP IPv4 space. And I have no
idea if calling out security implications has helped reduce
security-related design flaws.

On the other hand, calling out ops issues in RFCs is a modest reform
that at worst shouldn't hurt anything. That beats my next best idea:
asking the ops area to schedule its meetings with the various NOG
meetings instead of with the rest of the IETF so that the attendance
is ops who dabble in development instead of developers who dabble in
ops.

You disagree? What are your thoughts on fixing the problem?

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Hello List, a easy Cisco question.

[bill]

   Hello,

   I am not a heads down network guy, but I have setup a few
   firewalls, and have got them to do what I wanted, "eventually". But
   mostly through reading and trial and error.

   I am struggling with this one, but I think I know the answer, but
   want to verify it with some experts.



   We have a cisco asa 5505, with an internet connection with only one
   useable ip address (subnet 255.255.255.252). We/they have had a nat
   setup for outgoing connections for some time, but I have been trying to
   get a new inbound connection going for terminal services to a specific
   host on tcp port 3389. I'm using "ASDM" but checking the config file
   and it's building the correct static statement, and access lists (I
   think anyway). But It doesn't work, and doesn't give a real good
   definative log message. I was wondering if possibly the fact that nat
   is using the one ip address, if that precludes the static mapping from
   working.



   I've read several step by steps, and again had this working several
   other places, but always with more ip's. If having just one ip isn't
   the isssue, is there any other issues I should be looking for.



   I'd appreciate any insight you might share.



   Thanks in advance

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Leo Bicknell]

In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar 
wrote:
> Eh ANYBODY, including you, can sign up to the IETF mailing lists and
> participate there, just like a couple of folks from NANOG are already doing.

The way the IETF and the operator community interact is badly broken.

The IETF does not want operators in many steps of the process.  If
you try to bring up operational concerns in early protocol development
for example you'll often get a "we'll look at that later" response,
which in many cases is right.  Sometimes you just have to play with
something before you worry about the operational details.  It also
does not help that many operational types are not hardcore programmers,
and can't play in the sandbox during the major development cycles.

But this shuts out operators and discourages them from participating
when they are needed, which is at the idea phase and towards the
end of development.

If the IETF really wanted to get useful operator impact, they would
slightly modify their process.  On the front end there would be a
more clear way for operational types to add to the To-Do list "stuff
we really need to make the Internet work better".  Then, some sausage
would be made largely without operator involvement (but hey, if you
want to participate no exclusions), and then when developmen is
about 80-90% done there would be an "operational testing and comment
period".  Operators would be actively brought back in the process
to test some small scale deployments and provide feedback of
operational concerns that might lead to some tweaks, and then boom,
out the door it goes.

I suspect this would both increase operator participation by a few
orders of magnitude, and also keep the operators from annoying the
developers so much when they are in "trying things out" mode.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpGFY3IVVPMN.pgp
Description: PGP signature

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Jeff Wheeler]

On Mon, Jul 11, 2011 at 3:18 PM, William Herrin  wrote:
> On the other hand, calling out ops issues in RFCs is a modest reform
> that at worst shouldn't hurt anything. That beats my next best idea:

I think if this were done, some guy like me would spend endless hours
arguing with others about what should and should not be documented in
this proposed section, without it actually benefiting the process or
the improving the underlying protocol function / specification.  Let
me give you an example:

BGP Messages, which are up to 4KB, need to be expanded to support
future features like as-path signing.  Randy Bush proposes to extend
them to 65,535 octets, the maximum size without significantly changing
the message header.  This raises a few concerns which I label as
operational, for example, off-by-one bugs in code can fail to be
detected by a neighboring BGP speaker in some circumstances, because
an age-old (since BGP 1) idiot check in the protocol is being silently
removed.

If you ask me, that is operational and belongs in such a section.  I'm
sure others will disagree.  So we would have a bunch of arguing over
whether or not to call this out specifically.

Another person believes that expanding the message will affect some
vendors' custom TCP stacks, due to window size considerations.  I
might think that is a developer problem and the affected vendors
should fix their crappy TCP implementations, but it might produce
unusual stalling problems, etc. which operators have to troubleshoot.
Is that an operational issue?  Should it be documented?

There can be many "operational concerns" when creating or modifying a
protocol specification, and every person won't agree on what belongs
and what doesn't.  However, I do not think the requirement to document
them will improve the process or the protocols.  It will only add
work.

Besides, you want "IETF people" who are claimed not to understand
operational problems to figure them out and document them in the RFCs?
 I do not think this will be helpful.  More hands-on operators
participating in their process is what is needed.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Jeff Wheeler]

On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell  wrote:
> The IETF does not want operators in many steps of the process.  If
> you try to bring up operational concerns in early protocol development
> for example you'll often get a "we'll look at that later" response,
> which in many cases is right.  Sometimes you just have to play with
> something before you worry about the operational details.  It also

I really don't understand why that is right / good.  People get
personally invested in their project / spec, and not only that, vendor
people get their company's time and money invested in
proof-of-concept.  The longer something goes on with what may be
serious design flaws, the harder it is to get them fixed, simply
because of momentum.

Wouldn't it be nice if we could change the way that next-header works
in IPv6 now?  Or get rid of SLAAC and erase the RFCs recommending /80
and /64 from history?

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

RE: Hello List, a easy Cisco question.

[bill]

Hello,

   We have Nat setup on our equipment, just a plain vanilla internet
   connection.



   Here is the pertinent section of the runing config.



   !
   interface Ethernet0/2
nameif Etherpoint
security-level 0
ip address outside-ip 255.255.255.252
ospf cost 10
   !

   object-group service terminal-services tcp
port-object eq 3389
   access-list Inside_access_in extended permit icmp any any
   access-list Inside_access_in extended permit ip 192.168.125.0
   255.255.255.0 any
   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
   255.255.255.0 MobileVPN 255.255.255.0
   access-list Inside_nat0_outbound extended permit ip 192.168.0.0
   255.255.255.0 MobileVPN 255.255.255.0 inactive
   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
   255.255.255.0 any inactive
   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
   255.255.255.0 192.168.1.0 255.255.255.0
   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
   255.255.255.0 192.168.14.0 255.255.255.0
   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
   255.255.255.0 192.168.100.0 255.255.255.0
   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
   255.255.255.0 192.168.101.0 255.255.255.0
   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
   255.255.255.0 192.168.253.0 255.255.255.0
   access-list Haven_splitTunnelAcl_1 standard permit 192.168.125.0
   255.255.255.0
   access-list Etherpoint_access_in extended permit tcp host 192.168.125.8
   eq 3389 any eq 3389
   access-list Etherpoint_access_in extended permit tcp any eq 3389 host
   192.168.125.8 eq 3389
   access-list Etherpoint_access_in extended permit tcp any host
   192.168.125.8 eq 3389
   access-list Etherpoint_nat0_outbound extended permit ip host
   192.168.125.8 host outside-ip
   access-list Etherpoint_nat0_outbound extended permit ip host outside-ip
   host 192.168.125.8

   ip local pool HavenVPN 192.168.253.1-192.168.253.254 mask 255.255.255.0

   global (Etherpoint) 2 interface

   nat (Inside) 0 access-list Inside_nat0_outbound
   nat (Inside) 2 192.168.125.0 255.255.255.0
   nat (Etherpoint) 0 access-list Etherpoint_nat0_outbound outside
   static (Inside,Etherpoint) tcp interface 3389 192.168.125.8 3389
   netmask 255.255.255.255

   no threat-detection statistics tcp-intercept
   access-group Inside_access_in in interface Inside
   access-group Etherpoint_access_in in interface Etherpoint

   route Etherpoint 0.0.0.0 0.0.0.0 204.186.102.187 1



    Original Message 
   Subject: Re: Hello List, a easy Cisco question.
   From: Dennis <[1]daoden...@gmail.com>
   Date: Mon, July 11, 2011 12:39 pm
   To: [2]b...@kruchas.com
   On Mon, Jul 11, 2011 at 12:33 PM, <[3]b...@kruchas.com> wrote:
   >   Hello,
   >
   >   I am not a heads down network guy, but I have setup a few
   >   firewalls, and have got them to do what I wanted, "eventually". But
   >   mostly through reading and trial and error.
   >
   >   I am struggling with this one, but I think I know the answer,
   but
   >   want to verify it with some experts.
   >
   >
   >
   >   We have a cisco asa 5505, with an internet connection with only
   one
   >   useable ip address (subnet 255.255.255.252). We/they have had a nat
   >   setup for outgoing connections for some time, but I have been
   trying to
   So your provider has your ASA behind a NAT or there is a NAT
   inside,outside statement on your ASA?
   Some more pieces of the configuration would be helpful here too.
   Thanks,
   Dennis O.

References

   1. mailto:daoden...@gmail.com
   2. mailto:b...@kruchas.com
   3. mailto:b...@kruchas.com

RE: Hello List, a easy Cisco question.

[bill]

   Hello,

   I believe I have setup the appropriate access-lists, even have
   created it both ways in case I have the inside and outside reversed.

   The packet trace always drops through and hits the implicit rule
   which is deny everything. No matter how I have the access list setup. I
   have tried it several ways, and also included the nat exclude
   statement, but the current config doesn't have that listed anymore as I
   wanted to try to keep the config as clean as I can, but if the exclude
   is needed I can certainly add it. But none on the examples used it.



    Original Message 
   Subject: Re: Hello List, a easy Cisco question.
   From: James Laszko <[1]jam...@mythostech.com>
   Date: Mon, July 11, 2011 1:02 pm
   To: "[2]b...@kruchas.com" <[3]b...@kruchas.com>
   Have you setup the appropriate access rule along with the NAT?
   The packet trace button is useful in testing as well...
   Regards,
   James Laszko
   Mythos Technology Inc
   [4]jam...@mythostech.com
   - Original Message -
   From: [5]b...@kruchas.com [[6]mailto:b...@kruchas.com]
   Sent: Monday, July 11, 2011 12:33 PM
   To: nanog <[7]nanog@nanog.org>
   Subject: Hello List, a easy Cisco question.
   Hello,
   I am not a heads down network guy, but I have setup a few
   firewalls, and have got them to do what I wanted, "eventually". But
   mostly through reading and trial and error.
   I am struggling with this one, but I think I know the answer, but
   want to verify it with some experts.
   We have a cisco asa 5505, with an internet connection with only one
   useable ip address (subnet 255.255.255.252). We/they have had a nat
   setup for outgoing connections for some time, but I have been trying to
   get a new inbound connection going for terminal services to a specific
   host on tcp port 3389. I'm using "ASDM" but checking the config file
   and it's building the correct static statement, and access lists (I
   think anyway). But It doesn't work, and doesn't give a real good
   definative log message. I was wondering if possibly the fact that nat
   is using the one ip address, if that precludes the static mapping from
   working.
   I've read several step by steps, and again had this working several
   other places, but always with more ip's. If having just one ip isn't
   the isssue, is there any other issues I should be looking for.
   I'd appreciate any insight you might share.
   Thanks in advance

References

   1. mailto:jam...@mythostech.com
   2. mailto:b...@kruchas.com
   3. mailto:b...@kruchas.com
   4. mailto:jam...@mythostech.com
   5. mailto:b...@kruchas.com
   6. mailto:b...@kruchas.com
   7. mailto:nanog@nanog.org

Mediacom Communications Corporation contact available?

[Eric Tykwinski]

Looking for a NOC contact if there are any available.

 

Sincerely,

 

Eric Tykwinski

TrueNet, Inc.

P: 610-429-8300

F: 610-429-3222

 

Re: Hello List, a easy Cisco question.

[Michael Holstein]

>setup for outgoing connections for some time, but I have been trying to
>get a new inbound connection going for terminal services to a specific
>host on tcp port 3389.

It sounds like what you want to do is reverse PAT (aka "Policy NAT")

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008046f31a.shtml#t10

Are you familiar with the CLI or do you strictly use the GUI? .. you'll
find the former is much more common.

Cheers,

Michael Holstein
Cleveland State Unviersity

RE: Hello List, a easy Cisco question.

[bill]

   Thank You all,

   Here are some of the suggestions so far, all good. And I will followup
   on them and report back the final solution.

   Some reading for tonite ( I already had it and skimmed thru, but I'll
   need to digest it better).

   I'm hoping that I'm not beating my head against the wall using Nat
   instead of Pat, and not sure if Pat would be acceptable.



   Anyway, thanks again.



   Bill



   **

   Hey Bill,
   I don't think you can do a static NAT translation on a NAT egress IP
   address. Have you considered using Port Address Translation instead?
   Cheers,
   Taylor



As per [1]http://www.nanog.org/mailinglist/listfaqs/otherlists.php,
   since
   I don't see any responses to the list here, you'll probably get a more
   comprehensive reply from real Cisco experts at
   [2]http://puck.nether.net/mailman/listinfo/cisco-nsp
   I hope you get the problem solved!
   Whatever happens, do post back a reply to the list saying what solved
   the problem in the end.
   Alex

    Original Message 
   Subject: RE: Hello List, a easy Cisco question.
   From: "Eric Tykwinski" <[3]eric-l...@truenet.com>
   Date: Mon, July 11, 2011 12:47 pm
   To: <[4]b...@kruchas.com>
   Bill,
   Sounds like you need to use Port Address Translation (PAT), instead of
   Network Address Translation (NAT).
   Here's a Cisco help file for it:
   [5]http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_
   note09186a00804708b4.shtml
   Sincerely,
   Eric Tykwinski
   TrueNet, Inc.
   P: 610-429-8300
   F: 610-429-3222
   -Original Message-
   From: [6]b...@kruchas.com [[7]mailto:b...@kruchas.com]
   Sent: Monday, July 11, 2011 3:34 PM
   To: nanog
   Subject: Hello List, a easy Cisco question.
   Hello,
   I am not a heads down network guy, but I have setup a few
   firewalls, and have got them to do what I wanted, "eventually". But
   mostly through reading and trial and error.
   I am struggling with this one, but I think I know the answer, but
   want to verify it with some experts.
   We have a cisco asa 5505, with an internet connection with only one
   useable ip address (subnet 255.255.255.252). We/they have had a nat
   setup for outgoing connections for some time, but I have been trying to
   get a new inbound connection going for terminal services to a specific
   host on tcp port 3389. I'm using "ASDM" but checking the config file
   and it's building the correct static statement, and access lists (I
   think anyway). But It doesn't work, and doesn't give a real good
   definative log message. I was wondering if possibly the fact that nat
   is using the one ip address, if that precludes the static mapping from
   working.
   I've read several step by steps, and again had this working several
   other places, but always with more ip's. If having just one ip isn't
   the isssue, is there any other issues I should be looking for.
   I'd appreciate any insight you might share.
   Thanks in advance

References

   1. http://www.nanog.org/mailinglist/listfaqs/otherlists.php
   2. http://puck.nether.net/mailman/listinfo/cisco-nsp
   3. mailto:eric-l...@truenet.com
   4. mailto:b...@kruchas.com
   5. 
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00804708b4.shtml
   6. mailto:b...@kruchas.com
   7. mailto:b...@kruchas.com

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Joel Jaeggli]

On Jul 11, 2011, at 12:18 PM, William Herrin wrote:

> On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli  wrote:
>> On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
>>> Today's RFC candidates are required to call out IANA considerations
>>> and security considerations in special sections. They do so because
>>> each of these areas has landmines that the majority of working groups
>>> are ill equipped to consider on their own.
>>> 
>>> There should be an operations callout as well -- a section where
>>> proposed operations defaults (as well as statics for which a solid
>>> case can be made for an operations tunable) are extracted from the
>>> thick of it and offered for operator scrutiny prior to publication of
>>> the RFC.
>>> 
>>> Do you find this adjustment objectionable?
>> 
>> Do I think that adding yet another required section to an
>> internet draft is going to increase it's quality?
>> No I do not.
> 
> Joel,
> 
> You may be right. Calling out IANA considerations doesn't seem to have
> made the IETF any smarter on the shared ISP IPv4 space. And I have no
> idea if calling out security implications has helped reduce
> security-related design flaws.
> 
> On the other hand, calling out ops issues in RFCs is a modest reform
> that at worst shouldn't hurt anything.

To my mind, one of the really good criterion for an operational considerations 
document is some actual experience running it.

> That beats my next best idea:
> asking the ops area to schedule its meetings with the various NOG
> meetings instead of with the rest of the IETF so that the attendance
> is ops who dabble in development instead of developers who dabble in
> ops.

The OPS area works on OPS and Management. Protocol development of the sort 
you're describing generally occurs in working-groups chartered in the Internet 
or Routing areas... 

At least one of the ops chairs are on this list attends nanog regularly etc. 
Participants, especially those that actually do the work are the important part 
as far as I'm concerned. Rough consensus is an ugly an imperfect business, it 
should be recognized that not everyone is going to come away from every 
exchange with what they want.

> You disagree? What are your thoughts on fixing the problem?

I'm not sure that we agree on the dimensions of the problem.

on the question of ipv6 is broken:

* You're going to have to cope with what you have and can squeeze out of 
vendors in the near term. implmentors don't change that fast.
* People have to show up with the problem statement and stick around to do the 
work
* the outcomes are not always pretty.

I hope that my time is productively employed.

http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00

> Regards,
> Bill Herrin
> 
> 
> -- 
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
> 

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Owen DeLong]

On Jul 11, 2011, at 12:57 PM, Jeff Wheeler wrote:

> On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell  wrote:
>> The IETF does not want operators in many steps of the process.  If
>> you try to bring up operational concerns in early protocol development
>> for example you'll often get a "we'll look at that later" response,
>> which in many cases is right.  Sometimes you just have to play with
>> something before you worry about the operational details.  It also
> 
> I really don't understand why that is right / good.  People get
> personally invested in their project / spec, and not only that, vendor
> people get their company's time and money invested in
> proof-of-concept.  The longer something goes on with what may be
> serious design flaws, the harder it is to get them fixed, simply
> because of momentum.
> 
> Wouldn't it be nice if we could change the way that next-header works
> in IPv6 now?  Or get rid of SLAAC and erase the RFCs recommending /80
> and /64 from history?
> 

No... I like SLAAC and find it useful in a number of places. What's wrong
with /64? Yes, we need better DOS protection in switches and routers
to accommodate some of the realities of those decisions, but, that's not
to say that SLAAC or /64s are bad. They're fine ideas with proper
protections.

I'm not sure about the /80 reference as I haven't encountered that
recommendation outside of some perverse ideas about point-to-point
links.

Owen

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Mon, Jul 11, 2011 at 3:41 PM, Jeff Wheeler  wrote:
> On Mon, Jul 11, 2011 at 3:18 PM, William Herrin  wrote:
>> On the other hand, calling out ops issues in RFCs is a modest reform
>> that at worst shouldn't hurt anything. That beats my next best idea:
>
> I think if this were done, some guy like me would spend endless hours
> arguing with others about what should and should not be documented in
> this proposed section, without it actually benefiting the process or
> the improving the underlying protocol function / specification.  Let
> me give you an example:
>
> BGP Messages, which are up to 4KB, need to be expanded to support
> future features like as-path signing.  Randy Bush proposes to extend
> them to 65,535 octets, the maximum size without significantly changing
> the message header.  This raises a few concerns which I label as
> operational, for example, off-by-one bugs in code can fail to be
> detected by a neighboring BGP speaker in some circumstances, because
> an age-old (since BGP 1) idiot check in the protocol is being silently
> removed.
>
> If you ask me, that is operational and belongs in such a section.

Hi Jeff,

Thanks for your thoughtful response. Question: It seems to me like
figuring out what is or isn't a security issue to be called out has
exactly the same pitfalls. How do you deal with it?


> Besides, you want "IETF people" who are claimed not to understand
> operational problems to figure them out and document them in the RFCs?
>  I do not think this will be helpful.  More hands-on operators
> participating in their process is what is needed.

You're an "IETF person" trying to figure out what is or isn't an
operations issue so that you can call it out. How might you go about
figuring that out?

Personally, I might ask a few ops: "Lend me your ear for three minutes
to tell you about what I'm working on. Now that that I've given you
the pitch, is this something you'd like to control in a configuration
or is it something you want to -just work-?" "Control" = operations
issue. "Just work" = not an operations issue.

Regards,
Bill

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Owen DeLong]

> 
>> You disagree? What are your thoughts on fixing the problem?
> 
> I'm not sure that we agree on the dimensions of the problem.
> 
> on the question of ipv6 is broken:
> 
> * You're going to have to cope with what you have and can squeeze out of 
> vendors in the near term. implmentors don't change that fast.
> * People have to show up with the problem statement and stick around to do 
> the work
> * the outcomes are not always pretty.
> 

I don't think that has anything to do with the problem Bill is trying to 
address.

While it is the topic that started this thread, the problem that I think Bill 
is trying to address
and which I agree needs to be addressed is that IETF standards are developed 
with what
has become increasingly obvious as insufficient operator input.

Yes, operators are partially to blame in that decisions are made by those that 
show up
and operators have a hard time showing up to the IETF process for a variety of 
reasons
that are mostly related to the realities of running day to day operations and 
not realy
something the IETF can easily address.

However, part of the problem also relates to ways in which the IETF is 
particularly
difficult for operators to credibly participate. (the amount of ego and 
religion in some
of the working groups, the need for a thick skin if you want to make a statement
that goes counter to the current dogma, the time-consuming nature of meaningful
participation, etc.).

I don't pretend to have answers to all of these problems, but, I think there 
first needs
to be recognition and consensus that the lack of operator input into the IETF
is becoming increasingly problematic and is impacting the ability to deploy what
is developed by the IETF.

Owen

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Franck Martin]

Once upon a time, there was only the IETF, then NOGs came and standards
became sloppy

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Jeff Wheeler]

On Mon, Jul 11, 2011 at 5:12 PM, Owen DeLong  wrote:
> No... I like SLAAC and find it useful in a number of places. What's wrong
> with /64? Yes, we need better DOS protection in switches and routers

See my slides http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for
why no vendor's implementation is effective "DOS protection" today and
how much complexity is involved in doing it correctly, which requires
not only knobs on routers, but also on layer-2 access switches, which
is not easy to implement.  It's a whole lot smarter to just configure
a smaller network when that is practical.  In fact, that advice should
be "the standard."

I really don't understand why we need SLAAC.  I believe it is a relic
of a mindset when a DHCP client might have been hard to implement
cost-effectively in a really light-weight client device (coffee pot?
wrist-watch?)  Or when running a DHCP server was some big undertaking
that couldn't be made not only obvious, but transparent, to SOHO users
buying any $99 CPE.

I do understand why SLAAC needs /64.  Okay, so configure /64 on those
networks where SLAAC is utilized.  Otherwise, do something else.
Pretty simple!  Again, please see my slides.

> to accommodate some of the realities of those decisions, but, that's not
> to say that SLAAC or /64s are bad. They're fine ideas with proper
> protections.

The proper protections are kinda hard to do if you have relatively
dumb layer-2 access switches.  It is a lot harder than RA Guard, and
we aren't ever likely to see that feature on a large base of installed
"legacy" switches, like Cisco 2950.  Replacing those will be
expensive.  We can't replace them yet anyway because similar switches
(price) today still do not have RA Guard, let alone any knobs to
defend against neighbor table churn, etc.  I'm not sure if they ever
will have the later.

> I'm not sure about the /80 reference as I haven't encountered that
> recommendation outside of some perverse ideas about point-to-point
> links.

This is because you didn't follow IPv6 progress until somewhat
recently, and you are not aware that the original suggestion for
prefix length was 80 bits, leaving just 48 bits for the host portion
of the address.  This was later revised.  It helps to know a bit of
the history that got us to where we are now.

It was originally hoped, by some, that we may not even need NDP
because the layer-2 adjacency would always be encoded in the end of
the layer-3 address.  Some people still think vendors may get us to
that point with configuration knobs.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell  wrote:
> If the IETF really wanted to get useful operator impact, they would
> slightly modify their process.  On the front end there would be a
> more clear way for operational types to add to the To-Do list "stuff
> we really need to make the Internet work better".

Hi Leo,

That's an interesting idea, but how does it work?

As it stands, I can join a working group mailing list and submit an
I-D any time I feel like it. There is almost zero barrier to entry.
And I can take it to any step short of the final publication track
through the simple expedient of working on it myself.

How does the to-do list differ from this? Does it provide some kind of
push counter to the folks who hum against publication? How's it work?


> Then, some sausage
> would be made largely without operator involvement (but hey, if you
> want to participate no exclusions), and then when developmen is
> about 80-90% done there would be an "operational testing and comment
> period".

That's another interesting idea. Would you mind gaming it out for me?
Use RFC 3484. You have I-D-v6-address-selection 90% ready for
publication as RFC 3484. Now what?

In their prescience, the operator feedback is going to be "with
multiple addresses on a server representing various Internet paths
with various reliabilities, we need a way to communicate to the client
which addresses to prefer based on our expert knowledge of the
reliability of our local network." What elicits that feedback? What do
the authors of I-D-v6-address-selection do with the feedback prior to
publication?

Thanks,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[William Herrin]

On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli  wrote:
>
> On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
>
>> On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli  wrote:
>>> On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
 Today's RFC candidates are required to call out IANA considerations
 and security considerations in special sections. They do so because
 each of these areas has landmines that the majority of working groups
 are ill equipped to consider on their own.

 There should be an operations callout as well -- a section where
 proposed operations defaults (as well as statics for which a solid
 case can be made for an operations tunable) are extracted from the
 thick of it and offered for operator scrutiny prior to publication of
 the RFC.

 Do you find this adjustment objectionable?
>>>
>>> Do I think that adding yet another required section to an
>>> internet draft is going to increase it's quality?
>>> No I do not.
>>
>> Joel,
>>
>> You may be right. Calling out IANA considerations doesn't seem to have
>> made the IETF any smarter on the shared ISP IPv4 space. And I have no
>> idea if calling out security implications has helped reduce
>> security-related design flaws.
>>
>> On the other hand, calling out ops issues in RFCs is a modest reform
>> that at worst shouldn't hurt anything.
>
> To my mind, one of the really good criterion for an operational
> considerations document is some actual experience running it.

Hi Joel,

I'm not looking for anything that sophisticated. I just want a list of
"These are the things that can be tuned at an operations level (plus
the defaults) and these are the things that can't be tuned but someone
in the discussion thought a reasonable person might want them to be."
The idea is that an ops guy should be able to read the three-paragraph
intro, jump to the list of tunables and then be able to offer feedback
along the lines of, "Whoa! Of course X should be tunable, are you
kidding? Here's a rough description of where I want to configure it."
and "I'm never going to alter Y. You can make it configurable, but I'd
just as soon deal with everybody having the same value of Y."

Heck, make it multiple choice. 1 is "no chance I'll ever want to
change this value" and 5 is "I'll want to set this value case by
case."


>> That beats my next best idea:
>> asking the ops area to schedule its meetings with the various NOG
>> meetings instead of with the rest of the IETF so that the attendance
>> is ops who dabble in development instead of developers who dabble in
>> ops.
>
> The OPS area works on OPS and Management. Protocol
> development of the sort you're describing generally occurs
> in working-groups chartered in the Internet or Routing areas...

A moment ago you said, the ops area "reviews basically every draft in
front of the IESG."


> Participants, especially those that actually do the work are the
> important part as far as I'm concerned.

I don't disagree. But producing flawed standards does nobody any good,
least of all the folks who poured their hearts and souls into making
them.


> Rough consensus is an ugly an imperfect business, it
> should be recognized that not everyone is going to come
> away from every exchange with what they want.

Which if you were talking about a rough consensus of operations folk
addressing operations issues would be just fine. This is basically
what happens at the address registries like ARIN and it more or less
works. That's broken in the IETF. The ops folks aren't there for the
consensus checks. As a consequence, ops issues are being decided not
with -rough- consensus but with -false- consensus.

False consensus falls apart when you try to bring the excluded folks
back to the party, as you must in the operators' case with any
standard the IETF produces.


>> You disagree? What are your thoughts on fixing the problem?
>
> I'm not sure that we agree on the dimensions of the problem.
>
> on the question of ipv6 is broken:
>
> * You're going to have to cope with what you have and can squeeze out of 
> vendors in the near term. implmentors don't change that fast.
> * People have to show up with the problem statement and stick around to do 
> the work
> * the outcomes are not always pretty.

V6 poses some difficult challenges and you're right that in the short
term we're basically stuck with what is and have to make the best of
it. But V6 isn't my focus in this thread. The ops are sufficiently
irate at this point that they'll keep pounding on the WG's and the
vendors until fixes happen.

My focus in this thread is this: how do we help the next teams avoid
the discourtesy and the smackdown that the v6 teams are getting for
not adequately recognizing the ops' issues. These guys should have
been heroes but instead they screwed the pooch and everybody's paying
for it. How do we fix the systemic problems so that next time they are
heroes?

Regards,
Bill H

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Lucy Lynch]

On Mon, 11 Jul 2011, William Herrin wrote:


On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli  wrote:


On Jul 11, 2011, at 12:18 PM, William Herrin wrote:






My focus in this thread is this: how do we help the next teams avoid
the discourtesy and the smackdown that the v6 teams are getting for
not adequately recognizing the ops' issues. These guys should have
been heroes but instead they screwed the pooch and everybody's paying
for it. How do we fix the systemic problems so that next time they are
heroes?


get to the party early: http://trac.tools.ietf.org/bof/trac/
and stay late... lots of new work inbound.

- Lucy


Regards,
Bill Herrin

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Joel Jaeggli]

On Jul 11, 2011, at 3:37 PM, William Herrin wrote:

> On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli  wrote:
>> 
>> On Jul 11, 2011, at 12:18 PM, William Herrin wrote:
>> 
>>> On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli  wrote:
 On Jul 11, 2011, at 8:13 AM, William Herrin wrote:
> Today's RFC candidates are required to call out IANA considerations
> and security considerations in special sections. They do so because
> each of these areas has landmines that the majority of working groups
> are ill equipped to consider on their own.
> 
> There should be an operations callout as well -- a section where
> proposed operations defaults (as well as statics for which a solid
> case can be made for an operations tunable) are extracted from the
> thick of it and offered for operator scrutiny prior to publication of
> the RFC.
> 
> Do you find this adjustment objectionable?
 
 Do I think that adding yet another required section to an
 internet draft is going to increase it's quality?
 No I do not.
>>> 
>>> Joel,
>>> 
>>> You may be right. Calling out IANA considerations doesn't seem to have
>>> made the IETF any smarter on the shared ISP IPv4 space. And I have no
>>> idea if calling out security implications has helped reduce
>>> security-related design flaws.
>>> 
>>> On the other hand, calling out ops issues in RFCs is a modest reform
>>> that at worst shouldn't hurt anything.
>> 
>> To my mind, one of the really good criterion for an operational
>> considerations document is some actual experience running it.
> 
> Hi Joel,
> 
> I'm not looking for anything that sophisticated. I just want a list of
> "These are the things that can be tuned at an operations level (plus
> the defaults) and these are the things that can't be tuned but someone
> in the discussion thought a reasonable person might want them to be."
> The idea is that an ops guy should be able to read the three-paragraph
> intro, jump to the list of tunables and then be able to offer feedback
> along the lines of, "Whoa! Of course X should be tunable, are you
> kidding? Here's a rough description of where I want to configure it."
> and "I'm never going to alter Y. You can make it configurable, but I'd
> just as soon deal with everybody having the same value of Y."
> 
> Heck, make it multiple choice. 1 is "no chance I'll ever want to
> change this value" and 5 is "I'll want to set this value case by
> case."
> 
> 
>>> That beats my next best idea:
>>> asking the ops area to schedule its meetings with the various NOG
>>> meetings instead of with the rest of the IETF so that the attendance
>>> is ops who dabble in development instead of developers who dabble in
>>> ops.
>> 
>> The OPS area works on OPS and Management. Protocol
>> development of the sort you're describing generally occurs
>> in working-groups chartered in the Internet or Routing areas...
> 
> A moment ago you said, the ops area "reviews basically every draft in
> front of the IESG."

I said there is an ops directorate that reviews basically every draft in front 
of the iesg... much like their are genart reviews, security reviews iana 
reviews etc. The principle work on a draft by the time that occurs is already 
done unless the iesg returns the draft to the work group.



>> Participants, especially those that actually do the work are the
>> important part as far as I'm concerned.
> 
> My focus in this thread is this: how do we help the next teams avoid
> the discourtesy and the smackdown that the v6 teams are getting for
> not adequately recognizing the ops' issues. These guys should have
> been heroes but instead they screwed the pooch and everybody's paying
> for it. How do we fix the systemic problems so that next time they are
> heroes?

IPNG was a long time ago. things have changed and will continue to change 
because standards are written by humans and cemented with consensus which is 
imperment and changable. Rational changes, Requirements change and things 
should evolve, that's not failure it's healthy.

> Regards,
> Bill Herrin

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Jimmy Hess]

On Mon, Jul 11, 2011 at 5:03 PM, Jeff Wheeler  wrote:
> On Mon, Jul 11, 2011 at 5:12 PM, Owen DeLong  wrote:
>> No... I like SLAAC and find it useful in a number of places. What's wrong
>> with /64? Yes, we need better DOS protection in switches and routers

> See my slides http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for
> why no vendor's implementation is effective "DOS protection" today and
> how much complexity is involved in doing it correctly, which requires
[snip]

If every vendor's implementation is vulnerable to a NDP Exhaustion
vulnerability,
how come the behavior of specific routers has not been documented specifically?

If  "zero" devices are not vulnerable, you came to this conclusion
because you tested
every single implementation against IPv6 NDP DoS,  or?

How come there are no security advisories.
What's the CWE or CVE number for this vulnerability?

I'm not denying the that NDP overflow might be a DoS issue for all IPv6
routers,  but I haven't seen   any specific documentation from vendors
or security
researchers about specific DoS conditions that can be caused by NDP overflow
on particular devices

It would be useful to at least have the risk properly described, in
terms of what
kind of DoS condition could arise on specific implementations.


Regards,
--
-JH

NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Karl Auer]

On Mon, 2011-07-11 at 18:48 -0500, Jimmy Hess wrote:
> It would be useful to at least have the risk properly described, in
> terms of what kind of DoS condition could arise on specific implementations.

RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats

Section 4.3.2

   In this attack, the attacking node begins fabricating addresses with
   the subnet prefix and continuously sending packets to them.  The last
   hop router is obligated to resolve these addresses by sending
   neighbor solicitation packets.  A legitimate host attempting to enter
   the network may not be able to obtain Neighbor Discovery service from
   the last hop router as it will be already busy with sending other
   solicitations.  This DoS attack is different from the others in that
   the attacker may be off-link.  The resource being attacked in this
   case is the conceptual neighbor cache, which will be filled with
   attempts to resolve IPv6 addresses having a valid prefix but invalid
   suffix.  This is a DoS attack.

The above RFC and RFC3971 (SEND) both have good descriptions of a BUNCH
of possible attacks. RFC3971 is a bit dismissive IMHO of this particular
attack.

I realise this is not "specific implementations" as you requested, but
it seems to me that the problem is generic enough not to require that.

The attack is made possible by the design of the protocol, not any
failing of specific implementations. Specific implementations need to
describe what they've done about it (mitigation or prevention).

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156


signature.asc
Description: This is a digitally signed message part

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Jeff Wheeler]

On Mon, Jul 11, 2011 at 7:48 PM, Jimmy Hess  wrote:
> If every vendor's implementation is vulnerable to a NDP Exhaustion
> vulnerability,
> how come the behavior of specific routers has not been documented 
> specifically?

Well, I am in the business of knowing the behavior of kit being
considered by my clients for their applications.  Every box breaks
when tested, period.  I imagine you have tested zero, thus you have no
data of your own to go on.  No vendors are rushing to spend money on
"independent" testing laboratories to produce reports about this,
because they pretty much all know their boxes will break (or are not
even aware of the potential problem, in the case of a few scary
vendors.)

> If  "zero" devices are not vulnerable, you came to this conclusion
> because you tested
> every single implementation against IPv6 NDP DoS,  or?

Although I have tested many routers to verify my thinking, if you
actually read the slides and understand how routers work, you too will
know that every router is vulnerable.  If you don't know, you don't
understand how routers work.  It's that simple.

> How come there are no security advisories.
> What's the CWE or CVE number for this vulnerability?

Again, no one is interested in this problem yet because vendors really
don't want their customers to demand more knobs.  Cisco is the only
vendor who has done anything at all.  If you read about their knob,
you immediately realize that it is a knob to control the failure mode
of the box, not to "fix" anything.  Why?  It can't be "fixed" without
not using /64 (or similar) or going to the extreme lengths I outline
in those slides.

> It would be useful to at least have the risk properly described, in
> terms of what
> kind of DoS condition could arise on specific implementations.

Let's take 6500/SUP720 for example.  On this platform, a policer is
shared between the need to resolve ARP entries and ND table entries.
If you attack a dual-stack SUP720 box it will break not only IPv6
neighbor resolution, but also IPv4 neighbor resolution.  This is
pretty much the "worst-case scenario" because not only will your IPv6
break, which may annoy customers but not be a disaster; it will also
break mission-critical IPv4.  That's bad.  Routing-protocol
adjacencies can be affected, disabling not just some hosts downstream
of the box, but also its upstream connectivity.  It doesn't get any
worse than that.

You are right to question my statements.  I'm not an independent lab
doing professional tests and showing the environment and conditions of
how you can reproduce the results.  I'm just a guy helping my clients
decide what kit to buy, and how they should configure their networks.
The only reason I have bothered to produce slides is because we are at
a point where we have end-customers questioning our reluctance to
provision /64 networks for mixed-use data-center LANs, and until
vendors actually do something to address this, or "the standard"
changes, I need to increase awareness of this problem so I am not
forced to deploy a broken design on my own networks the way a lot of
other clueless people are.

Again, this is only hard to understand (or accept) if you don't know
how your routers work.
* why do you think there is an ARP and ND table?
* why do you think there are policers to protect the CPU from
excessive ARP/ND punts or traffic?
* do you even know the limit of your boxes' ARP / ND tables?  Do you
realize that limit is a tiny fraction of one /64?
* do you understand what happens when your ARP/ND policers are reached?
* did you think about the impact on neighboring routers and protocol
next-hops, not just servers?
* did you every try to deploy a /16 on a flat LAN with a lot of hosts
and see what happens?  Doesn't work too well.  A v6 /64 is 281
trillion times bigger than a v4 /16.  There's no big leap of logic
here as to why one rogue machine could break your LAN.

There is no router which is not vulnerable to this.  If you don't
believe me, read the Cisco documentation on their knob limiting ND
entries per interface, after which there may be service impact on that
interface.  That's the best anyone is doing right now.  Of course,
vendors understand that we, as customers, can configure a subnet
smaller than /64.  They are leaving us open to link-local issues right
now even with a smaller global subnet size, but at least that cannot
be exploited from "the Internet."  And as it happens, exactly the same
features / knobs are needed to "fix" both problems with /64, and with
link-local neighbor learning.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Doug Barton]

On 07/10/2011 12:45, Owen DeLong wrote:
> 
> On Jul 10, 2011, at 9:16 AM, Jeroen Massar wrote:
> 
>> On 2011-07-10 17:56 , David Miller wrote:
>> [..]
>>> +1
>>>
>>> The lack of will on the part of the IETF to attract input from and involve
>>> operators in their processes (which I would posit is a critical element in
>>> the process).

Discussing how the IETF should fix itself is both fruitless, and off
topic for this list. However ...

> While this is true, there are a couple of factors that make it more difficult
> than it would appear on the surface.
> 
> Number one: Participating effectively in IETF is a rather time-consuming
> process. While a lot of engineers and developers may have IETF effort
> as a primary part of their job function and/or get their employer to let
> them spend time on it, operators are often too busy keeping what they
> already have running and it can be _VERY_ difficult to get management
> to support the idea of investing time in things like IETF which are not
> seen by management as having direct operational impact. NANOG
> is about the limit of their vision on such things and even that is not
> well supported in a lot of organizations.
> 
> Number two: While anyone can participate, approaching IETF as an
> operator requires a rather thick skin, or, at least it did the last couple
> of times I attempted to participate. I've watched a few times where
> operators were shouted down by purists and religion over basic
> real-world operational concerns. It seems to be a relatively routine
> practice and does not lead to operators wanting to come back to
> an environment where they feel unwelcome.

What you're saying is absolutely right (unfortunately), but the answer
is that operators need to suck it up and get involved. The problem will
not fix itself if we don't.

The good news is that in many areas (at least, the areas that I
participate in) there is starting to be a lot more sympathy toward
operational concerns/realities, and real progress is being made. Yes,
it's slow, arduous, and often frustrating. (How's that for a sales
pitch?) But there is literally no other solution to improving the
situation that for the people that care to get involved in helping to
fix it.

For those interested in IPv6 I highly recommend subscribing to the the
6man and v6ops lists, listen in on the conversations for a while, and
then chime in when you feel comfortable. Treat those on the list with
the same courtesy and respect that you'd like to be treated with, and
way more often than not it will bear fruit.


hth,

Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

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

Facebook contact?

[Walter Keen]

If anyone from Facebook is here, Please contact me.

Thanks

--
Walter Keen
Network Engineer
Rainier Connect

(P) 360-832-4024
(C) 253-302-0194

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Randy Bush]

> Well, you work at Zynga, a company which makes facebook games. Before
> that you worked at Nokia, company which makes phones but doesn't run
> phone networks. Before that it was Check Point Software, a company
> which makes firewalls but doesn't run networks. And before that it was
> the University of Oregon.

down to the ad homina pretty quickly.  congrats.

fyi, what joel does/did at those companies is/was build and run networks
and data centers.

next ad hominem attack?

randy

Re: Hello List, a easy Cisco question.

[Jimmy Hess]

On Mon, Jul 11, 2011 at 3:16 PM,   wrote:
>   connection.
>ip address outside-ip 255.255.255.252
Aside from the fact 255.255.255.252  is not a valid IP address.

Firewalls are security sensitive devices, I suggest reading docs and not
relying on untrusted sources for basic operating directions; if improperly
configured a  Firewall may pass traffic but be insecure.

I can't tell you exactly what buttons to hit in the SDM right now,
but I see  you have
"  access-list Etherpoint_access_in extended permit tcp any eq 3389 host
  192.168.125.8 eq 3389"

Unless "192.168.125.8" is your global IP, something is wrong here.
You should permit to destination port 3389 on the global IP,  on the inbound ACL
of your outside interface,  when you are applying an ACL before translation.

Then traffic matching your port forwarding rule would then be allowed
through that ACL


 " access-list Etherpoint_access_in extended permit tcp host 192.168.125.8
  eq 3389 any eq 3389"

You don't need this,  assuming  .125.8  is an inside IP and Etherpoint is
your outside int.







>
>
>
>   Here is the pertinent section of the runing config.
>
>
>
>   !
>   interface Ethernet0/2
>    nameif Etherpoint
>    security-level 0
>    ip address outside-ip 255.255.255.252
>    ospf cost 10
>   !
>
>   object-group service terminal-services tcp
>    port-object eq 3389
>   access-list Inside_access_in extended permit icmp any any
>   access-list Inside_access_in extended permit ip 192.168.125.0
>   255.255.255.0 any
>   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
>   255.255.255.0 MobileVPN 255.255.255.0
>   access-list Inside_nat0_outbound extended permit ip 192.168.0.0
>   255.255.255.0 MobileVPN 255.255.255.0 inactive
>   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
>   255.255.255.0 any inactive
>   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
>   255.255.255.0 192.168.1.0 255.255.255.0
>   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
>   255.255.255.0 192.168.14.0 255.255.255.0
>   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
>   255.255.255.0 192.168.100.0 255.255.255.0
>   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
>   255.255.255.0 192.168.101.0 255.255.255.0
>   access-list Inside_nat0_outbound extended permit ip 192.168.125.0
>   255.255.255.0 192.168.253.0 255.255.255.0
>   access-list Haven_splitTunnelAcl_1 standard permit 192.168.125.0
>   255.255.255.0
>   access-list Etherpoint_access_in extended permit tcp host 192.168.125.8
>   eq 3389 any eq 3389
>   access-list Etherpoint_access_in extended permit tcp any eq 3389 host
>   192.168.125.8 eq 3389
>   access-list Etherpoint_access_in extended permit tcp any host
>   192.168.125.8 eq 3389
>   access-list Etherpoint_nat0_outbound extended permit ip host
>   192.168.125.8 host outside-ip
>   access-list Etherpoint_nat0_outbound extended permit ip host outside-ip
>   host 192.168.125.8
>
>   ip local pool HavenVPN 192.168.253.1-192.168.253.254 mask 255.255.255.0
>
>   global (Etherpoint) 2 interface
>
>   nat (Inside) 0 access-list Inside_nat0_outbound
>   nat (Inside) 2 192.168.125.0 255.255.255.0
>   nat (Etherpoint) 0 access-list Etherpoint_nat0_outbound outside
>   static (Inside,Etherpoint) tcp interface 3389 192.168.125.8 3389
>   netmask 255.255.255.255
>
>   no threat-detection statistics tcp-intercept
>   access-group Inside_access_in in interface Inside
>   access-group Etherpoint_access_in in interface Etherpoint
>
>   route Etherpoint 0.0.0.0 0.0.0.0 204.186.102.187 1
>
>
>
>    Original Message 
>   Subject: Re: Hello List, a easy Cisco question.
>   From: Dennis <[1]daoden...@gmail.com>
>   Date: Mon, July 11, 2011 12:39 pm
>   To: [2]b...@kruchas.com
>   On Mon, Jul 11, 2011 at 12:33 PM, <[3]b...@kruchas.com> wrote:
>   >   Hello,
>   >
>   >       I am not a heads down network guy, but I have setup a few
>   >   firewalls, and have got them to do what I wanted, "eventually". But
>   >   mostly through reading and trial and error.
>   >
>   >       I am struggling with this one, but I think I know the answer,
>   but
>   >   want to verify it with some experts.
>   >
>   >
>   >
>   >       We have a cisco asa 5505, with an internet connection with only
>   one
>   >   useable ip address (subnet 255.255.255.252). We/they have had a nat
>   >   setup for outgoing connections for some time, but I have been
>   trying to
>   So your provider has your ASA behind a NAT or there is a NAT
>   inside,outside statement on your ASA?
>   Some more pieces of the configuration would be helpful here too.
>   Thanks,
>   Dennis O.
>
> References
>
>   1. mailto:daoden...@gmail.com
>   2. mailto:b...@kruchas.com
>   3. mailto:b...@kruchas.com
>


Regards,

-- 
-JH

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Randy Bush]

>> My focus in this thread is this: how do we help the next teams avoid
>> the discourtesy and the smackdown that the v6 teams are getting for
>> not adequately recognizing the ops' issues. These guys should have
>> been heroes but instead they screwed the pooch and everybody's paying
>> for it. How do we fix the systemic problems so that next time they
>> are heroes?
> get to the party early: http://trac.tools.ietf.org/bof/trac/ and stay
> late... lots of new work inbound.

aka, suit up and show up.  talk is cheap.

randy

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Randy Bush]

> I said there is an ops directorate that reviews basically every draft
> in front of the iesg.

and this directorate is a group of actual operators?

randy

Myspace. Was:Re: Facebook contact?

[Walter Keen]

My apologies all, I meant to say myspace contact

Connected by DROID on Verizon Wireless

-Original message-
From: Walter Keen 
To: NANOG list 
Sent: Tue, Jul 12, 2011 00:29:19 GMT+00:00
Subject: Facebook contact?

If anyone from Facebook is here, Please contact me.

Thanks

-- Walter Keen
Network Engineer
Rainier Connect

(P) 360-832-4024
(C) 253-302-0194

Re: Myspace. Was:Re: Facebook contact?

[Matthew Petach]

On Mon, Jul 11, 2011 at 6:23 PM, Walter Keen
 wrote:
> My apologies all, I meant to say myspace contact
>

You're more likely to get a response if you give some indication
of what the issue is; for example, saying "I'm looking for a MySpace
contact because there is an attack coming from their servers that
appears to indicate they may have been compromised" will likely
get you a faster reaction from the security people.  Or, if it's a
network issue, saying "I'm looking for a MySpace network contact
because it appears they are announcing the following blocks which
really belong to me, which is causing reachability issues" will more
likely get you a reaction from an appropriate network person.

Without an indication of the nature of the problem, I think you'll find
most people on the list tend to ignore generic requests like this.

Thanks!

Matt

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Fred Baker]

On Jul 10, 2011, at 12:16 PM, Jeroen Massar wrote:
> On 2011-07-10 17:56 , David Miller wrote:
> [..]
>> +1
>> 
>> The lack of will on the part of the IETF to attract input from and involve 
>> operators in their processes (which I would posit is a critical element in 
>> the process).
> 
> Eh ANYBODY, including you, can sign up to the IETF mailing lists and 
> participate there, just like a couple of folks from NANOG are already doing.
> 
> You are on NANOG out of your own free will, the same applies to the IETF. If 
> you don't participate here your voice is not heard either, just
> like at the IETF.
> 
> Peeking at the i...@ietf.org member list, I don't see your name there. You 
> can signup here: https://www.ietf.org/mailman/listinfo/ipv6

Thanks, Jeroen.

For IPv6 functionality, I'd suggest i...@ietf.org 
(https://www.ietf.org/mailman/listinfo/ipv6). For IPv6 operational issues, I'd 
suggest v6...@ietf.org (https://www.ietf.org/mailman/listinfo/v6ops). For 
security-related issues, you might also look into op...@ietf.org 
(https://www.ietf.org/mailman/listinfo/opsec).


On Jul 10, 2011, at 3:45 PM, Owen DeLong wrote:
> Number two: While anyone can participate, approaching IETF as an operator 
> requires a rather thick skin, or, at least it did the last couple of times I 
> attempted to participate. I've watched a few times where operators were 
> shouted down by purists and religion over basic real-world operational 
> concerns.

That goes both ways. I periodically see dismissive statements about the IETF on 
operational lists, and dismissive statements about operators on IETF lists. I 
would classify David's comment as "dismissive", the kind of comment that causes 
IETF folks to not participate in operational meetings or lists, and the kind of 
comment cited by operational folks such as you as reasons to leave IETF 
meetings and lists. Such comments tend to come from a small set of individuals 
on each side. If such comments bother you, feel free to block the 
in-duh-viduals that send them. Personally, I try to listen to them; they are 
often telling me something I need to hear but don't want to.

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Owen DeLong]

On Jul 11, 2011, at 2:54 PM, Franck Martin wrote:

> Once upon a time, there was only the IETF, then NOGs came and standards
> became sloppy
> 

Uh, no... Really not.

Read some of the earliest standards documents and you'll find that they are
pretty sloppy, but, the community back then (predecessor to NOGs) was small
enough that people could develop and deploy workarounds and feed those
resolutions into superseding RFCs. Today, there are many more operators
and IETF has become a much larger and more complex set of bodies as
well.

Owen

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Owen DeLong]

> 
> Again, no one is interested in this problem yet because vendors really
> don't want their customers to demand more knobs.  Cisco is the only
> vendor who has done anything at all.  If you read about their knob,
> you immediately realize that it is a knob to control the failure mode
> of the box, not to "fix" anything.  Why?  It can't be "fixed" without
> not using /64 (or similar) or going to the extreme lengths I outline
> in those slides.
> 
While it can't be "fixed", controlling the failure mode is adequate in
the vast majority of cases.

Beyond that, it becomes increasingly academic and purist-oriented
rather than operational.

Owen

IMPORTANT: NANOG List Cutover Test

[Michael K. Smith - Adhost]

Hello:

I'll be testing the list cutover again at 10:00 PM PDT (GMT -7).  Please
ignore the subsequent "NANOG TEST" email that comes through to the list.

Regards,

Mike

NANOG TEST

[Michael K. Smith - Adhost]

As per my previous message - please ignore.

Mike
NANOG CC Chair

NANOG List Update - Moving Forward

[Michael K. Smith - Adhost]

Hello All:

Thankfully, the current test has been a success.  We are going to stay in
the present setup through tomorrow morning at approximately 11:00 AM PDT
(GMT -7).  Below is a brief description of the present state and the
changes that will be made tomorrow.

Present State

Mailman is shut down on s0.nanog.org and mail is being routed directly to
mail.amsl.com where it is being processed by our new list (etc.) system.

Tomorrow
---
We will cut DNS over for nanog.org so that mail and web are all being
handled natively within the new system.  There will likely be some
delivery issues related to stale DNS for some people, but we hope that
most folks here will be able to receive and process the DNS updates for
nanog.org in a timely fashion.

If you have any questions or concerns please let me know.

Thanks,

Mike

五工变频器，中国唯一与世界竞争的产品简介

[WUGON]

节约你的设备成本，提高你的设备质量――请选用中国五工变频器！
■五工变频器――中国唯一与世界竞争的产品！
――德国技术合作！
――国际认可的中国品牌！
――节约成本，提高质量，取代进口变频，一年为你节约几十万至几百万，甚至几千万资金！
――2010年取代进口变频快速上升！

（因是产品简介，内容简短，以免占用你的邮箱空间）

■五工变频器优势简介
详细产品请查看
――五工变频网站：http://wugon.letgo.com.cn（无病毒，请放心查看）

注意：咨询、合作、代理请按以下正确的联系方式：

联系方式：
单位：五工能源系统制造(惠州)有限公司 (变频器产品商务部）
地址：中国电子生产基地――广东省惠州市三新工业区
电  话：0752-2350566   传真：0752-2352166
手  机：15917753055（沈先生）  商务QQ：906270997 
E-mail：wugong...@163.com
网站：http://wugon.letgo.com.cn
（友情告知：因你的邮址在各网站是公开的，如有打扰或重复，敬请谅解）