Re: RFC 1149

[Valdis . Kletnieks]

On Tue, 02 Apr 2013 19:00:35 -0400, "Mike." said:

> Oddly, prehaps, those punchcards on the stagecoaches probably will
> outlast any magnetic media we have at our disposal today

Here's a picture of an estimated 4.3G of data on punch cards:

http://en.wikipedia.org/wiki/File:IBM_card_storage.NARA.jpg

20 rows of pallets, each row is 15 pallets, stacked 2 high, 45 boxes
of 2,000 to the pallet.

One has to wonder if those pallets are still there




pgpxT3lO2uuI_.pgp
Description: PGP signature

Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

[Seth Mattinen]

On 4/2/13 2:24 PM, Carlos Alcantar wrote:
> You might want to consider putting up a speedtest server internal to your
> network.  I know there is a fee but well worth it I believe.  You will
> still need to take the results with a grain a salt but you will have the
> best results as well.
> 

The speedtest.net mini version is free. Same test methodology and brand
recognition for the customers to be satisfied. Paid version if you need
branding or whatever.

~Seth

Re: Mikrotik visibility

[Beavis]

thanks all this is a good start.


regards,
-Beavis

On Tue, Apr 2, 2013 at 8:22 PM, Yang Yu  wrote:
> I am using Plixer Scrutinizer Flow Analyzer with RouterOS. It does
> have cool looking web panel. But some interfaces (instance 0, instance
> 1 etc.) reported doesn't exactly match up with interfaces in RouterOS.
> I haven't figured out what exactly those are.
>
> Yang



-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Re: Mikrotik visibility

[Yang Yu]

I am using Plixer Scrutinizer Flow Analyzer with RouterOS. It does
have cool looking web panel. But some interfaces (instance 0, instance
1 etc.) reported doesn't exactly match up with interfaces in RouterOS.
I haven't figured out what exactly those are.

Yang

Re: RFC 1149

[Jay Ashworth]

- Original Message -
> From: "Steven Bellovin" 

> DLT? I first heard it as a station wagon full of (9-track, 1600 bpi,
> that having been the state of the art) mag tapes on the Taconic Parkway,
> circa 1970. I suspect, though, that Herman Hollerith expressed the idea
> about a stage coach full of punchcards, back in the 1880s.

The earliest reference to this I've been able to pin down is Andy Tanenbaum's,
and TTBOMK -- and you of all people should know this, Steve -- he was talking
about Usenet, which a few sites actually *got feeds of on magtape*, in the
very early 80s.  Some of those tapes, in addition to UTZoo's backups of their
spool, constituted the very earliest material given to Dejagoo.

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

Re: RFC 1149

[Owen DeLong]

Things get upgraded over time.

Owen

On Apr 2, 2013, at 15:44 , Steven Bellovin  wrote:

> DLT?  I first heard it as a station wagon full of (9-track, 1600 bpi,
> that having been the state of the art) mag tapes on the Taconic Parkway,
> circa 1970.  I suspect, though, that Herman Hollerith expressed the idea 
> about a stage coach full of punchcards, back in the 1880s.
> 
> 
> On Apr 2, 2013, at 3:41 PM, Owen DeLong  wrote:
> 
>> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
>> 
>> Owen
>> 
>> On Apr 2, 2013, at 11:31 , "Scott Berkman"  wrote:
>> 
>>> Hey careful, Pigeons have won this fight before:
>>> 
>>> http://news.bbc.co.uk/2/hi/8248056.stm
>>> 
>>> -Original Message-
>>> From: George Herbert [mailto:george.herb...@gmail.com] 
>>> Sent: Monday, April 01, 2013 10:37 PM
>>> To: Jeff Kell
>>> Cc: NANOG
>>> Subject: Re: RFC 1149
>>> 
>>> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
>>> routing protocol extension hasn't been experimentally validated yet.
>>> 
>>> Whoever you are who keeps flying pigeons between my test towers, you can't
>>> deliver packets without proper routing updates!  Knock it off long enough
>>> for me to converge the #@$#$@ routing table...
>>> 
>>> 
>>> 
>>> On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell  wrote:
>>> 
 On 4/1/2013 10:15 PM, Eric Adler wrote:
