Re: Coded TCP

2012-10-23 Thread Masataka Ohta 
(2012/10/24 12:29), Rodrick Brown wrote:
> "With coded TCP, blocks of packets are clumped together and then
> transformed into algebraic equations that describe the packets. If
> part of the message is lost, the receiver can solve the equation to
> derive the missing data.

Don't do that.

> MIT found that campus WiFi (2%
> packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5%
> packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps."

If everyone start using TCP with FEC to tolerate 20% of packet
loss with 30% FEC overhead, it will make congestion more severe
that more than 20% of packets will be dropped and effective speed
share of each TCP will be decreased by 30%.

The proper approach against lossy liks is to have link local
retransmissions or FEC.

Masataka Ohta

Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

2012-10-23 Thread Joel Maslak 
On Tue, Oct 23, 2012 at 9:18 AM, Mike Jones  wrote:
> IPv4 addresses ending in .0 and .255 can't be used either because the
> top and bottom addresses of a subnet are unusable.
>
> Why would hetzner be making such assumptions about what is and is not
> a valid address on a remote network? if you have a route to it then it
> is a valid address that you should be able to exchange packets with,
> any assumptions beyond that are almost certainly going to be wrong
> somewhere.

As to why: I suspect they don't know either.  I wouldn't be surprised
if it was someone's misguided attempt years ago to stop smurf
amplification attacks, long since forgotten.  I'm not saying it's a
good idea (it's not), just why I suspect someone would do this.

Re: Coded TCP

2012-10-23 Thread George Herbert 
I understand and believe in the value of erasure coding, though I want to see 
the latency effects here.  But that model was very detailed view into an overly 
simple (to the point of operationally unrealistic) model.  Bad example, for a 
research paper.


George William Herbert
Sent from my iPhone

On Oct 23, 2012, at 8:57 PM, "Michael Painter"  wrote:

> George Herbert wrote:
>> Modeled with just simple FTP sessions?
>> 
>> Ugh: they admitted to having MIT backbone packet traces to analyze, and then 
>> used that simple of a simulator...
> 
> 
> The practical benefits of the technology, known as coded TCP, were seen on a 
> recent test run on a New York-to-Boston Acela train, notorious for poor 
> connectivity. By increasing their available bandwidth-the amount of data that 
> can be relayed in a given period of time-Medard and students were able to 
> watch blip-free YouTube videos while some other passengers struggled to get 
> online. "They were asking us 'How did you do that?' and we said 'We're 
> engineers!' " she jokes.
> 
> More here:
> http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/?utm_campaign=newsletters&utm_source=newsletter-daily-all&utm_medium=email&utm_content=20121023
>  
>

Re: Coded TCP

2012-10-23 Thread Michael Painter 

George Herbert wrote:

Modeled with just simple FTP sessions?

Ugh: they admitted to having MIT backbone packet traces to analyze, and then 
used that simple of a simulator...



The practical benefits of the technology, known as coded TCP, were seen on a recent test run on a New York-to-Boston Acela 
train, notorious for poor connectivity. By increasing their available bandwidth-the amount of data that can be relayed in 
a given period of time-Medard and students were able to watch blip-free YouTube videos while some other passengers 
struggled to get online. "They were asking us 'How did you do that?' and we said 'We're engineers!' " she jokes.


More here:
http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/?utm_campaign=newsletters&utm_source=newsletter-daily-all&utm_medium=email&utm_content=20121023

Re: Coded TCP

2012-10-23 Thread George Herbert 

Modeled with just simple FTP sessions?

Ugh: they admitted to having MIT backbone packet traces to analyze, and then 
used that simple of a simulator...

George William Herbert
Sent from my iPhone

On Oct 23, 2012, at 8:29 PM, Rodrick Brown  wrote:

> "With coded TCP, blocks of packets are clumped together and then
> transformed into algebraic equations that describe the packets. If
> part of the message is lost, the receiver can solve the equation to
> derive the missing data. The process of solving the equations is
> simple and linear, meaning it doesn't require much processing on
> behalf of the router/smartphone/laptop. In testing, the coded TCP
> resulted in some dramatic improvements. MIT found that campus WiFi (2%
> packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5%
> packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps."
> 
> http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf
> 
> --RB
>

Coded TCP

2012-10-23 Thread Rodrick Brown 
"With coded TCP, blocks of packets are clumped together and then
transformed into algebraic equations that describe the packets. If
part of the message is lost, the receiver can solve the equation to
derive the missing data. The process of solving the equations is
simple and linear, meaning it doesn't require much processing on
behalf of the router/smartphone/laptop. In testing, the coded TCP
resulted in some dramatic improvements. MIT found that campus WiFi (2%
packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5%
packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps."

http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf

--RB

Re: Inter-domain OTN, does it happen in the real world?

2012-10-23 Thread Phil Bedard 
Most telcos can provide an OTU2 client interface but there is no peering, they 
are just mapping directly to a wavelength or to OTU3/4.  So it's transparent 
service. 

Phil

On Oct 23, 2012, at 7:07 PM, Will Orton  wrote:

> Reading about OTN networks, I see that "IrDI" is specified to handle the case 
> where one OTN network needs to connect to another natively with OTN signals.
> 
> Is this done in the real world? Does OTN network operator A ever go to OTN 
> network operator B and say, "I'd like to buy a OTU2 from city X to city Y on 
> your 
> long haul network (at buildings J and K where we can connect simply with 
> short-distance SMF/1310 signals), and what TCM levels can you give me?"
> 
> I understand this in the case of lit 10GbE-WANPHY, LAN, and OC-192, but are 
> OTU 
> "lit" signals bought and sold wholesale this way too? Is there generally a 
> price 
> premium over the more normal client signals?
> 
> -Will Orton
> 
>

Re: Tech for blocking particular YouTube video - Wired.com question

2012-10-23 Thread Suresh Ramasubramanian 
Most countries that implement a great firewall of $country model already do
route all their international outbound traffic through a common gateway.

Still others use the mechanism of sending a court order to all registered
ISPs in the country asking them to block whichever URL it is.

If that ISP uses a transparent proxy, or Cisco NBAR or whatever suits their
individual architecture, that is entirely up to them

And yes, at least some YouTube videos have gone viral within individual
countries and triggered riots.  Videos with content like, say, a group of
people belonging to a particular religion demolishing and kicking down the
country's equivalent to the tomb of the unknown soldier

On Wednesday, October 24, 2012, JP Viljoen wrote:

> On 23 Oct 2012, at 11:52 PM, Ryan Singel >
> wrote:
> > A colleague is working on a story that a particular country not to be
> named
> > implemented technology to block a particular infamous riot-inducing video
> > for a certain section of its populace.
> >
> > The questions are: 1) how hard is this to do at scale, 2) does it require
> > DPI equipment and 3) is there a way to prove, from an end node, that it's
> > happening?
>
> Challenge number one, push all your HTTP through one specific place. Not
> that hard. Choke all your traffic via a single routed path, WCCP or
> whatever it off from there. Just need equipment that can handle it. I'm
> going to make a slight assumption here on the level of traffic required,
> since it's likely not /that/ much in those warring regions. But if you need
> more traffic, you may exceed device limits, and then you might run into
> interesting state sharing issues on async routing (if the traffic out goes
> over one router (thus one cache), and back via another router/cache combo).
> If you have enough budget, it's doable.
>
> On question 2) I'd guess only if people were tunnelling HTTPS in normal
> HTTP. You could block HTTPS at port level, which would make YouTube (in
> normal operation) only be available over HTTP. You'd need tunnelling of
> whatever sort to get around this.
>
> 3) …possibly. I would hazard to say it'd depend on how they're going about
> blocking in.
>
> To get back to 1: the moment you choke all the traffic through WCCP, you
> can hand it off to application servers that you maintain, and on those app
> servers you can then do whatever you like. This is how lots of
> semi-transparent/transparent caching is implemented.
>
> If you need more info, feel free to mail me directly.
>
> -J
>


