date:20100427


Andy Davidson wrote:

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
  

Did you use Yahoo IM, AIM, or Skype?
  

Yes, yes, and yes.  Works fine.



What about every other service/protocol that users use today, 
and might be invented tomorrow ?  Do  will they all work with 
NAT ?
  


Anyone inventing a new service/protocol that doesn't work with NAT isn't 
planning on success.

Do many others work as well or act reliably through NAT ?
  

Yes.

Will it stop or hamper the innovation of new services on the
internet ?
  

Hasn't so far.

The answer to these questions isn't a good one for users, so
as the community that are best placed to defend service quality
and innovation by preserving the end to end principal, it is 
our responsibility to defend it to the best of our ability.
  
Firewalls will always break the end-to-end principle, whether or not 
addresses are identical between the inside and outside or not.

So get busy - v6 awareness, availability and abundancy are
overdue for our end users.
  

Maybe. Most of them are perfectly happy.

Matthew Kaufman

Re: VPN over Comcast

2010-04-27 Thread gladney

Are you running IPSec over UDP?  We've had problems in Maryland with IPSec over 
UDP to Comcast customer.  Try switching to TCP.

Gary
--Original Message--
From: Michael Malitsky
To: nanog@nanog.org
Subject: VPN over Comcast
Sent: Apr 27, 2010 1:42 PM

I will probably be laughed at, but I'll ask just in case.

We are having particularly bad luck trying to run VPN tunnels over
Comcast cable in the Chicago area.  The symptoms are basically complete
loss of connectivity (lasting minutes to sometimes hours), or sometimes
flapping for a period of time.  More often than not, a reboot of the
cable modem is required.  The most interesting ones involve the
following: a PIX or ASA configured as an EZvpn client, connecting to a
3000 concentrator, authentication over RADIUS.  When I go to look at the
RADIUS logs, I see connections from the same box with small intervals.
Timeout is 8 hours, so theoretically I should see 3 connections in a
24-hr period.  In some cases, I see dozens, in the most egregious cases,
thousands over a 24-hour period.  I am taking that as an indicator of a
really unstable Comcast circuit.  We have not had this problem with any
other ISP, anywhere in the country.
I am pretty much down to telling customers to find another provider...  

Any thoughts or ideas on the matter will be appreciated.

PS.  To be fair (?) to Comcast, this is not a ubiquitous problem.  It
affects about 25% of the installations I get to see.

Sincerely,
Michael Malitsky

Sent via BlackBerry from T-Mobile

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Nick Hilliard

On 27/04/2010 18:48, Matthew Kaufman wrote:
 Anyone inventing a new service/protocol that doesn't work with NAT isn't
 planning on success.

You mean, like multisession bgp over tls?

Nick,
just sayin'

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Valdis . Kletnieks

On Tue, 27 Apr 2010 10:48:54 PDT, Matthew Kaufman said:

 Anyone inventing a new service/protocol that doesn't work with NAT isn't 
 planning on success.

Only true in the IPv4 world.  IPv6 will hopefully be different.

  The answer to these questions isn't a good one for users, so
  as the community that are best placed to defend service quality
  and innovation by preserving the end to end principal, it is 
  our responsibility to defend it to the best of our ability.

 Firewalls will always break the end-to-end principle, whether or not 
 addresses are identical between the inside and outside or not.

The difference is that if a protocol wants to be end-to-end, I can fix a
firewall to not break it.  You don't have that option with a NAT.

  So get busy - v6 awareness, availability and abundancy are
  overdue for our end users.

 Maybe. Most of them are perfectly happy.

Most of the US population was perfectly happy just before the recent
financial crisis hit.  Ignorance is bliss - but only for a little while.



pgp37Bg0L9uoK.pgp
Description: PGP signature

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Dave Israel

On 4/27/2010 1:36 PM, Andy Davidson wrote:
 On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
   
 Did you use Yahoo IM, AIM, or Skype?
   
 Yes, yes, and yes.  Works fine.
 
 What about every other service/protocol that users use today, 
 and might be invented tomorrow ?  Do  will they all work with 
 NAT ?
   

Sure, I can invent a service/protocol that doesn't work with NAT.  While
I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an
architectures using less than 256 bits of memory addressing.  I bet
it'll be popular!


 Do many others work as well or act reliably through NAT ?
   

Yes, nearly everything that end users use works great through NAT,
because end users are often behind NAT and for a service to be popular,
it has to be NAT-friendly.  Protocols that are not NAT friendly and yet
survive are generally LAN applications that are resting on their
NAT-unferiendliness and calling it security.

 Will it stop or hamper the innovation of new services on the
 internet ?
   

Nope.

 The answer to these questions isn't a good one for users, so
 as the community that are best placed to defend service quality
 and innovation by preserving the end to end principal, it is 
 our responsibility to defend it to the best of our ability.
   

The end to end principle only helps service quality and innovation when
the services are built on an end to end model.  In a client-server world
where addresses only identify groups of endpoints and individual
identification is done at higher layers (which is what the ipv4+NAT
Internet is looking like), end to endness is an anomaly, not the norm.

 So get busy - v6 awareness, availability and abundancy are
 overdue for our end users.
   

Nearly all of the end users don't give a rat's hindquarters about ipv6. 
It gives them nothing they know that they want.  Meanwhile, those who do
know they want it are getting used to working around it, using PAT
tricks and STUN services.  Should people *have* to use those services? 
No.  But there's so many other things that we shouldn't have to do, but
we do anyway because that's how it works, that these NAT-circumvention
tricks are not a dealbreaker.

Meanwhile, the NATification of the Internet continuously increases the
contrast between services (with real addresses) and clients (with shared
addresses).  Over time, this differentiation will increase and become
more and more a standard (a de facto one if not an actual codified
one.)  Clients will have shared, ephemeral addresses, and services will
have stable ones.  This helps ensure that clients cannot generally
communicate without a facilitating service, and every transaction will
then have a middleman, somebody you have to pay somehow to get your
services.  You may pay in cash, by watching commercials, by sacrificing
personal information, or by submitting your communciations to analysis
by others, but somehow, you will pay.  The vast majority of users won't
care; they communicate that way now, and it does not bother them much. 
It's only those few who want to communicate without paying, in time,
money, or privacy, or to communicate in ways other than the standard
protocols, who will really suffer.  And their complaints will have to
fight against the voice of those who will say, well, if you make it end
to end, then businesses lose money, and people will be able to share
files again and violate copyrights, and all these things will cost jobs
and tax dollars, etc, etc.

If you want to avoid that future, I strongly suggest you deploy ipv6 and
pressure others to do the same.  But you're going to need to use valid
arguments, about privacy and protection from the deprecations of
unscrupulous middlemen, instead of insisting that the Internet will
break down and die and locusts will descend from the heavens and eat our
first born if we don't.

-Dave

Re: comcast enterprise/carrier services

 Looking for a sales contact for Comcast enterprise/carrier services for
 there Ethernet product thanks.

there as contrasted with here?  I don't understand.

-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Jon Lewis


On Tue, 27 Apr 2010 valdis.kletni...@vt.edu wrote:


The difference is that if a protocol wants to be end-to-end, I can fix a
firewall to not break it.  You don't have that option with a NAT.


Maybe we want end-to-end to break.

Firewalls can trivially be misconfigured such that they're little more 
than routers, fully exposing all the hosts behind them to everything bad 
the internet has to offer (hackers, malware looking to spread itself, 
etc.).


At least with NAT, if someone really screws up the config, the inside 
stuff is all typically on non-publicly-routed IPs, so the worst likely to 
happen is they lose internet, but at least the internet can't directly 
reach them.


This has to be one of the bigger reasons people actually like using NAT.

--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: VPN over Comcast


