Review of Keyed IPv6 Tunnel [draft-mkonstan-keyed-ipv6-tunnel-00]

"Carlos Pignataro (cpignata)" <[email protected]> Thu, 15 Aug 2013 20:13:12 +0000

Newsgroups	gmane.ietf.l2tpext
Message-ID	<[email protected]>

Hi, Rainer, Giles, Maciek, Mark,

After the presentation of this draft in Berlin at the PWE3 meeting (with thanks to the PWE3 chairs!) available at http://tools.ietf.org/agenda/87/slides/slides-87-pwe3-2.pdf, I wanted to provide some review comments with the chair hat off.

I hope these are useful and clear, they are prefaced with "CMP"

http://tools.ietf.org/html/draft-mkonstan-keyed-ipv6-tunnel-00

Network Working Group R. Schatzmayr
Internet-Draft Deutsche Telekom AG
Intended status: Informational G. Heron, Ed.

CMP: I do not think that the intended status of this document should be Informational, as you are proposing protocol changes.

Abstract

This document describes a simple L2 Ethernet over IPv6 tunnel
encapsulation with mandatory 64-bit authentication key for connecting
L2 Ethernet attachment circuits identified by IPv6 addresses. The
encapsulation is based on L2TPv3 over IP.

and

3. 64-bit Authentication Key

All packets MUST carry a 64-bit authentication key in the L2TPv3

CMP: a cookie does not provide an authentication key. It is a simple context lookup check.

1. Introduction

CMP: It might be useful to mention in the introduction that there is precedence with proposals to do away with the session id lookup when considered redundant, as for example with draft-ietf-l2tpext-l2tphc.

2. Static 1:1 Mapping Without a Control Plane

Use of the L2TPv3 Control Plane is optional. When the control plane
is not used, local configuration creates a one-to-one mapping between
the access-side L2 attachment circuit and the IP address used in the
network-side IPv6 encapsulation.

CMP: I am not sure I understand how it would work *with* the L2TPv3 Control Plane. Instead of saying that it is optional, I would say that it is out of scope or similar, and this behavior is specified for static sessions only. Optional means it can be used, and they you would have to say "how" (which new AVPs, etc).

Further, circuit monitoring is
performed using Ethernet OAM mechanisms (802.1ag and/or Y.1731).

CMP: Why Ethernet OAM and not L2TPv3/PW OAM? e.g., [RFC 5085].

In the event that an IPv6 address used in L2TPv3 does not directly
correspond to one and only one attachment circuit on both sides of
the L2TPv3 tunnel, the Session ID may be used for additional
granularity. This allows for other addressing schemes that may
require additional bits beyond those which can fit in the IPv6 header
address field.

CMP: Assuming there are some gains in processing the session context from the IPv6 address instead of the session id, which could be described, is that lost with this last paragraph? Why have both?

4. Encapsulation

o Session ID. In the "Static 1:1 mapping" case described in
Section 2, the IPv6 address resolves to an L2TPv3 session
immediately, thus the Session ID may be ignored upon receipt. For
compatibility with other tunnel termination platforms supporting
only 2-stage resolution (IPv6 Address + Session ID), this
specification recommends supporting explicit configuration of
Session ID to any value other than zero. For cases where both
tunnel endpoints support one-stage resolution (IPv6 Address only),
this specification recommends setting the Session ID to all ones
for easy identification in case of troubleshooting.

CMP: Could you add that it is non-zero?

8.2. Informative References

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.

CMP: THis reference is not cited in the doc, please remove.

Thanks,

-- Carlos.

_______________________________________________
L2tpext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext

signature.asc (application/pgp-signature, 203 B)