-- 
--srs (iPad)

Inter-domain OTN, does it happen in the real world?

2012-10-23 Thread Will Orton 
Reading about OTN networks, I see that "IrDI" is specified to handle the case 
where one OTN network needs to connect to another natively with OTN signals.

Is this done in the real world? Does OTN network operator A ever go to OTN 
network operator B and say, "I'd like to buy a OTU2 from city X to city Y on 
your 
long haul network (at buildings J and K where we can connect simply with 
short-distance SMF/1310 signals), and what TCM levels can you give me?"

I understand this in the case of lit 10GbE-WANPHY, LAN, and OC-192, but are OTU 
"lit" signals bought and sold wholesale this way too? Is there generally a 
price 
premium over the more normal client signals?

-Will Orton

Re: Tech for blocking particular YouTube video - Wired.com question

2012-10-23 Thread JP Viljoen 
On 23 Oct 2012, at 11:52 PM, Ryan Singel  wrote:
> A colleague is working on a story that a particular country not to be named
> implemented technology to block a particular infamous riot-inducing video
> for a certain section of its populace.
> 
> The questions are: 1) how hard is this to do at scale, 2) does it require
> DPI equipment and 3) is there a way to prove, from an end node, that it's
> happening?

Challenge number one, push all your HTTP through one specific place. Not that 
hard. Choke all your traffic via a single routed path, WCCP or whatever it off 
from there. Just need equipment that can handle it. I'm going to make a slight 
assumption here on the level of traffic required, since it's likely not /that/ 
much in those warring regions. But if you need more traffic, you may exceed 
device limits, and then you might run into interesting state sharing issues on 
async routing (if the traffic out goes over one router (thus one cache), and 
back via another router/cache combo). If you have enough budget, it's doable.

