Re: Question on 7.0.0.0/8

[Jon R. Kibler]

CYMRU has 7/8 listed as a bogon:
http://www.cymru.com/Documents/bogon-dd.html

Their list is more or less authoritative, so I would believe that you should 
never see traffic from that netblock. This is also consistent with Sprint 
blackholeing it as a bogon in your original post.

That said, it doesn't mean that the netblock is unused. Most likely it is a 
netblock that DoD actually uses, but it is only routed on DoD's private 
backbone and never on the Internet.

If you are seeing traffic to/from that netblock, there are two possibilities 
that come to mind:
   1) Spoofed source IPs on UDP and ICMP traffic.
   2) If it is TCP traffic, then probably someone has hijacked the netblock and is 
publishing BGP routes to it. Hijacking unallocated netblocks has been a common 
spamming technique for at least 10 years -- although with today's botnets it does 
not appear to be as commonly used (IMHO). Also, the spammers usually try to hide 
within smaller unallocated netblocks (< /16) of allocated netblocks (a little 
less obvious and less likely to be blackholed).

If you are seeing traffic to/from this netblock, PLEASE do a traceroute back to 
that IP -- in fact do several from different networks -- to make it easier for 
law enforcement to trace back to the hijacker. Also, try using something more 
smarter than standard traceoute, such as:
http://www.paris-traceroute.net/

If you are seeing traffic from hijacked netblocks, contact your local 
InfraGuard group -- I know the FBI will be VERY interested in that information.

Jon Kibler



william(at)elan.net wrote:



Anybody know if 7.0.0.0/8 is or is not allocated to DoD?
The data at IANA and ARIN is kind-of confusing...

---
7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint
   7.0.0.0 - 7.255.255.255 ## Bogon (unallocated) ip range
---
http://www.iana.org/assignments/ipv4-address-space
007/8   Apr 95   IANA - Reserved
---
[IPv4 whois information for 7.0.0.1 ]
[whois.arin.net]

OrgName:DoD Network Information Center
OrgID:  DNIC
Address:3990 E. Broad Street
City:   Columbus
StateProv:  OH
PostalCode: 43218
Country:US

NetRange:   7.0.0.0 - 7.255.255.255
CIDR:   7.0.0.0/8
NetName:DISANET7
NetHandle:  NET-7-0-0-0-1
Parent:
NetType:Direct Allocation
Comment:
RegDate:1997-11-24
Updated:2006-04-28

OrgTechHandle: MIL-HSTMST-ARIN
OrgTechName:   Network DoD
OrgTechPhone:  +1-800-365-3642
OrgTechEmail:  [EMAIL PROTECTED]



--
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
(843) 849-8214

Re: Thoughts on increasing MTUs on the internet

[Joe Greco]