On Apr 27, 2010, at 10:48 AM, Kevin Day wrote:

 
 On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote:
 
 I will probably be laughed at, but I'll ask just in case.
 
 We are having particularly bad luck trying to run VPN tunnels over
 Comcast cable in the Chicago area.  The symptoms are basically complete
 loss of connectivity (lasting minutes to sometimes hours), or sometimes
 flapping for a period of time.  More often than not, a reboot of the
 cable modem is required.  The most interesting ones involve the
 following: a PIX or ASA configured as an EZvpn client, connecting to a
 3000 concentrator, authentication over RADIUS.  When I go to look at the
 RADIUS logs, I see connections from the same box with small intervals.
 Timeout is 8 hours, so theoretically I should see 3 connections in a
 24-hr period.  In some cases, I see dozens, in the most egregious cases,
 thousands over a 24-hour period.  I am taking that as an indicator of a
 really unstable Comcast circuit.  We have not had this problem with any
 other ISP, anywhere in the country.
 I am pretty much down to telling customers to find another provider...  
 
 Any thoughts or ideas on the matter will be appreciated.
 
 PS.  To be fair (?) to Comcast, this is not a ubiquitous problem.  It
 affects about 25% of the installations I get to see.
 
 Sincerely,
 Michael Malitsky
 
 
 
 We experienced the same thing, and switching from UDP tunnels to TCP tunnels 
 fixed it. There are two things at play here.
 
 1) The SMC modem/router that they insist you use for their Small Business 
 cable internet service seems to have trouble with very high rates of non-TCP 
 traffic going through its NAT.
 
If you have business class service, insist that they put the cablemodem in 
BRIDGE-ONLY mode.  This will resolve this issue and eliminate the unnecessary 
NAT.

 2) Comcast rate limits non-TCP traffic somewhere on their network.
 
Comcast rate limits traffic in general. TCP is not less rate limited than 
anything else in my
experience.

Owen

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?


On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote:

 Andy Davidson wrote:
 On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
  
 Did you use Yahoo IM, AIM, or Skype?
  
 Yes, yes, and yes.  Works fine.

 
 What about every other service/protocol that users use today, and might be 
 invented tomorrow ?  Do  will they all work with NAT ?
  
 
 Anyone inventing a new service/protocol that doesn't work with NAT isn't 
 planning on success.

Respectfully, I disagree.  There are many possible innovations that are 
available in a NAT-less world and it is desirable to get to that point rather 
than hamper future innovation with this obsolete baggage.

 Do many others work as well or act reliably through NAT ?
  
 Yes.

In reality, it's more like some yes, some not so much.

 Will it stop or hamper the innovation of new services on the
 internet ?
  
 Hasn't so far.

Here I have to call BS... I know of a number of cases where it has.

 The answer to these questions isn't a good one for users, so
 as the community that are best placed to defend service quality
 and innovation by preserving the end to end principal, it is our 
 responsibility to defend it to the best of our ability.
  
 Firewalls will always break the end-to-end principle, whether or not 
 addresses are identical between the inside and outside or not.

Yes and no.  Firewalls will always break the idea of global universal 
end-to-end reachability.

The do not break the end-to-end principle except when NAT is involved.

The end-to-end principle is that the original layer 3+ information arrives at 
the layer 3 destination un-mangled by intermediate devices when it is a 
permitted type of traffic. Blocking unwanted flows does not break the 
end-to-end principle. Maiming and distorting data contained in the datagram, 
including the headers, on the other hand does break the end-to-end principle.

 So get busy - v6 awareness, availability and abundancy are
 overdue for our end users.
  
 Maybe. Most of them are perfectly happy.
 
This word Most, it does not mean what you appear to think it means.

Owen

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Valdis . Kletnieks

On Tue, 27 Apr 2010 14:37:08 EDT, Jon Lewis said:

 Maybe we want end-to-end to break.
 
 Firewalls can trivially be misconfigured such that they're little more 
 than routers, fully exposing all the hosts behind them to everything bad 
 the internet has to offer (hackers, malware looking to spread itself, 
 etc.).
 
 At least with NAT, if someone really screws up the config, the inside 
 stuff is all typically on non-publicly-routed IPs, so the worst likely to 
 happen is they lose internet, but at least the internet can't directly 
 reach them.

You *do* realize that the skill level needed to misconfigure a firewall
into that state, and the skill level needed to do the exact same thing to
a firewall-NAT box, are *both* less than the skill level needed to remember
to also deploy traffic monitors so you know you screwed up, and host-based
firewalls to guard against chuckleheads screwing up the border box?

In other words, if your security scheme relies on that supposed feature of NAT,
you have *other* things you need to be working on.


pgp92Zt0KYD5H.pgp
Description: PGP signature

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?


Owen DeLong wrote:

On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote:

  

Andy Davidson wrote:


On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
 
  

Did you use Yahoo IM, AIM, or Skype?
 
  

Yes, yes, and yes.  Works fine.
   


What about every other service/protocol that users use today, and might be invented 
tomorrow ?  Do  will they all work with NAT ?
 
  

Anyone inventing a new service/protocol that doesn't work with NAT isn't 
planning on success.



Respectfully, I disagree.  There are many possible innovations that are 
available in a NAT-less world and it is desirable to get to that point rather 
than hamper future innovation with this obsolete baggage.
  
I would argue that every one of those innovations, if even passably 
useful, can also be implemented in a NAT-full world.
  

Do many others work as well or act reliably through NAT ?
 
  

Yes.



In reality, it's more like some yes, some not so much.
  
== Some designed to work properly in the face of NAT, some ignored 
reality at their peril.
  

Will it stop or hamper the innovation of new services on the
internet ?
 
  

Hasn't so far.



Here I have to call BS... I know of a number of cases where it has.
  
Ok, you called it... so where's the list of such services that haven't 
materialized as a result of NAT?


Matthew Kaufman

Re: VPN over Comcast

2010-04-27 Thread James M Keller


On 4/27/2010 1:42 PM, Michael Malitsky wrote:

I will probably be laughed at, but I'll ask just in case.

We are having particularly bad luck trying to run VPN tunnels over
Comcast cable in the Chicago area.  The symptoms are basically complete
loss of connectivity (lasting minutes to sometimes hours), or sometimes
flapping for a period of time.  More often than not, a reboot of the
cable modem is required.  The most interesting ones involve the
following: a PIX or ASA configured as an EZvpn client, connecting to a
3000 concentrator, authentication over RADIUS.  When I go to look at the
RADIUS logs, I see connections from the same box with small intervals.
Timeout is 8 hours, so theoretically I should see 3 connections in a
24-hr period.  In some cases, I see dozens, in the most egregious cases,
thousands over a 24-hour period.  I am taking that as an indicator of a
really unstable Comcast circuit.  We have not had this problem with any
other ISP, anywhere in the country.
I am pretty much down to telling customers to find another provider...

Any thoughts or ideas on the matter will be appreciated.

PS.  To be fair (?) to Comcast, this is not a ubiquitous problem.  It
affects about 25% of the installations I get to see.

Sincerely,
Michael Malitsky



   


I ran into issues in various Comcast serviced regions with SSL VPN over 
tcp-443.   From testing we started getting drops or severe rate limits 
on the flow after 7-10 minutes.Best guess was it was anti-p2p 
systems throttling encrypted/unknown protocol traffic after a set 
timer.   Disconnecting and reconnecting pushed performance back up to 
normal until the timer kicked in again.We ended up setting the SSL 
tunnel to re-key via new sessions every 5 minutes to keep the flow 
shorter then the observed timer intervals.   Other then running into a 
Cisco AnyConnect client bug (the app would steal focus at the re-keys) 
worked around the issue on Comcast and even some FiOS end users.


--
---
James M Keller

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Jon Lewis


On Tue, 27 Apr 2010 valdis.kletni...@vt.edu wrote:


At least with NAT, if someone really screws up the config, the inside
stuff is all typically on non-publicly-routed IPs, so the worst likely to
happen is they lose internet, but at least the internet can't directly
reach them.


You *do* realize that the skill level needed to misconfigure a firewall
into that state, and the skill level needed to do the exact same thing to
a firewall-NAT box, are *both* less than the skill level needed to remember
to also deploy traffic monitors so you know you screwed up, and host-based
firewalls to guard against chuckleheads screwing up the border box?