On question 2) I'd guess only if people were tunnelling HTTPS in normal HTTP. 
You could block HTTPS at port level, which would make YouTube (in normal 
operation) only be available over HTTP. You'd need tunnelling of whatever sort 
to get around this.

3) …possibly. I would hazard to say it'd depend on how they're going about 
blocking in.

To get back to 1: the moment you choke all the traffic through WCCP, you can 
hand it off to application servers that you maintain, and on those app servers 
you can then do whatever you like. This is how lots of 
semi-transparent/transparent caching is implemented.

If you need more info, feel free to mail me directly.

-J

Re: Tech for blocking particular YouTube video - Wired.com question

2012-10-23 Thread Mike Lyon 
And of course, we all know, it was the video that induced the riot... :)

-mike

Sent from my iPhone

On Oct 23, 2012, at 14:53, Ryan Singel  wrote:

> A colleague is working on a story that a particular country not to be named
> implemented technology to block a particular infamous riot-inducing video
> for a certain section of its populace.
>
> The questions are: 1) how hard is this to do at scale, 2) does it require
> DPI equipment and 3) is there a way to prove, from an end node, that it's
> happening?
>
> Off-list replies are fine, even better are folks willing to talk on record.
>
> I appreciate any help you can give.
>
> Ryan Singel
> Editor
> Wired
> Threat Level

Tech for blocking particular YouTube video - Wired.com question

2012-10-23 Thread Ryan Singel 
A colleague is working on a story that a particular country not to be named
implemented technology to block a particular infamous riot-inducing video
for a certain section of its populace.

The questions are: 1) how hard is this to do at scale, 2) does it require
DPI equipment and 3) is there a way to prove, from an end node, that it's
happening?

Off-list replies are fine, even better are folks willing to talk on record.

I appreciate any help you can give.

Ryan Singel
Editor
Wired
Threat Level

Re: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?)

2012-10-23 Thread Christopher Morrow 
On Tue, Oct 23, 2012 at 4:13 PM, Templin, Fred L
 wrote:
> I realize that this is reaching way back, but you may want
> to have a look at the latest version of IRON:
>
> http://www.ietf.org/id/draft-templin-ironbis-12.txt
>
> IRON manages the internal routing systems for large virtual
> service provider networks. It deals with deaggregation and
> churn due to mobility internally, and does not expose the
> deaggregation and churn to the interdomain routing system.
>
> IRON is therefore an intradomain routing overlay network
> system, and can be used in conjunction with any interdomain
> routing system - including BGP and LISP.

someone should have brought this up in the ARMD working group...

RE: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?)

2012-10-23 Thread Templin, Fred L 
I realize that this is reaching way back, but you may want
to have a look at the latest version of IRON:

http://www.ietf.org/id/draft-templin-ironbis-12.txt

IRON manages the internal routing systems for large virtual
service provider networks. It deals with deaggregation and
churn due to mobility internally, and does not expose the
deaggregation and churn to the interdomain routing system.

IRON is therefore an intradomain routing overlay network
system, and can be used in conjunction with any interdomain
routing system - including BGP and LISP.

Thanks - Fred
fred.l.temp...@boeing.com

