RE: World famous cabling disasters?

[Randy Epstein]

Joe,

>I'm looking for a couple of pictures of the worst cabling  
>infrastructure ever seem. One Wilshire meet me room comes to mind.
>Anyone got any links to their photo albums, etc?

The One Wilshire pictures you are referring to were within this Wired
article:
http://www.wired.com/techbiz/it/multimedia/2008/03/gallery_one_wilshire?slid
e=3&slideView=2

Also there are some great photos at
http://www.darkroastedblend.com/2007/03/really-bad-wiring-jobs_20.html


>Joe McGuckin
>ViaNet Communications

Regards,

Randy

Re: World famous cabling disasters?

[Patrick W. Gilmore]

On Feb 10, 2009, at 10:16 PM, joe mcguckin wrote:

I'm looking for a couple of pictures of the worst cabling  
infrastructure ever seem. One Wilshire meet me room comes to mind.

Anyone got any links to their photo albums, etc?


I've always considered this the worst:

   

Google shows lots of pictures, such as .


--
TTFN,
patrick

Re: World famous cabling disasters?

[Justin M. Streiner]

On Tue, 10 Feb 2009, joe mcguckin wrote:

I'm looking for a couple of pictures of the worst cabling infrastructure ever 
seem. One Wilshire meet me room comes to mind.

Anyone got any links to their photo albums, etc?


You might find some links in the archives.  I've seen a few in person that 
still make me cringe.


jms

World famous cabling disasters?

[joe mcguckin]

I'm looking for a couple of pictures of the worst cabling  
infrastructure ever seem. One Wilshire meet me room comes to mind.

Anyone got any links to their photo albums, etc?


Joe McGuckin
ViaNet Communications

j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax

Re: Is whois.apnic.net down? (IPv6-MW)

[Suresh Ramasubramanian]

On Wed, Feb 11, 2009 at 2:13 AM,   wrote:
>  933 ms33 ms33 ms  203.119.76.66
>  1036 ms35 ms35 ms  whois.apnic.net [202.12.29.13]
>
> Trace complete.
>
> It's reachable from where I'm sitting (NSW)

Reachable just fine (from my dsl box in India, and from my personal
colo near los angeles)

srs
-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: 97.128.0.0/9 allocation to verizon wireless

[Scott Howard]

On Tue, Feb 10, 2009 at 3:29 PM, Dave Temkin  wrote:

> Exactly.  I've seen this as well in both instances but haven't seen it on
> mobile phones.  It's something so obscure that you're going to have to
> really want it to turn it on.  I don't think the Port 25 example holds much
> water here.


Many/most GSM/GPRS/etc operators will have multiple APN's - one which is
setup for NAT, and the other which gives a public IP address.

By default, most "dumb" phones will use the former. Data cards will use the
latter, and smartphones seem to be split between the two - although
obviously it will vary between providers.

  Scott.

Re: 97.128.0.0/9 allocation to verizon wireless

[Dave Temkin]

Patrick W. Gilmore wrote:

On Feb 10, 2009, at 5:52 PM, Dave Temkin wrote:

Chuck Anderson wrote:

On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote:


Mark Andrews schrieb:


I don't see any reason to complain based on those numbers.
It's just a extremely high growth period due to technology
change over bring in new functionality.

OTOH, Verizon is not the only provider of smartphone connectivity 
in the
world. Most of them try to be "good citizens" and do not waste a 
scarce

resource (IPv4 space).



I disagree that using global IPv4 space is a "waste".  Every device 
deserves to have "real" internet connectivity and not this NAT crap.


Why must it be always "real" versus NAT?  99% of users don't care one 
way or another.  Would it be so hard for the carrier to provide a 
switch between NAT and "real" IP if the user needs or wants it?


Lots of providers do.  Sometimes the choice between static & dynamic 
is bundled with the choice between NAT & "real" on some broadband 
providers.


I've also seen hotels do it, and even charge extra for it.  (Yes, I 
paid. ;)


Exactly.  I've seen this as well in both instances but haven't seen it 
on mobile phones.  It's something so obscure that you're going to have 
to really want it to turn it on.  I don't think the Port 25 example 
holds much water here.


-Dave

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

[Mark Andrews]

In message , "Ricky Beam" writes:
> On Mon, 09 Feb 2009 21:11:50 -0500, TJ  wrote:
> > Your routers fail frequently?  And does your traffic continue to get
> > forwarded?  Perhaps through another router?
> 
> More frequently than the DHCP server, but neither are "frequent" events.   
> Cisco's software is not 100% perfect, and when you plug it into moderately  
> unstable things like phone lines (DSL) and cable networks, those little  
> bugs cause reloads -- you'd think they'd have better error handling, but  
> they don't. (I don't buy millions in equipment from Cisco so they don't  
> care about my problems.)  While I could use backup links, flip-floping  
> between ISPs with different addresses is not ideal (and that's as true for  
> v6 as v4.)
> 
> > Why is there a problem with RAs being the first step, possibly including
> > prefix info or possibly just hinting @ DHCPv6?
> 
> Because it doesn't fit the needs of *every* network.  In fact, it's only  
> "good enough" for very few networks.  As such it just adds more useless  
> layers of bloat.

Good. You admit it fits the needs of some networks.
 
> > Well, as it stands now the RA isn't useless.
> ...
> > Also, it is not true in every case that hosts need a "lot more" than an
> > address.
> > In many cases all my machine needs is an address, default gateway and DNS
> > server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
> 
> It's useless.  It does NOT provide enough information alone for a host to  
> function.

Hogwash.  The only thing needed for I used from DHCP on my
laptop is router, address and netmask.  I actually discard
anything else that is offered.  RA's meet my needs perfectly
fine.  In fact they do a better job than DHCP for my needs.

I don't trust dns servers returned by dhcp.  Lots of them
don't offer the level of functionality I require.  I run
my own recursive resolver to get the level of functionality
I require.

