Subject: mech-v2-05pre

From: Pekka Savola <[email-masked]>
Date: Mon, 23 Aug 2004 10:00:44 +0300 (EEST)

Hi,

(editor hat on)

It appears that there is at least some form of support of clarifying
the text to more clearly state that the tunnel entrypoint should be an
IPv4 address of the encapsulator. However, there are reasons (e.g., as
Stephen mentioned) why checking this at configuration time might not
be beneficial, and others also think this is an implementation detail.  
Therefore, I've opted for doing just simple clarifications, and
leaving the rest as implementation details.

This is not felt to be sufficient, I guess the only alternative would
be to add a new 3.x section which discusses the
configuration/operational aspects of tunnels, and certain
implementation approaches (e.g., the operational status of the tunnel
based on routing information, etc.).. but IMHO that's beyond the scope
of a protocol spec.

Please see proposed text at:

http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre-diff.html

Note: there have been no changes relating to sending ICMPv4 messages
for unconfigured tunnels.  That issue has already been closed long
time ago, with good reasons to have it the way it is now, and there is
no reason to repeat it now.

Is this a sufficient resolution to the concerns voiced in the WG?
Please speak up (on- or off-list) within a couple of days.

(editor hat off)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alex Conta <[email-masked]>
Date: Mon, 23 Aug 2004 12:19:11 -0400

Pekka,

Providing a revised draft is a definite step forward, definite progress.

I have some comments to the new text, one of which is major (see in line).

I have also some general comments, which I consider important (see in line).

> be beneficial, and others also think this is an implementation detail.  

Perhaps you have not read the last message Stephen sent on the 
discussion thread; as it turns out, the implementation Stephen mentioned 
does perform an address check, on the completion of the interface 
configuration operation.

Importantly, because the tunnel is a virtual point-to-point link, 
checking the correct tunnel entry point address, if it is being 
configured, is primarily a "protocol issue", so it belongs to the tunnel 
protocol engine, as opposed to the command used to configure the tunnel.

The correct analogy between this type of tunnel and a TCP, (or connected 
UDP) communication was made in some earlier messages, in that the "bind" 
function call implementation, called when "binding" a TCP, (or UDP) 
socket to an address, checks that the address belongs to the node.

Making the correct implications and distinctions in the text of this 
specification is in my view important as to not misguide the reader.

Currently, the specification seem to suggest that the checking is a 
"configuration command issue", and that is false: it is a "protocol 
setup issue", with appropriate place to address in the protocol setup 
mechanism.

Remember, the protocol can be setup by using some commands (CLI), but it 
can be setup also by calling directly function calls or entry points in 
the "protocol setup code".

The check can be implemented in the "command" code, but only as an 
additional check, and not as a replacement of the code
in the "protocol engine setup", which is th appropriate place for the 
check.

An analogy can be made with an FTP session, in which a "source address"
specified as parameter can be checked during "command" parameter 
validation phase, but ultimately, it is the TCP "bind" call in the 
protocol engine setup that checks the address, for protocol correct 
functioning.

> based on routing information, etc.).. but IMHO that's beyond the scope

Note that this specification is for a type of tunnel which creates a 
unique "pseudo-convergence", or "intersection" point between the IPv6 
and IPv4 routing systems, and the potential effects of routing 
instability from that perspective on the tunnel mechanisms, are in the 
scope of this specification.

> no reason to repeat it now.

I do understand this decision.

However, I am going to point out once more, that configuring a 
bi-directional IPv6inIPv4 tunnel, should align with configuring other 
bi-directional tunnels (PPTP, L2TP, MPLS etc...), and other links, or 
virtual links(PPP, ATM VC's, FR VC's,...) where the configuring provides
an error notification mechanism in case misconfiguration prevents a 
correct establishing of the tunnel, or link.

This alignment is necessary not for appearance reasons, but for sound 
design and operational reasons, which pointed the above mentioned 
protocols to implement such error notifications.

Another comment, which I consider important:

Orthogonal to the error notification, the introduction of 
bi-directionality without support of passing/negotiating configuration 
information automatically between the two end nodes of the tunnel, 
similar to other bi-directional tunnels, links, or virtual links 
(mentioned in previous paragraph) leaves the protocol look as incomplete 
('half baked').

> Please speak up (on- or off-list) within a couple of days.

Here are my comments/suggestions regarding the new text:

Comment 1 (major)
-----------------
Page 4, Section 1.1, Configured Tunnels

         .... behaving as virtual point-to-point links
         between the IPv4 tunnel endpoint addresses.

Problem:

"virtual point-to-point links between ..addresses", introduces a new and 
faulty concept.

IETF, and other standards bodies are very clear on these concepts:

- Point-to-point links are between two nodes
- nodes are attached to links through interfaces
- addresses are identifiers of interfaces on the link, and network.

Suggestion:

replace "addresses", with "nodes", or
remove "addresses", and make "endpoint" plural, i.e. "endpoints".

Comment 2
----------
Page 8, Section 3., last paragraph, and all other occurances

..... protocol-41, or protocol 41...

Problem: language

Suggestion:
replace "protocol-41", or "protocol 41" with
"IPv6 in IPv4 tunneling protocol"

Comment 3
----------
Page 15, Section 3.5

                 An IPv4 address of the encapsulator: either manually
                 configured or an address of the outgoing interface

problem: language

Suggestion:
replace with:
	
                 An IPv4 address of the encapsulator: manually
                 configured or automatically selected from the addresses
                 of the outgoing interface

Comment 4
----------
Page 15, Section 3.5, last paragraph

... tunnel peer has configured...

also penultimate sentence of paragraph

Problem:language; the "tunnel peer" is the object of configuration and 
not the agent performing the configuration.

Suggestion:

replace "has" with "was".

sentence is still awkward, and unclear. Replacing text was suggested 
with earlier message.

Comment 5
----------
Page 21, Section 5.

     -   IPv4 source address of the packet MUST be the same as configured
         for the tunnel end-point,

problem: ambiguity in text; as it is a bi-directional tunnel, the tunnel 
end-point is configured with a reverse path tunnel, i.e. a source 
address, which is one of the decapsulator's addresses. Without 
qualifiers, "configured" can be understood as applying to several 
things, in which "source address" is different.

Suggestion:
replace with:
"IPv4 source address of the packet MUST be the same as the tunnel 
entrypoint address configured for filtering purpose in the tunnel 
exitpoint (decapsulator)

> (editor hat off)

regards,
Alex