I think you forget where most networking is done.  Monitoring?  You mean 
something beyond walking down the hall to the network closet and seeing 
all the blinking lights are flashing really fast?


How about the typical home DSL/Cable modem user?  Do you think they even 
know what SNMP is?  Do you think they have host based firewalls on all 
their PCs?  Do you want mom and dad's PCs exposed on the internet, or 
neatly hidden behind a NAT device they don't even realize is built into 
their cable/DSL router?


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: VPN over Comcast

2010-04-27 Thread schilling

http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html
showed a feature of Gateway Smart Packet Detection in some SMC
cable modem.



The current solution is to identify the affected Comcast modem, and ask
Comcast engineer to turn that IDS feature off remotely.

I spend several days to talk with comcast about our blackboard will
not work sometimes in some shared business class residential building.
Finally got hold of a Regional Engineer to confess this with my
tcpdump proof. Local comcast engineer may not be aware of this
feature.


Schilling

On Tue, Apr 27, 2010 at 2:36 PM, Owen DeLong o...@delong.com wrote:

 On Apr 27, 2010, at 10:48 AM, Kevin Day wrote:


 On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote:

 I will probably be laughed at, but I'll ask just in case.

 We are having particularly bad luck trying to run VPN tunnels over
 Comcast cable in the Chicago area.  The symptoms are basically complete
 loss of connectivity (lasting minutes to sometimes hours), or sometimes
 flapping for a period of time.  More often than not, a reboot of the
 cable modem is required.  The most interesting ones involve the
 following: a PIX or ASA configured as an EZvpn client, connecting to a
 3000 concentrator, authentication over RADIUS.  When I go to look at the
 RADIUS logs, I see connections from the same box with small intervals.
 Timeout is 8 hours, so theoretically I should see 3 connections in a
 24-hr period.  In some cases, I see dozens, in the most egregious cases,
 thousands over a 24-hour period.  I am taking that as an indicator of a
 really unstable Comcast circuit.  We have not had this problem with any
 other ISP, anywhere in the country.
 I am pretty much down to telling customers to find another provider...

 Any thoughts or ideas on the matter will be appreciated.

 PS.  To be fair (?) to Comcast, this is not a ubiquitous problem.  It
 affects about 25% of the installations I get to see.

 Sincerely,
 Michael Malitsky



 We experienced the same thing, and switching from UDP tunnels to TCP tunnels 
 fixed it. There are two things at play here.

 1) The SMC modem/router that they insist you use for their Small Business 
 cable internet service seems to have trouble with very high rates of non-TCP 
 traffic going through its NAT.

 If you have business class service, insist that they put the cablemodem in 
 BRIDGE-ONLY mode.  This will resolve this issue and eliminate the unnecessary 
 NAT.

 2) Comcast rate limits non-TCP traffic somewhere on their network.

 Comcast rate limits traffic in general. TCP is not less rate limited than 
 anything else in my
 experience.

 Owen

Re: VPN over Comcast

2010-04-27 Thread Jared Mauch

You can get into the SMC device yourself by going to the 
http://10.1.10.1/login.asp link on the SMC.  The username/password are well 
known as cusadmin/highspeed.  I also recommend against using the integrated 
services in the device if at all possible.  It's also mildly annoying that it 
does not respond to traceroute either when it's your gateway with a pool of 
static ips.

I did have one case where it reverted to a mode where it ran dhcp/nat but that 
was shortlived and has not happened again.

- Jared

On Apr 27, 2010, at 2:56 PM, schilling wrote:

 http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html
 showed a feature of Gateway Smart Packet Detection in some SMC
 cable modem.
 
 
 
 The current solution is to identify the affected Comcast modem, and ask
 Comcast engineer to turn that IDS feature off remotely.
 
 I spend several days to talk with comcast about our blackboard will
 not work sometimes in some shared business class residential building.
 Finally got hold of a Regional Engineer to confess this with my
 tcpdump proof. Local comcast engineer may not be aware of this
 feature.
 
 
 Schilling
 
 On Tue, Apr 27, 2010 at 2:36 PM, Owen DeLong o...@delong.com wrote:
 
 On Apr 27, 2010, at 10:48 AM, Kevin Day wrote:
 
 
 On Apr 27, 2010, at 12:42 PM, Michael Malitsky wrote:
 
 I will probably be laughed at, but I'll ask just in case.
 
 We are having particularly bad luck trying to run VPN tunnels over
 Comcast cable in the Chicago area.  The symptoms are basically complete
 loss of connectivity (lasting minutes to sometimes hours), or sometimes
 flapping for a period of time.  More often than not, a reboot of the
 cable modem is required.  The most interesting ones involve the
 following: a PIX or ASA configured as an EZvpn client, connecting to a
 3000 concentrator, authentication over RADIUS.  When I go to look at the
 RADIUS logs, I see connections from the same box with small intervals.
 Timeout is 8 hours, so theoretically I should see 3 connections in a
 24-hr period.  In some cases, I see dozens, in the most egregious cases,
 thousands over a 24-hour period.  I am taking that as an indicator of a
 really unstable Comcast circuit.  We have not had this problem with any
 other ISP, anywhere in the country.
 I am pretty much down to telling customers to find another provider...
 
 Any thoughts or ideas on the matter will be appreciated.
 
 PS.  To be fair (?) to Comcast, this is not a ubiquitous problem.  It
 affects about 25% of the installations I get to see.
 
 Sincerely,
 Michael Malitsky
 
 
 
 We experienced the same thing, and switching from UDP tunnels to TCP 
 tunnels fixed it. There are two things at play here.
 
 1) The SMC modem/router that they insist you use for their Small Business 
 cable internet service seems to have trouble with very high rates of 
 non-TCP traffic going through its NAT.
 
 If you have business class service, insist that they put the cablemodem in 
 BRIDGE-ONLY mode.  This will resolve this issue and eliminate the 
 unnecessary NAT.
 
 2) Comcast rate limits non-TCP traffic somewhere on their network.
 
 Comcast rate limits traffic in general. TCP is not less rate limited than 
 anything else in my
 experience.
 
 Owen

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?


On Apr 27, 2010, at 11:49 AM, Matthew Kaufman wrote:

 Owen DeLong wrote:
 On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote:
 
  
 Andy Davidson wrote:

 On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
   
 Did you use Yahoo IM, AIM, or Skype?
   
 Yes, yes, and yes.  Works fine.
   
 What about every other service/protocol that users use today, and might be 
 invented tomorrow ?  Do  will they all work with NAT ?
   
 Anyone inventing a new service/protocol that doesn't work with NAT isn't 
 planning on success.

 
 Respectfully, I disagree.  There are many possible innovations that are 
 available in a NAT-less world and it is desirable to get to that point 
 rather than hamper future innovation with this obsolete baggage.
  
 I would argue that every one of those innovations, if even passably useful, 
 can also be implemented in a NAT-full world.

Perhaps, but, often at significant additional code, development time, QA 
resources and other costs.
Also, often at a degraded level requiring a non-NAT'd third-party broker to 
intermediate between any two NAT'd parties attempting to trade information.

  
 Do many others work as well or act reliably through NAT ?
   
 Yes.

 
 In reality, it's more like some yes, some not so much.
  
 == Some designed to work properly in the face of NAT, some ignored reality at 
 their peril.

We can agree to disagree about this. The reality is that there are cool things 
you can do with peer to peer networking that simply aren't possible in an 
enforced client-server model.
NAT enforces a client-server model and permanently and irrevocably relegates 
some administrative domains to the client role. This is an unfair disadvantage 
to the users within those domains when it is not by the choice of the 
administrator (and NAT in IPv4 so far, often is not).

  
 Will it stop or hamper the innovation of new services on the
 internet ?
   
 Hasn't so far.

 
 Here I have to call BS... I know of a number of cases where it has.
  
 Ok, you called it... so where's the list of such services that haven't 
 materialized as a result of NAT?
 