> In your own words, you need a DNS server.  That is NOT provided  
> by RA thus requires yet another system to get that bit of configuration to  
> the host -- either entered manually, DHCPv6, or from IPv4 network  
> configuration (ie. DHCP!)  Forcing this BS on the world is a colossal  
> waste.  We've had a system to provide *ALL* the information a host needs  
> or wants in the IPv4 world for years.  Why it's not good enough for IPv6  
> is beyond me.
> 
> --Ricky
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org

Re: 97.128.0.0/9 allocation to verizon wireless

[Patrick W. Gilmore]

On Feb 10, 2009, at 5:52 PM, Dave Temkin wrote:

Chuck Anderson wrote:

On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote:


Mark Andrews schrieb:


I don't see any reason to complain based on those numbers.
It's just a extremely high growth period due to technology
change over bring in new functionality.

OTOH, Verizon is not the only provider of smartphone connectivity  
in the
world. Most of them try to be "good citizens" and do not waste a  
scarce

resource (IPv4 space).



I disagree that using global IPv4 space is a "waste".  Every device  
deserves to have "real" internet connectivity and not this NAT crap.


Why must it be always "real" versus NAT?  99% of users don't care  
one way or another.  Would it be so hard for the carrier to provide  
a switch between NAT and "real" IP if the user needs or wants it?


Lots of providers do.  Sometimes the choice between static & dynamic  
is bundled with the choice between NAT & "real" on some broadband  
providers.


I've also seen hotels do it, and even charge extra for it.  (Yes, I  
paid. ;)


--
TTFN,
patrick

Re: 97.128.0.0/9 allocation to verizon wireless

[Valdis . Kletnieks]

On Tue, 10 Feb 2009 14:52:52 PST, Dave Temkin said:

> Why must it be always "real" versus NAT?  99% of users don't care one 
> way or another.  Would it be so hard for the carrier to provide a switch 
> between NAT and "real" IP if the user needs or wants it?

You're almost always better off not providing a user-accessible switch.
Especially not a shiny one labeled "Do not touch unless you know what
you are doing".