>   As long as only a small minority of hosts supports >1500-byte MTUs,
>   there is no incentive for anyone important to start supporting them.
>   A public server supporting 9000-byte MTUs will be frustrated when it
>   tries to use them.  The overhead (from attempted large packets that
>   don't make it) and potential trouble will just not be worth it.
>   This is a little similar to IPv6.
> 
> So I don't see large MTUs coming to the Internet at large soon.  They
> probably make sense in special cases, maybe for "land-speed records"
> and dumb high-speed video equipment, or for server-to-server stuff
> such as USENET news.

It is *certainly* helpful for USENET news.

So perhaps it is time to chuck the whole thing out and start over.  There
seem to be enough projects out there (cleanslate.stanford.edu, etc) that
are looking at just that topic...  maybe it is time for a new network
design with IPv6, flexible MTU's, etc.

The existing MTU 1500 situation made sense on ten megabit ethernet, of
course, and at the time, the overall design of the Internet, and the
capabilities of the underlying network hardware were such that it 
wasn't that reasonable or practical to consider trying to make it
negotiable.

There is no valid technical reason for that situation with modern
hardware.  The reasons people argue against larger MTU all appear to
have to do with hysterical raisins.

1500 was okay at 10 megabits.  That could imply 15000 for 100 megabits,
and 15 for 1 gigabit.  There probably isn't a huge number of
applications for such large MTU's, and certainly universal support is
not likely to happen, but we have to realize that the speeds of networks
will continue to increase, and in five years we'll probably be running
terabit networks everywhere.  I could picture 150K MTU's being useful
at those speeds.

The goal shouldn't really be to simply allow for some fixed higher MTU.
If any of these "redesign the Internet" programs succeed, we should be
very certain that MTU flexibility is a core feature.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Question on 7.0.0.0/8

[william(at)elan.net]

Anybody know if 7.0.0.0/8 is or is not allocated to DoD?
The data at IANA and ARIN is kind-of confusing...

---
7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint
   7.0.0.0 - 7.255.255.255 ## Bogon (unallocated) ip range
---
http://www.iana.org/assignments/ipv4-address-space
007/8   Apr 95   IANA - Reserved
---
[IPv4 whois information for 7.0.0.1 ]
[whois.arin.net]

OrgName:DoD Network Information Center
OrgID:  DNIC
Address:3990 E. Broad Street
City:   Columbus
StateProv:  OH
PostalCode: 43218
Country:US

NetRange:   7.0.0.0 - 7.255.255.255
CIDR:   7.0.0.0/8
NetName:DISANET7
NetHandle:  NET-7-0-0-0-1
Parent:
NetType:Direct Allocation
Comment:
RegDate:1997-11-24
Updated:2006-04-28

OrgTechHandle: MIL-HSTMST-ARIN
OrgTechName:   Network DoD
OrgTechPhone:  +1-800-365-3642
OrgTechEmail:  [EMAIL PROTECTED]

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Thoughts on increasing MTUs on the internet

[Fred Baker]

I agree with many of your thoughts. This is essentially the same  
discussion we had upgrading from the 576 byte common MTU of the  
ARPANET to the 1500 byte MTU of Ethernet-based networks. Larger MTUs  
are a good thing, but are not a panacea. The biggest value in real  
practice is IMHO that the end systems deal with a lower interrupt  
rate when moving the same amount of data. That said, some who are  
asking about larger MTUs are asking for values so large that CRC  
schemes lose their value in error detection, and they find themselves  
looking at higher layer FEC technologies to make up for the issue.  
Given that there is an equipment cost related to larger MTUs, I  
believe that there is such a thing as an MTU that is impractical.


1500 byte MTUs in fact work. I'm all for 9K MTUs, and would recommend  
them. I don't see the point of 65K MTUs.


On Apr 14, 2007, at 7:39 AM, Simon Leinen wrote:



Ah, large MTUs.  Like many other "academic" backbones, we implemented
large (9192 bytes) MTUs on our backbone and 9000 bytes on some hosts.
See [1] for an illustration.  Here are *my* current thoughts on
increasing the Internet MTU beyond its current value, 1500.  (On the
topic, see also [2] - a wiki page which is actually served on a
9000-byte MTU server :-)

Benefits of >1500-byte MTUs:

Several benefits of moving to larger MTUs, say in the 9000-byte range,
were cited.  I don't find them too convincing anymore.

1. Fewer packets reduce work for routers and hosts.

   Routers:

   Most backbones seem to size their routers to sustain (near-)
   line-rate traffic even with small (64-byte) packets.  That's a good
   thing, because if networks were dimensioned to just work at average
   packet sizes, they would be pretty easy to DoS by sending floods of
   small packets.  So I don't see how raising the MTU helps much
   unless you also raise the minimum packet size - which might be
   interesting, but I haven't heard anybody suggest that.

   This should be true for routers and middleboxes in general,
   although there are certainly many places (especially firewalls)
   where pps limitations ARE an issue.  But again, raising the MTU
   doesn't help if you're worried about the worst case.  And I would
   like to see examples where it would help significantly even in the
   normal case.  In our network it certainly doesn't - we have Mpps to
   spare.

   Hosts:

   For hosts, filling high-speed links at 1500-byte MTU has often been
   difficult at certain times (with Fast Ethernet in the nineties,
   GigE 4-5 years ago, 10GE today), due to the high rate of
   interrupts/context switches and internal bus crossings.
   Fortunately tricks like polling-instead-of-interrupts (Saku Ytti
   mentioned this), Interrupt Coalescence and Large-Send Offload have
   become commonplace these days.  These give most of the end-system
   performance benefits of large packets without requiring any support
   from the network.

2. Fewer bytes (saved header overhead) free up bandwidth.

   TCP segments over Ethernet with 1500 byte MTU is "only" 94.2%
   efficient, while with 9000 byte MTU it would be 99.?% efficient.
   While an improvement would certainly be nice, 94% already seems
   "good enough" to me.  (I'm ignoring the byte savings due to fewer
   ACKs.  On the other hand not all packets will be able to grow
   sixfold - some transfers are small.)

3. TCP runs faster.

   This boils down to two aspects (besides the effects of (1) and  
(2)):


   a) TCP reaches its "cruising speed" faster.

  Especially with LFNs (Long Fat Networks, i.e. paths with a large
  bandwidth*RTT product), it can take quite a long time until TCP
  slow-start has increased the window so that the maximum
  achievable rate is reached.  Since the window increase happens
  in units of MSS (~MTU), TCPs with larger packets reach this
  point proportionally faster.

  This is significant, but there are alternative proposals to
  solve this issue of slow ramp-up, for example HighSpeed TCP [3].

   b) You get a larger share of a congested link.

  I think this is true when a TCP-with-large-packets shares a
  congested link with TCPs-with-small-packets, and the packet loss
  probability isn't proportional to the size of the packet.  In
  fact the large-packet connection can get a MUCH larger share
  (sixfold for 9K vs. 1500) if the loss probability is the same
  for everybody (which it often will be, approximately).  Some
  people consider this a fairness issue, other think it's a good
  incentive for people to upgrade their MTUs.

About the issues:

* Current Path MTU Discovery doesn't work reliably.

  Path MTU Discovery as specified in RFC 1191/1981 relies on ICMP
  messages to discover when a smaller MTU has to be used.  When these
  ICMP messages fail to arrive (or be sent), the sender will happily
  continue to send too-large packets into the blackhole.  This problem
  is very real.  As an 

Re: Thoughts on increasing MTUs on the internet

[Simon Leinen]

Ah, large MTUs.  Like many other "academic" backbones, we implemented
large (9192 bytes) MTUs on our backbone and 9000 bytes on some hosts.
See [1] for an illustration.  Here are *my* current thoughts on
increasing the Internet MTU beyond its current value, 1500.  (On the
topic, see also [2] - a wiki page which is actually served on a
9000-byte MTU server :-)

Benefits of >1500-byte MTUs:

Several benefits of moving to larger MTUs, say in the 9000-byte range,
were cited.  I don't find them too convincing anymore.