> Make sure you don't miss the QoS implementation of RFC 2549 (and 
> make
 sure
> that you're ready to implement RFC 6214).  You'll be highly 
> satisfied
 with
> the results (presuming you and your packets end up in one of the 
> higher quality classes).
> I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
> the hurricane zone, but modified by implementing zip ties such that 
> the C47s aren't released under heavy (wind or water) loads.
 
 Actually, given recent events, I'd emphasize and advocate RFC3514
 (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
 for adoption.  The implementation would forego most of the currently 
 debated topics as related to network abuse or misuse :)
 
 Jeff
 
 
 
>>> 
>>> 
>>> --
>>> -george william herbert
>>> george.herb...@gmail.com
>>> 
>> 
>> 
>> 
> 
> 
>   --Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 

Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

[Alex Pressé]

The speedtest.net site has a free mini edition
(http://www.speedtest.net/mini.php) you can download and extract to
some http available path (asp, php, jsp all supported). It's a flash
applet, easy to wrap into your own page. Transfers one of ten large
JPG files of random noise (largest is 31MB). IIRC, it somehow does a
pretest to select a file that should take > 10 seconds.

If you're connected at >100Mbit to the hosting server then the results
are rather bogus (not enough time in flight to get any meaningful
averages).

Demos (found via google): https://test.kems.net/
http://speedtest.qualitynet.net/ http://speedtest.fsr.com/

Pros: not a java applet
Cons: adobe flash applet

On Tue, Apr 2, 2013 at 4:37 PM, Scott Weeks  wrote:
>
>
> 
> You might want to consider putting up a speedtest server internal to your
> network.  I know there is a fee but well worth it I believe.  You will
> 
>
>
> I would consider NDT as well: www.internet2.edu/performance/ndt
>
> Last I checked, about 3 years ago, speedtest sent only latin text in
> large packets.  NDT tests much more.  The customers just use a web
> browser and the only caveat is they need to have Java working.
>
> Here's one to get a feeling of what your customers will see:
> http://ndt.anl.gov:7123
>
> scott
>



-- 
Alex Presse
"How much net work could a network work if a network could net work?"

Re: Open Resolver Problems

[John Kristoff]

On Tue, 2 Apr 2013 18:41:17 -0400
Joe Abley  wrote:

> 26/1000 is more than zero but still quite small. Subsequent samples
> with bigger sizes give 332/10, 3017/100.
> 
> No science here, but 2% - 3% is what it looks like, which is big
> enough to be a noticeable support cost for a medium-scale provider if
> the customer damage is not robo-mediated in some way (e.g. whitelist
> known offenders to avoid the support phone glowing red when you first
> turn it on).

Thanks Joe.  That is interesting.

I can only imagine that on the customer side there are queries coming
from something other than typical OS stub resolvers on unix and
Windows based hosts.  I suppose some sort of NAT/PAT box could account
for some of it, maybe more likely could be some common CPE forwarder
that uses that port by default.  If the latter, that might be
considered a serious enough risk that the vendor should address it if
they haven't already.

If no one else does, another side project I'll add to my list of things
to do on a rainy day.

John

80 km BiDi XFPs

[Frank Bulk]

Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
supplier of generics doesn't have an option for us, but I would really like
to avoid leasing additional fibers.

Frank

Re: RFC 1149

[Mike.]

On 4/2/2013 at 6:44 PM Steven Bellovin wrote:

|DLT?  I first heard it as a station wagon full of (9-track, 1600 bpi,
|that having been the state of the art) mag tapes on the Taconic
Parkway,
|circa 1970.  I suspect, though, that Herman Hollerith expressed the
idea 
|about a stage coach full of punchcards, back in the 1880s.



Oddly, prehaps, those punchcards on the stagecoaches probably will
outlast any magnetic media we have at our disposal today

Re: RFC 1149

[Steven Bellovin]

DLT?  I first heard it as a station wagon full of (9-track, 1600 bpi,
that having been the state of the art) mag tapes on the Taconic Parkway,
circa 1970.  I suspect, though, that Herman Hollerith expressed the idea 
about a stage coach full of punchcards, back in the 1880s.


On Apr 2, 2013, at 3:41 PM, Owen DeLong  wrote:

> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
> 
> Owen
> 
> On Apr 2, 2013, at 11:31 , "Scott Berkman"  wrote:
> 
>> Hey careful, Pigeons have won this fight before:
>> 
>> http://news.bbc.co.uk/2/hi/8248056.stm
>> 
>> -Original Message-
>> From: George Herbert [mailto:george.herb...@gmail.com] 
>> Sent: Monday, April 01, 2013 10:37 PM
>> To: Jeff Kell
>> Cc: NANOG
>> Subject: Re: RFC 1149
>> 
>> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
>> routing protocol extension hasn't been experimentally validated yet.
>> 
>> Whoever you are who keeps flying pigeons between my test towers, you can't
>> deliver packets without proper routing updates!  Knock it off long enough
>> for me to converge the #@$#$@ routing table...
>> 
>> 
>> 
>> On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell  wrote:
>> 
>>> On 4/1/2013 10:15 PM, Eric Adler wrote:
 Make sure you don't miss the QoS implementation of RFC 2549 (and 
 make
>>> sure
 that you're ready to implement RFC 6214).  You'll be highly 
 satisfied
>>> with
 the results (presuming you and your packets end up in one of the 
 higher quality classes).
 I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
 the hurricane zone, but modified by implementing zip ties such that 
 the C47s aren't released under heavy (wind or water) loads.
>>> 
>>> Actually, given recent events, I'd emphasize and advocate RFC3514
>>> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
>>> for adoption.  The implementation would forego most of the currently 
>>> debated topics as related to network abuse or misuse :)
>>> 
>>> Jeff
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> -george william herbert
>> george.herb...@gmail.com
>> 
> 
> 
> 