(FWIW, this is exactly the same issue as "block port 25 unless user requests
opt-out from the block")


pgpi6taC8ZGqT.pgp
Description: PGP signature

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[John Curran]

On Feb 10, 2009, at 4:30 PM, TJ wrote:


But that is my point - Do any of the compliance frameworks /  
requirements /
audit standards today address IPv6, or detail how it could be  
implemented in

such a fashion as to 'pass' an audit (including the "in-house" /
consultant-specific audit guidelines)?  If it can be done, but is  
solely a
"you and your (current) auditor figure it out, on a case by case  
basis,
every time" I would argue that that is not good enough for the  
general case.


Compliance frameworks are generally technology agonistic.
They tell you "have an information boundary for your system",
"manage your user identifiers", etc.  Aside from the DoD IA
STIGs (and small handful of NIST areas such as encryption),
you don't find specifications that particular protocols or
technology is required.  They don't require major updating
for IPv6 because there's very little IPv4 specific contents
in them already.

That's not to say that moving an application to IPv6 is trivial
from a compliance and security perspective, as you've still got a
pile of mandatory firewall, load-balancing, and IDS infrastructure
that needs to handle IPv6 correctly before you can get started.
In organizations that are planning ahead, this is common security
control infrastructure, and gets done once centrally rather than
each little component.


And while I agree with you, "any change = redo" I would argue that not
everyone realizes that all of their C&A work will need to be re-done  
in
order to retain their CTOs/ATOs if they move forward with any sort  
of IPv6
deployment.  I have heard the gasps (I didn't see the faces, that  
was a

coworker of mine did and said it was amusing - in a sad way.)


Look, systems change.  Change your database software, and you
get to update the corresponding pieces of the C&A package.  Add
IPv6, you have to update the network portions.  This shouldn't
be a surprise to anyone, and it certainly doesn't mean "all of
their C&A work will need to be re-done".

/John

Re: 97.128.0.0/9 allocation to verizon wireless

[Dave Temkin]

Chuck Anderson wrote:

On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote:
  

Mark Andrews schrieb:


I don't see any reason to complain based on those numbers.
It's just a extremely high growth period due to technology
change over bring in new functionality.
  

OTOH, Verizon is not the only provider of smartphone connectivity in the
world. Most of them try to be "good citizens" and do not waste a scarce
resource (IPv4 space).



I disagree that using global IPv4 space is a "waste".  Every device 
deserves to have "real" internet connectivity and not this NAT crap.


  
Why must it be always "real" versus NAT?  99% of users don't care one 
way or another.  Would it be so hard for the carrier to provide a switch 
between NAT and "real" IP if the user needs or wants it?

Re: 97.128.0.0/9 allocation to verizon wireless

[Chuck Anderson]

On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote:
> Mark Andrews schrieb:
> > I don't see any reason to complain based on those numbers.
> > It's just a extremely high growth period due to technology
> > change over bring in new functionality.
> 
> OTOH, Verizon is not the only provider of smartphone connectivity in the
> world. Most of them try to be "good citizens" and do not waste a scarce
> resource (IPv4 space).

I disagree that using global IPv4 space is a "waste".  Every device 
deserves to have "real" internet connectivity and not this NAT crap.

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

[Nathan Ward]

On 11/02/2009, at 10:41 AM, Ricky Beam wrote:

It's useless.  It does NOT provide enough information alone for a  
host to function.  In your own words, you need a DNS server.  That  
is NOT provided by RA thus requires yet another system to get that  
bit of configuration to the host -- either entered manually, DHCPv6,  
or from IPv4 network configuration (ie. DHCP!)  Forcing this BS on  
the world is a colossal waste.  We've had a system to provide *ALL*  
the information a host needs or wants in the IPv4 world for years.   
Why it's not good enough for IPv6 is beyond me.



You are correct, alone RA does not provide enough for a host to  
function.


We have two mechanisms of providing addressing information to hosts -  
SLAAC and DHCPv6.


How do you, as a network manager, tell hosts which one to use? RA  
performs this function. Without RA you need to go around all the  
machines and manually configure how they will discover what addresses  
to use. That seems a bit silly, and going around every machine is  
something you have already indicated you don't want to do.


RA has two functions - telling your hosts which of SLAAC and DHCPv6 to  
use for addressing information, and providing addressing information  
in the case of SLAAC. Also, in the case of SLAAC, it might hint to the  
client to get additional information from DHCPv6 - DNS servers and so  
on - in this case it will not get addressing information.


Perhaps you have a problem with SLAAC? That is fine, you might not  
want to use it. Other people *do* want to use it, and RA is the best  
place to signal which of SLAAC and DHCPv6 a host should use for  
addressing.


Please do not use blanket comments that RA is bad if you actually mean  
SLAAC. Yes, if we do not have SLAAC then we don't need RA, because  
hosts will always know to use DHCPv6. However, many people do want  
SLAAC, so we need RA.


If you have an idea for alternative to RA for indicating whether to  
use SLAAC or DHCPv6 then I encourage you to get involved in the IETF  
and get your idea written up. If you would like to deprecate/fix SLAAC  
because you have a problem with it then again, I encourage you to get  
involved in the IETF.


--
Nathan Ward

Re: 97.128.0.0/9 allocation to verizon wireless

[Patrick W. Gilmore]

On Feb 10, 2009, at 5:31 PM, Matthias Leisi wrote:

Mark Andrews schrieb:


I don't see any reason to complain based on those numbers.
It's just a extremely high growth period due to technology
change over bring in new functionality.


OTOH, Verizon is not the only provider of smartphone connectivity in  
the
world. Most of them try to be "good citizens" and do not waste a  
scarce

resource (IPv4 space).


You mean like the 10.x.x.x addresses give to all iPhones in the US?

Wait, I thought NAT was bad?  So who is the "good citizen"?

--
TTFN,
patrick


If more providers would act like Verizon, we would have run out of  
IPv4
addresses a long time ago (whether or not that is a good or bad  
thing is

left as an exercise to the reader).

-- Matthias

Re: 97.128.0.0/9 allocation to verizon wireless

[Matthias Leisi]

Mark Andrews schrieb:

>   I don't see any reason to complain based on those numbers.
>   It's just a extremely high growth period due to technology
>   change over bring in new functionality.

OTOH, Verizon is not the only provider of smartphone connectivity in the
world. Most of them try to be "good citizens" and do not waste a scarce
resource (IPv4 space).

If more providers would act like Verizon, we would have run out of IPv4
addresses a long time ago (whether or not that is a good or bad thing is
left as an exercise to the reader).

-- Matthias

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

[Nathan Ward]

On 10/02/2009, at 3:20 PM, Christopher Morrow wrote:

IPv6 it's easier, but you're still limiting the uptime of your  
system to
that of the DHCPv6 server. Router advertisements is much more  
robust.


'more robust'... except it doesnt' actually get a device into a usable
state without admins walking around to each machine and poking at them
randomly. if you have 5 machines that's cool, knock yourself out, if
you have 5000 or 5 you are in a completely different ballpark of
work. DHCP servers do this today, the servers pass out all the
relevant bits require for dynamic-addressed and static-addressed
systems, they can be rebooted, moved, re-addressed, re-homed... all
without the masses of clients stopping their work.


I believe you are mis-interpreting Iljitsch's comments.
I believe he is talking about SLAAC, you are talking about *no* DHCPv6.

The difference is, SLAAC can still use DHCPv6 to get configuration  
information. If the DHCPv6 server goes away when using SLAAC for  
addressing, configuration information is already there.


I have a lot of problems with DHCP and most people don't _need_  
it. Still,


can you explain how 'most people don't need it'?? is that because most
people have an admin to go configure their DNS servers in their
resolver config?? Consumer Internet users are a great example of this,
if necessary an ISP can pass out new DNS servers, and in 8-10 days
easily remove the old DNS servers from the network, or move them to
another place in the network seemlessly without having to touch each
consumer device.

Why would anyone NOT want that?? what replaces that option in current
RA deployments?


Again, this seems to be confusion with SLAAC vs. "no DHCPv6 what so  
ever". I could be wrong though - I don't want to be putting words in  
to  Iljitsch's mouth.


--
Nathan Ward

RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

[TJ]

>> Your routers fail frequently?  And does your traffic continue to get
>> forwarded?  Perhaps through another router?
>
>More frequently than the DHCP server, but neither are "frequent" events.
>Cisco's software is not 100% perfect, and when you plug it into moderately
>unstable things like phone lines (DSL) and cable networks, those little
bugs
>cause reloads -- you'd think they'd have better error handling, but they
>don't. (I don't buy millions in equipment from Cisco so they don't care
>about my problems.)  While I could use backup links, flip-floping between
>ISPs with different addresses is not ideal (and that's as true for
>v6 as v4.)

But my real point was if the router is failed, traffic isn't being forwarded
regardless of how the host got the information ... correct?

And vendor support issues are a layer 8-11 problem ... no layer 3 fix for
that!
(8-11 == people politics religion money ... in no particular order)


>> Why is there a problem with RAs being the first step, possibly
>> including prefix info or possibly just hinting @ DHCPv6?
>
>Because it doesn't fit the needs of *every* network.  In fact, it's only
>"good enough" for very few networks.  As such it just adds more useless
>layers of bloat.

Obviously we disagree, fundamentally.


>> Well, as it stands now the RA isn't useless.
>...
>> Also, it is not true in every case that hosts need a "lot more" than
>> an address.
>> In many cases all my machine needs is an address, default gateway and
>> DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
>
>It's useless.  It does NOT provide enough information alone for a host to
>function.  In your own words, you need a DNS server.  That is NOT provided
>by RA thus requires yet another system to get that bit of configuration to
>the host -- either entered manually, DHCPv6, or from IPv4 network
>configuration (ie. DHCP!)  Forcing this BS on the world is a colossal
waste.
>We've had a system to provide *ALL* the information a host needs or wants
in
>the IPv4 world for years.  Why it's not good enough for IPv6 is beyond me.

Technically, that is a gap RFC5006 would fill - once supported, which should
have been long before now but too late for that, eh?