1. Fewer packets reduce work for routers and hosts.

   Routers:
 
   Most backbones seem to size their routers to sustain (near-)
   line-rate traffic even with small (64-byte) packets.  That's a good
   thing, because if networks were dimensioned to just work at average
   packet sizes, they would be pretty easy to DoS by sending floods of
   small packets.  So I don't see how raising the MTU helps much
   unless you also raise the minimum packet size - which might be
   interesting, but I haven't heard anybody suggest that.

   This should be true for routers and middleboxes in general,
   although there are certainly many places (especially firewalls)
   where pps limitations ARE an issue.  But again, raising the MTU
   doesn't help if you're worried about the worst case.  And I would
   like to see examples where it would help significantly even in the
   normal case.  In our network it certainly doesn't - we have Mpps to
   spare.
 
   Hosts:
 
   For hosts, filling high-speed links at 1500-byte MTU has often been
   difficult at certain times (with Fast Ethernet in the nineties,
   GigE 4-5 years ago, 10GE today), due to the high rate of
   interrupts/context switches and internal bus crossings.
   Fortunately tricks like polling-instead-of-interrupts (Saku Ytti
   mentioned this), Interrupt Coalescence and Large-Send Offload have
   become commonplace these days.  These give most of the end-system
   performance benefits of large packets without requiring any support
   from the network.

2. Fewer bytes (saved header overhead) free up bandwidth.

   TCP segments over Ethernet with 1500 byte MTU is "only" 94.2%
   efficient, while with 9000 byte MTU it would be 99.?% efficient.
   While an improvement would certainly be nice, 94% already seems
   "good enough" to me.  (I'm ignoring the byte savings due to fewer
   ACKs.  On the other hand not all packets will be able to grow
   sixfold - some transfers are small.)

3. TCP runs faster.

   This boils down to two aspects (besides the effects of (1) and (2)):

   a) TCP reaches its "cruising speed" faster.

  Especially with LFNs (Long Fat Networks, i.e. paths with a large
  bandwidth*RTT product), it can take quite a long time until TCP
  slow-start has increased the window so that the maximum
  achievable rate is reached.  Since the window increase happens
  in units of MSS (~MTU), TCPs with larger packets reach this
  point proportionally faster.

  This is significant, but there are alternative proposals to
  solve this issue of slow ramp-up, for example HighSpeed TCP [3].

   b) You get a larger share of a congested link.

  I think this is true when a TCP-with-large-packets shares a
  congested link with TCPs-with-small-packets, and the packet loss
  probability isn't proportional to the size of the packet.  In
  fact the large-packet connection can get a MUCH larger share
  (sixfold for 9K vs. 1500) if the loss probability is the same
  for everybody (which it often will be, approximately).  Some
  people consider this a fairness issue, other think it's a good
  incentive for people to upgrade their MTUs.

About the issues:

* Current Path MTU Discovery doesn't work reliably.

  Path MTU Discovery as specified in RFC 1191/1981 relies on ICMP
  messages to discover when a smaller MTU has to be used.  When these
  ICMP messages fail to arrive (or be sent), the sender will happily
  continue to send too-large packets into the blackhole.  This problem
  is very real.  As an experiment, try configuring an MTU < 1500 on a
  backbone link which has Ethernet-connected customers behind it.
  I bet that you'll receive LOUD complaints before long.

  Some other people mention that Path MTU Discovery has been refined
  with "blackhole detection" methods in some systems.  This is widely
  implemented, but not configured (although it probably could be with
  a "Service Pack").

  Note that a new Path MTU Discovery proposal was just published as
  RFC 4821 [4].  This is also supposed to solve the problem of relying
  on ICMP messages.

  Please, let's wait for these more robust PMTUD mechanisms to be
  universally deployed before trying to increase the Internet MTU.

* IP assumes a consistent MTU within a logical subnet.

  This seems to be a pretty fundamental assumption, and Iljitsch's
  original mail suggests that we "fix" this.  Umm, ok, I hope we don't
  miss anything important tha

Re: Thoughts on increasing MTUs on the internet

[Stephen Sprunk]

Thus spake "Lasher, Donn" <[EMAIL PROTECTED]>

PMTU Black Hole Detection works well in my experience, but unfortunately
MS doesn't turn it on by default, which is where all of the L2VPN with 
<1500