--Steve Bellovin, https://www.cs.columbia.edu/~smb

Re: Open Resolver Problems

[Joe Abley]

On 2013-04-02, at 18:18, John Kristoff  wrote:

> I would expect from stubs this will be close enough to zero to be
> effectively zero.  At least I would hope so.

This (below) is one of four resolvers, together providing service for two 
recursive DNS servers used by residential DSL and cable internet users at a 
medium-sized ISP in Canada. These resolvers are running unbound, which will 
never choose a source port of 53 on an outbound query; hence anything we see 
here with src port = dst port = 53 is one of those effective zeros.

[dns1-p1:~]% sudo tcpdump -i em0 -n -c 1 -w sample.pcap udp port 53   
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
1 packets captured
10267 packets received by filter
0 packets dropped by kernel
[dns1-p1:~]% tcpdump -r sample.pcap -q udp src port 53 and udp dst port 53 | wc 
-l
reading from file sample.pcap, link-type EN10MB (Ethernet)
  26
[dns1-p1:~]% 

26/1000 is more than zero but still quite small. Subsequent samples with bigger 
sizes give 332/10, 3017/100.

No science here, but 2% - 3% is what it looks like, which is big enough to be a 
noticeable support cost for a medium-scale provider if the customer damage is 
not robo-mediated in some way (e.g. whitelist known offenders to avoid the 
support phone glowing red when you first turn it on).


Joe

Re: RFC 1149

[Mike.]

On 4/2/2013 at 5:19 PM Jay Ashworth wrote:

|- Original Message -
|> From: "Owen DeLong" 
|
|> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
|
|Aww you remembered.
|
|  http://baylink.pitas.com/20110516.html#747F
 =