And I think we also disagree on a fundamental aspect, specifically - I see
it this way:
1) the RAs are there primarily to allow a router to provide
information about itself to the hosts on the link
a) which becomes the default gateway from the hosts'
perspective
2) Everything after that is a separate thing, namely - host
addressing and "other" configuration
a) which could be SLAAC, by including a prefix in the RA ...
and maybe a DNS server option, someday.
-) and maybe Stateless DHCPv6 as well, for the DNS
or other missing info
b) which could be DHCPv6, providing all of the addressing
and config info (but not router info)

I think the key factor to our disagreement is that I think it makes great
sense for the router to provide information about itself to the hosts, and
you'd rather it be centralized.  I don't really care either way, to be
honest - it just seems to make good sense (to me) the way it works now.  If
I understand correctly the answer, from your standpoint, would be to author
an RFC specifying a default gateway option for DHCPv6 (and maybe a prefix
length option as well?).  And then get DHCPv6 client functionality itself,
and this option, more widely supported (and in fact, "on by default").

As to "why it's not good enough" ... well, suffice it to say this debate has
raged for a LNG time and apparently sufficient consensus (for reasons
good or ill) was reached at some point for the way it is now.  Build
consensus to change that (factoring in the pain it would cause to current
deployments) ... maybe starting off small, with just defining the option and
convincing a major vendor or two to implement it ... if the world agrees, it
will migrate to working that way ... isn't that how this whole open
standards process is supposed to work? 
(OK, that last question was a bit rhetorical and was not meant to spark a
debate about this being the IETF vs the IVTF vs the __ etc. etc.
Sorry!)

Failing that (or while that is ongoing?) ... we have what we have.  
And it does indeed work, today, for almost all * cases.  
So let's get deploying, go team!

* - as discussed at length on this list and others


/TJ
"Be conservative in what you send and liberal in what you accept." --Jon
Postel
"The future belongs to those who see possibilities before they become
obvious." --unknown
"In essentials, unity; in non-essentials, liberty; in all things, charity"
--various
"Everyone's a hero in their own way, in their own not that heroic way."
--Joss Whedon

unsolicited name transfers from Godaddy

[Zaid Ali]

I have been receiving a high number of unsolicited domain transfer requests 
from Godaddy and have also written to Godaddy support about unsolicited domain 
transfer requests. Since I am not a Godaddy customer I got a standard talk to 
the hand. I have colleagues confirming that some similar chatter is also 
happening in the ICANN space with respect to Godaddy. 

Are folks here experiencing this also?

Thanks,
Zaid

Re: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH

