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