---

From: Pekka Savola <[email-masked]>
Date: Mon, 23 Aug 2004 23:58:34 +0300 (EEST)

> does perform an address check, on the completion of the interface 

Yes, I did read it.  But because the check is made later in the
process, after already configuring the tunnel (but rather when
deciding whether it's feasible to being operationally enabled or not),
it's entirely different issue -- which cannot be tackled without going
in depth to the operational status issue which is IMHO something we
should not do.  The point which was made that configuration-time
checking has drawbacks, and that's one reason we don't want to
recommend it, but leave it entirely up to the implementors.
 
> protocol engine, as opposed to the command used to configure the tunnel.

I disagree with this.  This depends on what you define the 'protocol'.  
I define the protocol as a mechanism which runs between two IPv4
configured addresses: whether it has a chance of working or not
depends that the configuration information ("input function" if you
consider the protocol as a system) has been entered correctly.

You probably think that it's protocol's job to deal with
misconfiguration, and a BUG of the protocol if it doesn't; my
assumption is that the protocol must work correctly with the correct
configuration, and nothing more is required.
 
> socket to an address, checks that the address belongs to the node.

That is IMHO a bad analogy as I pointed out.  TCP and UDP are
user-level protocols, requested by applications which have no specific
rights or privileges.

Setting up tunnels *always* (AFAICS) requires special "administrative"  
privileges.  It's not meant to be used by regular users and apps in
any way they feel fit.  Sure, if they're given sufficient permissions,
they could set up tunnels, but it comes with the caveat that they must
know what they're doing.

> setup issue", with appropriate place to address in the protocol setup 

As stated above, I disagree with this interpretation of the protocol.  
Protocols must not require being designed to work with incorrect input
from the administrators.

> the "protocol setup code".

I fail to see the analogy.  If you don't use CLI (which is implicitly 
assumed), it's an implementation issue to deal with the consequences, 
i.e., appropriately define the checks to the function calls to make 
the protocol work better even with wrong input.
 
> protocols to implement such error notifications.

As noted offlist, these examples are not close to what this spec is 
aiming to do.  This is intended for a very simple mechanism, requiring 
*manual* configuration.
 
> (mentioned in previous paragraph) leaves the protocol look as incomplete 

Again, such protocols can be specified and used in conjuction with
this spec, to help set up the tunnels.  See for example TSP.  Or you
could just use L2TP instead, that provides v6 support out of the box.

> Comment 1 (major)

Please provide a pointer to such concept because I haven't heard of
such consensus.  Point-to-point can be whatever we define it to be as
long as the definition of "point" is clear, which is exactly what I
was doing :-).

> remove "addresses", and make "endpoint" plural, i.e. "endpoints".

No; the fundamental presumption of the current specification is to
provide a tunnel between configured *addresses*, not *nodes* (which
could have multiple addresses).  As the new security checks etc.  
prevent the use of more than one address per node, we must spell out
the assumption that we want p2p between addresses not the more generic
p2p because it doesn't work.

> Comment 2

This doesn't seem a good approach, because protocol 41 is very 
specific.  There could be other v6-in-v4 tunneling protocols which 
might not use protocol 41.  It's better IMHO to use protocol-41 which 
is short and accurate (as far as it can be accurate).
 
> Comment 3

Could your suggestion be interpreted that the manually configured
address must be an address of the outgoing interface?  That would be
wrong, because it can be e.g., the loopback address.  I don't see how
your suggestion clarifies.
 
> Comment 4

I can't parse the sentence if I change "has" to "was" so I guess 
you're reading it differently than I am.

