Subject: RE: (ngtrans) two ideas for tunnel discovery

From: Cyndi Jung <[email-masked]>
Date: Fri, 15 Oct 1999 07:57:40 -0700

The presentations are now all posted on the forum web sites,

<http://www.ipv6forum.com>

Cyndi

At 02:23 PM 10/15/99 +0100, [email-masked] wrote:
>Keith,
>
>BT has implemented and recently demonstrated at the Paris IPv6 Global Forum
>a system that is very similar to your option 1. We did a presentation of the
>concepts which will soon be available via the IPv6Forums www site or get in
>contact and I can forward you a copy.
>
>Regards,
>Peter
>Peter Hovell
>Futures Lab
>Room 54 MLB4, Adastral Park, Martlesham Heath, IP5 3RE
>Tel: 01473 644208
>Fax: 01473 648808
>eMail: [email-masked]
>==================
>British Telecommunications plc
>Registered Office 81 Newgate Street London EC1A 7AJ
>Registered in England no 1800000
>
>
>> -----Original Message-----
>> From:	Keith Moore [SMTP:[email-masked]]
>> Sent:	14 October 1999 21:26
>> To:	[email-masked]
>> Cc:	[email-masked]
>> Subject:	(ngtrans) two ideas for tunnel discovery 
>> 
>> folks,
>> 
>> In looking for better ways to utilize the existing v4 network
>> as a substrate for deployment of IPv6, I am examining a couple
>> of approaches which don't seem to be covered by any of the
>> existing ngtrans internet-drafts.  these are:
>> 
>> 1. define a new DNS RR, to be used in the ip6.int space,  
>>    to advertise an IPv4 tunnel endpoint associated with
>>    a particular IPv6 address (or a block of IPv6 addresses).  
>>    such RRs could be returned either by explicit query, or 
>>    as additional information in DNS responses which included 
>>    AAAA or A6 records.  IPv6 hosts lacking connectivity to a 
>>    native v6 network could use the DNS information to automatically 
>>    construct a tunnel to an arbitrary IPv6 destination, as long 
>>    as there were a decapsulating router associated with that destination
>>    and advertised in DNS.
>> 
>>    as I imagine it this would look like:
>> 
>>    <ipv6-address>.ip6.int	TE	<v6-prefix-length> <ipv4-address>
>> 
>>    (ipv6-address could perhaps be wildcarded; TE stands for "tunnel
>> endpoint")
>> 
>>    depending on the api, with clever implementation it looks like the 
>>    connection setup delay that might result from extra DNS queries
>>    could often be avoided...i.e. the server DNS software would include
>>    TE records in responses that contained A6 or AAAA records, the host 
>>    DNS software would cache any TE records returned as additional 
>>    information in the response to an application's DNS query, and use
>>    the cache information (much like an arp cache) in 
>>    automatically constructing tunnels for outgoing v6 packets
>>    to those destinations with cached TE records.
>> 
>>    or in a border box the same kind of result could be obtained using
>>    DNS snooping (unlike DNS ALG, there would be no need to modify the 
>>    responses in transit)
>> 
>>    there are some security issues involved...in particular you don't
>>    want to believe a TE record unless it comes from a server known
>>    to be authoritative for that chunk of v6 space, or unless it is
>>    signed by a known and trusted party.  so you might end up doing
>>    the explicit TE query on <ipv6-address>.ip6.int anyway, or maybe
>>    this will serve as an incentive to deploy DNSSEC.  on the
>>    other hand if your api is such that you specify a dns name rather
>>    than an IP address when connecting to a remote host,  that api
>>    could probably safely trust the TE records returned as additional
>>    information (for the purpose of that connection only) as long as
>>    those TE records were not trusted for other connections.
>> 
>> 2. using BGP4's MP_REACH_NLRI attribute to associate 
>>    an IPv4 tunnel endpoint with an IPv6 prefix.  this could 
>>    then be used by v4/v6 border routers to tunnel v6 packets
>>    over the v4 network to a border router associated with
>>    the destination address.
>> 
>>    security issues are different here than in the DNS case,
>>    but the same security issues exist for any use of BGP.
>> 
>>    (I'm not nearly as familiar with BGP as I am with DNS,
>>    so I'm not so qualified to talk about the BGP limitations
>>    or the specifics of how this would be used.  The idea for BGP
>>    was suggested to me by someone else who might or might not want 
>>    his name to be associated with this, but will certainly
>>    be acknowldeged my me if he wishes :)
>> 
>> a few constraints and notes:
>> 
>> both of these should be used only for "real" ipv6 addresses
>> assigned to networks that are connected to the IPv6 Internet.
>> the address blocks advertised through DNS and NLRI have to be 
>> the same address blocks assigned to the site.  neither of these 
>> proposals provides an excuse to allocate IPv6 address space
>> in advance of being natively connected to the IPv6 internet.  
>> 6to4 addresses would still be used by those who are not connected 
>> natively.
>> 
>> #1 is for hosts or low-bandwidth small-scale border routers on the
>> periphery
>> #2 is obviously for routers with BGP feeds.
>> when both are available for a destination, #2 should have precedence 
>> over #1, and native IP routing should have precedence over either #1 or
>> #2.
>> 
>> 
>> the way I see this shaping up, a border box could support
>> NAT-PT, 6to4, and either or both of TE or NLRI.   assuming that
>> all v6 sites would include these records in DNS (if they wanted
>> to be reachable), this combination would allow the border box to provide 
>> end-to-end v6 connectivity to any other v6 host in the world.
>> if it works, this gets rid of the "dead end" by providing a clean
>> transition path from 6to4 to native v6.
>> 
>> two questions:
>> 
>> are there obvious showstoppers that cannot be overcome?
>> (as opposed to technical difficulties that would need further
>> investigation)
>> 
>> are any BGP or DNS experts willing to help draft concrete proposals?
>> 
>> Keith
>
>