> -Original Message-
> From: Wes Felter [mailto:w...@felter.org]
> Sent: Tuesday, August 07, 2012 10:51 AM
> To: nanog@nanog.org
> Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?)
> 
> On 8/6/12 8:04 PM, Owen DeLong wrote:
> 
> > The goal here was to make this as simple and cost-effective as the NAT-
> based
> > IPv4 solution currently in common use. There's no reason it can't be
> exactly that.
> >
> > It does provide advantages over the NAT-based solution (sessions can
> survive
> > failover).
> 
> What do people think about Fred Templin's IRON multihomed tunneling
> approach (or LISP, I guess it can do it)? IRON should give you
> multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming
> traffic. It's less reliable than BGP in theory since you'd be virtually
> single-homed to your IRON provider but that might be a worthwhile
> tradeoff since staying up is pretty much their purpose in life.
> 
> You'd have to pay a third provider to terminate your tunnels, but that
> might be cheaper than paying an extra BGP tax to both of your physical
> providers. IRON appears to require much less configuration than BGP and
> it can also provide IPv6 over v4-only providers (good luck finding *two*
> broadband providers in the same location that provide IPv6 and BGP).
> 
> --
> Wes Felter
> IBM Research - Austin
> 
> 
>

RE: Issues encountered with assigning .0 and .255 as usable addresses?

2012-10-23 Thread Darren O'Connor 
I purposely assigned myself a .0 and never had a problem using anything online, 
or going anywhere

> Date: Tue, 23 Oct 2012 22:00:53 +0200
> From: tore.ander...@redpill-linpro.com
> To: j...@instituut.net
> Subject: Re: Issues encountered with assigning .0 and .255 as usable 
> addresses?
> CC: nanog@nanog.org
> 
> * Job Snijders
> 
> > In the post-classfull routing world .0 and .255 should be normal IP
> > addresses. CIDR was only recently defined (somewhere in 1993) so I
> > understand it might take companies some time to adjust to this novel
> > situation. Ok, enough snarkyness!
> > 
> > Quite recently a participant of the NLNOG RING had a problem related
> > to an .255 IP address. You can read more about it here:
> > https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/
> 
> AIUI, that particular problem couldn't be blamed on lack of CIDR support
> either, as 91.218.150.255 is (was) a class A address. It would have had
> to be 91.255.255.255 or 91.0.0.0 for it to be special in the classful
> pre-CIDR world.
> 
> That said, it's rather common for people to believe that a /24 anywhere
> in the IPv4 address space is a «class C» so I'm not really surprised.
> 
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/
>

Re: Issues encountered with assigning .0 and .255 as usable addresses?

2012-10-23 Thread Tore Anderson 
* Job Snijders

> In the post-classfull routing world .0 and .255 should be normal IP
> addresses. CIDR was only recently defined (somewhere in 1993) so I
> understand it might take companies some time to adjust to this novel
> situation. Ok, enough snarkyness!
> 
> Quite recently a participant of the NLNOG RING had a problem related
> to an .255 IP address. You can read more about it here:
> https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/

AIUI, that particular problem couldn't be blamed on lack of CIDR support
either, as 91.218.150.255 is (was) a class A address. It would have had
to be 91.255.255.255 or 91.0.0.0 for it to be special in the classful
pre-CIDR world.

That said, it's rather common for people to believe that a /24 anywhere
in the IPv4 address space is a «class C» so I'm not really surprised.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

RE: MP-BGP next hop tracking delay 0

2012-10-23 Thread Jeff Tantsura 
Hi Adam,

Works just fine on any relatively modern router.

Cheers,
Jeff

-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk] 
Sent: Tuesday, October 23, 2012 12:31 AM
To: nanog@nanog.org
Subject: MP-BGP next hop tracking delay 0

I was wondering whether you have some experience with setting of the next hop 
tracking delay value for BGP to 0 for critical changes please There's gonna be 
only a few prefixes registered with BGP so far, around 150+

adam

Re: Issues encountered with assigning .0 and .255 as usable addresses?

2012-10-23 Thread james machado 
On Mon, Oct 22, 2012 at 6:49 PM, Justin Krejci  wrote:
> And since owen has not yet mentioned it, consider something that supports 
> having : in its address as well.
>
> Sort of tangentially related, I had a support rep for a vendor once tell me 
> that a 255 in the second or third octet was not valid for an ipv4 address. 
> Hard to troubleshoot a problem when I had to first explain how ip addressing 
> worked because the rep was so fixated on the 255 we were using on the 
> network. If any product really doesn't like 255 in any position then you 
> should consider yourself lucky to still be in business at all. Jimmy Hess 
>  wrote:On 10/22/12, Paul Zugnoni 
>  wrote:
> [snip]
>> Any experience or recommendations? Besides replace the ISA proxy…. Since
>> it's not mine to replace. Also curious whether there's an RFC recommending
>> against the use of .0 or .255 addresses for this reason.
>
> ISA is old, and might not be supported anymore, unless you have an
> extended support contract.   If it's not supported anymore, then don't
> be surprised if it has breakage you will not be able to repair. I
> don't recommend upgrading to TMG, either:  although still supported,
> that was just discontinued.
>
> If ISA is refusing traffic to/from IPs ending in .0, then ISA is
> either broken, or misconfigured.
> Get a support case with the vendor, raise it as a critical issue --
> unable to pass traffic to critical infrastructure that ends with a
> .255 or .0  IP address,  demand that the vendor provide a resolution,
> And explain that changing the IP address of the remote server is not an 
> option.
>
>
> If the vendor can't or won't provide a resolution,   then  not only is
> the proxy server broken,
> but malfunctioning in a way   that has an impact on network connectivity.
>
> I would consider its removal compulsory,  as you never know,  when a
> network resource, web site, e-mail server, etc. your org has a
> business  critical need to access,  or be accessed from;  may be
> placed on .255 or  .0
>
> --
> -JH
>

