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

From: [email-masked]
Date: Fri, 15 Oct 1999 14:23:25 +0100

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Oct 1999 13:24:35 -0400

> contact and I can forward you a copy.

In private mail, Peter sent me a pointer to the slides (thanks!)
for the information of others on the list, they are at:

http://www.ipv6forum.com/navbar/globalsummit/slides/zips/john.king.zip
(unzipping the file gives you a powerpoint document)

This is slightly different than what I'm proposing.    In particular
I'd like to avoid doing any DNS munging in the native-IPv6 case.
Instead I would propose that during the transition phase, all IPv6 networks:

(a) provide a decapsulating gateway which accepts IPv6-in-IPv4 and
    (if the inner destination address is that of one of their customers)
    decapsulates the inner packet and forwards it to its v6 destination.

(b) advertise the address of that gateway in DNS using a new RR type
    (or allow their customers to do so)

(c) advertise the address of that gateway in BGP using NLRI

(b) would allow any host or (low-volume) router in IPv4-land to
discover the tunnel endpoint corresponding to an IPv6 address.
(c) would allow a BGP-connected router to do the same.

From my understanding of the slides, the BT Ultima system is different
in that (a) it uses DNS only and (b) it tries to automate the process 
of advertising the endpoint address by having the border boxes modify
DNS packets in transit.

Keith