Subject: (ngtrans) Re: I-D ACTION:draft-ietf-ngtrans-mech-v2-00.txt

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Aug 2002 13:13:45 +0300 (EEST)

On Thu, 25 Jul 2002 [email-masked] wrote:
> 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)	: E. Nordmark, R. Gilligan
> 	Filename	: draft-ietf-ngtrans-mech-v2-00.txt
> 	Pages		: 23
> 	Date		: 24-Jul-02

Here are my comments on the document.

Bigger ones:

 1) Do we need to support/document unidirectional tunneling?  Does anyone 
use/implement that?  It should be in a separate document (if someone 
cares) if not.

 2) Tunnel MTU and Fragmentation

           if (IPv4 path MTU - 20) is less than or equal to 1280
                   if packet is larger than 1280 bytes
                           Send IPv6 ICMP "packet too big" with MTU = 1280.
                           Drop packet.
                   else
	                   Encapsulate but do not set the Don't Fragment
	                   flag in the IPv4 header.  The resulting IPv4
                           packet might be fragmented by the IPv4 layer on
                           the encapsulating node or by some router along
                           the IPv4 path.
                   endif
           else
                   if packet is larger than (IPv4 path MTU - 20)
                           Send IPv6 ICMP "packet too big" with 
                           MTU = (IPv4 path MTU - 20).
                           Drop packet.
                   else
                           Encapsulate and set the Don't Fragment flag
                           in the IPv4 header.
                   endif
	   endif

==> note "equal" in the first if.  This leads to a rare non-optimization
in the case that IPv4 path MTU is 1300: Don't Fragment flag is not set,
but it could be.  Did I miss something?  If not, dropping 'or equal' would 
just drop the case of 1300 to "else" and all would be well.

 3) Type of Service.
   - Should this be changed to DSCP and friends?  
   - Reference to ECN + tunneling considerations?
   - Remove/revise "currently underway" -comments:

--8<--
	Type of Service:

		0. [Note that work underway in the IETF is redefining
		the Type of Service byte and as a result future RFCs 
		might define a different behavior for the ToS byte when
		tunneling.]

3.6.  Decapsulation

   When decapsulating the packet, the IPv6 header is not modified.
   [Note that work underway in the IETF is redefining the Type of
   Service byte and as a result future RFCs might define a different
   behavior for the ToS byte when decapsulating a tunneled packet.]
--8<--

 3) We need better security considerations than last paragraph of 3.6 and 
ingress filtering.  The most major concern not addressed here is being 
able to inject packets to the node remotely as if they came from a 
physically local link.

More editorial ones:

1. Introduction

   The mechanisms defined here are intended to be part of a "transition
   toolbox" -- a growing collection of techniques which implementations
   and users may employ to ease the transition.  The tools may be used 
   as needed.  Implementations and sites decide which techniques are   
   appropriate to their specific needs.  This document defines the basic
   set of transition mechanisms, but these are not the only tools
   available.  Additional transition and compatibility mechanisms are
   specified in other documents.

==> I think the first sentence about 'part of transition toolbox' is a bit 
outdated, considering that these are "basic" or "core" mechanisms.

==> Split from beginning of 'This document defines ...' to a new 
paragraph.

   Types of IPv6 Addresses

	IPv6-native address:

		The remainder of the IPv6 address space.  An IPv6
                address that bears a prefix other than 0:0:0:0:0:0.

==> Note: IPv6-native address range includes e.g. mapped addresses.  
Speaking of them as "native" is IMO a bit inappropriate, but I'm not sure 
how to fix this properly.

==> Generic note: there are a lot of terms defined, some more or less
trivial.  I guess this isn't a bad thing..

1.2.  Structure of this Document

==> is this subsection necessary?  There's the contents and basically 3 
chapters..

2.  Dual IP Layer Operation

   The dual IP layer technique may or may not be used in conjunction
   with the IPv6-over-IPv4 tunneling technique, which are described in
   sections 3 and 4.  An IPv6/IPv4 node MAY support configured
   tunneling.

==> First sentence appears to be rather funny.  By definition, if you use
IPv6-over-IPv4 tunneling, you must have dual IP layer, but it has to be
used.  Is there something I'm missing?