MTU issues come from; turn BHD on and the problems just go away...  (And,
as others have noted, there's better PMTUD algorithms that are designed to
work _with_ black holes, but IME they're not really needed)


I wish I'd had your experience. PMTU _can_ work well, but on the internet 
as

a whole, far too many ignorant paranoid admins block PMTU, mostly by
accident, causing all sorts of unpleasantness.


You can't block PMTUD per se, just the ICMP messages that dumber 
implementations rely on.  And, as I noted, MS's implementation is dumb by 
default, which leads to the problems we're all familiar with.  "PMTU Black 
Hole Detection" is appropriately named; one registry change* and a reboot is 
all you need to solve the problem.  Of course, that's non-trivial to 
implement when there's hundreds of millions of boxes with the wrong 
setting...



Clearing DF only takes you so far. Unless both ends are aware, and respond
apppropriately to the squeeze in the middle, you're back to square one.


Smarter implementations still set DF.  The difference is that when they get 
neither an ACK nor an ICMP, they try progressively smaller sizes until they 
do get a response of some kind.  They make a note of what works and continue 
on with that, with the occasional larger probe in case the problem was 
transient.


In fact, one could consider Lorier's "mtud" to be roughly the same idea; 
it's only needed because the stack's own PMTUD code is typically bypassed 
for on-subnet destinations and/or not as smart as it should be.


S

* HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\EnablePMTUBHDetect=1

Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov 

Re: Abuse procedures... Reality Checks

[Steve Sobol]

On Fri, 13 Apr 2007, Rich Kulawiec wrote:
 
> Since when is it "punishment" to refuse to extend a privilege that's been
> repeatedly and systematically abused?

It IS punishment if it's in response to some sort of undesired behavior, 
but it probably isn't UNJUSTIFIED punishment.

-- 
Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows
Victorville, California PGP:0xE3AE35ED

It's all fun and games until someone starts a bonfire in the living room.

Re: DHCPv6, was: Re: IPv6 Finally gets off the ground

[David W. Hankins]

On Thu, Apr 12, 2007 at 11:11:54AM +0200, Iljitsch van Beijnum wrote:
> I have a Cisco 2500 with software from 1999 and a Windows XP box with  
> software from 2001, both supporting IPv6, sitting here... I didn't  
> get my first Mac until 2002, but that one supported IPv6 at that  
> point, too.

It would be foolish to suggest that software implementing IPv6 has
not existed for many years.

It would also be foolish to use "support IPv6" as a blanket
statement, when the features have not truly been usable by more
than bearded geeks.

> There is a provisioning problem with IPv6, yes.

Note that the word 'provisioning' is more than just 'addressing'.

A given ISP may or may not directly communicate with end hosts
using any form of DHCP, but the current broadband ISP models which
are de rigeur would not be salient without DHCPv4 on the end hosts,
even if that is only between the set top box and customer.

So it might not be "their job", but it's still an important facet
of the architecture.  One could say that although a DHCP department
doesn't exist within ISP's, there would have been a need for a
staffed department in its absence.


I remember the era when we used to deliver "install" floppies to our
prospective customers.  And I can tell you they weren't a very good
idea.

Web pages full of instructions, flyers with "simple to follow" steps,
none of them really worked very well either.  Even if our iconic
mascots trying to make the instructions friendlier were awfully cute.

What DHCP and PPP did do, was to remove all of that, and make ISP
integration of customer premise something that could "just happen"
without any handholding or bearded geekery.


When you can plug your computer in, and automatically (with no
clicking) get an IPv6 address, have something tell you where your
DNS assist servers, configure web proxies, and solve your dynamic
dns problems (as IPv4 set top boxes do today), then I would allow
you the use of the words 'supports IPv6' rather than 'implements
IPv6'.

On the subject of DNS, I think you are going to find that, since
IPv6 addresses do not pass the 'phone test', IPv6 customers will
have a new emphasis on having their names in DNS.  But these are
forward looking statements, and it's equally possible that people
will be moved instead to use presence networks.

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineer   you'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgp3AhMWtSXvG.pgp
Description: PGP signature

RE: AOL Postmaster?

[chuck goolsbee]

I'm still getting feedback on netblocks we haven't been
associated with in several years and I've tried about
20 times to get them to stop it but cannot.  If you call
they just tell you to email, if you email you get nowhere.

David


Some general, useful NANOG collected wisdom:

"It is so easy to miss pretty trivial solutions to problems deemed
complicated.  The goal of a scientist is to find an interesting problem,
and live off it for a while.  The goal of an engineer is to evade
interesting problems :)"
-- Vadim Antonov

"Protecting everything you've decided is important may be expensive.
It may not be worth the cost. It's best to have made that calculation
before the problem starts, when there's still time to spend money on
protection if you do decide it's worth it."
-- Steve Gibbard

"Curse the dark, or light a match. You decide, it's your dark."
-- Valdis Kletnieks



That is why we've always used a role email account, like 
[EMAIL PROTECTED] for an (non-actual) example, specifically setup 
to receive AOL's SCOMP feed. Much easier to change than a personal 
email. Much easier to /dev/null if the sending party has lost their 
clue.


--chuck

RE: Thoughts on increasing MTUs on the internet

[Lasher, Donn]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Stephen Sprunk
Sent: Friday, April 13, 2007 10:32 AM
To: Mikael Abrahamsson
Cc: North American Noise and Off-topic Gripes
Subject: Re: Thoughts on increasing MTUs on the internet

>PMTU Black Hole Detection works well in my experience, but unfortunately MS
doesn't turn it on by default, which is
> where all of the L2VPN with <1500 MTU issues come from; turn BHD on and
the problems just go away...  (And, as others
>have noted, there's better PMTUD algorithms that are designed to work
_with_ black holes, but IME they're not really
> needed)

I wish I'd had your experience. PMTU _can_ work well, but on the internet as
a whole, far too many ignorant paranoid admins block PMTU, mostly by
accident, causing all sorts of unpleasantness. Clearing DF only takes you so
far. Unless both ends are aware, and respond apppropriately to the squeeze
in the middle, you're back to square one.

Unless there were some other method of MTU Discovery implemented, depending
on something like PMTU discovery may fail just as dramatically on larger
packets as it does on 1500byte now.





smime.p7s
Description: S/MIME cryptographic signature

RE: AOL Postmaster?

[David Hubbard]

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> 
> 
> >Anybody from AOL on this list? Could you please send me an email
> >offlist?  I need some help.
> 
> Have you pursued every avenue of contact listed at:
> ?
> 
> I've found them to be GENERALLY pretty responsive on those channels, 
> as have many others.
> 
> --chuck

I'm still getting feedback on netblocks we haven't been
associated with in several years and I've tried about
20 times to get them to stop it but cannot.  If you call
they just tell you to email, if you email you get nowhere.

David

Re: AOL Postmaster?

[chuck goolsbee]

Anybody from AOL on this list? Could you please send me an email
offlist?  I need some help.