Staying more in the realm of what most on this list can afford... what
is the bandwidth of the following, when loaded with DLT carts - USPS
11" x 8-1/2" x 5-1/2" box, $40, 2 day delivery in the US

Re: Open Resolver Problems

[John Kristoff]

On Mon, 1 Apr 2013 19:40:03 +0100
Tony Finch  wrote:

> You should be able to get a reasonable sample of IPv6 resolvers from
> the query logs of a popular authoritative server.

When I tried this in the past for IPv4, I missed the majority of
potential open resolvers / open forwarders on the net compared to just
searching the entire address space.  And I was examining this from
the perspective of what a very large TLD was seeing.

I think it is likely that there are going to be a significant number of
IPv6-based resolvers that are aren't as easily knowable. This of course
is potentially good too, since if they are really that hard to find,
then it makes them less likely to be as easily abused.

So, in addition to BCP 38 (and don't forget to mention BCP 84 in the
same breath), RRL for auth servers and hardening/closing resolvers... we
should be advocating the migration to DNS over IPv6-only?  :-)

John

Re: Open Resolver Problems

[John Kristoff]

On Mon, 1 Apr 2013 20:33:36 +0200 (CEST)
Mikael Abrahamsson  wrote:

> > You're sending queries, not replies.  That's why DPI is needed to
> > do the blocking, rather than just by port.
> 
> What queries are sourced from port 53 nowadays?

I would expect from stubs this will be close enough to zero to be
effectively zero.  At least I would hope so.  I don't have a great
source of insight for a resolver of this type of source data that I
can easily look at the moment, but if someone does I'd be interested
to hear otherwise.

On the authoritative side, which is easier for me to examine however,
when I've looked at this before, and the last time was a year ago it
was about 1% of all queries came from resolvers using source port 53.  I
just now checked another server and the percentage is practically the
same.  Before anyone dismisses 1% of queries as insignificant, keep in
mind that if all remaining queries from all other possible source port
values were equally distributed, that 1% (1 out of 100) is easily more
common than any other.

John

Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

[Scott Weeks]

You might want to consider putting up a speedtest server internal to your
network.  I know there is a fee but well worth it I believe.  You will



I would consider NDT as well: www.internet2.edu/performance/ndt

Last I checked, about 3 years ago, speedtest sent only latin text in
large packets.  NDT tests much more.  The customers just use a web
browser and the only caveat is they need to have Java working.

Here's one to get a feeling of what your customers will see:
http://ndt.anl.gov:7123

scott

Mikrotik visibility

[Beavis]

Hello All,

I would like to ask if there are any folks out there that use any
specific tool (OpenSource/Closed) that is used for mikrotik routers. I
need packet visibility (ala netflow) or anything similar to that
effect.


any suggestions are greatly appreciated.


cheers,
-Beavis

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

[Carlos Alcantar]

You might want to consider putting up a speedtest server internal to your
network.  I know there is a fee but well worth it I believe.  You will
still need to take the results with a grain a salt but you will have the
best results as well.

Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / car...@race.com / http://www.race.com





-Original Message-
From: Lorell Hathcock 
Date: Tuesday, April 2, 2013 12:54 PM
To: "nanog@nanog.org" 
Subject: RE: Speedtest Results speedtest.net vs Mikrotik bandwidth test

Thanks for the many helpful suggestions I received offline.

One thing that I was able to deduce was that one of the radios along the
path had Ethernet auto negotiate turned on.  I turned it off and the TCP
speeds went way up.  It seems that UDP was not affected by this setting
while TCP was.

Thanks again!

Lorell



-Original Message-
From: Justin M. Streiner [mailto:strei...@cluebyfour.org]
Sent: Monday, April 01, 2013 7:27 PM
To: nanog@nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

On Mon, 1 Apr 2013, Lorell Hathcock wrote:

> I am having some speedtest results that are difficult to interpret.
>
> Some of my customers have begun complaining that they are not getting
> the proper speeds.  They are using speedtest.net and/or speakeasy.net
> to test the results.