this was also discussed back in August in this thread
http://mailman.nanog.org/pipermail/nanog/2012-August/051290.html

james

Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

2012-10-23 Thread Marc Storck 

>IPv4 addresses ending in .0 and .255 can't be used either because the
>top and bottom addresses of a subnet are unusable.

Only true if speaking of /24, but with the appearance of CIDR 19 years
ago, this is not true anymoreŠ The .255 and .0 in the "center" of a /23
are perfectly usable see an earlier post
http://markmail.org/message/n2ctx6tw6kdcj2mr

Regards,

Marc Storck


smime.p7s
Description: S/MIME cryptographic signature

Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

2012-10-23 Thread Mike Jones 
On 23 October 2012 14:16, Rob Laidlaw  wrote:
> RFC 2526 reserves the last 128 host addresses in each subnet for anycast use.

IPv4 addresses ending in .0 and .255 can't be used either because the
top and bottom addresses of a subnet are unusable.

Why would hetzner be making such assumptions about what is and is not
a valid address on a remote network? if you have a route to it then it
is a valid address that you should be able to exchange packets with,
any assumptions beyond that are almost certainly going to be wrong
somewhere.

Even if they did happen to correctly guess what sized subnets a remote
network is using and what type of access media that remote network is
using, I am pretty sure it would be wrong to assume that these
addresses can't be accessed remotely considering the only address that
is currently defined :)

I really hope this is down to some kind of bug and not something
someone did deliberately.

- Mike

Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

2012-10-23 Thread Andy Smith 
Hi Rob,

On Tue, Oct 23, 2012 at 08:16:48AM -0500, Rob Laidlaw wrote:
> RFC 2526 reserves the last 128 host addresses in each subnet for anycast use.

D'oh, I didn't even think to check for reserved addresses. Thanks.

Cheers,
Andy

-- 
http://bitfolk.com/ -- No-nonsense VPS hosting

RE: IP tunnel MTU

2012-10-23 Thread Templin, Fred L 
Hi Roland,

> -Original Message-
> From: Dobbins, Roland [mailto:rdobb...@arbor.net]
> Sent: Monday, October 22, 2012 6:49 PM
> To: NANOG list
> Subject: Re: IP tunnel MTU
> 
> 
> On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote:
> 
> > Since tunnels always reduce the effective MTU seen by data packets due
> to the encapsulation overhead, the only two ways to accommodate
> > the tunnel MTU is either through the use of path MTU discovery or
> through fragmentation and reassembly.
> 
> Actually, you can set your tunnel MTU manually.
> 
> For example, the typical MTU folks set for a GRE tunnel is 1476.

Yes; I was aware of this. But, what I want to get to is
setting the tunnel MTU to infinity.

> This isn't a new issue; it's been around ever since tunneling technologies
> have been around, and tons have been written on this topic.  Look at your
> various router/switch vendor Web sites, archives of this list and others,
> etc.

Sure. I've written a fair amount about it too over the span
of the last ten years. What is new is that there is now a
solution near at hand.
 
> So, it's been known about, dealt with, and documented for a long time.  In
> terms of doing something about it, the answer there is a) to allow the
> requisite ICMP for PMTU-D to work to/through any networks within your span
> of administrative control and b)

That does you no good if there is some other network further
beyond your span of administrative control that does not allow
the ICMP PTBs through. And, studies have shown this to be the
case in a non-trivial number of instances.

> b) adjusting your own tunnel MTUs to
> appropriate values based upon experimentation.