Would it be clearer to just remove the text about tunnel peer (because
it's now stated just before section 3.1) and change to singular for
clarity, like:

   When encapsulating the packets, the node must ensure that it will
   use the correct source address so that the packets are 
   acceptable to the decapsulator as described in Section 3.6. [...]
 
> Comment 5

I've wanted to avoid introducing the entry/exit point terminology, and 
I don't want to say that the entrypoint is just configured for 
filtering purpose; it's dually configured for the purposes of sending 
packets to that address, so I don't think it needs to be said here.

Further, these bullets are just referring & summarizing the checks
earlier in the draft, so I don't want expand it a lot here, rather
just include a referring pointer if really necessary.

Would adding a referral to section 3.6 help, like replace:

   Therefore, this memo specifies that the decapsulators make these
   steps to mitigate this threat:

with:

   Therefore, this memo specifies that the decapsulators make these
   steps (described in Section 3.6) to mitigate this threat:

.. or some other smaller change?

Thanks!

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 Aug 2004 10:10:44 -0700 (PDT)

> http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre-diff.html

Works for me.

Two nits though:
1. I think the names of people listed in the acknowledgements was originally
   in alphabetical order. I see that this is no longer the case but it
   might make sense to put them back in alphabetical order.

2. In the change log there is a change from

   -    Added a note that using TTL=255 when encapsulating might be
        useful for decapsulation security checks later on.
to
   -    Added a note that using TTL=255 when encapsulating.

which seems like an incomplete sentence. Did you intend to change this
bullet?

  Erik

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Aug 2004 11:43:36 -0700 (PDT)

>    might make sense to put them back in alphabetical order.

It seems that the order has reverted to chronological,
but it doesn't matter as far as I'm concerned.

I have another comment for this document; in section 3.6, change:

  "The encapsulating IPv4 header is discarded."

to:

  "The encapsulating IPv4 header is discarded, and the version
   encoded in the first 4 bits of encapsulated packet is checked.
   (Procedures for handling packets with version other than 6 are
   out of scope.)"

A paragraph break should also be inserted before the next
sentence beginning: "When reconstructing the IPv6 packet...".

Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Aug 2004 22:09:23 +0300 (EEST)

>    (Procedures for handling packets with version other than 6 are

I'm not sure if that's really needed.

The first paragraph says:

  When an IPv6/IPv4 host or a router receives an IPv4 datagram that is 
   addressed to one of its own IPv4 addresses or a joined multicast
   group address, and the value of the protocol field is 41, the packet 
   is potentially a tunnel packet and needs to be verified to belong to
   one of the configured tunnel interfaces (by checking
   source/destination addresses), reassembled (if fragmented at the IPv4
   level), have the IPv4 header removed and the resulting IPv6 datagram 
   be submitted to the IPv6 layer code on the node.

(note tha last sentence.)

If the v6 layer code does not check the IP version first, why should 
we specify additional checks? 

Note that often the IP delivery is done based on lowe layer, e.g.,
ethernet protocol number, so if an IPv6 packet where the version is
not 6 it's usually silently discarded as a bug in the lower layer if
the implementation even checks that.  That being said, tunneling
provides an easier means to inject bogus packets than physical link
layers.

That said, if folks think it makes sense to spell this out, I'd rather
suggest placing the version check as a new paragraph after the one you
proposed, without the text in ()'s.

Opinions?

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Aug 2004 13:35:22 -0700 (PDT)

> proposed, without the text in ()'s.

I can live without the text in ()'s, but the version check has
to come immediately after: "The encapsulating IPv4 header is
discarded". (If the version is bogus, no further IPv6 header
fields should be checked.)
 
Fred Templin
[email-masked]

---

From: Alex Conta <[email-masked]>
Date: Tue, 24 Aug 2004 15:19:49 -0400

Before I dive into answering point by point your remarks, I am going
to summarize the point we've reached:

Positive:
- the major problem related to the source address has been resolved.
- editorial comments were I think, with one partial exception (Section 
3.5. last paragraph), resolved.

This is very good, and encouraging progress!

Still to be resolved:
- Definition of configured tunnels in Terminology Section
- Some text delivering the right perception to the reader, that the
tunnel source address being configured is checked during the "tunnel
establishing phase", which is not the same with the "data exchange
phase" of the tunnel protocol, and is not the same with a CLI command 
acting on its own, with no coordination whatsoever with the protocol 
specifications.

So here it is:

Pekka Savola wrote:

> [...]

1. You seem to view the encapsulation/decapsulation, which is the "data
exchange" part of the protocol, as the only part of the tunnel protocol.

So let me clarify:

The tunnel protocol, like any other similar protocol, has two phases: a
protocol setup phase (a), which can also be called protocol control, and 
a protocol data change phase (b).

The protocol specification states the requirements and the functioning 
for both. Some specifications are organized differently than others, 
some have distinct sections, some are split, some name one phase as an 
independent sub-protocol, but that ultimately is irrelevant.

The tunnel creation is the "establishing phase of the tunnel protocol",
which is part of the "protocol control phase". Removing a tunnel, which
is the "tear-down phase of the tunnel protocol" is also part of the
"protocol control phase". These are protocol phases even though there is
no message exchange.

So there are two phases of the tunnel protocol:
- "control/setup" (establishing, tear-down) and
- "data exchange" (encapsulation/decapsulation).

This is quite similar to other protocols that create links, or virtual
links: PPTP, L2TP, PPP, ATM VC, FR VC, etc...

> configuration, and nothing more is required.

2. Let me clarify: the protocol specifications is supposed to state the 
requirements for the setup/control and data exchange phase, for the 
protocol to function correctly. When any of the requirements of protocol 
setup/control are not met, we deal with a protocol misconfiguration problem.

The Tunnel Protocol setup - the tunnel configuration - regulated by the 
tunnel establishing phase specification, is implemented in most cases 
with some split between a CLI command - 'ifconfig' for instance, and the 
"protocol control" section of code in the tunneling module (tunneling 
driver, kernel, or whatever name may have). The former is invoked and 
passed parameters by the user/administrator, the latter is called, under 
soma form, for instance system function call, and passed some partially 
pre-processed, or fully processed parameters, by the former.

Again, the two components - 'ifconfig'(a) and 'tunnel establishing 
phase' code in the tunnel module (b) - act together in configuring 
tunneling, following the requirements and functioning set forward by the 
protocol control phase specification. Detecting any requirement of this 
phase that is not met, whether detected by (a), or by (b) is 
communicated to the user: directly by the former (a), or through the 
former(a) by the latter (b).

The data exchange phase of the protocol is implemented entirely in the 
tunnel module. The requirements for its correct functioning are dealt 
with the implementation of this phase, and appropriate error 
notifications are sent to the client, with ultimate target the user, or 
administrator.

It seems that your interpretation, passed to the text of the 
specification, and consequently perceived by the reader, that there is a 
complete disconnect between the protocol and its configuration, and that
configuration is somewhat performed and successful by chance, and not by 
following some clear specifications.

This is what I was suggesting you to try understand and address.

> they could set up tunnels, but it comes with the caveat that they must

3. This is not really relevant for the essential point of this message,
nevertheless some clarification is in order:

For what is worth, I know you pointed out, but it was pointed back to
you, why the analogy is valid. The analogy is valid, in terms of source
address check by TCP socket "bind" (connection setup), similar to tunnel
establishing phase source address check. The analogy is also valid in 
what concerns separation between control functions and data exchange 
functions of the protocol:

- the tunnel "establishing phase" corresponds to the establishing of the
TCP virtual circuit, or a connected UDP, as a protocol control function.

- the tunnel  "tear-down phase" corresponds to the closing of a TCP
virtual circuit, or a connected UDP as a protocol control function.

- the tunnel "data exchange phase", corresponds to the TCP, or UDP data
exchange phase.

You are right that privileges are required. But they may have just
been misleading, since they are not relevant, even if at a closer, we
realize that there is no difference: a tunnel interface creation 
(ifconfig) is a command requiring user privileges, but so are using 
certain TCP and UDP ports that require user privileges

> As stated above, I disagree with this interpretation of the protocol.  

If you disagree, it means you're assuming that the CLI command is
performing entirely the tunnel establishing phase, and that the
establishing phase is not part of the protocol. These assumptions are
both incorrect. Ifconfig, and BSD IPv6 in IPv4 tunneling are a good example.

> Protocols must not require being designed to work with incorrect input

If I parse this correctly, this is a misunderstanding. I have not said
this.

But I am saying that a correct protocol specification will require that
incorrect input from the administrator does not pass undetected the
control functions phase of the protocol.

> the protocol work better even with wrong input.

Let's clarify the steps:

a. The administrators enters a CLI command to configure the tunnel. The
tunnel source address parameter entered with the CLI command is verified
by the administrator, who also must be privileged to invoke the command.

b. The CLI command does some pre-processing and validates that the 
tunnel source address is a valid IPv4 address. For instance returns an 
error if the source address specified is 01::0d:05:e0:f5.

c. The "tunnel establishing phase", part of the tunnel protocol control
function, which is invoked through a system function call, plugged into 
the tunnel module, validates further the pre-processed parameter, for 
instance that the IPv4 address is one of the node's addresses. For 
instance returns an error if address 1.2.3.4, which passed (b), is not 
2.3.4.5, and 3.4.5.6 the two ipv4 addresses of the node.

The point is that, the configuring of the tunnel is split in
b. and c., and the functions performed by b. and c. are following the 
protocol setup functions set forward by the specifications. Assuming 
(b)'s functions 'bf', and (c)'s functions 'cf', and the functions 
required by the specifications 'sf', the following equation reflects a 
correct implementation:

bf + cf = sf      (eq)

The choices an implementer has are:

i. not to follow the specifications, in that case:

bf + cf < sf

or,
ii. how much of 'sf' to put in 'bf', or in 'cf'. In some implementations

bf > cf, in other bf < cf, in other bf = cf.

The correct implementation is always reflected by the equation (eq).

I hope this helps.
>>[...]

So, you define a v-link between *addresses*, then you would define
interfaces, which are the attachment points of the *addresses* to the
v-link, and than you would define the addresses of these interfaces,
that identify these interfaces. So you would end up with addresses of
attachment points of *addresses* to the v-link...(-:

This is funny, it really is: I suggest this as good material for April
1st (Fool's day) RFC.

>>- addresses are identifiers of interfaces on the link, and network.

As I said, IETF and other standards; please check IETF RFC 1812,
MIL-STD-188,  ATIS/ANSI Glossary, IETF RFC 2460, IETF RFC 2461, to
mention a few.

> p2p because it doesn't work.

Seriously now, as far as I can say, some liberties were taken here, and
quite a bit of bending to make things fit, not to say more...

The concepts of network, links, interfaces, addresses, are part of the 
Internet Architecture, they are strongly inter-connected,  and 
inter-dependent, and you cannot simply change the definition, or the use 
of one the concepts, without defining a new architecture: Good luck if 
that's what you intend!

Even though they are abstract concepts, they have a direct 
correspondence  to physical reality:
- nodes are systems; they are either clients of the network (hosts), or 
serving network infrastructure functions (routers, switches).
- a link interconnects nodes (systems)
- a network is several links, a data communication infrastructure (cable 
or wire) interconnecting multiple nodes,

Ultimately, I have not seen much discussion about this, since I started 
following this list, I know I voiced my non-enthusiasm in the context of 
this tunneling specification, but I have not followed
closely this WG before... Can you point to some WG discussion on this
topic?, some WG consensus? some standards defining such ptop links?...

> is short and accurate (as far as it can be accurate).

It is common practice in good specifications - take IPv6, or IPv6 ND.
I would use the official name under which protocol 41 is assigned.
There can't be confusion there...

> your suggestion clarifies.

I see your point, you are right. Switching places would do it:

         An IPv4 address of the encapsulator: automatically
         selected from the addresses of the outgoing interface

         or manually configured.

>    acceptable to the decapsulator as described in Section 3.6. [...]

This is much better. It is clearer, and does the job for me.

> packets to that address, so I don't think it needs to be said here.

In the problem description above, I pointed out exactly to this type of
confusion, which you mentioned here.

Try to put yourself in the shoes of a first time reader. The
interpretation should not be ambiguous, and not different from that of
the familiar reader of the spec.

> .. or some other smaller change?

Probably yes.

In the same time, there is the suggestion or reminder that Security
sections are almost independent sections, with a life of their own, so
repeating some stuff may not hurt.

> Thanks!
My pleasure, I hope it helps. We move forward and that is very positive.
I appreciate that.

Regards,
Alex

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Wed, 25 Aug 2004 09:54:42 +0530

Hi pekka,
 as soon as the packet is decapsulated, we should do the version 6 check.

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Fred Templin" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>; "Alex
Conta" <[email-masked]>
Sent: Wednesday, August 25, 2004 12:39 AM
Subject: Re: mech-v2-05pre

---

From: "O.L.N.Rao" <[email-masked]>
Date: Wed, 25 Aug 2004 10:46:50 +0530

Hello All,

    I hope most of the IPv6 implementations do first check IP Version
    [Otherwise, TAHI does not allow that to be a "IPv6 Ready Logo"
implementation]

    Some implementations first check whether there is atleast 40 bytes (IPv6
Header Size) left in the packet.
    Once, it makes sure that there is atleast IPv6 Header Size data, then it
tries to process the header.
    Here, the first field processed is IP Version.

    Thank you,

Regards,
O.L.N. Rao

----- Original Message ----- 
From: "Radhakrishnan Suryanarayanan" <[email-masked]>
To: "Pekka Savola" <[email-masked]>; "Fred Templin" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>; "Alex
Conta" <[email-masked]>
Sent: Wednesday, August 25, 2004 9:54 AM
Subject: Re: mech-v2-05pre

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Aug 2004 08:33:03 +0300 (EEST)

> a protocol data change phase (b).

The protocol setup phase in this protocol is "administrative 
configuration".

> links: PPTP, L2TP, PPP, ATM VC, FR VC, etc...

All of these also include a lot of other negotiation.  Configured 
tunneling has no negotiation, and that's on purpose.

> following some clear specifications.

Yes, there is a disconnect between the data exchange and configuration 
in a sense.. that's because the data exchange should not need to care 
whether the configuration has been correctly entered or not.

Remember, the "setup phase" of the protocol does not even provide
positive acknowledgements when a tunnel has been set (on purpose!), so
you'd have to rely on negative acknowledgements.  But as that hasn't
been widely implemented, and will not be such, you cannot rely on
negative acks either.  So you'd end up in a situation that sometimes
you might get a negative ack ("the other end has not configured a
tunnel, this won't work"), but as you can't rely on getting those,
you'll have to do some other testing of the tunnel (e.g., by pinging
in any case).

The more complex protocols you list include an explicit negotiation
phase, so this is not an issue, but here the goal was to produce a
simple tunneling specification which relies on *manual*, correct 
configuration.
 
> establishing phase source address check. [...]
> 

Again, TCP "bind" is not IMHO a valid analogy.  Users can create such 
sockets and you have to do more scrutinous checks on the input.  While 
the users can run ifconfig, they have no privileges to actually create 
the tunnels.  So this is different.

A closer comparison (though not 100% accurate) IMHO is whether a host
must prevent the node from sending out packets with wrong source
addresses w/ raw sockets.  The permissions required for this and
configuring the tunnel are the same.

> establishing phase is not part of the protocol. These assumptions
> are both incorrect. Ifconfig, and BSD IPv6 in IPv4 tunneling are a
> good example.

I didn't think ifconfig was a good example of "tunnel establishment
phase".  If you configure the tunnel with an ifconfig command (for
example), then it has already been established as soon as you'll
receive no error code from the command.

> control functions phase of the protocol.

But that's still saying that the implementations will have to 
sanity-check the input given by the administrators.  Some 
implementations may want to do that, but as I showed, all of those I 
personally looked at didn't bother to do so.

The principle is that the admin can shoot itself in the foot, and if 
the tunnel doesn't work, he can only blame himself for 
misconfiguration.

> by the administrator, who also must be privileged to invoke the command.

Yes.
 
> error if the source address specified is 01::0d:05:e0:f5.

The implementation probably does a syntactic check yes, but that's an 
implementation decision.
 
> 2.3.4.5, and 3.4.5.6 the two ipv4 addresses of the node.

No, the tunnel establishment phase doesn't need to verify this (even
though it can if it wants).  I gave you 4 implementation examples
where they DON'T check this, and IMHO it's a good thing (because I
have a firm belief that we must not mandate the implementations to
"babysit" the operators, but I acknowledge that some implementations'
user base may be such that they require serious babysitting).
 
The current text in 05pre just clarifies that if the address isn't 
configured on the node, it's probably a misconfiguration -- but it 
doesn't mandate checking the address.

> attachment points of *addresses* to the v-link...(-:

There is no reason AFAICS why you need to be concerned what are the
attachment points of the addresses.
 
> This is funny, it really is: I suggest this as good material for April

I really hope it doesn't get that long for the RFC editor to produce 
this RFC, but April 1st is otherwise as good as any to me :-).
 
> of one the concepts, without defining a new architecture: Good luck if 

I think you're concerned about this from the pedantical perspective.

If we wanted to be 100% accurate, I guess one could reword:

All tunnels are assumed to be bidirectional, behaving as
virtual point-to-point links between the IPv4 tunnel endpoint
addresses.

to something like:

All tunnels are assumed to be bidirectional, behaving as virtual
point-to-point links between nodes, using the specified IPv4 
addresses as tunnel endpoints.

.. because the p2p links are between the nodes, the text above just 
makes it clear that the tunnels are tied to a particular address of a 
node, and they cannot be used except with that single address of the 
node.  So I'm don't think it's worth changing the above because
it doesn't increase clarity of the definition, just decreases it.

>          selected from the addresses of the outgoing interface

Compared to the current text, this has switched the order, removed
"either" (which seems like a no-op), and included "automatically
selected from the [addresses]", which is IMHO worse.  That's because
automatic selection should really not be used when there are multiple
addresses (because the results will likely not be deterministic, and
the decapsulator must have the correct configuration) -- you cannot
rely on automatic configuration getting it right!  So, I'd like to
avoid giving the expectation that automatic selection would work w/
multiple addresses.., hence I'd prefer to leave it as-is.

> > .. or some other smaller change?

I've only done that, in order to keep the changes at the minimum and 
to not repeat the whole checks in Security Considerations; it's only 
meant to be a summary of them in any case.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Aug 2004 08:47:33 +0300 (EEST)

>     Here, the first field processed is IP Version.

Good points; this is reflected at:

http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2-diff.html

See if it addresses your concerns (if OK, off-list is fine).

---

From: "O.L.N.Rao" <[email-masked]>
Date: Wed, 25 Aug 2004 12:11:28 +0530

Hi Pekka,

    The modifiet text is fine with me :)