Have you pursued every avenue of contact listed at:
?

I've found them to be GENERALLY pretty responsive on those channels, 
as have many others.


--chuck

Re: Thoughts on increasing MTUs on the internet

[Stephen Sprunk]

Thus spake "Mikael Abrahamsson" <[EMAIL PROTECTED]>

The internet is a very diverse and complicated beast and if end
systems can properly detect PMTU by doing discovery of this, it
might work.  ... Make sure they can properly detect PMTU by
use of nothing more than "is this packet size getting thru" (ie
no ICMP-NEED-TO-FRAG) or alike, then we might see partial
adoption of larger MTU in some parts and if this becomes a
major customer requirement then it might spread.


PMTU Black Hole Detection works well in my experience, but unfortunately MS 
doesn't turn it on by default, which is where all of the L2VPN with <1500 
MTU issues come from; turn BHD on and the problems just go away...  (And, as 
others have noted, there's better PMTUD algorithms that are designed to work 
_with_ black holes, but IME they're not really needed)


Still, we have a (mostly) working solution for wide-area use; what's missing 
is the critical step in getting varying MTUs working on a single subnet. 
All the solutions so far have required setting a higher, but still fixed, 
MTU for every device and that isn't realistic on the edge except in tightly 
controlled environments like HPC or internal datacenters.


Perry Lorier's solution is rather clever; perhaps we don't even need a 
protocol sanctioned by the IEEE or IETF?


S

Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov 

Re: Thoughts on increasing MTUs on the internet

[Adrian Chadd]

On Fri, Apr 13, 2007, Steve Meuse wrote:
> On 4/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> >
> >For that matter, what releases of Windows support setting a 9K
> >MTU?  That's
> >probably the *real* uptake limiter.
> 
> Most, if not all.  I have an XP box that has a GigE with 9k MTU.

Lucky you. The definition of "large frames" varies depending entirely
upon driver. I came up against this when a client nicely asked about
jumbo frames on his shiny new Cisco 3560 switch - and none of his
computers could agree on anything greater than 4k. And, to make things
worse - a few of the drivers wanted to enforce certain values rather
than any value between 1500 and an upper limit - making the whole
feat impossible.

Yay for non-clear specifications. The skeptic in me says "ain't going
to happen." The believer in me says "Ah, that'd be cool, wouldn't it?"
The realist in me says "probably best to mandate that kind of stuff
with the next revision of the ipv6-internet with the first few bits
set to 010 instead of 001. :)

The real uptake limiter is the disagreement on implementation.
Some of you have to remember how this whole internet thing started
and grew (I've only read about the collaboration in books.)



Adrian

Re: Thoughts on increasing MTUs on the internet

[Steve Meuse]

On 4/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:



For that matter, what releases of Windows support setting a 9K
MTU?  That's
probably the *real* uptake limiter.




Most, if not all.  I have an XP box that has a GigE with 9k MTU.


--

-Steve

RE: Thoughts on increasing MTUs on the internet

[Mikael Abrahamsson]

On Fri, 13 Apr 2007, Leigh Porter wrote:

What would be good is if when a jumbogram capable path on the Internet 
exists, jumbograms can be used.


Yes, and it would be good if PMTUD worked, and ECN, oh and large 
UDP-packets for DNS, and BCP38, and... and... and.


The internet is a very diverse and complicated beast and if end systems 
can properly detect PMTU by doing discovery of this, it might work. 
Requiring the core and distribution to change isn't going to happen 
overnight, so end systems first. Make sure they can properly detect PMTU 
by use of nothing more than "is this packet size getting thru" (ie no 
ICMP-NEED-TO-FRAG) or alike, then we might see partial adoption of larger 
MTU in some parts and if this becomes a major customer requirement then it 
might spread.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: Thoughts on increasing MTUs on the internet

[Leigh Porter]

I don't think it matters that everything can use jumbograms or that every 
single device on the Internet supports them. Heck, I still know networks with 
kit that does not support VLSM!

What would be good is if when a jumbogram capable path on the Internet exists, 
jumbograms can be used.

This way it does not matter than some box somewhere does not support anything 
greater than a 1500 byte MTU, anything with such a box in the path will simply 
not support a jumbogram. How do you find out? Just send a jumbogram across the 
path and see what happens.. ;-)

--
Leigh Porter
UK Broadband


-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Fri 4/13/2007 3:36 PM
To: Saku Ytti
Cc: NANOG list
Subject: Re: Thoughts on increasing MTUs on the internet
 
On Fri, 13 Apr 2007 08:22:49 +0300, Saku Ytti said:
> 
> On (2007-04-12 20:00 -0700), Stephen Satchell wrote:
>  
> > From a practical side, the cost of developing, qualifying, and selling 
> > new chipsets to handle jumbo packets would jack up the cost of inside 
> > equipment.  What is the payback?  How much money do you save going to 
> > jumbo packets?
> 
> It's rather hard to find ethernet gear operators could imagine using in
> peering or core that do not support +9k MTU's.

Note that the number of routers in the "core" is probably vastly outweighted
by the number of border and edge routers.  There's a *lot* of old eBay routers
out there - and until you get a clean path all the way back to the source
system, you won't *see* any 9K packets.

What's the business case for upgrading an older edge router to support 9K
MTU, when the only source of packets coming in is a network of Windows
boxes (both servers and end systems in offices) run by somebody who wouldn't
believe an Ethernet has anything other than a 1500 MTU if you stapled the
spec sheet to their forehead?

For that matter, what releases of Windows support setting a 9K MTU?  That's
probably the *real* uptake limiter.