Adjust it down to what? 1280? Then, if your tunnel with the
adjusted MTU enters another tunnel with its own adjusted MTU
there is an MTU underflow that might not get reported if the
ICMP PTB messages are lost. An alternative is to use IP
fragmentation, but recent studies have shown that more and
more operators are unconditionally dropping IPv6 fragments
and IPv4 fragmentation is not an option due to wrapping IDs
at high data rates.

Nested tunnels-within-tunnels occur in operational scenarios
more and more, and adjusting the MTU for only one tunnel in
the nesting does you no good if there are other tunnels that
adjust their own MTUs.

> Enterprise endpoint networks are notorious for blocking *all* ICMP (as
> well as TCP/53 DNS) at their edges due to 'security' misinformation
> propagated by Confused Information Systems Security Professionals and
> their ilk.  Be sure that your own network policies aren't part of the
> problem affecting your userbase, as well as anyone else with a need to
> communicate with properties on your network via tunnels.

Again, all an operator can control is that which is within their
own administrative domain. That does no good for ICMPs that are
lost beyond their administrative domain.

Thanks - Fred
fred.l.temp...@boeing.com

> ---
> Roland Dobbins  // 
> 
> Luck is the residue of opportunity and design.
> 
>  -- John Milton
>

Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

2012-10-23 Thread Sander Steffann 
Hi,

> RFC 2526 reserves the last 128 host addresses in each subnet for anycast use.

But that would mean that the ...:fffe address also shouldn't work. Considering 
RFC 2526 then filtering those addresses when used as source address makes sense.

- Sander

PS: I'm in contact with a network engineer from Hetzner now to see what is 
really happening

Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

2012-10-23 Thread Rob Laidlaw 
RFC 2526 reserves the last 128 host addresses in each subnet for anycast use.

On Tue, Oct 23, 2012 at 7:15 AM, Andy Smith  wrote:
> Hello,
>
> On Mon, Oct 22, 2012 at 10:07:50PM +, Paul Zugnoni wrote:
>> Curious whether it's commonplace to find systems that
>> automatically regard .0 and .255 IP addresses (ipv4) as src/dst in
>> packets as traffic that should be considered invalid.
>
> On a separate note, one of my customers discovered over the weekend
> that if they bring up an all ones IPv6 address in their /64
> (2001:db8:1:1::::) then they can't exchange traffic
> with stuff hosted at hetzner.de such as archives.postgresql.org or
> 1-media-cdn.foolz.us. Seems filtered somewhere inside Hetzner.
>
> I found the same if I brought up an all ones address in any other
> /64 in the same /48 as well. Using ...:::fffe worked
> fine.
>
> I haven't had time to investigate further or tell them yet, though.
>
> Is that sort of thing common?
>
> Cheers,
> Andy
>
> --
> http://bitfolk.com/ -- No-nonsense VPS hosting
>

Re: hotmail.com live.com admin needed

2012-10-23 Thread Suresh Ramasubramanian 
"authentication required" is a bizzarre error to return.

Does it go away if you actually turn off graylisting for hotmail?

On Tuesday, October 23, 2012, Carlos M. Perez wrote:

> Mike,
>
> I think this is exactly what is going on.  The domains that are having
> issues have greylisting on with the spam filtering service and are
> hosted on a farm of hosting servers.  We have blocked port 25 on the
> main hosting IP of the web server, and moved the built in mail server to
> listen on another IP.  This appears to be working, or at least has been
> for almost 12 hours.
>
> The real question is why is hotmail/live the only system that apparently
> does this; which seems to be in contradiction to RFC, and how everyone
> else does it.  The one thing that MS chooses to be different with...
>
> Thanks,
>
> Carlos M. Perez
> Runcentral, LLC
>
> On 10/23/2012 4:28 AM, Michiel Klaver wrote:
> > Carlos,
> >
> > check the mail logs of your web-server, your domain might have a primary
> > A-record pointing to something different than MX-records. When the MX
> > servers do something like greylisting and bounce with a temp-code (4xx)
> > hotmail servers will try alternative records (like @ IN A) and might
> find a
> > listening mail-daemon at your webserver.
> >
> >
> > At 23-10-2012 00:16, Carlos M. Perez wrote:
> >> Hi,
> >>
> >> We're trying to resolve some delivery issues reported by hotmail users.
> >> Started happening a few weeks ago.  Getting immediate NDRs, and the
> >> server that is supposed to receive the email has no records of
> >> attempts.  The messages also don't match what the receiving server
> >> should be sending.  The server(s) listed in the MX should receive all
> >> email without authentication, since it's a mail filtering service
> (Maxmail)
> >>
> >> =
> >> Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com
> >> Received-From-MTA: dns;SNT133-W53
> >> Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700
> >>
> >> Final-Recipient: rfc822;administra...@.com 
> >> Action: failed
> >> Status: 5.5.0
> >> Diagnostic-Code: smtp;550 authentication required
> >> =
> >>
> >> Kindly contact me off-list.
> >>
> >> Thanks,
> >>
> >
> >
> >
>
>
>
>
>
>
>
>