[Eloy Paris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Rob,

Eloy Paris from the Cisco PSIRT here. Please see below (inline) for
some comments regarding the issue you brought up in your email to the
cisco-nsp and nanog mailing lists this past Jan. 16th:

On Fri Jan 16 07:57:52 2009, Rob Shakir wrote:

> Strict RFC 4893 (4-byte ASN support) BGP4 implementations are
> vulnerable to a session reset by distant (not directly connected)
> ASes. This vulnerability is a feature of the standard, and unless
> immediate action is taken an increasingly significant number of
> networks will be open to attack. Accidental triggering of this
> vulnerability has already been seen in the wild, although the limited
> number of RFC 4893 deployments has limited its effect.
>
> Summary:
> It is possible to cause BGP sessions to remotely reset by injecting
> invalid data into the AS4_PATH attribute provided to store 4-byte ASN
> paths. Since AS4_PATH is an optional transitive attribute, the invalid
> data will be transited through many intermediate ASes which will not
> examine the content. To be vulnerable, an operator does not have to
> be actively using 4-byte AS support. This problem was first reported
> by Andy Davidson on NANOG in December 2008 [0], furthermore we have
> been able to demonstrate that a device running Cisco IOS release
> 12.0(32)S12 behaves as per this description.
>
> Details:

[...]

Cisco Bug CSCsx10140 was filed for Cisco IOS. Cisco IOS behaves exactly
as you described - upon receipt of AS_CONFED_SEQUENCE data in the
AS4_PATH attribute IOS will send a NOTIFICATION message to the peer,
which causes a termination of the BGP session. After the fix for this
bug IOS will ignore AS_CONFED_SEQUENCE data in the AS4_PATH attribute of
received BGP UPDATE messages and continue to process the UPDATE. This is
the new behavior that the revised RFC 4893 will require.

CSCsx18598 was filed for Cisco IOS XR. Cisco IOS XR doesn't reset the
session but accepts and forwards the invalid AS4_PATH data, so this bug
was filed to change this behavior.

CSCsx23179 was filed for Cisco NX-OS (for the Nexus switches.) Cisco
NX-OS behaves like IOS (it will reset the BGP session when it sees
AS_CONFED_SEQUENCE data in the AS4_PATH attribute), and this bug was
filed to change this and have the BGP implementation in Cisco NX-OS
follow the revised RFC 4893.

The Release Notes for each bug may have some additional
information. These are available via the Bug Toolkit on cisco.com
(http://tools.cisco.com/Support/BugToolKit)

To date, the only version of Cisco IOS that supports 4-byte AS numbers
is 12.0(32)S12, released in late December. A fix to the 12.0(32)Sxx
branch has been committed so the next 12.0(32)S-based release will have
the fix. 12.0(32)SY8 is coming out soon, and it will also have support
for 4-byte AS numbers, as well as the fix for the problem.

Thanks for bringing attention to this issue and for working with us,
specifically with the Cisco TAC, to get to the bottom of it and test
the proposed fix.

Cheers,

- -- 

Eloy Paris
Cisco PSIRT
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmR9OoACgkQagjTfAtNY9jv5ACgg3fKuuWKv38h8F8d8QHBML5J
CTsAnAnGMB/fBIQhk5z4E922JlhHVU5A
=FSOP
-END PGP SIGNATURE-

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

[Ricky Beam]

On Mon, 09 Feb 2009 21:11:50 -0500, TJ  wrote:

Your routers fail frequently?  And does your traffic continue to get
forwarded?  Perhaps through another router?


More frequently than the DHCP server, but neither are "frequent" events.   
Cisco's software is not 100% perfect, and when you plug it into moderately  
unstable things like phone lines (DSL) and cable networks, those little  
bugs cause reloads -- you'd think they'd have better error handling, but  
they don't. (I don't buy millions in equipment from Cisco so they don't  
care about my problems.)  While I could use backup links, flip-floping  
between ISPs with different addresses is not ideal (and that's as true for  
v6 as v4.)



Why is there a problem with RAs being the first step, possibly including
prefix info or possibly just hinting @ DHCPv6?


Because it doesn't fit the needs of *every* network.  In fact, it's only  
"good enough" for very few networks.  As such it just adds more useless  
layers of bloat.



Well, as it stands now the RA isn't useless.

...

Also, it is not true in every case that hosts need a "lot more" than an
address.
In many cases all my machine needs is an address, default gateway and DNS
server (cheat off of v4 | RFC5006 | Stateless DHCPv6).


It's useless.  It does NOT provide enough information alone for a host to  
function.  In your own words, you need a DNS server.  That is NOT provided  
by RA thus requires yet another system to get that bit of configuration to  
the host -- either entered manually, DHCPv6, or from IPv4 network  
configuration (ie. DHCP!)  Forcing this BS on the world is a colossal  
waste.  We've had a system to provide *ALL* the information a host needs  
or wants in the IPv4 world for years.  Why it's not good enough for IPv6  
is beyond me.


--Ricky

RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[TJ]

>> Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply
>> tend to omit IPv6 completely, and generally require everything not
>> explicitly called out to be disabled ... thus, no IPv6 on any network
>> that falls under any of these regulations.
>
>TJ - You attempted to say that for PCI, and then it was shown that there's
>clear language regarding compensating controls that could easily be
>considered applicable.  I haven't had the honor of running an IPv6-enabled
>system through a PCI compliance audit, but have little doubt that it will
>happen shortly and will require auditor education just like every other
>technology introduction.

First off - me neither; this is related to my realm, but not within it.

Secondly - we largely agree; although I think the level of "auditor
education" that will need to occur is more burdensome than might be expected
- partially due to lack of underlying guidance.  Again, I don't live and
breathe compliance, but the best I have seen is that some have started
developing these procedures/guidelines.  Started.

Additionally, I suspect (but do not know that) the compensating control
clause is meant to be a special case ... I'd love to hear more ...


>I run a data center which specializes in secure, compliant managed
services,
>and have been through hundreds of audits in support of our clients which
>include federal civilian, federal defense, health care, and financial
>services firms.  There are very few IT standards which have precise
protocol
>or address requirements embedded in them, and there is almost always an
>opportunity to provide compensating controls where necessary.  If you've
got
>an example from one of the above compliance frameworks to the contrary that
>would actually preclude IPv6 deployment, please cite it.

Sure, general language meant to be semi-technology-independent.

Perhaps not outright preclude deployment altogether, but certainly cause
(possibly rather expensive) delays or complications.
Note - I am merely pseudo-quoting from what auditors and policy people have
told me and my colleagues, through the course of several briefings.

Allow me to more directly quote one of my colleagues:
* Current C&A auditors are not checking for IPv6-based vulnerabilities. They
do not understand the process or have the tools to do IPv6 C&A.
* IPv6 is already deployed in a surprising number of IT systems, networks,
and software - we find it operating in audits of agencies and enterprises
that are "not deploying IPv6"
* Is your FISMA C&A complete/valid without considering IPv6?

Note that the last bullet is a somewhat rhetorical question - the answer is
obviously no, but you might be surprised to see the look on some peoples'
faces when you tell them that ...

Or let's take this -
http://72.34.43.90/IPV6/usipv6_reston_2004/thu/Kruger-Schifalacqua.pdf
... and while the goal is to show that/how it is possible to obtain your
ATO, I think it makes a strong case in the opposite direction.
How can you be assured that you live up to "Do no harm" when the definition
of harm, based on the (until very recently) absent standards upon which to
make this basis?  Or with a staff (local network or auditor) that is not
IPv6 savvy at day -1  (meaning prior to the expected deployment of IPv6).  
(And in fact, after just re-reading it - this presentation seems to make a
case for disabling DAD (albeit in a specific case) - something that violates
the protocol spec as well as the DoD APL requirements ... so who wins that
decision?)

To take it a step further (and perhaps be over-simplsitic): 
The guidance to "disable all unused protocols and services" applies.
So, if you aren't using IPv6 today it must be off.
If you want to turn it on, you must redo your C&A.
That costs money, therefore doesn't happen - atleast not "soon".
Therefore, no IPv6.

I would love to hear more from those who have done C&A (of any flavor) on an
IPv6 enabled network - specifically, was IPv6 actually considered/evaluated
and any problems it caused for the process.


>> (In other words (again, generally speaking) - if you run IPv6, your
>> current C&A (or perhaps your CTO (Certificate To Operate)) is
>> invalid).
>
>Sure... change your network, and you need to update your C&A package as
part
>of maintaining your ATO.  It's up to your DAA as to whether they want to
use
>IPv6 prior to equipment being certified under the DoD IPv6 Profile.

But that is my point - Do any of the compliance frameworks / requirements /
audit standards today address IPv6, or detail how it could be implemented in
such a fashion as to 'pass' an audit (including the "in-house" /
consultant-specific audit guidelines)?  If it can be done, but is solely a
"you and your (current) auditor figure it out, on a case by case basis,
every time" I would argue that that is not good enough for the general case.

And while I agree with you, "any change = redo" I would argue that not
everyone realizes that all of their C&A work will need to be re-done

Re: Is whois.apnic.net down? (IPv6-MW)

[jay]

Quoting Scott Howard :


On Tue, Feb 10, 2009 at 8:48 AM, Dale Carstensen  wrote:


>I get "Connection timed out" on whois commands to it.

Sorry to attempt to answer my own question, but maybe it's the fires
in Australia, as the last traceroute hop is a Brisbane.telstra.net



Brisbane (where APNIC is) is close to 1000 miles from Melbourne (where the
fires are).
Ironically the state Brisbane is in is currently experiencing very bad
flooding over most of the state...

But I digress.   www.apnic.net is also down over IPv4, but reachable over
IPv6.  whois.apnic.net doesn't seem to have an IPv6 address.

  Scott.



  933 ms33 ms33 ms  203.119.76.66
 1036 ms35 ms35 ms  whois.apnic.net [202.12.29.13]

Trace complete.

It's reachable from where I'm sitting (NSW)

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[John Curran]

On Feb 10, 2009, at 8:52 AM, TJ wrote:


Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply  
tend to
omit IPv6 completely, and generally require everything not  
explicitly called
out to be disabled ... thus, no IPv6 on any network that falls under  
any of

these regulations.


TJ - You attempted to say that for PCI, and then it was shown that
there's clear language regarding compensating controls that could
easily be considered applicable.  I haven't had the honor of running
an IPv6-enabled system through a PCI compliance audit, but have little
doubt that it will happen shortly and will require auditor education
just like every other technology introduction.

I run a data center which specializes in secure, compliant managed
services, and have been through hundreds of audits in support of
our clients which include federal civilian, federal defense, health
care, and financial services firms.  There are very few IT standards
which have precise protocol or address requirements embedded in them,
and there is almost always an opportunity to provide compensating
controls where necessary.  If you've got an example from one of the
above compliance frameworks to the contrary that would actually
preclude IPv6 deployment, please cite it.

(In other words (again, generally speaking) - if you run IPv6, your  
current

C&A (or perhaps your CTO (Certificate To Operate)) is invalid).


Sure... change your network, and you need to update your C&A package
as part of maintaining your ATO.  It's up to your DAA as to whether
they want to use IPv6 prior to equipment being certified under the
DoD IPv6 Profile.

/John
John Curran
EVP, COO, CTO
ServerVault Corp

[NANOG-announce] NANOG45 Updates

[Betty J. Burke]

Dear Community...

One more thank you to Terremark for hosting NANOG45, and to all those in 
the Dominican Republic who made our stay a bit more enjoyable.

However, it sure is nice to be home. Before moving on to our next adventure 
together, a few pieces of closure information for NANOG45 follows:


Survey open until Friday, February 13, be sure you completed yours!!

http://nanog.org/meetings/nanog45/agenda.php
Now includes the video archive

Meeting attendance and survey information will be posted
in approximately 2 weeks.

Moving forward, we are excited about NANOG46 in Philly! and look forward to 
seeing everyone there.

Sincerely,
Betty
Merit NANOG Community Project Manager

___
NANOG-announce mailing list
nanog-annou...@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Is whois.apnic.net down? (IPv6-MW)

[Scott Howard]

On Tue, Feb 10, 2009 at 8:48 AM, Dale Carstensen  wrote:

> >I get "Connection timed out" on whois commands to it.
>
> Sorry to attempt to answer my own question, but maybe it's the fires
> in Australia, as the last traceroute hop is a Brisbane.telstra.net
>

Brisbane (where APNIC is) is close to 1000 miles from Melbourne (where the
fires are).
Ironically the state Brisbane is in is currently experiencing very bad
flooding over most of the state...

But I digress.   www.apnic.net is also down over IPv4, but reachable over
IPv6.  whois.apnic.net doesn't seem to have an IPv6 address.

  Scott.

Re: Is whois.apnic.net down?

[Matthew Palmer]

On Tue, Feb 10, 2009 at 09:48:21AM -0700, Dale Carstensen wrote:
> >I get "Connection timed out" on whois commands to it.
> 
> Sorry to attempt to answer my own question, but maybe it's the fires
> in Australia, as the last traceroute hop is a Brisbane.telstra.net
> domain name.

Brisbane's about 2000km north of the major fires.  Instead, they're
recovering from a cyclone.

Gotta love this country.

- Matt

-- 
Talk about unlucky. D'you know, if I fell in a barrel of tits I'd come out
sucking me thumb.
-- Seen on the 'net:
 http://thelawwestofealingbroadway.blogspot.com/2006/01/bang-to-rights.html

Re: Is whois.apnic.net down?

[Brandon Galbraith]

On 2/10/09, Dale Carstensen  wrote:
>
> >I get "Connection timed out" on whois commands to it.
>
> Sorry to attempt to answer my own question, but maybe it's the fires
> in Australia, as the last traceroute hop is a Brisbane.telstra.net
> domain name.
>
> Backhoe fade I'm used to. But now fire fade? Lovely.

-brandon


-- 
Brandon Galbraith
Voice: 630.400.6992
Email: brandon.galbra...@gmail.com

RE: Is whois.apnic.net down?

[Dave Larter]

Times out for me as well.  Last hop in AU.

8   240 ms   238 ms   239 ms  10.14.254.125.unassigned.comindico.com.au
[125.254.14.10]
 

-Original Message-
From: Dale Carstensen [mailto:d...@lampinc.com] 
Sent: Tuesday, February 10, 2009 11:45 AM
To: nanog@nanog.org
Subject: Is whois.apnic.net down?

I get "Connection timed out" on whois commands to it.

Re: Is whois.apnic.net down?

[Dale Carstensen]

>I get "Connection timed out" on whois commands to it.

Sorry to attempt to answer my own question, but maybe it's the fires
in Australia, as the last traceroute hop is a Brisbane.telstra.net
domain name.

Is whois.apnic.net down?

[Dale Carstensen]

I get "Connection timed out" on whois commands to it.

New IPv4 blocks allocated to RIPE NCC

[Alex Le Heux]

[Apologies for duplicate mails]

Dear Colleagues,

The RIPE NCC received the IPv4 address ranges 109/8 and 178/8 from the
IANA in January 2009. We will begin allocating from these ranges in the
near future.

The minimum allocation size from these two /8s has been set at /21.

You may wish to adjust any filters you have in place accordingly.

More information on the IP space administered by the RIPE NCC
can be found at:

https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html

Please also note that several "pilot" prefixes are being announced from
each /8. These prefixes are:

178.0.0.0/16, pingable 178.0.0.1
178.1.0.0/21, pingable 178.1.0.1
178.1.24.0/24, pingable 178.1.24.1
109.0.0.0/16, pingable 109.0.0.1
109.1.0.0/21, pingable 109.1.0.1
109.1.24.0/24, pingable 109.1.24.1

They all originate in AS12654.

More information on this "pilot" activity is available in the
document "De-Bogonising New Address Blocks", which can be found at:

http://www.ripe.net/ripe/docs/ripe-351.html

Best regards,

Alex Le Heux
RIPE NCC
Policy Implementation Co-ordinator

Re: IPv6 delivery model to end customers

[Marshall Eubanks]

On Feb 10, 2009, at 9:01 AM, TJ wrote:


My pleasure, now everyone - feel free to ring up your local
sales/support rep and "encourage" their product to implement  
this ...

please!


What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to  
create L3

filter rules in L2 devices), is a standard needed or is it obvious to
vendors how to implement it?