Take the speedtest results with a grain of salt.  Once traffic leaves your
network, you no longer have (much) control over how packets flow across the
'rest of the internet'.

Did the customers report when the issue started?
Are they seeing other performance problems (latency/jitter/packet loss)?
Are you sure no internal links/routers are being saturated, even for brief
periods of time?

jms

Re: RFC 1149

[Jay Ashworth]

- Original Message -
> From: "TJ" 

> On Tue, Apr 2, 2013 at 3:41 PM, Owen DeLong  wrote:
> 
> > "Never underestimate the bandwidth of a 747 full of DLT cartridges."
> 
> XKCD is all over this: http://what-if.xkcd.com/31/
> :)

I have always wondered what kind of station wagon Andy had in mind; the
SRT-8 Magnum didn't exist when he said that...

Cheers,
-- jr 'hurtling?' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: RFC 1149

[Jay Ashworth]

- Original Message -
> From: "Owen DeLong" 

> "Never underestimate the bandwidth of a 747 full of DLT cartridges."

Aww you remembered.

  http://baylink.pitas.com/20110516.html#747F

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

RE: Speedtest Results speedtest.net vs Mikrotik bandwidth test

[Lorell Hathcock]

Thanks for the many helpful suggestions I received offline.

One thing that I was able to deduce was that one of the radios along the
path had Ethernet auto negotiate turned on.  I turned it off and the TCP
speeds went way up.  It seems that UDP was not affected by this setting
while TCP was.

Thanks again!

Lorell



-Original Message-
From: Justin M. Streiner [mailto:strei...@cluebyfour.org] 
Sent: Monday, April 01, 2013 7:27 PM
To: nanog@nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

On Mon, 1 Apr 2013, Lorell Hathcock wrote:

> I am having some speedtest results that are difficult to interpret.
>
> Some of my customers have begun complaining that they are not getting 
> the proper speeds.  They are using speedtest.net and/or speakeasy.net 
> to test the results.

Take the speedtest results with a grain of salt.  Once traffic leaves your
network, you no longer have (much) control over how packets flow across the
'rest of the internet'.

Did the customers report when the issue started?
Are they seeing other performance problems (latency/jitter/packet loss)?
Are you sure no internal links/routers are being saturated, even for brief
periods of time?

jms

Re: RFC 1149

[TJ]

On Tue, Apr 2, 2013 at 3:41 PM, Owen DeLong  wrote:

> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
>
> Owen


XKCD is all over this: http://what-if.xkcd.com/31/
:)

/TJ

Re: RFC 1149

[Owen DeLong]

"Never underestimate the bandwidth of a 747 full of DLT cartridges."

Owen

On Apr 2, 2013, at 11:31 , "Scott Berkman"  wrote:

> Hey careful, Pigeons have won this fight before:
> 
> http://news.bbc.co.uk/2/hi/8248056.stm
> 
> -Original Message-
> From: George Herbert [mailto:george.herb...@gmail.com] 
> Sent: Monday, April 01, 2013 10:37 PM
> To: Jeff Kell
> Cc: NANOG
> Subject: Re: RFC 1149
> 
> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
> routing protocol extension hasn't been experimentally validated yet.
> 
> Whoever you are who keeps flying pigeons between my test towers, you can't
> deliver packets without proper routing updates!  Knock it off long enough
> for me to converge the #@$#$@ routing table...
> 
> 
> 
> On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell  wrote:
> 
>> On 4/1/2013 10:15 PM, Eric Adler wrote:
>>> Make sure you don't miss the QoS implementation of RFC 2549 (and 
>>> make
>> sure
>>> that you're ready to implement RFC 6214).  You'll be highly 
>>> satisfied
>> with
>>> the results (presuming you and your packets end up in one of the 
>>> higher quality classes).
>>> I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
>>> the hurricane zone, but modified by implementing zip ties such that 
>>> the C47s aren't released under heavy (wind or water) loads.
>> 
>> Actually, given recent events, I'd emphasize and advocate RFC3514
>> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
>> for adoption.  The implementation would forego most of the currently 
>> debated topics as related to network abuse or misuse :)
>> 
>> Jeff
>> 
>> 
>> 
> 
> 
> --
> -george william herbert
> george.herb...@gmail.com
> 

