I'm still trying to figure out how some of these people on the list have time to answer or comment on almost every question that comes through this list! :-) I'm lucky if I can read through half of them!
> -----Original Message----- > From: Nigel Taylor [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 12:31 AM > To: [EMAIL PROTECTED] > Subject: Re: ISP 30bit net question [7:45257] > > Dre, > Question? When did you ever find time to read all of these > RFC's? > I'm I to assume > that both you and "Howard" have quite a bit more in common than you > seemingly endless > depth of knowledge in our field. > > Maybe the next time I speak with my mother, I'll talk to here about what > possibilities existed > if any, in bringing me into the world a whole lot sooner. :-> > > Nigel > > > ----- Original Message ----- > From: "dre" > To: > Sent: Tuesday, May 28, 2002 12:59 PM > Subject: Re: ISP 30bit net question [7:45257] > > > > ""Patrick Ramsey"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Is there a specific reason why isp's do not use private addess space > for > > > their 30bit networks to customers? > > > > Because if those links somehow send ICMP messages back to sources > > (e.g. host-/net-/prot-/port- unreachables, squench, time exceeded, needs > > frag unreachables, etc), it looks a lot better if these are publically > > routable > > IP addresses. Some people also would end up blocking these messages > > more often if they had a deny filter for, say, 10-dot space (if that ISP > > used > > 10-dot space for their infrastructure addressing). This could end up > > affecting > > things like traceroutes, path MTU discovery, and other unfriendly > things. > > > > http://www.ietf.org/rfc/rfc1191.txt > > RFC 1191 Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990. > > (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT > > STANDARD) > > http://www.ietf.org/rfc/rfc2923.txt > > RFC 2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000. > > (Format: TXT=30976 bytes) (Status: INFORMATIONAL) > > http://www.ietf.org/rfc/rfc792.txt > > RFC 792 Internet Control Message Protocol. J. Postel. Sep-01-1981. > > (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950) > > (Also STD0005) (Status: STANDARD) > > > > So when you do a traceroute through an ISP, especially the time exceeded > > messages will come from publically routable IP space that not only is > > available > > in the BGP table and marked as owned by a particular ASN, but also > available > > in the Internet routing registries (e.g. RADB) and regional internet > > registries (e.g. > > ARIN) as ISP-owned space that can be accounted for. This could be > important > > for a number of reasons. > > > > Also, if you want to give those links "DNS", in particular, "Reverse > DNS", > > there > > is no global authority for 10-dot or private address space as far as > reverse > > DNS > > is concerned. There would be no way to update that type of information > for > > any > > ISP. This would affect more things as well (esp. traceroutes again). > > > > For more information on the above, you might want to check out this > > Internet- > > Draft, > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dontpublish-unreachab > le > > -03.txt > > > > Here is another Internet-Draft that somewhat covers these issues: > > http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt > > > > You'll also note that a customer might find it difficult to set his > next-hop > > (or default > > gateway) to an ISP infrastructure address that's made up of 10-dots, > > especially if > > that customer is already routing 10-dots on his/her internal network(s). > > You could > > eventually hit router-id problems, etc etc. This wouldn't work so well > for > > routing > > protocols. > > > > > I can't think of anything right off hand that would prevent an isp > from > > > being able to route properly using private addresses for serial links. > > > > Basically, because it breaks things and it is also ugly and > unmanageable. > > > > I can't think of any reason that would allow an ISP to route properly > using > > private addresses, yet somehow some ISP's in the past may have gotten > away > > with it here and there. Consider all the reasons above before you > implement > > something like that. > > > > I highly recommend that ISP's use PI public address space for their > > infrastructure > > addresses, including /30's and /32 loopback addresses. I also implore > > vendors and > > ISP's to implement RFC 3021 and use 31-bit prefixes instead of 30-bit > > prefixes for > > point-to-point interfaces. > > > > http://www.ietf.org/rfc/rfc3021.txt > > RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links. A. Retana, > R. > > White, V. Fuller, D. McPherson. December 2000. (Format: TXT=19771 > > bytes) (Status: PROPOSED STANDARD) > > > > I also suggest implementing correct ICMP operation for these devices > > (rate-limiting > > works well in the place of filtering outright). Here is a document > > concering that: > > http://www.cymru.com/~robt/Docs/Articles/icmp-messages.html > > > > Finally, I suggest registering these routes in an IRR system (e.g. > RADB), > > the RIR > > system (e.g. ARIN) and having RFC 2142 or stdaddr correct SMTP addresses > > for contact information about these networks. Also making these routers > a > > part > > of the global DNS system (both forward and reverse) completes a best > > practice > > reference architecture for routing in the Internet. > > > > http://www.ietf.org/rfc/rfc2142.txt > > RFC 2142 Mailbox Names for Common Services, Roles and Functions. D. > > Crocker. May 1997. (Format: TXT=12195 bytes) (Status: PROPOSED > > STANDARD) > > http://www.watersprings.org/pub/id/draft-vixie-ops-stdaddr-01.txt > > > > http://www.ietf.org/rfc/rfc1034.txt > > RFC 1034 Domain names - concepts and facilities. P.V. Mockapetris. > > Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, > RFC0882, > > RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, > > RFC2065, RFC2181, RFC2308, RFC2535) (Also STD0013) (Status: > STANDARD) > > http://www.ietf.org/rfc/rfc1035.txt > > RFC 1035 Domain names - implementation and specification. P.V. > > Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes > > RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, > > RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, > > RFC2137, RFC2308, RFC2535, RFC2845) (Also STD0013) (Status: > STANDARD) > > > > -dre Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45348&t=45257 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