An analogy to "DHCP Guard" - yes, please do encourage them to also  
do this.

(And an RFC might not be a bad idea ... )

While we are at it - MLD Snooping should (IMHO) be a switch's default


s/MLD/MLD v2/

Marshall



behavior as well!

RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[TJ]

>Considering that RFC1918 says nothing about IPv at all, 

That may technically be true, but it does explicitly reference IPv4
addresses.  
Oh, and when RFC1918 (or more correctly, RFC1597) was written, "IP",
"TCP/IP", etc. all directly meant IPv4.  
(RFC1597 @ 03/94 ... RFC1883 @ 12/95)

RE: IPv6 delivery model to end customers

[TJ]

>> My pleasure, now everyone - feel free to ring up your local
>> sales/support rep and "encourage" their product to implement this ...
>> please!
>
>What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to create L3
>filter rules in L2 devices), is a standard needed or is it obvious to
>vendors how to implement it?


An analogy to "DHCP Guard" - yes, please do encourage them to also do this.
(And an RFC might not be a bad idea ... )

While we are at it - MLD Snooping should (IMHO) be a switch's default
behavior as well!

RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[TJ]

>However the PCI DSS does contain a "Compensating controls" section, which
>allows for the use of functionality which "provide[s] a similar level of
>defense" to the stated requirements, where the stated requirements can not
>be followed due to "legitimate technical or documented business
constraints"
>
>Now the fact that RFC1918 addresses don't work with IPv6 is clearly a
>"legitimate technical ... constraint", so as long as you could successfully
>argue that a stateful firewall or other measures in place provided
>equivalent security as NAT you should be fine.