RE: RFC 1149

[Scott Berkman]

Hey careful, Pigeons have won this fight before:

http://news.bbc.co.uk/2/hi/8248056.stm

-Original Message-
From: George Herbert [mailto:george.herb...@gmail.com] 
Sent: Monday, April 01, 2013 10:37 PM
To: Jeff Kell
Cc: NANOG
Subject: Re: RFC 1149

Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
routing protocol extension hasn't been experimentally validated yet.

Whoever you are who keeps flying pigeons between my test towers, you can't
deliver packets without proper routing updates!  Knock it off long enough
for me to converge the #@$#$@ routing table...



On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell  wrote:

> On 4/1/2013 10:15 PM, Eric Adler wrote:
> > Make sure you don't miss the QoS implementation of RFC 2549 (and 
> > make
> sure
> > that you're ready to implement RFC 6214).  You'll be highly 
> > satisfied
> with
> > the results (presuming you and your packets end up in one of the 
> > higher quality classes).
> > I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
> > the hurricane zone, but modified by implementing zip ties such that 
> > the C47s aren't released under heavy (wind or water) loads.
>
> Actually, given recent events, I'd emphasize and advocate RFC3514
> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
> for adoption.  The implementation would forego most of the currently 
> debated topics as related to network abuse or misuse :)
>
> Jeff
>
>
>


--
-george william herbert
george.herb...@gmail.com

RE: New Product Launch from 2600hz

[Brian Johnson]

Owen,

Was this actually posted anywhere. I'm pretty sure it's a joke, but I would 
like to send it to a vendor who keeps asking when we will need IPv6 support :)

Thanks.

Brian Johnson
Converged Network Engineer
CCNP, CCNP Security & MEF-CECP Certified

> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Monday, April 01, 2013 7:07 PM
> To: Joshua Goldbard
> Cc: 
> Subject: Re: New Product Launch from 2600hz
> 
> Goes in the same category as this bit of news:
> 
> 
> IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly
> announced that IPv4 would no longer be supported on the global internet
> after 1/1/2014. Those wishing to continue using the internet in 2014 and
> beyond
> should move to IPv6.
> 
> 
> Owen
> 
> On Apr 1, 2013, at 4:09 PM, Joshua Goldbard  wrote:
> 
> > Hello,
> >
> > Normally I wouldn't bother the respected members of NANOG with a
> product launch email, but this is such a unique application that I felt it was
> necessary.
> >
> > 2600hz is saying goodbye to SMS, Voice and even Video. Today we're
> launching a service we'd like to call BrainRTC. It's going to completely
> revolutionize communications.
> >
> > Check it out here: http://blog.2600hz.com/post/46886639094/voice-and-
> video-are-dead-heres-the-future
> >
> > Cheers,
> > Joshua
> >
> > Joshua Goldbard
> > VP of Marketing, 2600hz
> >
> > 116 Natoma Street, Floor 2
> > San Francisco, CA, 94104
> > 415.886.7923 | j...@2600hz.com
> 

Re: BCP38 tester?

[Jay Ashworth]

- Original Message -
> From: "Jimmy Hess" 

> On 4/1/13, Jay Ashworth  wrote:
> >> It would just be way too much luck and convenience for that to
> >> happen
> >> by coincidence.
> >
> > Once in a while, you win.
> 
> The trouble with winning by coincidence or winning as a side-effect...
> Do you keep winning?

Depends on how you won.

> What happens with IPv6 CPE devices, when there is no NAT?

Well, that's going to be an interesting question in general: 
will v6 edge routers a) exist, b) handle the addressing, c) handle
DHCP, d) actually not do NAT, or e) NAT a v4 home network to a v6
address/network?