Haven't materialized, for one, is an attempt to redefine the question.  Note 
that the original question included hamper.  I would argue that the cost of 
maintaining a NAT compatibility lab and the QA staff to use it is a sufficient 
burden to call it hamper.

For the ones that did not materialize, however, I am at an unfortunate 
disadvantage in the argument.  I can tell you that I know of at least 5 such 
cases.  However, I cannot reveal the details because I am under NDA to the 
companies that were developing these products. I can tell you that in 3 of the 
5 cases, adapting them to cope with a NAT world would have required the company 
to run an external service in perpetuity (or at least so long as the 
application would function, no server, no function) in order to do the 
match-making between clients that could not directly reach each-other.

I guess a good analogy is this:

In a NAT world, you have only matchmaking services and all of your ability to 
meet potential mates is strictly controlled through these matchmaking services. 
There are many services available independent of each other, and, each has its 
own limitations, biases, and quirks. However, you cannot meet potential mates 
without involving at least one matchmaker.

In a NAT-Free world, you have the ability to use a matchmaking service if you 
like, but, you also have the ability to meet potential mates at bars, in the 
grocery store, on the street, in restaurants, through chance meetings, 
introductions by a friend, or even at work.

It is possible that if you never knew it was possible to meet potential mates 
in all of these other ways, you would happily deal with a vast number of 
matchmaking services hoping to find a useful result. On the other hand, if you 
were to ask the average person who has experienced the latter scenario if they 
would be willing to limit their choices to only using a dating service, my 
guess would be that most people would reject the idea outright.

Owen

Re: comcast enterprise/carrier services

2010-04-27 Thread Scott Weeks



--- car...@race.com wrote:
From: Carlos Alcantar car...@race.com

Looking for a sales contact for Comcast enterprise/carrier services for
there Ethernet product thanks.
--


Please, please, PLEASE do not encourage sales droids like this.  It is evident 
to me you have never been hounded to death by the droids trolling this list.  
As usual, I encourage everyone to tell any droids that you absolutely will not 
buy from them when they contact you from your NANOG postings.

I have gone through it many times over the years and always get to the point of 
yelling in email WHAT PART OF NO DO YOU NOT UNDERSTAND! before they finally 
stop.  My apologies for yelling, but I want to get the point across that if we 
encourage them the list value is decreased by orders (plural) of magnitude.

scott

NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America

2010-04-27 Thread IPv3.com

NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America

1. To deploy and operate a network there may be network elements (aka
NATs) that are
used by network operators to upgrade versions  to help with audits.

2. L3 End-to-End is only part of the story. What about Hop Count ?
Lag Latency...band-width

3. In North America the Customer DeMarc is commonly to a Linux-based
CPE Router (WRT-54GL is one example)

4. For FCC purposes and other audits, the DeMarc for L3 IPv4+ has to
be consistent to
avoid comparing apples and oranges.

5. It may be that large parts of the IPv4+ Spectrum allocated to North
America no longer qualifies as part of the L3 End-to-End Transport
(and never did?).
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

6. Before ISPs run off chasing the IPv6 Brokers-duJour, it may be
prudent to first make
sure their IPv4+ networks still are part of the L3 End-to-End Transport.

NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America

Re: NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America

2010-04-27 Thread Justin Shore


On 4/27/2010 3:02 PM, IPv3.com wrote:

NANOG Operational Audit of IPv4+ End-to-End L3 Transport in North America


I haven't been keeping up with NANOG in a while so perhaps I missed the 
discussion and/or memo.  I take it that this spammer is still being 
allowed to send his shit to the mailing list?


Justin

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Valdis . Kletnieks

On Tue, 27 Apr 2010 14:54:07 EDT, Jon Lewis said:

 I think you forget where most networking is done.  Monitoring?  You mean 
 something beyond walking down the hall to the network closet and seeing 
 all the blinking lights are flashing really fast?

That site will manage to chucklehead their config whether or not it's NAT'ed.

 How about the typical home DSL/Cable modem user?

And they won't manage to chucklehead their config, even if it's not NAT'ed.
 
  Do you think they even 
 know what SNMP is?  Do you think they have host based firewalls on all 
 their PCs?

Hmm... Linux has a firewall.  MacOS has a firewall. Windows XP SP2 or later
has a perfectly functional firewall out of the box, and earlier Windows had
a firewall but it didn't do 'default deny inbound' out of the box.

Those people with XBoxes and Playstations and so on can take it up with their
vendors - they were certainly *marketed* as plug it in and network, and at
least my PS/2 and PS/3 didn't come with a Warning: Do Not Use Without a NAT
sticker on them.

So who doesn't have a host-based firewall in 2010? The idea is old enough
that it's *really* time to play name-and-blame.

 Do you want mom and dad's PCs exposed on the internet, or 
 neatly hidden behind a NAT device they don't even realize is built into 
 their cable/DSL router?

Be careful here - I know that at least in my neck of Comcast cable, you can go
to Best Buy, get a cablemodem, plug the cable in one side, plug an ethernet and
one machine in the other side, and be handed a live on-the-network DHCP address
that works just fine except for outbound port 25 being blocked.  For the past
month or so, my laptop has gotten 71.63.92.124 every night when I get home,
which certainly doesn't look very NAT'ed.

Are you *really* trying to suggest that a PC is not fit-for-purpose
for that usage, and *requires* a NAT and other hand-holding?

And for the record - I don't worry about my mother's PC being exposed on the
Internet, because she's running Vista, which has a sane firewall by default.
What *does* worry me is that she's discovered Facebook, and anything she clicks
on there will not have the *slightest* bit of trouble whomping her machine
through a NAT.

Let's be realistic - what was the last time we had a *real* threat that a
NAT would have stopped but the XP SP2 firewall would not have stopped? And
how many current threats do we have that are totally NAT-agnostic?



pgpgrdKEWuLRD.pgp
Description: PGP signature

Re: comcast enterprise/carrier services

2010-04-27 Thread deleskie

I'm wondering how can someone recomend a vendor for X be diffrent from, Can 
someone recond a box that does Y. I'm no fan of blind calls from sales droids 
anymore more then the next person but I see this posting as relevant or more 
then many post here. 
--Original Message--
From: Scott Weeks
To: nanog@nanog.org
ReplyTo: sur...@mauigateway.com
Subject: Re: comcast enterprise/carrier services
Sent: Apr 27, 2010 4:29 PM

--- car...@race.com wrote:
From: Carlos Alcantar car...@race.com

Looking for a sales contact for Comcast enterprise/carrier services for
there Ethernet product thanks.
--

Please, please, PLEASE do not encourage sales droids like this.  It is evident 
to me you have never been hounded to death by the droids trolling this list.  
As usual, I encourage everyone to tell any droids that you absolutely will not 
buy from them when they contact you from your NANOG postings.

I have gone through it many times over the years and always get to the point of 
yelling in email WHAT PART OF NO DO YOU NOT UNDERSTAND! before they finally 
stop.  My apologies for yelling, but I want to get the point across that if we 
encourage them the list value is decreased by orders (plural) of magnitude.

scott

Sent from my BlackBerry device on the Rogers Wireless Network

Re: iabelle francois

2010-04-27 Thread Jeroen van Aart


Ted Cooper wrote:

On Thu, 2010-04-22 at 23:22 -0400, Eric Carroll wrote:

On 10-04-21 06:59 PM, Jeroen van Aart wrote:

The url redirects to a Canadian med site.

Just FYI, it's not a real Canadian med site. It is high probability
not 
even Canadian.


Posting so many URLs which either are or should be listed in domain
block lists to a list with as many subscribers as this is probably not
wise. I'm guessing you just caused a wonderful bounce storm as the NANOG
servers attempted to send that out, depending of course on how many
people whitelist NANOG to URI filtering.


I would say one has their spamfilter configured incorrectly if such 
emails would be rejected and it should prompt an immediate fix.