Thank you,
O.L.N. Rao

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "O.L.N.Rao" <[email-masked]>
Cc: "Radhakrishnan Suryanarayanan" <[email-masked]>; "Fred Templin"
<[email-masked]>; "Erik Nordmark" <[email-masked]>;
<[email-masked]>; "Alex Conta" <[email-masked]>
Sent: Wednesday, August 25, 2004 11:17 AM
Subject: Re: mech-v2-05pre

---

From: Fred Templin <[email-masked]>
Date: Wed, 25 Aug 2004 08:10:55 -0700 (PDT)

Pekka,
 
In section 3.6, change:
 
   "If the payload is not at least 40 bytes in length (i.e., the minimum
   IPv6 packet), the packet MUST be discarded.  Likewise, if the the
   version encoded in the first 4 bits of the encapsulated packet is not
   "6", the packet MUST be discarded.
  
   The encapsulating IPv4 header is discarded."

to:

  "The encapsulating IPv4 header is discarded, and the version
   encoded in the first 4 bits of encapsulated packet is checked.
   If the version is "6" and the payload is not at least 40 bytes in
   length (i.e., the minimum IPv6 packet), the packet is discarded.
   (Procedures for handling packets with version other than "6" are
   out of scope.)"
 
If anyone is unsure why this is being suggested, please see the
IPvLX draft before commenting here.
 
