NAIPR Message

An idea to bounce off people: storing routing info in the DNS instead of the routers.

Michael,

Michael Gersten wrote:
> 
> Here's an idea that I wanted to bounce off people, a way to extend
> IPv4, reduce the size of the routing tables used by the routers,
> enable /31's to be published (are /32's even legal? If so, them too),
> and solve the complaint that people have of only ARIN issuing IP
> numbers (with no clear idea of what numbers or what criteria) by
> allowing anyone with extra IP's to act as an assigner of IP's.
> 
> The general assumptions are:
> 1. CIDR table reduction is blocked by non-collapsable entries (I.e,
> there's a lot of different published routes going through each
> backbone provider, which can never be collapsed without major
> renumbering)
> 2. Multihomed network entries are not a large component of the
> routing tables (A multihomed network: Any backbone that connects
> to two or more interconnection points, or any ISP that connects to
> two or more backbones, or any network that connects to two or
> more ISPs),
> 3. A new version of VJ-header compression can be written to deal
> with loose source routes in the headers (on the assumption that 99%
> of the loose source routes will be the same as the last one, just like
> the current assumption that 99% of the packets will go to the same
> place as the last packet),
> 4. Routers either (A) do not mind loose source routes in packets
> going through them, or (B) can have their software modified so that
> loose source routes, if "unchanged" (see 3 above), are essentially the
> same as destination addresses,
> 5. People will (can be forced to) update their DNS entries if the
> alternative is no packets will reach them (for the average dialup user
> this is a do-nothing -- their ISP will update the ISP's DNS entries if
> the ISP changes its backbone provider),
> 6. Someone else can solve the DNS security issues (:-)
> 7. All "major" routers -- those used by sprint, MCI, etc, can get
> software updates within about 6 months or less,
> 8. (The Big One): IP v4 has a router redirect message that can
> specify a loose source route to use, not just a single host to use, and
> that most vendor's ship an IP stack that accepts this message
> correctly,
> 9. Adding a new DNS RR to the v4 DNS isn't difficult (will live in the
> in-addr.arpa domain, just like the PTR record does now)
> 
> Before I send off the idea, I wanted to get people's comments on
> these assumptions, especially #8. (Some of you may already see
> what I'm saying here).
> 
> Note on #6: Right now I can find rfc's describing RIP, and how
> routing used to work in the internet. I know that things are not the
> same as they used to be, and that there's a lot of security in the
> routing protocols now, but I do not know which rfc's describe the
> current situation. I also understand that the DNS system can be
> easily lied to, so security is a real concern on this.

  This seems to be a very workable idea.  I think the RFC's you are
looking for
are RFC 2050 and RFC 1918 and Rfc 1917.  (Sorry to all the "ands")  >;)

  As to you concern reguarding regarding #8, I don't see this as a 
major concern right now.  Should be possibility at least.  

Question:  Have you considered submitting this to the ARIN folks through
channels or Ripe perhaps?  Might be worth a shot.

  Over all I like this suggestion.  Solves alot of problems possibly and
takes the political aspect and put's it on the back burner.  But it
might not fly with the InterNic/IANA/ARIN folks for just that reason.
> 
>                 Michael
> p.s. I apologize if these are not the appropriate lists; they are the
> most appropriate ones I know of.
> --
> Michael Gersten     michael at stb.info.com      http://www.stb.info.com/~michael
> NeXT Registered Developer (NeRD) # 3860
> Without Prejudice, UCC 1-207
> ** HIRE ME: http://www.stb.info.com/~michael/work/

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1 at ix.netcom.com