The mailinglist should ideally be whitelisted. In addition if you use 
content scanning (in almost all cases a bad idea, see: 
http://news.bbc.co.uk/2/hi/technology/8528672.stm ) your scanners ought 
to be trained well enough to figure out the email is not spam.


Regards,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Jon Lewis


On Tue, 27 Apr 2010 valdis.kletni...@vt.edu wrote:


That site will manage to chucklehead their config whether or not it's NAT'ed.


True...but when they do it and all their important stuff is in 
192.168.0/24, you still can't reach it...and if they break NAT, at least 
their internet breaks.  i.e. they'll know its broken.  When they change 
the default policy on the firewall to Accept/Allow all, everything will 
still work...until all their machines are infected with enough stuff to 
break them.



Hmm... Linux has a firewall.  MacOS has a firewall. Windows XP SP2 or later
has a perfectly functional firewall out of the box, and earlier Windows had
a firewall but it didn't do 'default deny inbound' out of the box.


Linux can have a firewall.  Not all distros default to having any rules. 
XP can (if you want to call it that).  I don't have any experience with 
MacOS.  Both my kids run Win2k (to support old software that doesn't run 
well/at all post-2k).  I doubt that's all that unusual.



Are you *really* trying to suggest that a PC is not fit-for-purpose
for that usage, and *requires* a NAT and other hand-holding?


Here's an exercise.  Wipe a PC.  Put it on that cable modem with no 
firewall.  Install XP on it.  See if you can get any service packs 
installed before the box is infected.


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?


On Apr 27, 2010, at 2:25 PM, Jon Lewis wrote:

 On Tue, 27 Apr 2010 valdis.kletni...@vt.edu wrote:
 
 That site will manage to chucklehead their config whether or not it's NAT'ed.
 
 True...but when they do it and all their important stuff is in 192.168.0/24, 
 you still can't reach it...and if they break NAT, at least their internet 
 breaks.  i.e. they'll know its broken.  When they change the default policy 
 on the firewall to Accept/Allow all, everything will still work...until all 
 their machines are infected with enough stuff to break them.
 
Nah... They'll chucklehead forward something to 135-139/TCP on the box with all 
the important stuff just fine.
NAT won't save them from this.

 Hmm... Linux has a firewall.  MacOS has a firewall. Windows XP SP2 or later
 has a perfectly functional firewall out of the box, and earlier Windows had
 a firewall but it didn't do 'default deny inbound' out of the box.
 
 Linux can have a firewall.  Not all distros default to having any rules. XP 
 can (if you want to call it that).  I don't have any experience with MacOS.  
 Both my kids run Win2k (to support old software that doesn't run well/at all 
 post-2k).  I doubt that's all that unusual.
 
And the rest of the world should pay for your kid's legacy requirements why?

 Are you *really* trying to suggest that a PC is not fit-for-purpose
 for that usage, and *requires* a NAT and other hand-holding?
 
 Here's an exercise.  Wipe a PC.  Put it on that cable modem with no firewall. 
  Install XP on it.  See if you can get any service packs installed before the 
 box is infected.
 
1.  Yes, I can.  I simply didn't put an IPv4 address on it. ;-)
2.  I wouldn't hold XP up as the gold standard of hosts here.

Owen

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread James Hess

On Tue, Apr 27, 2010 at 4:25 PM, Jon Lewis jle...@lewis.org wrote:
 breaks.  i.e. they'll know its broken.  When they change the default policy
 on the firewall to Accept/Allow all, everything will still work...until all
 their machines are infected with enough stuff to break them.

The same is true with IPv4 + NAT, in terms of real-world net security.
  Because security attacks against end-user equipment commonly come
from either an e-mail message the user is expected to errantly click
on,  or a malicious website, designed to exploit the latest
$MsOffice_Acrobat_Javascript_OR_Flash_Vuln_DU_Jour.

If user accidentally turns off their  outbound filtering software,
even the IPv4 user behind a NAT setup still have a pretty bad security
posture.


Fortunately, the IPv6  address space is so large and sparse, that
scanning it would be quite a feat,  even if a random outside attacker
already knew   for a fact  that a certain /64  probably contains a
vulnerable host.  Scanning IPv6 addresses by brute force,  is as
computationally  hard as  figuring out the  16-bit port number  pairs
of an IPv4   NAT user's   open connection,  in order to  fool their
NAT device and  partially hijack the user's  HTTP connection and
inject malicious code into their stream.

By the way,  if an attacker actually can figure out  the port number
pairs of a session recognized by the NAT device, the illusion of
security offered by the NAT setup potentially starts to crumble
  either way it's 32-bits to be guessed within a fairly limited
timeframe.

--
-J

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

2010-04-27 Thread Mark Andrews


In message pine.lnx.4.61.1004271718210.5...@soloth.lewis.org, Jon Lewis 
writes:
 Both my kids run Win2k (to support old software that doesn't run 
 well/at all post-2k).  I doubt that's all that unusual.

Then they won't have IPv6 and hence are irrelevent to the discussion
about IPv6 NAT.
 
As for built in firewalls, even my brother printer as a firewall
built into it and it supports IPv6.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

IPv6 rDNS - how will it be done?

2010-04-27 Thread Felipe Zanchet Grazziotin

Hi list,

this is my first post, so be nice. :)

Wondering about IPv6 deployments to end-users, imagine we deploy a full /48
address to each client.
How is the reverse DNS for each possible IPv6 address going to be?

Nowadays I'm used to do IPv4 reverse using old Class C, which has (up to)
256 entries. Are we really going to make reverse DNS entries for each of
those 2^80 addresses? Or going to deploy rDNS only at the PtP links and
relevant servers?

Kind regards,
Felipe

Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Mark Andrews


In message v2s621b657f1004271721icf7c9237kcfb877b7785d1...@mail.gmail.com, 
Felipe Zanchet Grazziotin writes:
 Hi list,
 
 this is my first post, so be nice. :)
 
 Wondering about IPv6 deployments to end-users, imagine we deploy a full /48
 address to each client.
 How is the reverse DNS for each possible IPv6 address going to be?
 
 Nowadays I'm used to do IPv4 reverse using old Class C, which has (up to)
 256 entries. Are we really going to make reverse DNS entries for each of
 those 2^80 addresses? Or going to deploy rDNS only at the PtP links and
 relevant servers?
 
 Kind regards,
 Felipe

Windows will just populate the reverse zone as needed, if you let
it, using dynamic update.  If you have properly deployed BCP 39
and have anti-spoofing ingres filtering then you can just let any
address from the /48 add/remove PTR records.  Other OS's will
follow suite.

Alternatively you can delegate the reverse for the /48 to servers
run by the customers.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Jason 'XenoPhage' Frisvold

On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
 Windows will just populate the reverse zone as needed, if you let
 it, using dynamic update.  If you have properly deployed BCP 39
 and have anti-spoofing ingres filtering then you can just let any
 address from the /48 add/remove PTR records.  Other OS's will
 follow suite.

Is DDNS really considered to be the end-all answer for this?  It seems we're 
putting an awful lot of trust in the user when doing this..  I'd rather see 
some sort of macro expansion in bind/tinydns/etc that would allow a range of 
addresses to be added.

 Alternatively you can delegate the reverse for the /48 to servers
 run by the customers.

This works for commercial customers, but I'm not sure I'd want to delegate this 
to a residential customer.

 Mark

---
Jason 'XenoPhage' Frisvold
xenoph...@godshell.com
---
Any sufficiently advanced magic is indistinguishable from technology.
- Niven's Inverse of Clarke's Third Law

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Richard Barnes

Naïve question: If you used macro expansion, wouldn't you end up
providing responses for a lot of addresses that aren't in use?  Maybe
that's not a problem?