Fred L. Templin
[email-masked]

Pekka Savola <[email-masked]> wrote:

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Aug 2004 22:19:54 +0300 (EEST)

> IPvLX draft before commenting here.

I think this proposed change would only add ambiguity.  It seems
clearer to specify these before specifying discarding the v4 header.

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 25 Aug 2004 16:11:21 -0400

Wouldn't the version check be part of the standard IPv6 processing?
Why do we want to mandate it here as well?

I can see the need to make sure that we have enough data, so the
decapsulator may want to check that it has at least 40 bytes of
payload, but the version check seems redundant to me.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Linux and Open Source Lab
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Aug 2004 07:43:51 +0300 (EEST)

> payload, but the version check seems redundant to me.

Well.. folks asked for the version check..

I can see a justification in the sense that AFAIK it's not strictly 
necessary to check the IP version when processing the packets, because 
the lower layer (ethernet protocol type, protocol 41, etc.) already 
indicated the ip version of the payload.  When using a tunnel, the 
chance of someone sending packets which aren't really IPv6 but using 
proto-41 (or the like) seems significantly larger than e.g., using 
Ethernet.

So, in that sense, both checks are redundant, just spelling out checks 
which should be done for IPv6 packets in any case, but I don't think 
it hurts to have them here.

If other set of folks think it's bad idea to have them here, we could
just remove the paragraph (and it would be as it was before), or add 
something like, "As with processing any other IPv6 packet received 
from link-layers, ...." to clarify that this particular link layer 
should not be special...

Thoughts?

Note: I already submitted -05 with the change.

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Thu, 26 Aug 2004 11:30:24 +0530

Hi pekka,
   I agree with your view that having those checks helps. I think we should