> No translation occurs, so possibly rogue source IP packets get
> through, unless the device specifically applies uRPF or clamping
> source addresses to the LAN interface subnet.
> 
> It would be nice if the RFCs specified Ingress filtering by default in
> router requirements for IPv4 and IPv6, as a MUST requirement; instead
> of some 2nd class citizen, optional best practices document.

Nah.  That's *not* ingress filtering, for all practical purposes; it's 
*egress* filtering -- filtering that's under control of the network 
operating entity, and thus semi-useless for the purposes at hand.

(On re-reading that, I see I'm not entirely clear: any filtering has to
be done on the upsptream end of the link, so that it is *not* in control
of the entity which might be originating the bad packets; John Carmack
illustrated why in his piece about Quake cheating.  What; you haven't 
read that piece?  And you run networks?  :-)

Cheers,
-- jra

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

Re: RFC 1149

[Jared Mauch]

On Apr 1, 2013, at 10:37 PM, George Herbert  wrote:

> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
> routing protocol extension hasn't been experimentally validated yet.
> 
> Whoever you are who keeps flying pigeons between my test towers, you can't
> deliver packets without proper routing updates!  Knock it off long enough
> for me to converge the #@$#$@ routing table...

I'm working to make our network comply with the latest standards in rfc6919

- Jared

RE: Open Resolver Problems

[Jamie Bowden]

> From: Dobbins, Roland [mailto:rdobb...@arbor.net]
> On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote:


> >  Such lines are tantamount to extortion especially if the ISP supplies
> commercial grade lines.


> Patrick's talking about consumer broadband access.  Such AUP stipulations
> are quite common.


> This is in no way 'tantamount to extortion'.  Folks can either accept the AUP,
> or choose not to enter into a contract for the service in question under those
> conditions; there is no compulsion or coercion to do so.

And that would be a valid response if we actually lived in a place where I, or 
anyone else, had more than two choices, both offering roughly the same terms 
and pricing.  In my little corner of Fairfax Co, we have Cox or FiOS.  Across 
the Potomac in Montgomery, they can pick between Comcast and FiOS.  I hear that 
in other bits of the US, your cable and telco might be different, but other 
than the label, nothing else is.

Jamie

Re: Open Resolver Problems

[Måns Nilsson]

Subject: Re: Open Resolver Problems Date: Tue, Apr 02, 2013 at 05:25:53AM +0200 
Quoting Mikael Abrahamsson (swm...@swm.pp.se):
> On Tue, 2 Apr 2013, Måns Nilsson wrote:
> 
> >What percentage of the SOHO NAT boxes actually are full-service
> >resolvers? I was under the impression that most were mere
> >forwarders; just pushing queries on toward the DHCP'd full service
> >resolvers of the ISP.
> 
> What does that help? They can still be amplifiers, it's just that
> now the ISP resolver will see the resolving load as well.

But, yes, of course. Nobody would be so stupid so ast o accept queries
on the WAN side and answer them? Would they? 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
My vaseline is RUNNING...


signature.asc
Description: Digital signature

Re: BCP38 tester?

[Jimmy Hess]

On 4/1/13, Jay Ashworth  wrote:
>> It would just be way too much luck and convenience for that to happen
>> by coincidence.
>
> Once in a while, you win.

The trouble with winning by coincidence or winning as a side-effect...
Do you keep winning?

What happens with IPv6 CPE devices,  when there is no NAT?
No translation occurs, so possibly  rogue source IP packets get
through,  unless the device specifically applies uRPF  or clamping
source addresses to the LAN interface subnet.

It would be nice if the RFCs specified Ingress filtering by default in
router requirements for IPv4 and IPv6, as a MUST requirement;  instead
of  some   2nd class citizen, optional  best practices document.

By specifying ingress as the default, it then becomes an implementor
responsibility to understand when and where in their network they have
to override the default for things to work properly,  when it is safe
to,   and where the filtering is required.

--
-JH