On Tue, Apr 27, 2010 at 8:47 PM, Jason 'XenoPhage' Frisvold
xenoph...@godshell.com wrote:
 On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
 Windows will just populate the reverse zone as needed, if you let
 it, using dynamic update.  If you have properly deployed BCP 39
 and have anti-spoofing ingres filtering then you can just let any
 address from the /48 add/remove PTR records.  Other OS's will
 follow suite.

 Is DDNS really considered to be the end-all answer for this?  It seems we're 
 putting an awful lot of trust in the user when doing this..  I'd rather see 
 some sort of macro expansion in bind/tinydns/etc that would allow a range of 
 addresses to be added.

 Alternatively you can delegate the reverse for the /48 to servers
 run by the customers.

 This works for commercial customers, but I'm not sure I'd want to delegate 
 this to a residential customer.

 Mark

 ---
 Jason 'XenoPhage' Frisvold
 xenoph...@godshell.com
 ---
 Any sufficiently advanced magic is indistinguishable from technology.
 - Niven's Inverse of Clarke's Third Law

Re: Mail Submission Protocol

2010-04-27 Thread Jeroen van Aart


Raoul Bhatia [IPAX] wrote:
  i recently had the problem that an lotus notes server insisted on

sending emails to one of our clients via port 465. so having mandatory
authentication there actually broke delivery for an exchange sender.


Leave it broken for the other end that is. Only way to force them to 
fix it.


The only acceptable, and standard, way to submit email these days is 
using port 587 with TLS. And if you have users with broken clients, they 
can use webmail behind https. I am against facilitating (and thus 
perpetuating the existence of) old broken clients by making available 
port 465.


Regards,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Jason 'XenoPhage' Frisvold

On Apr 27, 2010, at 8:50 PM, Richard Barnes wrote:
 Naïve question: If you used macro expansion, wouldn't you end up
 providing responses for a lot of addresses that aren't in use?  Maybe
 that's not a problem?

Presumably the op would only use macros where needed, ie dynamically assigned 
addresses.  So, for a pool of addresses assigned for DSL/Cable/FIOS 
subscribers, that pool would have forward/reverse set up.

Note: I am definitely not up on my IPv6 knowledge, so there may be a Really 
Good Reason(tm) that one should not do this..  However, I was under the 
impression that having both forward and reverse for dynamic IPs was a best 
practice..

---
Jason 'XenoPhage' Frisvold
xenoph...@godshell.com
---
Any sufficiently advanced magic is indistinguishable from technology.
- Niven's Inverse of Clarke's Third Law

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread David Conrad

On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote:
 On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
 Windows will just populate the reverse zone as needed, if you let
 it, using dynamic update.  If you have properly deployed BCP 39
 and have anti-spoofing ingres filtering then you can just let any
 address from the /48 add/remove PTR records.  Other OS's will
 follow suite.
 
 Is DDNS really considered to be the end-all answer for this?

Seems it is that or not bothering with reverse anymore.

 It seems we're putting an awful lot of trust in the user when doing this..  
 I'd rather see some sort of macro expansion in bind/tinydns/etc that would 
 allow a range of addresses to be added.

Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 
leaves. An interesting stress test for name servers... :-).

Slightly more seriously, there have been discussions in the past about doing 
dynamic synthesis of v6 reverses, but that gets icky (particularly if you 
invoke the dreaded DNSSEC curse) and I don't know any production server that 
actually does this now.  Dynamic DNS is probably the least offensive solution 
if you really want reverses for your v6 nodes.

Regards,
-drc

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Jason 'XenoPhage' Frisvold

On Apr 27, 2010, at 9:00 PM, David Conrad wrote:
 Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 
 leaves. An interesting stress test for name servers... :-).

Um.. sure.  :)  Your computer can't handle that?

How about a programmatic expansion?  Only create the necessary record when 
asked for it.

 Slightly more seriously, there have been discussions in the past about doing 
 dynamic synthesis of v6 reverses, but that gets icky (particularly if you 
 invoke the dreaded DNSSEC curse) and I don't know any production server 
 that actually does this now.  Dynamic DNS is probably the least offensive 
 solution if you really want reverses for your v6 nodes.

DNSSEC does seem to throw the proverbial wrench in the works..  At least, from 
what I understand..  I'm still not sold on DNSSEC and that, partly, has to do 
with a lack of knowledge..

If you allow a client to set their own reverse, don't you run into issues where 
the client can spoof their identity?  ie, set their reverse to whitehouse.gov 
or bankofamerica.com ?  Or is it possible to configure DDNS in such a way as to 
only allow subdomain names where the domain is tacked on automagically?

 Regards,
 -drc

---
Jason 'XenoPhage' Frisvold
xenoph...@godshell.com
---
Any sufficiently advanced magic is indistinguishable from technology.
- Niven's Inverse of Clarke's Third Law

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

On 4/27/2010 19:50, Richard Barnes wrote:
 Naïve question: If you used macro expansion, wouldn't you end up
 providing responses for a lot of addresses that aren't in use?  Maybe
 that's not a problem?

If you get a request, you will have to respond in any case.

I have a theory about data-base lookups--finding something is always
faster than not finding anything, unless you are using a human brain.

(A human brain can respond I don't know that without an inventory of
everything it does know.)

(That may be to only truly unique thing about humans.  And no, I have
not kept up with neural networks work.)

-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Richard Barnes

off-topic
IANADBExpert

Interesting theory, but seems kind of wrong.  Wouldn't the time to
look up or fail be tied to the complexity of how the key space is
populated?  In any case, it seems like the time to succeed or fail
will usually be about the same, since you'll try to access the value
for a key and either find something there or fail.


On Tue, Apr 27, 2010 at 9:19 PM, Larry Sheldon larryshel...@cox.net wrote:
 On 4/27/2010 19:50, Richard Barnes wrote:
 Naďve question: If you used macro expansion, wouldn't you end up
 providing responses for a lot of addresses that aren't in use?  Maybe
 that's not a problem?

 If you get a request, you will have to respond in any case.

 I have a theory about data-base lookups--finding something is always
 faster than not finding anything, unless you are using a human brain.

 (A human brain can respond I don't know that without an inventory of
 everything it does know.)

 (That may be to only truly unique thing about humans.  And no, I have
 not kept up with neural networks work.)

 --
 Somebody should have said:
 A democracy is two wolves and a lamb voting on what to have for dinner.

 Freedom under a constitutional republic is a well armed lamb contesting
 the vote.

 Requiescas in pace o email
 Ex turpi causa non oritur actio
 Eppure si rinfresca

 ICBM Targeting Information:  http://tinyurl.com/4sqczs
 http://tinyurl.com/7tp8ml

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread David Conrad

On Apr 27, 2010, at 6:10 PM, Jason 'XenoPhage' Frisvold wrote:
 How about a programmatic expansion?  Only create the necessary record when 
 asked for it.

The downsides I know of (off the top of my head) with dynamic synthesis are (a) 
challenges if you want DNSSEC and (b) increased susceptibility to D(D)oS 
attack.  There are probably others.

At some point, one has to ask if the ability to map the address into a name is 
worth the effort...

 If you allow a client to set their own reverse, don't you run into issues 
 where the client can spoof their identity?  ie, set their reverse to 
 whitehouse.gov or bankofamerica.com ?  

Yep, but those are boring examples.  I've seen (typically University computer 
science) networks with some truly fascinating (in scatological, religious 
and/or reproductive senses) reverse names.  Since anyone who relies on the 
reverse for anything other than a hint that the address might be part of a 
managed network deserves what they get, the names were good for a chuckle.

 Or is it possible to configure DDNS in such a way as to only allow subdomain 
 names where the domain is tacked on automagically?

Most DDNS servers support some form of filtering.  However, the better way, at 
least in IPv4, is to have the DHCP server do the dynamic updates, not the 
client.  However, since some view DHCPv6 as Evil Pure and Simple by way of the 
Eighth Dimension(tm), this may not be an option.

Regards,
-drc

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Richard Barnes

Presumably, if you've already got a script that's provisioning reverse
results, you could amend it to add name constraints.  No idea if this
is possible with current DynDNS software, though.

--Richard