Re: Thoughts on increasing MTUs on the internet

[Valdis . Kletnieks]

On Fri, 13 Apr 2007 08:22:49 +0300, Saku Ytti said:
> 
> On (2007-04-12 20:00 -0700), Stephen Satchell wrote:
>  
> > From a practical side, the cost of developing, qualifying, and selling 
> > new chipsets to handle jumbo packets would jack up the cost of inside 
> > equipment.  What is the payback?  How much money do you save going to 
> > jumbo packets?
> 
> It's rather hard to find ethernet gear operators could imagine using in
> peering or core that do not support +9k MTU's.

Note that the number of routers in the "core" is probably vastly outweighted
by the number of border and edge routers.  There's a *lot* of old eBay routers
out there - and until you get a clean path all the way back to the source
system, you won't *see* any 9K packets.

What's the business case for upgrading an older edge router to support 9K
MTU, when the only source of packets coming in is a network of Windows
boxes (both servers and end systems in offices) run by somebody who wouldn't
believe an Ethernet has anything other than a 1500 MTU if you stapled the
spec sheet to their forehead?

For that matter, what releases of Windows support setting a 9K MTU?  That's
probably the *real* uptake limiter.


pgpvV1Mibb6JM.pgp
Description: PGP signature

Anyone around from Sprint's e-mail administration?

[Drew Weaver]

   Please contact me off-list.

 

Thanks,

Drew

The Cidr Report

[cidr-report]

This report has been generated at Fri Apr 13 21:50:00 2007 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/as4637 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
06-04-07214183  138447
07-04-07214323  138473
08-04-07214396  138547
09-04-07214610  138763
10-04-07214432  138786
11-04-07214552  138836
12-04-07214559  138907
13-04-07214609  138920


AS Summary
 24809  Number of ASes in routing system
 10482  Number of ASes announcing only one prefix
  1485  Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - AT&T WorldNet Services
  90404864  Largest address span announced by an AS (/32s)
AS721  : DISA-ASNBLK - DoD Network Information Center


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 13Apr07 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 214763   1388917587235.3%   All ASes

AS4134  1244  307  93775.3%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS4323  1266  358  90871.7%   TWTC - Time Warner Telecom,
   Inc.
AS4755  1095  194  90182.3%   VSNL-AS Videsh Sanchar Nigam
   Ltd. Autonomous System
AS9498   967   91  87690.6%   BBIL-AP BHARTI BT INTERNET
   LTD.
AS6478  1091  279  81274.4%   ATT-INTERNET3 - AT&T WorldNet
   Services
AS18566  999  199  80080.1%   COVAD - Covad Communications
   Co.
AS11492 1027  377  65063.3%   CABLEONE - CABLE ONE
AS22773  697   52  64592.5%   CCINET-2 - Cox Communications
   Inc.
AS8151  1040  426  61459.0%   Uninet S.A. de C.V.
AS17488  663   84  57987.3%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS19262  707  170  53776.0%   VZGNI-TRANSIT - Verizon
   Internet Services Inc.
AS6197  1034  509  52550.8%   BATI-ATL - BellSouth Network
   Solutions, Inc
AS7018  1485  974  51134.4%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS18101  530   31  49994.2%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS19916  568  101  46782.2%   ASTRUM-0001 - OLM LLC
AS17676  503   65  43887.1%   JPNIC-JP-ASN-BLOCK Japan
   Network Information Center
AS4766   740  317  42357.2%   KIXS-AS-KR Korea Telecom
AS4812   451   74  37783.6%   CHINANET-SH-AP China Telecom
   (Group)
AS2386  1090  735  35532.6%   INS-AS - AT&T Data
   Communications Services
AS721618  277  34155.2%   DISA-ASNBLK - DoD Network
   Information Center
AS5668   581  247  33457.5%   AS-5668 - CenturyTel Internet
   Holdings, Inc.
AS7029   569  235  33458.7%   WINDSTREAM - Windstream
   Communications Inc
AS15270  521  188  33363.9%   AS-PAETEC-NET - PaeTec.net -a
   division of
   PaeTecCommunications, Inc.
AS16852  398   74  32481.4%   BROADWING-FOCAL - Broadwing
   Communications Services, Inc.
AS7011   781  464  31740.6%   FRONTIER-AND-CITIZENS -
   Frontier Communications, Inc.
AS4668   3128  30497.4%   LGNET-AS-KR LG CNS
AS33588  437  136  30168.9%   BRESNAN-AS - Bresnan
   Communications, LLC.
AS14654  3035  29898.3%   WAYPORT - Wayport
AS6198   567  270  29752.4%   BATI-MIA - BellSouth Network
 

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 30-Mar-07 -to- 12-Apr-07 (14 days)
Observation Point: BGP Peering with AS4637

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS912133665  3.0%  33.2 -- TTNET TTnet Autonomous System
 2 - AS17974   27902  2.5% 102.6 -- TELKOMNET-AS2-AP PT 
TELEKOMUNIKASI INDONESIA
 3 - AS982918425  1.6%  85.7 -- BSNL-NIB National Internet 
Backbone
 4 - AS306 14447  1.3%  79.4 -- DNIC - DoD Network Information 
Center
 5 - AS24731   13737  1.2% 305.3 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
 6 - AS578610301  0.9%  65.2 -- UPRENET - University of Puerto 
Rico
 7 - AS4775 9535  0.8%  80.8 -- GLOBE-TELECOM-AS Telecom 