2.3.  Advertising Addresses in the DNS

   However, this does not work well when the isolated node is trying to
   establish communication.  Even though it does not have an IPv6
   address in the DNS it will find AAAA records in the DNS for the peer.
   Since the isolated node has IPv6 addresses assigned to at least one  
   interface it will try to communicate using IPv6.  If it has no IPv6  
   route to the 6bone (e.g., because the local router was upgraded to   
   advertise IPv6 addresses using Neighbor Discovery but that router    
   doesn't have any IPv6 routes) this communication will fail.
   Typically this means a few minutes of delay as TCP times out.  The
   TCP specification [10] says that ICMP unreachable messages could be
   due to routing transients thus they should not immediately terminate
   the TCP connection.  This means that the normal TCP timeout of a few
   minutes apply.  Once TCP times out the application will hopefully try
   the IPv4 addresses based on the A records in the DNS, but this will  
   be painfully slow.

==> This does not seem to take possible ordering of results (e.g. A first, 
then AAAA) into account.

3.  Common Tunneling Mechanisms

   Tunneling techniques are usually classified according to the
   mechanism by which the encapsulating node determines the address of
   the node at the end of the tunnel.  In the first two tunneling
   methods listed above -- router-to-router and host-to-router -- the
   IPv6 packet is being tunneled to a router.  The endpoint of this type
   of tunnel is an intermediary router which must decapsulate the IPv6
   packet and forward it on to its final destination.  When tunneling to
   a router, the endpoint of the tunnel is different from the
   destination of the packet being tunneled. [...]

==> this is outdated, especially the last sentence: consider e.g. 6to4 
border routers where address embeds the router's address, not the 
end-node.

   -    The encapsulating node MAY need to maintain soft state
        information for each tunnel recording such parameters as the MTU
        of the tunnel in order to process IPv6 packets forwarded into
	the tunnel.  Since the number of tunnels that any one host or
        router may be using may grow to be quite large, this state
	information can be cached and discarded when not in use.

==> As automatic tunneling has been removed, this is not really all that
important anymore for non-automatic mechanisms, especially the last
sentence.

3.2.  Tunnel MTU and Fragmentation

   Encapsulating nodes that have a large number of tunnels might not be
   able to store the IPv4 Path MTU for all tunnels.  Such nodes can, at
   the expense of additional fragmentation in the network, avoid using
   the IPv4 Path MTU algorithm across the tunnel and instead use the MTU
   of the link layer (under IPv4) in the above algorithm instead of the
   IPv4 path MTU.

==> this is similar to the comment above about automatic tunnels, this is 
semi-OK to me though.

3.4.  Handling IPv4 ICMP errors

   In response to encapsulated packets it has sent into the tunnel, the
   encapsulating node might receive IPv4 ICMP error messages from IPv4 
   routers inside the tunnel.  These packets are addressed to the
   encapsulating node because it is the IPv4 source of the encapsulated
   packet.

==> s/inside the tunnel/on the path of the tunneled packets/ (or 
something) ?

3.5.  IPv4 Header Construction

	Total Length:

	        Payload length from IPv6 header plus length of IPv6 and
		IPv4 headers (i.e. a constant 60 bytes).

==> (i.e. IPv6 payload length plus a constant 60 bytes)?
(I'm not sure if this is really necessary.. :-)

	Source Address:

	        IPv4 address of outgoing interface of the encapsulating
		node.

==> IPv4 MAY also be administratively specified.
(This is especially useful on multi-interface nodes and with configured 
tunneling)

3.6.  Decapsulation

   After the decapsulation the node SHOULD silently discard a packet
   with an invalid IPv6 source address.  This includes IPv6 multicast
   addresses, the unspecified address, and the loopback address but also
   IPv4-compatible IPv6 source addresses where the IPv4 part of the
   address is an (IPv4) multicast address, broadcast address, 0.0.0.0,
   or 127.0.0.1.  In general it SHOULD apply the rules for martian
   filtering in [18] and ingress filtering [13] on the IPv4-compatible
   source address.

==> there are other places to embed weird IPv4 addresses than compatible
addresses, and compatible addresses are kind of a moot point now that they
aren't used anymore anyway.

   The decapsulating node performs IPv4 reassembly before decapsulating
   the IPv6 packet.  All IPv6 options are preserved even if the
   encapsulating IPv4 packet is fragmented.

==> This paragraph should probably be earlier in this section, before 
other decapsulation checks.

3.7.  Link-Local Addresses

==> s/Link-L/Link-l/ ?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Aug 2002 14:57:03 +0200 (CEST)

Thanks for the comments.

> use/implement that?  It should be in a separate document (if someone 

Good question. What do others think?

> just drop the case of 1300 to "else" and all would be well.

Hmm - I think you're right but I don't understand how we missed this
when designing the algorithm. 

>    - Should this be changed to DSCP and friends?  

I don't think there is a specification which formally updates RFC 791 to
rename the field in the IP header. RFC 2474 says:
   This document defines the IP header field, called the DS (for
   differentiated services) field.  In IPv4, it defines the layout of
   the TOS octet; in IPv6, the Traffic Class octet.  In addition, a base
   set of packet forwarding treatments, or per-hop behaviors, is
   defined.
Thus the name of the field remains "ToS".

>    - Remove/revise "currently underway" -comments:

I think referencing something in a non-normative way would be helpful
instead of the "underway" language.

> able to inject packets to the node remotely as if they came from a 

Do you have suggested text?

> outdated, considering that these are "basic" or "core" mechanisms.

What do you suggest instead?

> ==> Split from beginning of 'This document defines ...' to a new 

OK

> how to fix this properly.

Oops.

> used.  Is there something I'm missing?

The intent is the other way around; tunneling might be used when dual stack is
used. 

> ==> This does not seem to take possible ordering of results (e.g. A first, 

Yep. I guess the section should say it is looking at the worst case.
For the introduction of IPv6 that is AAAA ordered before A.

> border routers where address embeds the router's address, not the 

Hmm - do you have better text to suggest?

> important anymore for non-automatic mechanisms, especially the last

What is the "this" that isn't important?

I agree that the last sentence
isn't that critical, but it isn't harmful either to point out that the
information can be discarded and re-learned.

> ==> s/inside the tunnel/on the path of the tunneled packets/ (or 

Do you think the notion of "inside" is unclear?
If it is I'm not sure your suggestion is any better. When there
are multiple tunnels in the path that packets take through the network
your suggestion doesn't separate out that the different tunnels are
different.

> (I'm not sure if this is really necessary.. :-)

What are you suggesting? Just having the number 60 without explaining where
it comes from seems less than ideal.

> (This is especially useful on multi-interface nodes and with configured 

OK

> aren't used anymore anyway.

They might be used by attackers long after we remove them from the spec.
I'd like to leave some trace of this consideration in the specification
somehow.

> other decapsulation checks.

OK

> 3.7.  Link-Local Addresses

Good question. I was assuming capital-L made sense since the words
in the section titles have capitalized first letters. 

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Aug 2002 16:51:51 +0200

Pekka Savola wrote:
...
>    behavior for the ToS byte when decapsulating a tunneled packet.]

Good catch. 

Replace both [..] by reference to RFC 2983 "Differentiated Services and Tunnels"

   Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 8 Aug 2002 10:07:12 +0200 (CEST)

The ECN document also contains text about the ToS byte and tunneling.
Hence I'm adding references to this as well as the diffserv tunneling
document.

Suggested text:
        Type of Service:

                0.  (See [20] and [21] for issues relating to the ToS
                byte and tunneling.)

---

   When decapsulating the packet, the IPv6 header is not modified.  (See
   [20] and [21] for issues relating to the Type of Service byte and
   tunneling.)  If the packet is subsequently forwarded, its hop limit
   is decremented by one.

---

 [20]   D. Black, "Differentiated Services and Tunnels", RFC 2893,
        October 2000.

 [21]   K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit
        Congestion Notification (ECN) to IP", RFC 3168, September 2001.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Aug 2002 13:36:23 +0200

Looks good to me

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Aug 2002 15:20:08 +0300 (EEST)

Answering to the more or less remaining points.

> when designing the algorithm. 

MTU 1300 is rather rare and it works both ways?

Not that this detail really matters, but just noticed when looking at the 
pseudocode..
 
> Do you have suggested text?

No.. I could have, if need be.  I'm wondering whether this would have to
be written about in a bit more verbose manner, e.g. an I-D.
 
> >    appropriate to their specific needs.  [...]
> > 

The mechanisms defined here are intended to form the core of a "transition
toolbox" -- [...]

A bit strong words though..
 
> The intent is the other way around; tunneling might be used when dual stack is

Ok, then a rephrasing might be helpful, e.g.:

    The IPv6-over-IPv4 tunneling techniques, which are described in
    sections 3 and 4, may or may not be used in addition to the dual IP 
    layer operation.  An IPv6/IPv4 node MAY support configured tunneling.

[ note: also made tunneling techniques plural (common/configured)]

The last sentence is IMO a bit redundant, but still ok.

> Hmm - do you have better text to suggest?

In:

                                                So the addresses in the
   IPv6 packet being tunneled can not provide the IPv4 address of the
   tunnel endpoint.  Instead, the tunnel endpoint address must be
   determined from configuration information on the node performing the
   tunneling.

Do:

  s/So the addresses/In some cases, the addresses/
  s/must be determined/may need to be determined/

Perhaps this would be enough.
 
> What is the "this" that isn't important?

That the number of tunnels on a host may grow quite large and one may have 
to cache a lot of information (mainly MTU).

With only configured tunneling, this is not a problem; with stuff like 
6to4 (with non-standard MTU, see the new discussion), it may be.
 
> information can be discarded and re-learned.

Ok, it's ok as it is, though a small note about the applicability (not 
really needed for confg'd tunnels) would be better.
 
> Do you think the notion of "inside" is unclear?

Yes.

To me, 'inside the tunnel' are the IPv6 packets, well, encapsulated in
IPv4 packets.

Perhaps, s/inside the tunnel/forwarding the tunneling IPv4 packets/

> your suggestion doesn't separate out that the different tunnels are

The issue is that an encapsulating router can't know that: if any one 
router (be it on path or not) sends an ICMPv4 error with sufficient 
information, the encapsulating router will pass it on to IPv6 source.

So even though the messages should be sent from the path, it really isn't 
required, only the sufficient knowledge in the packet.

> it comes from seems less than ideal.

What I meant was replacing the section with:

     Total Length:

             Payload length from IPv6 header plus length of IPv6 and
             IPv4 headers (i.e. IPv6 payload length plus a constant 60 
             bytes).

but I wasn't sure if the original was really that ambiguous (though, 
textually, totally out of the context, it would have been).
 
> I'd like to leave some trace of this consideration in the specification

Ok.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 11:16:38 +0200 (CEST)

Thanks for the suggested texts - very helpful.

> MTU 1300 is rather rare and it works both ways?

Yes, it works in both cases. But I'll change it to use the more optimal
approach for that edge case of MTU = 1300.

> be written about in a bit more verbose manner, e.g. an I-D.

Reading your text above more carefully I think I now understand your point.
A node with a tunnel will see packets arrive on the tunnel (which is a single
link - not just a physical link) and it needs to understand that this is
different than a physical attached link because attackers can be remote.
Does this do a good job of capturing the issue:
	An implementation of tunneling needs to be aware that while a tunnel
	is a link (as defined in [4]), the threat model for a tunnel might be
	rather different than for other links, since the tunnel potentially
	includes all of the Internet. The recommendations to verify that
	the IPv4 addresses in the encapsulated packet matches what has been
	configured for the tunnel, coupled with use of ingress filtering
	in IPv4, ameliorate some of this. In addition, an implementation
	must treat interfaces to different links as separate e.g. to ensure that
	Neighbor Discovery packets arriving on one link does not effect
	other links.  This is particularely important for tunnel links.

>   s/must be determined/may need to be determined/

I did a slight variant on that which I think captures your intent:
	In some cases, the addresses in the
	IPv6 packet being tunneled can not provide the IPv4 address of the
	tunnel endpoint.  In those cases, the tunnel endpoint address must be
	determined from configuration information on the node performing the
	encapsulation.

> 6to4 (with non-standard MTU, see the new discussion), it may be.

I think this is what the paragraph should have said. Does it make more sense?
	The encapsulating node MAY need to maintain soft state
	information for each tunnel recording such parameters as the MTU
	of the tunnel in order to process IPv6 packets forwarded into
	the tunnel.  In cases where the number of tunnels that any one host or
	router is using is large, it is helpful to observe that this state
	information can be cached and discarded when not in use.

> Perhaps, s/inside the tunnel/forwarding the tunneling IPv4 packets/

Since "inside" is used in 3 places, I propose saying this the first time
it is used
	[...] inside the tunnel, i.e. between
	the encapsulating node and the decapsulating node, 

> information, the encapsulating router will pass it on to IPv6 source.

Sure. But it is a different encapsulating router for different tunnels
hence just saying "forwarding encapsulated packets" is not very accurate.
"forwarding the encapsulated packets encapsulated by this node" is
accurate but a bit verbose.

>              IPv4 headers (i.e. IPv6 payload length plus a constant 60 

Got it.
It's an improvement.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Aug 2002 14:45:57 +0300 (EEST)

Yes.

> 	other links.  This is particularely important for tunnel links.

This does not go into nasty details (probably shouldn't, either), but 
looks rather good.

A nasty detail is that as many protocols implement src=link-local address
hoplimit=255 checks (to protect from off-link attackers), there are
completely useless against attackers on tunnel links.

Therefore, especially "blind decapsulation" (like autotunnel) can be a 
source of enermous problems.

(s/particularely/particularly/ or especially (IMO better))

> 	determined from configuration information on the node performing the

Looks good.
 
> 	information can be cached and discarded when not in use.

Excellent.
 
> 	the encapsulating node and the decapsulating node, 

Good.
 
> accurate but a bit verbose.

Above clarification should be enough, I think.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 14:23:54 +0200 (CEST)

> completely useless against attackers on tunnel links.

Those packets are from neighbors (on link) on the tunnel link.
The point about "keep the links separate" is supposed to address
the fact that you don't want e.g. a router advertisement arriving on one 
interface affect things for other interfaces.
Of course, what this means for an implementation is a detail
that belongs in the yet-to-be-written "Neighbor Discovery on multi-linked
nodes" document :-) and tunnels make that slightly more interesting (one
can envision access control mechanisms e.g. to ignore router advertisements
on tunnel interfaces to affect the per node default router list for instance).

Seriously, it would be a mistake for the document to try to cover this in
detail, since by the protocols that treat "on-link" differently is
likely to increase over time. But perhaps a more concrete example would
be helpful. A example that doesn't go into the general multihoming
problem space would be to state that e.g. a Neighbor Advertisement packet
with hoplimit 255 received on a tunnel should of course not be able to
affect a neighbor cache entry the claimed address on different interface
(which should be evident from RFC 2461 stating that the neighbor cache is
per interface).

Would that make sense? Or is there something else we can do that doesn't
mislead folks into thinking that this document is authoritative on
the issues for security issues that cross interface boundaries on multi-linked
nodes?

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Aug 2002 15:40:24 +0300 (EEST)

> interface affect things for other interfaces.

Yep.  But in practise RA does always affect other interfaces (e.g. if the 
node configures the new default route towards the tunnel, or whatever).

Yes.

> likely to increase over time. 

Agreed.

> But perhaps a more concrete example would

Perhaps modifying what you suggested earlier:

                                        In addition, an implementation
        must treat interfaces to different links as separate e.g. to 
                                                           ensure that
        Neighbor Discovery packets arriving on one link does not effect
        other links.

ND packets -> ND packets (for example, in particular Route Advertisement 
messages) 

would be enough of a hint? (RA is the most important ND feature that 
affects multiple interfaces)

Or would that just lead people to believe they're safe if they disable RA?  
Hmm.
 
> the issues for security issues that cross interface boundaries on multi-linked

The security considerations section should not be too abstract and tight 
(e.g. IMO in 6to4 it was and thus difficult to grasp), but not overly 
verbose either.

If this is a bigger problem that needs more thorough analysis, perhaps a 
separate document (or separate paragraph) would be one option.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Aug 2002 14:57:03 +0200 (CEST)

Thanks for the comments.

OK

Oops.

OK

OK

  Erik

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 9 Aug 2002 10:13:42 -0500

From: "Erik Nordmark" <[email-masked]>
"I don't understand how we missed..."

How many years ?....and the basics were missed ?

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Aug 2002 14:45:57 +0300 (EEST)

Yes.

Looks good.

Excellent.

Good.