Excellent loophole!
Although I wonder how many clueful auditors are out there and able to make
this fly ...

RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[TJ]

>> >> > The SOX auditor ought to know better.  Any auditor that
>> >> > requires NAT is incompenent.
>> >>
>> >> Sadly, there are many audit REQUIREMENTS explicitly naming NAT and
>> >> RFC1918 addressing ...
>> >
>> >SOX auditors are incompetent. I've been asked about anti-virus
>> >software on UNIX servers and then asked to prove that they run
>UNIX.
>>
>> Fair enough, but my point was that it isn't the auditors' faults in
>> _all_ cases.
>> When the compliance explicitly requires something they are required to
>> check for it, they don't have the option of ignoring or waving
>requirements ...
>> and off the top of my head I don't recall if it is SOX that calls for
>> RFC1918 explicitly but I know there are some that do.
>
>   Please cite references.
>
>   I can find plenty of firewall required references but I'm
>   yet to find a NAT and/or RFC 1918 required.
>

Minor correction (I did say I wasn't sure it was SOX) ... It is PCI that
requires RFC1918 and translation.
For SOX, what is your assessment of (IPv6) internal controls and risk based
on?  Has anyone (with the authority to do so) developed and released
guidance?  Do we have a repository of "current best practices" to rely on
(yet)?

Interestingly, with SOX, I am curious if lack of IPv6 preparation will play
into the risk assessment as well :).

Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to
omit IPv6 completely, and generally require everything not explicitly called
out to be disabled ... thus, no IPv6 on any network that falls under any of
these regulations.  We are just starting to see finalized product profiles
and STIGs for IPv6 configuration - without that guidance Defense networks
really couldn't  run IPv6 either.

(In other words (again, generally speaking) - if you run IPv6, your current
C&A (or perhaps your CTO (Certificate To Operate)) is invalid).

Re: Private use of non-RFC1918 IP space

[Trey Darley]

Just for the record, the original post was in reference to use of
non-RFC1918 space on an *air-gapped* network.

--Trey

>> Let's face it - they're going to have to come up with much more
creative
>> $200/hour chucklehead consultants to burn through that much anytime soon.

>> Anybody feel like starting a pool for when we'll see a posting to NANOG
about somebody who's managed to burn through a /32?



++++
Kingfisher Operations
Trey Darley - Principal

RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[TJ]

>> IPTables is decent firewall code.
>
>Not really.  It's quite complicated for a non-engineer type to manage.
>Think of all the unpatched windows xp/vista users of the world.
>
>> It's free.
>...
>> Further, since more and more CPE is being built on embedded linux,
>> there's no reason that IPTables isn't a perfectly valid approach to
>> the underlying firewall code.
>
>No. It's not.  While you might not be paying anyone for the software, it
>does come with some significant costs... a moderately powerful processor
and
>a lot of memory.  Ah, "but both are cheap these days, and getting cheaper",
>you say.  Tell me where I can get 500MHz+ processors and 16+ MB of ram for
>"pennies".  Case in point... (in case you missed it) Linksys stopped using
>Linux on their popular WRT54G line years ago in favor of vxWorks because it
>took less resources and therefor meant they could use less memory (flash
and
>ram) and save money despite paying a license fee for vxWorks. (They still
>use vxWorks on the 54g, but have used linux on their newer (much more
>expensive) hardware.)

Well thank goodness that VxWorks 6.x (or with 3rd party hackery) can both do
IPv6 and can have firewalling functionality as well (or so Google tells me).
Oh, and Linux can be tiny - even with iptables.  I suspect Cisco (nee
Linksys) chose VxWorks for a number of reasons, "footprint" being but one of
them.