Carrier  /  ISP Plus +
 8 - AS8447 9171  0.8% 129.2 -- TELEKOM-AT Telekom Austria 
AutonomousSystem
 9 - AS9583 8859  0.8%   9.7 -- SIFY-AS-IN Sify Limited
10 - AS5803 7429  0.7%  78.2 -- DDN-ASNBLK - DoD Network 
Information Center
11 - AS702  7327  0.7%  27.9 -- AS702 Verizon Business EMEA - 
Commercial IP service provider in Europe
12 - AS4249 6907  0.6%  51.5 -- LILLY-AS - Eli Lilly and Company
13 - AS222916906  0.6%  14.2 -- CHARTER-LA - Charter 
Communications
14 - AS176456609  0.6% 600.8 -- NTT-SG-AP ASN - NTT SINGAPORE 
PTE LTD
15 - AS175576096  0.6%  16.3 -- PKTELECOM-AS-AP Pakistan Telecom
16 - AS252336069  0.5%  83.1 -- AWALNET-ASN Autonomus System 
number for Awalnet
17 - AS126546068  0.5% 148.0 -- RIPE-NCC-RIS-AS RIPE NCC RIS 
project
18 - AS308905852  0.5%  28.3 -- EVOLVA Evolva Telecom
19 - AS191085720  0.5%  15.3 -- SUDDENLINK-COMMUNICATIONS - 
Suddenlink Communications
20 - AS364875682  0.5% 811.7 -- NEB-SANDHILLS-NET - 
Consolidated Telephone Company


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS315944114  0.4%4114.0 -- FORTESS-AS Fortess LLC Network
 2 - AS3043 1373  0.1%1373.0 -- AMPHIB-AS - Amphibian Media 
Corporation
 3 - AS380775344  0.5%1336.0 -- TIMOR-TELECOM-AS-AP Timor 
Telecom, SA
 4 - AS297002698  0.2% 899.3 -- CYPRESS-SEMICONDUCTOR - Cypress 
Semiconductor
 5 - AS34378 850  0.1% 850.0 -- RUG-AS Razguliay-UKRROS Group
 6 - AS5609 1644  0.1% 822.0 -- ASN-CSELT  # AS-CSELT CONVERTED 
TO ASN-CSELT FOR RPSL COMPLIANCE CSELT S.p.A. is a Research Center for the 
study, research,
 7 - AS9747 1642  0.1% 821.0 -- EZINTERNET-AS-AP EZInternet Pty 
Ltd
 8 - AS364875682  0.5% 811.7 -- NEB-SANDHILLS-NET - 
Consolidated Telephone Company
 9 - AS1708 1599  0.1% 799.5 -- FR-CNET-ISSY - Centre National 
d'Etudes des Telecommunication -- CNET
10 - AS307071598  0.1% 799.0 -- 
11 - AS118283326  0.3% 665.2 -- SOINET - State of Illinois/CMS
12 - AS12408 625  0.1% 625.0 -- BIKENT-AS Bikent Ltd. 
Autonomous system
13 - AS32761 616  0.1% 616.0 -- WASSE-NYC - Wasserstein & Co.
14 - AS176456609  0.6% 600.8 -- NTT-SG-AP ASN - NTT SINGAPORE 
PTE LTD
15 - AS3944  558  0.1% 558.0 -- PARTAN-LAB - Partan & Partan
16 - AS19760 532  0.1% 532.0 -- CALPINECORP-1 - CALPINE CORP
17 - AS41555 528  0.1% 528.0 -- NOVATKL-AS FW Austria, Kundl
18 - AS143463076  0.3% 512.7 -- S.A O Estado de Sao Paulo
19 - AS331881012  0.1% 506.0 -- SCS-NETWORK-1 - Sono Corporate 
Suites
20 - AS17555 498  0.0% 498.0 -- SPRINGFIELD-AS-AP Springfield 
NOC


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 81.213.47.0/24 7290  0.5%   AS9121  -- TTNET TTnet Autonomous System
 2 - 81.212.197.0/246726  0.5%   AS9121  -- TTNET TTnet Autonomous System
 3 - 194.242.124.0/22   4114  0.3%   AS31594 -- FORTESS-AS Fortess LLC Network
 4 - 59.94.240.0/20 4042  0.3%   AS9829  -- BSNL-NIB National Internet 
Backbone
 5 - 59.94.192.0/20 4042  0.3%   AS9829  -- BSNL-NIB National Internet 
Backbone
 6 - 59.95.240.0/20 4042  0.3%   AS9829  -- BSNL-NIB National Internet 
Backbone
 7 - 59.94.160.0/20 4042  0.3%   AS9829  -- BSNL-NIB National Internet 
Backbone
 8 - 81.212.39.0/24 3728  0.3%   AS9121  -- TTNET TTnet Autonomous System
 9 - 89.4.131.0/24  3417  0.2%   AS24731 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
10 - 89.4.129.0/24  3378  0.2%   AS24731 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
11 - 89.4.128.0/24  3357  0.2%   AS24731 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
12 - 

Re: Abuse procedures... Reality Checks

[Rich Kulawiec]

On Sat, Apr 07, 2007 at 05:12:19PM -0500, Frank Bulk wrote:
> If they're properly SWIPed why punish the ISP for networks they don't even

"punish"?

