[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mech-v2-05pre
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).
Pekka Savola wrote:
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.
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.
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.
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.
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.
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').
Is this a sufficient resolution to the concerns voiced in the WG?
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature