Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-04.txt

From: [email-masked]
Date: Wed, 02 Jun 1999 08:30:18 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of the IETF.

	Title		: Transition Mechanisms for IPv6 Hosts and Routers
	Author(s)	: R. Gilligan, E. Nordmark
	Filename	: draft-ietf-ngtrans-mech-04.txt
	Pages		: 24
	Date		: 01-Jun-99
	
This document specifies IPv4 compatibility mechanisms that can be
implemented by IPv6 hosts and routers.  These mechanisms include
providing complete implementations of both versions of the Internet
Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4
routing infrastructures.  They are designed to allow IPv6 nodes to
maintain complete compatibility with IPv4, which should greatly
simplify the deployment of IPv6 in the Internet, and facilitate the
eventual transition of the entire Internet to IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ngtrans-mech-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ngtrans-mech-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Sellers, Julian P" <[email-masked]>
Date: Tue, 8 Jun 1999 14:33:53 -0600

Richard Draves wrote:
	.
	.
	.
> Section 3.7 says
>      Both the configured and automatic tunnels are IPv6 
> interfaces (over
>      the IPv4 "link layer") thus must have link-local addresses.  The
>      link-local addresses are used by routing protocols operating over
>      the tunnels. 
> 
> I disagree with this - I think link-local addresses should 
> only be required
> for genuine links, those which employ Neighbor Discovery. So for this
> document, that would be 6over4 links and bidirectional 
> configured tunnels.

I think this answers my fundamental question about this document, which is:
Do hosts and routers perform Neighbor Discovery and Stateless Address
Autoconfiguration on configured tunnels?

Section 1.1, Terminology, defines configured tunneling as follows:

        Configured tunneling:

                IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
                address is determined by configuration information on
                the encapsulating node.  The tunnels can be either
                unidirectional or bidirectional.  Bidirectional
                configured tunnels behave as virtual point-to-point
                links.

This implies that hosts and routers perform Neighbor Discovery on
bidirectional configured tunnels (since those tunnels behave as virtual
point-to-point links).  I have not found a definition of "unidirectional"
and "bidirectional" configured tunnels, but I get the impression that
"bidirectional" means "configured at both ends of the tunnel."

Section 3.7 describes formation of the link local address of a tunnel (see
Richard Draves' comment above concerning which kinds of tunnels need link
local addresses), and offers only the following comment on the use of the
link local address:  "The link-local addresses are used by routing protocols
operating overthe tunnels."

Then comes Section 3.8, Neighbor Discovery over Tunnels, where I expected to
find some description of whether and how Neighbor Discovery works across a
tunnel.  Instead, 3.8 states in its entirety:

     Automatic tunnels and unidirectional configured tunnels are
     considered to be unidirectional.  Thus the only aspects of Neighbor
     Discovery [7] and Stateless Address Autoconfiguration [5] that
     apply to these tunnels is the formation of the link-local address.

     If an implementation provides bidirectional configured tunnels it
     MUST at least accept and respond to the probe packets used by
     Neighbor Unreachability Detection [7].  Such implementations SHOULD
     also send NUD probe packets to detect when the configured tunnel
     fails at which point the implementation can use an alternate path
     to reach the destination.  Note that Neighbor Discovery allows that
     the sending of NUD probes be omitted for router to router links if
     the routing protocol tracks bidirectional reachability.

The first paragraph of 3.8 rules out Neighbor Discovery and Stateless
Address Autoconfiguration on unidirectional tunnels (and I think that
Richard Draves' comment applies here also).  The second paragraph mentions
only Neighbor Unreachability Detection on bidirectional configured tunnels.
This leaves me still uncertain about 1) what "bidirectional" means, and 2)
whether or not hosts and routers perform Neighbor Discovery and Stateless
Address Autoconfiguration on configured tunnels.

Assuming that ND and SAA are required on a tunnel, I can guess that a router
probably would not respond to a host's Router Solicitation across a tunnel
if the router did not also have the tunnel configured.  A definition of
"bidirectional configured tunnel," together with the existent definition of
configured tunneling quoted above would probably confirm that.

Another question is whether two hosts can configure a tunnel between
themselves, discover each other, and communicate using their link local
addresses.  I don't know if anyone would want to do that, but I'd like to
know if it would be possible.

Please excuse this rookie's ramblings if these are really stupid questions.
Thank you for any assistance.

Julian Sellers

---

From: Richard Draves <[email-masked]>
Date: Thu, 17 Jun 1999 18:08:37 -0700

> There must be some miscommunication.

For sure!

> I added the whole concept
> of bidirectional tunnels in the draft because you pointed out
> that the concept was missing. And now you want yet-another concept!

The "missing" concept was bidirectional configured tunnels that use Neighbor
Discovery. The concept of unidirectional configured tunnels that do not use
Neighbor Discovery already existed. The concept of a pair of unidirectional
configured tunnels already existed - although it may not have been explicit
in the spec it's what you got in practice when two people set up configured
tunnels. I don't want any additional concepts.

I would agree with Julian, way back when I first read about & implemented
configured tunnels it was unclear to me how they were supposed to use or
interact with Neighbor Discovery. I guess I'm still having trouble with it.
:-)

> You must mean something different than RFC 2460 when you say 
> "interface".
> It says:
>    interface   - a node's attachment to a link.
> 
>    link        - a communication facility or medium over 
>                  which nodes can
>                  communicate at the link layer, i.e., the layer
>                  immediately below IPv6.  Examples are 
>                  Ethernets (simple
>                  or bridged); PPP links; X.25, Frame Relay, or ATM
>                  networks; and internet (or higher) layer "tunnels",
>                  such as tunnels over IPv4 or IPv6 itself.
> 
> I can't read this other than a node's attachment to a tunnel over IPv4
> is an interface.

But must every form of tunneling or encapsulation be considered a link, with
the node having an interface on the link and a link-local and other
addresses assigned to the interface ? I hope not.

For example the creation of a tunnel-mode security association in IPsec
doesn't mean you have a new link with interfaces on the link and new
link-local addresses assigned to those interfaces. Or what about automatic
tunneling? Or 6to4?

> Having said that implementations are free to implement tunnels any way
> they please. For instance in BSD based systems here may or may not be
> an ifnet structure associated with an IPv6 interface as defined above.
> 
> Is there an implementation problem to have link-local addresses
> for tunnels?

I would like to allow the implementation architecture where a simple host
implementation has a configured tunnel without having an "interface"
structure associated with the tunnel. With this simple implementation
architecture, it's awkward at best to associate a link-local address with a
configured tunnel. This simple architecture doesn't work for dynamic routing
protocols, but otherwise it's sufficient to interoperate with other nodes on
the 6bone.

Thanks,
Rich