Subject: RE: [dhcwg] IPv6 tunnelling options for IPv4

From: "Bernie Volz" <[email-masked]>
Date: Fri, 1 Oct 2004 13:45:27 -0400

Hi:

Because there are so many different tunnel technologies and so many
different ways in which these can be used, clarity would be extremely
useful. So, I'd highly recommend adding diagrams and descriptions of the
likely uses unless there are good IETF documents elsewhere that can be
referenced (and referenced explicitly, with figure and section numbers).

I don't understand the diagram you included Daniel. Modifying Ralph's,
perhaps it should look like:

          IPv6|<-------------IPv4 only----------->|<--IPv6--...

          +-------+            IPv4          +--------+
          | Dual  |          network         | Tunnel |
          | Host  +------------core----------+endpoint|
          +-------+              |           +--------+
                             +---+--+
                             | DHCP |
                             |server|
                             +------+

The Dual [Stack] host tunnels traffic over IPv4 to get IPv6 connectivity.

I'm also wondering whether there would ever need to be any redundancy in the
tunnel end-points and whether returning a list of IPv4 addresses would be
appropriate. The node can try the first, if no response (not exactly sure
how it would tell - no RA?), it can try the others? But perhaps this is
unneeded complexity at this time as there may not be any easy way for a node
to tell if the end-point is up?

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Soohong Daniel Park
> Sent: Thursday, September 30, 2004 8:09 PM
> To: Ralph Droms; [email-masked]
> Subject: RE: [dhcwg] IPv6 tunnelling options for IPv4
> 
> 
> > I've been reviewing draft-daniel-dhc-ipv6in4-opt-04.txt - does 
> > draft-daniel-dhc-ipv6in4-opt-04.txt specify "configured 
> IPv6-over-IPv4 
> > tunneling", as described in section 4 of RFC 2893?  If so, 
> it would be 
> > helpful to include a specific reference, as there are numerous 
> > tunneling and "IPv6-xxx-IPv4" transition mechanisms...
> 
> So, I've added this concern into the revised version.
> 
> > 
> > I can imagine the mechanism in
> > draft-daniel-dhc-ipv6in4-opt-04.txt as being
> > useful in the following scenario:
> > 
> > <---IPv6---->|<-------------IPv4 only----------->|<--IPv6--...
> > 
> >           +-------+     +------+              +--------+
> >           |  CPE  |     | Edge |      ISP     | Tunnel |
> >           |gateway+-----+Router+-----core-----+endpoint|
> >           +-------+     +------+       |      +--------+
> >                                    +---+--+
> >                                    | DHCP |
> >                                    |server|
> >                                    +------+
> > 
> > In this scenario, the CPE gateway uses DHCPv4 to obtain its IPv4
> > address and
> > other configuration information.  The DHCPv4 configured 
> tunnel endpoint
> > option would provide the IPv4 address of the ISP tunnel endpoint 
> > as part of
> > the DHCPv4 configuration process to the CPE gateway, which 
> would then use
> > that IPv4 address as the destination to tunnel IPv6 traffic from the
> > customer network through the IPv4-only portion of the ISP network.
> > 
> 
> Also, this option is useful for dual stack user to obtain its 
> IPv6 connectivity
> via IPv6-over-IPv4 tunnel within its IPv4 network.
> 
>                          [DHCP server]
>                                   |
>                                   |
> <-----IPv4--------------------+------------------------>IPv6
> [IPv4/6 user]==IPv6-over-IPv4 Tunnel===>
> 
> 
> > If I have this scenario right, it would help to include a 
> > description of it
> > in draft-daniel-dhc-ipv6in4-opt-04.txt, both to clarify the 
> use of the
> > option and motivate the requirements for its definition.
>  
> Originally, I thought of this point as out of scope of the 
> draft because
> several similar draft were proposed in this WG without specific 
> description of use case like mine. If needed, it can be done simply.
> 
> > Is the expectation in draft-daniel-dhc-ipv6in4-opt-04.txt 
> that the tunnel,
> > once established, looks like a simple link to the IPv6 stack?  
> > That is, will
> > RAs be exchanged and ND be run across the link?  Will the 
> tunnel endpoints
> > use a routing protocol?
> 
> It was also tested and added into the new version. RA runs well 
> via this configured tunnel.
> 
> 
> 
>      Daniel (Soohong Daniel Park)
>      Mobile Platform Lab. Samsung Electronics.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Soohong Daniel Park <[email-masked]>
Date: Sat, 02 Oct 2004 08:43:25 +0900

Hi Bernie

> referenced (and referenced explicitly, with figure and section numbers).

no problem here.

>           | Host  +------------core----------+endpoint|

It's why we need a IPv6-over-IPv4 tunnel. There are several possible
use cases according to this tunnel and your depict is one of them.

> to tell if the end-point is up?

In my figure below, when a dual stack node attached to IPv4 only network
generates an IPv6 packet for IPv6 connectivity, it must use a tunnel
interface among its multiple internal interfaces. At that time, IPv6 packet is
encapsulated in IPv4 packet and forwarded it to the tunnel endpoint
via IPv6-over-IPv4 tunnel which is already configured by this mechanism 
proposed in this draft automatically. Tunnel protocol must allow for means 
for one tunnel endpoint to verify the reachability of other tunnel endpoint 
towards which it intends to send packets.When I implemented this
mechanism with DHCP, I used TCP/UDP port assigned by admin in 
advance between dual stack node and tunnel endpoint and it works
well of course.

> [IPv4/6 user]==IPv6-over-IPv4 Tunnel===>

As I indicated earlier (many times), this task works in progress in v6ops
and here are several related document as below;

DHCP approach aims the same concern of below documents

http://www.watersprings.org/pub/id/draft-palet-v6ops-tun-auto-disc-01.txt
http://www.watersprings.org/pub/id/draft-nielsen-v6ops-zeroconf-goals-01.txt

---

From: Josh Littlefield <[email-masked]>
Date: Fri, 08 Oct 2004 17:36:29 -0400

Based on the documents you refer to, it seems that Ralph's diagram, 
which includes an IPv6 router/gateway in the home, is not specifically a 
target of this option, or of the zeroconf tunnel architecture.  The 
zeroconf-goals document describes the need to assign a single /128 
address to the host (sec. 3.1).  While it's possible to support a v6 
gateway on the DHCPv4 client end of the link (through manual 
configuration of IPv6 networks, and RIP, or through DHCPv6 prefix 
delegation), it seems out of scope for this particular document.

In relation to RFC 2983, I think it would be useful to indicate that 
this is in support of automatically configuring a host to router 
configured tunnel (not "automatic tunneling").  By definition, this is 
unidirectional.  Then, if the intent is to support an automated 
establishment of a reverse configured tunnel, that is up to the TEP and 
the host, and to a large extent is beyond the scope of this document.  I 
would think a different document, most likely within v6ops, would define 
things such as how the TEP decides to accept the tunnel, how it decides 
to assist the host in global address assignment, how it the two maintain 
reachability, etc.  In other words, I would thing the details of reverse 
tunnel establishment and maintenance, addressing, etc., would be part of 
a tunnel protocol document that cites this one as the way to kick things 
off.

  -josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: same               Boxborough, MA  01719-2205