On Tue, Apr 27, 2010 at 9:10 PM, Jason 'XenoPhage' Frisvold
xenoph...@godshell.com wrote:
 On Apr 27, 2010, at 9:00 PM, David Conrad wrote:
 Hmm. A macro expansion for a /48 would mean 
 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for 
 name servers... :-).

 Um.. sure.  :)  Your computer can't handle that?

 How about a programmatic expansion?  Only create the necessary record when 
 asked for it.

 Slightly more seriously, there have been discussions in the past about doing 
 dynamic synthesis of v6 reverses, but that gets icky (particularly if you 
 invoke the dreaded DNSSEC curse) and I don't know any production server 
 that actually does this now.  Dynamic DNS is probably the least offensive 
 solution if you really want reverses for your v6 nodes.

 DNSSEC does seem to throw the proverbial wrench in the works..  At least, 
 from what I understand..  I'm still not sold on DNSSEC and that, partly, has 
 to do with a lack of knowledge..

 If you allow a client to set their own reverse, don't you run into issues 
 where the client can spoof their identity?  ie, set their reverse to 
 whitehouse.gov or bankofamerica.com ?  Or is it possible to configure DDNS in 
 such a way as to only allow subdomain names where the domain is tacked on 
 automagically?

 Regards,
 -drc

 ---
 Jason 'XenoPhage' Frisvold
 xenoph...@godshell.com
 ---
 Any sufficiently advanced magic is indistinguishable from technology.
 - Niven's Inverse of Clarke's Third Law

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

On 4/27/2010 20:25, Richard Barnes wrote:
 off-topic
 IANADBExpert
 
 Interesting theory, but seems kind of wrong.  Wouldn't the time to
 look up or fail be tied to the complexity of how the key space is
 populated?  In any case, it seems like the time to succeed or fail
 will usually be about the same, since you'll try to access the value
 for a key and either find something there or fail.

The theory is based on the notion that if you find something you stop
looking for it.  If what you are looking for is not there, you have to
search all of the key-space, regardless of the index method.

-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Re: Connectivity to an IPv6-only site

2010-04-27 Thread Steve Bertrand

On 2010.04.23 02:50, Steve Bertrand wrote:

 http://onlyv6.com

 All findings will be publicly posted.

I'm currently evaluating my options to best automate some of the
findings that I've got so far (I didn't ask for a common format for
replies, so most will be manual).

However, an interesting item that I've noted thus far, is that ~50% of
all successful connections do not have rDNS.

Originally, I thought that the majority of these simply didn't have
their delegated reverse zones on v6-reachable DNS servers, but this is
not necessarily so.

I copied the web log onto a dual-stack box and re-ran the DNS tests, and
only two of the non-resolvable ip6.arpa addresses resolved over v4.

fwiw, for those who have been asking, inbound SMTP is now working, and
I've got a basic IMAP/POP3 daemon running. If you still want a test
account, let me know.

st...@onlyv6.com

Thanks everyone for all of the support.

Cheers,

Steve

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Mark Andrews


In message 268ebce2-9d47-488e-8223-29b5a6323...@godshell.com, Jason 
'XenoPhage' Frisvold wri
tes:
 On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
  Windows will just populate the reverse zone as needed, if you let
  it, using dynamic update.  If you have properly deployed BCP 39
  and have anti-spoofing ingres filtering then you can just let any
  address from the /48 add/remove PTR records.  Other OS's will
  follow suite.
 
 Is DDNS really considered to be the end-all answer for this?

It works if you let it.

 It seems =
 we're putting an awful lot of trust in the user when doing this.

What trust?  The OS just does it.  The user doesn't need to think about
this.

 I'd =
 rather see some sort of macro expansion in bind/tinydns/etc that would =
 allow a range of addresses to be added.

Macro expansion won't work.  1208925819614629174706176 PTR records is
a hell of a lot of records and that's just 1 /48.  :-)

  Alternatively you can delegate the reverse for the /48 to servers
  run by the customers.
 
 This works for commercial customers, but I'm not sure I'd want to =
 delegate this to a residential customer.

Some will be capable others won't.  I would leave it as a option
but not the default.  Some thing that the account's control panel
can turn on and off.

I would however use a different set of servers for the /48's to
that of serving the /32 (or whatever) as you can just change the
delegation without having to also add and remove zones which you
would if they are on the same servers.
 
I would also provide customers with forward zones that they can
populate again using the /48 to control access.

e.g.
hex.customer.isp.com.

hex is the hexadecimal representation of the /48.

machine.hex.customer.isp.com.  hex:client

They don't need to use it but it should be there to provide complete
the loop.

If HE was following this schema then bsdi would default to:

bsdi.200104701f00.customer.he.net  2001:470:1f00:::5a1
bsdi.200104701f00.customer.he.net  2001:470:1f00:820:2e0:29ff:fe19:c02d

But as I care about the name of the machine it is:

bsdi.dv.isc.org.2001:470:1f00:::5a1
bsdi.dv.isc.org.2001:470:1f00:820:2e0:29ff:fe19:c02d

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

On 4/27/2010 20:28, Larry Sheldon wrote:
 On 4/27/2010 20:25, Richard Barnes wrote:
 off-topic
 IANADBExpert

 Interesting theory, but seems kind of wrong.  Wouldn't the time to
 look up or fail be tied to the complexity of how the key space is
 populated?  In any case, it seems like the time to succeed or fail
 will usually be about the same, since you'll try to access the value
 for a key and either find something there or fail.
 
 The theory is based on the notion that if you find something you stop
 looking for it.  If what you are looking for is not there, you have to
 search all of the key-space, regardless of the index method.

That is why, when I was actively designing (or supervising the design)
of data-bases, we tried to make the most likely hits at the beginning of
the key-space.  In general, easier to say than to do.  And not as
intuitive as you might think.

(In the old days, there was the closely related entertainment of
predicting which benefited most from cached-disc systems, random files
or sequential files.)

-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Re: Starting up a WiMAX ISP

2010-04-27 Thread John Levine

+ I have those numbers I can beat the pavement and find out what people
will pay for my service and then I will know based on my table if there
is a snowball's chance in hell of this working.

Don't forget that you're competing against rural ILECs that drink
deeply from the well of USF funding.  My local telco (Trumansburg)
called me today to point out that I was paying $76/mo for a package of
phone, 3Mb/382Kb DSL, voice mail and caller ID, but if I added in
national long distance and a few other features, they'd give me the
package rate of $66.  They offer 3MB DSL all over their service area,
even those long long rural runs.  You think you can compete with that?

Lightlink does OK against Verizon in Ithaca in the relatively dense
area at the foot of Cayuga Lake, but with, as other people have noted,
the owners doing nearly all the work.

R's,
John

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Steve Bertrand

On 2010.04.27 21:00, David Conrad wrote:
 On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote:
 On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
 Windows will just populate the reverse zone as needed, if you let
 it, using dynamic update.  If you have properly deployed BCP 39
 and have anti-spoofing ingres filtering then you can just let any
 address from the /48 add/remove PTR records.  Other OS's will
 follow suite.

 Is DDNS really considered to be the end-all answer for this?
 
 Seems it is that or not bothering with reverse anymore.

There are other solutions, which has become a major focus of mine based
on some of the results I've gathered from my little test.

About 50% (currently 50.59%) of all successful visits to my site do not
have rDNS configured for their IPv6...

That is a problem that needs a solution.

The OP has a great question here.

Steve

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread John Levine

Hmm. A macro expansion for a /48 would mean
1,208,925,819,614,629,174,706,176 leaves. An interesting stress test
for name servers... :-).

My inclination would be to use a wildcard that returns something like
not-in-service.some-network.net, and let the clients add records for
the addresses they use.

For spoof resistance, how about doing a forward lookup on the
purported name and only installing it if it gets a matching 
record?

R's,
John

Re: Starting up a WiMAX ISP

2010-04-27 Thread John R. Levine

Of course what they offer over those long long rural runs and what they can 
actually provide are two different things.  DSL performance decreases with 
distance rather dramatically..


That's what I thought, but my friend out on the sheep farm in the next 
county says he gets 3Mb just like I do in the village three blocks from 
the CO.  (Yes, he knows what he's talking about.)  They must spend a lot 
on repeaters and concentrators.


R's,
John

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread David Conrad

On Apr 27, 2010, at 6:46 PM, John Levine wrote:

 Hmm. A macro expansion for a /48 would mean
 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test
 for name servers... :-).
 My inclination would be to use a wildcard that returns something like
 not-in-service.some-network.net, and let the clients add records for
 the addresses they use.