Since when is it "punishment" to refuse to extend a privilege that's been
repeatedly and systematically abused?  (You have of course, absolutely
no right whatsoever to expect any services of any kind from anyone other
than those you've contracted for.  Everything beyond that is a privilege,
generously furnished to you at the whim of those operating the service.
It may be restricted or withdrawn at any time, for any reason, with or
without notice to you.   Now as a general rule, we all have chosen to
furnish those services -- by default and without limitation.  But that
doesn't turn them into entitlements.)

The word "punish" is completely inapplicable in this context.

> operate, that obviously belong to their business customers? 

Questions:

1. Is your name on it in any way, shape or form?
   (This includes allocations.)
2. Is it emitting abuse?

If the answers are "yes", then it's YOUR abuse.  Trying to evade
responsibility by claiming that "it's one of our customers" is
just another pathetic excuse for incompetence.
 
> Of course, it doesn't hurt to copy the ISP or AS owner for abuse issues from
> a sub-allocated block -- you would hope that ISPs and AS owners would want
> to have clean customers.  

Unless of course the ISP or AS owner *are* the abuser under another
name, or unless they're actively complicit.  Both are quite common.

Beyond that: any *competent* ISP or AS owner will already know about
the abuse.  They will have deployed measures designed to detect said
abuse well before anyone else out there reports it to them.  (Example:
setting up their own spamtraps explicitly designed to catch their own
customers.)  By the time an external observer reports a problem to them, it
should already be old news and already be well on its way to remediation.

---Rsk

Re: Abuse procedures... Reality Checks

[J. Oquendo]

Last post for me on this thread... Dirty Networking 101

So the other morning I found a contact for a company who'll for
now remain unamed, this contact is on this group...Sent them
yet another message (3 this week):


To whom it may concern,

One of my servers has been heavily under attack for the past 24
hours from your IP space. There were 10726 attempts to log into
my VoIP server within the last 24 hours. Please sanitize this
machine from your network. Attached is the logfile.


10726 attacks in a variety of forms. Why should I NOT ban this
network and its clients from reaching my networks. Can someone
please help me understand the logic of being called something
akin to a crybaby, spoiled sport, unfair admin since I am now
going to block their /17?

On to semi-relevant news...

For those who care: Support Intelligence analyzed 22,000 ASNs
for every kind of eCrime including DDoS, Scanning, hosting
Malware, sending Spam, hosting a phish, or transmitting viruses
... 17 of the 100 networks listed are from ARIN. Six of the
seventeen are from Time Warner. 5 are from Comcast, 2 are from
Charter.

http://blog.support-intelligence.com/2007/04/doa-week-14-2007.html

That's their record. I now have 52 hosts dumping out syslog
records and can name about 30+ networks of which some of
the engineers from them are on this list. So what is their
left to do when points of contact fail miserably.

Maybe I will take a crack at writing a document based on the
amount of waste whether its bandwidth, time or money in blocking
venomous hosts from my subnets. Costs, benefits, experience,
pros, cons.

--

J. Oquendo
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743
sil . infiltrated @ net http://www.infiltrated.net

The happiness of society is the end of government.
John Adams


smime.p7s
Description: S/MIME Cryptographic Signature

RE: Thoughts on increasing MTUs on the internet

[michael.dillon]

> No, I doubt it will change.  The CRC algorithm used in Ethernet is 
> already strained by the 1500-byte-plus payload size.  802.3 
> won't extend 
>   to any larger size without running a significant risk of the CRC 
> algorithm failing.

I believe this has already been debunked.
 
>  From a practical side, the cost of developing, qualifying, 
> and selling 
> new chipsets to handle jumbo packets would jack up the cost of inside 
> equipment.  What is the payback?  How much money do you save going to 
> jumbo packets?

I believe that the change is intended to apply to routers and the
ethernet switches that interconnect them in PoPs and NAPs and exchange
points. Therefore the cost of a small chipset modification is likely to
be negligible in the grand scheme of things.

As for numbers, it is not dollar figures that I want to see. I would
like the people who have jumbo packets inside their end-user networks to
run some MTU discovery and publish a full MTU matrix on all paths on the
Internet. That way we can all see where there is end-to-end support for
large MTUs and people who want to make buying decisions on this basis
will have something other than vendor assurances to show that a network
supports jumbograms. 

--Michael Dillon

RE: Thoughts on increasing MTUs on the internet

[Neil J. McRae]

Saku Ytti wrote:

> IXP peeps, why are you not offering high MTU VLAN option?
> From my point of view, this is biggest reason why we today
> generally don't have higher end-to-end MTU.
> I know that some IXPs do, eg. NetNOD but generally it's
> not offered even though many users would opt to use it.

Larger MTU size was something I did some work on back in the FDDI days and the 
benefits are significant. More than just CPU improvements. Throughput and 
server performance increased substantially also. But  FDDI and the like didn't 
come cheap so little interest at the time. At the LINX a few providers did run 
larger MTUs during those FDDI days. We did some testing with SRP/DPT in 
Stockholm and London also and again it worked well but again not cheap. (we 
were looking at this for storage and exchange of cached content at the time)

Unfortunately I think the time where IXPs could make a difference might be past 
- and to make this happen tere needs to be more of a demand  from the members 
of tose exchanges, its not just a case of turning on a vlan either the impact 
to the main fabric needs to be understood. Also atleast here in Europe many of 
the circuits into exchanges are Ethernet based also and I suspect many circuits 
into exchanges would require a lot of work to support Jumbos.  And then again 
lots of circuits into customer premise are Ethernet based now also some on GFP 
based SDH systems, some ATM and other whacko technologies with dubious support 
for jumbo or larger frames.

Then there is the actual interface card support of large amounts of jumbos 
which in my experience is questionable  based on a limitedl amount of testing 
though - Come back POS all is forgiven!

Regards,
Neil