-- 
--srs (iPad)

Re: hotmail.com live.com admin needed

2012-10-23 Thread Carlos M. Perez 
Suresh,

The affected domains have never been on hotmail, etc.  We've actually
held this domain/hosting for the past 14+ years on this particular
domain.  Yes, there is an RFC violation, and it's apparently due to the
greylisting feature from the spam filtering.

Carlos M. Perez
Runcentral, LLC

On 10/23/2012 4:37 AM, Suresh Ramasubramanian wrote:
> Falling back to A when there is an MX (especially after receiving any
> kind of SMTP response from the MX) is an RFC violation by the way (rfc
> 5321 section 5.1)
>
> Even then - this doesn't appear to be the case.  The bounce below was
> generated entirely within Hotmail.  From SNT133-WS53 (a hotmail
> webserver) to snt-omc3-s27.snt0.hotmail.com
>  - which I believe is part of
> their outbound mail farm.  That's where the bounce was generated.
>
> "Requires authentication" might be because whatever domain is being
> sent to was originally hosted on hotmail, and set to require
> authentication to relay out through hotmail's servers.
>
> --srs
>
> On Tuesday, October 23, 2012, Michiel Klaver wrote:
>
> Carlos,
>
> check the mail logs of your web-server, your domain might have a
> primary
> A-record pointing to something different than MX-records. When the MX
> servers do something like greylisting and bounce with a temp-code
> (4xx)
> hotmail servers will try alternative records (like @ IN A) and
> might find a
> listening mail-daemon at your webserver.
>
>
> At 23-10-2012 00:16, Carlos M. Perez wrote:
> > Hi,
> >
> > We're trying to resolve some delivery issues reported by hotmail
> users.
> > Started happening a few weeks ago.  Getting immediate NDRs, and the
> > server that is supposed to receive the email has no records of
> > attempts.  The messages also don't match what the receiving server
> > should be sending.  The server(s) listed in the MX should
> receive all
> > email without authentication, since it's a mail filtering
> service (Maxmail)
> >
> > =
> > Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com
> 
> > Received-From-MTA: dns;SNT133-W53
> > Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700
> >
> > Final-Recipient: rfc822;administra...@.com 
> > Action: failed
> > Status: 5.5.0
> > Diagnostic-Code: smtp;550 authentication required
> > =
> >
> > Kindly contact me off-list.
> >
> > Thanks,
> >
>
>
>
> --
> --srs (iPad)
>
>

Re: hotmail.com live.com admin needed

2012-10-23 Thread Carlos M. Perez 
Mike,

I think this is exactly what is going on.  The domains that are having
issues have greylisting on with the spam filtering service and are
hosted on a farm of hosting servers.  We have blocked port 25 on the
main hosting IP of the web server, and moved the built in mail server to
listen on another IP.  This appears to be working, or at least has been
for almost 12 hours.

The real question is why is hotmail/live the only system that apparently
does this; which seems to be in contradiction to RFC, and how everyone
else does it.  The one thing that MS chooses to be different with...

Thanks,

Carlos M. Perez
Runcentral, LLC

On 10/23/2012 4:28 AM, Michiel Klaver wrote:
> Carlos,
>
> check the mail logs of your web-server, your domain might have a primary
> A-record pointing to something different than MX-records. When the MX
> servers do something like greylisting and bounce with a temp-code (4xx)
> hotmail servers will try alternative records (like @ IN A) and might find a
> listening mail-daemon at your webserver.
>
>
> At 23-10-2012 00:16, Carlos M. Perez wrote:
>> Hi,
>>
>> We're trying to resolve some delivery issues reported by hotmail users.
>> Started happening a few weeks ago.  Getting immediate NDRs, and the
>> server that is supposed to receive the email has no records of
>> attempts.  The messages also don't match what the receiving server
>> should be sending.  The server(s) listed in the MX should receive all
>> email without authentication, since it's a mail filtering service (Maxmail)
>>
>> =
>> Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com
>> Received-From-MTA: dns;SNT133-W53
>> Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700
>>
>> Final-Recipient: rfc822;administra...@.com
>> Action: failed
>> Status: 5.5.0
>> Diagnostic-Code: smtp;550 authentication required
>> =
>>
>> Kindly contact me off-list.
>>
>> Thanks,
>>
>
>
>

Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

