Re: AS path weirdness

[Andy Davidson]

On 21 Mar 2009, at 02:48, Jason Lewis wrote:

I'm not entirely sure what I'm looking at. The reserved AS, 65490  
appears in parentheses and I've never seen that in MRT formatted  
data and not sure why it's happening.


This has been observed when a vendor runs 32-bit AS aware code on part  
of their edge, and non-32-bit AS aware code on a different part of  
their edge.


I'm also not clear on why I see 23456 *and* a 32 bit AS in the  
path.  Is anyone else seeing this or is it something wacky at RRC04?

91.207.218.0/23|29222 6830 (65490) 3356 35320 3.21 23456


There's some history with this prefix.

http://www.andyd.net/media/talks/asn4_breaks_network.pdf [from nanog45]

Andy

Re: Redundant AS's

[Robert E. Seastrom]

Lyndon Nerenberg lyn...@orthanc.ca writes:

   Autonomous systems will be  assigned  16-bit  identification
   numbers  (in  much  the same ways as network and protocol numbers
   are now assigned), and every EGP message header contains one word
   for  this  number.

 Was that a 36-bit word?

16-bit word in the sense of a PDP-11 or DG Nova, not 36-bit word
in the sense of a Univac-1100 or DECSYSTEM-20.  Be glad that it wasn't
a 12-bit word in the sense of a PDP-8.

(page 33, same RFC)

-r

Re: Akamai wierdness

[Paul Wall]

Patrick Gilmore wrote [context inserted]:
 Perhaps using the RFC required address [...@akamai] would be more
productive than e-mailing 10k strangers?

Normally I see emails like this and, if it's Not In My Back Yard, and the
Internet is not going nutz, the delete key explains how worried i am.

Back to your email:

 using the RFC required address

The correct catty response to the Akamai question is : cc...@akamai.com.
 That's C as in Customer, Care as in they actually care.

I would end the email there, but it really gets me how someone that is
in-house doesn't realize that n...@akamai is a black hole.
Drive Slow,

-paul

Re: REVERSE DNS Practices.

[Steven Champeon]

on Sat, Mar 21, 2009 at 12:44:15PM -0500, Frank Bulk wrote:
 The recommendations in this draft proposal have worked for me:
 http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt

Also:

http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06

http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07

In any case, it depends on whether those IPs will house legitimate
sources of mail; I *strongly* recommend indicating whether an IP is
dynamically or statically assigned, and (ideally) what sort of tech is
in use (dialup? DSL? cable? wifi? etc) so that mail admins can make
decisions about whether or not to allow mail from those hosts. (Hrm, do
I want mail from a dynamic wifi IP? not so much; static generic dsl?
okay, maybe for now).

If you want to be friendly to folks who don't necessarily want to
have to use regexes to match your dynamics, make sure that if you
do use some sort of topology- or geography-based naming, that you
put the dynamic or static token as far to the right as possible,
so that you end up with

 rdu-1-2-3-4.cable.dynamic.example.net

instead of 

 dyn-1-2-3-4.cable.rdu.example.net

because it's a lot easier for mail admins to block 'dynamic.example.net'
than to have to have local access.db entries for every last geography
you're serving, or have to use regexes. And please don't mix dynamics
and statics under the same naming conventions. 

Finally, if you *do* intend for these IPs to house legit mail servers
(or mail sources, for that matter), whether yours or your clients', for
the love of all that is good and holy, give them /custom/ PTRs that 
indicate the actual domain of the responsible party, rather than just
giving them generic names in your domain, unless you really want to
act as an abuse report gateway for your clients. 

HTH,
Steve

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/
antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/