""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-unreachable -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=45264&t=45257 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