2012-10-23 Thread Andy Smith 
Hello,

On Mon, Oct 22, 2012 at 10:07:50PM +, Paul Zugnoni wrote:
> Curious whether it's commonplace to find systems that
> automatically regard .0 and .255 IP addresses (ipv4) as src/dst in
> packets as traffic that should be considered invalid.

On a separate note, one of my customers discovered over the weekend
that if they bring up an all ones IPv6 address in their /64
(2001:db8:1:1::::) then they can't exchange traffic
with stuff hosted at hetzner.de such as archives.postgresql.org or
1-media-cdn.foolz.us. Seems filtered somewhere inside Hetzner.

I found the same if I brought up an all ones address in any other
/64 in the same /48 as well. Using ...:::fffe worked
fine.

I haven't had time to investigate further or tell them yet, though.

Is that sort of thing common?

Cheers,
Andy

-- 
http://bitfolk.com/ -- No-nonsense VPS hosting

Re: hotmail.com live.com admin needed

2012-10-23 Thread Suresh Ramasubramanian 
Falling back to A when there is an MX (especially after receiving any kind
of SMTP response from the MX) is an RFC violation by the way (rfc 5321
section 5.1)

Even then - this doesn't appear to be the case.  The bounce below was
generated entirely within Hotmail.  From SNT133-WS53 (a hotmail webserver)
to snt-omc3-s27.snt0.hotmail.com - which I believe is part of their
outbound mail farm.  That's where the bounce was generated.

"Requires authentication" might be because whatever domain is being sent to
was originally hosted on hotmail, and set to require authentication to
relay out through hotmail's servers.

--srs

On Tuesday, October 23, 2012, Michiel Klaver wrote:

> Carlos,
>
> check the mail logs of your web-server, your domain might have a primary
> A-record pointing to something different than MX-records. When the MX
> servers do something like greylisting and bounce with a temp-code (4xx)
> hotmail servers will try alternative records (like @ IN A) and might find a
> listening mail-daemon at your webserver.
>
>
> At 23-10-2012 00:16, Carlos M. Perez wrote:
> > Hi,
> >
> > We're trying to resolve some delivery issues reported by hotmail users.
> > Started happening a few weeks ago.  Getting immediate NDRs, and the
> > server that is supposed to receive the email has no records of
> > attempts.  The messages also don't match what the receiving server
> > should be sending.  The server(s) listed in the MX should receive all
> > email without authentication, since it's a mail filtering service
> (Maxmail)
> >
> > =
> > Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com
> > Received-From-MTA: dns;SNT133-W53
> > Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700
> >
> > Final-Recipient: rfc822;administra...@.com 
> > Action: failed
> > Status: 5.5.0
> > Diagnostic-Code: smtp;550 authentication required
> > =
> >
> > Kindly contact me off-list.
> >
> > Thanks,
> >
>
>

-- 
--srs (iPad)

Re: hotmail.com live.com admin needed

2012-10-23 Thread Michiel Klaver 
Carlos,

check the mail logs of your web-server, your domain might have a primary
A-record pointing to something different than MX-records. When the MX
servers do something like greylisting and bounce with a temp-code (4xx)
hotmail servers will try alternative records (like @ IN A) and might find a
listening mail-daemon at your webserver.


At 23-10-2012 00:16, Carlos M. Perez wrote:
> Hi,
> 
> We're trying to resolve some delivery issues reported by hotmail users.  
> Started happening a few weeks ago.  Getting immediate NDRs, and the 
> server that is supposed to receive the email has no records of 
> attempts.  The messages also don't match what the receiving server 
> should be sending.  The server(s) listed in the MX should receive all 
> email without authentication, since it's a mail filtering service (Maxmail)
> 
> =
> Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com
> Received-From-MTA: dns;SNT133-W53
> Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700
> 
> Final-Recipient: rfc822;administra...@.com
> Action: failed
> Status: 5.5.0
> Diagnostic-Code: smtp;550 authentication required
> =
> 
> Kindly contact me off-list.
> 
> Thanks,
>

MP-BGP next hop tracking delay 0

2012-10-23 Thread Adam Vitkovsky 
I was wondering whether you have some experience with setting of the next
hop tracking delay value for BGP to 0 for critical changes please
There's gonna be only a few prefixes registered with BGP so far, around 150+

adam