Re: Blackholing traffic by ASN

2008-02-01 Thread JAKO Andras

 wee! and for some extra fun, just append the bad-guy's ASN to your
 route announcements, force bgp loop-detection to kill the traffic on
 their end (presuming they don't default-route as well)

Even more fun if you are not the only one filtering that ASN. :)

Andras


Re: /48 for each and every endsite (Was: European ISP enables IPv6 for all?)

2007-12-19 Thread JAKO Andras

 But even in 2000 the policy was and still is:
  /128 for really a single device
  /64  if you know for sure that only one single subnet will
   ever be allocated.
  /48  for every other case (smart bet, should be used per default)

I believe this policy is changing. The new text is: End Users are 
assigned an End Site assignment from their LIR or ISP. The size of the 
assignment is a local decision for the LIR or ISP to make, using a minimum 
value of a /64 (only one subnet is anticipated for the End Site).

RIPE Policy Proposal 2005-08 was accepted in November.
http://www.ripe.net/ripe/policies/proposals/2005-08.html

Andras


Re: European ISP enables IPv6 for all?

2007-12-18 Thread JAKO Andras

 doesn't more address space just give us more routes to handle?

No. It only makes more possible prefixes. Migrating to IPv6 while keeping 
the current (IPv4) routing and current business relations, there would be 
somewhat less routes:

bigger address space - bigger chunks - less need to incrementally add 
prefixes to the same place - less prefixes

Andras


Re: European ISP enables IPv6 for all?

2007-12-18 Thread JAKO Andras

   doesn't more address space just give us more routes to handle?
  
  No. It only makes more possible prefixes. Migrating to IPv6 while keeping 
  the current (IPv4) routing and current business relations, there would be 
  somewhat less routes:
  
  bigger address space - bigger chunks - less need to incrementally add 
  prefixes to the same place - less prefixes
 
 You mean more address space - individual businesses want to multihome
 and are willing to pay for their own space - more prefixes.

These are different business relations.

I know for sure that IPv6 allows us to keep the number of prefixes lower, 
assuming the current business relations. IPv6 may of course modify the 
business relations as you described, but I'm not smart enough to know for 
sure in advance whether that will happen or not.

Andras


Re: NeXT Default Network

2007-11-27 Thread JAKO Andras

 Fred, Brandon, Spiro,

Thanks for all your answers.

 operating system called NextStep. It sounds like they came up with a variety
 of site-local address pre-RFC1918 and pre-RFC3927 that did something similar
 to RFC 3927 addresses.

That's it. 192.42.172.0/24 is often used in examples, but I also found in 
the Automatic Host Addition chapter of 
http://www.levenez.com/NeXTSTEP/netinfo_user_guide.pdf the following:

The second property, configuration_ipaddr, is required and specifies the 
address that must not be allocated by nibootpd. This address is in fact 
the address that NeXT uses to identify a new workstation temporarily 
during the boot process. It should always be set to 192.42.172.253 
explicitly.

It looks like this /24 is (was) a must for their Automatic Host Addition 
process. So now I see how this prefix got into Barry's list.

Andras


RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

2007-10-03 Thread JAKO Andras

 break.  It seems like an IPv6-only ISP would need to operate the NAT-PT
 boxes, and dedicate a block of v4 addresses the size of the expected
 concurrent online users to the NAT-PT box.  Keep in mind that a v6 ISP
 with 1 million customers won't need a million v4 addresses, for obvious
 reasons.  It's going to be considerably less than if each customer got a
 v4 address.  NAT-PT does seem like a viable short term solution.  I'm

An IPv6-only ISP with enough IPv4 addresses for its concurrent online 
users seems strange. Why wouldn't that ISP give those v4 addresses to the 
online users instead of the NAT-PT box? And why do you call it IPv6-only?

Andras


Re: ICANN registrar supporting v6 glue?

2007-06-29 Thread JAKO Andras

 ;.  IN  NS
 A.ROOT-SERVERS.NET. 360 IN  A   198.41.0.4
 B.ROOT-SERVERS.NET. 360 IN  A   192.228.79.201
 C.ROOT-SERVERS.NET. 360 IN  A   192.33.4.12
 D.ROOT-SERVERS.NET. 360 IN  A   128.8.10.90
 E.ROOT-SERVERS.NET. 360 IN  A   192.203.230.10
 F.ROOT-SERVERS.NET. 360 IN  A   192.5.5.241
 G.ROOT-SERVERS.NET. 360 IN  A   192.112.36.4
 H.ROOT-SERVERS.NET. 360 IN  A   128.63.2.53
 I.ROOT-SERVERS.NET. 360 IN  A   192.36.148.17
 J.ROOT-SERVERS.NET. 360 IN  A   192.58.128.30
 K.ROOT-SERVERS.NET. 360 IN  A   193.0.14.129
 L.ROOT-SERVERS.NET. 360 IN  A   198.32.64.12
 M.ROOT-SERVERS.NET. 360 IN  A   202.12.27.33
 
 
 I don't see any v6 glue there...  Rather than having conversations about
 transition to IPv6, maybe we should be sure it works natively first?  It's
 rather ironic to think that for v6 DNS to work an incumbent legacy protocol is
 still required.