retain them.
The idea is only to indicate to the implementor of the need for the check to
filter out non-ipv6 packets while decapsulating like any other layer 2
protocol implementation does.
Rgds
Radhakrishnan
----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Vladislav Yasevich" <[email-masked]>
Cc: "Fred Templin" <[email-masked]>; "O.L.N.Rao" <[email-masked]>;
"Radhakrishnan Suryanarayanan" <[email-masked]>; "Erik Nordmark"
<[email-masked]>; <[email-masked]>; "Alex Conta" <[email-masked]>
Sent: Thursday, August 26, 2004 10:13 AM
Subject: Re: mech-v2-05pre

---

From: Fred Templin <[email-masked]>
Date: Thu, 26 Aug 2004 08:17:32 -0700 (PDT)

Vlad,
 
Pekka has already provided I think a good rationale for the version check,
and it is beyond the scope of this document to say what decapsulators
do when encapsulated packets with version other than '6' are received.
 
Fred L.Templin
[email-masked]

Vladislav Yasevich <[email-masked]> wrote:

-vlad

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 26 Aug 2004 12:54:32 -0400

Fred

I agree.  Thus I think mandating that the packets be dropped is way
to harsh.  Just stating that version other then 6 is outside the scope
is fine.

-vlad

Fred Templin wrote:
> [email-masked] <mailto:[email-masked]>
> 
> */Vladislav Yasevich <[email-masked]>/* wrote:
> 
> 
>      >> "The encapsulati ng IPv4 header is discarded, and the version

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Aug 2004 21:35:33 +0300 (EEST)

> to harsh.  Just stating that version other then 6 is outside the scope

As far as I see it, this is practically just a matter of semantics.

Unless we think that there's going to be another IP protocol which has
almost identical headers as IPv6 so that you'd be cable to transport
the "new" IPv6 packets (let's call them IPv11 packets just to make
sure they don't overlap with other proposals ;-) over unmodified
configured proto-41 tunnels.

On the other hand, if the IPv11 header would be significantly 
different from IPv6, there would be a need to specify a different 
configure tunneling in any case, so it doesn't matter what we specify 
in protocol-41 configured tunneling.

I somehow don't see the chance that in future we'd have to 
support almost identical new IP protocol versions over unmodified 
configured tunnels, so a drop policy seems like the most useful 
one.  It's really practically required in any case, because we require 
parsing a number of fields, like src/dst addresses, hop limit, ECN 
bits, etc.

Of course, if there's another spec down the road which modifies 
proto-41 configured tunnels behaviour somehow so that other IP 
protocols than just "6" are OK, that's fine as well.  The question is 
just about whether unmodified configured tunnels could support 
protocols other than "6", which doesn't seem to be the case..

---

From: Fred Templin <[email-masked]>
Date: Thu, 26 Aug 2004 12:16:59 -0700 (PDT)

> protocols other than "6", which doesn't seem to be the case..

As far as I can tell, no one is suggesting *support* for protocols
other than "6".

The suggestion is for the specification to declare as out-of-scope
the behavior for packets discovered to have version other than "6"
after the encapsulating IPv4 header is discarded.

Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Aug 2004 22:48:01 +0300 (EEST)

> after the encapsulating IPv4 header is discarded.

Right, and in such a case there'a very little difference to just
specifying drop here (and specifying the other protocols elsewhere),
or declaring it out of scope (and implying a drop and specification
elsewhere).

Just because this spec says they MUST be dropped doesn't mean some 
other spec cannot say that instead of dropping, something else needs 
to be done about them.

(Example: options which are "must be zero and ignored", which later
specifications define and specify meanings for.  In this case, there's
just no need for "ignored" because we don't expect interoperability.)

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 26 Aug 2004 16:11:57 -0400

Ok, I willing to drop my objection.  It seem like
a slight overspecifiction, but that's better then
having ambiguous text.

It just seemed to me in the begining that this was
an implementation detail and how and where it's
handled was up to the implementation.

The way text reads now, it seems like it's the job
of the tunnel driver to drop the packet, not the l3 (which
in my opinion is kind of backwards, i.e. ethernet doesn't
look at the IP header).

-vlad

---

From: Fred Templin <[email-masked]>
Date: Thu, 26 Aug 2004 15:15:25 -0700 (PDT)

Pekka,

> or declaring it out of scope (and implying a drop and specification

Drop silently? Drop and send an ICMPv4 error? Drop and send
an ICMPv6 error? Drop and do something else? By specifying
drop here, the behavior needs to be clearly spelled out to
avoid interoperability issues.

It seems both unambiguous and correct to say that if the version
is "6" and the payload is not at least 40 bytes, the packet MUST
be silently discarded. (Reason: there is no error from the IPv4
perspective, and there is not enough information to construct an
ICMPv6 error.) The same cannot be said for versions other than
"6", which argues for declaring out of scope.

Suggest re-wording the text as follows:

   "If the version encoded in the first 4 bits of the encapsulated packet
   is "6", and the payload is not at least 40 bytes in length (i.e., the
   minimum IPv6 packet), the packet MUST be silently discarded.  Further
   processing for packets with version other than "6" is out of scope."

Fred L. Templin
[email-masked]

---

From: Alex Conta <[email-masked]>
Date: Thu, 26 Aug 2004 18:06:48 -0400

[...]

[...]
[...]
> addresses as tunnel endpoints.

This is a lot better than before.

I suggest two small changes: remove 'the', and replace 'as' with 'of 
the' as in the following text:

    All tunnels are assumed to be bidirectional, behaving as virtual
    point-to-point links between nodes, using IPv4 addresses of the
    tunnel endpoints.

[...]
> multiple addresses.., hence I'd prefer to leave it as-is.

I suggested "automatically selected", to balance, and for symmetry to
"manually configured". Even if you remove "automatic selection", if it 
is not "manually configured", then it is still automatically selected, 
so you say "manually" for "configuring", but you say nothing for 
"automatic selection".

If you dislike "automatically selected", then just remove "manually", to
balance the text, but to me, the text that says both is better balanced.

Furthermore, regarding the technical aspects, which you elaborated 
above, I would like to walk through, to make some clarifications:

The "automatic selection of source address" relies on *route* selection:
this is always deterministic. The selected route to destination yields 
the outgoing interface, which is also deterministic.

Based on that, and furthermore, the "automatic selection" from *multiple 
addresses of a node* is *deterministic* if:
a. - there is one address per interface
else
b. - the prefix of one of the multiple addresses per interface matches 
the destination.
else
c. - the "automatic selection" is non-deterministic.

So, while I understand your point, I think it applies, only for (c.) and 
not the others, as you implied in your text above, and how the spec implies:

As the current text says "an address", it can also be any of the 
multiple addresses of an interface. Furthermore, as I pointed out 
before, the last paragraph in Section 3.5, is exposing itself once more 
as being weak.

So this need better clarification in the text.

Maybe changing the second phrase from:
    This may be a problem
    with multi-addressed, and in particular, multi-interface nodes,
    especially when the routing is changed from a stable condition, as
    the source address selection may be adversely affected.

to:
    Configuring the source address is to be considered particularly in
    cases in which the automatic selection of source address is not
    deterministic.

or,

    Configuring the source address is appropriate particularly in cases
    in which automatic selection of source address is not deterministic.

Note that an implementation has multiple choices:
1. can always give a WARNING to the operator, if the "automatic 
selection" is not deterministic, or
2. return with a question to the operator, which of the addresses in a 
possible list to choose.
3. return the selected address to the operator, to be used for further 
configuration at the other end node.

These could be documented in an Appendix, if you intended to have an 
Implementation Notes section.

This has been narrowed down considerably. I am really happy with the 
progress! If we could work out these last 2 issues, it would be great.

Regards,
Alex

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Aug 2004 08:44:26 +0300 (EEST)

>     point-to-point links between nodes, using IPv4 addresses of the

Let's discuss this in another thread off-list, as it seems more of
wordsmithing than anything else.

> balance the text, but to me, the text that says both is better balanced.

I could replace "manually configured" by "configured by the
administrator", if that would sound better without "automatically
selected".. otherwise I'd prefer to leave it as is.

I agree that the implementation has to select in any case (because it
says "an address"; that's because I didn't want to open the discussion
which would ensure if it said "the address" if you have multiple
addresses), but it just needs to be picked in any case, and it seems
worse to spell it out because it's suboptimal in the case when there
are multiple addresses.

> the outgoing interface, which is also deterministic.

Not necessarily if you run routing protocols.  Route changes somewhere
in the net could change the outgoing interface to be more optimal,
while the original interface's addresses could still work as well.
 
[...]
>     in which automatic selection of source address is not deterministic.

This seems OK to me, though I'm concerned that just saying "not 
deterministic" might not give sufficient guidance to the readers.

Maybe it should be elaborated with another sentence like:

 Configuring the source address is appropriate particularly in cases
 in which automatic selection of source address is not deterministic;
 this is often the case, e.g., with multiple addresses or with 
 multiple interfaces when using routing protocols.

> Implementation Notes section.

I'd rather avoid adding such a section.  

In this particular case, I think all the implementations either
require the admin to always specify the source address, or leave it up
to the responsibility of the admin to know when it must be specified.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Aug 2004 08:56:32 +0300 (EEST)

> avoid interoperability issues.

It should be obvious that it's "silent discard" but that can be 
spelled out if necessary.

> "6", which argues for declaring out of scope.

I can't see your point.  Protocol-41 is meant to transport *IPv6*
packets -- that's why it's protocol 41.  Your point would be valid (I
think) if we were specifying a more generic tunnel (like GRE), which
doesn't specify the protocol of the inner payload, but we aren't.. so
it seems fair to say that anything in the payload that's not IPv6 is
an error, and must be dealt with (and it's just a question where it's
specified clearly enough who needs to deal with it).

Again, this doesn't matter in practice at all (AFAICS) unless one
intents to devise a new IP protocol almost exactly like IPv6 which
must be tunneled across unmodified protocol-41 configured tunnel 
implementations.

FWIW, I personally understand Vlad's concern that checking is really
the job of the IPv6 code, not the "Layer 2" code, but in this case 1)
when tunnels have a bigger chance of transmitting bogus packets, 2)
the protocol-41 already specifies that the content is IPv6, and 3) we
already specify a lot of check in the layer 3 contents, this should
not be a big issue to make sure that the implementor doesn't forget to
check the version & length.

---

From: Fred Templin <[email-masked]>
Date: Fri, 27 Aug 2004 06:30:12 -0700 (PDT)

Pekka,
 
I thought about it more, and the only way a decapsulator should be able
to receive an encapsulated packet with version = 6 and length less than 40
is if the act of encapsulation itself were the source of the truncated packet
(or, if the packet were somehow truncated in the IPv4 network). Reason is
that truncated packets would be discarded by IPv6 long before ever reaching
the encapsulator's IPv6-in-IPv4 tunnel driver. Some implementors might see
this as reason for sending an ICMPv4 error, so if we want it to be "drop silent"
this needs to be clarified.
 
About versions other than 6, if you want to argue that having something
other than 6 is an error, then that would suggest sending some sort of
error message - but it's not clear exactly what kind of error could be sent?
(ICMPv6 "parameter problem"? Some kind of ICMPv4? Other?)
 
Aside from this, I think we are both correct to a certain degree but for the
above reasons I believe my text suggestion is better. Here it is again: 

Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Aug 2004 22:40:51 +0300 (EEST)

On Fri, 27 Aug 2004, Fred Templin wrote:
> the encapsulator's IPv6-in-IPv4 tunnel driver.

Yes.

> Some implementors might see

If e.g., checksum (of v4) fails, there's no ICMP error, so there
shouldn't be one now.

> (ICMPv6 "parameter problem"? Some kind of ICMPv4? Other?)

No, I don't think sending an ICMP message is needed, because the
link-layer is supposed to be v6-only.  The close analogy is that if
you receive an ethernet frame with the IPv6 type, but the protocol is
not in fact IP version 6, no error is sent.  There's no use sending
error messages on packets which the sender should know are bogus.

So, I think we just disagree about this and need to get more input.  
Let's consider three options:

 1) something like the current text, disallowing non-IPv6 packets:

  If the payload is not at least 40 bytes in length (i.e., the minimum
  IPv6 packet), the packet MUST be silently discarded.  Likewise, if 
  the version encoded in the first 4 bits of the encapsulated packet 
  is not "6", the packet MUST be silently discarded.

 (support from O.L.N.Rao and Radhakrishnan Suryanarayanan)

 2) something like you proposed, leaving non-ipv6 unspecified:

  If the version encoded in the first 4 bits of the encapsulated packet
  is "6", and the payload is not at least 40 bytes in length (i.e., the
  minimum IPv6 packet), the packet MUST be silently discarded.  Further
  processing for packets with version other than "6" is out of scope.

 (support from Fred Templin)

 3) leave everything out, let the IPv6 code deal with this.

 (support from Vlad Yasevich)

What do others think?

Personally, either 1) or 3) seems best to me.

---

From: Alex Conta <[email-masked]>
Date: Sat, 28 Aug 2004 01:45:30 -0400

> wordsmithing than anything else.

I am going to answer on the list to this separately. It may look like 
wordsmithing, but it is not. It is about mixing architectural 
concepts/definitions, it is about consistency.

> selected".. otherwise I'd prefer to leave it as is.

Actually "...administrator" sounds better.

> Not necessarily if you run routing protocols. 

The selection of a route, and yielding the outgoing interface is a 
deterministic process - longest prefix match is the algorithm - 
regardless of using routing protocols, or manually configured routes.

Note, a route change may occur even if you do not use routing protocols: 
an operator can enter any time commands to add/change/remove routes, 
which may have exactly the same effect as dynamic routing changing of 
routes.

Route changes somewhere
> while the original interface's addresses could still work as well.

I just realize, that you and I used the word "deterministic" to mean 
different things. So I am going to change the text you last suggested, 
to reflect your meaning.

>  multiple interfaces when using routing protocols.

Configuring the source address is appropriate particularly in cases in 
which automatic selection of source address results in different 
addresses in a certain period of time. This is often the case with 
multiple addresses, and multiple interfaces, when routes change frequently.

or

Configuring the source address is appropriate particularly in cases in 
which automatic selection of source address is producing different 
results in a certain period of time. This is often the case with 
multiple addresses, and multiple interfaces, when routes change frequently.

Regards,
Alex

---

From: Pekka Savola <[email-masked]>
Date: Sat, 28 Aug 2004 09:00:02 +0300 (EEST)

> Actually "...administrator" sounds better.

OK.

> different things. So I am going to change the text you last suggested, 

Possibly.  I used it roughly in the meaning, "is out of the control of
the administrator of the node, i.e., the behaviour is stable and can
be pre-determined by the administrator", i.e., if the admin manually
changes routing tables, that's OK, but if dynamical routing protocol
changes them, that's different.

> multiple addresses, and multiple interfaces, when routes change frequently.

OK, with a bit more conditionals thrown in the mix, because just the 
possibility of it happening should be sufficient to manually configure 
the address

Configuring the source address is appropriate particularly in cases in
which automatic selection of source address may produce different
results in a certain period of time. This is often the case with
multiple addresses, and multiple interfaces, or when routes may change
frequently.

---

From: Alex Conta <[email-masked]>
Date: Sat, 28 Aug 2004 03:01:12 -0400

> multiple addresses, and multiple interfaces, or when routes may change
OK

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 28 Aug 2004 18:10:47 +0900

>>>>> On Fri, 27 Aug 2004 22:40:51 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> What do others think?

I think option 3 makes most sense.  I can live with option 1, but it
seems just redundant as Vlad pointed out.  Option 2 seems odd to me
because proto-41 should be specific to IPv6 and there seems no
reasonable reason to mention other versions than 6 in this context.

BTW, doen't option 3 also make those who support option 2 happy?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Aug 2004 10:29:25 +0200

RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent
discard in such a case, i.e. solution 1.

   Brian

---

From: Fred Templin <[email-masked]>
Date: Sun, 29 Aug 2004 04:23:34 -0700 (PDT)

> reasonable reason to mention other versions than 6 in this context.

If we can't reach agreement on new text with "MUSTs" then we should
revert to saying nothing at all and trust that robust implementations will
do the right thing w/o gratuitous specification, which I believe is also
reinforced by Brian's citations:

> discard in such a case, i.e. solution 1.
 
I agree that these points strongly suggest the silent discard, but wouldn't
that indicate solution 3? (BTW, "parsimonious" seems an odd word to
find in a document about simplicity.)
 
Fred
[email-masked]

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Mon, 30 Aug 2004 09:30:14 +0530

Hi fred, Jinmei & pekka,
The idea of suggesting the option 1 is to make it clear to the implementator
of possible bogus packets which needs to be taken care.

But definitely I am also not against option 3 provided that we add the info of "possible bogus packets threats" in the appropriate section in the draft.

IMHO, i would like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4.

-Radhakrishnan
  ----- Original Message ----- 
  From: Fred Templin 
  To: [email-masked] ; Brian E Carpenter ; [email-masked] 
  Sent: Sunday, August 29, 2004 4:53 PM
  Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre]

  Fred
  [email-masked]

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Mon, 30 Aug 2004 10:20:57 +0530

Errata correction :
IMHO, i would NOT like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4.
  ----- Original Message ----- 
  From: Radhakrishnan Suryanarayanan 
  To: Fred Templin ; [email-masked] ; Brian E Carpenter ; [email-masked] 
  Sent: Monday, August 30, 2004 9:30 AM
  Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre]

  Hi fred, Jinmei & pekka,

  -Radhakrishnan
    ----- Original Message ----- 
    From: Fred Templin 
    To: [email-masked] ; Brian E Carpenter ; [email-masked] 
    Sent: Sunday, August 29, 2004 4:53 PM
    Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre]

    Fred
    [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Aug 2004 09:26:34 +0200

Fred Templin wrote:
> that indicate solution 3? 

Well, I think it's a matter of taste, really. Philosophically, silent
discard is supposed to be the Internet default, so you can argue that
it isn't necessary to state it everywhere. I could live with solution 1
or 3.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 31 Aug 2004 11:14:58 +0300 (EEST)

Hi,

(co-chair hat on)

OK, there seems to be multiple people supporting 1) and likewise for
3), but all of those could seem to be able to live with either of
these approaches.

As 3) is what we had in the document during WG last call, IETF LC, and 
IESG evaluation, let's use (basically) that.

However, to fix the problem pointed out by 1) in a slightly better
way, I'd suggest wording like (changes in the first sentence only):

The encapsulating IPv4 header is discarded, *and the resulting packet
is checked for validity when submitted to the IPv6 layer*. When
reconstructing the IPv6 packet the length MUST be determined from the
IPv6 payload length since the IPv4 packet might be padded (thus have a
length which is larger than the IPv6 packet plus the IPv4 header being
removed).

or: *and the resulting packet is checked for validity by the IPv6 
layer*.

(emphasis mine) -- this reminds that the v6 layer must validate the
packet, but leaves the the exact checks unspecified in this memo,
which was the main concern for those supporting 3).

If you have comments/objections to this, please state them
****off-list**** within a day or so.

(hat off)