>DSL and cable modems are extremely simple devices.  I'm amazed they have
any
>amount of "router" in them at all.  And I've yet to see one running Linux.
>(the 2 popular brands around here -- westell and motorola -- run
>vxworks.)

Actually, the DOCSIS 3.0 spec may be changing that ... "eRouter" ... 

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[Valdis . Kletnieks]

On Tue, 10 Feb 2009 18:03:40 +1100, Matthew Palmer said:
> Considering that RFC1918 says nothing about IPv at all, could that be a
> blocker for deployment in general?  That'd also make for an interesting
> discussion re: other legacy protocols (IPX, anyone?)...

I was all set to call shenanigans on this one - except I double-checked the
dates on the RFCs, and RFC1752 pre-dates 1918 by a year...

Not sure what it says about our industry that both RFCs are 13+ years old
now, and we still can't collectively do either one right...


pgpUXbgEq87yq.pgp
Description: PGP signature

Re: Network equipments process utilization

[Elmar K. Bins]

li...@memetic.org (Adam Armstrong) wrote:

> >>>   CPU load _always_ jumps to 100% for short periods of
> >>>   time - BGP needs something calculated ;-) I get interested
> >>>   whenever CPU load _stays_ high
> >>>  
> >>Yeah - Cisco would like to know why as well:
> >>http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html
> >>
> >
> >I know ;-)
> >
> >But: This is not a churn problem, it's a problem of slow CPUs in
> >allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my
> >76's, as RP. Still, this is getting off-topic.
> >  
> 
> The MSFC4 in the RSP720 has a 1.2GHz 8548 PPC whereas the NPE-G2 has a 
> 1.67GHz 7448 PPC.
> 
> I'd guess the performance isn't all that far apart, especially as the 
> MSFC4's processor isn't doing any forwarding.

That's why I wrote "with SUPs" (and not RSPs). RSP is fairly new, and
they got it right this time.

Re: Network equipments process utilization

[Adam Armstrong]

Elmar K. Bins wrote:

h...@efes.iucc.ac.il (Hank Nussbacher) wrote:

  

 - slow-CPU boxes like everything Cisco with SUPs, since the
   CPU load _always_ jumps to 100% for short periods of
   time - BGP needs something calculated ;-) I get interested
   whenever CPU load _stays_ high
  

Yeah - Cisco would like to know why as well:
http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html



I know ;-)

But: This is not a churn problem, it's a problem of slow CPUs in
allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my
76's, as RP. Still, this is getting off-topic.
  


The MSFC4 in the RSP720 has a 1.2GHz 8548 PPC whereas the NPE-G2 has a 
1.67GHz 7448 PPC.


I'd guess the performance isn't all that far apart, especially as the 
MSFC4's processor isn't doing any forwarding.


adam.

Re: Network equipments process utilization

[Elmar K. Bins]

h...@efes.iucc.ac.il (Hank Nussbacher) wrote:

> >  - slow-CPU boxes like everything Cisco with SUPs, since the
> >CPU load _always_ jumps to 100% for short periods of
> >time - BGP needs something calculated ;-) I get interested
> >whenever CPU load _stays_ high
> 
> Yeah - Cisco would like to know why as well:
> http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html

I know ;-)

But: This is not a churn problem, it's a problem of slow CPUs in
allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my
76's, as RP. Still, this is getting off-topic.

Elmar.

Re: Network equipments process utilization

[Hank Nussbacher]

At 09:39 AM 10-02-09 +0100, Elmar K. Bins wrote:


  - slow-CPU boxes like everything Cisco with SUPs, since the
CPU load _always_ jumps to 100% for short periods of
time - BGP needs something calculated ;-) I get interested
whenever CPU load _stays_ high


Yeah - Cisco would like to know why as well:
http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html

:-)
-Hank

Re: Network equipments process utilization

[Elmar K. Bins]

Good morning (from here),

lion...@samsung.com (???×?) wrote:

> I wonder which percentage is good level of CPU and Memory util of network 
> equipment ?
> In my case, I try to keep under 30% cpu util and 70% memory util. My most 
> equipment are Cisco product. 
> I have no technical reference about that, it is just a rule of mine or my 
> predecessor.
> Could you tell me how other operators are doing ? what is your operation 
> baseline ? or is there any guideline about process utilization ?

I'm trying to keep all Cisco equipment idle, if at all possible,
since there may come worse times...

Typical exceptions are

  - software forwarding routers, where CPU load is directly
depending on current traffic levels; should the load stay
above 15-20% all the time, it's time for an upgrade

  - slow-CPU boxes like everything Cisco with SUPs, since the
CPU load _always_ jumps to 100% for short periods of
time - BGP needs something calculated ;-) I get interested
whenever CPU load _stays_ high

  - switches; Cisco switches need like 5% CPU to blink the LEDs ;)


It gets more interested with packet filters and load balancers,
where CPU loads depend on traffic levels and patterns. I try to
keep the baseline between 5 and 10%.

HTH,
Elmar.

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[Mohacsi Janos]

On Mon, 9 Feb 2009, Ricky Beam wrote:

On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk  
wrote:

Non-NAT firewalls do have some appeal, because they don't need to mangle
the packets, just passively observe them and open pinholes when
appropriate.


This is exactly the same with NAT and non-NAT -- making any anti-NAT 
arguments null.


In the case of NAT, the "helper" has to understand the protocol to know what 
traffic to map.


In the case of a stateful firewalling ("non-NAT"), the "helper" has to 
understand the protocol to know what traffic to allow.


Subtle difference, but in the end, the same thing... if your gateway doesn't 
know what you are doing, odds are it will interfere with it.  In all cases, 
end-to-end transparency doesn't exist. (as has been the case for well over a 
decade.)



You arguments making any pro-NAT arguments null. You agree, that NAT and 
Stateful Packet Inspetion firewall doing similar things. Advantage of the 
SPI firewall is that you have to maintain only one forwarding/state table. 
While in NAT you have to maintain two table. Therefore SPI firewall is 
more scalable


Regards,


Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882





--Ricky