At least something is happening:

http://www.icann.org/committees/security/sac016.htm
http://www.icann.org/committees/security/sac017.htm

Regards,
Andras


Re: TCP and WAN issue

2007-03-27 Thread JAKO Andras

 Philip,

 I have an east coast and west coast data center connected with a DS3. I 
 am running into issues with streaming data via TCP and was wondering 
 besides hardware acceleration, is there any options at increasing 
 throughput and maximizing the bandwidth? How can I overcome the TCP 
 stack limitations inherent in Windows (registry tweaks seem to not 
 functions too well)?

I don't know the RTT, but you should have at least 300 kByte buffers on 
the end hosts for a 60 ms RTT path to reach 40 Mbps TCP throughput. (This 
requires window scaling as well.) Is this what you were trying to tune on 
your Windows hosts?

Is your DS3 free of errors? Even a very low packet loss can degrade TCP 
performance badly.

You'll find a lot of useful information about TCP performance in the 
GEANT2 PERT Knowledge Base at http://www.kb.pert.geant2.net/

Andras


Re: IPv6 subnet calculators?

2003-02-12 Thread JAKO Andras

 Jeff,

 I am trying to find an IPv6 subnet calculator or even a cheat sheet that
 will help show how a /32 allocation is broken down into /40, /48 and /64

I guess that you don't even need a cheat sheet for that. All the prefix
lengths you mention are multiples of four, which means they're on nibble
boundaries. Since IPv6 addresses are usually written in hex, this is just
as simple as to break a dotted decimal IPv4 /8 to /16s or /24s.

Maybe the only common mistake you should be careful about: You must always
write down the digits to the next colon (16 bit boundary). So if you break
down 2005:2001::/32 into /40s, then the second /40 is 2005:2001:0100::/40.
(NOT 2005:2001:01::/40, because that would mean 2005:2001:0001::/40, which
is the 2005:2001::/40 prefix.)

Andras



Re: Cisco 4000 series switches

2002-07-16 Thread JAKO Andras


 Hello,

 I've pretty much always assumed that what a switch
 reported as a status regarding the link of a node was the
 actual status of the line to be the case. However, when I

I think that there is no such thing as the actual status of the line.
Each end of the cable has a status, either full or half. That is, they
don't use or do use CSMA/CD.

 Is this a common situation or just a mis-understanding of the column
 that makes up Duplex for the Cisco IOS? Or is it that The Cisco Switch
 truly is trying to do full duplex but the end node is only doing half.

It's quite common, that one end or the cable works in full duplex mode,
while the other works in half duplex. There can be various reasons for
this. Improper configuration (setting on end to auto-negotiate while
setting the other to fix full-10 for example), software/firmware bugs,
etc.

 If so would/should I see line errors at some point under heavy

You should see late collisions on the half duplex end, since the full
duplex end will transmit frames whenever it has them, and this happens too
between the transmission of the 64th octet and the CRC of frames sent out
on the half duplex end, which is a violation of CSMA/CD (late collision).

On the full duplex end, you'll find CRC errors, runts, alignment errors,
because the half duplex end stops transmitting frames in the middle, when
it senses late collisions.

Andras




Re: /31 mask address

2002-05-06 Thread JAKO Andras


  Has anyone used /31 mask addresses on their network?

 Yes, works fine (on an all Cisco network).

Maybe not interesting for an ISP, but I'm using it on a vlan interface on
a 6500/7600. It works fine with IOS 12.1.8-EX5, but 12.1.11-E1 refused the
configuration because it's not a p2p interface. I know, documentation only
talks about p2p, but sometimes I don't like when a feature gets fixed...

Andras




EDFA

2002-04-26 Thread JAKO Andras


 Hello,

A bit off-topic and maybe stupid question:

I was told yesterday, that a Hungarian telco/ISP is experimenting with
EDFAs. My friend said that the box looks like if they just brought it from
a research lab (however it's a commercial product). How common is it
nowadays to use EDFAs in ISP backbones?

Please reply me off-list. Thanks.

Andras