While better than 1 septillion zone entries, you still have the problem of how 
to let the clients add the records.  DDNS is one approach.  Manual intervention 
(e.g., as part of a customer provisioning system) is another as long as you 
don't use privacy extensions.

 For spoof resistance, how about doing a forward lookup on the
 purported name and only installing it if it gets a matching 
 record?

Sounds like a reasonable DDNS filtering approach.

Regards,
-drc

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread Felipe Zanchet Grazziotin

On Tue, Apr 27, 2010 at 11:13 PM, David Conrad d...@virtualized.org wrote:

 On Apr 27, 2010, at 6:46 PM, John Levine wrote:

  For spoof resistance, how about doing a forward lookup on the
  purported name and only installing it if it gets a matching 
  record?

 Sounds like a reasonable DDNS filtering approach.


On controlled environments it might work. Don't know how larger ISPs would
set  records before for bazillion possible combinations of
computer.subnet.customer.isp.tld.

If going dynamic, are you willing to lower your DNS TTL to handle that?

Maybe doing wildchar evatulation for /64 subnets? Everything under this
subnet is my-subnet.customer.isp.tld.


 Regards,
 -drc



Kindly,
Felipe

Re: [Nanog] Re: IPv6 rDNS - how will it be done?

2010-04-27 Thread James Hess

On Tue, Apr 27, 2010 at 7:58 PM, Jason 'XenoPhage' Frisvold
xenoph...@godshell.com wrote:
 On Apr 27, 2010, at 8:50 PM, Richard Barnes wrote:
...However, I was under the impression that having both forward and reverse 
for dynamic IPs was a best practice..

Perhaps we should back up a bit and delete 'how' from the subject line
of this thread, and first ask 'Will it be done?'  and where will RDNS
be implemented?

It is best practice within IPv4 networks.   The IPv6 internet is a new
network,  and prevalent practices will not necessarily turn out to be
what we consider best from V4. 'Best practice'  is going to have
to meet with administrative necessity  in some form at some point.

A reality may be that not all hosts necessarily have a meaningful
hostname that they should be addressed by,  or that the 'operator'
(web browser user) wants to be known;  Useful RDNS records may become
more confined to hosts  that  actually  provide a globally accessible
service.

Residential subscribers of ISPyou-are-not-allowed-to-run-a-server
level of DSL/Cable service   will likely not  have their   own domain
name,  providing RDNS delegation would be mostly a waste of resources.

Providing  DDNS updates to RDNS is likely to be abused  in various
ways, even if it can be secured  (malware would love this -- instant
fully RDNS-cognizant mail server).

The prevalent practice is almost certainly going to be for res. ISPs
to provide a NXDOMAIN response to  RDNS queries,  or a generic
response  like is common with V4.

Probably  custom RDNS  would be considered a business service, and
like all business services, have its own pricing schedule,  and
involve subscriber  providing IP addresses of DNS servers to delegate
to.

If  Res.  subscribers are lucky  the big ISPs  might provide a
proprietary app to run on their PC to  magically register it with
RDNS, and enable for connectivity.

With the downside that there can now be an  enforced  per-PC  surcharge.
Consumer DSL providers would probably love this   $60/month,
connectivity for one PC to the internet at X/speed  included. .
 $1/day  extra  for  each additional PC   registered with the DNS,
$0.10/hour  for each Xbox/gaming console/HTPC/Media streaming device
registered for internet access.

*zip bang voom*   4 years later...   IPv6  NAT,  the prevalent
technology present in every $50  IPv6 router,  an unofficial hack that
might some day get an RFC made about it


--
-J

Re: VPN over Comcast

2010-04-27 Thread Aaron C. de Bruyn

On 2010-04-27 at 14:56:04 -0400, schilling wrote:
 http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html
 showed a feature of Gateway Smart Packet Detection in some SMC
 cable modem.

On one of our cable modems I had this manifest itself by dropping
every other packet.

I spent several hours trying to figure that one out, resetting the
modem, and talking with L1 support.  Finally someone higher up said
'Turn off SPD'.

-A

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

Owen DeLong wrote:

On Apr 27, 2010, at 11:49 AM, Matthew Kaufman wrote:

Owen DeLong wrote:

On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote:

Andy Davidson wrote:

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:

Did you use Yahoo IM, AIM, or Skype?

Yes, yes, and yes. Works fine.

What about every other service/protocol that users use today, and might be invented
tomorrow ? Do will they all work with NAT ?

Anyone inventing a new service/protocol that doesn't work with NAT isn't
planning on success.

Respectfully, I disagree. There are many possible innovations that are
available in a NAT-less world and it is desirable to get to that point rather
than hamper future innovation with this obsolete baggage.

I would argue that every one of those innovations, if even passably useful, can
also be implemented in a NAT-full world.

Perhaps, but, often at significant additional code, development time, QA
resources and other costs.
Also, often at a degraded level requiring a non-NAT'd third-party broker to
intermediate between any two NAT'd parties attempting to trade information.

Yes, there's additional development, but if NAT was more standardized
(which it has a chance of being for IPv6, if we'd just stop arguing
about whether or not it is going to happen... it'll happen, the question
is whether or not there'll be a standard to follow) that development
cost could be nearly a one-time library cost vs. custom code to deal
with every situation and changing situations.

Do many others work as well or act reliably through NAT ?

Yes.

In reality, it's more like some yes, some not so much.

== Some designed to work properly in the face of NAT, some ignored reality at
their peril.

We can agree to disagree about this. The reality is that there are cool things
you can do with peer to peer networking that simply aren't possible in an
enforced client-server model.

Agreed.

NAT enforces a client-server model and permanently and irrevocably relegates
some administrative domains to the client role. This is an unfair disadvantage
to the users within those domains when it is not by the choice of the
administrator (and NAT in IPv4 so far, often is not).

No. Most NAT *doesn't* enforce a client-server model, it enforces a
deliberate signaling model for establishing peer-to-peer communication,
and allows open client-server communication (and most communication is,
and will forever be, client-server). Assuming, again, that the NATs
behave reasonably when trying to do peer-to-peer communication through
them, which most (over 90% of what's deployed for IPv4) do. And *all*
could, if there were standards people could code to. Which, again, for
IPv6 there could be, if we'd stop claiming that NAT will never happen /
is a bad idea and so shouldn't be standardized / etc.

Will it stop or hamper the innovation of new services on the
internet ?

Hasn't so far.

Here I have to call BS... I know of a number of cases where it has.

Ok, you called it... so where's the list of such services that haven't
materialized as a result of NAT?

Haven't materialized, for one, is an attempt to redefine the question. Note that the original
question included hamper. I would argue that the cost of maintaining a NAT
compatibility lab and the QA staff to use it is a sufficient burden to call it hamper.

Again, such a lab would not be needed if NAT operation were codified in
standards. Which could happen, if not for the vocal set who keeps
arguing against them, even when there's 5+ good reasons for them, even
in IPv6.

For the ones that did not materialize, however, I am at an unfortunate
disadvantage in the argument. I can tell you that I know of at least 5 such
cases. However, I cannot reveal the details because I am under NDA to the
companies that were developing these products. I can tell you that in 3 of the
5 cases, adapting them to cope with a NAT world would have required the company
to run an external service in perpetuity (or at least so long as the
application would function, no server, no function) in order to do the
match-making between clients that could not directly reach each-other.

I guess a good analogy is this:

In a NAT world, you have only matchmaking services and all of your ability to
meet potential mates is strictly controlled through these matchmaking services.
There are many services available independent of each other, and, each has its
own limitations, biases, and quirks. However, you cannot meet potential mates
without involving at least one matchmaker.

True, but that's essentially true for all software, and certainly true
for all web-based software.

In a NAT-Free world, you have

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?